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

On Sep 23, 2008, at 15:45, Joshue O Connor wrote:

> Henri Sivonen wrote:
>> For the use cases your clients have, would it be necessary to use/ 
>> recommend headers/id if browsers implemented the Smart Headers  
>> algorithm Ben mentioned and reported those associations to AT?
>
> I don't know yet. I am not sure that it is the right solution.

It seems to me that on the general level, an automatic association  
algorithm is the right way to go.

Which approach will improve Web accessibility more (on average across  
the Web): an approach that requires implementation in 4 code bases  
(the top 4 browser engines) or an approach that requires countless of  
content authors and Web app developers to indicate relationships by id  
references? It should be a no-brainer that the approach that requires  
fewer active participants should be favored if the the goal is to  
improve table accessibility on average across the Web.

It's worth noting that the example put forward as a reason why headers/ 
id is needed is (if I've understood correctly) from an intranet app.  
If you want to maximize the accessibility of an intranet app that has  
dedicated accessibility people on the team, then, sure, explicit bolt- 
on accessibility may give a more precise result than built-in  
automatic accessibility. But here again, we run into the conflict  
between designing technology for the Web vs. designing technology for  
intranet apps.

What works for intranets doesn't necessarily work on the Web.

> For the record, if a new authoring method works (i.e is well,  
> supported, easy to author/understand etc) I have no problem  
> recommending it. With this issue I am very concerned with legacy use  
> but I do concede that if a solution is semantically superior at some  
> stage a clear break must be made in favour of it.

Do you mean legacy content, legacy clients or both?

> But this is not a black and white issue, there are many shades of  
> grey. For example, support by AT for @scope is practically non- 
> existent. Anecdotally, it seems to me that many tables that use  
> @scope just happen to coincide in their design to how the screen  
> readers heuristic evaluation understands the content pattern, rather  
> than because @scope had been used to mark up the content.


Does it really make sense for AT to know *anything* about the scope,  
headers or id HTML attributes? Shouldn't the browser engine compute  
the associations and expose the associations via the accessibility  
APIs without telling AT how the associations were computed? There are  
fewer browser engines than there are are ATs, and knowing HTML is the  
core competence of browser engines but not of ATs.

For an accessibility API, it may be a sensible design for an  
application to declare that cell A is a header for cell B. It doesn't  
follow that making these associations IDREFs in HTML is a good design.

However, I do realize that there's are two plausible needs for headers/ 
id: authoring for legacy UAs and overriding the automatic algorithm  
when it fails. Both these activities are probably things that an  
"average author" won't do. Yet, I'm inclined to think that we should  
make the headers attribute on td and th pointing to a th in the same  
table a part of the language (mainly to support those authors who  
actually want to make a special effort to support legacy UAs) *unless*  
there's research showing that doing so on the Web makes tables less  
accessible due to existing erroneous use (i.e. that headers so often  
pointed to the wrong cell that acting on those associations did more  
harm than good). (If headers/id weren't a pre-existing feature, I  
probably would be of opinion that the feature shouldn't be introduced  
due to falling on the wrong side of 80/20.)

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

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. I'd have a much more favorable view on the exact same technical  
details and syntax if people advocating headers/id indicated that  
client-side automation were the goal and headers/id were mainly for  
legacy compatibility. (Putting the algorithm in browser engines  
instead of ATs seems to be the better place technically, though.)

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.

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.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 24 September 2008 16:34:53 UTC