- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Thu, 27 May 2010 17:16:22 -0400
- To: WAI-AUWG List <w3c-wai-au@w3.org>
Hi all, Sorry for the double-post if you are on xtech etc. Of special interest to AUWG is the "editor behavior" part: https://wiki.mozilla.org/Accessibility/EditorBehaviourOnUserInput Cheers, Jan -------- Original Message -------- Subject: Accessibility Experts - user agent keyboard navigation (resending) Resent-Date: Wed, 26 May 2010 14:03:26 +0000 Resent-From: wai-xtech@w3.org Date: Wed, 26 May 2010 09:02:48 -0500 From: Richard Schwerdtfeger <schwer@us.ibm.com> To: wai-xtech@w3.org, dev-accessibility@lists.mozilla.org, Matthew King <mattking@us.ibm.com>, Frank DiPalermo <dipalerm@us.ibm.com>, IAccessible2 mailing list <accessibility-ia2@lists.linux-foundation.org>, cyns@exchange.microsoft.com, faulkner.steve@gmail.com, Brian Cragun <cragun@us.ibm.com>, David Todd <dltodd@us.ibm.com>, 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 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 -- (Mr) Jan Richards, M.Sc. jan.richards@utoronto.ca | 416-946-7060 Adaptive Technology Resource Centre (ATRC) Faculty of Information | University of Toronto
Received on Thursday, 27 May 2010 21:16:49 UTC