In my opinion accessibility is something you shouldn’t have to think about. It should be an integrated part of the technology. If it’s not than the technology is broken. If authors are “abusing” such a technology to do cool stuff (for more than it’s designed to do) and you have to add specific code just to make sure it’s accessible you can be sure it won’t scale. It also won’t be used by your average web developer. Only the few people who are really into it and companies who are forced by law will make such enhancements for the benefit of a small group of people. Now it’s good that they care and make such changes to their pages, but it shouldn’t be necessary.
Lets make this a bit less abstract. What I’m referring to here is the role attribute used to “denote” the purpose of certain elements in a page. That knowledge about those elements can than be used by accessibility tools to aid disabled users use the elements for their specific purpose. class="datepicker" doesn’t help them much (unless part of some recognized microformat), but role="foo:datepicker" does I guess in some way. You still need to encode all the additional data needed for it in some way though. (Information about this can be found on the W3C WAI PF WG pages.
I have this thing with the role attribute which I wanted to write about for some time now and it kind of fits in here. It’s really hard for me to get how things like <a:b role="x:y> are actually going to scale. Also, how they are better than just having an element x:y. Take into account that the latter actually has even more benefits as you can easily give it various properties through attributes which are kind of hard to encode on the a:b approach. Besides, as we should have learned with the HTML object element overloading a particular element doesn’t really do any good and causes interoperability issues for the next decade or so. (And they still haven’t been sorted out. Fun!)
So web developers have this need to create date widgets and other types of widgets and they use some scripting and more or less neutral elements to accomplish that because no element comes close in semantics. Part of the reason is of course that HTML was originally a document language and is slowly evolving in being both that and an application language. Accessibility tools need more semantics to make sense of pages. So how about adding more semantics? How about actually making things simpler for developers and solving part of the accessibility problem at the same time? By letting web developers use more native controls those instantly become more accessible as the particular interface is done by the implementation. Also, doing this developers don’t have to give shit about accessibility and don’t (mostly).
Adding semantics and letting HTML evolve in a more application like language is good, though we should be careful by adding only the things we really need. Doing too much new things at once mostly fails. From those “basic components” you can easily build more complex widgets and wrap together in some XBL file.
Other ideas I had were that accessibility tools could become much smarter about content and markup. Guidelines for accessibility tell you to put “skip link” functionality for “art produced by characters” or a “navigation list.” How about just providing the option to skip the contents of pre elements based on some characteristics? Or if you have a ul or ol element containing li elements whose only child is a? Get the idea? If there is no nav element you can still be smart.