Accessibility Experts - user agent keyboard navigation (resending)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Accessibility Experts - user agent keyboard navigation (resending)

Richard Schwerdtfeger

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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

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

Richard Schwerdtfeger

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

[hidden email] wrote on 05/26/2010 09:02:48 AM:

> Richard Schwerdtfeger/Austin/IBM@IBMUS
> Sent by: [hidden email]
>
> 05/26/2010 09:02 AM
>
> To
>
> [hidden email], [hidden email], Matthew King/
> Fishkill/IBM@IBMUS, Frank DiPalermo/Austin/Contr/IBM@IBMUS,
> IAccessible2 mailing list <[hidden email]-
> foundation.org>, [hidden email],
> [hidden email], Brian Cragun/Rochester/IBM@IBMUS, David
> Todd/Greensboro/IBM@IBMUS, Damian Chojna <[hidden email]>,
> [hidden email], [hidden email],
> [hidden email], Frank Olivier <[hidden email]>,
> [hidden email], [hidden email]
>
> cc
>
> [hidden email]
>
> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

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

Alexander Surkov
In reply to this post by Richard Schwerdtfeger
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 <[hidden email]> 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:        [hidden email]
> Cc:        IAccessible2 mailing list
> <[hidden email]>,
> [hidden email], Brian Cragun/Rochester/IBM@IBMUS,
> [hidden email], Damian Chojna <[hidden email]>, David
> Todd/Greensboro/IBM@IBMUS, [hidden email],
> [hidden email], [hidden email], Frank
> DiPalermo/Austin/Contr/IBM@IBMUS, Frank Olivier <[hidden email]>,
> [hidden email], [hidden email], Matthew
> King/Fishkill/IBM@IBMUS, [hidden email],
> [hidden email], [hidden email], [hidden email]
> 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
>
> [hidden email] wrote on 05/26/2010 09:02:48 AM:
>
>> Richard Schwerdtfeger/Austin/IBM@IBMUS
>> Sent by: [hidden email]
>>
>> 05/26/2010 09:02 AM
>>
>> To
>>
>> [hidden email], [hidden email], Matthew King/
>> Fishkill/IBM@IBMUS, Frank DiPalermo/Austin/Contr/IBM@IBMUS,
>> IAccessible2 mailing list <[hidden email]-
>> foundation.org>, [hidden email],
>> [hidden email], Brian Cragun/Rochester/IBM@IBMUS, David
>> Todd/Greensboro/IBM@IBMUS, Damian Chojna <[hidden email]>,
>> [hidden email], [hidden email],
>> [hidden email], Frank Olivier <[hidden email]>,
>> [hidden email], [hidden email]
>>
>> cc
>>
>> [hidden email]
>>
>> 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
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility