- From: Robert Burns <rob@robburns.com>
- Date: Fri, 27 Jul 2007 00:13:58 -0500
- To: James Graham <jg307@cam.ac.uk>
- Cc: joshue.oconnor@cfit.ie, Lachlan Hunt <lachlan.hunt@lachy.id.au>, HTML WG <public-html@w3.org>
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