RE: Perceivable structures (very long)

An interesting analysis, John. Thanks.

I think we are trying to find wording that means both
1. If your technology has mechanisms for indicating structure (in the
sense that you describe in your message), then use it as intended.
2. If you can author content whose visible representation contains
certain relationships (like tables), there must be a mechanism for
indicating that structure.

We struggle with item 1 because some structure is viewed as more
important than others (probably based on the current support in
assistive technology). This is why there may be differences in opinion
about whether the <code> element should be required. This starts feeling
similar to our validity discussions.

We struggle with item 2 because we don't like to single out visual
presentation as privileged. But the primacy of visual rendering on the
web is what causes us so many problems. As you point out, we pretty much
slide by questions of structure within multi-media.

I have been able to turn these thoughts into a specific proposal,
either. I'll keep thinking about it.

Loretta

Loretta Guarino Reid
lguarino@adobe.com
Adobe Systems, Acrobat Engineering 

> -----Original Message-----
> From: public-wcag-teamb-request@w3.org [mailto:public-
> wcag-teamb-request@w3.org] On Behalf Of John M Slatin
> Sent: Sunday, January 08, 2006 3:50 PM
> To: public-wcag-teamb@w3.org
> Subject: 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 Tuesday, 10 January 2006 02:44:30 UTC