- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 28 Jul 2009 16:08:18 -0500
- To: Alexander Surkov <surkov.alexander@gmail.com>
- Cc: wai-xtech@w3.org, wai-xtech-request@w3.org
- Message-ID: <OF77C450BA.BCEE96B0-ON86257601.00726F1C-86257601.00741DB9@us.ibm.com>
Alex, The testing we did with Firefox 3.5 is the form controls are editable and operable. My take on this is that all the accessibility API mapping and event notification should be the same. Form elements should operate the same way they do inside or outside the contenteditable area with one possible exception. I believe that if you are editing a contenteditable area and using the arrow keys and run across this situation text <input type="text"> Then the right arrow key should when on the last t in text should move you into the text input field and arrowing to the right within it should arrow you out of the text field to the next dom node within the contenteditable area. A select might operate slightly differently when you drop the listbox down (probably want to cycle around the listbox while it is dropped. After all, you are editing a document. Up and down arrow keys should navigate you in and out of the form element based on its visual location. Rich Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist Alexander Surkov <surkov.alexander @gmail.com> To Sent by: wai-xtech@w3.org wai-xtech-request cc @w3.org Subject Treatment of "Edit form controls 07/21/2009 03:55 nested inside editing hosts" HTML 5 AM section Hi. My question concerns to behaviour of HTML form elements inside of editable area (see HTML 5 section "contenteditable attribute -> User editing actions" (http://dev.w3.org/html5/spec/Overview.html#user-editing-actions). Do HTML form elements inside of editable area have similar behaviour on user input as HTML form elements placed in not editiable document? For example, if user clicks on button then will onclick event handler be invoked or, for example, is user able to choose an option from HTML:select? The spec says: "When an editable form control is edited, the changes must be reflected in both its current value and its default value; for select elements it means updating the option elements' defaultSelected DOM attribute as well as the selected DOM attribute". I can see the unique treatment of this statement which is user should be able to operate with form elements inside of editable area like he does it usually, i.e. all keyboard shortcuts and mouse work as usual. As well partially that means tab key on form element should be used to navigate to next form element. Summary of this would be next: if the focus is on form element then keyboard and mouse behaves the same way like the form element would not be inside of editable area, if focus is on HTML element (like html:p) then keyboard and mouse behaves as inside of editable area. Technically it looks reasonable with me but reality is neither IE or Fx follow this rule. Does this treatment look correct? And how does it look from a11y point of view? Thank you. Alex.
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic03998.gif
- image/gif attachment: ecblank.gif
Received on Tuesday, 28 July 2009 21:09:09 UTC