Re: Treatment of "Edit form controls nested inside editing hosts" HTML 5 section


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 Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

             Alexander Surkov                                              
   >                                                To 
             Sent by:                            
             wai-xtech-request                                          cc 
                                       Treatment of "Edit form controls    
             07/21/2009 03:55          nested inside editing hosts" HTML 5 
             AM                          section                           


My question concerns to behaviour of HTML form elements inside of
editable area (see HTML 5 section "contenteditable attribute -> 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.

Received on Tuesday, 28 July 2009 21:09:09 UTC