Are PDFs More Important Than Web Accessibility?

Written by Mark Magennis Friday, 04 September 2009

We recently did an audit of a website where probably close to 99% of all the information it contained was in downloadable documents, mostly PDFs. These documents contained a lot of the stuff you'd usually find on a website – structured text, data tables, application forms, complex diagrams, graphs and other images. None of those we looked at were accessible. We wondered what we should advise the client to do about it.

The PDFs weren't structured or tagged, so a user of assistive technologies would find them problematic. For a screen reader user, the structure would be difficult to make out, data tables difficult to understand, information in diagrams and graphs completely unavailable and application forms impossible to fill in. So even if the HTML pages were made fully accessible, or if the PDFs could be acquired by some other means, 99% of the information and functionality on the website would still be unavailable to those users. In this case, it could be argued that the PDFs are more important for accessibility than the 'web accessibility'.

Times change and so does PDF

In the old days, when we audited websites we were a bit lax about PDFs. We used to audit the HTML pages and tell the client how to fix them, but for PDFs we'd almost treat them as if they were something else entirely. Not part of the website but merely something made available from it and therefore a bit outside the scope of the audit. We used to say something like "you really ought to make these PDFs accessible as well as making the site accessible". Our advice was that PDFs couldn't be made accessible in themselves so they should be converted to accessible HTML.

We're older and wiser now so we have a different view of what constitutes Web content, a view that better encompasses PDFs along with other non-HTML content. This is in part due to the considerable advances that have been made in PDF accessibility. Features like headings, data table structures and text alternatives for images can now be marked up in a way that can be read by the latest screen readers. So it is now possible to say something about PDFs other than just "use HTML".

PDFs have therefore moved very much within scope for the audit. WCAG 2.0 makes the point (better than WCAG 1.0 did) that anything hosted on a website is 'web content' and therefore within the scope of the guidelines. The main way it applies itself to technologies other than HTML is through the concept of 'accessibility supported'.

Accessibility supported

Accessibility supported means you can use a technology (like PDF for example) for a particular use and it will be accessible. For example, using a PDF to present a paragraph of plain text can be said to be accessibility supported because assistive technologies, used in combination with the free Adobe Reader, have been able to read plain text in PDFs for years. But what about a complex data table or an interactive form? Can you use PDF for those purposes and still guarantee that people with assistive technologies will be able to read them? If not, then PDF cannot be said to be accessibility supported for data tables or interactive forms.

So 'accessibility supported' is a judgement of whether it is okay to use a given technology for a given type of content or functionality. This is important to understand clearly. Accessibility support doesn't apply just to a technology, so it's not logical to say "PDF is accessibility supported" or "PDF is not yet accessibility supported". You can only apply the concept of accessibility support to the use of PDF for a particular purpose, as in "using PDFs for that interactive form is not accessibility supported".

It depends on the users

But there's more to it than that. It depends on who the users are and what they can do. Specifically, what assistive technologies they have available to them. You see, accessibility support requires three things:

That the technology is capable of making the type of content or functionality available to assistive technologies;
That assistive technologies are capable of working with that;
That users have those assistive technologies available to them.

If any one of these conditions is not met, accessibility support does not exist. For example, even if PDFs can express the structure of data tables and the latest screen readers can read that structure, if blind users don't have those screen readers available to them then there is no accessibility support. And this will be different for different user populations. For a company intranet, the company can make sure all staff have the required assistive technologies. But for a public website such as the one we audited, no such control is possible.

So what do we tell the client?

Back to our audit and the question of what do we tell the client about how to make the information in their PDFs accessible? Could we tell them how to use PDFs for their purposes in ways that would be accessibility supported? Could we simply say "create structured and tagged PDFs and users with disabilities will be able to access them"? Well:

We know whether PDF has the capability to express the different type of content or functionality because we can look that up;
We're not sure what versions of what assistive technologies can actually access those features because we haven't done the research and we can't find enough comprehensive research done by other people;
We don't know what versions of what assistive technologies the users (a general Irish population) have available to them because, again, we haven't done the research and neither has anyone else. Even the notion of 'have available to them' is a bit tricky because it could be said that the latest assistive technologies are 'available' to anyone, as long as they can afford to pay for them. That wouldn't be a very practical attitude though.

To even approach this issue and advise clients about it in an effective way, it's clear that we need to do some research. We need to find out what capabilities the various assistive technologies have (something WAI has been calling for) and what assistive technologies people are using. Then we will be able to tell our clients "this use of PDF is accessibility supported as long as you mark it up properly". Except no, there's another problem and it's a "how long is a piece of string?" kind of a problem.

How much is enough?

The problem is that the concept of 'accessibility supported' is not an either/or concept, but a judgement. It includes within it an implied 'sufficiently', as in 'sufficiently accessibility supported', as in 'enough users have good enough assistive technologies to work with this'. So how much is enough? What if we find that 50% of users have the required assistive technologies? Is that enough? How about 70% or 80%? Who decides? Also, since it seems like this support, even when it's there, can be a bit flaky, when can it be said to be "good enough"?

In the WCAG 2.0 documentation, WAI leaves these decisions up to "the community and to entities closer to each situation that set requirements for an organization, purchase, community, etc.". There doesn't seem a lot else they can do, but essentially this looks like the same thing we had in WCAG 1.0 with the checkpoints that began with the words "Until assistive technologies ...". There were always people popping up on discussion lists asking "Are we there yet?". This is more complex of course and WCAG 2.0 includes a clear request to the community to do this research and gives guidance on how to report the results.

Hey look! We're in the real world

So for many uses of non-HTML technologies, we can't say "this is accessible" or "this is inaccessible" without making a judgement of how far we think we ought to go and how many people we are prepared to leave out. Is this situation just a big headache then? Not in my opinion. This is good! This is realistic! It gives us a clear way to reason about the extent of accessibility based not on generally applicable abstract standards and best practices, but on the situations of the real user population for the specific web resource we are evaluating. It potentially gives us a way to recognise and accept how many people we are including and how many we are leaving out. In my book that's great. If people are being left out, it's good to be open and honest about it. It's more work, but more useful work.

So we in CFIT now need to get going on that research, and keep it up to date. My guess is that we'll then collide head-on with another issue – disabled users' knowledge of the capabilities of their assistive technologies. We may find that even where users have assistive technologies that provide accessibility support, a lot of them don't know how to use those features. In fact, I know for sure that's what we'll find. Then we will have identified the specific needs for a whole bunch of user training, but that's another story.

What's more important then?

Back to the title of this article. Are PDFs more important than web accessibility? No, they are a part of web accessibility, as much as HTML pages are, and the extent of their importance is determined by the extent of the role they play on the website. How many websites have 30%, 50%, 70% or even 99% of their information and functionality contained in PDFs I wonder?

Add your comment

Your name:
Your email:
Your website:
Subject:
Comment (you may use HTML tags here):

Comments (14)

On Fri, 4 Sep 2009, Mark Magennis wrote:

"We did an audit recently of a website where up to 99% of the information was contained in inaccessible PDFs. Crikey! It raised some interesting questions about what to say to the client about it. You can read my ramblings about this on the CFIT website [1]. Please comment if you have any interesting input or opinions. I think this is a big issue in web accessibility. "

Well, of course I can never resist responding to the PDF issue.

My core reaction: while we are not there yet, I would say that
authoring technologies for "single source master" design of
"documents" are now maturing; and publishers are gradually
becoming more clued into the importance of such tools, of which
accessibility is only one. So while I don't disagree with
anything in the CFIT article, I would like to emphasise the idea
of offering users multiple alternative formats to choose from for
this particular category of content. Yes, PDF (preferably
properly tagged); but yes, HTML (properly tagged); and, soon,
DAISY and ePub (ditto). If that kind of infrastructure is put
into place on the authoring/publication chain side, then we can
actually escape the most difficult questions that Mark raises.
It then doesn't actually matter whether "enough users have good
enough assistive technologies to work with" any particular one of
the technologies (PDF or otherwise) - because they each get to
choose whichever works best for them.

Is this complete utopianism? I honestly don't think so. Yes,
there are edge cases, where something is harder to achieve in one
of these technologies than the others (which was the basis for
Joe Clark's somewhat strained defence of PDF). But (as I have
said before, too many times) the vast majority of the content
currently published in PDF just is not in that category - it is
all very well covered by a wide diversity of technologies at
various levels of maturity. We don't have to shoehorn all users
into just one of these.

So what to advise the client? That this is key strategic issue
for their business; and that accessibility is only the tip of
this iceberg. They need to take a strategic, long term, look at
their publications processes, one that is not focussed on a
particular output format, and especially not a single,
fundamentally visually oriented format (as PDF still is). If
they can think about re-engineering that process into one that
can produce a living repository of structured, re-purposable,
information, which will benefit the organisation and its users
long beyond any single, transient technology-de-jour - rather
than one whose business has changed merely from putting dots of
ink on paper to one of projecting pictures of dots of ink on
paper onto a computer screen - then, which is more, "you will be a man, my son..."

(But if that is just too wishy washy and abstract ... whisper
"kindle" and "reflowable" and see if that can't work better...)

Good luck!

- Barry.

Good points well presented as usual Barry. I agree that single source to multiple versions is a key strategic issue for many organisations and that accessibility is only the tip of the iceberg. I think we are already in a position to advise clients of this and how to achieve it to some extent at least.

As you say, we're not completely there yetwith the technologies and processes but we are some of the way and a lot of organisations could make a more effective and efficient job at information publishing right now, simply by getting their MS Word authoring to PDF/HTML output better planned and executed.

Mark

Mark, Barry and all,
my tuppence worth.

Barry wrote:
> >
> > So what to advise the client? That this is key strategic issue
> > for their business; and that accessibility is only the tip of
> > this iceberg. They need to take a strategic, long term, look at
> > their publications processes, one that is not focussed on a
> > particular output format, and especially not a single,
> > fundamentally visually oriented format (as PDF still is). If
> > they can think about re-engineering that process into one that
> > can produce a living repository of structured, re-purposable,
> > information, which will benefit the organisation and its users
> > long beyond any single, transient technology-de-jour - rather
> > than one whose business has changed merely from putting dots of
> > ink on paper to one of projecting pictures of dots of ink on
> > paper onto a computer screen - then, which is more, "you will be a
> > man, my son..."

A little worms-eye view of this issue if I may...

While this is precisely the long-term approach to be taken, I think most public sector organisations are still quite a way off from this. All website managers are up against it when dealing with the typical publication process. This very often involves draft content in a Word document authored by multiple people being sent to a desk-top publishing company and, many iterations of edits later, a print-ready PDF is created which the web manager is then expected to make an accessible something out of. One of the progressive managers I know recently told me they then pay the desk-top publishing house to 'tag-up' this PDF in order for it to be accessible. This I believe is probably being done because it is preferable to tackling to process in which the content is authored, proofed and edited which does not lend itself to the creation of a single mater document from which multiple formats can be created.

However in most cases there is not the money/support for the web manager to do this or to the convert this content themselves. My suggestions to web managers looking to tackle this is to take a staged approach along the following lines:

Short-term goal: Identify the most popular documents on your website
that are used or likely to be used by the widest range of people (such
as fact-sheets).

Start with publishing these in an accessible, structured format. This
will help identify the technical (such as authoring tools) and
organisational issues that need to be overcome and dealt with regards to
the publication process itself.

Clearly state on the website that any older inaccessible documents
will be converted to an accessible version on request (according to
obligations under the Disability Act and the Code of Practice)
Long-term goal: Identify a point in time from which all content will be
published in an accessible format and work on the content production and
publishing process with this in mind.

Donal J. Rice wrote:

> > Start with publishing these in an accessible, structured format.
> > This will help identify the technical (such as authoring tools) and
> > organisational issues that need to be overcome and dealt withregards to
> > the publication process itself.

To break this down, how about something like this:

Employ accessibility experts to create MS Word template(s), an author's guide and a format conversion guide. Regularly produced document types (e.g. planning decision reports or regional managementplans) can have their own template. There can also be generic templates for things like application forms and miscellaneous documents.

These templates should define appropriate heading styles and contain placeholder examples of different content types, such as an image, a data table, a graph, a map or an interactive form. These examples will, as far as is possible in MS Word, be accessible. For each content type, the author's guide should explain the accessibility
issues, authoring best practice and the limitations of MS Word.

The format conversion guide should explain how to convert the MS Word document into HTML, tagged PDF and possibly other formats. It should outline the conversion procedure describing how to retain the accessibility information that is already in the document and how to create the required information where it is missing (e.g. adding the
data table markup that is not possible in MS Word). The organisation's staff should receive training and ongoing mentoring in the understanding and use of these tools and guides. The organisation should develop a suitable editorial structure and publishing procedures to ensure quality.

On Wed, 9 Sep 2009, Donal J. Rice wrote:

> > One of the progressive managers I know recently told me they
> > then pay the desk-top publishing house to 'tag-up' this PDF in
> > order for it to be accessible.

I think this is a good incremental step: but clients can and
should be advised to formulate this brief for the outside agency
more precisely and explicitly. In particular they should
be explicit that the delivered PDF must be not merely "tagged",
but "accessible". I suggest that be expressed as "conforming to
WCAG 2.0 level AA".

Beyond that, it would be ideal if they start moving now to
adopting some form of "accessible master format" as a "primary"
deliverable at least from such outsourced work (migrating it to
internal document authoring processes would, of course, be a
longer term process). The issues there are much bigger than just
accessibility; and the available tools are still immature. But if
this sort of requirement starts being built into procurement then
that would send a clear market signal that will actually
positively affect the availability of tools. There is a whole
other debate about what is an appropriate choice of "accessible
master format". Insofar as we are talking about public sector
agencies and public sector procurement I think this is a matter
of major public interest: it would be very useful if it could be
taken up in a co-ordinated way. But ... I've just spent 15
minutes trying, fruitlessly, to figure out, yet again, who, if
anybody, is currently responsible for "IT strategy" in central
government. But I did enjoy this page (albeit in a very grim,
Irish, "black humour", "In Bruges" sort of way):

which kind of says it all...

Hi,

I'd like to weight to both Mark and Donal's points. We've tried, for at least the last 8 years without success, to get various public bodies to move towards single source publishing. It simply doesn't work on the ground.

It requires too much business change and imposes too many additional and often unnecessary constraints on workers who already have too much to deal with. The best we can hope for is slow and incremental movement in the right direction such as CMS with workflow and well structured office documents.

Henry

Henry Poskitt wrote:
[...] We've tried, for at least the last 8 years without success, to get various public bodies to move towards single source publishing. It simply doesn't work on the ground. It requires too much business change and imposes too many additional and often unnecessary constraints on workers who already have too much to deal with. The best we can hope for is slow and incremental movement in the right direction such as CMS with workflow and well structured office documents.

Yes, Its also worth noting some tools that can be used to produce /only/ structured docs. Charlie Pike from TPG gave an example of one at the last IIA gig that was really interesting - can't remember what it was called. It was an enterprise level tool that only allowed you to create the semantic content - no presentation stuff IIRC.

Cheers

Josh

Barry wrote:

> > I've just spent 15 minutes trying, fruitlessly, to figure out,yet again, who, if anybody, is currently responsible for "IT strategy" in central government.

That would be the Technology Policy division of CMOD, located in Lansdowne House. They don't seem to have much details about it on the web but they are responsible, as far as I know, for this site on ICT procurement
frameworks. [1]

Joshue wrote:
[...] Charlie Pike from TPG >> gave an example of one at the last IIA gig that was really interesting[...]

Yes, that was an interesting tool but can't remember its name. Open Office also has good support for structuring PDF though I have not used it myself.

Again I think the public sector is some ways off being ready to migrate to anything other than MS Word.

Mark wrote:
> > Employ accessibility experts to create MS >>Word template(s), an author's guide and a format conversion >> guide. Regularly produced document types (e.g. planning decision reports or regional management plans) can have their own template.

Not in the current economic climate, you won't :) i don't think many organisations have the money to engage consultancies. I commissioned a plug-in for Ms Word developed by Eoin Campbell based on something I used to use in the Oasis project. It provides a menu and toolbar with a bunch of buttons that aid in the writing of a structured Word document. We use it in conjunction with a paid service to convert content to accessible HTML but used in isolation it still goes a good way towards to assisting the non-technical author to create a structured Word document.

It come with its own installer and instructions. i am happy to give it anyone who want it if they contact me off list.

Regards,
Dónal.
[1] http://ictprocurement.gov.ie/

The structured authoring tool that Charlie Pike mentioned at the IIA presentation was "Author-it" [1]. He said it takes formatting out of the authors' hands.

[1] http://www.author-it.com/

Regards,
Alan.

[...]Overview of tools for creating Accessible PDFs [...]

I agree that PDF accessibility is a subset of web accessibility, and it's important to address this aspect of any web site.

I just wish more people would ask and answer these questions before presenting data in PDF format: WHY am I using this format? Can this data be presented more simply and elegantly in another way (like HTML, the 'lingua franca' of the web)? Would adding a print stylesheet be sufficient?

And in those cases where PDF is indeed the best tool for the job, we need to use the best tool for making it accessible. At this point, Acrobat 8 or higher makes tagging easiest.

It's the same old story.To a man whose favorite tool is a hammer, everything looks like a nail. So javascript aces want to do everything in javascript, Flash developers want to do everything in Flash. People who have learned the basics of conversion to PDF, and are satisfied with that, may never look into what it takes to go one step farther and make it an accessible PDF. This self-satisfied tendency, more than anything else, is what impedes accessibility on the web. That, and the failure of many otherwise imaginative people to grasp the many reasons for doing this correctly.

Thanks for an interesting post. Roger Hudson is also thinking hard about accessibility support on his blog at http://www.dingoaccess.com.

You wrote:

But what about a complex data table or an interactive form? Can you use PDF for those purposes and still guarantee that people with assistive technologies will be able to read them? If not, then PDF cannot be said to be accessibility supported for data tables or interactive forms.

Can you use PDF for accessible complex data tables? Yes.

Can you use PDF for accessible interactive forms? Yes.

Can you come up with a data table or form that is so complex that it is not possible for a user with a disability to successfully read the document or interact with the form? Yes, as is the case with any format.

The WCAG 2.0 implementation report highlights a lot of information to bolster these claims, and we are currently working with the WCAG working group to provide techniques for PDF (and Flash) that will appear on the W3C site alongside techniques for other technologies. Take a look at the implementation report for PDF at http://www.w3.org/WAI/GL/WCAG20/implementation-report/PDF_accessibility_support_statement and you'll find information about tables and forms within it.

So in response to your question of what to tell your client, there are a number of options. You might tell them to stop using PDF, and maybe that would work for them, but they may have sound reasons for using it and then then they would hopefully ask how to make the documents and forms accessible. Adobe provides a number of resources to help document authors and form developers address accessibility. These can be found at the Adobe accessibility web site (http://www.adobe.com/accessibility).

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.

I have been reading this article and comments with much interest. We have been trying very hard to bring all of our website content up to par with accessibility. One of the problems I have encountered with pdf's is the use of Ramseyer format for proposed charter amendments. Authors have also used other methods in addition to these such as strike through text and colored text. None of these get interpreted by screen readers that I know of so I'm still scratching my head trying to figure out how to present these so they are accessible. Some of the documents are quite lengthy so recreating them in html (not to mention the fact that a lot of Hawaiian words use special characters) would probably be out of the question. I admire Adobe for the work they have done on making PDF's accessible and am learning more every day. This has been quite a learning process and then I also have to share the knowledge with others. I appreciate being able to go online and find such informative and helpful information as is supplied here. Mahalo!

yvComment v.1.22.0

Home