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: David Poehlman
Date: Wed, Mar 28 2007 11:35 AM

I might be rong, but jaws can read text boxes in word if I understand
correctly with a keystroke I don't right now have to hand. This is
an issue though and I agree that requirements for different document
markup formats need to be described. I'd actually like to stay with
open document formats if possible.

On Mar 26, 2007, at 3:22 PM, Lybarger, Barbara (MOD) wrote:

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.

From: = EMAIL ADDRESS REMOVED = [mailto:teitac-
= EMAIL ADDRESS REMOVED = ] On Behalf Of Whitney Quesenbery
Sent: Sunday, March 18, 2007 10:28 PM
To: TEITAC documentation and technical support subcommittee
Subject: Re: [teitac-documentation] listing file format to use in
best practice not a standard

I agree with the discussion as summarized on the wiki.

But I also think that the world would be improved by some clear
guidance on what makes a PDF accessible.

From the number of agency web sites that provide step-by-step
instructions, this is clearly a difficult issue. Even if the source
document is set up correctly, it can be hard to know just what
"buttons to push" to make sure that the PDF file is actual
accessible, or how to test it.

Are there specific attributes of an accessible PDF file that we could
identify, or requirements for a PDF file that is posted without an
alternate accessible version? Could this be included in the section
on content?

Another point we might want to make (which might also be a general
requirement on alternate formats) is that when there are several
alternative formats offered, they should be close together. I'm not
sure how to say this clearly, but it would mean (for example) having
the two links side by side ("Download as a [PDF] [RTF] file"), rather
than grouping all of the accessible versions in one (separate) place.

Hmm. Doesn't this sound just like the discussion on documenting
keyboard shortcuts? Don't make people go hunting for the "alternate"
- put it with the "default" mode.

At 06:15 PM 3/16/2007, Michele Budris wrote:

> In the March 15, 2007 meeting we discussed the topic of what are
> acceptable electronic formats? Notes from the discussion are on the
> wiki page http://teitac.org/wiki/Documentation:Electronic_Formats.
>
> Agreement is that file formats change too frequently so it would be
> better to make the requirement state the content of the file be
> accessible. Listing of specific file formats should be in a best
> practice if included at all.
>
> The currently proposed text for 1194.41a already states that the
> content of the files should be accessible. See http://teitac.org/
> wiki/Documentation:Alternate_Format for the text. Are any
> additional changes needed?
>
> Should a best practice on how to make accessible PDF be added to
> 1194.41a?
> That leads then to the question of should PDF even be singled out?
> Should information on other file formats be included?
>
>
> Michele
>
>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University