Confirmed users
1,396
edits
Accessibility/EditorBehaviourOnUserInput: Difference between revisions
Jump to navigation
Jump to search
Accessibility/EditorBehaviourOnUserInput (view source)
Revision as of 16:45, 17 February 2010
, 17 February 2010→Summary
mNo edit summary |
|||
| 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 of the | 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 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 | 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 | The proposal should make real these two different behavior models. | ||
== | ==Interactive approach== | ||
The start point of this proposal is an assumption that special content inside an editable area should have the same behaviour as it would if it wasn't inside an editable area. An editable area should thus behave similarly to regular caret navigation mode plus editing behaviour. | The start point of this proposal is an assumption that special content inside an editable area should have the same behaviour as it would if it wasn't inside an editable area. An editable area should thus behave similarly to regular caret navigation mode plus editing behaviour. | ||