Not to mention that it’s open source, easier to implement, and at least it lives in the [very large] arena of semantic markup.

[backing out of the conversation with a humble bow]

So this discussion is a bit weird because it seems to assume that once you’ve got a DOM bootstrapped, you somehow are under the same constraints as you were should you assume that the document is static throughout it’s life-cycle. You seem to be under the impression that it’s a reasonable thing to do to assume that a document based on a semantically impoverished markup language ((X)HTML) can fully represent the interaction primitives that we’d like to provide to the user without resorting to composition of things that *gasp* might not have semantic meaning!

Functionally, this is why the XBL language and now Dojo’s widget system are so tremendously important. We’re not discussion a change to the display of some semantic content. We’re generally talking about the wholesale replacement of one set of less-information and choice dense UI elements with ones that pack more (and different) meaning. Script gives us the ability to do this and still present some navigation and accessibility information without the language needing to be made aware aprioi of all of the “semantics” that my application’s UI will represent and the state transitions that those elements will undergo.

Joe has taken the stance variously that we should be adding new tags, which is another way of skinning the cat, but one that I think is doomed to failure if it’s the only tool we bring to bear on the problem. I’ve used semantically rich markup languages (e.g., DocBook), and they fail in all of the same ways that HTML does. Scripting and flexible, quickly iterable interfaces/contracts like the role and state information that we can add at runtime to inform assistive technologies of changes allow to make life better for users without putting onerous constraints on developers.

I’d argue that the technologies that will win the accessibility race will exhibit many of the same traits that the web in general has, namely that if they are easier to use than the alternatives then their actual conceptual quality can be very low. It won’t matter, though, because they’ll still win. HTTP’s single-direction links are the poor step-child of Xanadu. HTML is the poor man’s SGML dialect. Worse but easier to implement wins. There’s very little precedent to suggest that yelling at developers to write better code or understand their tools better will ever get you anything but a nice lather of moral outrage. And I say this as someone with a computer security background. Moore’s Law discounts perfection and provides the advantage to standardized inefficiencies that make things cheaper to do for *implementers* (Java and Python are my favorite examples of this).

It’s time that we stopped treating markup semantics as a religion and started asking whether or not, in a particular context, they are better for the users we’re trying to serve. If we can get there better, faster, and more importantly, cheaper using something else, we owe it to our users to do exactly that.

Regards

As for semanticness, I really wish we could get beyond that straw man. We’re talking about *applications* with this announcement.

Alex, with all due respect – so what? Yes, we are talking about applications. They need to be accessible too. You are building applications with (X)HTML and your responsibility is to use the language semantically. I don’t see why you are saying semantic markup is a straw man.

The Dojo widget system provides a way for us to build semantic markup and then provide whatever display rendering of the intended component is appropriate. That these things don’t map to a sematic DOM is only to be expected.

I don’t follow your last statement. If you build semantic markup and then change the display, how is it that it doesn’t map to a semantic DOM? (This is a serious and sincere question – I’m really not sure what point you are trying to make)

we’re stuck with figuring out how to fix the experience with the tools we have.

Its not just about using the tools you have (I agree with you – we do need more than what we currently have avaiable). It is also about using the tools that you do have correctly.

Regarding tabindex, I think the main driver behind “-1″ is that it maps to what IE is exposing down to it’s accessibility bindings. Is it a good idea? I don’t know, but it works today.

The WCAG process is clearly off the rails, and I think that if you use that as the basis for the leading question that you’ve asked, you can get to one of two conclusions about IBM’s motives (which I have no inside knowledge of):

1.) that IBM has customers who are screaming for an answer and they need to ship products that meet a market need
2.) that IBM has a dark under-motive for wanting to somehow keep the W3C process as broken and impotent as possible so that they can pounce on the resulting chaos and provide something proprietary to fill the gap

ISTM that the second is both less likely and less plausible, not least of all because they’re making the stop-gap solutions part of Open Source projects like Mozilla and Dojo. Of all the organizations involved, IBM is the only one I can think of without a proprietary markup agenda. Companies like IBM don’t go throwing resources at a problem unless there is a market for whatever solution they come up with.

Whether or not their size and internal process affects the quality of those solutions is another question entirely, and one that I’m also not suited to answer.

As for semanticness, I really wish we could get beyond that straw man. We’re talking about *applications* with this announcement. The Dojo widget system provides a way for us to build semantic markup and then provide whatever display rendering of the intended component is appropriate. That these things don’t map to a sematic DOM is only to be expected. It’s why things like XBL were introduced (and sadly not implemented everywhere). We’re half-pregnant today because the web grows in ugly ways. Always has.

If the W3C wants to start doing something useful again, I can think of all kinds of things that *should* be part of new and existing standards that would ease everyone’s lives and make your goals of semanticness possible as a side-effect. The fact that there’s a widget system in the JS toolkits in lieu of in-browser shadow-DOM support is just brain-dead. We shouldn’t have to be doing *any* of this. Given that this is apparently still not something the W3C views as useful, we’re stuck with figuring out how to fix the experience with the tools we have.

Regards

What I see actually happening is this: IBM adopted Microsoft’s nonstandard use of tabindex=”-1″, which could easily have been “1″ or “32768″, and bases an entire technology around that. Fundamental to this technology is adding new attributes to nearly everything, including nonsemantic elements like span. In the future envisaged here, users of certain screen readers could tab onto those spans and operate them via keyboard.

But a span doesn’t mean anything. While this indicates a lack of richness in HTML semantics, something groups like WHATWG are eager to fix if it suits programmers (e.g., blockcode), it also indicates that nobody is trying particularly hard to solve that problem of richness. If we’re defining a new DTD, why not define a few new elements? The argument that browsers won’t know what to do with them is an argument that can be made about the new role, state, and tabindex attributes. Why be half pregnant?

Again, what is the corporate agenda behind this busting of Web standards?

(Thanks for the advice on tone, James. I’ll add it to the pile.)