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

Thank you. I am looking forward to seeing it come out.


Rich Schwerdtfeger


From: Matt Garrish <matt.garrish@bell.net>
To: <cooper@w3.org>, "Shane McCarron" <shane@aptest.com>, Richard
            Schwerdtfeger/Austin/IBM@IBMUS
Cc: <public-dpub-aria@w3.org>, "ext Janina Sajka"
            <janina@rednote.net>
Date: 03/27/2015 07:57 AM
Subject: 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