W3C home > Mailing lists > Public > public-html@w3.org > August 2008

Re: Deliverable for Action 72 @headers

From: Gez Lemon <gez.lemon@gmail.com>
Date: Sun, 24 Aug 2008 19:54:30 +0100
Message-ID: <e2a28a920808241154t40c947b4n63c82d9fe670ce10@mail.gmail.com>
To: "James Graham" <jg307@cam.ac.uk>
Cc: "Laura Carlson" <laura.lee.carlson@gmail.com>, "HTML WG" <public-html@w3.org>, "Ian Hickson" <ian@hixie.ch>, "W3C WAI-XTECH" <wai-xtech@w3.org>, "Joshue O Connor" <joshue.oconnor@cfit.ie>

2008/8/24 James Graham <jg307@cam.ac.uk>:
> I think there is now general agreement that there is more than one way to
> skin a cat which I think just leaves one more issue to address here.

As I said earlier, even though nested header elements don't feel
right, I wouldn't oppose them, as it's better than what the current
spec allows. I'll leave the problems of nested headers to the
architectural people, as they are better able to explain how they
might be problematic than I am. Making the "Budgeted", "Actual", and
"Forecasted" cells header cells in the example data table [1] seems
strange (assuming the scope algorithm only applies to the cells in the
reading order of the table - e.g., left-to-right for English), and
there would still be scenarios where the headers attribute should be
able to reference a td.

> Gez Lemon wrote:
>>>
>>> In the specific case of table headers, I have reservations about
>>> the current spec, but I recognize that it is in a state where the best
>>> way
>>> to produce improvements is to see how it fares in actual implementations
>>> and
>>> under user testing.
>>>
>>
>> The improvements in this case have been to introduce conformance
>> requirements that mean complex data tables cannot be marked up
>> accessibly, which doesn't seem like an improvement to me.
>>
>
> I meant "improvements from the current spec to a better spec".

I take it there wasn't a design decision to make the current
specification suboptimal with a view to improving it at candidate
recommendations stage, as that would be a very strange way of
operating. It's already clear that the current specification isn't
good enough to be able to provide accessible data tables.

>>> People implementing the spec and going "look this user
>>> can't understand this type of table because they need more information"
>>> is a
>>> really strong argument, and really likely to produce a change. In the
>>> meantime by not focusing on this issue I hope to free up enough bandwidth
>>> for everyone that progress can be made in other areas.
>>>
>>
>> I raised two bugs [1] [2] with that type of information, and both were
>> dismissed in minutes, so I haven't seen evidence so support your
>> assertion.
>>
>
> The important point was *implementing the spec* to perform user testing. We
> agree that there seem to be issues with the current spec. The strongest way
> to make the case that these issues need to be addressed is to go away and
> implement the current spec and show how it doesn't work e.g. by
> demonstrating user confusion compared to a different algorithm in which
> headers my themselves have headers. Or to get an implementor to explain why
> they won't implement the current spec in their product.

If things are removed from a specification that works, why on earth
would the implementers need to remove the feature in order to prove it
doesn't work, when nothing has been provided to make it work?

If the markup language doesn't allow the headers attribute to
reference a td, removing those relationships where they exist to
adhere to the markup specification will mean information is lost.

If the markup language doesn't allow the scope attribute on a td,
removing those relationships where they exist to adhere to the markup
specification will mean information is lost.

Similarly, other accessibility attributes or conformance requirements
that are removed from the specification with nothing to replace them
doesn't require an implementation to prove that it doesn't work - it's
obvious. What's needed is proof that those accessibility attributes or
conformance requirements were not necessary. I've not seen proof, but
I've seen opinions about how things work that are based on someone's
opinion, rather than what actually happens.

Your suggestions aren't allowed in the current specification, and
dealing with these issues at candidate recommendation stage seems
ridiculous, as it's obvious the relationships won't work now.

> Of course this isn't the only way to effect change; Hixie might decide that
> the arguments presented are stronger than his counter arguments when he next
> examines this issue.

How does he measure how strong an argument is? He dismissed the
counter arguments I provided without understanding them. How come it
depends on one person to decide on whether things are allowed in a
specification, when it can be proven that those relationships are
required?

> But it is by far the most compelling and potentially
> gets an implementation into the hands of users which is good for them and
> good for us when we reach CR.

Removing accessibility features isn't good for people who rely on them.

[1] http://juicystudio.com/wcag/tables/complexdatatable.html

Gez


-- 
_____________________________
Supplement your vitamins
http://juicystudio.com
Received on Sunday, 24 August 2008 18:55:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:22 GMT