Thread Subject: Re: Allen's proposal for a newsection oncontent

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: Peter Korn
Date: Tue, Apr 03 2007 1:05 AM

I'm enjoying this discussion of content accessibility; I think it is
very useful.

I've a bunch of comments on messages on this thread.

From Don Barrett:
> My only concern is that the accessibility requirement spelled out by
> each criterion doesn't necessarily follow the if-then clause. For
> example, in proposed standards 5 and 6 reprinted below, the requirement
> that the content support data tables doesn't automatically ensure that
> the accessibility conclusive statement can be met. Microsoft Word is a
> perfect example; its content format definitely "supports data tables,"
> but in Word, one can neither "identify row and column headers," nor
> "associate row and column headers with other table cells." Are we
> prohibiting the use of Word?
>

If it cannot be clear from the .doc document format that some table
cells are headers, then we have a problem with .doc that should be
remedied. If it can be clear from the .doc format, but Word doesn't
allow a user to make such a relationship clear, then we have a problem
in the document authoring tool. If we have the proper format and the
application support it but users aren't using it, then we have a
usage/policy problem, and as a group we have to figure out to what
extent 508 should say anything about whether and how authoring tools
should alert/encourage/enforce properly encoding of documents for
accessibility when purchased under Section 508.

It hopefully goes without saying that this applies equally well to .odt
files, .pdf files, etc. - Word was simply the example Don raised.

Don further writes:

> Another way to rewrite 5 and 6 might be:
> 5. An encoding mechanism shall be provided to identify row and column
> headers for tabular information displayable by a user-agent when such a
> mechanism is supported by the content format.
>
> 6. An encoding mechanism shall be provided to associate row and column
> headers with other table cells, displayable by a user-agent when such a
> mechanism is supported by the content format.
>
> In this way, content preparers are mandated to use the content format to
> its fullest potential, without requiring more of the format than it can
> deliver.
>

I must disagree here with where you are placing the "when". I think
this is a requirement of the document format when it provides tabular
information with visually identifying headers; not only on the
application when the content format has a way of encoding header
information. The key thing is if the application/format vendor is
actively anticipating users using this feature - perhaps even selling it
as a product feature - then an accessible encoding mechanism must be
present. This should be distinct from a user going into a tool like
Adobe Illustrator and creating tables with visible headers by placing a
bunch of lines (thicker and thiner) into a grid which is then filled
with text "cells" and called "Table of cell mutations" or some such.


Gregg Vanderheiden writes:

> On the first point, (i.e. color values of the forground text and
> background) I still am not sure I understand the benefit. If the
> content is rendered to the screen the AT can always get the color
> values. But from discussions in our other group it was my
> understanding that there are no AT that can deal with presenting the
> millions of colors to people in a way that they can understand.

This is a bad assumption. Content rendered via DirectDraw or some other
mechanism allowing applications to communicate directly to video memory
frame buffers may not such that "AT can always get the color values".
Nor in a requirement about content should we assume a content render is
involved. If I am converting this document to Braille or DAISY or some
other format, all I have to go on is the format. If the information I
need for accessibility isn't clearly present in the format, I won't be
able (and shouldn't be required) to run a particular content rendering
application and observe what it does in order to figure out what is
going on.


Barbara Lybarger wrote:

> Is this mixing up the issues involving color with those involving
> contrast? At least the way I've always thought about those two standards:
>
> 1.
> The color provision is about not using color alone (i.e. without
> text) to convey information, because folks who are color blind
> or have low to no vision can't distinguish the color.
> 2.
> The contrast provision is about text on a background not using
> colors (or grays) the density of which are so close together
> that they are hard to distinguish for folks who are color blind
> or who have low vision.
>
>
> The issue you seem to be dealing with is really the latter. The
> existing 508 approach, although needing better specificity, deals with
> the degree of contrast between colors. AT doesn't really address the
> contrast issue for the reasons you identify. Given this, the standard
> may need to at least stay as is (i.e. contrast is in the eye of the
> beholder thru manual testing), unless someone has comes up with a
> viable means of automated measurement of contrast.

I believe these are distinct issues. We don't want users to encode
meaningful information solely with color. We further don't want users
to create meaningful content with insufficient contrast. This is
distinct from whether color value information is or is not clearly
encoded in the document format where AT and other document
reading/transcoding tools cannot get at it.

And lest anyone make the assumption that if one application can read and
understand a file, therefore all of the information must be in there and
clear, please look at examples of file formats that contain undocumented
binary data, and file formats that contain actual programs (e.g. an
ActiveX control, or an image metafile, or a Java rendering component),
which cannot be understood without executing them on a machine that can
run that code. There are multiple real-life examples of such files.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

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