RE: AXAPI Role mappings for DPub and Graphics AAMs

A follow up question. What if these roles are used outside of the EPUB context? They are written with the intention of being used anywhere.

Thanks,
Tzviya

Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Friday, July 22, 2016 1:48 PM
To: James Craig
Cc: Siegman, Tzviya - Hoboken; Joanmarie Diggs; ARIA Working Group; Fred Esch; Mike Cooper; DPUB-ARIA (public-dpub-aria@w3.org)
Subject: Re: AXAPI Role mappings for DPub and Graphics AAMs

d
Rich Schwerdtfeger



On Jul 21, 2016, at 8:27 PM, James Craig <jcraig@apple.com<mailto:jcraig@apple.com>> wrote:


On Jul 21, 2016, at 5:37 AM, Richard Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>> wrote:


On Jul 21, 2016, at 1:32 AM, James Craig <jcraig@apple.com<mailto:jcraig@apple.com>> wrote:


On Jul 19, 2016, at 4:49 PM, Rich Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>> wrote:


Folks, I tried. I will put in James' mappings.

Joanie asked me to review the mappings, and I did. Some of the macOS subroles and role descriptions that were in the DPUB-AAM document seemed to have been fabricated, or at best, speculative. The draft I reviewed recommended non-implemented, non-standard, unsupported, and therefore potentially misleading and overly complicated API, so I asked that the editors correct it.

This is a standard practice in the standardization process.

Yes, as is the discussion. We know the subroles would be fabricated as they did not exist. We were asking for new roles.

If and/or when those roles are created and supported, they should go into the next draft. Until that time, they should not be included in a TR. There is no benefit to documenting unsupported, unimplemented, information that is highly likely to change. So I asked that they be removed, as is my duty.


We have recommended and created new accessibility API enhancements for some ARIA 1.1 features on other accessibility APIs. So, your platform should be no different.

I do not agree with mapping things to the group role bucket which has no real value to end users. I feel dependencies on author defined headings to convey role information is brittle.

Straw man fallacy. I did not suggest such a thing. That would indeed be brittle and foolish.


However, it is your platform. If you choose to not expose information the digital publishing industry accessibility professionals feels is important to AT users that is of course entirely your choice. It is your platform.

You keep suggesting that we're somehow preventing assistive technology users from getting to necessary information. It's just simply untrue. Apple has the strongest accessibility record of any major company, and iBooks is one of the most accessible EPUB reader readers on the market. I think it's likely the *most* accessible of the mainstream EPUB readers.

The information you deem necessary to be exposed through new API mappings is already exposed by the unambiguous document structure of EPUB.

Let's take the "doc-acknowledgements" role as an example.

  *   EPUB requires the use of a table of contents that links to sections of the documents
  *   EPUB requires the use of class="acknowledgements"
  *   EPUB requires the use of epub:type="acknowledgements" (presumably this is changing to role="doc-acknowledgements", which would still be unambiguous even without additional platform-specific role mappings, because EPUB readers have direct source or DOM access to the EPUB files)

I see. So, you plan to access the information through the DOM and that defines your interoperability. That was not stated before or conveyed to the group.

Is it also true that VoiceOver accesses the DOM in addition to the accessibility API? Is this the case for iBooks and general web content?


Without the need for any additional platform-specific role mappings, any EPUB reader (even one that renders in a standard web browser) already has multiple unambiguous ways to identify and navigate to the "acknowledgements" section. No platform-specific accessibility API role mapping is required, though it'd be fine for a platform API to adopt one if and when they determine it to be useful or more efficient than the other means. This is what all other working groups recognize as an "implementation detail."

Regardless of the implementation details, end users with accessibility needs can (and already do) have an accessible means of identifying and navigating to the section in many EPUB readers, including iBooks. Therefore, an additional API role mapping for the "acknowledgements" section is unnecessary.

Conversely, adding new mappings for purely academic reasons has seriously negative implications. It requires implementation and engineering work with no clear user benefit, and further complicates the API, discouraging author adoption, and delaying implementation by browser vendors.

I don't know of any clearer way to state that.
If you plan on having your AT access the DOM for this information then I don’t have issues, at least in terms of the book reader. I would hope this is also the case for general browser access.

I ask you these questions as there needs to be a way to expose access to the information. In my mind it does not have to mean the a11y. Microsoft Edge does NOT expose the DOM to ATs on Windows 10. All information must be exposed through UIA. We don’t carry a crystal ball with James and we don’t know what VoiceOver has access to. This is the first we have heard this from you.

Net, Net, we should write that fact into the API mappings. If you are saying that the ATs can have access to the DOM I can make an argument that we don’t even have to test that mapping as All browsers must produce a DOM and the standard DOM 1.0 supported access to the attributes.


Rich



James



Rich




Cheers,
James



Rich

Sent from my iPhone


On Jul 19, 2016, at 6:05 PM, James Craig <jcraig@apple.com<mailto:jcraig@apple.com>> wrote:



On Jul 19, 2016, at 11:30 AM, Rich Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>> wrote:

To me this is a very limited view. I have been on multiple calls now where we have limited accessibility issues to those related to sight.

The inclusion of these semantics enables mobility enabled users, in fact all users to navigate via voice. I should be able to tell my book reader to go to the abstract or read the abstract. You absolutely do not need a heading to make this work for all users nor should we depend on it.

We need to think about the use of these much more broadly. Going forward we will be going to user interactions that will be far less dependent on these ATs and the assumption that we must always be able to see something to get to it is false.

If this is the limited vision of ARIA working group members then I have a problem.

You're conflating product design and API design. Product vision would be limited if we assumed that all new product features require a new API role.

As an assistive technology developer, there are a number of ways to achieve this. The approach that relies on an author to add an opt-in role may be the least reliable because it hinges on authors doing the right thing. History has shown that simple, mainstream APIs are the most widely used and therefore the most reliable. The the case of EPUB, there is a standard way to define special sections (acknowledgements, etc) and EPUB readers use those standards to provide navigation by chapter and special sections like Table of Contents, Footnotes, etc.

It's not the Working Group's charter to design products but to design an API. It's in everyone's best interest if the group keeps that API as simple as possible.


DAISY talking books, for which these semantics came from did not have to depend on visual labels.

James, please reconsider your position in the API mappings.

Rich



Sent from my iPhone


On Jul 18, 2016, at 8:06 PM, James Craig <jcraig@apple.com<mailto:jcraig@apple.com>> wrote:

Siegman, Tzviya - Hoboken wrote:


Rich Schwerdtfeger wrote:


James provided mappings for things like appendix and acknowledgements below. Rather than expose these as appendix and acknowledgements he believes they only need be exposed as a group as the headers for those section will include those words i. Them at all times

While it is true that often there is a heading for these elements (e.g. <h1>Bibliography</h1>), it is not always the case, especially for something like doc-endnotes.

If these sections (acknowledgements, etc) have no heading, then there is no indication to sighted users that it's different from any other section. Therefore assistive technology users don't need additional context either. Both sighted and blind users could be equally confused by the lack of an explanatory heading, but that does not make it an accessibility issue.

A specific accessibility API role mapping would only be necessary if some context was conveyed visually but was not clear to say, a screen reader user.

James