Skip to content

Commit

Permalink
Editorial: Modify the introduction to reference the EO suite of
Browse files Browse the repository at this point in the history
documents and remove the reference to UAAG.

Completes ACTION-2035
  • Loading branch information
richschwer authored and joanmarie committed Mar 9, 2016
1 parent 9d6f19d commit 13a5e4a
Showing 1 changed file with 2 additions and 8 deletions.
10 changes: 2 additions & 8 deletions aria/aria.html
Expand Up @@ -153,13 +153,8 @@ <h1>Introduction</h1>
<p>This draft currently handles two aspects of <a>roles</a>: user interface functionality and structural <a>relationships</a>. For more information and use cases, see the [[WAI-ARIA-PRIMER]] for the use of roles in making interactive content accessible.</p>
<p>The role <a>taxonomy</a> is designed in part to support the common roles found in platform <a>accessibility <abbr title="Application Programing Interfaces">APIs</abbr></a>. Reference to roles found in this taxonomy by dynamic web content may be used to support interoperability with assistive technologies.</p>
<p>The schema to support this standard has been designed to be extensible so that custom roles can be created by extending base roles. This allows <a>user agents</a> to support at least the base role, and user agents that support the custom role can provide enhanced access. Note that much of this could be formalized in [[XMLSCHEMA-2]]. However, being able to define similarities between roles, such as <a href="#baseConcept">baseConcepts</a> and more descriptive definitions, would not be available in <abbr title="Extensible Markup Language Schema Datatypes">XSD</abbr>.</p>
<ul>
<li><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Primer [[WAI-ARIA-PRIMER]], a W3C Working Group Note, introduces developers to the accessibility problems that <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is intended to solve, the fundamental concepts, and the technical approach of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>.</li>
<li><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices 1.1 [[ARIA-PRACTICES]], a planned W3C Working Group Note, describes how web content developers can develop accessible rich internet applications using <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. It provides detailed advice and examples directed primarily to web application developers, yet also useful to user agent and developers of assistive technologies.</li>
<li>Core Accessibility API Mappings 1.1 [[CORE-AAM]], a planned W3C specification, describes how browsers and other <a class="termref">user agents</a> expose the semantics of web content languages to <a class="termref">Accessibility APIs</a>.</li>
<li>Accessible Name and Description: Computation and API Mappings 1.1 [[ACCNAME-AAM]], a planned W3C specification, describes how <a class="termref">user agents</a> determine <a class="termref">Accessible Name</a>s and descriptions of <a class="termref">accessible objects</a> from web content languages and expose them in <a class="termref">accessibility APIs</a>.</li>
<li><cite><a href="http://www.w3.org/TR/wai-aria-roadmap/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Roadmap</a></cite> [[WAI-ARIA-ROADMAP]], planned a W3C Working Group Note, defines the path to make rich web content accessible, including steps already taken, remaining future steps, and a time line.</li>
</ul>
<p><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.1 is a member of the <a href="https://www.w3.org/WAI/intro/aria#wai-aria-1_1"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.1 suite</a> that defines how to expose semantics of WAI-ARIA and other web content languages to <a>accessibility <abbr title="Application Programing Interfaces">APIs</abbr></a>.
</p>
<section class="section" id="intro_ria_accessibility">
<h2>Rich Internet Application Accessibility</h2>
<p>The domain of web accessibility defines how to make web content usable by persons with disabilities. Persons with certain types of disabilities use <a>assistive technologies</a> (<abbr title="Assistive Technologies">AT</abbr>) to interact with content. Assistive technologies can transform the presentation of content into a format more suitable to the user, and can allow the user to interact in different ways. For example, the user may need to, or choose to, interact with a slider widget via arrow keys, instead of dragging and dropping with a mouse. In order to accomplish this effectively, the software needs to understand the <a>semantics</a> of the content. Semantics is the science of meaning; in this case, used to assign roles, states, and properties that apply to user interface and content elements as a human would understand. For instance, if a paragraph is semantically identified as such, assistive technologies can interact with it as a unit separable from the rest of the content, knowing the exact boundaries of that paragraph. An adjustable range slider or collapsible list (a.k.a. a tree <a>widget</a>) are more complex examples, in which various parts of the widget have semantics that need to be properly identified for assistive technologies to support effective interaction.</p>
Expand Down Expand Up @@ -237,7 +232,6 @@ <h3>Testing Practices and Tools</h3>
<h2>Assistive Technologies</h2>
<p>Programmatic access to accessibility semantics is essential for assistive technologies. Most assistive technologies interact with user agents, like other applications, through a recognized accessibility API. Perceivable objects in the user interface are exposed to assistive technologies as accessible objects, defined by the accessibility API interfaces. To do this properly, accessibility information – role, states, properties as well as contextual information – needs to be accurately conveyed to the assistive technologies through the accessibility API. When a state change occurs, the user agent provides the appropriate event notification to the accessibility API. Contextual information, in many host languages like HTML, can be determined from the <abbr title="Document Object Model">DOM</abbr> itself as it provides a contextual tree hierarchy.</p>
<p>While some assistive technologies interact with these accessibility APIs, others may access the content directly from the <abbr title="Document Object Model">DOM</abbr>. These technologies can restructure, simplify, style, or reflow the content to help a different set of users. Common use cases for these types of adaptations may be the aging population, persons with cognitive impairments, or persons in environments that interfere with use of their tools. For example, the availability of regional navigational landmarks may allow for a mobile device adaptation that shows only portions of the content at any one time based on its semantics. This could reduce the amount of information the user needed to process at any one time. In other situations it may be appropriate to replace a custom user interface control with something that is easier to navigate with a keyboard, or touch screen device.</p>
<p>These requirements for semantic programmatic access parallel <a href="http://www.w3.org/TR/2002/REC-UAAG10-20021217/guidelines.html#tech-ui-access-api">User Agent Accessibility Guidelines: Programmatic operation of user agent user interface</a> and <cite><a href="http://www.w3.org/TR/2002/REC-UAAG10-20021217/guidelines.html#tech-api-notify-change">Programmatic notification of changes</a></cite> ([[UAAG10]]) except that it applies to content, not just to the <a>user agent</a>.</p>
</section>
</section>
<section class="informative" id="usage">
Expand Down

0 comments on commit 13a5e4a

Please sign in to comment.