PDFs breaching the DDA
Isofarro's take on the same event is here :
http://www.isolani.co.uk/blog/access/RnibAccessiblePdfMediaBriefing
(I know he's posted the link elsewhere on the forums but I thought it might help being in the same thread).
[offtopic]
Two people, same event, different experience? Sounds about right.
It's like if I go out with a tie on, and my black shoes on, I can have a great time, but the people I'm out with don't. Just ask Pix and Daz.
[/offtopic]
Share: 
| Alastc wrote: |
| 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. |
One of the comments from Greg Pisocky - Adobes Accessibility Manager - was that accessible PDFs really start with Adobe Acrobat version 7. He quickly demoed adding alternative text to an image, it was just a click on the image to select then a menu option that displays a dialogue box for entering the alternative text.
In terms of generating tagged PDF - its a similar concept to HTML. You could specify a block of text and tag it as a paragraph. The best approach, the Adobe guys mentioned, is to start with an XML file and import that into a PDF. That solves the structured and tagging bits - and perhaps the alternative text on images too.
Share:
| Lee28 wrote: |
| I hope people like yourself can give us more info on here in the near future about how easy these features are to use. |
I will be getting Acrobat 7 Pro soon, but there is one fairly inescapable fact for creating PDFs: the source is vital.
If the source isn't Word 2000+ or decent HTML, it is more effort than it's worth. As Isofarro said, Garbage In Garbage Out, and for Acrobat that generally means a word doc with alts on the images is needed. Even then you often need to edit the tags. If the source is image based, you are probably better off creating an alternative.
<Shameless plug>
I believe we (that is, nomensa) are putting together a brief course on it for next year. It isn't aimed at people here, or something you couldn't work out yourself with a copy of acrobat 6/7, Joe's article and reading Adobe's documentation; but we'll package it up nicely with practical examples and tackle the most difficult things people can find for us. Mainly aimed at Gov & Corporate non-technical content editors, who seem to produce the most PDFs!
</Shameless plug>
The next challenge for my more technical colleagues will be creating tagged PDFs from XML sources, but that will have to wait for a little while due to more immediate projects.
Share:
| Isofarro wrote: |
| One of the comments from Greg Pisocky - Adobes Accessibility Manager - was that accessible PDFs really start with Adobe Acrobat version 7. |
Damn, I've been trying since version 5!
That's good to know, I'll update before we do another public report in PDF. However, a demo is one thing, it will be interesting to see if that means tables & things are easier to do and to correct.
Share:
| Alastc wrote: |
| That's good to know, I'll update before we do another public report in PDF. However, a demo is one thing, it will be interesting to see if that means tables & things are easier to do and to correct. |
From the demo Hugh Huddy gave, sounds like tables can be done correctly - it as if it were tables navigation mode in IBM Homepage reader. Whether its easy to do - I think Adobe still need to do some work to make it easier.
Share:
| JackP wrote: |
| Isofarro's take on the same event is here :
http://www.isolani.co.uk/blog/access/RnibAccessiblePdfMediaBriefing |
Different event, different purpose I suspect. The seminar I attended was directed at developers who were interested in learning about creating accessible documents for download. From Mike's account the RNIB briefing was more comprehensive, technical, authoritative and possibly promotional (given Adobe's presence).
| Quote: |
| Two people, same event, different experience? Sounds about right. |
As I've aluded to above, the lack of an Adobe rep at the seminar I attended may have allowed Hugh to be more forthright in his assessment of the capabilites of Acrobat v7 and Reader v7 with regards to screenreader users. That said it's very encouraging that Adobe are working with RNIB and being open enough to share the platform at an event like that.
This isn't a situation Adobe can fix themselves - accessible PDFs don't happen by software magic, they need to be designed correctly from the start.
The source of the problem in my experience is users who don't know how to use their source software correctly - I see daily very large MS Word documents where headings have been created by selecting text, resizing it and making it bold. Not a style in sight. Those documents are never going to be accessible, whether converted to PDF, HTML or whatever, because we simply don't have the resources to correct those sorts of fundamental errors. In this case it's our problem, and a training issue, and no matter how good Acrobat 8 is it's an issue we need to overcome (and I'd be very surprised if we were alone in this camp).
Dan Champion, Champion IS, Mooch Marketing, Revish
Last edited by danchamp on 26 Oct 2005 03:01 pm; edited 1 time in total
Share:
please don't post a pic as proof!Share:
| Lee28 wrote: |
| 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".... |
Lee if it's any consolation we're kinda on the same boat here. We want to produce authorative guidance on when to create PDFs and how to create accessible ones but I find this area the same as yourself, too many ifs and buts.
We have a high end CMS so there's no problem for authors to create compliant html pages. To get people out of the habit of creating PDFs is a different matter though and the starting point is comprehensive advance on the whys and wherefores.
Share:
| Daz wrote: | ||
Lee if it's any consolation we're kinda on the same boat here. We want to produce authorative guidance on when to create PDFs and how to create accessible ones but I find this area the same as yourself, too many ifs and buts. We have a high end CMS so there's no problem for authors to create compliant html pages. To get people out of the habit of creating PDFs is a different matter though and the starting point is comprehensive advance on the whys and wherefores. |
Just show them the pictures on the Frappr accessify page and explain that if they use PDFs, Patrick will be round to offer a little 'friendly advice'
Share:
That would be a rather rich and ironic misreading of the extremely plain language of my A List Apart article, which states in no uncertain terms that you have no business using PDFs online unless they fall into one of 14 very limited and unusual categories.
Anybody want to take these wankers to the DRC? I'd love to testify.
Share:
Unfortunately some people have taken it as "PDFs can be accessible therefore it's OK to use them", without paying attention to the details.
Not generally developers (unless it makes life easier for the unenlightened), but some managers & decision makers. No fault of the article, but removing the previously simple (if inaccurate) story of "PDFs are not accessible" has been taken as a green light for using PDFs.
Share:
That's exactly the problem. After a long discussion about when you should and shouldn't use PDFs on the publicsectorforums website, one local authority manager posted a link to Joe's article on ALA, simply saying "See, PDFs are accessible". 
It's hard to make people read the details, when what they want to hear is, "yeah, no problem. Keep those 14,000 existing PDFs they're fine."
Share:
To be fair, rather than spend time/money converting 14,000 PDFs, I'd try and persuade them to create processes that mean they don't produce any more (that aren't necessary).
Share:
The organisation i'm working for at the moment are so large, and with so many content creators for their site, that it's impossible to put any definitive processes in place.
I'm writing some guidelines, but unfortunately it's just too large for anyone to monitor if these guidelines will be properly adhered to.
Also, it tends to be a merry-go-round of the same conversations.
1.) Use PDFs only when necessary.
Fine.
2.) Make them accessible if you have to use them.
Fine.
Then, once they realise they can be accessible to some extent, you can see that point one is going to go out of the window, quickly followed by point two.....
I agree that the existing docs can't all be removed/updated in one fell swoop, and I think any large government organisation is going to be stuck with this problem for some time yet.
It's linked in to the whole attitude that IT departments, and also accessibility laws, are working "against" the users/content authors. As long as they see it all as negative they won't have the desire to produce their PDFs properly.
As well as trying to guide them towards accessibility, i've also been suggesting to my current employers that we need to emphasise the positives of what we're doing, so that people are aware we're not just trying to make their lives harder. Unfortunately, with old-skool PDF documents proliferating at a rapid rate, that's going to be hard to achieve, because the fact is we DO want to stop people using PDF as the soft option, and it is going to make their lives harder.
That's the big problem with creating accessible PDFs. From what little i've seen and read, it sounds like the process needs to become much easier, because in my experience it's not developers creating these PDFs, it's the non-technical staff looking for a non-technical way of creating nice designs.
Share:
| Alastc wrote: |
| To be fair, rather than spend time/money converting 14,000 PDFs, I'd try and persuade them to create processes that mean they don't produce any more (that aren't necessary). |
plus, i'd say have a system in place where the old PDFs are converted / retrofitted in order of importance/popularity based on server stats, and add a notice (plus relevant processes) that allows visitors to request a PDF in an alternative format, and convert that one as and when required.
Patrick H. Lauke / splintered
Share: