- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 9 Apr 2015 09:31:14 -0500
- To: Markus Gylling <markus.gylling@gmail.com>
- Cc: cooper@w3.org, Janina Sajka <janina@rednote.net>, Matt Garrish <matt.garrish@bell.net>, public-dpub-aria@w3.org, "Shane McCarron" <shane@aptest.com>
- Message-ID: <OF177BCC32.9248675F-ON86257E22.004FA24A-86257E22.004FC3B1@us.ibm.com>
I included a review/vote discussion in the ARIA Task Force Meeting today
ahead of the PF call next week. The final vote would come from PF.
Rich Schwerdtfeger
From: Markus Gylling <markus.gylling@gmail.com>
To: Janina Sajka <janina@rednote.net>, Richard
Schwerdtfeger/Austin/IBM@IBMUS, Matt Garrish
<matt.garrish@bell.net>, cooper@w3.org, public-dpub-aria@w3.org
Date: 04/09/2015 08:13 AM
Subject: Re: Drafts of the Digital Publishing WAI-ARIA module abstract
and introduction as promised
The DPUB IG will make its call for resolution on this coming Mondays IG
call.
/markus
Janina Sajka
9 Apr 2015 14:59
We need a RESOLUTION: on record from the Dpub IG and from PF
requesting
transition to First Public Working Draft (FPWD).
However, it would be best to use a permanent, short name URI for
the
Call for Consensus email, rather than a rawgit.
If we're ready to go forward, I can get out PF's CfC today. But, I
need
confirmation of the URI to use.
Janina
Richard Schwerdtfeger
8 Apr 2015 22:14
Hi Matt, Michael,
What is the status of the publication of this document to FPWD?
http://rawgit.com/w3c/aria/master/aria/dpub.html
Rich
Rich Schwerdtfeger
Matt Garrish
27 Mar 2015 13:56
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
Richard Schwerdtfeger
26 Mar 2015 23:46
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
Attachments
- image/gif attachment: graycol.gif
- image/jpeg attachment: 31497465.jpg
Received on Thursday, 9 April 2015 14:31:58 UTC