This thread is closely related to the thread about #506, in which David
and Gregg discuss a revised definition of structure that was put
forward by David.
Earlier this week, in a message about the 506 thread [1], I wrote that I
was concerned that we were defining structure in a way that's too
HTML-specific (and too text-specific as well, though I didn't actually
say that). I'll paste my proposed definition in here for ease of
reference; the full message at [1] includes the exchange between David
and Gregg as well as a dictionary definition of structure that was the
starting point for mine.
<proposed>
structure
Structure refers to the set of elements and relationships that make up a
Web resource. Elements may contain text, graphics, mathematical
equations, etc. Some elements may contain other elements, and may also
define relationships between two or more elements. We User agents,
including Web browsers and some assistive technologies, make the
structure of Web resources evident to the user.
Some relationships are hierarchical. For example, an HTML document may
contain multiple sections. Each section begins with an HTML heading
element (<h1>...<h6>) that contains the title of the section or
sub-section. The heading element may also show the logical relationship
of one section or sub-section to the sections and sub-sections before
and after it.
In MathML, certain elements are used to show the syntactic structure of
mathematical notation-for example, to make it clear that calculations
have to be performed in a specific order. In SVG, certain elements
(such as the <g> element) are used to define groups of related graphical
objects and to provide information about the document's structure.
Some relationships are non-hierarchical. For example, non-hierarchical
relationships may be created by links between one part of the document
and another part, or between the document and another resource.
</proposed>
I do *not* think this definition is ready for primte-time. I'm not at
all certain that it accurately conveys the ideas of structure embodied
in SVG and MathML, for example. I put it out here in hopes that we can
try to come up with a definition that's broad enough to encompass the
broad range of technologies we're concerned with.
[1]
http://lists.w3.org/Archives/Public/w3c-wai-gl/2004AprJun/0375.html#star
t
John
"Good design is accessible design."
Please note our new name and URL!
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/
-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Ben Caldwell
Sent: Thursday, May 13, 2004 5:08 pm
To: w3c-wai-gl@w3.org; tcroucher@netalleynetworks.com
Subject: RE: Issue 556 and 669
Finishing some thoughts from the call today...
I like the proposal to move emphasis into a separate criterion.
Questions:
> 1. "Structures and relationships of the content can be derived
> programmatically (for example, through a markup or data model)"
Tom, are you proposing that we remove the references to hierarchical and
non-hierarchical relationships? I think the specific mention of
paragraphs, lists, headings, tables, etc. is important to understanding
this guideline and helpful to those who come to the guidelines searching
for answers to questions like "how do I make tables accessible".
> 2. "Differentiation of content to imply additional meaning or stress,
> such as the types of emphasis commonly denoted by bold or italics, can
> be derived programmatically."
Is there a better word than "stress"?
Perhaps "... imply additional meaning, emphasis or distinction, such as
..."
With regard to the questions raised about whether these criteria imply
that the archives of this list would not be accessible, it may be that
this is answered through questions about scoping and whether
technologies have been used according to specification (guideline 4.1).
For scoping, one could claim that the W3C list archives interface meets
WCAG 2.0 level one, but that the scope of the claim does not include the
content that it receives/processes from external sources (i.e. plain
text emails).
For the according to spec. question, there is no spec that I know of by
which one might mark up structure using plain text. So, plain text
content (like the emails submitted to the W3C archives or the comments
we've been collecting via form submissions in WCAG Bugzilla) would be
excepted. However, in the case of content written in (X)HTML, not using
a header tag to mark a header would fail the requirements of 4.1.
-Ben