RE: FW: Good accessibility practice for handling footnotes

Thanks, that helps me as well. Sometimes I have trouble keeping track of all the different specs… 😊


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: Matt Garrish <matt.garrish@gmail.com>
Sent: Tuesday, August 3, 2021 10:48 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; 'Peter Weil' <peter.weil@wisc.edu>; 'Louise Lister' <Louise.Lister@iop.org>; w3c-wai-ig@w3.org; kerscher@montana.com
Subject: RE: FW: Good accessibility practice for handling footnotes

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Bryan, Peter,

The DPUB-ARIA module is not a creation specifically for EPUB although it was obviously developed with publishers as a top priority. You can use the roles in any web content which is why they have the generic prefix “doc-“ instead of a more specific prefix like “epub-“. Publishers often have multiple output streams, and EPUB content is often read in browsers, so the roles need to work anywhere.

The DPUB-ARIA AAM document defines the mapping for these roles for exposing them to AT, and they’re also documented in the ARIA in HTML document, so although uptake may still not be perfect, if there are holes or bugs we should be able to get them addressed.

The reason why the vocabulary exists as a separate module is that that is the extensibility model for ARIA. It’s sort of like a proving ground for the roles, with the possibility in the future that there could be tighter integration in ARIA core for at least some roles (which would then drop their “doc-“ prefix). When we approached the ARIA group about integrating roles that are useful for publishing, creating the module was agreed on as the first step. The roles are as valid as the core ones, in other words. (There’s also an extension for graphics roles.)

You also don’t have to know anything about XML namespaces here. The “doc-” prefix is sort of namespace-lite, where ARIA defines the part before the hyphen as the prefix without anyone having to declare it (it’s also why ARIA role names aren’t hyphenated).

Anyway, hope this helps clear up at least some confusion. And there should be a first public working draft of the 1.1 module landing shortly.

Matt

From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Sent: August 3, 2021 2:20 PM
To: Peter Weil <peter.weil@wisc.edu<mailto:peter.weil@wisc.edu>>; 'Louise Lister' <Louise.Lister@iop.org<mailto:Louise.Lister@iop.org>>; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>; kerscher@montana.com<mailto:kerscher@montana.com>
Subject: RE: FW: Good accessibility practice for handling footnotes

Hi,
It is important to note that standard ARIA roles and supporting attributes are global in context, meaning they are usable within any HTML webpage and will be parsed by the browser in that context.

The epub roles, in contrast, are specific to epub document syntax, and do require XML namespacing to function properly.
https://format.mtm.se/nordic_epub/2020-1#namespaces


At least, this is my understanding.

“Also, do these roles communicate any information directly to the user, or only to the assistive technologies users might be using?”

The breakdown is that valid ARIA roles and supporting attributes are parsed by the browser, the browser then builds the accessibility tree which maps them into the OS accessibility API, then Ats like screen readers interface with elements in the accessibility tree, then the AT conveys what it detects to the user however this is programmed to do so such as by conveying the role of the element or detecting changed states or triggered events on those elements.

Hopefully that makes sense.

All the best,
Bryan



Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: Peter Weil <peter.weil@wisc.edu<mailto:peter.weil@wisc.edu>>
Sent: Monday, August 2, 2021 5:34 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>; 'Louise Lister' <Louise.Lister@iop.org<mailto:Louise.Lister@iop.org>>; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>; kerscher@montana.com<mailto:kerscher@montana.com>
Subject: Re: FW: Good accessibility practice for handling footnotes

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Thanks Bryan and Matt.

Does anyone know why are these aria-roles are documented separately from the roles developers are probably more familiar with in https://w3c.github.io/aria/? If they are usable in the web context, it seems as though they deserve some mention in the latter (unless I’ve missed something).

Also, do these roles communicate any information directly to the user, or only to the assistive technologies users might be using?

Peter


--
Peter Weil, Web Developer
University Marketing
University of Wisconsin–Madison
peter.weil@wisc.edu<mailto:peter.weil@wisc.edu>
(m) 608-220-3089