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: [email protected]
Cc: IAccessible2 mailing list
<[email protected]>,
[email protected], Brian Cragun/Rochester/i...@ibmus,
[email protected], Damian Chojna <[email protected]>,
David Todd/Greensboro/i...@ibmus, [email protected],
[email protected], [email protected], Frank
DiPalermo/Austin/Contr/i...@ibmus, Frank Olivier <[email protected]>,
[email protected], [email protected], Matthew
King/Fishkill/i...@ibmus, [email protected],
[email protected], [email protected], [email protected]
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
[email protected] wrote on 05/26/2010 09:02:48 AM:
> Richard Schwerdtfeger/Austin/i...@ibmus
> Sent by: [email protected]
>
> 05/26/2010 09:02 AM
>
> To
>
> [email protected], [email protected], Matthew King/
> Fishkill/i...@ibmus, Frank DiPalermo/Austin/Contr/i...@ibmus,
> IAccessible2 mailing list <[email protected]
> foundation.org>, [email protected],
> [email protected], Brian Cragun/Rochester/i...@ibmus, David
> Todd/Greensboro/i...@ibmus, Damian Chojna <[email protected]>,
> [email protected], [email protected],
> [email protected], Frank Olivier <[email protected]>,
> [email protected], [email protected]
>
> cc
>
> [email protected]
>
> 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
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
