Sure. Here are examples representative of the three cases we want to handle in LSR.
1) The user tabs to the Close button in the gedit settings dialog. In this case, we might say the name of the button, the role of the button, and the mnemonic for the button. 2) The user reviews to a grayed out menu item in gedit. In this case, we might say the name of the menu item, the role of the menu item, and the word "disabled" to indicate that the menu item is not currently active. We want to say "disabled" here to inform the user that this menu item could potentially become enabled for regular interaction by changing the state of the program (e.g. inserting some new text in a document enables the Save menu item). 3) The user reviews to the toolbar in the gedit main window. In this case, we might say the text on the toolbar and its role. However, we do not want to say "disabled" because this the toolbar is never technically enabled for interaction. That is, we do not want the user thinking it could be enabled for interaction by changing the state of the program (e.g. nothing I do in the program will ever enable/disable the toolbar such that I can interact with it). The way gail distinguishes these three cases is the following: 1) STATE_FOCUSABLE and (STATE_ENABLED or STATE_SENSITIVE) 2) STATE_FOCUSABLE and not (STATE_ENABLED or STATE_SENSITIVE) 3) not STATE_FOCUSABLE The original question I was asking was what other techniques can we use to distinguish case #2 and case #3 since Firefox wants to remove STATE_FOCUSABLE in case #2. Pete On 3/2/07, Willie Walker <[EMAIL PROTECTED]> wrote: > Hi Peter: > > > So how does Orca distinguish the case of some interactive widget being > > disabled from some widget that can never be enabled? Does Orca say > > disabled in both cases? > > Can you enumerate some actual use cases? Concrete examples might make > this discussion easier. > > Thanks! > > Will > > >> Of course, if there were one common accessibility infrastructure for all > >> platforms and we were all working against that infrastructure, the story > >> would be different. IMO, that's the next generation we should be > >> striving for rather than repeatedly reinventing the same API model for > >> specific platforms. Based upon my experiences and discussions with > >> folks over the past few years, not many people are ready for that yet > >> > _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
