W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2003

Re: Checkpoint 1.1 - PDF Accessibility

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Tue, 2 Sep 2003 15:19:37 -0500
To: w3c-wai-ig@w3.org
Message-ID: <OFCCA626B6.B13BF5AE-ON86256D95.006A6932-86256D95.006FC004@us.ibm.com>





Seems to me that there are two different types of questions being asked.
One more policy related and one technically related.  The first is "What do
I do about non-HTML format documents, Word and PDF?  and the second, "What
to do about complex images of geographic maps and plans - regardless of the
format?"  [by the way, what is a geographic plan?]

Let me discuss the second question first.  If the complex images were in
HTML documents would they be any more easier to describe?  No - from your
statement "it is going to be extremely onerous to provide detailed
descriptions of the visual information".  So the harder issue seems to be
about providing the detail descriptions - not so much the format.  If that
is the main issue, and you are still going to provide a contact to get the
detail description; then it would seem to me that you could "capture" the
detail descriptions as they are requested and publish them to the sight so
you only have to "capture & create" the detail descriptions once.

If the issue is more complex than my assumption; for example,  say the
images are so complex and have so many uses that you don't know for sure,
until asked, what information the person is looking for.  If it was a
satellite photograph of an area, the person could be looking for a
comparison with a street map, or to see the outline of the islands compared
to their recollection of their last holiday in the area, or to see the land
use in agriculture vs native jungle, or what ever. You need to ask yourself
what information are you trying to provide by including the geographic
maps?  Is that information available in text somewhere else?  For example
the satellite image may be redundant to the tabular data about the
agriculture percentages in the area, or the population density in the area,
etc. so that the information you are trying to provide may be available in
another means.   If the information is not available in another means, then
you need to decide what you are trying to provide and start collecting,
creating, or capturing the information and publish it along with the
geographic maps.  If the site is public, then I would recommend HTML format
for the detail descriptions.

Now my first policy related question about non-HTML WORD and PDF documents.
If its an internal intranet site, then you may have more knowledge and/or
control over the configurations of your users - so non-HTML formats may not
be an issue.  For example,  your users have the technology for displaying
the Word and PDF formats and they are compatible with the deployed screen
magnifiers, screen readers, and keyboard navigation aids.  The Word and PDF
documents still have to provide the short and detail descriptions of the
images, i.e., the geographic maps.  If it is a public site, then in my
opinion this W3C WAI list does not have a mission to discuss the policy
question.  In other words, is it a policy debate about whether you need to
provide HTML formats of the Word and PDF documents?  You already seem to
have a policy or at least a goal to comply with WCAG 1.0 level-AA based on
your question.  Since WCAG 1.0 doesn't contain checkpoints for making Word
and PDF directly accessible, then you need to consider extending your
policy or converting the whole system so it can handle the W3C HTML format.

I'm not sure from your statement: "it is critical to the success of the
system that users are able to provide information in both Word and PDF
format." if the definition of system includes the end users or just the
software?  If the software can only handle attaching and moving Word and
PDF files, then it would seem to be a poorly (as in it should handle more
file types) architected software system.     .

Regards,
Phill Jenkins,  IBM Accessibility Services
http://www.ibm.com/able
Received on Tuesday, 2 September 2003 16:19:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:10 GMT