Re: Accessibility Experts - user agent keyboard navigation (resending)

Hi Alex,

This is just a first pass:

Starting with this link:
https://wiki.mozilla.org/Accessibility/RichContentKeyboardBehaviour

In ARIA widgets you say that ARIA is all about screen readers. That is not
true. Most AT solutions: Voice recognition technology, alternate input
devices, magnifiers, etc. have hysteresis for determining how to present a
web page, or any application, to the user. Knowing what type of content is
there is important. Imagine an assistive technology for the mobility
impaired wanting to know navigational landmarks or knowing how to apply an
alternative input device toward operating an ARIA widget. ... You have to
know something about what it is.


Navigation blocks:

In navigation order provide examples of navigation blocks. Is it a div with
a tabindex property applied somewhere in it? ... it is not clear. It
appears you are using some HTML 5 standard terms as well. It would be good
to link to those.

Rich element as a lexical unit:

- I recommend you link back to the definition earlier in the page.
- When you say auto generated characters are you referring to the
accessibility API or the actual DOM itself?

In-text element

Regarding this paragraph, the first sentence I understand but the the rest
I do not.:
"If the in-text element is next on the way (i.e. the first word of its
sentence is next word) then the caret should be set before the element. If
the caret is before the element then it should be moved before the begin of
the second word of the sentence. If the the sentence consist of one word
then the caret should be moved before the word following the sentence. "

Did you mean to say:

"When processing in-text elements:

- if the next element is the first word of a sentence the caret should be
placed directly before the element
- if the caret is placed directly before the first word of the sentence,
then a move to the next word would place the caret directly in front of the
second word of the sentence.
- If the caret is placed directly before the first word of the sentence,
and the sentence contains only one word, then a move to the next word would
result in placing the caret directly in front of the word following the
sentence. "

A general comment about word navigation is that the concept of a word needs
to be defined per language. For example, simplified Chinese or Mandarin
does not have the concept of a "word." These languages have no spaces.
Assistive technology vendors, like screen readers, have defined their
concept of what a word is per language. It has been quite some time since I
worked on screen reader/2 or the Java Self Voicing Kit so I do not recall
what rules we used. I would recommend you ask one of the ATVs, such as
Jamie Teh, for that answer.

When you refer to character navigation you refer to using the arrow keys
and you make an exception for


There are some general editorial issues but perhaps those can get addressed
on the Wiki vs. here.

Regarding Home and End. When you state that the allow you to navigate to
the beginning and end of the current line. What constitutes a line? This
needs to be defined.

Regarding cutting and pasting to the clipboard does that include inline
script?

Thank you for pulling this together. I am glad someone has taken the time
to address this.

Rich Schwerdtfeger
CTO Accessibility Software Group

wai-xtech-request@w3.org wrote on 05/26/2010 09:02:48 AM:

> Richard Schwerdtfeger/Austin/IBM@IBMUS
> Sent by: wai-xtech-request@w3.org
>
> 05/26/2010 09:02 AM
>
> To
>
> wai-xtech@w3.org, dev-accessibility@lists.mozilla.org, Matthew King/
> Fishkill/IBM@IBMUS, Frank DiPalermo/Austin/Contr/IBM@IBMUS,
> IAccessible2 mailing list <accessibility-ia2@lists.linux-
> foundation.org>, cyns@exchange.microsoft.com,
> faulkner.steve@gmail.com, Brian Cragun/Rochester/IBM@IBMUS, David
> Todd/Greensboro/IBM@IBMUS, Damian Chojna <damian.chojna@ie.ibm.com>,
> blewis@freedomscientific.com, RobG@freedomscientific.com,
> jcraig@apple.com, Frank Olivier <franko@microsoft.com>,
> david.bolter@gmail.com, marco.zehe@googlemail.com
>
> cc
>
> surkov.alexander@gmail.com
>
> Subject
>
> Accessibility Experts - user agent keyboard navigation (resending)
>
> An important feature of web browser today is the ability to navigate rich
> content editable areas. This feature is standardized in HTML 5. IBM,
> Mozilla, and other members of the open community have been working hard
on
> addressing keyboard navigation. Alex Surkov, Mozilla, is creating a
> document for browser manufacturers to follow when a keyboard is being
used.
> He would like feedback from the community on that document which should
> become a best practices guide for browser manufacturers. It would be
> problematic if the keyboard navigation behavior was only employed in
> Firefox.
>
> IBM is working on the accessibility of rich content editable areas, to
> support some of our products, with Mozilla and members of the AT
community
> so we have an immediate need to address this issue. However, I am sure
that
> others will be interested.
>
> Alex's proposal consists of two parts. The one part concerns to behavior
in
> caret navigation mode
> (https://wiki.mozilla.org/Accessibility/RichContentKeyboardBehaviour).
>
> The second part is about editor behavior
> (https://wiki.mozilla.org/Accessibility/EditorBehaviourOnUserInput),
> the editor behavior doc is built upon the doc for caret navigation
> mode.
>
> Highlights:
>
> - put all elements (including form controls) into keyboard navigation
> sequence.
> - define ARIA role's affect on keyboard navigation. It allows ARIA
widgets
> to behave similar to native widgets so that ARIA widget authors shouldn't
> care about caret navigation inside ARIA widgets bydefault (of course ARIA
> widget author always is able to override behavior).
> - wrap elements (like form controls, links) by special characters (called
> empty characters in the proposal) so that the user is able to put the
caret
> before element, before first character of the element's content.
>
> The editor doc suggests to have two modes defining the behavior of UI
> controls inside an editable area. The first mode is to make controls
> working as usual, the second mode is to make them a stub controls (so
that
> the user can't interact with them).
>
> Alex is fine with posting comments on the mozilla wiki pages above or via
> email. If we could all provide Alex Surkov feedback it would be much
> appreciated. I am going through the documents now.
>
> Alex, thank you for pulling this together!
>
> Rich
>
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group