Re: on-screen keyboards and Web page structure

Al Gilman wrote:
> * background:
> I believe I have seen a demonstration of on-screen-keyboard
> behavior where choices were organized into a menu tree of
> at least two levels.  The submenus were displayed as rows
> in a grid and the upper level choices represented by the rows.
> The process of "tool animates focus, user selects one when
> it is focused" was repeated first selecting rows and then
> individual choices in a row.
> This kind of hierarchical descent selection is re-affirmed
> as helpful in Colvin and Lysley,
> "Designing and using efficient interfaces for switch accessibility"
> <>
> .. but they are talking about designers consciously designing for switch
> usability, not AT groping their way through the level of structure
> that you find in the wild on the Web.  My question has to do
> with actual practice applied to general Web pages.
> * question:
> My question is: is there any current practice where an on-screen
> keyboard or other switch-user Assistive Technology uses the
> nesting hierarchy of a Web page (elements inside other elements)
> to construct such a hierarchical menu?
Although it seems an interesting idea, I'm not aware of an existing 
practice. Perhaps there is precedent for switch based document 
navigation in other formats?
> In which the user gets
> to choose among the interactive items in the page by page-region
> group first, and eventually winds up with a group of individual
> actions that they can activate or not as the scanning passes by?
With GOK (the GNOME On-screen Keyboard), we let the 
platform-accessibility-exposed "UI" tell us the hierarchy. For example, 
using GOK (in Linux) with FF3, one can navigate this browser's UI 
hierarchy using on-screen keys/keyboards. A good example of hierarchical 
UI mapping to hierarchical keyboards is GOK's treatment of menus (see - sorry there isn't a good text 
alternative to these images but basically a GOK menu keyboard is 
generated with keys labeled "file", "edit", and so on. Selection of 
"file", will display a keyboard made up of the "file" menu items, "new", 
"open", and so on).

Similarly, each browser tab can be displayed as a key on a GOK 
dynamically generated keyboard, but as for content within a web page, 
GOK treats it as it would any other UI, displaying as GOK keys, those 
items exposed ultimately through the platform accessibility API 
(atk/at-spi). We haven't yet done anything fancy with content hierarchy 


Received on Monday, 7 April 2008 16:37:10 UTC