The Australian Government recently released a study into the Accessibility of the Portable Document Format (PDF) for people with a disability, which Duff Johnson analysed very effectively.
I can agree with almost all of Duff’s points, and it’s covered so well I didn’t feel I needed to check the source material (although I will). But as is the nature of blogging, there is something I’d like to disagree with:
The comparison with HTML.
Duff knows a great deal more than I do about PDF standards and technologies, however, I’m pretty strong on the web-standards side of things, so it’s a useful discussion around the intersection of these areas.
I’d not heard it put in this way, but it is an excellent point:
PDF creation is democratic, HTML is centralized
…most people don’t write HTML, so most don’t author documents with any attention to semantics. Since PDFs may be created and posted without the benefit of a content management professional, it’s harder to impose authoring standards outside of specific organizations.
I agree with the point made, but there is a good reason why HTML websites are more likely to be accessible than PDFs in this context: the interface.
Interface lockdown
When you setup the editor in a Content Management System, you can lock it down to only allow semantic elements. You can even make the inclusion of style-oriented elements look wrong by adding certain CSS.
The key thing is that the available options are accessible, and the inaccessible ones have been removed (e.g. font/background colours). There are other things to do, but that problem is solved once, and then works for that website ongoing. If the CMS is sufficiently usable, you can even extend the number of contributors without worrying about the accessibility.
Theoretically, you can also lock down Word templates so that you can only use Word’s styles (I’m not sure about InDesign?). However, it’s a pain to implement, and I’ve not come across an organisation prepared to do so.
How organisations typically publish documents
In a typical medium/large organisation that publishes web content, it is generally non-technical people updating web pages and uploading documents. When I’ve run courses teaching people how to make accessible PDFs, it is generally people on a web team that attend (government, private and charity sector organisations). Not coders, content authors and managers.
The web team are usually happy with the web pages, but they are sent inaccessible PDFs to publish, often without access to the source documents. The central team simply doesn’t have the resource to repeat the same accessibility fixes on every document they are sent.
I’m not blaming PDF for this situation, I’m even reluctant to blame Microsoft (where the interface matters most), it’s the people buying software that aren’t aware of the issue.
Pressure from organisational procurement (on Microsoft and Adobe) to provide a good option to use a locked down interface (and enforce it’s use) would prevent most of the accessibility problems we see. Oh, not to mention some more competition in the PDF-tagging software space.
Therefore, I agree with Duff that the report is likely to lead to an ineffective policy, even though I have a different perspective on why.
Download Web Axe Episode 87 (Web Axe 2010 Year in Review)