Accessibility means different things to different people. For some it means automatic doors, or bank machines at a specific height; for others it can mean a sign language interpreter at a job interview or the right to travel with a service dog. Although every disability is different, all of these accommodations have one thing in common: they need to be done well or they will not be effective.
The same holds true for document accessibility. Just because the font is big it doesn’t mean that the content is readable by someone with low vision. Just because the screen reader starts talking when you open the file, it doesn’t mean the end user is getting the information you’re trying to convey.
Advances in technology mean that, in some cases, less and less background knowledge is required to change a document from one format to another. You can save a pdf file to a number of other document types that can render the content more accessible. Braille translation software will even allow you to import word or text files and with one click you can transform print into braille. Having said that, will the converted file contain all of the information of the original? Will the read order and formatting be logical? Does the output meet industry standards for accessibility? This is where testing or quality control comes in.
For several years I worked as a human resources advisor for the federal government. Although my job was not related to accessibility I would often assist colleagues who were trying to ensure that documents and web pages complied with relevant accessibility legislation. I was once asked to verify a fillable PDF. My colleague informed me that he was pretty sure the file was okay: “I opened it and the screen reader started talking, so it’s probably fine.” Sure enough, when I opened the file JAWS did start talking, but all it did was say the name of the form. In each of the boxes to be completed it said the word “edit”. The read order had not been properly tagged so it was impossible to know which information belonged in which box. Just because it talks, doesn’t mean it’s accessible!
Whether you call it testing, proofing, or QC, this process has two key elements in accessible document production. The first is to ensure that the accessible version of the file is accurate and contains all of the information found in the original. This is essential in all kinds of files but is of particular importance in banking and financial statements, where a zero more or less makes a significant difference.
The other element is compliance with industry standards. Each accessible format has guidelines and standards that must be followed. For example, large print is not just about making the font bigger. It’s also about how the content is laid out on the page. Formatting is also important in braille, and there are a number of rules that govern the use of the code itself. WCAG 2.0 AA and PDF/UA provide guidance for making PDF files accessible. All formats have requirements about how images and other visual information should be displayed. There are additional specifications for hard copy, such as paper quality, binding and dot height. Testing ensures that the end user gets accurate information in a document that meets the highest standards for the format requested.
To learn more about the testing process or to get ideas for testing your own files internally it’s not too late to sign up for tomorrow’s webinar, Testing Accessible Documents. Being held from 1:00 to 2:00 PM ET, we’ll review best practices for testing accessible formats such as braille, large print, eText, Accessible PDF and other commonly used formats.
