Re: [Audacity-devel] Accessibility and Usability Feedback

[<vt...@ma...>]

Hi Leland,
Would you mind if I use a different quoting tac on the list? It would be=20
easier to read with speech if in stead of the greater than signs,=20
single-letter name tags would be used. I'll use L for your comments and V=
=20
for mine. IF you need to quote any previous bits just append an ordinal a=
t=20
the end of the tag or repeat the tag once or more.

L: Hi Veli,  (is that right???)
V: Well, almost. It is a Finnish male compound name so the full form=20
Veli-Pekka is ordinarily used. Think of Maryann for an English example. B=
oth=20
Veli and Pekka are also valid Finnish names. Most people call me simply b=
y=20
my nickname Vellu, which might be more mnemonic as well.

L: Wow!  Some really great feedback here and quite a bit to digest.
V: Glad to be of help <smile>.

L: hadn't thought about magnification as I've been concentrating on speec=
h.
V: I thought that would be the case and that's why I brought it up, thoug=
h=20
I'm mostly a speech user myself. Basically accessibility hurdles related =
to=20
magnification are often about color or contrast. FOr more info in my case=
,=20
you could have a look at my sight page:

http://www.student.oulu.fi/~vtatila/sight.html

There are also some pretty good resources on the Web such as:

http://www.lighthouse.org/color_contrast.htm

Basically you should make sure that colors aren't dazzling and that you'v=
e=20
got good contrasts between elements. I don't find the Audacity selection=20
color very easy to see compared to the Forge, for instance. Can the color=
s=20
be changed in the GUi? Maybe you could take the selection background syst=
em=20
color which is dark in most, but probably not in all, of the WIndows colo=
r=20
schemes.

In my Windows color scheme I've made sure that I can read both dialog and=
=20
window text but also that the contrast between dialog and window backgrou=
nds=20
is good enough to easily tell text fields and lists apart inside a dialog=
.=20
This is a fact crudely overlooked in all of the Windows, MAc and Linux=20
high-contrast looks I've seen so far but a very important point for me=20
personally. IN my color scheme, for instance, both windows and dialogs ha=
ve=20
black text but their background colors are RGB: 255, 255, 204 for windows=
 to=20
avoid dazzling and RGB: 0, 213, 213 for dialogs as pure cyan would be too=
=20
bright. Here's how audacity would look, also notice the magnifier and the=
=20
bold fonts:

http://tols17.oulu.fi/~vtatila/downloads/win_magnify.png

The straw analogy does apply to magnification, too, and it can manifest=20
itself in various ways. In Photoshop, for instance, only the top and left=
=20
sides of the image have the rulers for measuring the selection. however w=
hen=20
I'm selecting stuff with the mouse, that's what the magnification is=20
tracking. SO if selection ends up in the middle of the image, I canot eas=
ily=20
check my current ruler position without destroying the selection. Also so=
me=20
text is vertically written and is extremely hard to read magnified. aNoth=
er=20
manifestation of the straw analogy is in dragging up to manipulate knobs =
in=20
a soft synth. IF the mouse pointer may move freely you cannot see the kno=
b=20
you are manipulating and because the pointer has moved away from the knob=
,=20
you'll have to manually relocate the knob after the manipulation, which i=
s=20
no fun business.  See my VST plug-in accessibility tips if you haven't=20
already. The URL is:

http://www.student.oulu.fi/~vtatila/vst_access.html

L: sliders and buttons on each track are not controls that
can receive keyboard focus since they are windowless.
V: I see, I think. This is kind of odd, though, as most basic Win32 apps=20
have pretty much everything in a window and controls are regarded simply =
as=20
child windows. IF a control is windowless does that automagically mean th=
at=20
you cannot route the keyboard focus to it?

L: the track label by keeping track of where the "focus" is and directing=
=20
keyboard input to that specific control.
V: Must this kind of work be done manually, wouldnt it be better if the O=
S=20
took care of focus tracking? I think that in raw Win32 code you get=20
transparent focus handling in dialogs but not in windows. But some higher=
=20
level APis like the NET framework provide focus handling for both. I gues=
s=20
neither fgets used, as this is a cross platform effort, so this might be=20
totally irrelevant. Having the user code keybord focus handling for the=20
umpteenth time seems like poor design as far as the GUI library goes,=20
though.

L: break up each track into separate smaller classes/windows. <snip>
resource consumption.  For instance, an audio track would require 10
different windows.
V: Why is the number of windows such a performance drain, I thought poor=20
performance mostly comes down to bad algorithms or lazy re-drawing. Umm=20
couldn't you keep all controls inside a single window and merely add spac=
ing=20
between the tracks? Just a naive thought, bearly knowing Win32 and Swing =
as=20
well as having no knowledge of any X based UI thingy. Umm is it a must to=
=20
have dedicated controls for each track? I mean couldn't you simply share =
a=20
set of controls which would operate whatever trakc is currently being=20
selected. I guess the main drawback here, though it wouldn't affect scree=
n=20
reader users, is that you cannot easily get the big picture by merely=20
glancing at the screen. Still I reckon a GUI with 48 sets of track specif=
ic=20
controls is awfully busy looking and sort of confusing anyway.

How come resource problems are so prominant in Audacity but I've never ha=
d=20
issues in any of the commercial sound editors. Do they optimize things=20
better or is it just that they don't report the problems even in release=20
notes? I reckon cross-platform coding might take its toll, too.

L: pretty drastic code restructuring and I think the leaders have said th=
at
changes of this magnitude should be rolled into major releases like v2.0.=
=20
<snip>
having something in place in the interim is what I'm concentrating on.
V: Ok sounds good to me so far. I know implementing major changes is goin=
g=20
to be difficult and often many accessibility nightmares can be easy fixes=
,=20
such as adding controls in the tab order or sub-classing existing control=
s=20
rather than rolling your own.

L: realize it's throw away work,
V: Well not necessarily. Maybe bits and pieces could be re-used if not in=
 an=20
oopy manner then by cutting and pasting. Also you are doing accessibility=
=20
prototyping here and receive a lot of valuable data which helps in making=
 V2=20
totally accessible over time, I hope.

L: I've read your "Ideas for a Free Screen Reader" page several times
in the past.  Has there been any progress on this?
V: Not really, nothing much came of it. Even the ideas are not that widel=
y=20
agreed upon, I'd say, so take them with a grain of sault. It's just my vi=
ew=20
of things and it seems I'm in the minority as far as the screen reading=20
philosophy goes. I'm still part of the OSSRP project, though, which is=20
aiming at creating a free or low-cost reader using the UI automation and=20
accessibility technology supplied in Windows Vista. Seems the guys leadin=
g=20
that project know what they are doing.

--=20
With kind regards Veli-Pekka T=E4til=E4 (vt...@ma...)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/=20