Re: AXAPI Role mappings for DPub and Graphics AAMs

> 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:
>> 
>> It is your platform. 
>> 
>> Incidentally, I have built a lot ATs and APIs. Also, I have a lot more history.
> 
> I admit initial confusion why a Working Group Chair would cross-post his credentials to multiple working groups. 
> 
> I now presume this was because I included the sentence, "As an assistive technology developer, there are a number of ways to achieve this." The sentence was not referring to me, so there is no need for a competitive response. I could have also phrased it: "Assistive technology developers have a number of ways to achieve this." I'm hopeful that's more clear.
> 
>> We are in complete disagreement. 
> 
> I don't think so. In your previous email, you wrote:
> 
>> On Jul 19, 2016, at 7:13 AM, Rich Schwerdtfeger <richschwer@gmail.com> wrote:
>> 
>>> A lot of things indeed do not need to be mapped to something unique and this will be the case as you add new roles. There is also the point where you reach information overload with no ROI for AT users. In which case the roles should simply not be mapped. 
> 
> 
> This is precisely my point regarding some of the API mappings. Thank you for acknowledging it.
> 
> It seems we're in agreement conceptually. I'm just a little more conservative; I believe simpler APIs are better overall, and avoid new API if it's not needed to achieve the same end-user functionality. I'm trying to stay vigilant and strict to avoid scope creep. 
> 
> I consider this not only a reasonable approach, but the only reasonable approach for web API standardization. It's our duty to prevent unnecessary scope creep. Any unnecessary complication hinders adoption among authors and delays implementation among browser vendors.
> 
>> 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. 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. 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. 

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
>>> 
>> 
>

Received on Thursday, 21 July 2016 12:38:03 UTC