Confirmed users
1,396
edits
Accessibility/EditorBehaviourOnUserInput: Difference between revisions
Jump to navigation
Jump to search
m
Accessibility/EditorBehaviourOnUserInput (view source)
Revision as of 03:51, 10 March 2010
, 10 March 2010→Summary
m (→Summary) |
m (→Summary) |
||
| Line 5: | Line 5: | ||
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 and etc. It is based on [[Accessibility/RichContentKeyboardBehaviour|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 [[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 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 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 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. | ||
| Line 11: | Line 11: | ||
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. | 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]. | ||
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== | ==Interactive approach== | ||
| Line 20: | Line 20: | ||
Note: while this describes a simple default behaviour, there is no reason ''special content'' can not be overridden with specialized navigation and editing behaviour on a case by case basis. | Note: while this describes a simple default behaviour, there is no reason ''special content'' can not be overridden with specialized navigation and editing behaviour on a case by case basis. | ||
However the HTML 5 specification doesn't specifically address the issue of editable area behaviour. That was a reason to start this proposal. | However the HTML 5 specification doesn't specifically address the issue of editable area behaviour. That was a reason to start this proposal. | ||
| Line 35: | Line 33: | ||
# to use unformalized forms | # to use unformalized forms | ||
# AT users to work with controls as usually | # AT users to work with controls as usually | ||
==Stub approach== | |||
=Suggestion= | =Suggestion= | ||