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

Hi, Rich. Thank you for your response. My testing was based on trunk
Firefox. Some controls like input@type="button" are operable actually,
however for example I can't drop popup of HTML select by mouse click.
Also there are couple of problems with focus when I use arrow keys to
navigate in editable area.

Please correct me if I got you wrong. We should keep the rule "if
keyboard shortcuts haven't specific meaning for HTML form element then
they should have meaning of editable area. For example, if HTML select
is focused then up/down arrow keys should change selected option,
however if HTML button if focused then up/down keys should move caret
to previous/next line. Do I understand right?

Alex.


On Wed, Jul 29, 2009 at 5:08 AM, Richard Schwerdtfeger<schwer@us.ibm.com> wrote:
> 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 ---07/21/2009 03:58:22 AM---Hi.
>
> Alexander Surkov <surkov.alexander@gmail.com>
> Sent by: wai-xtech-request@w3.org
>
> 07/21/2009 03:55 AM
>
> To
> wai-xtech@w3.org
> cc
>
> Subject
> Treatment of "Edit form controls nested inside editing hosts" HTML 5 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.
>
>
>

Received on Thursday, 30 July 2009 02:38:43 UTC