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.
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.
For example, if editable area contains two buttons (HTML and ARIA buttons) and there is one button outside of editable area
<div contentEditable="true"> Text<button>btn1</button>text<div role="button" tabindex="0">btn2</button>text </div> <button>btn3</button>
and the 1st button is focused then tab press should move the focus to the 2nd button and then to the 3d button.
control element is treated as a word
Control element should be treated as a word consisted of one character. If user navigates through editable area by characters and control element is met on the way then control should be focused. If control element can't be focused (for example, when it's disabled) then control element is skipped from navigation sequence. If control element is focused, user navigates by characters and if no control action can be performed for the pressed key then editor should be focused and caret position should be 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 two buttons (HTML button) are placed each after other
text<button>btn1</button><button>btn2</button>
then left arrow key presses should traverse "text" by characters, then focus the 1st button, focus the editor and set caret position between buttons and then focus the 2nd button.
selection, drug'n'drop and clipboard
Control element should be selected entirely, its content doesn't participate in selection. Visually it might look like blue border around the control element.
Selected control element can be dragged from one place to another one as indivisible element. If element is focused then drag'n'drop operation is performed as usually. For example, if textbox is focused and user starts to drag selected text of textbox then the text should be dragged only.
If control is selected then it can be copied into clipboard. Both its text representation and control itself should be copied into clipboard as different mime types. If control element is focused then clipboard operation works as usually (if control wouldn't be inside of editable area).
Implementation notes
editor rules are applied when no action can be performed on control
When control element is focused and no action can be performed on the pressed key then editor rules should be applied. Therefore editor should have an ability to check whether action can be performed or not to accomplish this requirement. The possible approach is control element should prevent default action of an event (nsIDOMEvent.preventDefault) if it performs an action on this event. If there is no control's action then editor processes this event and accordingly performs editor's actions.
when is the given element a control?
Editor should have an ability to recognize if the given element is control or not because it needs to skip it if it's not focusable and not allow to move caret into the content of control element. For example, if ARIA button is placed inside of editable area
text<div role="button">button</div>text
then editor should skip button from navigation sequence if user moves the caret by characters because the ARIA button is not focusable.
Editor should have a map to know if the given element is control, so that tag name should be used as a map key for HTML, role attribute value should be used for ARIA widgets, CSS display style should be used for any content it is applicable to.