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

Hi, Brian. Thank you for thoughtful reading, for comments and for editing.

> [cragun: to clarify, if there are two rich elements next to each other then
> there will be (empty)(rich)(empty)(empty)(rich)(empty). Did I understand
> correctly?]

Yes.

> [Cragun: can we use something different that | blue and | red, which are not
> accessible?

Yes, absolutely. I'll fix it.

> [cragun: do you mean it should should be unpronouncable so the AT cannot
> read it? or do you mean it should be pronounceable so it can be read without
> special support?]

I think they should be unpronouncable so the AT won't read them aloud,
however they must be visible for AT so that AT deal with correct text
offsets and AT is able notify the user about caret position change,
for example, let we have abc<button>btn</button>abc then screen reader
could read something like 'a', 'b', 'c', 'before button', button, 'a',
'b', 'c'.

I'll try to run through the spec again, address your and Rich comments
on these days off.

Thank you.
Alex.


On Fri, May 28, 2010 at 7:13 AM, Brian Cragun <cragun@us.ibm.com> wrote:
> Hi Alex,
>
> I've taken a pass through
> https://wiki.mozilla.org/Accessibility/RichContentKeyboardBehaviour   I did
> not see anything I disagreed with.
>
> I corrected several small spelling / grammar right in the wiki.   You can
> see these edits using the Wiki changes function.   There are a couple of
> questions, as well, which I added to the wiki, similar to davidb.   You can
> search on "cragun".
>
> (1)
> To make this happen special autogenerated empty characters are inserted
> before and after the rich element. If the rich elements are placed one after
> another then each of them has empty character embedded between them, i.e.
> the elements don't share empty characters.
>
> [cragun: to clarify, if there are two rich elements next to each other then
> there will be (empty)(rich)(empty)(empty)(rich)(empty). Did I understand
> correctly?]
>
> (2)
> conditional notation can be presented as "text|||value|text", where the
> empty character is marked by '|' symbol. Both the empty word for the button
> and the complex word for the input are wrapped by empty characters ('|'
> symbols of blue and red colors correspondingly).
>
> [Cragun: can we use something different that | blue and | red, which are not
> accessible? Could we state: "conditional notation can be presented as
> "text||!value!text", where the empty character is marked by the '|' and '!'
> symbols. Both the empty word for the button and the complex word for the
> input are wrapped by empty characters (blue '|' for the first case and red
> '!' in second case. ) ]
>
> (3)
> The rich element accessible as a part of text container accessible is an
> embed character. All characters of the reach word or sentence including its
> empty characters are contained in embed character. The empty character
> should be exposed to AT as a certain character. This character should be not
> pronounceable character so that AT might not need any additional special
> support.
>
> [cragun: do you mean it should should be unpronouncable so the AT cannot
> read it? or do you mean it should be pronounceable so it can be read without
> special support?]
>
> Regards.
>
> Brian Cragun
> IBM AbilityLab Consultant
> Human Ability & Accessibility Center
> www.ibm.com/able & w3.ibm.com/able
> W:(720)-663-2801    H:(507)288-2437
>
>
>
>
> From:        Richard Schwerdtfeger/Austin/IBM
> To:        surkov.alexander@gmail.com
> Cc:        IAccessible2 mailing list
> <accessibility-ia2@lists.linux-foundation.org>,
> blewis@freedomscientific.com, Brian Cragun/Rochester/IBM@IBMUS,
> cyns@exchange.microsoft.com, Damian Chojna <damian.chojna@ie.ibm.com>, David
> Todd/Greensboro/IBM@IBMUS, david.bolter@gmail.com,
> dev-accessibility@lists.mozilla.org, faulkner.steve@gmail.com, Frank
> DiPalermo/Austin/Contr/IBM@IBMUS, Frank Olivier <franko@microsoft.com>,
> jcraig@apple.com, marco.zehe@googlemail.com, Matthew
> King/Fishkill/IBM@IBMUS, RobG@freedomscientific.com,
> surkov.alexander@gmail.com, wai-xtech@w3.org, wai-xtech-request@w3.org
> Date:        05/26/2010 05:32 PM
> Subject:        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
>

Received on Friday, 28 May 2010 12:31:09 UTC