Perceivable structures (very long)

Hi, all. Last week I took an action item to think about the issues
raised by issues 1795 (comment from Jason) and 1863 (comment comp;aining
that the definition of structure is too hard for ordinary mortals als to
understand).
What follows is an attempt to think through this. I'm sorry it's so
long-- among other things I tried to apply thThe last paragraph makes a
kind of recommendation but I'm not sure what to do with it-- or if it
even works.

<discussionOfStructure>
(1)	Jason writes (in issue 1795) that the phrase "perceivable
structures" in SC 1.3.1 raises some troubling questions. Ultimately, he
says, the question is "What counts ... as a perceivable structure?"
which in turn depends on the question, "perceivable to whom?"
Prior to the 23 November 2005 draft, SC 1.3.1 read, "Structures within
the content can be programmatically determined." I think we added the
term "perceivable" in an attempt to address questions that Andi, Ben,
and others had raised about the limits of the requirement. For example,
Ben had asked if the SC would require use of the <code> element anytime
content included bits of source code (I think Ben thinks the answer
should be "no"; I think it might be "yes"). Andi had proposed listing
sufficient techniques for marking up visually important structures such
as headings, data tables, form controls, etc. Reasons for limiting the
SC to "perceivable structures within the content" rather than all
structures or just visually important ones was (a) the fact that the
default presentation may not be visual and (b) the belief that
structural features of the content which are perceivable to any class of
users should be perceivable to all classes of users, including users
with disabilities. And I think there's a (c)-we don't believe that all
structures within the content actually are important.

So  there was an attempt to allow for situations where the content (or
at least the default presentation) is not (or not primarily) visual.
But I think we should acknowledge that so far we're still thinking
primarily in terms of HTML and other markup languages, and largely in
terms of text (Christophe notes somewhere in a recent post that even
VoiceXML starts as text which is then rendered as synthetic speech). We
haven't talked about making the structure of audio content perceivable,
nor the structure of animations, nor the structure of video.  Where
multimedia is concerned, we do think about the structural separation of
the visual track from the audio track, but that's about as far as it
goes for now.  To the extent we've discussed how this SC might apply to
non-text content, we've said explicitly that we don't mean to require
use of SVG at Level 1.

Whether or not we intend SC 1.3.1 to cover non-text content, I think we
need to acknowledge that we're talking in narrowly formalist terms. For
example, we are not talking about such things as the literary structure
of poem X or the narrative structure of painting Y or the logical
structure of philosophical argument, all of which can be said to be
perceivable to people in the relevant fields. We're only talking about
things to which our definition of "structure" might apply.

So let's come at it from the direction of that definition. The
definition is in three parts. The first two parts go together. Structure
means the way the parts of an authored unit are organized in relation to
each other and the way multiple authored units within a delivery unit
are organized in relation to the delivery  unit. The third part applies
to collections of delivery units, and I'll skip that for now.

An authored unit is defined as some set of material created as a single
entity by an author. Examples include individual images as well as
"collections of markup." Since a delivery unit is defined as content
which is transferred from one machine to another as the result of a
single http: request, individual images and entire Web pages may be both
authored units and delivery units. Presumably this would apply to
audio-only and video-only files and to some multimedia (though I've
noted above that we distinguish between audio and video tracks here). 

Let's take the case of a single .GIF or .JPEG image. It's an authored
unit because it's all in one file. As a "single entity, it doesn't
really have any individually distinguishable parts, so our definition of
"structure" doesn't have anything more to say about it, and neither does
SC 1.3.1.

Now take a data table. This is also an authored unit, because it's a
"collection of markup." But it does have parts: row and column headings,
data cells, etc. SC 1.3.1 applies because those are structures within
the content, and they must be perceivable as such in order for the
content to make sense. And of course the table itself must be
perceivable as a table (for example, on a page that includes other
content such as text and images, users have to be able to tell that the
table is there and that it's different from the other content on the
page).

SC 1.3.1 does not require use of SVG for all images. However, SC 1.3.1
would apply to an image that's created entirely by SVG markup. In this
case, the image is actually "a collection of markup," just like the data
table. The question is, could an SVG image fail SC 1.3.1? (Maybe it
would automatically fail 1.3.1 if it failed 4.1.1, since the structures
within it wouldn't be perceivable if it couldn't be parsed
unambiguously.)

But I think Jason's really asking if there's anything we're willing to
say should not be counted as a perceivable structure for the purposes of
WCAG 2.0. I think the term "perceivable" is throwing us off-structures
become perceivable when they're marked off in some way from the rest of
the content (which is why it's possible to write a general technique
about formatting palin text so that simple structures like headings can
be programmatically determined, as well as why plain text
representations of tabular data aren't acceptable). 

Maybe the answer is that it's not counted as a "perceivable structure"
if it can be used to satisfy another SC under GL 1.3.  For example, I
mentioned the <code> element in the context of SC 1.3.3 (variations in
presentation of text), so maybe it's not required under 1.3.1.

Thoughts?
</discussionOfStructure>

John

"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web http://www.utexas.edu/research/accessibility

Received on Sunday, 8 January 2006 23:50:38 UTC