RE: PDF in WCAG 2

On Tue, 17 Aug 2004, Patrick Lauke wrote:

> > It is sometimes necessary to use pdfs exactly because equivalent
> > HTML files don't exist

but could exist with a little additional work

> What type of content within a PDF is there no HTML equivalent for?
>
> > or is too expensive to make available
>
> Fair enough, cost can indeed be an issue, particularly when there's a
> large backlog of legacy documents.

but the vast majority of pdf files out there are NOT old,  if maybe there
was a statement that pdf could be used on legacy documents OLDER than X
years old (maybe originals older than 50years old)

> > Very often we need pdf files because they are an easy and handy way to
> > make a lot of important information available to most users
> > at almost no additional costs.

but mostly because of lazyness.
>
> "Most users" certainly depends on the target audience of your site.
> Also, if it is so important, I'd see that as an extra incentive to actually
> devise accessible alternatives.

MOST common example of pdf files that I find currently is bus/train/plane
schedules.  and who is almost universally dependent on public transport?
visually impaired folks who can't drive and need to check on the bus
schedule.  They are almost never avaliable in alternative format (I have
never even heard of a city bus schedule in braille for example) yet try to
find the local bus schedule in a text format that can be used by a screen
reader.

most transit systems say "call the information line" which in reality is
only open a limited amount of time and usually leaves you on hold for 20
minutes until you can get the information you needed 20minutes ago because
the bus went by 10 minutes ago and it's a half hour til the next one

REAL WORLD is not a legacy document...

> > Think of archives from The Second World War
> > written on
> > a typewriter with hand written comments in the margins, handwritten
> > dairies, etc. You can make such material available for most
> > users (99%)
> > in its original historical look and feel at almost no costs.
>
> Again, I'd object to the 99% statistic.

and how,  maybe, just maybe 5% of the pdf files currently used are truely
things that could not be presented in more usable format.  and legacy
document such as WWII hand written material is I suspect well under 1%
most have never been scanned into electronic format of any kind!

> > Making the same material available also in HTML, the material
> > would not only loose all its historical authenticity,
>
> How so? Yes, it may lose its visual/presentational values, but the
> content should not lose anything, no?
>
> > We can make
> > fast and dirty pdfs as easy as using a copy machine.
> [...]

AH the real reason is apparent, it is just too much trouble to make the
information avaliable for everyone...isn't that the purpose of WAI???

> >  making the material
> > available in the newest brand of accessible tagged pdf files,
> > is also a
> > multi million dollar project.

and they are only marginally usable then.

> [...]
> > Pdfs in WCAG-1 was also far from ideal since we still have a lot of
> > material that is pdf in origin. Just think of glossy annual paper
> > reports, fact sheets about products, etc. With almost no extra costs
> > such material, originally used as print files, can be served
> > also on the
> > net.
> [...]
> > Such material has a lot of pictures, a lot of data tables,
> > and a lot of
> > graphs and descriptive statistics still difficult to convert to
> > accessible tagged pdfs in an automated process or into
> > accessible XHTML.

which means that if I own X number of shares of that company my investment
is not valuable enough to provide me with the information to make informed
decisions??? (as an example)

> So, if I understand you correctly, you're bemoaning the fact that to
> achieve WCAG1.0 is not fast, dirty or cheap, and cannot by done simply
> by automated means?

NOW THIS is the true excuse and none of the above?!

> > We need
> > some rules of thumb that can help us in the decision making
> > process when
> > and how and during what circumstances it is acceptable in the final
> > analysis to serve a quick and dirty pdf even without an
> > equivalent HTML
> > file.
>
> That final analysis rests with you, and in my mind it's quite simple:
> if you want to be able to claim compliance with WCAG1.0, you need to
> address the issue of PDFs. If you don't have the resources, time,
> technology, whatever to convert your PDFs to an equivalent, here's a
> crazy thought: don't claim WCAG1.0 compliance for that particular section.
> You could easily write an accessibility statement clarifying that your
> site complies with WCAG1.0 AA, except for the PDF archive - but that
> you're willing and able to provide the content of the PDF in alternative
> format upon request on a case by case scenario, perhaps (much in the same
> way that, say, you would not convert all your paper based literature to
> braille and keep it in stock, but have mechanisms in place to provide
> braille versions upon request, within a reasonable time scale).

but what is a "reasonable time scale" the guy trying to finish a term
paper for college needs the document "NOW" not a week after the paper is
due.

contract documents usually have deadlines, how does one bid on a contract
if the specifications come after the bid deadline.

and of course see the above example about transit schedules..

> > How then has WCAG-2 clarified the use of pdfs? Are we getting new and
> > better guidelines that can help us out in our daily work for a more
> > accessible internet?
> >
> > Nothing at all. The original pdf-issue has even died without
> > a whimper
>
> Maybe I'm over-interpreting, but: I would class PDFs as non-text content
> (particularly if the PDF is merely a container for scanned documents), in
> which case the very first guideline, 1.1, would apply. This possibly needs
> clarification in the current WCAG2.0.

I have to agree, it probably needs clarification

> > and is no more to be found anywhere in the accessibility guidelines
> > proper or in the supplementary documents about HTML and CSS.
>
> As PDFs are not a W3C technology, and they're not HTML or CSS, then I sort
> of see the logic of them not being mentioned in the HTML or CSS documents...

and it could be said tha pdf in and of itself is not accessible since it
requires proprietary software to read it, and most of the adaptive crumbs
avaliable for pdf are not avaliable in operating system enviorenments
other than windows...(if not WAI it is a 508 problem.)

maybe it is my tuesday morning cynical nature but it also seems the more
demanding the enviorenment the less likely the document will be avaliable
in an accessible format.


Bob

(a subparagraph of murphy's law,  "the more important the document, the
less likely it is to be accessible"!)



++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CONFIGURE YOUR E-MAIL TO SEND TEXT ONLY, see http://expita.com/nomime.html
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

"They that can give up essential liberty to obtain a little temporary
safety deserve Neither liberty nor safety",    Benjamin Franklin
-   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
   ASCII Ribbon Campaign                        accessBob
    NO HTML/PDF/RTF in e-mail                   accessys@smartnospam.net
    NO MSWord docs in e-mail                    Access Systems, engineers
    NO attachments in e-mail,  *LINUX powered*   access is a civil right
*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#
THIS message and any attachments are CONFIDENTIAL and may be
privileged.  They are intended ONLY for the individual or entity named

Received on Tuesday, 17 August 2004 14:36:38 UTC