- From: Alexander Surkov <surkov.alexander@gmail.com>
- Date: Thu, 27 May 2010 22:15:03 +0900
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: IAccessible2 mailing list <accessibility-ia2@lists.linux-foundation.org>, blewis@freedomscientific.com, Brian Cragun <cragun@us.ibm.com>, cyns@exchange.microsoft.com, Damian Chojna <damian.chojna@ie.ibm.com>, David Todd <dltodd@us.ibm.com>, david.bolter@gmail.com, dev-accessibility@lists.mozilla.org, faulkner.steve@gmail.com, Frank DiPalermo <dipalerm@us.ibm.com>, Frank Olivier <franko@microsoft.com>, jcraig@apple.com, marco.zehe@googlemail.com, Matthew King <mattking@us.ibm.com>, RobG@freedomscientific.com, wai-xtech@w3.org, wai-xtech-request@w3.org
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