Accessibility/EditorBehaviourOnUserInput
Summary
The article is aimed to propose editor behaviour on user input when control elements are contained in editable area. The start point of this proposal is control elements inside of editable area should have normal behaviour as they wouldn't be inside of editable area. So that they should be operable with mouse and keyboard as usually. The point doesn't contradict with HTML 5 specification. However the specification doesn't address editable area behaviour in question. That was a reason to start the proposal.
The start point can be found not suitable for certain amount of web applications and they might want to change it somehow to meet their specific needs, for example, if web application wants to provide an ability to edit the button's label in wysiwyg mode. This proposal is indented to provide sort of default behaviour and don't pretend to define unique one for all possible cases.
The main goal is to ensure control elements inside of editable area are accessible for any user. Therefore it's necessary to ensure control elements are accessible and operable by keyboard.
In this proposal under control elements are considered either HTML controls or ARIA controls. However the proposal is not restricted to HTML only, proposed ideas should work for other markup languages.
Suggestion
- mouse interaction with control element
Control element behaviour is the same on mouse input. For example, if user clicks on combobox (HTML:select) then drop down list is appeared.
- keyboard interaction with control element
Control element behaviour is the same on keyboard input when control is focused and action can be performed. Otherwise editor rules are applied. For example, if textbox (HTML:input) is focused then arrow keys moves through its text. If caret reaches the end of the text then editor takes the focus and caret position is set immediately after textbox element. If listbox (HTML:select) is focused then up/down arrow keys change selected item, if the last listbox option is selected and arrow down key is pressed then editor takes the focus and caret is moved to the text or control element placed under the listbox control.
- tab navigation
If control is focused then tab press should navigate to the next in tab order control. Next in tab order control can be placed either inside or outside of editable area.
- control element is treated as word
Control element should be treated as a word. If user navigates through editable area by characters and control element is met on the way then control should be focused. If user continues movement by characters and if no control action can be prepared for the used key then editor should be focused and caret position is set immediately after control element. If user navigates by words and control element is met on the way then control should be skipped and editor should get the focus and caret position should be set immediately after control element.
For example, if several buttons (HTML button) are placed after each other
text<button>btn1</button><button>btn2</button>
then left arrow key should be result of "text" traversing by characters, focus the first button, focus editor and setting of caret position between buttons, focus the second button.