Documentation:Electronic Formats

Documentation > Electronic Formats

What are acceptable electronic formats? pdf, ascii, a word processor file such as Word?

The currently proposed text for 1194.41a already states that the content of the files should be accessible. See 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?

Discussion and Comments

This was question discussed at the March 15, 2007 meeting. Comments from that meeting include:

• Due to the frequency of change on document formats, instead of list specific formats to be used, it is better to specify the content be accessible.
• Many people use PDF but don't make it accessible. Would like to see it clearly stated must be tagged PDF. Some can translate PDF to text, others can not. If make it a standard when would not have this issue.
• Agreed that the issue of PDF would be better done in a best practice but not in a standard.
• Many agencies have their old documentation in non-accessible PDF. Those files will be around a long time, and they will go away with time. When people do need those in accessible form, the agency does the conversion as needed.
• 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.

Agreement was to send this to the email alias for input making this a best practice and not a standard.

Additional discussion on email:

March 16 - Gregg Vanderheiden

The usual way to address this in standards is to avoid specifying particular formats. We should talk about what has to be true about the documents with regard to accessibility.

Also we probably should talk about the format being ‘conformant’ rather than ‘accessible’. That is we specify that they should conform to our standards for accessible documentation rather than saying that they be accessible.

March 19 - David Poehlman

I'd like to offer a different approach. What we need are guidance/standards if you will that provide a roadmap for formats to be compliiant. We need to also target the requestor by functionality. If braille meets the need, it should be braillee and not only braille, but grade1 if that is what is needed. If cassette, asci, other commonly used and or open formats meet the need, that should be supplied. In other words, do away with alternate formats altogether and talk about compliant formats if you will.

March 19 - Whitney Quesenbery

So, if I posted a "file" in several formats and at least one of the formats met each of the general functional performance requirements, I'd be in compliance?

As I think about this, I do this all the time, even outside of disabilities considerations. For example, if the information if the info is from an application used by some (but not all) members of a project, I might send it out in the native format, but also send an exported format such as text or PDF or HTML. (Example: Microsoft Project, which will create a number of formats to read a project plan.)

The next question is what is a "sufficient" format. Is it enough to have formats that (taken as a group) conform to requirements? What else must be taken into consideration:

-- The capabilities of the users' IT be taken into consideration? The example above is one (from general use) in which the availability of the "reader program" is a consideration.

-- User preferences? I can see how this might be determined through user research in a specific case (easier or perhaps more targeted for employees than for the public), but how would it be specified as a general requirement.

-- Availability (% adoption? cost? ease of acquisition/installation?) of the AT or "reader program"?

What if I choose not to install a wildly popular and free plugin (e.g. Acrobat, Flash)? Is that "my choice" but not "your responsibility"?

March 19 - David P. and Whitney Q.

WQ: Good point, in applications/formats where this is possible. What about: a diagram in a graphics format and an accompanying textual description.

DP: This example fits with my thinking. It iss not a format exactly, it is a conceptual format.. The actuall concept I think is a diagramm with complete narative. In this way, the diagram can be detatched or made tactile etc. The fconcepts would be audio, visual, electronic textual and tactile aand probably others and an appropriate mixture for meetinggg multiiple functional needs. So, the bigggest issues we have here are what electronic forms something should take in order to satisfy our requirements that the content be acccessible. Tactile and audio are almost easy although we could set standards for them as well relying on information ffrom the Library of congress (NLS), AAmerican foundation for the blind and others. Whether it is mixed content or pure graphical or textual, it needs too bee in formats which meet requirements yet to be deterrmined. In my estimate, what would be a logical approach would be that if it is streight text, there needs to be something diamagratic or visually apppropriate to rrepresent it for those who need that and vise verssa. If it is purely graphical, it needs to also be textual. This can become complex and it can also boil down to an easy way to meet needs.

In other words, mixed content must meet functional requirements. And that is where the formats come into play for dealing with the objects in the content. Pleae remember, we haven't written these requirements as yet but if it is possible to do so, I believe a lot of ambiguity can be dealt with.

March 19 - Whitney Quesenbery

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?

March 19 - Norman B. Robinson

An observation: what is the definition of alternate formats or alternate methods?

1. What would be examples of how this should be implemented? e.g.: We provide documentation in PDF format that (we believe) meets all the 1194 subpart B and C requirements. What happens with the users that can't open a PDF v 12 using their assistive technology or it doesn't work on their platform/operating system? That is, what happens when the end-user deems the format unacceptable? If I don't run MS Office at home, is a MS Word document acceptable? What is the acceptable alternate format for blueprints? We've have a primitive approach to this in our USPS policy: http://www.usps.com/cpim/ftp/hand/as508a/508a_c6.html#508hdr79.

2. Are we addressing the real world need for accessible electronic formats (and not just Braille or other options)?

3. What would be examples of how this could be implemented in undesirable ways? e.g., We provide documentation in one format only, which our legal council has deemed meets our legal requirements since [vendor specific example] is commonly available. Assume there is no accessible plug-in for [vendor specific format]. Assume the vendor software costs a significant amount of money to obtain. Generally, I've found this is left until someone actually makes a request, then the responsible program has to back-track into satisfying the end-user's needs.

4. Who _legally_ determines what is an acceptable alternate format? Do we expect when reasonable people disagree, the desired course of action would be for the affected individual to file a Section 508 complaint? Do we expect clarification in the next version of the Section 508 technical standards that describes what the best practice or acceptable formats should be allowed?

March 26 - Barbara Lybarger

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.