Possible additions to DPUB-ARIA 1.0

[mattgarrish]

Originally opened in https://github.com/w3c/dpub-aria-2.0/issues/1 :

Opening this issue to get feedback on desired additions.

(Copying follow-up comments below.)

[mattgarrish]

@mattgarrish responded:

As raised on the last call, one possible addition would be a role to identify the starting location so that users can bypass front matter and begin reading, similar to the epub:type bodymatter landmark in the navigation document.

The existing ARIA main role is used to bypass header/sidebar matter on a web page to get to the primary content. This is arguably not the same purpose, as each page can have a main section, and the whole book should technically be inside the main element on a single-page publication.

Front/body/back matter identifiers might be useful, but they are prone to abuse. Users undoubtedly would not want these semantics in every document, as there is no need to hear that every chapter is in the bodymatter, for example. They could also be misused to attach them to a section with a heading (e.g., role="bodymatter chapter") which would have bodymatter override the chapter role (only the first recognized role is exposed).

[mattgarrish]

@TzviyaSiegman replied:

one possible addition would be a role to identify the starting location so that users can bypass front matter and begin reading, similar to the epub:type bodymatter landmark in the navigation document.

@mattgarrish and @laudrain. If we model on the WAM, I wonder if start_url serves the same or similar purpose. I do not know how AT interacts with this.

[mattgarrish]

@mattgarrish replied:

If we model on the WAM, I wonder if start_url serves the same or similar purpose. I do not know how AT interacts with this.

Right, we need to see what happens with this, too.

A jump to bodymatter landmark is probably only useful in single-document publications. Unless it moves the user past all the frontmatter, it wouldn't serve any more of a purpose than the main role/element. The start_url potentially wouldn't be useful in this case, unless it accepts a fragid.

We also need to consider that chapters are landmarks, so a user can already find their way to the start of the body matter by simple progression through the landmarks until they reach the first chapter, something a specific role isn't going to speed up.

These are some of the reasons why we omitted the *matter semantics in 1.0.

[mattgarrish]

@laudrain replied:

@mattgarrish chapters are not always sufficient to inform where the content begins. I find it difficult to imagine that start of content would have to be found among a dozen or so of different values of role.
I thought that structural semantic information would be useful for a11y, and I understand that it is not the case for ARIA roles.

Would you mind to remind me of the reasons why *matter where omitted?

[mattgarrish]

@mattgarrish replied:

The landmarks are a list compiled from the source of the page, @laudrain. The user is not going to find the start of the content without having to search through them (getting a hotkey added to AT just for this would be a challenge). And given that most publications are split into pieces, it's not going to be useful except for single-page publications, as you won't find the starting point until you reach the document it's in anyway.

I've listed a number of reasons above why they are not very helpful semantics, but to recap:

• there's typically no heading associated with them, which either means they will be ignored by assistive technologies, or, worse, that users will misapply them and override more meaningful semantics to get them to validate.
• Writing BODYMATTER above every chapter heading would irritate sighted users, so why do it for users of AT, which is what you'll be doing if you add an explicit heading.
• as I mentioned at the start, the semantics are pretty useless when content is chunked since the positions cannot be determined from within any single file.

All that said, I don't disagree with you about finding a way to jump straight to where users will want to start reading, but I think we should be looking at mechanisms that are useful for all users (i.e., something baked into the format). ARIA roles are not the same as EPUB's landmarks, which were for reading systems to find useful locations. We may want something similar in the WPUB manifest, but we don't need ARIA to annotate the link relationships. Or we might be able to use start_url like Tzviya mentioned. I think this may be an issue for the WPUB manifest.

I also don't think *matter is the right way to go for identification as one publisher might want to jump the user to the bodymatter and another might just want to jump them to the start of the "readable" front matter.

Hope that helps clarify my position on this, but also cc'ing @GeorgeKerscher and @avneeshsingh to get their perspectives.

[mattgarrish]

@laudrain replied:

DAISY structure guidelines had elements for FrontMatter, BodyMatter and RearMatter http://www.daisy.org/z3986/structure/SG-DAISY3/part2-major.html
DAISY specs were so rich because DAISY books were played by specialized reading systems. Jumping directly to the main content is helpful to At users, but I am concerned about the user agents. We envision that WP would be read in browsers, and long list of publishing specific roles may not end up in browsers and screen readers.
So, if the same functionality can be achieved by some existing aria role, it would be more practical.

[mattgarrish]

@mattgarrish replied:

So, if the same functionality can be achieved by some existing aria role, it would be more practical.

We certainly don't have to mint roles for everything. These three could always be done using the group or region roles (region if it really needed to be a landmark):

<section role="group" aria-label="bodymatter">

But if this is done at the start of every document, I see it impeding readability not improving it as the label will still be announced.

[mattgarrish]

@laudrain replied:

And what about that kind of coding in today's EPUB3:

<body epub:type="bodymatter" role="group" aria-label="bodymatter">
     <section epub:type="chapter" role="doc-chapter">
...
   </section>
</body>

[mattgarrish]

@mattgarrish replied:

You can't redefine the body element with an ARIA role. It would have to be:

<body>
   <section  epub:type="bodymatter" role="group" aria-label="bodymatter">
     <section epub:type="chapter" role="doc-chapter">
...
   </section>
  </section>
</body>

[mattgarrish]

@laudrain replied:

You can't redefine the body element with an ARIA role.

Sorry to ask you that, but why ?

[mattgarrish]

@mattgarrish replied:

The body element already has the strong semantic role=document, and HTML rules do not allow it to be modified: https://www.w3.org/TR/html-aria/#body

Changing roles changes how the document gets compiled into the accessibility tree and exposed to users of AT. Overriding the document role could well break the whole page, although I expect that browsers would simply not expose the modified role, in which case it's like not having added it at all.

[mattgarrish]

@BillKasdorf replied:

This may be a dumb suggestion (feel free to say that!) but would it be at all worthwhile to look at DTBook to see if we have everything covered? Since that was created for accessibility it might be an indication of what elements were considered useful to identify for accessibility. And ideally we'd find that between native HTML semantics, ARIA, and DPUB-ARIA, we already have it all covered, or all but a small number of things. (Note: the problem with DTBook wasn't that it wasn't good, it was that it wasn't HTML.)

[mattgarrish]

@mattgarrish replied:

Not dumb at all, but maybe complicated as the most useful additions to DTBook tend, in my view, to address flaws in HTML markup (adding line markup and infinitely nestable sections, for example). We can't address those through roles.

But going over that element set with an eye to items that we didn't add to 1.0, the two that I think have some merit for consideration would be titlepage (coverpage in dtbook) and poem.

Someone brought up titlepage during the review of 1.0 as a means of jumping to where information about the publication is provided. I can see that being useful.

We've dodged poetry over the years to avoid getting sucked into modelling in HTML, but given how poetry is highly dependent on visual formatting, I keep thinking a high-level semantic that just identifies instances might be useful. In a book of poetry not so much, but when poems/lyrics/etc. are interspersed in the text I wonder if it would be helpful to know when the text is transitioning form?

[quasicomputational]

I wouldn't mind <dateline> being lifted from DAISY and generalised a bit, so that it can also cover, e.g., establishing time & location at the start for a chapter of fiction, as you might see in a stereotypical thriller novel. This would cover one of the last places where I'm unhappy with the options for semantic markup and having to resort to classes and hanging styling off them (with all of the opacity for non-visual media that that entails).