Re: AXAPI Role mappings for DPub and Graphics AAMs

> On Jul 21, 2016, at 5:37 AM, Richard Schwerdtfeger <richschwer@gmail.com> wrote:
> 
>> On Jul 21, 2016, at 1:32 AM, James Craig <jcraig@apple.com> wrote:
>> 
>>> On Jul 19, 2016, at 4:49 PM, Rich Schwerdtfeger <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)

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.

James


> Rich
> 
> 
>> 
>> Cheers,
>> James
>> 
>> 
>>> Rich
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Jul 19, 2016, at 6:05 PM, James Craig <jcraig@apple.com> wrote:
>>>> 
>>>> 
>>>>> On Jul 19, 2016, at 11:30 AM, Rich Schwerdtfeger <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> 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
>>>> 
>>> 
>> 
> 
>