Re: Comments on IRC log

Joshue O Connor wrote:

>>>>> # [07:52] <Hixie> the most annoying thing for me in public-html is
> the way most people jump to a solution rather than determining the problem
> 
> Thats not true. 

I disagree :) Although having said that I think things are changing for 
the better. Let's take the example of the headers attribute, since that 
is an example that you yourself have used later. The first thing to note 
is that the headers attribute is a _solution_. So any discussion that 
starts with the premise "we need the headers attribute" has started by 
assuming a solution, rather than with a specification of the problem. 
I'm sure everyone who has been on the list for more than a few weeks is 
aware there has been more than one thread which has started with this 
premise. Indeed we have a Wiki page which documents much of the 
discussion which has stemmed from the premise "we need a headers 
attribute"[1].

The alternative which Hixie, amongst others, advocated is to start with 
a clear definition of the problem. In this case that would be something 
like:

"Users without visual UAs have difficulty in navigating the complex 
relationships inherent in the structure of a table. In order that these 
users can understand tabular content they must be able to determine the 
headings that apply to a particular cell".

Having defined a use case, it is easier to work out what solutions would 
meet the use case and what are the advantages and disadvantages of each 
e.g.:

Algorithm for walking the table from a cell to the row and column headers:
Pro:
Simple for authors (only requires correct use of <th> and <td>)
Con:
Relatively complex to implement
Doesn't work for complex tables
May give the wrong answer in some cases

Scope attribute
Pro:
Moderately simple for authors, only need to add one piece of invisible 
metadata per heading
Works with more tables than the no-extra-metadata case
Con:
Relatively hard to implement
Doesn't work for all conceivable tables

Headers attribute
Pro:
Works for all conceivable tables
Simple to implement
Implementation support already in some prominent UAs
Con:
High burden on authors; must repeat the metadata once per cell
Metadata prone to be incorrect (can set up cycles of headers or point to 
non-<th> elements

describedby Attribute:
etc.


I'm sure people who know more about this issue can fill in this sort of 
assessment better than I can and add relevant research about things like 
how often headers is used in a nonsensical way, how often tables need 
more than can be provided for by @scope, and so on. Indeed, that has 
been done with some success for the case of in-body style [2] and 
fallback for images [3] although nobody seems to have taken on the task 
of doing the same for table summaries [4], although I tried to seed the 
page with the correct format.

> People try their best to answer related threads and contribute. 

Answering threads may not be the best way to contribute. So far there 
have been ~6000 mails to public-html and expecting the editors to digest 
all that information in raw form is unreasonable. Therefore they have 
set out a clear preference for information to be presented in the form 
described above [5],[6].

>>>>> # # [07:54] <Lachy> yeah, that too. I tried getting people to focus
> on the problem months ago, and it didn't really work then, and still not
> working now
>>>>> # # [07:55] <Lachy> like in the whole headers="" debate, I tried to
> talk about how we could make tables accessible without needing headers,
> and basically got accused of ignoring the needs of the accessibility
> community
>>>>> # # [07:55] <Hixie> yeah
>>>>> # # [07:56] <Hixie> it's ridiculous
> 
> This is slightly alarming as it seems to say that - we tried to ask you
> what you thought but we didn't like the answer we got so we may not ask
> again in the future. As far as the headers thing goes I am totally in
> the dark about what the suggested replacement technique was/is. Hence my
> own insistence on keeping the whole id/headers thing afloat - for both
> legacy UAs and also because I am confused about what the suggested
> replacement should be.

It's pretty clear that there is a level of disconnect between the people 
who are approaching this effort from a mainly accessibility background 
and those approaching from a mainly markup background. Maybe the people 
who have done a lot of work on accessibility have considered all the 
possible ways of solving accessibility-related problems with a similar 
set of values to those embodied in the HTML-WG design principles and 
have determined that the solutions like <td headers=""> and <table 
summary=""> are the best compromise. If tht is the case, I hope it won't 
be too much trouble to document all the solutions that were considered 
so that the rest of us can follow your thinking. Alternatively, it may 
be that there are _better_ solutions that have not previously been 
considered because people were working within the confines of HTML 4 or 
because the method of evaluating the possible solutions was not optimal 
(e.g. it favored solutions with high complexity and consequent low 
uptake over those simple enough to be used widely). In this case, going 
through the above process should help us to identify the solution which 
will have the most positive overall impact on accessibility.

It is a mistake to think that people don't care about accessibility. 
They do. It's just that different people here have very different 
backgrounds, experience and skills. The WHATWG process was very tolerant 
of people challenging the accepted wisdom about a topic; indeed the 
entire process challenged the widely accepted wisdom that XHTML2 was the 
future of the web. There is no reason accessibility is sacred in this 
regard; merely purporting accessibility benefits should not be a free 
pass into the spec. On the other hand we should strive to make HTML 5 
work well for people with atypical web browsing experiences and features 
that really promote this will, no doubt, be included. Unfortunately, 
some people seem to have mistaken challenging accepted wisdom about 
accessibility with rejecting the concept entirely. This is not the case.

> 
>>>>> # # [15:01] <Dashiva> This is orthogonal to fallback/alt content for
> images, though
>>>>> # # [15:05] <Lachy> oh well, the legal stick of accessibility has
> been waived again :-/
>>>>> # # [15:05] <Lachy> why is it that when accessibility advocates
> can't come up with a rational argument, they always fall back to the
> legal stick?
>>>>> # # [15:08] <Dashiva> Well, maybe they realize there are no carrots
> available?
>>>>> # # [15:25] <mpt> If the Web had smell-o-vision, would accessibility
> advocates fight for longdescs of odors on behalf of those with no sense
> of smell?
>>>>> # # [15:27] <Lachy> A perfume site that made use of smell-o-vision
> would probably provide a description of the smell anyway for all users,
> so they can know what it's like before sampling.
> 
> This section is frankly kind of amazing. In several fell swoops the
> entire efforts of the accessibility people on the list are dismissed as
> almost Pavlovian responses and then an absurd dialogue about
> smell-o-vision ensues. This is trivializing the efforts of people here
> who are concerned about the needs of people with disabilities.

On the contrary, I would suggest that the discussion of smell-o-vision 
is an example of a case where the sensory experience transcends the 
ability of most authors to replicate the content in an alternative 
medium. I would find it astonishingly difficult to provide a "longdesc" 
of a smell, especially if it were targeted at a user with no historical 
experience of smell to provide points of reference. The same is true of 
many images; I could provide a pedestrian description of the elements of 
the image but leave the reader in the dark as to the _point_ of the 
image which might be entirely apparent to a sighted user. This is a 
problem that Maciej has alluded to several times in the past and has 
identified as a problem with the current wording of the spec text which 
identifies an <img> as a graphical representation of a piece of text.


[1] http://esw.w3.org/topic/HTML/IssueTableHeaders
[2] http://esw.w3.org/topic/HTML/StyleAttribute
[3] http://esw.w3.org/topic/HTML/LongdescRetention
[4] http://esw.w3.org/topic/HTML/SummaryForTABLE
[5] http://lists.w3.org/Archives/Public/public-html/2007Jun/0863.html
[6] http://lists.w3.org/Archives/Public/public-html/2007Jun/0953.html
-- 
"Mixed up signals
Bullet train
People snuffed out in the brutal rain"
--Conner Oberst

Received on Friday, 27 July 2007 00:24:01 UTC