W3C home > Mailing lists > Public > public-html-a11y@w3.org > December 2009

Re: CHANGE PROPOSAL: Table Summary

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Sun, 6 Dec 2009 07:01:02 -0600
Message-ID: <1c8dbcaa0912060501n1504e16etc286055022c16381@mail.gmail.com>
To: HTML Accessibility Task Force <public-html-a11y@w3.org>, Ian Hickson <ian@hixie.ch>
Cc: Roger Johansson <roger@456bereastreet.com>
Ian wrote:

> Nobody has collected equivalent data showing summary="" is useful at
> improving accessibility in practice,

Last month Roger Johansson asked on his blog, "Do you find table
summaries helpful?"[1]. and received three responses from screen
reader users.

Some questions:

Would it in-scope for this task force to do similar survey of screen
reader users  on a wider scale? Would such a survey help bring this
issue to resolution? If so, are there any accessibility task force
members willing to collaborate on such a survey? Could the W3C WBS
survey tool be used for such a survey?

Roger was the original person to raise the table summary issue on May
1, 2007. [2]

Best Regards,

[1]  http://www.456bereastreet.com/archive/200911/do_you_find_table_summaries_helpful/
[2] http://lists.w3.org/Archives/Public/public-html/2007May/thread.html#msg12

On 12/5/09, Ian Hickson <ian@hixie.ch> wrote:
> On Sat, 5 Dec 2009, Laura Carlson wrote:
>> John Foliot wrote:
>> >> It comes down to two perspectives: Universal Design versus
>> >> Accommodation features.  In a perfect world, Universal Design would
>> >> solve all problems, as the Design would be, well, Universal.
>> >> However, when Universal Design fails is there another way forward?
>> >> The answer is via Accommodation features.  @summary is one such
>> >> Accommodation feature - it exists when other 'solutions' are either
>> >> not viable or wanted, for whatever reason. Matt May and Cynthia
>> >> Shelly are two senior developers who have specifically noted in the
>> >> context of *this thread* that they have experienced, first hand, the
>> >> tug and pull of Accessibility Requirements versus other Business and
>> >> Aesthetic considerations, and they, like I, have experienced more
>> >> than once the defeat of Accessibility enhancements (or even basic
>> >> needs) to the Trump Card of other voices at the decision table.
>> >> Having solutions such as @summary in the developer's toolbox provides
>> >> an additional option when options are required - it allows for a
>> >> compromise solution that you have not offered in any other way.
>> Ian Hickson wrote:
>> > I'm not arguing with the principle; I'm arguing with this application
>> > of the principle.
>> If I recall correctly, Ian didn't you argue the same against restoring
>> the table headers attribute for a year and a half and yet ended up
>> restoring @headers in the spec making it conforming?
>> If that is correct from your perspective, what is the difference between
>> the @headers issue [1] and the @summary issue [2]?
> Ben Millard collected convincing data showing that tables existed that
> benefitted from the headers="" attribute, and that assistive technologies
> could not derive the same information from the existing markup. There was
> also evidence showing that headers="" misuse was relatively easily
> algorithmically detectable, such that it didn't harm users. Finally, the
> feature doesn't cause harm to non-AT users.
> Nobody has collected equivalent data showing summary="" is useful at
> improving accessibility in practice, and people _have_ collected data
> showing that it is harmful to both AT and non-AT users (in different
> ways).
>> They are both accessibility accommodations. What is the difference in
>> applying the principle in the two cases?
> The principle is that accessibility accommodations (meaning features that
> authors have no motivation to use _other_ than improving the experience of
> AT users) should be a last resort, to be used when there is evidence that
> their use would improve matters, that their design is likely to lead to
> acceptably frequent good usage, that there are no better solutions, and
> that their introduction would not lead to a reduction in the experience
> for either AT or non-AT users.
> Evidence was collected showing that the conditions apply for headers="".
> Evidence was collected showing that the conditions did not apply for
> summary="".
> That's the only difference.
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Laura L. Carlson
Received on Sunday, 6 December 2009 13:01:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:27 UTC