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

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