WCAG Samurai Peer Review: Part 1
I’ve been reading through Gian Sampson-Wild’s technical review of the WCAG Samurai Errata and she seems to have picked up on most of the points that I noticed but is perhaps over-critical in other areas. In this post, I’ll confine myself to looking Gian’s comments under Accessible Technologies.
The Two Standpoints
PDF files published by the normal means (e.g., a simple hyperlink to the PDF) are not non-text information and do not need text equivalents. WCAG Samurai Errata
It is my opinion that although these technologies do contain some accessibility features they do not currently contain the type and variety of accessibility features inherent in HTML. … until that time I believe that these technologies must be considered non-text content and treated accordingly.
The Middle Ground
I think both camps are taking somewhat extreme positions.
PDFs are text content. Even when they are improperly tagged and structured, they are still text content. I don’t think that Gian can expect people - even for an interim period - to accept that they are not.
That said, we need to be mindful that many of the PDFs currently online do create barriers for some user groups. Not because they are in PDF format but simply because they have not been created in a structured or accessible manner. So the designer needs to ask two questions:
- Is this an accessible tagged PDF document?
- If not, does it contain important information that would be inaccessible to any disabled user group?
If the answer to Question 1 is “yes”, no problem. We don’t need any text equivalent.
If the answer to Question 1 is “No”, then we need to look at what the PDF document contains and why it is being published using this format before we can decide if a text equivalent is necessary.
PDF Examples
Let’s take two very different scenarios:
Scenario 1
The site owner wishes to publish a user manual in PDF format and has no intention of providing this material in HTML format.
In this context, it is essential that all user groups can access all of the information that the PDF document contains onscreen. So, unless we are sure that the document is already accessible, I’d argue that we must provide a text alternative. It’s not that difficult. At the very least, it takes very little effort to create a plain text version of an unencrypted PDF using an on, or off, line tool. The end result may not be pretty but at least, by using the lowest possible common denominator, we can be reasonably sure that the text is accessible by all types of assistive technology.
Scenario 2
The site owner wishes to publish a poster or flyer for an event — the details of which have been already expanded fully elsewhere on the site - simply so that interested parties can print and display copies.
In this situation, I see no real reason for providing a text equivalent. This is not a document that is meant to be read onscreen. It’s meant to be printed. Once printed, it can be accessed by anybody using whatever means they normally use to read printed material — whether that be donning a pair of glasses or ensuring it’s printed using a braille printer. It’s simply not a web accessibility issue, in my opinion, and therefore we don’t need to do anything.
Flash and Other Technologies
The broad principles that cover the use of PDFs could be extended to cover Flash and other scripting technologies. Irrespective of what technology is being used, the prime question has to be “Will any user group suffer if they cannot access this information?”
In some situations, I may choose to offer a text based method (HTML) to explain a complex process to those users whose primary method of comprehension is verbal. However, I may decide to supplement the text with a Flash presentation specifically aimed at anyone who may have a reading problem. Graphical tools can, and do, offer ways of presenting complex and difficult concepts in a manner that can be absorbed very easily by some people.
In general, there are a number of very distinct ways of absorbing information. Everyone, irrespective of any disabilities that they may have, absorbs information far more effectively if they can make use of one of their “preferred” learning methods. So it makes sense to sometimes present the same information in a number of different ways. In a sense, it’s accessibility through diversity.
In this context of using technology suppoprtively, I don’t see that it really matters if the Flash presentation is accessible or has a text equivalent providing it is, in itself, an alternative communication vehicle and that users can bypass it easily with the minimum of fuss.
Neither the Errata nor Gian seem to really touch on this.
Furthermore, Gian seems to suggest that my hypothetical Flash presentation must be treated as non-text content and have a text equivalent when I would argue that the Flash file is a graphical equivalent of the pre-existing page text.
Suggestion
Reword the relevant point under “Corrections to Guideline 1.1″.
Correctly structured and tagged PDF files published by the normal means (e.g., a simple hyperlink to the PDF) do not need text equivalents. Less accessible PDF files intended for print are not non-text information and do not need text equivalents. Other PDF files intended for onscreen use, or that contain information that is not available elsewhere on the site, should be accompanied by a text equivalent.
Add something to cover supplementary technology usage.
“Applets” and “scripts” - including Flash - do not need to be intrinsically accessible or be accompanied by text equivalents providing they are offered as alternatives to existing, accessible text information and can be easily bypassed.
Summary
As I understand it, one of the guiding principles behind WCAG Samurai Errata is to remove as many as the “what if” and “until when” phrases as possible. But, in reality, accessible web design is rarely a choice between simple black or white. Although Gian is correct to raise the issue that many PDFs, scripted solutions and Flash presentations are not as accessible as they should be, I think she goes too far in the opposite direction.
We need at least one shade of grey here.
I’m willing to look at further requirements for PDF, but PDFs are not loaded into a Web page and are not non-text content. PDFs are not Web content any more than zip files are. You download both and deal with them outside the browser. Sorry, kids.
I see no contradiction with your argument and what I wrote in my peer review. In all the examples above the provision of information via non-HTML (Flash, PDF etc) was an alternative to existing content within the web site. Where content exists in a web site and an alternative Flash or PDF version is provided then I do believe the site is accessible. What I do have a problem with is content - say a manual like you described above - being provided only in PDF with no alternative. Even if the PDF is tagged using the accessibility features in Adobe Acrobat, there still will be people with disabilities that can’t access it.
And just for the record - I am female.
Gian Sampson-Wild
FYI Gian is a “she”.. good points however.
Joe: That’s really thin ice there. I can easily see some people arguing that video files offered as links are not loaded into a web page and are viewed/dealt with outside of the browser and that, therefore, there’s no need to caption them.
If you do feel there’s a real distinction to be made here, might I suggest that we need a very clear definition of what constitutes a browser plugin and what is a standalone application? Otherwise, I can see a very big loophole opening up.
Gian: Please accept my apologies over the pronoun mix-up. In theory, I’m the last person who should have fallen into that particular gender trap since I’ve also been on the receiving end of it too. I’ve amended the post accordingly and self-administered a mental slap on the wrist.
With regard the the PDF issue, however, surely there has to be a point where the web designer’s responsibility stops? Having done our part to try and ensure that a PDF is as accessible as possible, I’m not convinced that we should be making up any remaining shortfalls. That’s Adobe’s responsibility - not ours.
Gary: Duly noted. I’m still blushing over that particular gaffe …
[...] to my previous post, I’m continuing to read through Gian Sampson-Wild’s technical review of the WCAG [...]
Joe Clark:
Most PDFs I come across are loaded within the browser window rather than in a separate application. (This makes them even more confusing, for a lot of people).
I don’t see why you think you can ignore the use of PDFs - they are still part of the website, whether they are in HTML format or not. If they form an integral and essential part of the website - just like HTML pages, audio and video clips, etc - they must be accessible. If the PDFs are not, in themselves, tagged and accessible, the information must be available in an alternative accessible format. Likewise, I wouldn’t want to see essential components of a webpage published as linked .doc (or .odt!) files unless these were written so as to be fully accessible. Such documents do form part of the content of websites, much as we might sometimes wish they didn’t!
I would have thought that producing guidelines on making content on websites accessible was what the WCAG was all about. I’m sorry that you seem to think otherwise.