WCAG 2.0 is for web content, not all content. It’s important to use the most applicable standard for any given technology.
First, let’s say that WCAG 2.0, the current W3C standard for accessible web content, is an excellent starting point for thinking about electronic content accessibility in almost any situation, even for content that never appears on a web site.
That’s because WCAG 2.0 uses (mostly) technically neutral and general terms to define priorities for ensuring that text, images, information, video, scripting, navigation, structure, design, writing style and more are accessible. Many, even most WCAG 2.0 Success Criteria are applicable across multiple technologies at varying levels of abstraction.
WCAG 2.0 discusses accessibility from an inherently web-centric (that is to say, HTML/CSS) perspective. Naturally enough, there are electronic content applications that WCAG 2.0 misses. For such cases it’s appropriate to refer to applicable standards in addition to WCAG 2.0.
WCAG 2.0 cannot, for example, to be applied to closed systems such as kiosks or ATM machines because such systems don’t allow a user’s software to “programmatically determine” the content.
Some WCAG 2.0 assumptions regarding navigation, pagination, forms and more don’t translate to electronic documents very well. Depending on content and circumstance, software developers and authors may need additional technical specifications in order to achieve consistent accessible results in non-web technologies.
Why do I mention “consistent”? Normative requirements regarding consistency in WCAG 2.0 – SC 3.2.3 and 3.2.4 – are specific to the web, marginally applicable to electronic documents) and get only ‘Level AA’ prioritization in WCAG 2.0.
For electronic documents, however, consistency (also known as “portability”) is king.
For PDF, it’s not enough to simply require developers to make all “information, structure and relationships” (to quote WCAG 2.0 SC 1.3.1) programmatically determinable. PDF is internally complex, with many diverse structures. Consistent results require more specificity. Success Criteria 1.3.1 is far more readily applicable to HTML, where “information” is constrained to tags and CSS classes. Applied to PDF directly, SC 1.3.1 is hand-waving – more or less akin to simply demanding: “Do the right thing.”
In PDF, reliable appearance and functionality from one computer and user to the next is key. That’s what electronic document users require. AT users should get the same reliable experience as any other user.
PDF isn’t HTML. HTML relies on the browser to represent the document’s content; PDF relies on the file itself. Assuring consistent accessibility in complex document formats like PDF requires specifications well beyond simply “do the right thing.” In the case of PDF, as Adobe Systems themselves point out, it means PDF/UA (ISO 14289), the international standard for accessible PDF.