Tools to Help Assess Ebook Accessibility

A selection of hand tools, cropped
  • Sumo

Once you’ve got your ebook workflow down, paying attention to the nuances of accessibility, how do you check that work? There is no substitute for experience, but I have a couple of tools that can help.

Use these tools to complement your experience and testing. And go make better ebooks!


What? FlightDeck? That’s not an ebook accessibility tool, is it? Well, not strictly. But a well-made ebook is more accessible than average and FD will push you there. FlightDeck is not a free tool, but can be affordable when used via one of the subscription packages.

A FD report gives a good all-round overview of the ebook. For example, this EPUB is reflowable EPUB 3, has some embedded fonts, and has 62 images for which I will want to check the image descriptions.

A screen shot from a Flight Deck report illustrating that it is EPUB 3, reflowable, and has 62 images, among other basic statistics.

Here are some areas of the report that you might consider worthy of attention.

Best Practices

The Best Practices tab will point out any areas that you may have missed. This screenshot shows that there are some fonts in the EPUB that aren’t being actively used and that I might want to delete to save space. It also suggests that inline styling is not a good idea. This part of the report will also tell you if your ebook is missing a landmarks section and/or a page list – both of which will add rich navigation to your EPUB and are important to accessibility.

The “Best Practices” tab of a FlightDeck report pointing out that the ebook is missing an ISBN, that there are extra font files embedded, and that the cover has inline styling.

Structural Hierarchy

When I take a first look at an EPUB, one of the first things I look at is the heading breakdown in FD, comparing it to the table of contents. I want there to be as many level on headers as there are top-level entries in to the TOC. Similarly the number of <h2>s matches secondary entries in the TOC, etc.

Looking at the “Header Levels” and “Table of Contents” on the Stats page is going to point to any problems with the structure of the content.

A snippet of a FlightDeck report showing the number of heading levels and part of the “Table of Contents.”

Ace, by DAISY Accessibility Checker

This new tool is a huge help when it comes both to checking for accessibility and pushing developers to use best practices. If your EPUB is missing accessibility metadata, for example, you will get some serious errors. If epub:type semantics don’t have corresponding ARIA roles, you will get a mountain of errors.

A summary of the errors in a well-made EPUB – well-made despite the 4,702 errors pointed out by Ace, by Daisy.

In my experience with a broad cross-selection of good and bad ebooks, the more attention a developer pays to accessibility, the more Ace squawks. So, for example, an EPUB 2 reflowable with no page list, no landmarks, no HTML 5 tags, no image descriptions, and no semantics whatsoever, might turn up a minimal number of Ace errors. And a really well-built EPUB that is missing metadata and ARIA roles, will generate hundreds of errors, as seen in this slightly alarming screenshot.

I don’t say this to dissuade you from using it; on the contrary it is the best tool available to vet the accessibility of your ebooks. But I caution you to use it as one tool in your tool chain. Ace will strong-arm you into folding ARIA roles into your epub:type semantics, and will bully you into adding accessibility metadata – both of which will make you a better ebook developer. This article from Simon Collinson might help convince you that working ACE into your workflow is well worthwhile.

All the errors that show up on Ace are actionable and come with a link that will point you toward answers. This screenshot points out a minor best-practice error, a problem with the epub:type semantics missing its matching ARIA role.

A screen shot from an Ace HTML report showing a minor error which points to a missing complementary ARIA role.

Errors have four handy categorizations: critical, serious, moderate, and minor. They are all worthy of your attention as you take some baby steps toward better ebook development practices.

Explore Ace. Ask questions when the error doesn’t make sense (#eprdctn is a good place). A quick piece of Ace’s report that I want to point towards: lack of image descriptions is not always an error and can’t be reported as such by Ace. The image may be described adequately in the surrounding text, for example, which automated checkers just can’t check for. An EPUB that is utterly devoid of image descriptions will not generate any errors for this lack.

As you can see in this screenshot, the alt text for the cover is the abysmal description of “cover.jpg”, and the frontispiece map has no description at all. Neither are highlighted as erroneous, which might lead you to think things are cool. They are not.

From the “Images” tab of the HTML report, highlighting the lack of ALT text, and a very poor repetition of the image name as ALT – neither of which are highlighted as an error.

It is important to note that while these tools are useful, they are just one piece of the puzzle and do not replace human testing. The developer behind Ace suggests that it will get you about 30% of the way there, for example.

Use these tools to complement your experience and testing. And go make better ebooks!

2 Responses to “Tools to Help Assess Ebook Accessibility”

  1. Aaron Troia says:

    I know it’s basically Ace, but I have found the Born Accessible Content Checker ( to be a very helpful web based alternative since I can’t use Ace on my work computer. It is a little light on explaining what the errors and warnings are, but nothing a little asking around on #epdrctn cant fix 🙂

  2. Aaron Troia says:

    *correction #eprdctn