- From: Alexander Surkov <surkov.alexander@gmail.com>
- Date: Thu, 8 Oct 2009 11:25:12 +0800
Hi. My suggestion concerns to keyboard behaviour inside of editable area (@contenteditable="true") within control elements. The suggestion is based on Rich Schwerdtfeger comment from http://lists.w3.org/Archives/Public/wai-xtech/2009Jul/0184.html: > 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. The suggestion is to treat control element as special character, i.e. when you move through the text by arrow keys and control element is met then control element should be focused and its selection should be changed appropriately. When control has the focus then keyboard behaviour is defined by control preferences with once exception. If particular navigation key isn't processed by control or doesn't have any defined action then editor rules are applied. Let's consider Rich's example: begin<input type="text" value="text">end If the caret selection is immediately after "begin" and right arrow key is pressed then html:input is focused and its caret position is set to the begin of text (after 't' of the 'text'). Once html:input is focused then keyboard navigation rules for html:input are applied. When the end of the text of html:input is reached then keyboard navigation rules of editor are applied so that html:input looses the focus and caret is moved to the 'n' character of the 'end' word. The same rules are applied for up and down array keys inside of html:input. If we deal with html:select at size>1 then html:select is focused and arrow keys are used to move though select options. As well if the first or the last option is achieved by up/down arrow keys then html:select is unfocused and caret is set above/below the select control. The same idea is applied to the tab key. If control element is focused then tab should focus the next control element. If the caret is on text then tab key should do the action defined for the editor (for example insert \t symbol). The idea to focus control element on navigation keys makes control elements accessible by keyboard. If editable area contains couple of control elements following each other like "start<input/><select><option>1</option><button>finish" then the combination of controls should be treated as word. Therefore if you press ctrl+right arrow key (assuming the caret is after "start" word) then focus should be moved to the next text entry (i.e. on "finish" text). I appreciate to hear your opinions and feedback. Thank you a lot. Alex.
Received on Wednesday, 7 October 2009 20:25:12 UTC