Epub Accessibility - Changes for Sigil?

[Doitsu]

Originally Posted by KevinH

And why hardcode a class name like "chapter" at all?

I took this from an actual book and forgot to delete the class attribute.

Originally Posted by KevinH

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?

When I last tested epub3 books with epub:type/role attributes, they displayed fine with ADE 2.0.1. However, there's no guarantee that older RMSDK based eink devices won't choke on those files.
Maybe other Sigil users have some older eink devices in their drawer and can test this.

[KevinH]

One of the issues we face for a gui interface is there is at a rough count approximately 40 aria doc-* roles. We can hardly create a pulldown menu with 40 or more options, and a separate clip of 40 icons would be needed if we go the clips approach.

So to make them all easily accessible we would need to categorize them into 4 or 5 common groupings with 8 to 10 menu items per group menu.

We could still create a most-often used clips bar for easier/faster access.

It is something to think about at least.

[DNSB]

I've tested on an ePub2 (ADE 2.0.1) renderer and it does what it should do with unknown elements and disregards them. Now if Adobe had extended that to errors in the stylesheet.

The few clips I currently use for epub:type, role, aria-labelledby mostly do blocks of related elements. Much like your example in message #12 but with the types filled in.

[JSWolf]

Originally Posted by DNSB

I've tested on an ePub2 (ADE 2.0.1) renderer and it does what it should do with unknown elements and disregards them. Now if Adobe had extended that to errors in the stylesheet.

The few clips I currently use for epub:type, role, aria-labelledby mostly do blocks of related elements. Much like your example in message #12 but with the types filled in.

I've also tested an ePub3 with ADE 2.0.1 and it works. Here's a sample of some of the code.

<section aria-labelledby="ch01_hd" role="doc-chapter">
<span aria-label="7" id="page_7" role="doc-pagebreak"/>
<h1 class="h1ch" id="ch01_hd">ONE</h1>
<p class="ahead1"><i>Starship Enterprise</i> <span class="f1">Federation–Klingon Border</span></p>
<p class="noindent">“Get your sorry ass in gear, Lieutenant.”</p>
<p class="indent">Erica Ortegas stared at the ceiling in her quarters as she gave herself the order, briefly

What I wish ADE 2.0.1 handled was uppercase and small-caps.

[KevinH]

Hi All,

To make thigns clearer, I coded up a proof of concept. Nothing is final but I would like people's thoughts.

Here is a sequence of screenshots:

1. initial_xhtml.png shows a blank xhtml epub3 page
2. I highlight the contents of the body tag and then use the "section" tag on my clips bar.
3. It add in the section and then I place my cursor in it and use the Insert menu and select Role...
4. It pops up a full menu of possible Aria Roles and their official descriptions for the user to select from
5. The resulting xhtml screenshot shows it properly added the aria role and any mapped epub:types to the current tag.

Old values of either attributes are replaced. The destination tag is first checked to see if the Aria Role you selected can be used on a tag of that type, and warns you if otherwise.

This provides the full interface for all Aria Publishing roles and forces them to be only used on correct tags. It adds any epub:type that corresponds with it, and properly handles the updating of old attributes or creation of new ones. It also registers the Insert Role menu so that it can be assigned a keyboard shortcut.

This is a time consuming given the almost 40 different Aria publishing roles, but as many have said, users can sidestep this process using their own clips for their most frequently used structures with roles that fill in all the pieces.

I still have to figure out how to disable or grey these menu items out when editing an epub2 but if people like the following approach I will work on that.

1. clips for most often used roles and their associated structures
2. an insert menu that gives you access to all roles and provides descriptions of each role and that check for proper destination tag.

If anyyone wants to play with this proof of concept I have pushed it to my personal repo so it can be cloned from:

https://github.com/kevinhendricks/Sigil.git


I also have attached screenshots.

Any feedback or thoughts welcome.

[Doitsu]

Originally Posted by KevinH

To make things clearer, I coded up a proof of concept. Nothing is final but I would like people's thoughts.

I really like the concept. A similar context menu item for epub:type attributes would also be very helpful.

[BeckyEbook]

I like it too!

Small issue for <hr/>: <hr/ role="doc-pagebreak" epub:type="pagebreak">

Great request: showing in the window only those roles that can be applied to the current tag. Unless it is very tedious.

[KevinH]

Thanks for the feedback!

I will need to fix how attributes are auto added to single/void tags. This is an existing bug as the routine I used should have handled that.

I really hate to duplicate the entire thing for epub:type as the degree of overlap is huge. The only real differences is epub:type allows footnotes, and endnote, and biblioentry while
aria adds example.

There are no real restrictions on which tags you can use epub:type on nothing as enforced as far as I can tell.

So perhaps we change Insert "Role..." to Insert "Semantics ..."

Then add in the overlap codes but properly applying them as either epub:type alone, role alone or both as allowed and expanding the descriptions to note when exceptions happen.

How does that sound?

[KevinH]

Originally Posted by BeckyEbook

Great request: showing in the window only those roles that can be applied to the current tag. Unless it is very tedious.

It is doable. It would require me to not reuse the existing AddSemantics dialog we now use for Guide and Landmarks, and instead pass in the current tag to a variation of it that filters based on allowable tags.

Let me think about it.

[KevinH]

Looking again at the very latest epub 3 epub:type Semantics vocabulary guide from March 2025, they have introduced lists of allowable tags for epub:types which of course includes the body tag itself which directly conflicts with all the aria roles.

I understand epub:types for Nav landmarks, and footnote and endnote and their backlinks, but outside those areas epub:type attributes are *not* used by e-reading systems and are *not* used for accessibility software as clearly and brutally stated by the Daisy Knowledgebase website.

https://kb.daisy.org/publishing/docs...epub-type.html

Given that, do we want to add another full dialog and code class, and menu item just to insert them if no one is using them? Many of them are epub dictionary specific, and index specific but are not being used at all.

Thoughts?

Should I just merge endnote, footnotes, and bibliography entry into the roles but mark clearly they are epub:type only in the descriptions?

Or should we create a second menu item, class, and Dialog to insert the majority of the available epub:types from the vocab doc like the proof of concept did for aria publishing roles?

[DNSB]

I would like the epub:type bits and bobs but on that proverbial other hand, I seldom use them other than for footnotes/endnotes. So far the role item in Sigil seems to working for me.

[KevinH]

Thanks for your input.

That Daisy knowledgebase article on epub:type is literally scathing, and does not even credit its use in nav landmarks!

Obviously not written by a fan of epub:type.

Maybe we start with a slightly expanded Insert Roles to cover the common footnote, endnote, etc and maybe later on expand things to a full blown epub:type class, dialog, and menu if users think that would helpful.

[Doitsu]

Originally Posted by KevinH

I understand epub:types for Nav landmarks, and footnote and endnote and their backlinks, but outside those areas epub:type attributes are *not* used by e-reading systems and are *not* used for accessibility software as clearly and brutally stated by the Daisy Knowledgebase website.

Even though they are not used for accessibility, it'd be a nice-to-have feature to have Sigil also add an epub:type attribute whenever an ARIA role is selected that has an epub:type equivalent.
I.e., keep the original prototype idea for the ARIA role right-click menu but also silently add/update the corresponding epub:type attribute.
You could then document in the user guide that adding an ARIA role will also add/update the corresponding epub:type attribute if one exists.

[KevinH]

Originally Posted by Doitsu

Even though they are not used for accessibility, it'd be a nice-to-have feature to have Sigil also add an epub:type attribute whenever an ARIA role is selected that has an epub:type equivalent.
I.e., keep the original prototype idea for the ARIA role right-click menu but also silently add/update the corresponding epub:type attribute.
You could then document in the user guide that adding an ARIA role will also add/update the corresponding epub:type attribute if one exists.

That is exactly what the proof of concept code does now. But there are a few epub:type values like a footnotes section, an endnote, and a bibliography entry, that do not exist in Aria roles (or are deprecated) but might be useful or needed.

Those are the ones I would like to add to the Insert Roles dialog (marked as epub type only).

So people would have to use only one menu in Sigil to add Accessibility and epub:types in one go where possible.

[KevinH]

Okay, I have just pushed version 2 of this to master on my own personal repo.

It adds a few key epub:type only codes that might be useful for bibliography, footnotes, and endnotes.

Second it add its own AddRoles dialog, that looks at your current tag and only shows you Roles that are valid for that tag as requested by BeckyEbook

I have also fixed adding attributes to single (void) tags in both this version and in Sigil master since the bug was in both.

Any thoughts and feedback on this would be helpful.

On my todo list would be to add a new clips specific to aria roles that might be used frequently (such as a section with chapter role, aside footnote, with backlink a tag, endnote ditto, etc). But for that matter with the extra clips we have now, perhaps we just let that up to the user.

Things to consider.

Any feedback welcomed!