- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Wed, 24 Sep 2008 18:25:51 +0100
- To: "Henri Sivonen" <hsivonen@iki.fi>
- Cc: joshue.oconnor@cfit.ie, "James Craig" <jcraig@apple.com>, "Al Gilman" <alfred.s.gilman@ieee.org>, "Chris Wilson" <Chris.Wilson@microsoft.com>, "W3C WAI-XTECH" <wai-xtech@w3.org>, public-html@w3.org, "Gez Lemon" <gez.lemon@gmail.com>
hi henri, If the spec stays as is, it will leave me in my professional work to advise clients (in the future): For cases where they want to mark up complex and irregular data tables so they can be interpreted relaible by AT , (admittedly not a frequent occurance but it does occur.) 1. To continue to use HTML4 2. write non-conforming HTML5 3. use aria-labelledby example - (http://www.paciellogroup.com/blog/misc/complexdatatable.html) I can live with that. In regards to your process gripes. I don't like that the HTML5 spec is controlled by one person and that W3C process in the HTML WG is a charade, but we all have our crosses to bear. regards stevef 2008/9/24 Henri Sivonen <hsivonen@iki.fi>: > > 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/ > > > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Wednesday, 24 September 2008 17:26:27 UTC