Thread Subject: Re: listing file format to use in bestpractice not a standard

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Lybarger, Barbara (MOD)
Date: Mon, Mar 26 2007 12:30 PM


I think information on the various formats needs to be addressed in
guidelines, which make clear that, when executed in accordance with the
manufacturer's instructions for creating the accessible format, each of
several specific formats can be accessible. When laid out clearly there
are a number of formats that can be rendered accessibly. However, some
are more work than others.

For example (and to pick on something other than .PDF), the .rtf format
can afford equal access to short, uncomplicated documents, but only when
resaved in a more feature rich format. If the document is long or
complex, headings, tables and a document map are often needed to afford
equal access. Those features are not supported in .rtf.

If the document was created in another format and converted to .rtf or
if it was created by scanning a print document and saved in .rtf, there
are a variety of access issues, such as lack of support for braille and
incompatibility with screen readers. For example, the Duxbury Braille
Translator (the be-all-and-end-all of brailling) does not support .rtf.
If one opens an .rtf in Duxbury, one gets all the formatting code from
the document. This will not braille anything intelligible for the
braille user. One must save the .rtf as a .doc file, and hope that the
next problem is not also present.

For both Braille translation and screen readers, a problem revolves
around how .rtf addresses indented and/or bulleted text. For the most
part intents and bulleted text are created by putting the affected text
into text boxes. For both screen reader and the brailler software (and
although the full text appears on the screen for the sighted user), the
boxed text is skipped by both pieces of AT. This problem can be
addressed by manually cutting and pasting the content of each text box
into the main body of the document (a time consuming pain) or by saving
the document as a plain text file, resaving it in .doc and reformatting
the document (another type of pain). Obviously these only works if one
knows about these fixes, and has the manual and spatial skills to get
everything reassembled correctly.

One could go on, but you get the idea.


WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University
http://webaim.org/teitac/mailarchives/mail_message?id=3533&listid=9
webaim.org
crawl=CC-MAIN-2013-20
9852
application/http; msgtype=response
sha1:NS2V4T7QHOMYXSQJAQCBFWM2IZ7BAHHW
<urn:uuid:8e385339-e52c-44f2-8338-374a20863533>
2013-05-20T02:07:33Z
184.106.203.86
sha1:S3XBAZCIC47TUGJIWU7LWS2ETA4HAIEB
<urn:uuid:efd92351-f822-431a-b057-9dafbbc8e1a0>
http://webaim.org/teitac/mailarchives/mail_message?id=3533&listid=9
response
<urn:uuid:5651db85-9102-4e25-a850-1baf99666fb7>
robots: classic
hostname: ip-10-60-113-184.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2013-20
operator: CommonCrawl Admin
description: Wide crawl of the web with URLs provided by Blekko for Spring 2013
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf