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 <mailto:janina@rednote.net>
> 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 <mailto:schwer@us.ibm.com>
> 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 <mailto:matt.garrish@bell.net>
> 27 Mar 2015 13:56
> This is fantastic! We'll get integrated today.
> Matt
> *From:* Richard Schwerdtfeger <mailto:schwer@us.ibm.com>
> *Sent:* Thursday, March 26, 2015 6:46 PM
> *To:* cooper@w3.org <mailto:cooper@w3.org> ; Shane McCarron 
> <mailto:shane@aptest.com> ; Matt Garrish <mailto:matt.garrish@bell.net>
> *Cc:* mailto:public-dpub-aria@w3.org ; ext Janina Sajka 
> <mailto:janina@rednote.net>
> *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_/ 
> <http://rawgit.com/w3c/aria/master/aria/aria.html#bib-HTML5>].
>
> This document is part of the WAI-ARIA suite described in the _WAI-ARIA 
> Overview_ <http://www.w3.org/WAI/intro/aria.php>.
>
> 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 
> <wlmailhtml:Digital%20Publishing%20WAI-ARIA>.
>
> *1.1 Target Audience**_§_* <http://www.w3.org/TR/wai-aria-1.1/>
>
> This specification defines the basic model for WAI-ARIA, including 
> roles, states, properties, and values. It impacts several audiences:
>
>
>     · _User agents_ <http://www.w3.org/TR/wai-aria-1.1/>that process
>     content containing WAI-ARIA and Digital Publishing WAI-ARIA features;
>
>     · _Assistive technologies_
>     <http://www.w3.org/TR/wai-aria-1.1/>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**_§_* <http://www.w3.org/TR/wai-aria-1.1/>
>
> WAI-ARIA relies on user agent support for its features in two ways:
>
>
>     · Mainstream _user agents_ <http://www.w3.org/TR/wai-aria-1.1/>use
>     WAI-ARIA to alter how host language features are exposed to
>     _accessibility APIs_ <http://www.w3.org/TR/wai-aria-1.1/>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_ <http://www.w3.org/TR/wai-aria-1.1/>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**_§_* 
> <http://www.w3.org/TR/wai-aria-1.1/>
>
> The Digital Publishing WAI-ARIA module is intended to augment 
> semantics in supporting languages like [/_HTML5_/ 
> <http://www.w3.org/TR/wai-aria-1.1/>],  [/_SVG2_/ 
> <http://www.w3.org/TR/wai-aria-1.1/>], 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_ 
> <http://www.w3.org/TR/wai-aria-1.1/>role on a divelement 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**_§_* <http://www.w3.org/TR/wai-aria-1.1/>
>
> *1.5.1 Authoring Tools**_§_* <http://www.w3.org/TR/wai-aria-1.1/>
>
> Many of the requirements in the definitions of the WAI-ARIA and 
> Digital Publishing WAI-ARIA _roles_ 
> <http://www.w3.org/TR/wai-aria-1.1/>, _state_ 
> <http://www.w3.org/TR/wai-aria-1.1/>, and _properties_ 
> <http://www.w3.org/TR/wai-aria-1.1/>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**_§_* 
> <http://www.w3.org/TR/wai-aria-1.1/>
>
> The accessibility of interactive content cannot be confirmed by static 
> checks alone. Developers of interactive content should test for 
> device-independent access to _widgets_ 
> <http://www.w3.org/TR/wai-aria-1.1/>and applications, and should 
> verify accessibility API access to all content and changes during user 
> interaction.
>
> *1.6 Assistive Technologies**_§_* <http://www.w3.org/TR/wai-aria-1.1/>
>
> 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 <mailto:schwer@us.ibm.com>
> 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_/ 
> <http://rawgit.com/w3c/aria/master/aria/aria.html#bib-HTML5>].
>
> This document is part of the WAI-ARIA suite described in the _WAI-ARIA 
> Overview_ <http://www.w3.org/WAI/intro/aria.php>.
>
> 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 <Digital%20Publishing%20WAI-ARIA>.
>
> *1.1 Target Audience**_§_* <http://www.w3.org/TR/wai-aria-1.1/>
>
> This specification defines the basic model for WAI-ARIA, including 
> roles, states, properties, and values. It impacts several audiences:
>
>
>     · _User agents_ <http://www.w3.org/TR/wai-aria-1.1/> that process
>     content containing WAI-ARIA and Digital Publishing WAI-ARIA features;
>
>     · _Assistive technologies_
>     <http://www.w3.org/TR/wai-aria-1.1/> 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**_§_* <http://www.w3.org/TR/wai-aria-1.1/>
>
> WAI-ARIA relies on user agent support for its features in two ways:
>
>
>     · Mainstream _user agents_
>     <http://www.w3.org/TR/wai-aria-1.1/> use WAI-ARIA to alter how
>     host language features are exposed to _accessibility APIs_
>     <http://www.w3.org/TR/wai-aria-1.1/> 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_
>     <http://www.w3.org/TR/wai-aria-1.1/> 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**_§_* 
> <http://www.w3.org/TR/wai-aria-1.1/>
>
> The Digital Publishing WAI-ARIA module is intended to augment 
> semantics in supporting languages like [/_HTML5_/ 
> <http://www.w3.org/TR/wai-aria-1.1/>],  [/_SVG2_/ 
> <http://www.w3.org/TR/wai-aria-1.1/>], 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_ 
> <http://www.w3.org/TR/wai-aria-1.1/> 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**_§_* <http://www.w3.org/TR/wai-aria-1.1/>
>
> *1.5.1 Authoring Tools**_§_* <http://www.w3.org/TR/wai-aria-1.1/>
>
> Many of the requirements in the definitions of the WAI-ARIA and 
> Digital Publishing WAI-ARIA _roles_ 
> <http://www.w3.org/TR/wai-aria-1.1/>, _state_ 
> <http://www.w3.org/TR/wai-aria-1.1/>, and _properties_ 
> <http://www.w3.org/TR/wai-aria-1.1/> 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**_§_* 
> <http://www.w3.org/TR/wai-aria-1.1/>
>
> The accessibility of interactive content cannot be confirmed by static 
> checks alone. Developers of interactive content should test for 
> device-independent access to _widgets_ 
> <http://www.w3.org/TR/wai-aria-1.1/> and applications, and should 
> verify accessibility API access to all content and changes during user 
> interaction.
>
> *1.6 Assistive Technologies**_§_* <http://www.w3.org/TR/wai-aria-1.1/>
>
> 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
>