Working together for standards The Web Standards Project

On Monday, IBM officially announced its support for the Dojo Toolkit JavaScript framework. This announcement comes soon after the creation of the Dojo Accessibility email list, and like its other open source donations, IBM’s support for Dojo includes a major emphasis on accessibility for people with disabilities.

Several weeks ago, Dojo project lead Alex Russell and IBM’s Becky Gibson quietly committed the first source code update towards support for dynamic accessible web content. Though widely unnoticed, this update marked an important step for Ajax accessibility and was the first public indication of the IBM endorsement.

However, the Dojo updates center around other IBM-sponsored suggestions to the W3C PF Roadmap, so I was skeptical. Though partially supported in Window Eyes and FireFox, the dynamic content features rely on a set of assumptions not yet standardized. Wondering what made this approach any better than any other proprietary feature update, and slightly worried that IBM was steamrolling the groups for its own benefit, I approached Becky for comment, fully intent on a WaSP sting. Instead, I was pleasantly surprised by her explanation.

The justification is that, in addition to going through the proper, open standardization channels within the W3C, the IBM accessibility team wanted to create an adoptable, practical solution. The approach offers an open forum for feedback while attempting to create a de facto standard with a relatively-short adoption timeline. The reason for creating these concurrently is that practical challenges in the working examples can feed back into corrections for the standardization drafts in progress and, in the meantime, developers and disabled users can benefit from a real working solution.

More improvements in JavaScript accessibility and usability are in the works. Keep you eyes peeled for developments from the W3C WebAPI and PF Groups, as well as coming updates from the other major scripting libraries.

Your Replies

#1 On June 6th, 2006 7:19 am Joe Clark replied:

It’s inappropriate in the extreme for the Web Standards Project to sound so impressed by this whole thing, which busts the HTML specification.

#2 On June 6th, 2006 9:05 am Richard Marr replied:

You’d be fair to say that the WSP would be on dodgy ground by blindly supporting Dojo, but that doesn’t seem to be what they’re doing. I understood James Craig to be saying that he was pleasantly surprised by an explanation that he was expecting to find distasteful.

New standards and specifications are born all the time from innovation and creativity. I don’t think this situation is quite as black and white as your slightly fundamentalist post suggests.

#3 On June 6th, 2006 9:57 am Trails replied:

With respect, Mr. Marr, I have to disagree.

The above technique violates the HTML spec, which conflicts with what WaSP states in part on its “About” page, “… The Web Standards Project (WaSP) fights for standards that reduce the cost and complexity of development while increasing the accessibility and long-term viability of any site published on the Web.”

The justification supplied can be paraphrased as the standards submision and approval process is too lengthy. While I agree that it’s too lengthy, and Big Blue’s heart might be in the right place, doing an end run aorund the W3C is problematic, and we know where implementation before standardisation gets us.

I’m all for IBM pushing to streamline and speed up the W3C. Treating it as an after thought or parallel process to standardisation is frought with problems. What if all major software developers did this? What if ALL software developers did this?

Didn’t we just get out of this hole with Internet Explorer?

#4 On June 6th, 2006 11:57 am WaSP Member jcraig replied:

I apologize for not explaining more about the Accessibility Roles, but there is nothing about them that inherently breaks the XHTML specification. Although the first source update and the examples listed above rely on some non-standard expando attributes, the developing roadmap suggests adhering to the standards by using namespaces within the XHTML specifications. My skepticism was about implementing an undefined standard, not about implementing a standard that breaks another. It’s already apparent that the most recent draft is better than the original examples; that the draft and the examples are mutually beneficial.

If I have concerns about the future of this direction, it is that some of the W3C groups are not working as closely together as some of the member companies appear to be.

#5 On June 6th, 2006 1:24 pm Joe Clark replied:

IBM has corporate motives behind its intense push to break the HTML spec (or publish highly specific XHTML DTDs that will make this business legal). The WAI Protocols & Formats star chamber has been assisting in this regard.

Here is my question, and it’s the same one I’ve been asking since I saw a demo of this approach in Boston in 2005 and immediately asked why it was busting the spec: This is a priority fix for HTML?

#6 On June 6th, 2006 2:16 pm WaSP Member jcraig replied:

@Joe: I’d like to remind you that all corporations have corporate motives. Try to look past the tabindex addition as it stands now, and see that the proposal has the potential to become one of the first useful implementations of the X in XHTML.

I’d also like to remind you that individuals—you and me included—have professional motives for the announcements they make and for the choice wording of their responses, such as your comment about it being “inappropriate in the extreme for the Web Standards Project to sound so impressed…” You’re more than welcome to call me inappropriate—I often am—though I’d refer you to the disclaimer at the bottom of this page for the official WaSP stance on the matter.

#7 On June 7th, 2006 2:50 am Alex Russell replied:

Hi Joe,

The minimal system that we’ve committed to trunk operates on expando attributes *in templates*. These get transformed to correctly namespace’d XHTML2 role and state values at runtime and never exist in the document (in either form) before the widget system upgrades the page from it’s initial state, so the markup for the page that you send down the wire never has to be “polluted”.

Joe, I know you’re not willing to give us the benefit of the doubt given our previous run-in’s, but with Dojo we really *are* trying to build things that help users. All of them. That goal leads to a pragmatic approach which uses the current browser state of the art (and a good dose of realism about our deployment environment) to provide a stable platform for people to write accessible apps to today. We’ll gladly get out of the way once the browsers give us everything we need in a coherent portable way.

Given that it looks to be a long road until that happens, I’d like to invite you to join us is figuring out how to do the right thing by all users until then:

http://dojotoolkit.org/mailman/listinfo/dojo-accessibility

Regards

#8 On June 7th, 2006 1:16 pm Joe Clark replied:

The closest thing I can find to a commitment to Web standards in anything produced by IBM, Mozilla, or the WAI PF star chamber is a commitment to use XHTML 1.1 (yes) with a custom DTD. ALl well and good, except for getting it to work in IE6, which may admittedly not be a priority.

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

#9 On June 7th, 2006 7:11 pm Alex Russell replied:

Hey Joe,

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

#10 On June 9th, 2006 9:48 am WaSP Member feather replied:

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.

#11 On June 9th, 2006 6:37 pm Alex Russell replied:

Hi Feather,

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

#12 On June 15th, 2006 11:24 am luxuryluke replied:

Personally, while i find all this discussion intriguing (and somewhat above me), I’m just really excited that there is yet another way to design interfaces that work well and are easy on the eyes of developers (code) and the end-users (wysiwig).

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]

#13 On June 16th, 2006 12:01 pm Kary replied:

I think this was very smart by IMB this is just another great product in a long line of products. And I totaly agree with Luke in that it is nice to have another easy to use products for web develpoers.

#14 On June 19th, 2006 1:33 pm WaSP Member jcraig replied:

Developing news from Derek: Sun joins IBM for Ajax development.

#15 On July 3rd, 2006 9:54 am Aaron replied:

This was a relly nice read ! Thanks

#16 On September 22nd, 2006 11:03 am David replied:

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

#17 On October 10th, 2006 3:31 am Simon replied:

Great article. I have passed this onto our tech team. Great to see Accessibility getting more coverage these days.

Post a Reply

Comments are closed.