MozillaWiki

Accessibility/WebAccessibilityAPI: Difference between revisions

Page Discussion

Accessibility/WebAccessibilityAPI (view source)

Revision as of 15:06, 8 May 2015

3,715 bytes added ,  8 May 2015
→‎Questions/concerns
No edit summary
 
(15 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,492: Line 1,506:
control.relations.add("labelledby", label.a11yment);
control.relations.add("labelledby", label.a11yment);
</pre>
</pre>
====Actions====
<pre>
partial interface ActionMap {
  void tweak(DOMString oldname, DOMString newname);
  void add(DOMString name, object);
  void delete(DOMString name);
};
</pre>
<code>
ActionMap ..''tweak''
::Toggles the action name.
</code>




<div id="AccessibleSource">
<div id="AccessibleSource">
===Extend the semantic via accessible source===
===Extend the semantic via accessible source===
</div>
</div>
Line 1,963: 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>
Line 2,230: Line 2,226:
   sequence<DOMString> states;
   sequence<DOMString> states;
   Object attributes;
   Object attributes;
  sequence<DOMString> relations;
  sequence<DOMString> actions;
};
};
</pre>
</pre>
Line 2,252: Line 2,250:
RoleTaxon .''attributes''
RoleTaxon .''attributes''
::List of attributes supported by the role. Default value of the attribute may be specified as modifier. For example, "live:polite" points out that "live" object attribute has "polite" value by default. If default value is not specified then it's taken from referred attribute taxon description.
::List of attributes supported by the role. Default value of the attribute may be specified as modifier. For example, "live:polite" points out that "live" object attribute has "polite" value by default. If default value is not specified then it's taken from referred attribute taxon description.
RoleTaxon .''relations''
::List of relations supported by the role.
RoleTaxon ..''actions''
::List of supported actions. Actions from the list are exposed on the accessible element depending on states present on it. For example, if supported actions are "check" and "uncheck", then "check" is exposed if the accessible element doesn't have "checked" state, otherwise "unchecked".
</code>
</code>




<b>Example. ARIA <code>textbox</code> role</b>
<b>Example. ARIA <code>textbox</code> role.</b>


<pre>
<pre>
Line 2,277: Line 2,281:
</pre>
</pre>


<b>Example. ARIA <code>log</code> role.</b>
 
<b>Example. ARIA <code>checkbox</code> role.</b>
 
<pre>
var taxa = {
  checkbox: {
    description: "checkbox",
    parents: [ "input" ],
    states: [ "checkable:default, "checked" ],
    actions: [ "check", "uncheck" ]
  }
};
</pre>
 
 
<b>Example. ARIA <code>log</code> role.</b>


<pre>
<pre>
Line 2,289: Line 2,308:
};
};
</pre>
</pre>


====States====
====States====
Line 2,297: Line 2,315:
   DOMString description;
   DOMString description;
   sequence<DOMString> dependents;
   sequence<DOMString> dependents;
   DOMString opposite;
   DOMString exclusives;
}
}
</pre>
</pre>
Line 2,309: Line 2,327:
::List of all dependent states. For example, "focused" state always accompanied by "focusable" state.
::List of all dependent states. For example, "focused" state always accompanied by "focusable" state.


StateTaxon ..''opposite''
StateTaxon ..''exclusives''
::An opposite state if any. Opposite state are mutually exclusive. For example, if "vertical" state is applied then "horizontal" is not and vice versa.
::Mutually exclusive states if applicable. For example, if "vertical" state is applied then "horizontal" is not and vice versa.
</code>
</code>


Line 2,322: Line 2,340:
   },
   },
   focused: { },
   focused: { },
   singleline: {
   singleline: {
     opposite: "multiline"
     exlcusives: [ "multiline" ]
   },
   },
   multiline: {
   multiline: {
     opposite: "singleline"
     exlcusives: [ "singleline" ]
   },
   },
   readonly: { },
   readonly: { },
   editable: { },
   editable: { },
   required: { }
   required: { },
 
  checked: {
    exlusives: [ "mixed" ]
  },
  mixed: {
    exlusives: [ "checked" ]
  }
};
};
</pre>
</pre>


====Attributes====
====Attributes====
Line 2,373: Line 2,399:
</pre>
</pre>


=HTML and beyond=


This doc introduces common patterns to express the semantics of markup languages to accessibility. Markup specifics is not a target for this doc in general. Each markup specification has to take care to describe their accessibility stuff in terms of this API.
====Actions====


=Extensibility=
<pre>
dictionary ActionTaxon {
  DOMString description;
  DOMString dual;
  sequence<DOMString> states;
};
</pre>


The web application might need to extend default taxonomies to express the new semantics. For example, the web service publishing music sheets can introduce new characteristics like role, states, etc to describe music sheet content. However the web application should take care to explain new characteristic by extending default taxonomies, i.e. by describing the connection between old and new characteristics. That will resolve any backward compatibility issue, so if the consumer doesn't know about new roles then he can still figure out a closest match it's aware about. For example, if the web app author introduces "x-redbutton' and provides a role taxonomy for it saying this is an extension of 'button' role, then the consumer unfamiliar with 'x-redbutton' role will treat it as a button.
<code>
ActionTaxon .''description''
::Localized action description.


The author should follow name convention to avoid potential collisions with future additions into the spec predefined lists. Thus all names should be prefixed by 'x-' like 'x-redbutton' from example above.
ActionTaxon .''dual''
::Dual action taxon. When action is invoked, it is switched to its dual action if applicable.
 
ActionTaxon .''states''
::Implied states. When action is invoked, states of dual action are cleared, this action states are set.
</code>
 
 
<b>Example.</b>
 
<pre>
var taxa = {
  check: {
    description: "check",
    dual: "uncheck",
    states: [ "checked" ]
  },
  uncheck: {
    description: "uncheck",
    dual: "check"
  }
};
</pre>
 
=HTML and beyond=
 
This doc introduces common patterns to express the semantics of markup languages to accessibility. Markup specifics is not a target for this doc in general. Each markup specification has to take care to describe their accessibility stuff in terms of this API.
 
=Extensibility=
 
The web application might need to extend default taxonomies to express the new semantics. For example, the web service publishing music sheets can introduce new characteristics like role, states, etc to describe music sheet content. However the web application should take care to explain new characteristic by extending default taxonomies, i.e. by describing the connection between old and new characteristics. That will resolve any backward compatibility issue, so if the consumer doesn't know about new roles then he can still figure out a closest match it's aware about. For example, if the web app author introduces "x-redbutton' and provides a role taxonomy for it saying this is an extension of 'button' role, then the consumer unfamiliar with 'x-redbutton' role will treat it as a button.
 
The author should follow name convention to avoid potential collisions with future additions into the spec predefined lists. Thus all names should be prefixed by 'x-' like 'x-redbutton' from example above.


==Music sheet example==
==Music sheet example==
Line 2,413: Line 2,478:
   crescendo: [note, ...] a list a notes the crescendo is applied to
   crescendo: [note, ...] a list a notes the crescendo is applied to
   diminuendo: [note, ...] a list a notes the diminuendo is applied to
   diminuendo: [note, ...] a list a notes the diminuendo is applied to
</pre>
Or in terms of taxonomies:
<pre>
document.import("role", {
  sheet: {
    description: "sheet",
    attributes: [ "instrument", "tempo", "clef" ]
  },
  note: {
    description: "note",
    attributes: [ "key", "alteration", "octave", "duration", "effects" ],
    relations: [ "crescendo", "diminuendo" ]
  }
});
document.import("attributes", {
  instrument: {
    description: "instrument type"
  },
  tempo: {
    description: "tempo"
  },
  clef: {
    description: "clef"
  },
  key: {
    description: "key",
    values: [ "C", "D", "E", "F", "G", "A", "H" ],
  },
  alteration: {
    description: "alteration",
    values: [ "none", "flat", "sharp" ],
    default: "none"
  },
  octave: {
    description: "octave",
    values: [ "contra", "great", "small", "1line", "2line" ],
  },
  duration: {
    description: "duration"
  },
  effects: {
    description: "effects"
  }
});
document.import("relations", {
  crescendo: {
    description: "crescendo"
  },
  diminuendo: {
    description: "diminuendo"
  }
});
</pre>
</pre>
Surkov.alexander
Confirmed users
1,396

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1073316...1073446"