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, etc. It is based on the keyboard navigation proposal and refines statements specific for page editing.

The problem we want to address here is: there is no specification which defines the user interaction when form controls and other special elements of web page (referred as rich elements) are presented inside an editable area. Currently 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 merely used to designate the location of specific form element within the page. Other applications might want to be WYSIWYG applications and provide interactive form elements 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.

Comment: I think we could ignore unformalized forms for v1.0 -- davidb

Comment (gaidukov): I propose to change term 'unformalized form' to "semi-structured form". There is generally accepted term "semi-structured data". Interactive approach will allow to create input forms which can generate semi-structured data. Some information about problem of input forms for semi-structured data can be found in article "XForms tutorial part 1".

Semi-structured data are widely used in clinical data. The article is described the problem of exchange and representation of clinical semi-structured data. Interactive approach allows to create input forms for convenient input of clinical documents which can be in HL7 CDA R2 format.

Also interactive approach (semi-structured forms) can be used as input forms for semi-structured interview. In forms like this paper form controls (e.g. html:select or xf:select) with most common phrases can be placed into text fields. When user select a phrase from a control then the selected phrase can be coded. Coded phrases can be used for machine processing. In medicine semi-structured interviews are widely used.

In WinIE there is scriptable editing API which support controls into contentEditable areas (e.g. oncontrolselect event). WebKit's team has plans to support this API. Right now WinIE and Chrome (Safari and Opera I have not tested yet) are supported interactive approach.

-- gaidukov

The HTML 5 specification doesn't specifically address the issue of editable area behavior. However it's founded on the assumption that rich elements inside an editable area should have the same behavior as they would if they weren't inside an editable area (see user editing actions section). This seems to be confirmed by Ian Hickson on Whatwg list and by Richard Schwerdtfeger on WAI ARIA list.

However it ignores 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

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

[gaidukov: If html editor is used stub approach for forms then interactive approach can be used as quick form preview. ]

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.

Comment: I think the rich elements should be focusable but not interoperable; but I'm not sure -- davidb

Details

Navigation block

Editable area is always navigation block.

Keyboard navigation

In the case of interactive approach if caret is inside an editable area then the editor is focused until the rich element is focused.

In the case of stub approach if caret is inside an editable area then the editor is focused.

Tab navigation

interactive approach

If the editor is focused then pressing tab should insert '\t' character or its analogue or move the focus to the next element in the tab order (outside or inside an editable area) according to editor preferences or platform.

stub approach

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 depending on editor preferences or platform.

Keyboard interaction

interactive approach

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.

stub approach

The rich element isn't focusable or interactive.

Mouse selection

When a mouse click is occurs on the rich element while the 'add-to-selection' modifier key is pressed (e.g. 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

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.

Removing the selection from DOM

The selection is removed from DOM by 'Del' or 'Backspace' keys (or their platform's equivalent) as usual.

If the rich element is selected then it's removed entirely along 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 part of a compound element's content but not the element itself then the selected element's content will be removed, the element is saved.

Drag'n'drop

An 'entirely' selected rich element is dragged from one place to another as an individual element. If one or more selected elements are part of a selected region then the region is dragged entirely along with (including) all selected elements.

If a special content element is focused (in the case of interactive approach) then drag'n'drop operation is performed as usual. For example, if a textbox is focused and the user starts to drag some selected text from within the 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 a rich 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 rich element is focused (in the case of interactive approach) then clipboard operation works as usual.

If the rich 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

This section is applicable to interactive approach only.

When the rich element is focused and no action can be performed via keyboard then editor rules should be applied.

The editor implementation should have the ability to check whether an action (interactivity) can be performed or not in order to accomplish this requirement. One 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 rich 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, whereby the tag name can be used as a map 'key' for native markup elements, the role attribute value should be used for ARIA widgets, CSS display style should be used for any content it is applicable to.

Comment: I think asking the editor to pay that kind of attention to the role attribute makes things more complicated and possibly fragile. Note DHTML widget authors are currently responsible for keyboard handling via JS. Specialize caret implementation based on role is pretty complicated. -- davidb

The editor should be extensible to plug elements of markup languages not supported natively.

Switching between editing modes

The DOM document should provide an ability to switch the editing mode.

document.editingMode [= value]

Return "interactive" if the document editing mode is interactive.
Otherwise it returns "stub". The default value is "interactive".

[davidb: or maybe "livecontrols" and "deadcontrols"?]