One of the most frustrating aspects of my chosen field is that I need to deal with people who believe that there’s only One True Way™ to make something accessible. This purely accessible format generally comes in the form of a web site, and all other formats must be inherently flawed if you decide to use them.
— Paul J. Adam (@pauljadam) November 14, 2012
In my experience, nothing is as prevalent to this occurring in accessibility than the incessant debate over PDF vs. HTML. Most proponents of web accessibility (that I have come across) have an annoying tendency to make superlative and often incorrect assumptions about PDF accessibility. To a person with an ASD, this sort of commentary is particularly ingratiating. In fact, I’ve walked out on some conversations with colleagues because the same incorrect statements were made over and over again.
Time and time again, I have heard from web gurus and information technology experts that in order to be fully accessible, something needs to be made a website. In fact, many Accessibility experts make incorrect statements about PDF in an effort to get people to stop using it altogether.
Although not digital, responsive, searchable, or accessible, PDF persists because it lets content creators use familiar tools. #aeachi
— Jeffrey Zeldman (@zeldman) August 31, 2015
— Shawn Lawton Henry (@shawn_slh) May 15, 2014
— Julia Garnett (@jzgarnett) June 4, 2015
This is a big deal, because these statements are just untrue. The fact is, PDF is capable of being just as accessible as many other open formats. That’s right, PDF is an open standard. What would be a more accurate statement — one even echoed by many who work with PDF — is that not everything should be a PDF. I will go a step farther and say that not everything should be a web site.
The problem is, Jeffrey, Shawn, and Julia aren’t completely wrong either. Like many websites, while PDF technically can be accessible, most usually aren’t. And unlike the most basic websites, many aren’t accessibly supported. The W3C defines accessibility support as “supported by users’ assistive technologies (AT) as well as the accessibility features in browsers and other user agents.”
To this extent, the accessibility features of PDF is superficially supported. I suspect that most commercial AT began providing rudimentary support for this technology because there are so many in use and their users were complaining about not being able to access them. However, the ability for assistive technology to access the accessibility features of PDF have been available since 2001, within PDF 1.4. It’s just that, these standards aren’t adhered to.
I believe there’s two reasons why Assistive Technology (or Apple, as Paul noted above) has failed to make this technology accessible is for two primary reasons:
There’s been no reason for Assistive Technology to adhere to the specifications (aside from Adobe, who invented it) for the Portable Document Format. When it came to web sites, laws and regulations stipulated that things must be built a certain way so as to expose the information to AT. The US Federal government couldn’t buy anything that didn’t adhere to certain guidelines set forth in Section 508. The original Section 508 relied heavily on WCAG 1.0, the predecessor of WCAG 2.0. That said, WCAG 1.0 referenced current web standards: of consideration, those specifications regarding HTML and CSS.
While AT can sometimes fix a large number of accessibility problems found on web sites for its Users, it’s in the AT vendor’s best interest to make something that works with technology created to work with it. Another way to look at it is if an AT vendor decides to make their AT work however they want it to instead of standards, users would be less inclined to use it if they can’t get it to work with the technology required by law.
That said, there is no law currently that explicitly states that PDFs must be accessible. This has actually sparked a large amount of contention among Accessibility Experts who deal with Fed IT departments informing their agencies they only need to make web sites accessible. This idea comes from a pedantic, yet often used interpretation of the current Section 508 rules. The current law is heavily technology-specific, separating the requirements in 1194 by technology. Only until fairly recently has this view changed to include web content as more than content that just happens to be on the web.
So if there’s no requirement to make PDFs accessible, then doing so is generally considered a “feature.” In terms of software development, features can be described as cool bells & whistles added to how a product works, and a requirement is what’s needed in order to fulfill the basic needs in order for the product to actually work. At the end of the day, a requirement is what gets you paid, and a feature is how you acquire or retain the customer in the first place.
The sad reality is that if it’s not considered a functional requirement, making things work a certain way won’t ever be considered a requirement.
The second reason why AT doesn’t adhere to the specifications is that vendors rely heavily on their user’s Choice-supportive bias. Choice-supportive bias is what happens when, “after making a choice, a person is likely to maintain the belief that the chosen option was better than the options rejected. [from Wikipedia]” This happens all the time in technology.
This type of decision making for using a technology is why we choose an XBOX over a Playstation, or why we choose a Mac over a PC. If a person decides to buy a Playstation, the typical rationale was because they felt the feature set of the product was better than an XBOX. Opinions drive brand loyalty, which companies eat up with silver spoons.
When it comes to web sites, it’s easier for people to attribute feature capabilities they believe are easy to implement because it’s already their chosen medium. In accessibility, the feature set of web sites are thoroughly rich, and it’s a fair assumption that it’s easier to adapt to technology that is built on existing platforms rather than ones that don’t. Since web sites already have a foundation of well documented accessibility standards, any technology that is used on top of that must inherently be accessible by association.
Mobile Accessibility? Check. Video Accessibility? Check. Audio? Driverless cars? Smart refrigerators? Why not? The skies the limit.
Except there is a limit
New technology happens all the time. And there’s no requirement that the technology that comes out is understandable by Assistive Technology. For example, accessibility support for WAI-ARIAis still widely varied across screen readers. SVGis widely supported by many browsers, yet fails to be relevant to many authoring environments people use. The specifications of these technology exists, yet there’s no functional requirement that they be made anything more than a feature.
Does that mean we shouldn’t use ARIA or SVG? Of course not! But why is PDF left behind? The specifications for tagged PDF have been around just as long as these other technologies, and they are far more in use today than the ones I’ve mentioned. Even more poignant is the fact that the one thing that all three of these technologies have in common is that there is no requirement for them to be taken seriously.
I believe that Web standardistas believe that these other technologies are more relevant than PDF because they have had the benefit of using it with a requirement that it needs to work using industry best practices. Should there never been any requirement out there to follow the Standards provided, this would be a very different discussion!
I’m not saying that one format is better than the other. Quite the contrary. When I bad mouth Apple or Windows machines, someone invariably believes I’m a fanboy for the opposing team. The truth is, I hate all technology equally. Everything out there has a universal ability to suck. But it still gets used, and when that happens, there must be some understanding that we need to promote that it should be made accessible.
I doubt that I’ll change anyone’s minds about PDF accessibility, but I urge my Accessibility colleagues to acknowledge that PDF aren’t going anywhere, and if there’s a chance to make them accessible, we should fight to make them that way. Telling end users to go use one technology you like better than another is like telling them to buy an XBOX because Playstation sucks. It’s not helpful, and they’re going to buy whichever one they feel more comfortable using. In the end, they’ll get schooled online by someone who knows about what it’s really capable of.