On Sat, Jun 02, 2001 at 11:23:32AM -0700, Peter Korn wrote: > > In the usability mailing list and in the #usability channel on > > irc.gnome.org we've been discussing dialogs in GNOME and GTK+, and > > dialog buttons in particular. However, for the most part we are not > > accessibility experts and we'd like to know if anyone here can give us > > any input from an accessibility perspective. > > Thanks for raising these issues! Don't thank me. Thank Calum. He suggested that you guys might be interested. > > Default buttons: > > The default button is that which is activated when the enter key is > > pressed, regardless of which widget has the focus. The contentious > > issue is whether developers should avoid setting a destructive action > > as the default or whether they should choose the action the user is > > most likely to want to perform regardless of how destructive it may > > be. As we've discussed it so far, it's largely a matter of finding a > > good trade-off between safety and convenience. > > My opinion is that this is a case-by-case decision that the developers/usability > folks closest to the application need to make. If deleting stuff is very > common, I don't want to have to go through lots of layers to get the darn thing > deleted. People with disabilities will feel the same way. Noted. > > Default button movement: > > Currently, when any button on the bottom row of a dialog has the focus > > it will also become the default. When another widget is selected the > > default will revert to the original default. Is this behaviour > > desirable? Should the default ever change? > > I personally think this is sub-optimal and potentially confusing. Changing what > button is the default may work reasonably well when the user has visual > feedback. For a blind user, having stuff change out from underneath them is not > friendly. Though this information could be conveyed, it raises the noise floor > for in the audio stream. Ah. This is interesting. > For example, let's say we have a dialog with the three > buttons on the bottom row of a dialog: "Yes", "No", and "Cancel". Without > default changability, the audio stream from a screen reader might go something > like this: > > "Tab - Button Yes"; "Tab - Default Button No"; "Tab - Button Cancel" > > (and then additional tabs take the user up into the rest of the dialog). But if > the default were changing, it would probably be something like this: > > "Tab - Button Yes - Button Yes now Default"; > "Tab - button No - Button No now Default"; > ... > > You would need to tell the user each time the default changed. And the signal > that signifies to the screen reader that the default button has changed may not > be trivially coalesced into the focus change signal (and it probably comes after > the focus change signal), making the shortening: > > "Tab - Button Yes - now Default"; "Tab - button No - now Default"; ... > > somewhat tricky to do 100% correctly. But since a blind user would have to go > to some length to discover that these three buttons are on the bottom row (as > opposed to other buttons), expecting them to "know" this behavior won't work. hmm. Ignoring the issue of defaults for a moment, would it be possible and/or desirable to let them know that these buttons where on the bottom row? (Or, to put it semantically, that they were buttons that applied to the dialog as a whole.) You see, I've been thinking, for a number of reasons, that it would be useful to have some sort of API or component to say that a set of buttons were specifically dialog buttons. > > Button layout: > > Should button layout follow the Windows style of having the action > > buttons on the left or a more Mac-like style of having action buttons > > on the right? The former is more consistent with other platforms, the > > latter generally thought to be more comfortable. > > Users with disabilities mostly live in Windows, just like everyone else. They > will have a similar familiarity with Windows-based layout as their mainstream > colleagues. And I expect they will have a similar adjustment period to the > change as well. So, I would not use accessibility as an argument to keep > something that is generally felt to be sub-optimal. If blind users are using a screen reader as you describe above, and tabbing through a set of buttons, am I right in thinking that with Windows-style layout they'd get to the action buttons first, but if the action buttons were on the right they'd encounter Cancel first? Would this be a bad thing? colin _____________________________ ____ rtnl http://rational.cjb.net c z robertson ndirect co uk icq 13294163
Attachment:
pgpASsi5eZADi.pgp
Description: PGP signature