Alternative Formats

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?

> 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 http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv.html

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 issues.

Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able

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/

Good points. Is there anyone specifically in charge of alternative formats, not just web accessibility? Such as W3C has standards for web accessibility.

>  . . . 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?

Well, I would expand your simple list to also include the following, quoted from Understand WCAG:

• Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)
• Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
• Test: If non-text content is a test or exercise that must be presented in non-text format, then text alternatives at least provide descriptive identification of the non-text content.
• Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
• CAPTCHA: If the purpose non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
• Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able