DPUB abstract/afterword/foreword/epilogue/qna/preface/prologue roles are unnecessary for accessibility

[cookiecrook]

The DPUB abstract role is unnecessary for accessibility. This is a simple section/chapter/region, etc. whose additional semantics are clearly conveyed by the labeling heading (usually "Abstract"). If this role is intended for parsing, I suggest using an ID instead. <section id="abstract">

[cookiecrook]

Ditto for afterword, foreword, epilogue, preface, and prologue

[halindrome]

Remember that A11Y isn't just about ATs. It is also about machines understanding the content. Having a search engine know that an area of a publication is the abstract / prologue / whatever will improve the ability to search for essential data.

[cookiecrook]

That's fine, but all the more reason to prefix and include and accessibility fallback role if that's the intended use. Members of DPUB have implied all these roles are for accessibility, so I'm pointing out that they are not very useful for the stated purpose.

[cookiecrook]

Ditto "qna" role

[joanmarie]

The are potentially something assistive technologies would want to provide navigation for, however. Mind you I personally would assume whatever the "quick key" is, it would be the same. If so, could this need be addressed by adding new types of landmark?

[cookiecrook]

I agree that using a landmark role for these is beneficial for quick navigation, but I don't think they need separate role semantics. We have discussed making labeled regions a generic landmark. So these could labels ("Prologue", etc) on an element with role="region"

[sideshowbarker]

Remember that A11Y isn't just about ATs. It is also about machines understanding the content. Having a search engine know that an area of a publication is the abstract / prologue / whatever will improve the ability to search for essential data.

Then I’d (re)assert that the need to convey information to machines understanding the content for that purpose can be accomplished using something other than the role attribute. I believe it is a language-design mistake to try to shoehorn not-for-AT information into the role attribute.

Also I am not interested in burdening users of the conformance checker I work on with consequences of adding unnecessary complexity to the reporting behavior for the role attribute. That checker behavior and reporting for users is already extremely complicated enough to the point of being baroque even though at this point it’s only limited to checking conformance rules for ARIA 1.0 role values and associated states and properties allowed for those particular roles.

I’m not going to implement support for some further fiddling with the role attribute for other things that I consider to be fundamentally bad language design that violates language principles that have been guiding the HTML over its history and in particular over the last 10 years—and that breaks with sound precedents that have been set.

[LJWatson]

I agree with @cookiecrook that these roles seem superfluous.

If the abstract role remains though, I suggest we find a different name for it. Calling a concrete role "abstract", when an abstract role is a very specific thing in programming terms, is not good usability.

[JaninaSajka]

These are accessibility because explicit semantic markup is the only way
a screen reader user can navigate to that explicit structure. Yes,
they're structures that everyone needs to understand. But people have
been seeing and comprehending them in print books since Gutenberg. The
screen reader user only since DAISY.

Janina

Léonie Watson writes:

I agree with @cookiecrook that these roles seem superfluous.

If the abstract role remains though, I suggest we find a different name for it. Calling a concrete role "abstract", when an abstract role is a very specific thing in programming terms, is not god usability.

---

Reply to this email directly or view it on GitHub:
#50 (comment)

Janina Sajka, Phone: +1.443.300.2200
sip:janina@asterisk.rednote.net
Email: janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf

[michael-n-cooper]

I think it is an important principle that we not let artifacts of the
spec intrude on the space of possible values for role names. The term
"abstract" has a very specific and well-known meaning in the publishing
world, and is a reasonable value for a role name. The fact that it also
has a different, well-known meaning in the programming world, and that
the ARIA spec uses that term, does not mean we should not allow the
value. The situations you would use "role=abstract" are very different
from the situations where you would use "abstract roles", so I do not
see the likelihood of confusion. Furthermore we have agreed to take
concrete steps to minimize the confusion, including explaining the
difference and removing abstract roles from the primary view of the spec
so most people won't encounter more than one meaning of the term.

This is important not just for the role of "abstract" being proposed,
but for other roles as well. If we were to decide that terms that have
meaning in the ARIA spec are not allowed as role values, we would
prohibit quite a number of values. For starters, "role", "state", and
"property" would be forbidden values, which would make it difficult for
an ontology of programming roles to be complete. Probably even "aria"
would be a forbidden value, which would be a major problem for a music
ontology.

This is a road we should not go down. The ARIA spec should not prohibit
any lexically valid role value, except for ones that are already defined
by the ARIA spec or a recognized extension. We should, however, attempt
to reduce the likelihood of confusion where such potential exists. One
has been identified for the value of "abstract" and we have committed
steps to address it.

On 06/05/2015 10:06 AM, JaninaSajka wrote:

These are accessibility because explicit semantic markup is the only way
a screen reader user can navigate to that explicit structure. Yes,
they're structures that everyone needs to understand. But people have
been seeing and comprehending them in print books since Gutenberg. The
screen reader user only since DAISY.

Janina

Léonie Watson writes:

I agree with @cookiecrook that these roles seem superfluous.

If the abstract role remains though, I suggest we find a different
name for it. Calling a concrete role "abstract", when an abstract role
is a very specific thing in programming terms, is not god usability.

---

Reply to this email directly or view it on GitHub:
#50 (comment)

Janina Sajka, Phone: +1.443.300.2200
sip:janina@asterisk.rednote.net
Email: janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf

—
Reply to this email directly or view it on GitHub
#50 (comment).

[richschwer]

I agree with Michael. Also, the task force agreed to not show the abstract roles, used for purposes of the taxonomy, in the spec.

[TzviyaSiegman]

Thank you for your feedback. This issue has been resolved by editing the document to comply with the rules for extending ARIA (https://www.w3.org/WAI/PF/wiki/ARIAExtensions).