(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.

[ell1e]

There was a solution suggested on the w3c tracker, which is using role=separator on some otherwise unrelated element.

I wonder, wouldn't something like <scene-break style="display:block; height:1em;" role=separator>&#160;</scene-break> dodge most issues? It isn't hidden via styling and hence shouldn't be skipped by anything, it's not an empty paragraph <p>&nbsp;</p> that seems to be skipped by some visual e-book readers, it doesn't rely on visual effects some e-book readers may not implement thinking that it's too advanced to be used in e-books, and for a human reader of the actual markup source it's pretty clear what this is meant to be (which I also think is an important quality).

If I'm not missing something here, perhaps it would be worth adding this approach to the context break page.

I am now test-running this exact HTML with my EPUB export, the reader I tested so far displays it correctly:

Style section:

scene-break {display:block; height:1em;}

Text body section:

<scene-break role="separator" class="indent">&#160;</scene-break>

[mattgarrish]

Sure, that's just an autonomous custom element with an ARIA role on it. It's the generally same as if you'd put the role on a generic element like div; custom elements just come with no default styling or properties if you don't initialize them to inherit from another html element class using javascript.

I'm not sure if custom elements cause any issues in epubs as they haven't been used a lot so we haven't tested them. I'd have to do some checking to see if assistive technologies correctly announce the attached roles, for example.

In any case, documenting custom elements really belongs in a different section of the knowledge base. Once we introduce custom element names then the usage possibilities multiply for different cases and different languages. But I'll leave this issue open as a reminder to take a deeper look at this.

[ell1e]

In any case, documenting custom elements really belongs in a different section of the knowledge base

Can you elaborate why?

My suggestion is that the page on scene breaks should start with an example that both makes semantic sense and is expected to work. This doesn't seem to be the case for the first example, given another page of the wiki says width:0 elements may be read out, as in might be skipped. That seems to be in part due to the inherent dispute if a hidden element should be read or not, and therefore not something that looks like it's going to be solved (correct me if I'm wrong). What I'm trying to do is find and provide an example that is expected to work everywhere and also keep working.

My apologies if this is misguided.

[mattgarrish]

Autonomous custom elements are just made up tag names. It makes sense to you as the author of the tag, but it doesn't add any accessibility and isn't necessarily the name that anyone else will want to use, certainly if they're not native English speakers. The focus of the knowledge base is on using the predefined html tags to make content accessible. It doesn't mean you can't roll your own solution, but documenting everyone's solutions is not in scope of what we're doing. You can put role="separator" on p, div, span, img, or any other element that accepts any role and they'll all do exactly the same thing as the element name you've proposed.

Explaining the nature of custom elements and how to make them accessible also goes beyond context breaks, so introducing them on that page just brings them into the site without context. That can lead to people mistakenly believing that if they just use names that sound semantic somehow it will improve the accessibility when in fact it can lead back to the dark days of ebooks when authoring programs output everything as stylized paragraphs.

ARIA should be the last resort for making content accessible. The hr element was designed for context breaks and benefits from not relying on aria roles to give it meaning which is why html elements are always preferred and why the site focuses on them first.

What assistive technologies have you found it problematic to use with when setting a zero width?

[ell1e]

What assistive technologies have you found it problematic to use with when setting a zero width?

The wiki itself suggests they can't be relied upon, here: https://kb.daisy.org/publishing/docs/html/hidden.html "Zero height and width [...] AT behavior: Text may be read".

I have no preference for custom element or not. However, hr seems as per above inherently unreliable and also kind of semantically questionable, since it seems to me like there is a fundamental disagreement what zero height and width should mean for a screen reader in regards to whether it should read it out or not.

Hence I'm suggesting alternatives that both make semantic sense and might be more reliable. The variant with a div role=separator comes directly from the w3c bug tracker to avoid above problem. However, I felt like it would makes less semantic sense than either hr or a named custom element to a reader, since div isn't related to context breaks with its usual usage. Therefore my custom element suggestion. The naming is in English, since that seems to be how all elements are named in HTML.

I don't really care if it's a custom element or not.

My apologies if this is really just an issue that I'm seeing, and nobody else is.