Re: function and impacts (was: @scope and @headers reform)

Laura Carlson wrote:
> It is highly commendable to improve the algorithm, but retaining
> headers/id functionality is needed as well as backwards compatibility.
> I June 2007 PF advised grandfathering it into the spec: "a
> re-engineered solution could deliver both superior usability and
> authorability. 

+1, That is my position on this subject also.

Henri said:
> That said, I have four problems with the way headers/id has been lobbied.
> 
> 1) Headers pointing to td. I may be missing some practical issues here, but to me it seems that this is essentially a statement against native markup semantics enabling accessibility 
>and for promoting bolt-on accessibility as an ongoing solution. 

It's not a desired stance /against/ native enabling semantics at all. 
It's a distilled realization that this may be needed in order to make 
more complex tables accessible in a way that will practically work. 
Again, the semantic ideal vs the real world. Supporting this behavior in 
the spec until UAs can deal with the improved algorithm (and you make 
very valid points about the need to improve it) would mean that HTML 5 
will support older AT "out of the box". On this issue anyway.

>To raise the overall accessibility on the Web, making things work out-of-the-box should be the way to go, so we should promote proper use of th semantics.

Whatever the solution while one eye should be on the brave new world we 
must have our feet firmly on the ground. By that I mean, ask yourself 
"How will the choices I make effect end users?". I work with people with 
disabilities so they are the first user group I think of, so the 
discussions that I get involved with here are largely motivated by a 
desire to inform the group. It's a good question.

> 2) The attitude that a *handful* of AT vendors can't implement complex algorithms so instead it's OK that *countless* authors should go through trouble they wouldn't need to go through
  >if the client software had the kind of algorithms James' inspector 
has is just wrong.

James' table inspector is a very useful tool and yes, AT support for 
these algorithms is poor. If we try and shoe in our ideal of how things 
should be, even though we know in the real world our ideals may not be 
supported, surly we are asking for trouble? Especially when we can see 
that even existing table algorithms are poorly supported by current AT, 
and the HTML 4 spec has been a TR for many years. If this pattern 
continues, and I see little evidence to the contrary, whatever comes out 
of the stable door when HTML5 is unleashed will in all likelihood also 
be poorly implemented.

> 3) Even if I'm inclined to think that headers/id as a pre-existing feature should be kept as an override and for targeting legacy UAs (even if the case for introducing headers/id to HTML now might not quite be strong enough if headers/id hadn't been in HTML4), I don't like the attitude of trying to fast-track this particular thing even by trying to use another WG to override this WG when there are some many other things in the queue (including the WF2 stuff from 2006, which is being processed now). If an implementor had announced that s(he) was scheduled to touch the table accessibility API exposure code in Gecko, WebKit, Opera or Trident imminently, then there'd be a good reason to put this issue ahead of queue.

As Laura mentioned,  HTML WG has requirements in our charter to work 
with  WAI, and PFWG in
particular. It says: "The HTML Working Group will cooperate with the
Web Accessibility Initiative to ensure that the deliverables will
satisfy accessibility requirements. Coordination with WAI will be
primarily conducted through the Protocol and Formats Working Group,
but direct coordination with other WAI groups, such as Web Content
Accessibility Guidelines Working Group and User Agent Accessibility
Guidelines Working Group, will also be done when appropriate." [1]

I don't see it as fast tracking (not when it has taken 14 months to get 
this far, if we are anywhere) and LOL add the past ten years of 
discussion for the last iteration of HTML into the mix to get a true 
picture, so a fast track this isn't.

> 4) The message has been "HTML5 should have headers/id"--just that. However, I haven't noticed suggested solutions to obvious problems that would flow from having headers/id, such as how to deal with cyclic references. 

Well, we have anecdotal evidence, expert opinion, we could have video 
footage (though I am unconvinced at how effective that would be), 
complex table examples to indicate the issue, and many many emails on 
the pros and cons from a multitude of perspectives. As far as cyclic 
references, I have never come across them myself, apart from on this 
list :-)

Cheers

Josh

Received on Thursday, 25 September 2008 07:59:48 UTC