Re: single keystroke commands

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

Received on Sunday, 23 July 2000 20:13:12 UTC