Okay here is the single most important description I could find comparing epub:type to aria roles so I quoted it here:
Quote:
It is important to understand the differences between the epub:type attribute [epub-3] and the role attribute [wai-aria] to ensure that they are properly applied for their intended purposes and audiences.
The biggest of these differences is in their primary applications. The epub:type attribute has evolved to aid publisher workflows. It has limited use enabling reading system behaviors outside of some core functionality of EPUB (identifying navigation elements and enhancing media overlay documents). Although it was hoped the attribute would also expose information to assistive technologies, in practice it does not.
The primary purpose of the role attribute, on the other hand, is to expose information to assistive technologies. It is not to facilitate user agent behaviors.
The result of these differences is that the application of epub:type semantics is largely harmless, but misapplication of ARIA roles can have negative impacts on the reading experience, from over-announcement of information to broken rendering for assistive technology users.
This guide addresses key authoring differences to be aware of when migrating to ARIA roles from the epub:type attribute, or when using both attributes together. The goal is to help publishers avoid the pitfalls of applying ARIA roles like they would epub:type semantics and breaking the reading experience for users of assistive technologies.
|
This quote was taken from here:
https://www.w3.org/TR/epub-aria-authoring-11/
So they hoped epub:type would be useful to assistive technologies but it turns out they are basically ignored.
The epub:type values were also designed to alert publishing and reading systems and to be used in the nav for Landmarks (similar to what guide elements did for epub2). In addition, epub:type values can be used by an e-reader to understand the nav and table of contents and to do things like make pop-up footnotes happen.
So epub:type value are typically assigned to file level as nav landmarks or individual elements like a single footnote.
The aria role is what current assistive technologies use but certain roles may only be applied to certain types of tags and are not typically file level. In fact aria-roles can never be assigned to a body tag. They can be assigned to section, div, span and more generic container tags. But the rules are complex. For example doc-footnote should not be applied to an item in a list such as an li tag inside a ul or ol tag. So you can label a section or div tag with a doc-footnotes role but if a list is used no individual doc-footnote role should be applied to individual footnotes in that list.
So adding roles to an epub3 is really good for assistive technologies but how exactly that is done needs to follow quite arcane rules.
The bottom line is we can make it easier to assign both epub:type attributes and aria roles but the latter needs to be done by the author very carefully to prevent harm from being done by assistive technologies overly announcing things or interfering with things.
The rules of when and where to assign aria roles is complex enough that a full table lookup had to be implemented in the Sigil Access-Aide plugin just to try to come to grips with it.
This is going to take some design thought. And whatever tool we end up using in CodeView must be context sensitive based of the current tag the cursor is in at the very least. But given its inheritance property, it may come need even more help.
Perhaps a more advanced Access-Aide plugin might be the way to go here. Or we just pass the buck to the epub dev person to know when if and where to attach aria roles and give them a clips menu and let them at it.