Using epub:type=(noteref,footnote,endnote,pagebreak) as mapped to ARIA roles

[GarthConboy]

Issue request from Web Publishing WG F2F Meeting...

For EPUB structural vocabulary see: https://idpf.github.io/epub-vocabs/structure/

The above epub:type values are used by Reading Systems to afford footnote pop-up support (and indication of paper page-breaks). These all have mappings to ARIA roles.

If Reading Systems were to recognize the mapped ARIA roles to provide the affordances that they currently ascribe to epub:type... is this "wrong"? Would such drive creation of content that is sub-optimal from an A11Y perspective?

Use of this approach (using ARIA role mapping) seems better than exploring creation of another (non-epub:type) mechanism for defining said semantics.

[GarthConboy]

@TzviyaSiegman @iherman for the above.

[quasicomputational]

I think this is related to something I just bumped into, which is that dpub-noteref inheriting from link constrains how authors can use it: if you want pop-up footnotes (like, e.g., Wikipedia does), you really want role=button - but then that loses the semantic of 'this is a footnote'. There's an awkward conflation of semantic role and UI role here, and getting one right compromises the other.

[mattgarrish]

if you want pop-up footnotes (like, e.g., Wikipedia does), you really want role=button

But you can use progressive enhancement to get this, since the button and modal won't work if scripting isn't available (not uncommon in epub). The role wasn't designed for the modal case, as there are already roles for that. It's more about informing the user of the content at the end of the link (which can also lead to offering the ability to skip unwanted content, etc.).

The other problematic nature of this request is that implementing pop-up footnotes is not something the author designs in epub, so there isn't a case of authors using the role to mimic a button. Having it be a button would break epub content unless the author also implements a modal pop-up, as pop-up footnotes are not universal.

So to the question of whether a reading system can use the presence of an ARIA attribute as a trigger to reprocess the author's data, sure, why not? Any attribute is inspectable and operable on. But in doing so you couldn't leave doc-noteref on the transformed element, as it should have a button role instead.

Reading systems will need to produce alternative accessible markup for the new design pattern, in other words.

[mattgarrish]

But I should add that if reading systems are intercepting clicks and opening the pop-ups without modifying the underlying markup, then all bets are off about the accessibility. Not sure what the effect would be, as it would probably be RS and platform-dependent.

[mattgarrish]

I'm going to close this issue now, though, as I don't believe it is still relevant, at least not in the context of what we were discussing around web publications.

Any answer about suitability will have to revolve around what UI functionality is intended to be implemented and whether the roles being used are for accessibility or just UI hooks.