Re: Drafts of the Digital Publishing WAI-ARIA module abstract and introduction as promised

This is fantastic! We’ll get integrated today.

Matt

From: Richard Schwerdtfeger 
Sent: Thursday, March 26, 2015 6:46 PM
To: cooper@w3.org ; Shane McCarron ; Matt Garrish 
Cc: mailto:public-dpub-aria@w3.org ; ext Janina Sajka 
Subject: Drafts of the Digital Publishing WAI-ARIA module abstract and introduction as promised

Happy Trails. :-)

Abstract: 

Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow assistive technologies to convey appropriate information to persons with disabilities. This specification defines a [WAI-ARIA 1.1] module encompassing an ontology of roles, states, and properties specific to the digital publishing industry. These semantics are designed to allow an author to convey digital book user interface behaviors and structural information to assistive technologies and to enable semantic navigation, styling, and interactive features used by digital book readers. It is expected this will complement [HTML5]. 

This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

Issues: 

We need to update the WAI-ARIA Overview to include this document, WAI-ARIA 1.1, and all the WAI-ARIA Mapping specification suite of documents. 
Can we reference EPUB in the abstract?


Introduction:

This section is non-normative.


This section is non-normative. 

The goals of this specification include: 


  · Expanding WAI-ARIA 1.1 to produce structural semantic extensions to accommodate the digital publishing industry 
  · Align with a new governance model for modularization and extensions to WAI-ARIA. 

  · Provide structural semantics extensions that will support both assistive technologies and enable semantic navigation, styling, and interactive features used by digital book readers 


WAI-ARIA is a technical specification that defines a common host language semantic accessibility API and framework that enables web browsers to map the accessibility semantics in web content to platform-specific accessibility APIs. This enables web content to be interoperable with platform assistive technologies similar to native platform applications without platform dependencies. For a more detailed explanation of WAI-ARIA please refer to the WAI-ARIA Introduction and how it applies to Rich Internet Application Accessibility. This specification is a modular extension to designed for the digital publishing industry and it is derived from the EPUB Structural Semantics Vocabulary. 

1.1 Target Audience§ 

This specification defines the basic model for WAI-ARIA, including roles, states, properties, and values. It impacts several audiences: 


  · User agents that process content containing WAI-ARIA and Digital Publishing WAI-ARIA features; 
  · Assistive technologies that present content in special ways to user with disabilities; 

  · Digital Book Authors; 

  · Digital Book Authoring tools that help authors create conforming content; and 

  · Conformance checkers,  that verify appropriate use of WAI-ARIA and this Digital Publishing WAI-ARIA module.


Each conformance requirement indicates the audience to which it applies. 
Although this specification is applicable to the above audiences, it is not specifically targeted to, nor is it intended to be the sole source of information for, any of these audiences. In the future, additional documents will be created to assisting authors in applying these WAI-ARIA semantics for the digital book publishing industry as well as define how the information in this document is mapped to platform accessibility APIs. 

1.3 User Agent Support§ 

WAI-ARIA relies on user agent support for its features in two ways: 


  · Mainstream user agents use WAI-ARIA to alter how host language features are exposed to accessibility APIs in order to improve accessibility. The mechanism for this is defined in the Core Accessibility API Mappings 1.1 [CORE-AM] specification and the Accessible Name and Description Computation and Accessibility API Mappings 1.1 [ACCNAME-AAM] and a future accessibility mapping specification corresponding to this specification. 
  · Assistive technologies use the enhanced information available in an accessibility API, or uses the WAI-ARIA markup directly via the DOM, to convey semantic and interaction information to the user.


Aside from using this markup to improve what is exposed to accessibility APIs, user agents behave as they would natively. Assistive technologies react to the extra information in the accessibility API as they already do for the same information on non-web content. User agents that are not assistive technologies, however, need do nothing beyond providing appropriate updates to the accessibility API. 
The WAI-ARIA specification neither requires or forbids user agents from enhancing native presentation and interaction behaviors on the basis of this markup. Mainstream user agents, such as EPUB book readers, might respond to voice recognition commands to navigate to landmarks areas defined in this specification with the intention to facilitate navigation for all users. User agents are encouraged to maximize their usefulness to users, including users without disabilities. 

The intent of this specification is to provide missing semantics so that the intent of the author may be conveyed to assistive technologies. Generally, authors using this WAI-ARIA module will provide the appropriate presentation and interaction features. Over time, host languages may add WAI-ARIA equivalents that are implemented as standard accessible user interface elemnts by the user agent. This allows authors to use them instead of custom WAI-ARIA enabled user interface components. In this case the user agent would support the native host language feature. Developers of host languages that implement Digital Publishing WAI-ARIA features are advised to continue supporting these features when they do not adversely conflict with implicit host language semantics, as these semantics more clearly reflect the intent of the author if the host language features are inadequate to meet the author's needs. 

1.4 Co-Evolution of WAI-ARIA and Host Languages§ 

The Digital Publishing WAI-ARIA module is intended to augment semantics in supporting languages like [HTML5],  [SVG2], and EPUB or to be used as an accessibility enhancement technology in other markup-based languages that do not explicitly include support for ARIA. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page, because the invention of new types of objects is faster than standardized support for them appears in web languages. 

It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of objects. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively. For example, it's not better to use an heading role on a div element than it is to use a native heading element, such as an <h1>. 

It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with this specification. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using this module for that feature. Legacy content may continue to use the Digital Publishing WAI-ARIA module, however, so the need for user agents to support it remains. 

While specific features of this module may lose importance over time, the general possibility of the Digital Publishing WAI-ARIA module to add semantics to web pages or open web based standares, such as EPUB, is expected to be a persistent need. Host languages may not implement all the semantics this module provides, and various host languages may implement different subsets of the features. New types of objects are continually being developed, and one goal of this specification is to provide a way to make such objects accessible, because authoring practices often advance faster than host language standards. In this way, this module and host languages both evolve together but at different rates. 

Some host languages exist to create semantics for features other than the user interface. For example, SVG expresses the semantics behind production of graphical objects, not of user interface components that those objects may represent; XForms provides semantics for form controls and does not provide wider user interface features. Host languages such as these might, by design, not provide native semantics that map to this specification's features. In these cases, the Digital Publishing WAI-ARIA module could be adopted as a long-term approach to add semantic information to these host languages. 

1.5 Authoring Practices§ 

1.5.1 Authoring Tools§ 

Many of the requirements in the definitions of the WAI-ARIA and Digital Publishing WAI-ARIA  roles, state, and properties can be checked automatically during the development process, similar to other quality control processes used for validating code. To assist authors who are creating digital books, such as EPUB, can compare the semantic structure of Digital Publishing WAI-ARIA roles from the DOM to that defined in this specification and notify the author of errors or simply create templates that enforce that structure. 

1.5.2 Testing Practices and Tools§ 

The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content should test for device-independent access to widgets and applications, and should verify accessibility API access to all content and changes during user interaction. 

1.6 Assistive Technologies§ 

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 DOM itself as it provides a contextual tree hierarchy. 

While some assistive technologies interact with these accessibility APIs, others may access the content directly from the DOM. 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. 

These requirements for semantic programmatic access parallel future specifications designed to map the features of this document to platform accessibility APIs. 

Rich

Rich Schwerdtfeger