Apparently, there's a need for an invisible but semantically meaningful <hr> variant

[ell1e]

Please let me know in which w3c repository to move this issue if this is a bad place. I'd like to talk about an accessibility problem with current HTML markup regarding digital literature. I came across this while programming my own EPUB export functionality.

Problem

EPUB is an e-book standard based on HTML and CSS. It seems to be the most widely adopted standard for digital literature, and therefore reaching a wide range of audiences even outside of the typical techie users.

Apparently, there's a need for an invisible but semantically meaningful <hr> variant for ebook publishing. All e-books I have test opened don't annotate a scene break in a way that screen readers understand. Scene breaks separate two separate sections in a fiction novel, commonly to indicate a time gap and a potential change in location, time, cast, and even point of view character, but without starting a new chapter.

(In non-fiction documents, like this GitHub issue, I don't think they're used as commonly and instead a new subsection will have a new separate headline to clearly indicate that a new topic is being discussed.)

Problem example in the wild

Here is an example of a scene break:

The common industry standard to do this seems to be the following markup:

<p>Anna stared at them as they left, and Isla grinned.</p>
<!-- The new scene starts here. -->
<p class="first-after-scene-break"><b>Addison.</b> Addison leaped across the campus...</p>

And then a CSS rule will be specified for the class first-after-scene-break to add a top margin before that paragraph.

This apparently isn't picked up or understood by screen readers as a scene break, which is bound to lead to major reader confusion.

Why alternate solutions available so far don't seem to work

You might see when studying the EPUB Accessibility Publishing Knowledge Base that HTML/CSS doesn't seem to currently fulfill this need, with the following issues apparently being present as discussed in the downstream issue:

1. A basic <hr> works semantically and seems to serve a similar purpose, but from my own experience poses problems with the typography. It's simply the case that almost no fiction novel ever draws a visible line between scenes.

   Not only is this an aesthetic problem, but it would potentially confuse readers that rely on the visual representation to match what they're expecting. That in itself would be kind of an accessibility problem.

2. One suggested workaround is an equivalent to <hr style="width:0px; margin-top:0.5em; margin-bottom:0.5em; margin-left:0px; margin-right:0px;">. The problem here seems to be that automated software like screen readers or also search engine web crawlers etc. will apparently sometimes assume, and in my opinion that's not too far-fetched, that a hidden element is also intended to be semantically ignored.

   This means that the aesthetic and visual representation needs would be met, but screen readers might again skip over the scene break, making the scene unintelligible to readers with accessibility needs.

   Also see here, regarding zero width: it says "text may be read", which is a problem. The reason here is likely that it's not semantically clear if an element hidden in that way should be treated as being presented to the user or not.

3. Another suggested workaround is <hr style="opacity: 0;"> but apparently this has inconsistent reading system support. This in my opinion kind of makes sense since e-books are often read on e-book readers that often use e-paper with high visual latency and very low spec hardware. As a result, often advanced effects like transparency, javascript, transformations, and so on might be left out in the software, since any advanced visual effects may not be successfully handled or displayed as intended anyway. This seems like a reasonable trade-off if you ask me.

Possible solutions

I can think of two ways to address this in the long term, but I'm sure other people here will have better ideas:

1. Introduce a new element, like I don't know, <ihr> for "invisible hr", or whatever the name might be. This is also useful for web pages and not just e-books, where paragraph breaks might be used inside a document as well. If anything, it could be useful for showing common fiction book preview excerpts on a web page.

2. One way could be a generic CSS rule alternative to display:none that both maintains the space and semantic meaning, but doesn't rely on supporting any more advanced transparency or fading effects commonly not present in e-book reading systems.

   I'm not sure this makes much sense however, since I can't think of any other element where the presence of its mere empty boundaries, it would still have as much of a semantic meaning as an "invisible hr". Like, what logical intention would a hidden-but-semantically-meaningful <div> really express? But perhaps if there are other examples of this that make sense, this could be a good idea.

I would love to hear other ideas. My apologies if I presented this issue poorly or in the wrong space.

[scottaohara]

converted to a discussion because this is not an issue with wcag.

this sounds like an opacity 0 or .001 hr element would suffice. or some other style to visually hide the hr in a way that it will still be programmatically available in the accessibility tree. or, wrapping scenes in an element that allows for an accessible name, like an article, or element region or group role so that the boundaries of the start/end can be programmatically exposed.

you could even forego using the hr element all together if default UA styling is an issue, and instead do div role=separator to get the same exposed role with zero default styling.

adding new elements to the HTML specification is not easy - particularly if what's being proposed is duplicative of available features where the only difference is style. since there are other ways to do this with CSS or ARIA, or other HTML / a11y mapping semantics that can provide a similar outcome (ie the named container role semantics i was mentioning), those are probably your best bet.

[ell1e]

As mentioned before, due to the black and white nature and the low CPU specs of such devices, opacity and other such visual effects are often not implemented by e-book readers. I wonder, is <div role=separator></div> something that screen readers actually support in practice?

But that seems like kind of an ugly solution from a semantic angle, since it doesn't seem like that would allow using an element that makes sense. I suppose something like <scene-break style="display:block; height:1em;" role=separator></scene-break> would work, but it seems a bit unfortunate no native element works here.

I don't think the difference is merely style, but rather that any style that hides it is commonly misinterpreted by screen readers as intent not to read the element. Therefore, I think there is a conceptual problem here of what the intent of styling regarding visibility is. Adding something like <ihr> would work around that.

[ell1e]

Can confirm from first tests that <scene-break style="display:block; height:1em;" role=separator></scene-break> seems to work. Will continue testing e-readers to get a better idea of device support.

[scottaohara]

I wonder, is <div role=separator></div> something that screen readers actually support in practice?

it's rather well supported being an ARIA 1.0 role. it's the implicit role of the hr element.

But that seems like kind of an ugly solution from a semantic angle, since it doesn't seem like that would allow using an element that makes sense.

by that logic all use of ARIA is ugly, though it can be used to achieve the exact outcome you are looking for. It is a practical solution. As are all the roles added to the child d-pub ARIA spec specifically because epubishers wanted additional role semantics beyond what html and aria provide.

I don't think the difference is merely style, but rather that any style that hides it is commonly misinterpreted by screen readers as intent not to read the element. Therefore, I think there is a conceptual problem here of what the intent of styling regarding visibility is. Adding something like <ihr> would work around that.

it's fine if you don't agree with that stance, but the reality is that it is the general stance that HTML has to adding new elements. the issue you're describing of a device not being able to appropriately handle hr style=opacity:0 would be seen as a gap in that device - not a gap in HTML or CSS. For instance, in recent efforts to try and add a new customizable <selectmenu> element to HTML, it was rejected because <select> already exists - adding a separate element for styling purposes was a non-starter. So, instead work shifted to update the spec/browsers in a way so that the existing <select> element had more features and could be styled by web developers. That has now been released in chrome/edge and is planned for implementation with firefox and safari.

ihr would similarly be rejected. It's really not an idea worth pursuing when there are other avenues to achieve exactly what you're looking for - or per my prior response - if you were to go the container element route, you would get start/end boundaries to a scene without needing an element at all.

<section aria-label="scene 1">
  <!-- optionally with role=group instead if a region isn't what you'd want here
         either would allow screen readers the possibility of announcing when someone
         has entered the 'scene' or hits the end/leaves the 'scene' 
  ...
</section>
<section aria-label="scene 2">
  ...
</section>

maybe even dpub's doc-part or doc-chapter roles might be appropriate for this purpose - depending on their implementation support in the devices you need to target.

[ell1e]

the issue you're describing of a device not being able to appropriately handle hr style=opacity:0 would be seen as a gap in that device

I get that, but it's I assume also not clear that a screen reader wouldn't be meant to skip an element with opacity:0, for the same reason an element with width:0 is skipped.

I like the section variant. I'll investigate if that has device support in terms of not causing any pagination issues. Thanks so much for all the neat suggestions!