Accessibility/EditorBehaviourOnUserInput

Summary

The article is aimed to propose editor behaviour on user input when editable area contains non only text container elements (like HTML p) and structural elements (like HTML table). In other words the following element types are considered: control elements (like HTML form elements), ARIA widgets (where proper role attribute is used), focusable elements (like HTML div with tabindex attribute or HTML a) or non editable elements (like HTML span with contentEditable="false" attribute).

All these elements will be referred everywhere below as special elements.

The problem is there is no specification which would define the behaviour when special elements are presented inside of editable area and reality is different browsers implement the behaviour differently and it sounds no one makes this perfect because the editable text content mixed with special elements is not fully accessible by keyboard and mouse.

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 more rarer case is when editable area with control elements is used as unformalized form where control elements are used to help to fill up the form however the user has an ability to remove the whole text including control elements and write his own version.

The start point

The start point of this proposal is an assumption that special 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 mostly as usual. So that the editor behaviour should be much similar to the behaviour in caret navigation mode with the difference the text and special elements participate in editing.

This start point doesn't contradict with HTML 5 specification and it is confirmed implicitly in user editing actions section. As well it was confirmed by Ian Hickson on Whatwg list and by Richard Schwerdtfeger on WAI ARIA list.

Unfortunately HTML 5 specification doesn't address editable area behaviour in question. That was a reason to start the proposal.

The chosen start point shouldn't contradict with ideas of form building applications. Moreover it allows to make these application to work in WYSIWYG mode, i.e. when the user is able 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, select them and operate with them by clipboard. The proposed behaviour should allow to perform these operations easy and additionally should make special elements operable.

However 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. However the defined behaviour shouldn't make impossible to use the editor by these application and it is advisable the behaviour should be able to be overridden easy enough to meet their specific needs.

Shortly the start point allows

1. to create WYSIWYG applications to build forms
2. to use unformalized forms
3. AT users to work with controls as usually

Suggestion

Special element is a word

In general the special element should be treated as a word when the user navigates through editable area. So that non editable element is treated as a word consisted of one character. The HTML anchor is treated as a word consisted of number of characters equaled to the length of the anchor text. For example, if the anchor text consist of several words then anchor element is treated as a compound word. The control element is treated as a special word so that the word boundaries is the control itself with no whitespaces wrapping the control.

Keyboard interaction with control element

In general control element behaviour is the same on keyboard input when control is focused. If no control action can be performed while the control is focused then 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. The exception might be made for combobox element when its popup is open which should be closed by user before he can continue the navigation and editor can take the focus.

The detailed behaviour is considered in the next "Keyboard navigation" section.

Keyboard navigation

Navigation by words if editor is focused

If editor is focused, i.e. the caret position is somewhere in middle of the editable text, if the user navigates by words (ctrl + arrow key or alt + arrow depending on platform) and control element is encountered on the way then the control element should be skipped, i.e. the caret should be moved from the position before the control to the position after control, editor should stay focused.

Navigation by words if control is focused

If the control element is focused and the user navigates by words then

1. caret position should be moved after the control element if no action can be performed on the control element on the pressed key
2. otherwise the control's action should be invoked.

It's a rare case when control element has an action on the "navigate by words" keyboard combination. The example of such control is textbox containing several words. In this case the user should navigate to the last word of textbox and then leave the control, i.e. editor should take the focus and caret should be set immediately after the control.

Navigation by characters

If the user navigates through editable area by characters and control element is encountered on the way then control should be focused. If the control element can't be focused (for example, when it's disabled) then control element is skipped from navigation sequence, i.e. editor should stay focused and caret should be moved to position after the control element.

If the control element is focused and the user navigates by characters then

1. editor should be focused and caret position should be set immediately after control element if no control action can be performed for the pressed key
2. otherwise control action should be performed.

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.

Tab navigation

If the control element is focused then pressing tab should navigate to the next control in tab order. Next control in tab order can be encountered 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.

If the editor is focused then pressing tab should insert '\t' character or its used analogue or focus the next tabable element what depends on editor preferences or platform.

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.

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.