(Perhaps the wrong issue tracker here, feel free to suggest where I should put this) Scene breaks seem inherently inaccessible in all EPUBs I opened

[ell1e]

I've noticed that scene breaks seem inherently inaccessible in all EPUBs I opened.

The problem seems to be that apparently XHTML allows omitting an empty paragraph, e.g. <p>&nbsp;</p>, so every single book where I've checked the source code does scene breaks like this: <p>This is the last paragraph of scene 1.</p><p class="some_obscure_style_that_forces_a_visual_break_via_padding_or_margin">This is the first paragraph of scene 2.</p> I assume that no screen reader available anywhere is going to figure out that this is actually a scene break.

There doesn't seem to be any semantic HTML element that I'm aware of to annotate a scene break in a semantically meaningful way. I wonder if the EPUB or HTML standardization bodies may need to be made aware of this, unless this is easy to do correctly and somehow just all EPUBs I opened and checked get this wrong. In that case I apologize.

[mattgarrish]

The hr element is a better fit for a scene break, but there's no way to semantically identify it as such. By default AT should announce the presence of the separator, but you could add an aria-label attribute with a description, though: <hr aria-label="scene break"/>.

Plays and poetry have been raised as issues before, but getting new tags or semantics is not an easy process. Publishers are generally left to use what is available and they're not always focused on what makes for optimal accessibility.

We cover the use of hr for context breaks in the knowledge base here: https://kb.daisy.org/publishing/docs/html/context.html

But the examples are pretty generic at the moment. Adding this use case as an example would be good.

[ell1e]

But the hr adds a giant line, which isn't how most books do scene breaks. And I imagine a display:none would remove the spacing again. And I wonder if any more complex CSS than that would potentially break in some readers... like, does the width: 0 reliably work? I guess I'll have to do some testing.

[mattgarrish]

width is usually supported but the issue that can arise with it is that AT may ignore zero width elements. The more effective way to hide the rule and still have the separator announced is to use clipping or opacity, but those are much more likely to not be supported by reading systems.

You could also set the background image use a blank image instead of asterisks like in the second example. If the image is transparent then user changes to reading background shouldn't affect the display.

[ell1e]

That sounds like perhaps there should be some proper element made for this so at least in the future this works properly.

[mattgarrish]

Getting new semantic elements in html is a challenge. You'd have to make a proposal to the WHATWG.

[ell1e]

that AT may ignore zero width element

Forgive my ignorance, what's AT referring to here? Some accessibility software?

Getting new semantic elements in html is a challenge. You'd have to make a proposal to the WHATWG.

It seems like that might be the best solution in the long term. Again forgive me for being super uninformed, but I wonder, couldn't the element be simply added to EPUB? And then some sort of "backport" to HTML could be optional later. I imagine getting it added to EPUB3+ would be easier and quicker to do, and then it would gain some more widespread practical real-world use that may convince WHATWG to add it to HTML later.

[mattgarrish]

Forgive my ignorance, what's AT referring to here?

Assistive technologies, like the jaws and nvda screen readers. They may skip announcing elements with zero widths or heights, so in that case any accessibility benefit of the tag is lost.

couldn't the element be simply added to EPUB? And then some sort of "backport" to HTML could be optional later.

No, unfortunately, changes have to go through the HTML folks before they become part of EPUB. The standards body that publishes EPUB would never let us do the reverse even if we wanted to.

[ell1e]

Hm I see. It seems to be that either a WHATWG proposal, or getting the screen readers not to ever drop a zero width hr tag in EPUBs, might be the way to go then. (Or both?)

I feel like the problem however is more that making an element have zero width/height and or 0% opacity has unclear semantic implications for a screen reader, even when the regular non-assistive renderer supports it. Perhaps the question is if there should be a more accessibility friendly hidden display variant, something like display: for-assistive-semantics-only instead of display:none. It might need a better name than that, though. I hope some of these ideas are useful to start a discussion what a good proposal could be.

[mattgarrish]

It's not definite that there will be a problem, and there's not necessarily a way to force the screen readers to announce things. Nothing says they shouldn't announce a zero width element; it's an optimization they've made because authors often hide content without thinking that it will still be announced by screen readers. In most cases, reading that hidden content not what's wanted.

But I tested the zero width method again with the latest versions of nvda and jaws and both announce that there is a separator. It would be good to reverify with VoiceOver, but if it announces the separator as well then the only potential problem would be reading system css support.