Epub Accessibility - Changes for Sigil?

[KevinH]

And since individual semantics like rearnote, footnote, endnote, *ref are not true Landmarks, we should design an easy way to just add structural epub:type attributes to individual non-Landmark level tags.

I am thinking of an extra clips-like bar that is pre-filled in with these attribute strings (and not user editable) that could add these non-Landmark/Guide level individual attributes to the current cursor location in CV.

Perhaps we could extend that interface to add aria-roles in a similar way?

Of course a user could use his/her own clips bar for that but a dedicated single-click one might be nicer.

This would only be to add the additional epub 3.3 structual semantics that are not Guide/Landmark level but instead are meant to indicate a role for an individual tag.

Thoughts anyone?

[DNSB]

Sounds like a good idea. A single icon wouldn't take up that much space and would save me quite a few clips I've added. Please include the aria-roles.

[Doitsu]

Originally Posted by KevinH

I am thinking of an extra clips-like bar that is pre-filled in with these attribute strings (and not user editable) that could add these non-Landmark/Guide level individual attributes to the current cursor location in CV.

Perhaps we could extend that interface to add aria-roles in a similar way?

I like the idea.

Maybe you could do an informal survey among Sigil users and ask which epub:type attributes and ARIA roles they most frequently use?

I'd recommend at a bare minimum the following epub:type/ARIA role values:

footnote / doc-footnote
endnote / doc-endnote
page-break / doc-pagebreak

Maybe you could also add an epub3 accessibility preference setting that'll automatically add the corresponding ARIA role whenever an epub:type attribute is added via the new clip-like bar.

[BeckyEbook]

Well, epub 3.3 structural semantics is much more developed.
Of course, the "main" semantics settings (sectioning content) can remain, but all these settings for section, aside, etc. require a completely new approach. New clips bar for new semantics and aria-roles is a good idea. Those who are not interested do not even have to display it, and it can also be hidden by default.
If these new clips are smart enough to properly insert/replace epub:type and aria-roles, that would be great.

So my patch is like the last addition to the old type of semantics.

[KevinH]

I don't understand why on earth they make epub:type roles that duplicate aria-roles at all. epub:type requires a epub prefix namespace while aria-roles are built in. I wonder how many reading accessibilty screen readers grok aria-roles and how many grok epub:type attributes. My guess is aria-roles are much more often used and accepted.

[KevinH]

And does it really help Accessibility screen readers when both attributes are used at the same time?

Does anyone know?

[KevinH]

The clips approach means a straight forward string insertion so the user would have to manually remove any attributes that were old or conflicted in some way. Just like our normal clips. Something smarter would need to keep and parse all existing attributes and see if any conflict which is not straight forward. Not like checkboxes.

[philja]

Originally Posted by KevinH

The clips approach means a straight forward string insertion so the user would have to manually remove any attributes that were old or conflicted in some way. Just like our normal clips. Something smarter would need to keep and parse all existing attributes and see if any conflict which is not straight forward. Not like checkboxes.

Accessibility issues are becoming increasingly important in some marketplaces. It was when I was experimenting with adding various aria-roles manually that I noticed in build 2.5.1 that PV was not displaying the error messages I expected to see when tag pairs were not yet completed.

Anything that would automate the job of adding those roles in Sigil would be welcomed.

[KevinH]

The aria spec is truly horribly written, Its main focus seems to to make web user interfaces, forms, and user input controls interpretable. But outside of that why define innate roles for almost every tag but then say do not use them. The rules for applying those roles are just too arcane to be useful. And why define an innate role for a table or table row, etc at all. A typical spec designed and written by a committee without any thought for practical use.

So given all of that, and given an epub is not a web user interface in itself and is instead a publishing mechanism, I think Doitsu is rght here and we should collect a much shorter list of the most frequently used aria roles.

What I think is very strange given the "do not overspecify or duplicate" guidance all throughout the aria spec, is why there is a huge overlap between epub:type and aria digital publishing roles. Seems quite strange. Are both needed? If so that breaks the do not duplicate guidance in the aria spec.

So for those reading this, a shorter list of the aria-roles you actually use would prove to be useful.

Please attach a list in a response in this thread and I will collect and collate them to aid the design of the clips ui.

[KevinH]

Okay here is the single most important description I could find comparing epub:type to aria roles so I quoted it here:

It is important to understand the differences between the epub:type attribute [epub-3] and the role attribute [wai-aria] to ensure that they are properly applied for their intended purposes and audiences.

The biggest of these differences is in their primary applications. The epub:type attribute has evolved to aid publisher workflows. It has limited use enabling reading system behaviors outside of some core functionality of EPUB (identifying navigation elements and enhancing media overlay documents). Although it was hoped the attribute would also expose information to assistive technologies, in practice it does not.

The primary purpose of the role attribute, on the other hand, is to expose information to assistive technologies. It is not to facilitate user agent behaviors.

The result of these differences is that the application of epub:type semantics is largely harmless, but misapplication of ARIA roles can have negative impacts on the reading experience, from over-announcement of information to broken rendering for assistive technology users.

This guide addresses key authoring differences to be aware of when migrating to ARIA roles from the epub:type attribute, or when using both attributes together. The goal is to help publishers avoid the pitfalls of applying ARIA roles like they would epub:type semantics and breaking the reading experience for users of assistive technologies.

This quote was taken from here:

https://www.w3.org/TR/epub-aria-authoring-11/

So they hoped epub:type would be useful to assistive technologies but it turns out they are basically ignored.

The epub:type values were also designed to alert publishing and reading systems and to be used in the nav for Landmarks (similar to what guide elements did for epub2). In addition, epub:type values can be used by an e-reader to understand the nav and table of contents and to do things like make pop-up footnotes happen.

So epub:type value are typically assigned to file level as nav landmarks or individual elements like a single footnote.

The aria role is what current assistive technologies use but certain roles may only be applied to certain types of tags and are not typically file level. In fact aria-roles can never be assigned to a body tag. They can be assigned to section, div, span and more generic container tags. But the rules are complex. For example doc-footnote should not be applied to an item in a list such as an li tag inside a ul or ol tag. So you can label a section or div tag with a doc-footnotes role but if a list is used no individual doc-footnote role should be applied to individual footnotes in that list.

So adding roles to an epub3 is really good for assistive technologies but how exactly that is done needs to follow quite arcane rules.

The bottom line is we can make it easier to assign both epub:type attributes and aria roles but the latter needs to be done by the author very carefully to prevent harm from being done by assistive technologies overly announcing things or interfering with things.

The rules of when and where to assign aria roles is complex enough that a full table lookup had to be implemented in the Sigil Access-Aide plugin just to try to come to grips with it.

This is going to take some design thought. And whatever tool we end up using in CodeView must be context sensitive based of the current tag the cursor is in at the very least. But given its inheritance property, it may come need even more help.

Perhaps a more advanced Access-Aide plugin might be the way to go here. Or we just pass the buck to the epub dev person to know when if and where to attach aria roles and give them a clips menu and let them at it.

[KevinH]

It is interesting to note that the aria-roles were designed for websites with no table of contents, no Landmarks, no navigation aids, so very unlike an epub. So accessibility software can build its own navigation interface by parsing the aria-roles attached to sections, and div tags.

From what I can tell, very very few epub3's actually make use of the section tag as the file itself is typically a base unit of navigation with ids inside the file as destinations for links within and outside it.

If you read the epub type and aria roles documentation they want a typical accessible epub3 chapter file to be structured much like the following (if it has a single section):

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
  <title></title>
</head>

<body>
  <section epub:type="chapter" role="doc-chapter" aria-labelledby="loc-h1">
      <h1 id="loc-h1">Chapter 1: The Title for the Chapter</h1>
      <p></p>
      ...
  </section>
</body>
</html>

But I do not think I have ever seen that in an actual epub in the wild. And for what it is worth those section tags did not exist back in the epub2 era so I am not sure if that set of tags would be properly parsed by older epub2 e-readers. That said I did find this under xhtml and aria that might work with epub2 but that would need to be validated:

<!-- For example, if you are using XHTML 1.1 directly, use the public
     identifier in the DOCTYPE declaration, with the namespace declaration
     on the document element to identify the default namespace: -->

       <?xml version="1.0"?>
       <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN"
                             "http://www.w3.org/MarkUp/DTD/xhtml-aria-1.dtd">
       <html xmlns="http://www.w3.org/1999/xhtml"
             xml:lang="en">
       ...
       </html>

Update: Tried variations of the above but epubcheck rejected it and rejected the section tag as well. So using aria roles and section tags means no backwards compatibility from epub3 to epub2.

Col: 57: ERROR(HTM-004): Irregular DOCTYPE: found "-//W3C//DTD XHTML+ARIA 1.0//EN", expected "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">".

Does anyone create or see epub3 structures with section tags like this? It would make backwards compatible epub3s with epub2 more difficult if not impossible. In a website with no OPF and no nav TOC and Landmarks that every epub generates, some tag would be needed to create an outline toc from (and they do not seem to use the h1-h6 tags for that).

Is this something Sigil should be supporting. Maybe by user preference to make an empty epub3 file structure with the section tags with build in h1-h6 tags with a aria-labelledby linking them?

Of course anyone could create this structure on their own but it appears that the section tag is heavily used/needed for many digital publishing aria roles.

Thoughts?

[KevinH]

Thinking more about this, creating the following clip with the name "section" is an easy way to create sections without having to change the default empty epub:

Simply highlight everything between the opening and closing body tags (not the tags themselves) and hit the section clip button (that a user could create right now)

<section epub:type="" role="" aria-labelledby="">\n\1\n</section>

And then you would have to fill in the epub-type, the aria role and of course the id of any heading associated with it in the provided attributes.

That should speed things up without changing the default empty epub3 xhtml file. And is something very simple that can be done now.

Thoughts?

[Doitsu]

Originally Posted by KevinH

Thinking more about this, creating the following clip with the name "section" is an easy way to create sections without having to change the default empty epub:

IMHO, it might be easier if you simply added the following elements to the [h*] tool bar button:

section Chapter <section class="chapter" epub:type="chapter" role="doc-chapter">\1</section>
a Note ref. <a epub:type="noteref" role="doc-noteref">\1</a>
aside Footnote <aside epub:type="footnote" role="doc-footnote">\1</aside>

This will cover the most freqently used epub:type/role attributes.
Since new Sigil users might not know that these tags/attributes can only be used in epub3 books, they should only be shown if the current book is an epub3 book.

Speaking of the [h*] button, it would be helpful if Sigil remembered the last selection. For example, if a user wants to mark several phrases as paragraphs, each time they'll have to select <p> from the list.
If the button remembered the last selection, a user could select <p> from the tag list once and re-apply it without having to select it again from the tag list button.

[KevinH]

Hi Doitsu,
Thanks. That is a definite possibility.

But how would this be different from a clips bar that is dedicated to doing the same thing? No pulldown in needed then at all, and all are available to be clicked at any time so no "memory" is needed.

And does anyone use the aria-labelledby approach and place an id on the h1 tag it encloses?
And why hardcode a class name like "chapter" at all?

Making the [h*] button remember its last state is a good idea I will look into. But I do not like the idea of it changing its function for epub2 and epub3 given the tool bar itself works on all epub types now.

Perhaps a new top-level menu called "Add Accessibility" that could easily be made context sensitive and only be shown under epub3? Or perhaps make an epub3 menubar that removes all epub3 specific tools from the Tools menu and Accessibility becomes an entry under it.

The user can decide to show or not show an Accessibility clips bar, so maybe that is the way to go.

One issue with menus and toolbars being context sensitive is the multiple main window approach used in Sigil on macOS in which a user may be editing an epub2 and an epub3 simultaneously.

Lots to think about!

Thanks for sharing your recs and thoughts!

[KevinH]

I know that epubcheck for epub2 barfs on section tags and aria role attributes and probably even epub:type attributes but that is a ns add-on). But has anyone tried an epub3 with section tags, and aria-roles on an older ADE 1 or 2 style epub2-only e-reader. Does it still display just fine if provided with a ncx and guide?

Does a screen reader based assistive technology work on old ADE desktop e-readers?