Accessibility/WebAccessibilityAPI: Difference between revisions

 
(7 intermediate revisions by the same user not shown)
Line 474: Line 474:
                           });
                           });
</pre>
</pre>
====Questions/concerns====
* Interactions should be extended to allow to specify a control that triggers the action. The concept is described by InidieUI: you can use mouse, touchscreen, keyboard, voice control or a control element to invoke the action. Maybe Interactions should be renamed to Triggers to share terms with IndieUI.
Here's the image of InideUI action/interaction concept.
<div style="height: 254px; overflow: hidden;">
http://www.w3.org/WAI/intro/iui-scroll.png
</div>
Alternatively we could introduce relations between actions like "triggers" and "triggeredby".
* What about highlevel actions (uberactions), for example, "press" buttons means "send something somewhere". This may be covered by label. Another example, selected listitem on the left changes a view on the right, "select" actions has meaning of "change view". Or checkbox that enables/disables related controls, "check/uncheck" action means "enable/disable controls". These examples correlates to controlledby/controllerfor relations, but the relations doesn't reveal type of control.


===Parent-child relations===
===Parent-child relations===
Line 1,049: Line 1,064:


<code>
<code>
AccessibleDocument .''text''
AccessibleDocument .''text(AccessiblePos)''
::Returns the text enclosed between this and given accessible positions.
::Returns the text enclosed between this and given accessible positions.


AccessibleDocument .''text''
AccessibleDocument .''text(CriteriaLiteral)''
::Returns the text at the position complying the given criteria. See [[#Criteria|criteria]] for options.
::Returns the text at the position complying the given criteria. See [[#Criteria|criteria]] for options.
</code>
</code>
Line 1,103: Line 1,118:
p.textAttributes.get("font-weight") == 700; // true
p.textAttributes.get("font-weight") == 700; // true
</pre>
</pre>


==Caret and selection==
==Caret and selection==
Line 1,945: Line 1,959:
===Implied semantics===
===Implied semantics===


The author has to be less verbose as possible. If a role usually implies number of sets or attributes then they are supposed to set so the authur doesn't need to list them. For example if <code>listitem</code> is selectable then you don't have to point <code>selectable</code> state on it, in other words, these code snippets are equivalent:
The idea is to help the author to keep the code less verbose as possible. If role implies a number of preset attributes or states then they are present on the accessible element by default, i.e. if the author didn't list them. For example, if <code>listitem</code> role is selectable and focusable by default then the author doesn't have to point <code>selectable</code> and <code>focusable</code> states when he describes a listitem source, in other words, these code snippets are equivalent:


<pre>
<pre>
var source = {
var source1 = {
   role: "listitem"
   role: "listitem"
};
};
</pre>


<pre>
var source2 = {
var source = {
   role: "listitem",
   role: "listitem",
   states: [ "selectable" ]
   states: [ "selectable", "focusable" ]
};
};
</pre>
</pre>


The implied semantics is described by [[#SemanticsProviders|semantics provides]].
Implied semantics is described by [[#SemanticsProviders|taxonomies]].
 


===Conflicts===
===Conflicts===


[to be done conflicts between native semantics, ARIA and this API]
[to be done conflicts between native semantics, ARIA and this API, I tend to think that the author should be able to replace/remove native semantics if needed. This can ruin the web page but it gives the absolute control over the page content. A dangerous but quite powerful tool like atomic energy. ]
 


===Sniffing===
===Sniffing===


In order to make optimization the content provider has to know whether accessibility consumer is active. The provider can add a callback for <code>deploy</code> and <code>conceal</code> event types which will be triggered when consumer appears/gets inactive.  
In order to make an optimization, the content provider has to know whether an accessibility consumer (like screen reader) is active. The provider can add a callback for <code>deploy</code> and <code>conceal</code> event types which will be triggered when consumer appears/gets inactive.  


<pre>
<pre>
Confirmed users
1,396

edits