mattgarrish
commented
2 years ago The only reference to ARIA in the 1.0 specification was in the description of optional accessibilityAPI property. That property is no longer referenced, and the use of ARIA as an API was also incorrect and has been fixed in the vocabulary -- it is now a feature.
We're not modifying the requirements on the use of names, roles, states, and properties that go into meeting WCAG. If you don't meet those requirements, you can't claim accessibility. That would include meeting aspects of 1.3.1, 4.1.2, 4.1.3 and probably others that aren't immediately coming to mind.
A separate relationship section can't really be justified in the main specification, in other words, as there's nothing specific to tie it to in the rest of the document. If we want to mention ARIA just for emphasis, I'd replace "rich semantics" in the first sentence of the WCAG relationship section with:
WCAG [wcag2] and its associated techniques provide extensive coverage of issues and solutions for web content accessibility — from tables to embedded multimedia to using [[wai-aria]] for interactive content.
We already mention ARIA often in the techniques document, which is where it's more apt since ARIA isn't a conformance standard. If there's something specific about its use in publications that needs explaining, that would be the place to focus on.
LaZay
It would be nice to add a new section called Relationship to ARIA. As a matter of fact, there is a lot of misinformation on this topic.
This new section would be parallel to Relationship to WCAG, with a very similar (low investment) content, as the philosophy of complementary accessibillity standards is exactly the same in both cases.
It goes better when you say it explicitly. Some people do not want to make the investment into ARIA. They pretend that no ARIA at all is necessary for AT in EPUBs, as the EPUB accessibility v1.1 standard does not even refer to ARIA anymore, when v1.0 did. Unfortunately, this can be false in some specific use cases.