PDFs breaching the DDA
| Cerbera wrote: |
Spending resources on the rare and specialist knowledge required to make PDF documents "accessible" seems like something of a waste. If these documents were converted into HTML web pages then accessibility would be immediately improved and the usability for all visitors would be infinitely better. HTML suits the Web far better than any other format, which isn't particularly surprising.  |
To a certain extent I agree with you Ben, people need to think HTML first before creating PDFs, often their easy way out. The problem is there will always be cases where PDF is the only answer. Joe Clark's article gives some good examples, such as documents which have endnotes, sidenotes, footnotes as HTML has no equivalent.
I'd reinforce my opinion again, to ensure maximum accessibility only use PDF when necessary, ensure it's properly tagged if you do, create a gateway page for every PDF and never link directly and lastly always give contact information for obtaining hard copies or alternative formats.
Share: 
| Daz wrote: | ||||
Complaining often won't get you anywhere or may take up to 16 weeks as I know some Gov Department have to wait this long for a simple network change. |
This is still not a problem a web developer or software vendor should have to concern themselves about. Its clear the problem squarely lies in the department that is offering you that restricted service.
If the organisation you work for (or purchase a service from) doesn't allow you to use the tools required to do your job properly - that's a matter to escalate internally within that organisation.
Share:
| Isofarro wrote: |
| This is still not a problem a web developer or software vendor should have to concern themselves about. Its clear the problem squarely lies in the department that is offering you that restricted service.
If the organisation you work for (or purchase a service from) doesn't allow you to use the tools required to do your job properly - that's a matter to escalate internally within that organisation. |
I appreciate where you are coming from but it's a reality web authors have to accept. The same as we accept some people browse with javascript turned off. We can tell them to turn it on, give instructions etc in order to receive certain info or functionality, but at the end of the day if they can't for whatever reason or simply don't want to then we have to provide an alternative.
Share:
| Quote: |
| Isofarro: You're on a different bandwagon. Please have the decency to name it differently, and not pass it of as web accessibility. |
Thanks for that. I did say that it was my opinion, and that I don't believe the definition of the W3C WAI should necessarily be the be-all and end-all.
Also, i'm having to cater for the fact that some users don't have Javascript enabled, but really those users should get a better browser shouldn't they, by the same argument? The technology's available.....
Anyway, i've no desire to get into a personal fight over (of all things) PDFs, so i'll leave it there.
Last edited by Lee28 on 26 Oct 2005 11:26 am; edited 1 time in total
Share:
Dennis asked me to point out the following before I posted the article.
| Dennis Kessler wrote: |
| When you post the article, I'd be grateful if you could note that the article is based on my coverage of the Adobe event at the RNIB last Thursday. This opinions it contains represent a combination my views and those of the RNIB's Hugh Huddy - it's not all my own original thinking. Some of the specific points on which I think you disagreed were in fact made clearly and strongly by Hugh Huddy during his excellent
presentation/demonstration. |
and then here's the article itself...
| Dennis' article wrote: |
| Adobe Acrobat is the original tool for producing PDFs. But it isn’t an authoring tool – you don’t use it to create a memo, or a spreadsheet or a presentation. Instead, Acrobat takes that letter or spreadsheet or presentation and converts it into PDF format.
This means that PDF is a destination format – it’s designed to be a result, not a starting point for converting into some other format. In fact it was originally designed for printing. The great virtue of the PDF format is still that it preserves the formatting – text styles, layout and graphics – of the original document. There has been an explosion in the use of PDFs as downloadable documents. The number of PDFs available for download on the Web now runs into the hundreds of millions. By providing its Acrobat Reader product free and ensuring versions were available for numerous popular platforms, Acrobat has established its PDF format as a de facto industry standard format for exchanging documents across a wide range of platforms and systems while preserving presentation, graphics and layout perfectly. What’s more, it’s officially recommended in e-Government and other public sector standards as the format of choice for non-HTML content (ie, for providing documents other than web pages). Yet despite the popularity of PDF documents, problems remain for public sector organisations whose online information and services must be fully accessible. It seems that few of the content owners, publishers and web teams which happily create and publish PDFs on their websites are aware that, unless they’ve carried out some specific and sometimes complex steps, their PDFs are highly if not completely inaccessible. These failures put them in breach of the relevant bits of eGovernment policy which require the content and services of government websites to be fully accessible – the eGovernment Interoperability Framework (eGIF) in general, and the “Priority Outcomes” for local e-Government produced by the Office of the Deputy Prime Minister. And there’s worse that will come as an even big shock to many site owners: If you’re creating and publishing PDF documents on your website which aren’t accessible, you’re also in breach of the Disabilities Discrimination Act (DDA). Why in breach? Because parts of the DDA relating to information and services provided via the Web cover all content on your site. This means all content – including downloadable PDFs – has to be accessible, not just web pages. This makes sense, given that interoperability is all about allowing content and data to be exchanged between as many different systems as possible – implicitly including access by people using any platform, system and access or assistive technology. Whereas early versions of Acrobat were completely inaccessible, Adobe has been working to rectify the mistakes of the past and mitigate their impacts. At an event on PDF accessibility hosted by the Royal National Institute of the Blind (RNIB) on October 20 in London, Adobe showed how its latest version of Acrobat contains new features to make existing PDF documents more accessible to people using some assistive technologies. At this event Greg Pisocky, US-based senior accessibility specialist for Adobe, admitted that a PDF document will never be fully accessible. This means that he doesn’t expect a PDF document ever to achieve the same degree of accessibility offered by an optimally produced XHTML equivalent. Nonetheless, he boasted of the richness of accessibility features offered by Acrobat 7 Professional, the latest version of the Acrobat platform. This includes specific support for screen readers – the browser add-ons which read out the contents of web pages and other documents to people who are blind or visually impaired. For a PDF document to be as accessible as possible, it has to be “tagged”. These tags are additional information hidden within the document which provide a screen-reader or other non-visual application with details of structure, text flow and alternative text for graphics. Ensuring correct text flow is especially important for non-visual users, as without the ability to see the page, they are depending on their access technologies to deal correctly with multi-column layouts, or multiple text blocks embedded within a single page. Without this information being present, screen-readers and their users may simply be unable to navigate or make sense of a PDF document which a sighted user would have no trouble reading from start to finish. While the previous version of Acrobat allowed screen-reader users to access and navigate “tagged” PDF documents successfully, Acrobat 7 supports many features for untagged documents. This is potentially a big step forward, as the vast majority of PDF documents produced are untagged. Despite this, untagged PDFs still represent a serious barrier to non-sighted users. Why are so many PDFs untagged? Because relatively few people seem to realise this additional tagging information is needed to ensure an accessible result. This isn’t entirely Adobe’s fault. If you remember to provide an alternative text description for an image appearing in a document or presentation that you then convert into a PDF, Acrobat will happily find and retain that description within the PDF. But if there’s no alternative text in the source document, then there’s nothing for Acrobat to use in the PDF version. And that means that someone using a screen-reader to try to read that document may discover that there’s an image there, but they’ll have no way of knowing what it is. Although Adobe provides online guidance and training on accessibility support for its Acrobat products, you have to be pretty determined to find it buried within the Acrobat section on the Adobe website. And the PDF guide which Adobe provides for this process (well tagged, we assume) comprises 115 pages and weighs in at a hefty 10.5 Mbytes. And this is the real problem: tagging a PDF document to ensure optimal accessibility is a complex process requiring skill, judgement and no small amount of knowledge. So even if many web teams become aware of the need and techniques for this additional step, it’s unlikely that many will have the time or resources to do this every time they pump out a new PDF on their website or intranet. Just consider the RNIB’s own experience of attempting this. At the PDF accessibility event in October, Hugh Huddy, part of the RNIB’s Digital Policy Development team, demonstrated the experience of a screen-reader user trying to access an untagged PDF compared with that for a well-tagged document. Mr. Huddy, a former graphic designer who lost his sight in his twenties, showed how the screen reader he was using struggled to navigate the untagged document. But for the well-tagged, well-structured document, in this case a PDF version of the RNIB’s annual report and accounts for 2006/06, he claimed the experience came close to feeling as if he was actually reading the document as a sighted reader. As well as being able to “read” the text content, he was also able to navigate through complex tables of financial data with ease. Despite the dryness of the subject matter, there was genuine emotion and passion as he explained how liberating it was to achieve such an unprecedented degree of access to such complex and varied information. But the problem is that, despite the success of the end result, achieving it was anything but easy. Mr Huddy explained how the RNIB set itself the goal of producing an accessible PDF of its annual report and accounts for the first time. But the RNIB team responsible had so much trouble that they reached an impasse and had to call in external consultants to get the job done. And if a dedicated team from the RNIB can’t do this, what hope is there for those of us with more modest resources available – not to mention time constraints? Acrobat 7 may indeed represent a step forward in the right direction. But the manual effort required to create a single accessible PDF will simply be beyond the means of the web teams or publishers in many public sector organisations. And although many screen-reader users will, like Mr Huddy, benefit from the improved accessibility offered by Acrobat 7, he was in no doubt that it’s still too complex and too difficult to get this right. While Adobe is moving in the right direction, it still needs to do much more to improve the current situation – and do so faster. And if the eGovernment Unit are serious about expecting owners of government other public sector websites ensure their online content is fully accessible, they are going to have to provide a lot more guidance and support to help people wade through this morass. |
it's stirred up quite a debate, no?
Share:
Jack, just out of curiosity who is Dennis Kessler? It's worth pointing out the new UK Government guidelines for websites (yet to be published) give advice on creating tagged PDFs and make reference to gateway pages.
Share:
He's one of the contributors to our neighbours accessify.com as it happens. He's also an independent consultant and a board member of the BWDMA's Usability & Accessibility Working Group. But he says he might join us later with his own points so he can tell you more himself if he does.
Share:
I attended a seminar at the Dundee accessible design conference in September where Hugh Huddy presented on the issues with PDFs. He gave a live demonstration of a screen reader processing a tagged PDF, and I have to say I was extremely disappointed with the results.
I can't put my hand on my notes right now, so this is from memory. The reader detected headings, but presented them as 'links'. It couldn't sort headings into different levels. In short it was almost impossible to navigate any reasonable sized PDF with a screenreader.
Hugh also presented the findings of a survey of screenreader users where they were asked which document format they preferred for online documents. MS Word came top, followed by ASCII and Excel. PDF wasn't mentioned at all.
When I find my notes I'll flesh this out, but I concluded from the seminar that the best alternative to PDF for us was MS Word. Currently we continue to post PDF, Word and ASCII versions where possible, but we now view PDF as the least accessible. The biggest problem for us comes when the source is InDesign, Quark or similar - ASCII is the only real accessible option in that case.
Dan Champion, Champion IS, Mooch Marketing, Revish
Share:
Thanks Jack that would be good.
Share:
| Cerbera wrote: |
| This difficulty of use creates real barriers to many users, who should not be required to learn yet another interface. |
Not all data out there can be bodged into HTML. You, and probably everyone in here uses only HTML all day and every day as the only data format. Its impractical and unrealistic.
| Cerbera wrote: |
| PDF a format which is only useful when downloaded to disc and read like a book. It is a very bloated and clumsy format which simply isn't suitable for Web browsing, imho. |
PDFs and HTML are not perfect complements - thats where you are going wrong. PDF has many uses HTML would be piss-poor at, equally so vice-versa.
You can argue as much as you like that certain uses of PDF would be better off as HTML, but you'd not be able to cover all of the PDFs features in this way.
| Cerbera wrote: |
| Spending resources on the rare and specialist knowledge required to make PDF documents "accessible" seems like something of a waste. |
The work involved in converting an inaccessible PDF to a web page or to an accessible PDF is the same. The "specialist knowledge" is almost roughly equivalent to the "specialist knowledge" to create an accessible web page.
| Cerbera wrote: |
| If these documents were converted into HTML web pages then accessibility would be improved and the usability for all visitors would be better. By applying common techniques for accessibility, the pages would become endlessly more accessible and usable. |
I've seen the output created by organisations doing exactly this. What comes out is a series of HTML pages - one for each page of the PDF. Every HTML page contains one image - the image that was in the PDF in the first place.
Your solution now exasperates the problem. The problem isn't the PDF format itself, its how the content inside the PDF is arranged. Remember a PDF document can contain plain text, a number of image formats as well as XML. Its not as straightforward as you claim.
| Cerbera wrote: |
| HTML suits the Web far better than any other format, which isn't particularly surprising. |
This is where the fundamental disconnect is happening. The average knowledge worker does not have the Web as their single source of information.
Even web wise - HTML is a piss-poor format when it comes to archiving information offline. Ever tried managing a directory of saved HTML files? Its horrible. When buying a life assurance policy online, people wanting an electronic copy of the terms and conditions of the policy tend to opt for a PDF rather than an HTML, CSS and 20 odd image dump of a web page.
Share:
| Isofarro wrote: |
| Even web wise - HTML is a piss-poor format when it comes to archiving information offline. Ever tried managing a directory of saved HTML files? Its horrible. When buying a life assurance policy online, people wanting an electronic copy of the terms and conditions of the policy tend to opt for a PDF rather than an HTML, CSS and 20 odd image dump of a web page. |
Simon Pieters
Share:
Two comments:
Cerbera: I think you've got your web guru head on again. Not everyone has the level of HTML ability, and working in a local authority I can vouch for the fact that most users think word documents, excel spreadsheets and pdfs first, html pages second. In any large organisation it only tends to be developers who see html as the format of choice. You therefore have massive resource implications if you say every PDF needs a HTML equivalent. It may actually prove to be impractical (cost, resource, time)for some organisations to do this. I would imagine many organisations/authorities will eagerly await the to-be-published government guidelines to better know what is expected of them - legally at least.
Iso: re Lee28's usability/accessibility thing earlier. I've got to side with him on this. If a site is not usable, it cannot be accessible. Yes, they are different - a site may be usable to a user without any limiting conditions, but may be inaccessible and therefore unusable to those with one or more limiting conditions. I would tend to say usability and accessibility (and for that matter standards compliant design) all go hand in hand, and should all be considered by developers/designers whenever they are introducing new web content.
Share:
With regards to providing alternatives to PDF formats for content authors pressed for time, there's a handy area on the Adobe website that will convert PDFs to text or HTML ( I haven't checked their HTML output personally).
http://www.adobe.com/products/acrobat/access_onlinetools.html
Share:
| danchamp wrote: |
| Hugh also presented the findings of a survey of screenreader users where they were asked which document format they preferred for online documents. MS Word came top, followed by ASCII and Excel. PDF wasn't mentioned at all. |
It is worth noting that screen readers (this coming mostly from knowledge of Jaws, others may vary) have to be configured to work with just about any application. There is probably a certain amount of catching up that they have to do with the progress that Adobe have made, and then the even longer process of the users finding out about it.
Also, since the tags don't directly equate to HTML, this job is probably harder than it could have been.
Oh, and for the person who had trouble with their browser freezing, I had the same thing (on a well specced machine), I'm guessing you were on Acrobat reader 6? There are a couple of solutions. The first thing I tried was an alternative reader, I think it was Foxit - very quick, but you can't select text or use any advanced fuctions.
The other thing is to update to Acrobat 7 reader, and make sure you adjust the options so that it doesn't load in the browser - a much better experience. Acrobat 7 also seems to load quicker anyway, I had thought it would be more bloated.
On one of Isofarro's comments on the publishing tools being equivelent for HTML and PDF - that isn't what I've experienced (NB: with Acrobat Pro 6). I know the theory is right, but I don't think it's there yet.
For HTML, there are a variety of editors, and a few can produce good code from a fairly easy WYSIWYG interface.
Acrobat (6) allows some access to the 'tags', but the interface is a nightmare for doing anything behond the very simple. trying to mark up a table usefully is nigh on impossible, and even images can be hard to find through the interface. As Dennis said, it's a difficult process, I'm really hoping that version 7 improves on this.
Share:
Thanks Alastic, i'll try Foxit.
With regards to your other points, i'd be really interested to get some more detail on the reality of this whole PDF situation for users of alternative user agents like screen readers, and also the realities of creating tagged PDFs.
I hope people like yourself can give us more info on here in the near future about how easy these features are to use. The team i'm working with at the moment are looking at producing our own tagged PDFs so we can give the content authors some guidance, but at the moment we don't really have a clue. Too much of this area is "ifs" and "but's"....
Share: