Auditing Advice
This page explains how to audit the current accessibility of all aspects of the organisation, including the frontlist and backlist book files, the website functionality and the backend submission platform. You could complete this yourself using self auditing, or employ an external auditor. You could also look at assessing current organisational knowledge, attitudes towards and motivations for engaging with accessibility work. For a full audit, especially if you have ambitions to go beyond legal compliance, you could consider all of the four steps below, but completing the first two would be sufficient as a minimum.
- Automated Testing
- Manual Checking
- Assistive Technology Tests
- End user testing from print disabled people
Automated Testing
There are many proprietary and open source tools available to audit accessibility using automated testing. Below we have collated our top picks for open source tools, however many publishers may have budget to purchase a tool to do this, therefore, we have included links to other curated lists of accessibility tools from recommended sources. It's important to note that automated testing is only part of the process and can only take you so far, as many accessibility features require human assessment, for example, automated tools can check for the presence of ALT text, but can only guess at it's quality, for example length or matching the file name, and full quality checking will always need a human.
Top Picks:
EPUBs
Ace by Daisy: https://daisy.org/activities/software/ace/
Smart by Daisy: https://smart.daisy.org/
PDFs
PAC (Pdf Accessibility Checker): https://pac.pdf-accessibility.org/en
HTML and Web Pages
Wave Browser extensions https://wave.webaim.org/extension/
Accessibility Checker: https://accessibilitychecker.org/
More tools:
https://www.w3.org/WAI/test-evaluate/tools/list/
https://accessibility-manual.dwp.gov.uk/tools-and-resources
https://github.com/ediblecode/accessibility-resources?tab=readme-ov-file#checkers
https://www.a11yproject.com/resources/#tools
Manual checking
EPUBs and PDFs
We recommend our auditing tool, OARC, which includes just the parts of WCAG that are relevant to static files, and has additional checklist items for the two most common file type formats for open eBooks.
HTML and Web Pages
For HTML books and web pages, you would need to consider all of WCAG AA, rather than just the selected checklist above, which only includes aspects of standards that apply to ebook files that need to be manually checked. Below are a list of already available widely used full WCAG based checklists:
Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0
Deque Accessibility Developer's Guide
Other checklists and related tools:
UK Government: Basic accessibility check
Web Content Accessibility Guidelines - Quick Reference
Web Content Accessibility Guidelines in Plain English
BCCampus - Accessibility Toolkit - 2nd Edition
Open University Library - WCAG 2.2 Level A and AA Basic Primo VE Checklist
Assistive Technology Tests
We recommend running at least a sample of eBooks through assistive technology in order to double check that everything works OK, and best if this is a range of the most commonly used tools that fulfill a range of functions. The minimum checks you complete should be checking that:
- the file opens
- the file displays properly in a way that's understandable
- everything within the file can be used with that technology
There are different types of assistive technology that are commonly in use and you should check through at least one example of each type.
Contrast, Colour and Font Changers
Try different settings using:
- Windows High Contrast mode
- Different browser's settings, such as Firefox and Chrome
Screen Readers
NVDA desktop screen reader and JAWS desktop screen reader are commonly used open source applications that you can download and test with. It's also recommended to check using mobile screen readers such as VoiceOver on iOS or TalkBack on Android. Complete the following tests using these technologies:
- Read every element and header
- Tab through every link
- Check every landmark, for example your footer and any navigation
- Check your use of Accessible Rich Internet Applications (ARIA)
- Check you can fill in any editable fields, for example writing and submitting a form
Screen Magnifiers
Use desktop features such as Windows Magnifier or mobile features such as Apple Zoom to check this. Complete the following checks using these features:
- Test up to at least 4 times magnification
- The spacing between elements, for example the gap between a form label and field
- That page elements display consistently on different page layouts - so someone who is zoomed in to a page can always find the search box, for example
- That users know when something happens outside the viewport - for example, with modals or error messages
Speech Recognition
Dragon speech recognition is a commonly used proprietary desktop screen reader that you can test with. It's also recommended to check using mobile speech recognition on iOS or Android. Complete the following tests using these technologies:
Make sure you speak clearly, but naturally. You should also use a high quality headset rather than an in-built microphone in your local machine and make sure you’re at a consistent distance from the microphone.
More information:
WebAim articles
using JAWS to evaluate web accessibility
using NVDA to evaluate web accessibility
using VoiceOver to evaluate web accessibility
UK Government advice
https://www.gov.uk/service-manual/technology/testing-with-assistive-technologies
End user testing from print disabled people
While not common for small presses, and likely this is beyond available capacity, best practice would be to approach end users with disabilities to test a sample of book files, web pages and submission systems. Below is some advice on finding user testing opportunities like this, if presses decide to go down this route.
The best feedback will always come from end users with disabilities, and from older users, as it can uncover accessibility barriers that are commonly experienced by your readership, yet are not captured within legal minimum accessibility requirements.
In most cases, including users in evaluation involves:
- getting a few people with disabilities, and depending on your target audience, older users
- including them throughout the development process to complete sample tasks on draft book files and websites so you can see how different aspects of the design and coding could be improved before publication
- discussing accessibility issues with them
Sources:
W3C Involving Users in Evaluating Web Accessibility
W3C Involving Users in Web Projects for Better, Easier Accessibility
More information:
AbilityNet - A Step-by-Step Guide to User Testing
AbilityNet - Product and Services - User Accessibility Testing and Research
The Gov.UK website includes a set of hypothetical user profiles to give you working examples of the range of users and their needs. These can be used to develop a strong idea of accessibility use cases and may help make content design decisions.
No Comments