- From: Rich Schwerdtfeger <richschwer@gmail.com>
- Date: Tue, 19 Jul 2016 19:49:17 -0400
- To: James Craig <jcraig@apple.com>
- Cc: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>, Joanmarie Diggs <jdiggs@igalia.com>, ARIA Working Group <public-aria@w3.org>, Fred Esch <fesch@us.ibm.com>, "DPUB-ARIA (public-dpub-aria@w3.org)" <public-dpub-aria@w3.org>
It is your platform. Incidentally, I have built a lot ATs and APIs. Also, I have a lot more history. We are in complete disagreement. Folks, I tried. I will put in James' mappings. 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 Tuesday, 19 July 2016 23:49:49 UTC