Closed LaZay closed 1 year ago
aria-details is an excellent technique to identify the element's id that contains the extended description or a link to the extended description. I suggest this be included.
@GeorgeKerscher, while I expect aria-details
is still too new to have appeared in any techniques, is there anything specific about it for publications? The only thing I can think of is the bug with figures, but I'm not sure we want to add techniques about bugs. That's probably better explained in places like the knowledge base.
Otherwise, I'm not sure this issue is proposing anything that isn't already covered by WCAG's or our own techniques.
In the technical specification, there are two sections addressing ARIA so far;
ARIA could also be addressed the 4.7 Text and 5. EPUB Techniques.
The problem with adding an ARIA conformance section is that it would seem to compete with WCAG's success criteria, which are more flexible to how you achieve conformance.
Just as an example, the requirement for alt text and descriptions for images is already a requirement of SC 1.1.1. There are techniques for how to add these using aria attributes. Similarly, 1.3.1 covers situations where styling is used inaccessibly, and there is a technique for using ARIA role/level semantics.
ARIA is definitely an important means of achieving many success criteria, but we always have to be mindful that we're not writing competing documentation. That would most likely lead to conflicts moving the documents through W3C process, let alone the very real issue of our introducing language that blurs what is needed for conformance. The guiding principle has always been that we don't add to existing techniques unless they differ from their general application for publications (see the purpose and scope). If we think WCAG is missing information that is needed by anyone making content accessible, we go back to them to standardize it.
I agree the cases you've cited are important, in other words, but I can't see that they aren't already covered by WCAG itself.
Proposing that we close this issue, as we're not going to add a new section in CR and it's not clear how this would coexist with the same requirements in WCAG. /cc @avneeshsingh
In EPUB 3 Working Group Documents, we should avoid duplicating the information that already exists in Accessibility Guidelines and ARIA working groups documents. This would create practical issues but may also trigger political issues. if more guidance for implementing ARIA in publishing context is required, We can create additional community driven documents (in publishing CG or DAISY knowledge base).
The Wai-aria spec still does not address (nor directly include) the DPUB ARIA vocabulary. https://www.w3.org/TR/wai-aria-1.1 (Recommandation 2017) https://www.w3.org/TR/dpub-aria-1.0 (Recommandation 2017) https://www.w3.org/TR/dpub-aria-1.1 (Draft 2022)
So it is important that ARIA is clearly pointed out by the EPUB a11y spec, including both standard ARIA and DPUB ARIA, as they are complementary.
There are a few things to say about ARIA Conformance.
A) Semantics In order to help impaired people escape/zoom content
ARIA
@role
and@epub:type
epub:type
attribute + with better AT)ARIA
@role
to add missing semantics@level
), lists, tables, notes (if tagged as<span>
&<div>
)ARIA for accessible images
@aria-describedby
or@aria-labelledby
@role="doc-cover"
, and@role="presentation"
on decorative images?ARIA state for invisible content dedicated to visually impaired people
@aria-hidden
(very badly supported by reading systems so far, they MUST do much better = really hide text + reflow visible text)B) Interactivity Not a priority, but at least remind authors producing interactive EPUBs, that they must deal with ARIA states & properties