Accessibiliy? Usability? How about Practicality?

Talking to Saroj led to other thoughts about accessibility in practice as well. She showed a slide set at the Web Design Meetup with the humorous pie chart. Note the yellow and magenta areas in particular.

The shifting sands of Web browsers and server technologies upon which people build their house-of-cards Web sites and pretend-Web-CMS's have limited the potential for truly accessible sites by consuming excessive developer cycles (as suggested by the chart). An even worse roadblock is that the subsurface, founded as it is upon HTML recommendations, is a growing swamp filled with plenty of rotten ideas, many of which were chosen to limit the usefulness and accessibility of content.

Take the DIV and SPAN tags for instance: designers still use them as layout primitives, rather than as purely semantic concepts of "group" and "fragment". I assert that this is still table-based design, just with different labels. People make pure-CSS designs this way, but it is still bad practice. The issue is beyond the idea that one or another screen reader can ignore the markup and more-or-less give something like what a non-vision impaired person might see. The problem is, the underlying HTML formatting architecture is biased toward this kind of practice, so in order to get sites that provide the visual appearance designers are still intermingling markup-just-for-the-purposes-of-layout with semantically meaningful content. Thus we're really not separating "style from content", just CSS style attributes. Much of the layout code is still embedded in the content.

Similarly for guidelines like using an H2 tag before an UL LI used for menus, from an architectural perspective it is a hack: a menu is not a heading, nor a heading a menu, although both may be considered navigational primitives. Thus we are introducing rigid structures which don't mean what they say, and at that just for the sake of a limited set of reading devices. Which is to say, we are making guidelines to mangle non-semantic HTML to work with a specific vendor's browser because of what it can do today.

I certainly understand the rationale: it is pragmatic. A real tool can read that code, and a person gets fairer access to public sites because of it. That's a good thing. The bad thing is the twisted architecture which then telescopes and reinforces itself by twisting working practices. Like a tree growing around an obstruction like a rock: once grown, the tree remains deformed even if you remove the rock. The BEST practice would be to grow the tree in the open, clear of obstructions. That's what generic markup is about. (And if you want to extend the metaphor, DITA is like training the tree to an arbor. Maybe that's what it takes for farming levels of productivity in generic markup. )

I'm hoping to see more in the ARIA recommendations about this, but given the Web vendors' penchant for throwing obstructions into the language machinery, I'm no longer as optimistic as I once was.