Confirmed users
1,085
edits
Accessibility/EditorBehaviourOnUserInput: Difference between revisions
Accessibility/EditorBehaviourOnUserInput (view source)
Revision as of 01:40, 19 March 2010
, 19 March 2010→What this is all about
m (→Details) |
DavidBolter (talk | contribs) |
||
| 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 | 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 | 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 | 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 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). | 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 | 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== | ||