Tuesday style guide meeting

Hi All;

I can't make tomorrow's meeting but I do have some thoughts to share on
James suggestion that 1] the AT should control  keynav and 2] the style
guide is Windows centric, here's a summary of them. An expanding discussion
follows below.
    a. The style guide  needs to account for platform differences or
identify the platforms it applies to.
    b. Component [widget] developers should be responsible for implementing
the key sequences, it's easier to not do the ARIA work if they don't need to
implement the key sequences.
    c. The style guide for the base platform, or platform/browser combo
should drive the key sequence definition for each platform
        1] MacOS users shouldn't have to learn Windows key sequences for
example.
    d. Most solutions restrict the actionable mode to individual cells, to
get out of a cell you must toggle to navigation mode to leave a cell.
    e. Sighted keyboard-only users loose out if it is left to AT to control
the user interaction.
    f. Which way is better when content contains dynamic and static
components [e.g. tables]?

More Info
1. James is correct in pointing out a flaw in the current style guide - it
assumes all platforms define key sequences the same. In reality, each
platform has differences and sometimes, as with Macs, the key sequences are
very much different than the Windows/mostly-Gnome centric model currently
defined by the style guide.
    a. Maybe there should be a similar MacOS track -or- it should be noted
which platforms the style guide targets.

2. The goal of the dhtml styleguide is, to my knowledge, to define key
sequences that follow the base platform's defined key sequences. Divergences
occur only when , for our case, a browser has re-purposed a key sequence to
do something else [e.g. cntrl-tab].
    a.Which way is better if the developer doesn't put any keyboard support
in - is the user screwed regardless of the technique?
    b. I prefer the widget developer versus AT do the work, if it doesn't I
fear none of the necessary ARIA implementation work will be done.

3. I've heard multiple AT vendors say they would rather use the platform's
key navigation, selection, and activation key sequences instead of special
casing their own.
    a. Consensus of opinion or no, implemented on the widget or by the AT,
perhaps this style guide should be identifying the keys that should be used
when interacting with a widget, regardless of whether the AT controls the
keynav experience or it's implemented on the widget.
    b. I speak from a lack of expertise here but aren't the divergences in
how AT and base platforms interact on navigation and selection due to
implementation choices made by the AT vender? Shouldn't the style guide work
be driven by how the platform defines key sequences and interactions versus
how a given AT does it?
    c. AT should be forced to define its own key sequence only when the
platform [includes the browser] doesn't define a key sequence or necessary
function.

4. It still appears that the general and physically impaired sighted
keyboard only user will be screwed if it is left to an AT to determine how
to interact with dynamic widgets and content.

5. I looked at spreadsheets, Orca, and the information on VoiceOver and see
the below. At a high level, the difference between them is, as James pointed
out, who controls the navigation/actionable interaction - the widgtet or the
AT. Maybe the answer is who cares as long as it matches the dhtml style
guide?
    a. All have an actionable and navigation mode in tables - it's a key
toggle
    b. All of them use the arrow key to move around cells.
    c. None of them say anything clear [yet] about selection of table cell
contents when it contains multiple actionable elements or if it's active in
actionable or navigation interaction modes.
        1] VoiceOver and Orca, in the info I had access to, say little about
tables
    d. Orca, VoiceOver, and Excel force action or editing mode to be a cell
by cell basis. In these, you must toggle out of edit mode before input focus
can be moved to another cell.
        1] The current styleguide recommendation is, wrongly, you can
navigate between cells in actionable mode until it is toggled off.
        2] Maybe an easier path from an interaction perspective is to
request a table property in ARIA that identifies when a cell has actionable
content; then, as with headings and header cells, the AT has a landmark to
look for to quickly jump focus to the next actionable cell?
        3] Note that it would probably be AT's responsibility to define the
sequence used for this.

6. On Windows, when does AT typically define the key sequences used for
standard html elements and when does it utilize the key sequences defined by
the browser?
    a. What type of monkey wrench does this throw in the works on pages with
similar dynamic and standard components on the same page?



-- 
Earl
http://www.linkedin.com/in/earljohnson1
earlj.biker@gmail.com