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

Hi, Rich.

Thank you much for looking at this and your valuable comments. I'll
address them soon.

> 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

Did you mean "next word" instead of "next element"? If yes then I like
your wording.

Thank you.
Alex.


On Thu, May 27, 2010 at 7:32 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> 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

Received on Thursday, 27 May 2010 13:15:37 UTC