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

RE: Alternative Formats

From: Ryan Jean <ryanj@disnetwork.org>
Date: Thu, 28 Aug 2008 09:43:34 -0400
To: "'Phill Jenkins'" <pjenkins@us.ibm.com>
Cc: <w3c-wai-ig@w3.org>
Message-ID: <E1KYhoq-000472-Bu@maggie.w3.org>
I like that. Very thought provoking. I was referring to all formats, such as
visual, audio, and written. I do see where all 3 of these would fall into
web accessibility. Visual for graphics, audio for sound, and written for
downloading files as PDF or TXT. Do you agree?



Ryan Jean

Assistant IT Specialist

The Disability Network

Flint, MI



From: Phill Jenkins [mailto:pjenkins@us.ibm.com] 
Sent: Wednesday, August 27, 2008 5:51 PM
To: Ryan Jean
Cc: w3c-wai-ig@w3.org
Subject: Re: Alternative Formats


> Would alternative formats fall under the category of web accessibility? 

In my opinion, in general, yes.   

1. For example, many consider text alternative to non-text content to be an
alternative format of the same content. That is the fundamental basis of
WCAG 2.0 Guideline 1.1 - read more about understanding text alternatives at

2. And many consider making content available in multiple FILE formats as a
valid and useful technique for making web content or applications accessible
to more people, independent of disability.  We should probably ask you to
expand your questions to be more explicit - as in 
        Alternative (file?) formats (of what? content) fall under the
category of web accessibility (WCAG or 508 standards)? 

For example, PDF file format of content could be made directly accessible
(compliant with technical standards) with tagging and such, but also by
making (providing an alternative format) the content available in another
format - such as accessible HTML format.  Another example is making
PowerPoint (PPT) documents posted on web sites available in an alternative
format such as Rich Text Format (RTF).   

Interestingly, the term "file formats" is not explicitly discussed in either
the WCAG Techniques [2] or Understanding [1] documents. probably something
we should send to the editors. 

The theory or principle is that the 'guidelines' apply to any and all file
formats (also referred to as technologies), whether they be HTML, SMIL, PDF,
RTF, etc. and the 'techniques' apply to specific file format or
technologies.  So the long held notion that a particular file format is or
isn't accessible has been omitted from the documents by the more academic
approach of "provid[ing] the basic goals that authors should work toward in
order to make content more accessible to users with different disabilities."
[WCAG 2.0 Guidelines definition Note 3]. 

And, because we often confuse the "policy" from the "technical standard" and
that WCAG 2.0 is a technical standard and not a policy, we need to make
provisions in the policies for the anomalies for problems in the technical
standards that occur with different or competing file formats.  For example,
one file format may have a way (capability) for marking up language
different from the base document while another file format may not (or not
yet) have that capability.  So depending on which way one is converting
formats, you end up with different policy decisions.  If I have a document
in a format that doesn't support language tags, but convert it to a document
that does support language tags, is it compliant or not without the language
tags being added?  If the document (or content) was in a format that
provided language tags and gets converted into a format that doesn't have
the capability, is it less accessible (less compliant) with the technical
standard? And then when you have a document that doesn't have different
languages in the same document or file or page - does it matter?  Are not
both file formats of the same content just as compliant with the technical
standards?  The debate often slips back into the "file format wars", where
you hear automatic assumptions that HTML is more accessible than
'pick-your-other-file-format', or not as widely supported by blah blah blah,
or whatever.   

The point I'm getting to is that neither WCAG, 508, or any of the other
"standards" really address which file formats are better or worse
alternatives to the other - they really only address if the particular file
format of the particular content is complaint or not with the particular set
of technical provisions (guidelines) - and in my opinion should probably
stay that way to avoid getting into policy decisions and anti-innovations

Phill Jenkins
IBM Research - Human Ability & Accessibility Center

1 Understanding WCAG 2.0        http://www.w3.org/TR/UNDERSTANDING-WCAG20/ 
2.Techniques for WCAG 2.0        http://www.w3.org/TR/WCAG20-TECHS/ 
3 WCAG 2.0 requirements        http://www.w3.org/TR/WCAG20/ 
Received on Thursday, 28 August 2008 13:45:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:38 UTC