New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.1] conflict between Packages section 5.4.1 and DPUB-ARIA? #941

Closed
therealglazou opened this Issue Jan 11, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@therealglazou

therealglazou commented Jan 11, 2017

Section 5.4.1 ( http://www.idpf.org/epub/31/spec/epub-packages.html#sec-package-nav-def-model ) says the content model of nav is restricted when the element carries the epub:type attribute. Fine, easy, simple, since epub:type is not in the html original model.

But DPUB-ARIA ( https://www.w3.org/TR/dpub-aria-1.0/#exit_criteria ) makes epub:type only a fallback of the role attribute, and a fallback meant to ultimately vanish...

And it's impossible to restrict the model of all nav elements carrying a role attribute.

@mattgarrish

This comment has been minimized.

Show comment
Hide comment
@mattgarrish

mattgarrish Jan 11, 2017

Member

There was discussion about whether the fact that publishers are already using epub:type was sufficient to prove use of the WAI-ARIA module. That section, as I recall, was trying to make clear that we need publishers to commit to using ARIA role for accessibility where they are currently using epub:type, not that were trying to sneak a backdoor change into EPUB that would force people to stop using epub:type as it is defined in the specifications and replace it with role.

We rejected migrating to ARIA role for semantics in 3.1, and that section doesn't change that decision.

Authors should not use or rely on epub:type where they are expressing semantics for accessibility -- a given since it never got AT support. We recommend adding both attributes in the accessibility techniques to cover both cases.

It is kind of hard to decipher from the current prose, which does seem a bit drastic in its expectations, but that's at least my understanding.

Any thoughts @iherman ?

Member

mattgarrish commented Jan 11, 2017

There was discussion about whether the fact that publishers are already using epub:type was sufficient to prove use of the WAI-ARIA module. That section, as I recall, was trying to make clear that we need publishers to commit to using ARIA role for accessibility where they are currently using epub:type, not that were trying to sneak a backdoor change into EPUB that would force people to stop using epub:type as it is defined in the specifications and replace it with role.

We rejected migrating to ARIA role for semantics in 3.1, and that section doesn't change that decision.

Authors should not use or rely on epub:type where they are expressing semantics for accessibility -- a given since it never got AT support. We recommend adding both attributes in the accessibility techniques to cover both cases.

It is kind of hard to decipher from the current prose, which does seem a bit drastic in its expectations, but that's at least my understanding.

Any thoughts @iherman ?

@mattgarrish

This comment has been minimized.

Show comment
Hide comment
@mattgarrish

mattgarrish Feb 10, 2017

Member

Closing this issue as nothing to fix. I confirmed that the wording in the ARIA spec was only to highlight that publishers need to make a firm commitment to use the vocabulary as soon as it is published to count in the exit criteria. They do not have to replace epub:type, and certainly not where it is required by the EPUB specifications.

Member

mattgarrish commented Feb 10, 2017

Closing this issue as nothing to fix. I confirmed that the wording in the ARIA spec was only to highlight that publishers need to make a firm commitment to use the vocabulary as soon as it is published to count in the exit criteria. They do not have to replace epub:type, and certainly not where it is required by the EPUB specifications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment