Re: Axis attribute

Al, (comments interspersed)

> AG:: What evidence has led you to this conclusion?  Have you discussed this
> with Tom W.?

In this case, no.  I'm fully capable of developing an opinion on my own.  I
consider this list to be a resource that should be regarded as comparable to
a colleague.  I can walk into Tom W's office and say, "I think axis is
unnecessary, do you think otherwise?" or I can post a statement and question
to the IG list.  The goal in both cases is to refine my understanding by
interacting with a community of knowledgeable people interested in access
issues.  Should all questions to this list be checked out with recognized
authorities prior to posting?

> It is a cliche of the human-computer interaction business that users of the
> graphical display get lots of help from what else in in view at the same
> time. 
> Speech produces one word at a time.  It is not backed up by random eye-access
> to lots of concurrent context.
> 
> So it is often rational for an audible rendering of content to contain more
> explicit framing or orientation cues than are exposed in the GUI display.
> 
> In the specific case of 'Seattle' in this table, the visual user has
> concurrent
> access to the items "San Jose" and "Seattle" displayed in parallel form.
> It is
> clear that they are two instances of a common pattern.  From the
> association of
> the two the category of 'cities' can be inferred.
> 
> The aural user only hears 'Seattle.'

I am already familiar with and fully support using markup to associate data
cells with header information for the purpose of providing explicit framing
or orientation cues for the user.  I agree that it is useful for screen
reader users to know that "Seattle" is a city as much as it is for sighted
users to know.  A sighted user probably infers that Seattle is a city
because the caption refers to travel.  Screen reader users can also make
this assumption.  In a more complex table with less familiar terms it is
undoubtedly more difficult to carry orientation information from the caption
throughout the interaction with the table.  Part of my post was asking for
examples.

Unfortunately, (today) only JAWS users will benefit from the axis attribute
information.  If there was a summary for the table that clearly provided
orientation information, the user wouldn't need to hear "location" multiple
times.  

I have provided an example file with two nearly identical tables -- the
first uses axis and the second uses a summary attribute to the table (which
should be in the first anyway).

> 
> Had the peers of 'Seattle' been 'Geronimo' and "Sitting Bull" instead of "San
> Jose" it would have been clear to the visual user that the topic was "Native
> American leaders" and not cities.  To make up for the lack of contextual cuing
> from parallel elements in the concurrent display, Jaws picks up the 'axis'
> information and verbalizes it.  The aural user is more likely to need this cue
> than the visual user is.
> 
> In other words, alternate filtering of the verbiage is _an appropriate_
> kind of
> change in how content is presented when moving between modalities of
> display or
> command/input.

If I look at this table by itself, I might have a hard time disproving a
claim that Seattle and San Jose are software builds or project code names.
I would refer to the table caption and headings to give me clues, and
usually these would help.  Beyond that, a sighted user would need the
information on the rest of the page.  Tables are sometimes provided without
paragraphs of supporting text, and if this table were provided alone I would
say that it is incomplete, regardless of modality.

> This needs to be done under well-defined rules that the user understands
> how to
> control in the browse process and the author understands as user-controllable
> adjustments in their authoring.  We don't have all the rules clear enough
> yet. 

Agreed.

> But don't think that what words you would put on the screen define what should
> be read out aurally, or vice versa.  The language just doesn't stretch that
> far
> and produce a rendition that passes the laugh test [or cry].
> 
> On the other hand, following the User Agent Accessibility Guidelines, all
> users
> in all modalities should have access to all content, such as the 'Location'
> annotation in the axis attribute.  But the default presentation as prepared by
> the format and author will beneficially be profiled differently for different
> display modalities.

At the root of my original question is just that.  If I create a complex
table and diligently use scope or id and headers attributes, I am providing
a way to access the header information that is related to the data point.  A
sighted user using a table looks at the heading and caption of a table
before looking at the data and remembers what the table is about.
Similarly, a screen reader user hears the caption and summary and needs to
keep that information in mind while the headers and data are being read.

I have no problem providing the axis attribute, but want to make sure that
the effort expended is fruitful.  I have not seen a table where I'm
convinced that axis is necessary.

> Why are you being so stingy and only asking 'necessary'?  Do you care if it is
> helpful?  Are you trying to produce content that is not illegal, or content
> that is useful?

Jeez, you make it sound like I'm an ogre for asking for justification.  You
are aware that NCAM is not developing Web pages for the Federal Government;
legality is not the concern.  I do have the occasion to speak with people
who are developing pages where accessibility (and yes, sometimes legality)
is a concern -- I find the most effective way to squander their good will is
to tell them a way to do something that is not a productive use of their
time.  I'm being "stingy" because I want a rock-solid reason to convince
developers to use it (Jim made this point, and I saw your reply so I won't
belabor it further).

"Helpful" is very subjective, and could be contrasted with another screen
reader user saying that it is "annoying" to have "location" announced each
time.  Of course, the user agent might set a preference for the speaking of
the axis data, but the user might find it just as helpful to use a keystroke
to reread the caption or summary.

Thanks for your input, Al.  I do believe that we are interested in the same
thing, but there are obviously unanswered questions remaining.

Andrew


On 12/4/01 5:53 PM,  Al Gilman (asgilman@iamdigex.net) wrote:

> At 11:42 AM 2001-12-03 , Andrew Kirkpatrick wrote:
>> I have been doing some testing with the axis attribute and come up with a
>> question.  JAWS does read axis values, but it seems only when the data cell
>> uses the headers attribute to make the connection to the header cell where
>> axis is given its value.
>> 
>> The information in the axis attribute is not going to be seen by the sighted
>> user, but is read by JAWS.  What information needs to go into axis? The WCAG
>> techniques document has a table (expense items in different categories, on
>> different dates, and incurred in different locales)  where axis is used
>> (<http://www.w3.org/TR/WCAG10-HTML-TECHS/#identifying-table-rows-columns>h
>> ttp://www.w3.org/TR/WCAG10-HTML-TECHS/#identifying-table-rows-columns).
>> In this table, JAWS reads "Location" as the axis prior to voicing the city
>> where an expense item was incurred.  Location is not visible on screen.  One
>> could argue that people know Seattle is a location, but if a table on a
>> different topic sighted people might need the axis information to understand
>> the table content.
>> 
>> I'm increasingly of the mind that if a table uses axis to convey information
>> to screen readers then the developer is either repeating information
>> unnecessarily or sighted users are not getting all of the necessary
>> information.
>> 
> 
>> So here's the question:
>> Does anyone have an example of a table where axis is necessary for assistive
>> technology users? 
>> 
>> Thanks,
>> Andrew
>> 

-- 
Andrew Kirkpatrick, Technical Project Coordinator
CPB/WGBH National Center for Accessible Media
125 Western Ave.
Boston, MA  02134
E-mail: andrew_kirkpatrick@wgbh.org
Web site: ncam.wgbh.org

617-300-4420 (direct voice/FAX)
617-300-3400 (main NCAM)
617-300-2489 (TTY)

WGBH enriches people's lives through programs and services that educate,
inspire, and entertain, fostering citizenship and culture, the joy of
learning, and the power of diverse perspectives.