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