Home

Adobe's accessibility commitment

Wednesday, 30 September 2009

Adobe's accessibility tools have improved greatly since I started with Acrobat 4, and it's fairly easy now to make most documents quite accessible if you try. But when we talk about planning for accessible content on the web, consider this: Acrobat was conceived as a way to assure presentational accuracy and portability of fixed-layout documents. Presentational accuracy and fixed layouts are legacy concepts from the printing trade (not a bad thing), and nobody does this better than Adobe Acrobat. View or print a PDF on any platform, on any printer, and you get impressive consistency. On the other hand, one of the beauties of the HTML and XML languages is their flexibility, their ability to render one properly coded datasource into multiple formats (various screen resolutions, print modified by CSS, mobile devices, DocBook and other structured layouts ...). This is not a slam on Acrobat or the Portable Document Format, but Adobe has had to struggle to make PDFs do what standards-compliant HTML does natively — that is, to separate content from structure. This is a very important accessibility principle. It also speeds data sharing and data processing, which is important in some contexts. As Andrew notes above on Adobe's behalf, there will be people who have sound reasons for providing all sorts of data in the PDF format, and Adobe has built-in accessibility helpers to help make that data more universally readable. All well and good, but we should always resist stepping away from simple, semantically correct HTML that can be parsed without browser plugins or external programs of any kind. Keep it simple! Accessible PDFs have an important role to play in web accessibility, but it should be a very small role for most of us.