Re: Comments on IRC log

Hi James,

On Jul 26, 2007, at 7:23 PM, James Graham wrote:

>
> 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].

When I first joined the WG, the @headers debate was raging, and I  
just read the emails and didn't jump in because I was still digesting  
the HTML5 draft and trying to understand the various issues involved.  
However, I think this is a good example of how poorly the discussion  
has often gone.

There has been a selective application of principles here (including  
WhatWG principles). The @headers isn't the only issue where some have  
leaped to the solution. There are many solutions in the current draft  
that still haven't had a use-case stated[1]. So it''s both difficult  
to discuss the current draft and it's more difficult to even review  
portions of the HTML5 draft when faced with solutions and no use- 
cases or problem statements. We have been told to look through the  
WhatWG archives to find those use-cases. Would it also be acceptable  
to tell others to look through the W3C archives to find the use-case  
for @headers? I don't think it would. I also do not think that it is  
an acceptable answer for point WG members to the WhatWG archives to  
find use-cases there. We're all here trying to improve the state of  
HTML for the future. It is not asking too much for advocates of a  
certain feature to provide, at least, some brief  description of use- 
cases (I can understand referring new, or forgetful, WG members to  
earlier posts in our own archives, but that's very different than  
sending us to other archives).

Turning back to the issue of the @headers attribute, I found the  
responses to the issue overly defensive and often uncooperative  
towards other WG members. Often times use-cases may be obvious,  
implied, or self-evident to one WG member and may be completely  
obscured to another WG member. So if anyone thinks another WG member  
is not providing a use-case, why not simply say, I don't understand  
the use-case you're addressing. Instead there is an assumption that  
the other WG member is just making up solutions for problems that  
don't exist. That's almost certainly not the case. In reading the  
HTML5 draft, I always read with the presumption that there are use- 
cases or problem statements behind the new features proposed for  
HTML5 (or even justifying the removal of HTML4 features)). It's not  
always easy to decipher what those use-cases/problem statement might  
be, but I think it's useful if we always assume the other person is  
trying to solve a legitimate problem.

My understanding to the issue of @headers is that it probably needs  
to be broken into the two forms of conformance to understand the  
issue properly. In terms of UA conformance the @headers attribute  
remains (likewise for any HTML4 facility). In terms of using the  
@headers attribute on legacy or even new content, the UA conformance  
meets that need. However, there's a problem with removing it from  
document conformance because it means accessibility oriented authors  
(meaning authors trying to make content work in existing  
accessibility UAs in a backwards compatibility way) will face  
countless errors (hundreds o thousands or errors) when checking the  
conformance off a document that makes use of the @headers attribute  
(on for example a large table or a document with several large tables).

So what about document conformance? Here I think there are use-cases  
or (perhaps a better phrase) problem statements that have been left  
unspoken. One problem statement is: the existence of the @headers  
attribute, along with a failure to explicitly guide UAs in matching  
data cells with header cells has led to an over-reliance by authors  
and UAs on the @headers attribute (rather than matching cells through  
@scope or other means). Of course completely removing @headers is a  
kick-in-the-butt approach. Removing it is like a wake-up call to UAs  
and says loudly "hey, look at this new algorithm. Use this for  
matching header cells to data cells." However, that's quite a heavy- 
handed approach to get the message across. Far better to leave  
@headers in the recommendation (or add it back if you prefer) and  
simply deprecate the use of @headers for such use in simple tables.  
Of course even that deprecation needs to be qualified since obviously  
authors will still need to make extensive use of @headers for  
backwards-compatibility accessibility reasons until all targeted  
accessibility-oriented UAs meet HTML5 UA conformance criteria (which  
could be a long time).

To me this would be like specifying that HTML5 conforming UAs should  
fix their OBJECT handling and then remove IMG from the document  
conformance criteria. If just such a proposal was made here  
(challenging the accepted wisdom as James calls it), it would be  
decried by many of our WG members as failing to take proper account  
of backwards compatibility (and perhaps rightly so). Yet the analogy  
could not be more apt (except that @headers actually adds  
capabilities to HTML that IMG does not add when compared to OBJECT)?  
Of course we do not need IMG if all UAs had an algorithm to handle  
OBJECT properly for images (and other embedded content too). However,  
every author using IMG would then see countless errors in their  
conformance report for every IMG element in the document.

> 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".

Once we leave the issue of backwards compatibility with existing  
accessibility-oriented-UAs aside, @headers really has nothing  
inherently to do with accessibility. Instead, @headers is completely  
about semantics: though semantics specified with accessibility in  
mind (and it is a semantic that probably has inadequate visual  
presentation controls compared to aural, as has been pointed out on  
this list). Once the use of  @headers is deprecated for use in simple  
tables and UAs implement the HTML5 algorithm for matching header  
cells with data cells, the further specification of @headers is  
purely about expressing explicit semantics of a complex relation  
between header cells and data cells. So the above specification of a  
use-case seems deliberately crafted to eliminate the use-case for  
@headers (the one that would justify keeping it). I'm not saying that  
it was deliberately crafted that way, however it's not that difficult  
to craft a use-case for a feature that wouldn't lead to its  
elimination (if we're being objective). Are tables, so complex very  
rare? No doubt. However, if the attribute is to remain there for UA  
conformance what possible cost could there be in maintaining @headers  
in document conformance criteria for those — possibly rare — cases  
when tables get that complex. Especially since HTML5 would offer no  
other alternative f or authors to express that semantic (in other  
words all benefits are removed with absolutely no savings in cost).

> [...]
>
> ugh 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].

It may be true that answering threads leads to too many emails for  
the editors to digest, but communicating on the threads (in a good  
faith manner) also helps us all to understand one another better so  
that we can actually write Wiki pages that benefit from that dialogue  
(and consequently benefit the draft).

>>>>>> # # [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.

As someone who comes at this from both a markup background and an  
accessibility background I don't think the distinction you're making  
is all that relevant. I think part off what's going on is that, after  
three years, the WhatWG has it's own received wisdom. I sense a  
resistance here to ideas not invented by WhatWG: ideas that challenge  
the WhatWG received wisdom. It's apparent in the discussion on IRC  
and it's often apparent in the dismissive responses often posted on  
this list.

> 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.

I don't find much challenging received wisdom in this paragraph. The  
notion that "merely purporting accessibility benefits should not be a  
free pass into the spec" sounds more like the same old mantra. What  
else can any of us offer to recommend features than to talk about  
their benefits (or perhaps costs, but as Henri points out we're  
talking marginal costs here and those are approaching zero in terms  
of adding a new feature or retaining an existing feature in document  
conformance). Why is a hyperlink sacred. Well it has certain  
"purported benefits": benefits I think should give it a free pas into  
HTML5. Same with other semantic facilities of HTML (like @scope and  
@summary, etc).

>>>>>> [...]
>
>
> 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.

As the drafters off a new recommendation for HTML, it's out of scope  
for us to come up with the perfect @longdesc text (I'm reminded of  
Ali G. asking an interviewee what the perfect PIN number would be  
that no one would ever guess it). For us, the point is to provide  
facilities that authors can use to provide a @longdesc of an image.  
If that's a difficult task for an author, that's really not our  
concern. Writing a novel is a difficult task. Should we not print  
novels because writing them is so difficult? So often the discussion  
of accessibility features in HTML5 turns to difficulties authors have  
in using those facilities. We should certainly try to address those  
difficulties. However, too often the conclusion is that the  
difficulties should imply the removal of the features. It's like  
we're saying: "You're having difficulty using those accessibility  
features correctly, so we'll have to take those away." I think that's  
absurd. It would be like saying: "You seem to be having difficulty  
maneuvering your wheelchair into the restroom, we'll have to take  
that wheelchair away." There are other ways to deal with those  
difficulties that doesn't involve scrapping the wheelchair.

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML#head- 
c62a1d12119821bab60d66c97c240cd411a011af>

Received on Friday, 27 July 2007 05:14:06 UTC