QA for Accessible Ebooks
The world of creating and checking accessible ebooks can be confusing and gnarly. When I lead workshops for publishers or teach undergrads how to make ebooks, I can see the exasperation on people’s faces as they try to grasp all the moving parts.
In the early days of making ebooks, when there weren’t a lot of reference materials or resources around, a lot of ebook developers used the #eprdctn hashtag on Twitter to rant and rave and seek advice. That method still works to some extent, but the plethora of tools and resources is dramatically different from a decade ago. The most important tools are the Daisy Knowledge Base, EPUB-Checker, and ACE by Daisy.
Automated vs Manual Checks
An important thing to note about these tools is that they are just that: tools. They are one tool in your toolbox that must be augmented by human checks. Passing automated testing is a bare minimum and a starting point for more robust manual reviews. Think of an automated accessibility checker like a spell checker in a word processor. Though a good start for identifying misspelled words, a person must still read through the text to ensure words have been used correctly.
While automated accessibility checkers are a great way to get a quick review of accessibility, they cannot be relied upon to identify all potential barriers or even to identify them accurately. Some barriers, particularly those that involve meaning in one way or another, can’t be measured with automated checkers (at least, not with the current state of the technology). Checkers are also not able to determine whether some types of inaccessible content have accessible alternatives.
The general rule of thumb is that automated checkers are good for about 30% of the work to verify the accessibility of content.
Some common errors that are often not picked up by automated testing include:
1. Poor Alt-text
An automated checker can tell if alt-text is present on an image, but it cannot tell if it is descriptive enough, sufficient, too long or if it should be empty instead.
InDesign used to populate the alt text field with the file name of the image, for example. I don’t think cover-image_v2_final-final.jpg is adequately descriptive to meet anyone’s needs. (Thankfully InDesign doesn’t do that anymore but if you are on an older version of ID, you might be cautious.)
An automated checker also couldn’t tell you if the alt-text is completely wrong, and it says “Banana” instead of “Apple.” Or maybe it says “Apple” but should be much more descriptive — such as “shiny red apple on an open window ledge in the afternoon sun”. Everything depends on how the image description is being used.
Perhaps the image is adequately explained in the copy surrounding the image and doesn’t need much explanation. Image descriptions are a fine art and a judgement call that automated checkers are just not capable of scrutinizing.
2. Poor Page Titles, Headings and Hyperlink Text
As with alt-text, an automated checker can tell if a page title or hyperlink has content. But it cannot tell if a page title or hyperlink uses appropriate or meaningful text. The same goes for headings.
As any user — sighted users with or without a disability and also non-sighted users — goes around a website and individual pages, the accuracy and descriptiveness of page titles, headings and hyperlinked text are important.
3. Improper Use of Tags
An automated checker cannot tell if the proper HTML tag was used for an element. Perhaps paragraph tags were used for what should be a list of items. Or maybe what should be body text is a heading tag instead. Maybe what should be a heading is instead tagged as body text. Or a table was used for layout purposes.
One of the areas in which I see the most confusion and errors is the misuse of em / i / cite / span, and bold / strong / span, for example.
All of these require review by a knowledgeable developer.
4. Incorrect Reading Order
Correct reading order is another issue an automated checker cannot detect. The order in which a sighted user reads something on a page is not necessarily how a user of assistive technology experiences it.
5. Language shifts
Automated checkers cannot make the determination about language shifts — whether they are marked up properly with the correct language code, or if they are missing altogether, or even if a short phrase is so common that it doesn’t need to be marked.
Checklists
I used the attached checklist, modified from one on the Accessible Publishing Learning Network, and added columns about whether one can rely on automated checkers to test for a specific piece of the accessible ebooks puzzle, and whether or not InDesign is useful to that line item. Please let me know if you find it useful or if you have suggestions to add or take away.
