This was a guest post for EPUBSecrets by Romain Deltour, lead developer of the Ace software tool, and re-posted here with the kind permission of Laura Brady, editor of EPUBSecrets.

The mission of ebook developers and publishers is a pretty darn cool and noble one, if you ask me: crafting pure information, pure knowledge, so that it can be readable by everyone. Yes, Everyone. As Billy Gregory playfully put it on Twitter in 2015, “when UX doesn’t consider ALL users, shouldn’t it be known as Some Users’ Experience, or… #SUX?”. If some people are left out, SUX. Well, we don’t want that in our EPUBs! The alternative is of course truly inclusive publishing, where content is accessible to all.

“When UX doesn’t consider ALL users, shouldn’t it be known as Some Users’ Experience, or… #SUX?”

Producing accessible ebooks, however, comes with its own challenges. Sometimes, accessibility is just underestimated and dashed off. Other times, goodwill may be damped down by perceived technical complexity. In any case, it is — sadly — far too easy to let some inaccessible content slip through a production workflow.

Wouldn’t it be useful to have some tools to help spot the most obvious accessibility errors, so that you can more easily work your way towards inclusive publishing? That’s the idea behind Ace, an accessibility checker for EPUB developed by the DAISY Consortium and currently in public beta testing.

Ace, in a nutshell

Ace is an open source tool that can help with evaluating conformance to the EPUB Accessibility 1.0 specification. Ace actually does two things: it runs some automated checks (and will report obvious accessibility violations), and it also extracts some data that can be used in a later manual inspection process.

Ace is usable as a command line tool, or can be integrated in larger software via a Javascript or HTTP API. Ace can create reports both in a machine-readable format (JSON-LD), or as a human-friendly HTML document.

“Ace is an open source tool that can help with evaluating conformance to the EPUB Accessibility 1.0 specification.”

Automated checks

When it comes to automated checking, it is very important to understand that a tool can only detect a limited set of accessibility requirements. Steve Faulkner, W3C HTML editor and well-known accessibility expert, for instance recently mentioned the figure of 30% of WCAG 2.0 criteria being able to be automatically verified. Trying to report more can result in a report riddled with false-positives and bloated information, which can be counter-productive.

In Ace, we’re trying to adopt a conservative approach and only report true and confirmed violations. Under the hood, to check an EPUB’s HTML content documents, Ace notably relies on aXe, a high-quality Web accessibility checker by Deque Systems. On top of these WCAG-related checks, Ace also runs a few EPUB-specific checks, for instance to check the presence of accessibility metadata. When a violation is found, Ace will point to DAISY’s accessible publishing knowledge base (curated by Matt Garrish).

Data extraction

In addition to the automated checks, Ace extracts some data that is intended to be useful for manual accessibility inspection. For instance, Ace can report the outline computed from the HTML headings (HTML elements h1 to h6) alongside the ToC from the Navigation Document, so that a person can check that they are consistent. Ace also extracts the list of the EPUB’s images and graphics along with their associated accessibility descriptions, and renders them in a consolidated table for easier review.

Again, automated checks cannot give the full picture, and by extracting relevant data Ace intends to prepare for the later stages in the process.

When to use Ace?

Fixing inaccessible content can be a costly operation. Imagine that you’re building a house: would you consider piercing the windows after having raised the walls and decorated with wallpaper, or would you rather consider it at build time? The example may sound trite, but it’s really what is at stake for accessibility. The well-known mantra “test early, test often” totally applies. The sooner you identify an issue, the easier and cheaper it is to fix. Accessibility testing doesn’t have to be put off to the QA stages down the line; it is a sane practice to also test during development.

What’s the plan, and how can I help?

Ace is currently in beta testing phase, and we’re eager to get feedback from technical experts in ebook production. Please be aware it may have some rough edges and …erm… bugs too (wouldn’t life be a bit bland without them?). We’re also looking forward to any usability suggestions or feature requests (on both Ace or the knowledge base). Feel more than welcome to use our issue tracker, or the beta testing feedback form.

We intend to release version 1.0 later this year. There’s already a bunch of improvements on our radar, including better configurability, more EPUB-specific rules, basic support for EPUB 2, localization, integration with EpubCheck,… Stay tuned! For news on Ace release updates (as well as all areas related to accessibility and publishing), don’t hesitate to sign up to the Inclusive Publishing newsletter, and follow @InclusivePub on Twitter.

Romain Deltour is a software developer and accessibility expert for the DAISY Consortium, and is a firm believer in the Web’s potential to enable a truly inclusive publishing ecosystem. When he’s not coding or attending W3C conference calls, he can usually be seen playing with one of his three lovely kids. Sometimes, they happen to enjoy the conference calls too…but shh!
[/av_textblock]