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 the assumption that control elements inside of editable area should have normal behaviour as if they weren't inside the editable area. In other words, they should be operable with mouse and keyboard as usual. 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 to be suitable for certain amount of web applications, for example, if a web application wants to provide the ability to edit control element content in WYSIWYG mode like to edit the button's label. This ability complicates requirements to the editor behaviour and therefore it is dropped from the initial consideration. This proposal is intended to provide sort of default behaviour and doesn't pretend to define unique one for all possible cases. Web application might want to change the behaviour somehow to meet their specific needs.

The most widespread use case of control elements inside of editable area is applications used to create design of web pages, i.e. used to build forms and web pages with form elements. The chosen start point shouldn't contradict with ideas of these applications. It allows to make these application to work in WYSIWYG mode, i.e. the user can always see how his page works without the usage of page preview modes. The main requirement of these application is an ability to drag'n'drop control elements within editable area, selection and clipboard operation with control elements. The proposed behaviour should allow this operation to be performed easy and additionally should make control elements operable.

The start point is major requirement because

1. it allows to create WYSIWYG application to build forms
2. it allows to use unformalized forms where the user can get advantages of work with controls and can edit the form on its demand the same time
3. it allows AT users to work with controls as usually

The main goal of the proposal is to ensure control elements inside of editable area are accessible for any user and user experience to work with editable area won't be broken.

In this proposal, control elements are considered to be either HTML controls or ARIA controls. However the proposal is not restricted to HTML only, proposed ideas should work for other markup languages. Also it should be possible to spread out the rules applied to control elements on non editable areas inside of editable areas.

Suggestion

Сontrol element is a word

Control element should be treated as a word consisting of one character. If user navigates through editable area by characters and control element is encountered 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 after another

text<button>btn1</button><button>btn2</button>

then right 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.

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 appears.

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 move through its text. If caret reaches the end of the text then editor takes the focus and caret position is set immediately after the 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 below the listbox control.

tab navigation

If control is focused then pressing tab should navigate to the next control in tab order. Next control in tab order 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 pressing tab should move the focus to the 2nd button and then to the 3rd 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. Control can be selected or added into selection by mouse or keyboard. If element is added into selection (for example, it is clicked when shift or ctrl key is pressed or shift + arrow keys are pressed) then element shouldn't be focused but selected.

Selected control element can be dragged from one place to another as individual element. If element is focused then drag'n'drop operation is performed as usual. 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 usual (if control wasn't 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 the 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 performs editor's actions accordingly.

when is the given element a control?

Editor should have an ability to recognize if the given element is a 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.