RE: PDF in WCAG 2

Phill Jenkins wrote:
> 
> It's not "impossible", all I have to do is provide one or more groups
> some assistive technology that supports the PDF format and insure the
> PDF content follow the guidelines for making the content complaint. 
> But if I provide them content in HTML that includes an image file
> that doesn't include the alt text, then it is impossible to get that
> information to the individual.  The WCAG priorities are about the
> content, not the file format.      

Phill, I might concede you that, if and when there is a PDF
"interpreter" for all user agents, on all platforms.  As Bob has claimed
(on numerous occasions), he cannot access PDF's using his combination of
Linux, Lynx and the emacspeak screen reader.

> 
> It's the "content accessibility guidelines", not "file format choice
> guidelines".  Choosing HTML does not prevent one from including
> images without alt text.  Choosing PDF does not prevent one from
> including images without alt text.  The format choice may be a
> concern to some, but once we get past that (which is where I'm at) it
> is still whether the content is compliant with the guidelines -
> regardless of file format chosen.   

"WCAG Priority 2: 11.1 Use W3C technologies when they are available and
appropriate for a task and use the latest versions when supported."

"WCAG Priority 2: 3.1 When an appropriate markup language exists, use
markup rather than images to convey information." (Many PDF's,
especially legacy ones, are nothing more than giant pictures)
	  	  	 
"WCAG Priority 2: 3.2 Create documents that validate to published formal
grammars." (I am unaware of a formal grammar for PDFs)

This is not about PDF bashing, it's about compliance to published
guidelines... If you *must* adhere to these, then this is what they say.
   
> 
> This could easily be a discussion about SVG, SMIL, or MATHML, or
> FLASH, ASCII Text, or XHTML 2, or whichever format you choose.  WCAG
> 2.0 is attempting to apply to all or any of them, with specific
> techniques document to provide specific file format guidance.   
> 
> John, I do not agree with your statement:
> 
> "The WAI, WCAG, etc. is concerned about making *HTML based content*
> universally accessible.  Period."
> 

<include>

Andrew Kirkpatrick wrote:
>> John Foliot wrote:
>> The WAI, WCAG, etc. is concerned about making *HTML based
>> content* universally accessible.  Period.
> 
> John, can you clarify a bit here?  I'm not 100% certain
> whether you are suggesting that WAI/WCAG are currently just
> concerned with HTML-based content or if they _should_ only be
> concerned with doing this. 

</include>

OK... I'll back track somewhat.  The WAI concerns accessibility to/of
all web delivered content, including multimedia, alternative file
formats, etc.  My reading of the WCAG (1.0) is a little more narrow, it
concerns the development of accessible web pages (HTML, or equivalent:
XHTML, ASP, PHP, etc., which is essentially all just HTML anyway)...
What the lay person would refer to as a web page.  Content created for,
and intended to be delivered to, a web browser.  The guidelines
themselves use the term "page" on numerous occasions.

I will concede that these types of documents have become "richer" over
time - however the WCAG addresses these issues (IMO) in the context of
delivery through a "web page".  For example:

	1.1 Provide a text equivalent for every non-text element

	6.3 Ensure that pages are usable when scripts, applets, or other
programmatic objects are turned off or not supported. If this is not
possible, provide equivalent information on an alternative accessible
page. 
**(Note the term "page" - JF)**

	1.3 Until user agents can automatically read aloud the text
equivalent of a visual track, provide an auditory description of the
important information of the visual track of a multimedia presentation.

	1.4 For any time-based multimedia presentation (e.g., a movie or
animation), synchronize equivalent alternatives (e.g., captions or
auditory descriptions of the visual track) with the presentation.

	11.4 If, after best efforts, you cannot create an accessible
page, provide a link to an alternative page that uses W3C technologies,
is accessible, has equivalent information (or functionality), and is
updated as often as the inaccessible (original) page.
**(Again, note the term "page" - JF)**

...etc., etc.

> although that is a misconception of some, it's concerned with much
> more than *HTML based content*.  WCAG 2.0 specifically says: 
> 
> "... version 2.0 builds on WCAG 1.0. It has the same aim: to explain
> how to make Web content accessible to people with disabilities ... It
> attempts to apply guidelines to a wider range of technologies and to
> ... The design principles in this document represent broad concepts
> that apply to all Web-based content. They are not specific to HTML,
> XML, or any other technology. This approach was taken so that the
> design principles could be applied to a variety of situations and
> technologies, including those that do not yet exist. "       
> 

Yes, change is good.  WCAG 2.0 rightly builds upon WCAG 1.0, which was
appropriate for it's time, but is now 5 years old.  Flash and PDFs (for
example) exhibit many of the same accessibility issues as HTML does. To
make them accessible, we need to apply many of the same principles. The
debate to me isn't about whether or not a technology is accessible, it
is about what the primary delivery format should be. HTML is the most,
and will continue to be the most universally accessible format.

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   1.866.932.4878 (North America)

Received on Thursday, 19 August 2004 17:26:27 UTC