Accessibility/EditorBehaviourOnUserInput
Summary
What this is all about
This article proposes a model for how a user edits and navigates within an editable area that might contain any kind of web page content like rich text, form controls and etc. It is based on keyboard navigation proposal and refines statements specific for the page editing.
The problem we want to address here is: there is no specification which would define the interaction when form controls and other special elements of web page (referred as rich elements) are presented inside an editable area. Browser implementations vary and none are perfect; editable text mixed with rich elements is not fully accessible by keyboard and mouse.
The most widespread use case is applications used to design and create web pages, i.e. used to build forms and web pages with form elements. Some of these applications want to deal with stubs instead of real form elements, so that the form elements aren't interactive and are used to designate the location of specific form element within the page. Other applications might want to be WYSIWYG applications and welcomes the form elements interaction so that the user always see how his page mock-up works.
The other and 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 HTML 5 specification doesn't specifically address the issue of editable area behaviour. However it's founded on the assumption that rich elements inside an editable area should have the same behaviour as they would if they weren't inside an editable area (see user editing actions section). As well this was confirmed by Ian Hickson on Whatwg list and by Richard Schwerdtfeger on WAI ARIA list.
However it drops the case of form builder applications when they want to have stubs instead real control elements which is found unsuitable for their needs. This is a reason to propose two behavior models allowing the user to switch between them.
Interactive approach
The start point of this approach is an assumption that rich elements inside an editable area should have the same behaviour as they would if they weren't inside an editable area. An editable area should thus behave similarly to regular caret navigation mode plus editing behaviour.
The start point allows to make form builder applications to work in WYSIWYG mode, in other words the user is able see how his page works without the usage of page preview modes. The main requirement of these applications is an ability to drag'n'drop control elements within editable area, select them and operate with them by clipboard. Therefore the proposed behaviour should allow to perform these operations easy and additionally to make these elements operable and accessible.
However the start point can be found not suitable for certain amount of web applications, for example, if a web application wants to provide an 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 for implementation the behaviour should be able to be overridden easy enough to meet their specific needs.
Note: while this describes a simple default behaviour, there is no reason rich elements can not be overridden with specialized navigation and editing behaviour on a case by case basis.
Shortly the start point allows
- to create WYSIWYG applications to build forms
- to use unformalized forms
- AT users to work with controls as usually
Stub approach
Suggestion
Note: for discussions about navigation, unless specified assume caret navigation mode is off.
Special content element as a lexical unit
Special content element is a word
The special content element should be treated as a word when the user navigates through editable area.
The compound element will be referred as a compound word (for example, HTML anchor), any other element as a word (for example, HTML button). The term special word will be used to emphasize the word is represented by a special content element.
The number of characters of the special word depends on whether this is compound word or not. If the word is not compound then it hasn't any characters and it will be referred as an empty word. Otherwise the word contains all characters of the element's content.
In that way non editable area is treated as an empty word if caret navigation mode is turned off. Otherwise it is treated as a compound word consisted of a number of words equaled to a number of words non editable element consists of. The control element is treated as an empty word. The focusable compound element consists of a number of words equaled to a number of words of the element's content and it doesn't depend on caret navigation mode state.
Boundaries of the special word
The special word boundaries are designated by special autogenerated empty characters, used as a word delimiters. If the special content elements are placed each after other then each of them has empty character embedded between them, i.e. the elements don't share empty characters.
The empty characters are not presented visually, however they participate in keyboard navigation as normal characters.
In the following example
text<button>btn</button><a>link</a>text
conditional notation can be presented as "text|||link|text", where the empty character is marked by '|' symbol. Both the empty word for the button and the compound word for the link are wrapped by empty characters ('|' symbols of blue and red colors correspondingly).
The caret position and selection terms
If the caret position is immediately before/after left/right empty character of the special content element then it will be referred as the caret is immediately before/after the element.
If the caret position is between empty characters of the sibling special content elements then it will be referred as the caret is between the elements.
If the caret position is between empty characters of the integral element then it will be referred as the caret is on the element.
If the selection contains both empty characters of the special content element then it will be referred as the element is selected entirely.
Keyboard interaction with special content
In general special content behaviour on keyboard input is the same as usual. However there are subtleties that will be discussed in next sections.
No additional rules for non editable areas. The behaviour is defined by caret navigation mode.
Focusable compound elements have behaviour matched caret navigation mode.
Control elements has normal behaviour if focused and control action can be performed on pressed key. 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. 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.
If the editor is focused, i.e. the caret position is somewhere in the middle of the editable text, if the user navigates by words (ctrl + arrow key or alt + arrow depending on platform) and special content element is encountered on the way then the special content element should be skipped, i.e. the caret should be moved from the position before the element to the position after the element, the editor should stay focused.
If the control element is focused and the user navigates by words then
- caret position should be moved after the control element if no action can be performed on the control element on the pressed key
- otherwise the control's action should be invoked.
It's a rare case when control element has an action on the "move to the next/previous word" keyboard combination. The example of such control is textbox (like HTML input element) containing several words. In this case the user should navigate consecutively 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.
If the compound element is focused, the caret is somewhere in the middle of element's content and the user navigates by words then the caret should be moved by constituent words of the element until it reaches the end of the element's content. Then editor should take the focus and the caret should be set after the element. The behaviour is similar to described above behaviour of textbox.
If the user navigates through editable area by characters and special content element is encountered on the way then
- if the element is focusable then it should be focused
and
- if the element is compound then caret position should be set before the first character of the element's content
- otherwise the caret should be set on the element.
For example, if the control element is disabled or if the caret navigation mode is off and the element is non editable area then the caret should be set on the element, the editor should stay focused. Visually it might look like dashed border around the element.
If the control element is focused and the user navigates by characters then
- editor should be focused and caret position should be set after the control element if no control action can be performed on the pressed key
- 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, then focus the 2nd button, then focus the editor and set caret position after the second button.
If the compound element is focused and the user navigates by characters then caret should be moved consecutively to the end of the element's content, then should be set after the element and the editor should take the focus.
For example, if the HTML anchor and HTML button are placed after another
<a href="">link</a><button>btn</button>
then caret should be moved through the "link" text, should be set after anchor element and then button should be focused.
If the special content element is focused then pressing tab should navigate to the next focusable element in tab order. Next focusable element in tab order can be encountered either inside or outside of editable area. This requirement is applied to control elements and compound element both.
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 move the focus outside of editable area to the next tabable element what depends on editor preferences or platform.
The user should be able to navigate to the begin/end of
- the current line (for example, Home/End keys)
- the editable area (for example, Home/End keys with pressed 'alt' modifier key).
Mouse interaction with special content
The special content element behaviour is the same on mouse input if the mouse isn't used to change the selection.
For example, if user clicks on combobox (HTML:select) then drop down list appears.
Managing the selection
When integral element participates in selection then it should be selected entirely always. If the integral element has own selection behaviour (like a HTML input) while the it's focused and the user starts the selection inside of it then there is no way to extend the selection out of boundaries of the element.
When compound element participates in selection then the editor should provide two opposite options to the user. It should be possible to select the element entirely so that its content wouldn't be selected. On the another hand it should be possible to select the content of the compound element so that the element itself wouldn't be selected.
Visually the selected entirely element might have blue border around it.
Keyboard selection
When user holds selection modifier key (for example, shift key) and moves through editable area then the editor stays focused.
At the same time if the integral element encountered on the way then the element is appended to the selection entirely.
If the compound element is encountered on the way while
- the user moves by words then the element is appended to the selection entirely
- the user moves by characters then the element's content is appended consecutively to the selection until the user reaches the end of the element.
- If the caret leaves the element then the element is appended to the selection entirely.
- If the user releases the selection modifier key then the compound element is focused while the caret stays inside of the element's content.
If the selection is started inside of compound element while is is focused then editor will take the focus once the caret leaves the compound element content.
Mouse selection
If the mouse is moved to extend the selection while the editor is focused then it stays focused.
At the same time if the special content element is encountered on the way then
- the element is appended to the selection entirely if the element is an integral,
- otherwise the element's content is appended to the selection until the mouse reaches the end of the element, then the element is appended to the selection entirely.
When mouse click is occurred on the special content element while 'add-to-selection' modifier key is pressed (like ctrl key) then the element is appended to the selection entirely, the element is not focused and no element's action is invoked.
The mouse can be used to add the part of the compound element's content to the selection, i.e. to move the caret into element's content and focus the element. There are few possible options. The end version of the proposal might define the one way only.
- Click and move approach when users presses the left mouse key on the element with pressed 'add-to-selection' modifier key and moves the mouse to extend the selection.
- Deep click approach when the user presses the left mouse key on the element with pressed 'add-to-selection' key and do not release the mouse key during some time.
- Double click or second click approach when the user presses the 'add-to-selection' modifier and clicks on the element twice.
If the selection is started inside of compound element while is is focused then editor will take the focus once the caret leaves the compound element content.
Removing the selection from DOM
The selection is removed from DOM by 'Del' or 'Backspace' keys (or their platform's analogies) as usual.
If the special content element is selected then it's removed entirely with its boundary characters. If the integral element is focused and 'Del' or 'Backspace' key is pressed and if there is no element's default action then the element is removed. Both 'Del' and 'Backspace' keys have the same meaning in this case.
If the selected region contains the part of compound element's content but the element itself then the selected element's content will be removed, the element is saved.
Drag'n'drop
The selected entirely special content element is dragged from one place to another as an individual element. If the selected element is a part of the selected region then the region is dragged entirely with all selected elements.
If the special content 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. As well in the case of focused compound element its selected content participates in drag'n'drop operation, not the element itself.
Drag'n'drop operation can be performed by mouse or by keyboard. However keyboard shortcuts are under discussion still.
Clipboard operations
If the special content element is selected entirely then it can be copied into clipboard. Both its text representation and the element itself should be copied into clipboard as different mime types.
If the special content element is focused then clipboard operation works as usual.
If the special content element is pasted from clipboard into editable area then it is pasted as an element.
Implementation notes
When no action can be performed on control
When the special content element is focused and no action can be performed on the pressed key then editor rules should be applied.
The editor implementation should have the ability to check whether action can be performed or not to accomplish this requirement. The possible approach is the element should prevent default action of an event (DOMEvent.preventDefault) if it performs an action on this event. If there is no action then the editor processes this event and performs editor's actions accordingly.
When the element is compound
The editor implementation should have the ability to recognize whether the element is special content element or not and whether the element is compound or not. This is needed to allow (or not allow) caret navigation into element's content. 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 a control element and it's not focusable.
The editor implementation should have a map to accomplish this requirement, so that tag name should be used as a map key for native markup elements, role attribute value should be used for ARIA widgets, CSS display style should be used for any content it is applicable to.
The editor should be extensible to plug elements of markup languages not supported natively.
Expose the special word boundaries to AT
The empty characters used to designate the begin and the end of the special word should be exposed to AT as a certain character like it happens for nested text container accessibles. Probably two different characters should be reserved for the start and the end boundary characters. link title