Accessibility/EditorBehaviourOnUserInput: Difference between revisions

Accessibility/EditorBehaviourOnUserInput (view source)

Revision as of 08:46, 10 March 2010

226 bytes removed , 10 March 2010

m

→‎Interactive approach

Surkov.alexander

Confirmed users

1,396

edits

@@ Line 17: / Line 17: @@
 ==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 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.
-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.
+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 HTML 5 specification doesn't specifically address the issue of editable area behaviour. That was a reason to start this proposal.
-The chosen start point shouldn't contradict with ideas of form building applications. Moreover it allows to make these application to work in WYSIWYG mode, in other words the user will be 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 special content 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