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
Refined statements
- navigation block
Editable area is always navigation block.
- keyboard navigation
If caret is inside an editable area then the editor is focused until the rich element is focused.
- tab navigation
If the editor is focused then pressing tab should insert '\t' character or its used analogue or move the focus to the next tabable element (outside or inside an editable area) what depends on editor preferences or platform.
- mouse interaction
The rich element behavior is the same on mouse input if the mouse isn't used to change the selection, i.e. if the user click on rich element and moves the mouse to extend the selection then element is not clicked, i.e. it doesn't get the focus but selected. The special case is in-text elements what aren't focused and click event handlers aren't invoked when the user clicks on.
- mouse selection
When mouse click is occurred on the rich 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. Note, this is applicable for in-text elements as well.
Stub approach
All rich elements aren't focusable and included into navigation sequence. When the caret is between empty characters of the rich word or sentence then the rich element is called selected. Visually it might look a blue border around the element.
Refined statements
- navigation block
Editable area is always navigation block.
- keyboard navigation
If caret is inside an editable area then the editor is focused.
- tab navigation
If the editor is focused then pressing tab should insert '\t' character or its used analogue or move the focus outside an editable area to the next tabable element what depends on editor preferences or platform.
- keyboard and mouse interaction
The rich element isn't focusable or interactive. If the user clicks on the element then it's selected, i.e. the caret is put between empty characters.
- mouse selection
When mouse click is occurred on the rich 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. Note, this is applicable for in-text elements as well.
Suggestion
Note: for discussions about navigation, unless specified assume caret navigation mode is off.
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