Calibre Accessibility Tool

[Lukusaukko]

I've been toying around with an idea for an accessibility tool that runs inside the Edit Book editor, does not depend on ACE (which is kind of annoying to install), and which would make it easier for non-savvy users to make their ebooks accessible, i.e. take away much of the need to know intimate details about landmarks, epub:types, aria, etc.

The existing tools tend to have two problems: they aren't very transparent at what they do and may do things they shouldn't: for example, a novice user may think that running Access Aide alone makes the book accessible, and AA also doesn't provide much input about what it actually did; ACE on the other hand is a mainly a reporting tool that doesn't really hook back into the editing flow easily, and which requires you to get quite intimate with the above-mentioned details.

The basic ideas are that first it should provide an easy way to jump into the location where the accessibility issue is and inform the user what the problem is and what could be done about it; secondly, for those issues that cannot be automatically fixed and need human review, it should provide an appropriate editing interface to manually resolve that issue (something Sigil's Access Aide does with image alt text). This should all happen within the Edit Books interface, and provide hooks to Calibre's diff so that the user can review what it did.

I have a basic prototype already in testing, but since I don't personally need accessibility features at least for now, it's basically a toy that I play around with - but if it's something that people might find useful and something that isn't already adequately served by existing tools, I might take it further.

[BetterRed]

@Lukusaukko - I moved your post to here because its more likely to be seen here by users who will have an opinion on the issues you raise.

BR

[DNSB]

How does the ouput from your proposed plugin for the calibre ebook-editor compare to the output from the Access-Aide plugin for Sigil?

[Lukusaukko]

Originally Posted by DNSB

How does the ouput from your proposed plugin for the calibre ebook-editor compare to the output from the Access-Aide plugin for Sigil?

Are we talking about the semantic code itself? In that case, it shouldn't be all that different - accessible semantics are pretty much set. Otherwise, in it's current proof-of-concept form, it produces a list of accessibility issues it discovers (a subset of ACE checks), and then lets the user click at the issue and jump to the spot; it also has some automatic fixes, such as adding missing language definitions and aria roles corresponding to their epub:types where those are missing. It then lets the user to view the standard Calibre diff to see what has changed.

One of the concepts in CAT is its semantic map editor, which allows the user to define parts of the document in terms of frontmatter, bodymatter, backmatter, and their roles (chapter, preface, etc.) - it can then use that information to create the semantic structure. It's still very basic, but the idea is that ultimately the user creates a semantic map of the document based on its contents, and CAT does the actual semantic tagging where it can automatically do so, and provides an interface to manually edit those parts that need human review (like image alt text or landmarks).

An example of the checker output:

Warning LANG-DOC-001 chapter01.html:2 The html element declares no language.
Pass HEAD-001 : No problems found by this check.
Pass ID-001 : No problems found by this check.
Pass IMG-001 : No problems found by this check.
Pass LINK-001 : No problems found by this check.
Pass PUB-LANG-001 : No problems found by this check.
Pass PUB-PARSE-001 : No problems found by this check.
Pass PUB-TITLE-001 : No problems found by this check.
Pass SEM-ARIA-001 : No problems found by this check.
Not applicable CONF-001 : No dcterms:conformsTo claim.
Not applicable PAGE-001 : No page-list or page-break markers.
Warning DISC-001-ACCESSIBILITYFEATURE content.opf: schema:accessibilityFeature is not declared.
Warning DISC-001-ACCESSIBILITYHAZARD content.opf: schema:accessibilityHazard is not declared.
Warning DISC-001-ACCESSMODE content.opf: schema:accessMode is not declared.
Warning DISC-001-ACCESSMODESUFFICIENT content.opf: schema:accessModeSufficient is not declared.
Warning NAV-LANDMARKS-001 nav.xhtml: Navigation document has no landmarks nav.
Info DISC-001-ACCESSIBILITYSUMMARY content.opf: schema:accessibilitySummary is not declared.
Pass NAV-002 : No problems found by this check.
Pass NAV-003 : No problems found by this check.
Not applicable DISC-002 : No accessibility metadata declared.
Not applicable DISC-003 : No accessibilityHazard declared.
Not applicable DISC-004 : No accessibility metadata to compare.

[Lukusaukko]

I decided to go on working on it, since there aren't that many ebook accessibility tools especially on Linux. It's not really ready for the Plugin Index yet, since there are a few issues that still need resoving.

For example, ACE doesn't flag missing cover image descriptions, but is it because cover images don't need an accessible description or because it doesn't check svg-wrapped images? At least some sources say that you should describe cover images too, though just a simple "Cover of [book] by [author]" is sufficient. Currently missing cover image description is a fail condition, but I'm wondering if it should just be informative condition - but I haven't been able to find a definitive answer whether cover images need descriptions or not.

But even so, I can now quite easily convert a plain epub into an accessible epub that passes Epubcheck and ACE checks (other than metadata, as that cannot be automated) in about 15-30 minutes, without having to edit semantic tags by hand.

The source is available at CodeFloe if someone wants to take a look.

[theducks]

Originally Posted by Lukusaukko

I decided to go on working on it, since there aren't that many ebook accessibility tools especially on Linux. It's not really ready for the Plugin Index yet, since there are a few issues that still need resoving.

For example, ACE doesn't flag missing cover image descriptions, but is it because cover images don't need an accessible description or because it doesn't check svg-wrapped images? At least some sources say that you should describe cover images too, though just a simple "Cover of [book] by [author]" is sufficient. Currently missing cover image description is a fail condition, but I'm wondering if it should just be informative condition - but I haven't been able to find a definitive answer whether cover images need descriptions or not.

But even so, I can now quite easily convert a plain epub into an accessible epub that passes Epubcheck and ACE checks (other than metadata, as that cannot be automated) in about 15-30 minutes, without having to edit semantic tags by hand.

The source is available at CodeFloe if someone wants to take a look.

There is a bit of difficulty. Checking the book COVER while in Calibre, does not really stay valid as the cover and metadata get updated (replaced) when sent.
Maybe, all the (cover type) plugin developers could set an Alt="Cover", but that will be about the best that could happen.

[Lukusaukko]

Originally Posted by theducks

There is a bit of difficulty. Checking the book COVER while in Calibre, does not really stay valid as the cover and metadata get updated (replaced) when sent. Maybe, all the (cover type) plugin developers could set an Alt="Cover", but that will be about the best that could happen.

Didn't know that - however, if you save the book to disk it is saved as is, so it's only a problem when you send the book to a device (and how many devices actually support accessibility features?); if you copy it via USB or just read on your computer, it might still be worthwhile to include descriptions for covers. But maybe implement it as informational check only, not something that blocks metadata editing (CAT prevents updating accessibility metadata until blocking issues are solved).

[Lukusaukko]

I have found a document on DAISY's site that does say that cover pages should also have a description for accesibility. I'm guessing Ace doesn't flag Calibre-produced covers because they are a kind of a hybrid, raster images wrapped in SVG, and it doesn't recognize them.