DPUB IG Telco, 2015-12-07: Accessibility Mapping, Archiving Task Force

Author(s) and publish date


See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

DPUB ARIA Accessibility API mapping

A mapping of the DPUB ARIA terms to Assistive technologies have just been published as a Working Draft. To provide a clearer understanding of what is this technology doing, Joseph Scheuhammer, from the ARIA WG, has joined the group to give an overview.

The roles in any of the ARIA document is a list of terms. What the API mappings do is say how the accessibility API mapping should utilize this. It functions as the layer between the HTML/SVG/etc, and the assistive technologies that part of the operating system.

The DPUB ARIA mapping includes a table with a row for each DPUB ARIA terms. The cells define how that term is mapped on the various mappings used by Windows, OS X, IOS, Linux, etc. (Android uses the Linux API, i.e., all current platforms are covered.) Each of these systems have so called accessible objects, which is a tree-structure in the accessible API. Similar to a DOM element, but not actually in the DOM. So a browser extracts (subsets) the DOM and creates a new tree item in the accessibility object tree. From there on you will have nodes in the new tree that has a role, a name, possibly a description, and a whole bunch of states and attributes. Using doc-abstract as an example: if you're a browser running on windows, and you're using i-accessable2, you take the string "doc-abstract" and it'll be a "role-system grouping" in the accessibility tree and it will include a property of the accessible object for abstract. From that point on the assistive technology system takes over and produces an accessible version of the information. It is important to note that the concept and the exact structures of the accessibility trees predates the Web, hence the major differences among platforms.

There were some questions on the details of the table which should, and will be converted into issues against the document.

Some further information on the underlying technologies are at:

Archival TF

The issue of archiving came up a few weeks ago, and the group discussed the need and possible scope for an archival Task Force. There are efforts on premise in the library space. There's an ISO standard on article versioning. We need to formulate the questions and get answers. We also need to make sure the PWP document reflects though. There are broader questions: should we strategically engage the parts of the library community that is dealing with archiving. The special library association is dealing with this area—there are preservation coalitions. Do we need to worry about archiving in our testing and demonstrations?

It was agreed that a separate task force should be set up, with has to give a more detailed scope for the task force. In general, it would be interesting to find out if archival institutions have run into technical issues—missing information— when archiving, e.g., large number of EPUB documents. What should be provided to making archiving easier? What is missing - from a technical point of view—and what is necessary—or PWP to make the job of archivers easier? If the answer is 'nothing really' then maybe we don't need to do more.

A number of pointers were listed for further reference:

Related RSS feed

Comments (0)

Comments for this post are closed.