MozillaWiki

Accessibility/EditorBehaviourOnUserInput: Difference between revisions

< Accessibility
 
(46 intermediate revisions by 3 users not shown)
Line 3: Line 3:
==What this is all about==
==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 [[Accessibility/RichContentKeyboardBehaviour|keyboard navigation proposal]] and refines statements specific for the page editing.
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 [[Accessibility/RichContentKeyboardBehaviour|keyboard navigation proposal]] and refines statements specific for 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 [[Accessibility/RichContentKeyboardBehaviour#Terminology|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 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 [[Accessibility/RichContentKeyboardBehaviour#Terminology|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 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 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.
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 [http://www.w3.org/TR/html5/ 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 [http://dev.w3.org/html5/spec/Overview.html#user-editing-actions user editing actions] section). As well this was confirmed by Ian Hickson on [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021680.html Whatwg list] and by Richard Schwerdtfeger on [http://lists.w3.org/Archives/Public/wai-xtech/2009Jul/0179.html WAI ARIA list].
''Comment: I think we could ignore unformalized forms for v1.0 -- davidb''


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.
''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
[http://blog.adriaandejonge.eu/2005/05/xforms-tutorial-part-1.html article "XForms tutorial part 1"]. ''
 
''Semi-structured data are widely used in clinical data. [http://iospress.metapress.com/content/dyp63xxvf93wje8u/fulltext.pdf 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 [http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1380194/ HL7 CDA R2 format].''
 
''Also interactive approach (semi-structured forms) can be used as input forms for [http://en.wikipedia.org/wiki/Semi-structured_interview semi-structured interview]. In forms like [http://www.scielo.org.co/img/revistas/prf/n10/n10a04a2.gif 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 [http://www.sleepclinician.com/resources/ widely used].''
 
''In WinIE there is [http://msdn.microsoft.com/en-us/library/ms537833%28v=VS.85%29.aspx scriptable editing API] which support controls into contentEditable areas (e.g. oncontrolselect event). WebKit's team has [http://webkit.org/projects/editing/index.html plans] to support this API. Right now WinIE and Chrome (Safari and Opera I have not tested yet) are supported interactive approach. ''
 
''-- gaidukov''
 
The [http://www.w3.org/TR/html5/ 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 [http://www.w3.org/TR/html5/editing.html#user-editing-actions user editing actions] section). This seems to be confirmed by Ian Hickson on [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021680.html Whatwg list] and by Richard Schwerdtfeger on [http://lists.w3.org/Archives/Public/wai-xtech/2009Jul/0179.html 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==
==Interactive approach==
Line 30: Line 43:
# to create WYSIWYG applications to build forms
# to create WYSIWYG applications to build forms
# to use unformalized forms
# to use unformalized forms
# AT users to work with controls as usually
# AT users to work with controls as usual
 
==Stub approach==


=Suggestion=


Note: for discussions about navigation, unless specified assume caret navigation mode is off.
[gaidukov: If html editor is used stub approach for forms then interactive approach can be used as quick form preview. ]


==Special content element as a lexical unit==
==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.


===Special content element is a word===
''Comment: I think the rich elements should be focusable but not interoperable; but I'm not sure -- davidb''
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 <i>compound word</i> (for example, HTML anchor), any other element as a <i>word</i> (for example, HTML button). The term <i>special word</i> will be used to emphasize the word is represented by a special content element.
=Details=
 
==Navigation block==
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 <i>empty word</i>. Otherwise the word contains all characters of the element's content.
Editable area is always [[Accessibility/RichContentKeyboardBehaviour#Navigation_blocks|navigation block]].
 
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 <i>empty characters</i>, 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
 
<pre>
text<button>btn</button><a>link</a>text
</pre>
 
conditional notation can be presented as "text<span style="color:blue;">||</span><span style="color:red;">|</span>link<span style="color:red;">|</span>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 <i>the caret is immediately before/after the element</i>.
 
If the caret position is between empty characters of the sibling special content elements then it will be referred as <i>the caret is between the elements</i>.
 
If the caret position is between empty characters of the integral element then it will be referred as <i>the caret is on the element</i>.
 
If the selection contains both empty characters of the special content element then it will be referred as <i>the element is selected entirely</i>.
 
==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.


==Keyboard navigation==
==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.


===Navigation by words===
In the case of stub approach if caret is inside an editable area then the editor is focused.
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.
 
===Navigation by characters===
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
==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.


<pre>
;stub approach:
text<button>btn1</button><button>btn2</button>
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.
</pre>


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.
==Keyboard interaction==


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


For example, if the HTML anchor and HTML button are placed after another
;stub approach:
The rich element isn't focusable or interactive.


<pre>
==Mouse selection==
<a href="">link</a><button>btn</button>
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.
</pre>


then caret should be moved through the "link" text, should be set after anchor element and then button should be focused.
;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.
===Tab navigation===
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
 
<pre>
<div contentEditable="true">
  Text<button>btn1</button>text<div role="button" tabindex="0">btn2</button>text
</div>
<button>btn3</button>
</pre>
 
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.
 
===Home/end navigation===
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==
==Removing the selection from DOM==
The selection is removed from DOM by 'Del' or 'Backspace' keys (or their platform's analogies) as usual.
The selection is removed from DOM by 'Del' or 'Backspace' keys (or their platform's equivalent) 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 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 the part of compound element's content but the element itself then the selected element's content will be removed, the element is saved.
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==
==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.
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 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.
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.
Drag'n'drop operation can be performed by mouse or by keyboard. However keyboard shortcuts are under discussion still.


==Clipboard operations==
==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 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 special content element is focused then clipboard operation works as usual.
If the rich element is focused (in the case of interactive approach) 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.
If the rich element is pasted from clipboard into editable area then it is pasted as an element.


=Implementation notes=
=Implementation notes=


===When no action can be performed on control===
===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.
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 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.
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===
===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
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


<pre>
<pre>
Line 225: Line 122:
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.
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 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.
The editor should be extensible to plug elements of markup languages not supported natively.


===Expose the special word boundaries to AT===
===Switching between editing modes===
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.
The DOM document should provide an ability to switch the editing mode.
[http://www.example.com link title]
 
<pre>
document.editingMode [= value]
 
Return "interactive" if the document editing mode is interactive.
Otherwise it returns "stub". The default value is "interactive".
</pre>
 
[davidb: or maybe "livecontrols" and "deadcontrols"?]

Latest revision as of 14:59, 11 June 2010

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"?]

Retrieved from "https://wiki.mozilla.org/index.php?title=Accessibility/EditorBehaviourOnUserInput&oldid=230057"