There's a new sheriff in town …

[KevinH]

Yes, I can make it an option. I should have added prefs support to ePub3-itizer anyway. Can anyone point me at a mapping of epub:type to these aria roles? Or even a site that describes the most common roles. If so perhaps an "add aria role" (think similar to set semantics) should be added to Sigil for epub3 only.

[Doitsu]

Originally Posted by KevinH

Can anyone point me at a mapping of epub:type to these aria roles?

Here you go:

EPUB Structural Semantics to ARIA Roles Mapping Guide

EPUB Type to ARIA Role Authoring Guide

[KevinH]

Thanks for those links. All of the items labelled draft are a real pain. The IDPF can't seem to get out of there own way.

My thoughts for epub3-itizer are:

1. default to including the accessibility features but controllable with pref setting

2. disable their inclusion if more than one dc:language field is provided in the opf to prevent incorrect xml:lang and lang tags from being created.

3. disable their inclusion if an audio or video resource is present in the opf since that would invalidate the extra metadata. Or is there special metadata entries for these cases?

4. disable their inclusion if mathml tags are found (is this needed? Can text readers grok mathml?)

5. if enabled, use first ncx/nav entry for each xhtml file that links to top of page (no #id used in link) to fill in title tag for head in each page. Leave blank if no top of page link exists in the ncx/nav

6. if enabled, add in the needed metadata as provided above.

That way, the accessibility features will only be added under basic operation forcing them to be hand added if something special is needed to prevent incorrect code from being added.

What do you think?

KevinH

[Doitsu]

Originally Posted by KevinH

3. disable their inclusion if an audio or video resource is present in the opf since that would invalidate the extra metadata. Or is there special metadata entries for these cases?

There are special tags, but I don't know if all screen readers support them.

Originally Posted by KevinH

4. disable their inclusion if mathml tags are found (is this needed? Can text readers grok mathml?)

There is also a special aria attribute to describe MathML, but I don't know if all screen readers support it. Also the existing epub 3.0.1 standard requires an epub:switch element while the epub 3.1 standard removed this element.

IMHO, default accessibility attributes/metadata entries should only be added if a book doesn't contain JavaScript, MathML or multimedia files.

(I agree with all your other suggestions.)

[DaleDe]

I have built an Ace page in the wiki and am starting to collect accessibility features there.

Dale

[KevinH]

There one other option, instead of adding this to Sigil's ePub3-itizer plugin for converting epub2 to epub3, we could instead create a BasicAccessability plugin that only runs on epub3 and try to add in the features above no matter what. Perhaps even present a thumbnail for each image and an associated label field to enter or edit the alt attribute. If multiple language tags exist, it could also provide a table for the primary language for each chapter so that the proper html lang and xml:lang attributes can be entered.

By making it its own plugin, it could be run on any existing epub3 and therefore add general value in itself, and not rely on epub3-itizer.

Would this be better?

KevinH

[jcsalomon]

Much better.

Should it integrate the ACE checker, or should that be yet another plugin?

[Doitsu]

Originally Posted by jcsalomon

Should it integrate the ACE checker, or should that be yet another plugin?

IMHO, it'd be better if the ACE checker would be a separate plugin.
Just running ACE checker and displaying the messages in a Web Browers would take only a couple of lines of code. However, since the ACE report doesn't use line and column numbers, it might be a bit tricky to reformat the output for use with Sigil. Also during my tests, ACE checker often crashed for no particular reason. Maybe we should wait until ACE checker is more stable.
Moreover, there doesn't seem to be much interest in accessibility tools....

@KevinH: It appears that ACE checker uses epubcfi to refer to locations in the epub. Does Sigil/Gumbo support epubcfi?

[JSWolf]

The problem will come if the IDPF makes the next version of ePub not backwards compatible enough and if publishers take to it. That will not be a good.

[DaleDe]

Originally Posted by KevinH

There one other option, instead of adding this to Sigil's ePub3-itizer plugin for converting epub2 to epub3, we could instead create a BasicAccessability plugin that only runs on epub3 and try to add in the features above no matter what. Perhaps even present a thumbnail for each image and an associated label field to enter or edit the alt attribute. If multiple language tags exist, it could also provide a table for the primary language for each chapter so that the proper html lang and xml:lang attributes can be entered.

By making it its own plugin, it could be run on any existing epub3 and therefore add general value in itself, and not rely on epub3-itizer.

Would this be better?

KevinH

This would be better. Many of the changes can also apply to ePub 2 as well so there is no reason not to use it on them as well.

Dale

[KevinH]

Hi Doitsu,
No, Sigil does not support epubcfi. IMO the epubcfi spec is yet another standard that seems to be overdone and not particularly useful especially in an epub that is being actively edited. It also depends strongly on how the dom deals with text, as a separate node or not. For example dom trees built by BS4 and gumbo differ in that regard. You can work around it but it is a pain since text nodes are not counted until the end.

In a final epub after all changes have been made, epubcfi can be useful to identify locations on the page that do not have an "id" attribute to indicate the destination. That said, node order strings including siblings and children accomplishes the same thing and is much easier to implement and understand.

As far as I can tell epubcfi's role in epub3.1 has been greatly reduced in comparison to epub 3 with its role in the opf using relative positions removed. It might be useful in a Reader, but is not particularly useful in an editor with constantly changing nodes.

Kevin

Originally Posted by Doitsu

IMHO, it'd be better if the ACE checker would be a separate plugin.
Just running ACE checker and displaying the messages in a Web Browers would take only a couple of lines of code. However, since the ACE report doesn't use line and column numbers, it might be a bit tricky to reformat the output for use with Sigil. Also during my tests, ACE checker often crashed for no particular reason. Maybe we should wait until ACE checker is more stable.
Moreover, there doesn't seem to be much interest in accessibility tools....

@KevinH: It appears that ACE checker uses epubcfi to refer to locations in the epub. Does Sigil/Gumbo support epubcfi?

[elibrarian]

I got quite overwhelmed by the reaction on my first post (just asked if anyone knew a tool to implement accessibility to epubs, and wham! a lot of knowledgeable people began making it. You guys are amazing!

Anyway, I think Kevins suggestion of making it a standalone plugin is great, since that will leave anyone to his own decisions on using accessibility tagging or not. And of course it will be a great tool to update old epub3's with these tags too.

On another note, there's been some mentions on the IDPF future standards here and in other fora on MobileRead the last days. But since IDPF doesn't exist anymore, that won't happen. New ebook/epub groups are forming under W3C, but at present I find the W3Cs internet site(s) regarding epublisning rather confusiong, and can't see, in what direction they're going. (This is the subject for another thread, methinks, but have a look at the "obituary" on idpf.org).

Regards,

Kim

[KevinH]

For the future for epub4 see:
https://www.w3.org/TR/2018/WD-pwpub-20180104/

Please note epub4 breaks all backwards compatibility so it really just represents a packaged streamed set of web pages and apps



For epub3.2 or ePub 3.0.2 discussions:
https://docs.google.com/document/d/1...EY/mobilebasic

and

https://github.com/w3c/publ-epub-revision/issues/986

[KevinH]

Our only hope is to focus on epub3.2 But the discussion of it makes it seem like a rollback of 3.1 to 3.0. Sad but refines and switch and trigger are back. The original google doc proposal was much more reasonable but too many idiots are ruining it.

[elibrarian]

Originally Posted by KevinH

For the future for epub4 see:
https://www.w3.org/TR/2018/WD-pwpub-20180104/

Please note epub4 breaks all backwards compatibility so it really just represents a packaged streamed set of web pages and apps

For epub3.2 or ePub 3.0.2 discussions:
https://docs.google.com/document/d/1...EY/mobilebasic

and

https://github.com/w3c/publ-epub-revision/issues/986

Thanks for those. I like the 3.2/3.0.2. goal - sort of making a 3.0 compatible version 3.1. - but the W3C "wpub" or epub 4.0 proposition really makes me want to find a suitable wall to bang my head into

Regards,

Kim