RE: SC 2.4.4 and 2.4.8

Having missed the calls  this week, I hesitate to weigh in on the list,
so feel free to ignore this if it raises issues that have already been
considered and rejected.

I prefer 2.4.4 option  d as proposed by Loretta. Option a seems overly
specific somehow, while at the same time excluding headings, one of the
most widely used devices for establishing link context. This technique
works well for sighted users; seems like what we want is a way to make
the resulting construct accessible.

I think the notion of "context" in options b and c is impossibly broad,
though this could be handled by defining "context" in a way that limits
it to things like the items specified in option a. But then we might as
well just specify them...

The idea of "programmatically determined context" might make people's
heads spin, but I think it's useful because it could allow AT vendors to
innovate in the way they handle both recognizing and retrieving context.
The items from option a could be listed in examples for the definition,
along with headings if there are reliable algorithms for determining
whether some text H is the heading for some block of text B that
includes the potentially ambiguous link text. (This might make room for
things like XHTML 2.0's new <section><heading></heading></section>
construct, where the heading element is a child of the section element.

I think we'll need to define "programmatically determined context" in
some way, But I wonder if we could get away with adapting the existing
definition of "programmatically determined," then adding examples; and
if the WG wants to support treating headings as programmatically
determined context, that could be handled in the examples.

Here's a stab at a definition:

<proposed>
Programmatically determined context
Additional information that can be determined by software from data
provided in a  user-agent-supported  manner such that the  user agents
can extract the information, combine it with link text, and present this
information to users in different modalities 
</proposed>

The big problem here, at least in the short term, is that the definition
of "programmatically determined" includes the phrase
"user-agent-supported manner," which requires that the capacity be
"implemented" by user agents. So the list of *currently* sufficient
techniques could get awfully short.

I'm not sure how big a problem this is. After all, WCAG 1.0 required
markup for data tables that wasn't supported by AT for several years
after WCAG 1 went to Recommendation (and it's not in an "Until user
agents..." clause, either!). We don't want merely to ratify current
practice-- we want the vendors to extend what they're doing. And really
this seems like a short stretch, though I'm sure there are edge cases
where it requires a much longer reach.

John

"Good design is accessible design"
John Slatin, Director
Accessibility Institute University of Texas at Austin 1 University
station Stop G9600
Austin, TX 78712, USA
Phone +1.512.495.4288 Fax +1.512.495.4524 cell +1.512.784.7533
email jslatin@austin.utexas.edu
www.utexas.edu/research/accessibility/

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Loretta Guarino Reid
Sent: Thursday, September 07, 2006 9:14 PM
To: w3c-wai-gl@w3.org
Subject: SC 2.4.4 and 2.4.8



I'd like to get more feedback on SC 2.4.4 and SC 2.4.8 before drafting
another proposal. Based on today's discussion, I see several options for
these SC. 

We need to word SC 2.4.4 so that 
* the SC is suitably technology independent, 
* there is high inter-rater reliability in determining which other text
on the page can be combined with the link text to determine its purpose.
* there is enough clarity that User Agent developers could implement
support for indicating when different contexts are available for a link
and for providing a way of retrieving the context.

I'm assuming that for HTML, we agree that the only acceptable context
that can be added to the link text is
* title attribute
* enclosing sentence
* enclosing paragraph
* enclosing list item
* enclosing table cell, plus the headers for that table cell

(Note that this excludes "preceding heading element".)

I also assume that the "link text" for an image is its alt attribute.

SC 2.4.4, Option A: The purpose of each link can be determined from the
link text, the link's supplemental and alternative text, and the text of
any enclosing sentence, paragraph, data table cell with its associated
headers, or list item.

SC 2.4.4, Option B: The purpose of each link can be determined from the
link text and its context.

SC 2.4.4, Option C: The purpose of each link can be determined from the
link text and its immediate context.

SC 2.4.4, Option D: The purpose of each link can be determined from the
link text and its programmatically determined context.

For Options B, C and D, do we need a glossary definition for "context",
"immediate context" or "programmatically determined context"? (I think
so, but it is open for discussion.)

Some dictionary definitions for context are:
* The part of a text or statement that surrounds a particular word or
passage and determines its meaning
* the set of circumstances or facts that surround a particular event,
situation, etc; a setting
* The parts of a written or spoken statement that precede or follow a
specific word or passage, usually influencing its meaning or effect
* discourse that surrounds a language unit and helps to determine its
interpretation
* That which surrounds, and gives meaning to, something else

The challenge is to define context without making the definition depend
upon "that which gives meaning", since then the SC would be impossible
to fail. 

I worry that if we can't define what qualifies as context clearly
enough, this SC isn't viable. "Programmatically determined" attempts to
tap into the need for user agent support. However, we know that current
user agent support for context is pretty poor, and if we rely on that as
our definition of context, the difference between 2.4.4 and 2.4.8 may
not be worth the confusion introduced by having two different SC. 


For SC 2.4.8, the issue is whether content other than the link text can
be considered in determining the purpose of the link, e.g., title
attributes. (Option B corresponds to what a user would get in a list of
links for the Web unit.)

SC 2.4.8, Option A: The purpose of each link can be determined by the
user from link text, including supplemental and alternative text.

SC 2.4.8, Option B: The purpose of each link can be determined by the
user from link text.

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

Received on Friday, 8 September 2006 16:27:17 UTC