WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Semantics for Indicating Accessible Version of Files

for

From: Cliff Tyllick
Date: Jan 29, 2009 12:55PM

A colleague suggested a different approach that is at least worth considering when the accessible file is completely reliable (that is, when its text layer wasn't obtained by OCR). In other words, this approach is not helpful if the only existing record is a scanned copy, but it could be useful for future documents---especially if you're not comfortable inserting images or don't have Photoshop.

Here's my colleague's idea: Why not post the accessible version and append to it the scanned version of only the signature page? Alt text could identify that page as "signed version of page x" (or whatever else makes sense).

If more than one page of the "official" document has significant handwritten marks, each such page could be scanned, marked with appropriate alt text, and added to the end. There would be no need to do OCR on the scanned pages, because that content would be available in the main part of the document.

You might even be able to add a section heading such as "Scanned Copies of Handwritten Notes and Signatures." That way, the images are easy to find for anyone who wants them.

Cliff

>>> "Randy Pearson" < <EMAIL REMOVED> > 1/28/2009 4:12 PM >>>
>> If it's a page that lists many such files, how about a properly
>> marked up table, with the two versions in separate columns?

We started down that path, but then didn't like it. Hence pausing for this
post. ;) What we did not like was the table might already have 4 columns to
include date, size, type, name. If you added the accessible version to the
same row, then really you need 4 similar columns, as date, size, type apply
separately to those files also. That approach felt both structurally and
visually wrong.

>> How about "signed copy" (or "as submitted," if it's something
>> your agency received) and "accessible version"?

Good idea. We're already en route to establishing file naming conventions,
wherein one can (hopefully) grok something from the names (e.g., one might
have an extra "_text" appended to the stem of the name). But your idea
sounds like a good one. Perhaps add a "notes" column to the right that
includes this. In fact that could provide an avenue to point to the other
file also.

-- Randy