Re: single keystroke commands

Harvey a more update set of functions was posted to the list on 11 July:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0037.html

Could you recheck you concerns with this posting.  It was agreed on the 13 
July to use this list as the minimum set of functions.

Jon



At 08:12 PM 7/23/2000 -0400, Harvey Bingham wrote:
>At 2000-06-28 07:46-0500, Kitch Barnicle wrote:
>>The following is a proposed set of configurable single stroke functions. ...
>>I propose the following minimum set of commands be accessible with a 
>>single keystroke or that the user be able to configure those as single 
>>stroke commands those items on this list.
>>
>>1. next link
>>2. previous link
>
>Link is not in the UAAG glossary. By these I presume you mean the subset of
>active elements that in some browsers is navigated through without activation
>by tab or shift-tab
>
>>3. next structural element(s) - (Should each structural element, eg. 
>>table, form, list, get its own keystroke.)
>
>Note that other structural elements can occur (nested, or recursively) within
>table, form, list. So going forward or back from the next specific kind of
>structural element depends on its containing structural element.
>
>In anticipation of XML applications, the list of such element types is
>open-ended. That suggests that a user style sheet be able to select which
>among the element types should get keystroke mapping. I expect that DOM
>navigation provides adequate capability here that we should leave to it
>the tools that allow DOM wanderings through hierarchy and siblings.
>
>>4. back
>>5. forward
>>6. refresh
>>7. page up
>>8. page down
>>9. line up (arrows)
>>10 line down (arrows)
>
>In a table, keypair-augmented up/down arrows might be interpreted as 
>prior/next row, and augmented left/right arrows as prior/next cell.
>
>In a FORM, are some elements more equal than others? Does the type text
>attribute value of the INPUT element type have special needs?  one of
>     "(TEXT | PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET |
>      FILE | HIDDEN | IMAGE | BUTTON)"
>used to specify the kind of widget is needed (and hence possibly different
>means of local navigation. How is non-visual accommodation made?)
>
>>11. next active element
>
>Combine with next/prior link? (or do you mean links as targets, whereas
>active elements contain hrefs?
>
>>12. stop loading
>
>This should work in conjunction with some loading progress indicator?
>
>
>>Other useful commands that may be candidates for single stroke assignment
>>
>>13. to address bar / open location
>
>Do we have a means to edit that address bar? to query its content?
>
>>14. next viewports
>>15. load/unload graphics
>>16. increase font size
>>17. decrease font size
>
>I prefer this, as implemented in NSN, to the limited choices of MSIE.
>I believe it should affect font size of tooltips as well.
>
>>18. page search
>
>Do you mean, search for string in current page, or search for page containing
>some pattern, from some domain of pages?
>
>>19. add to bookmark
>>20. go to bookmark list
>>21. go to history list
>>22. navigate among all Elements
>
>Where do we indicate we expect to be able to have DOM-based navigation? And
>attribute query therein?
>
>>23. turn on/off colors/style/sheets
>>24. help - for conventions sake, I think this should stay at F1
>>
>>Another questions is whether we need a different set of single keystroke 
>>commands for media players?
>>(e.g. stop, start, pause, volume)
>
>I would add means to  select a particular track or step to prior/next track.
>Also I would add means to fast forward and fast reverse (or go to particular
>time within track.)
>
>[I'm currently trying to memorize some music as sung on a CD, and those are
>the most important controls I use. Audio Station 32 makes this quite
>convenient, with track selection or stepping to prior or next. During track
>play a display shows current time position from the start of the current 
>track.
>A linear slider shows position within the track. Its adjustment stops
>play to allow fast-slews to the desired time, shown on the display.
>Bookmarks to such starting positions mid-track would also be useful.]
>
>Regards/Harvey

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Monday, 24 July 2000 11:19:09 UTC