balancing accessibility/setting priorities
With all the recent progress in the web development scene priorities have clearly shifted. Canvas is the bomb, css3 is like pixie dust and experimentation equals attention from the community. We're living on a high, but at the same time we seem to have lost sight of some of the best practices of yonder. Once more accessibility is reduced to a mere afterthought, erasing five long years of sensibilization. But how do we counter this evolution?
levels of accessibility
Last week I read an article on html source order by Roger Johansson. I usually tend to agree with the articles he writes, but this particular one seemed to take accessibility concerns just a little too far. The article argues that the source order of a html page should match the visual order of element rather than follow a logical structural flow. The reason: accessibility concerns.
Don't get me wrong, it's good to see articles on accessibility these days (just this morning I found a comprehensive article on modals, completely lacking any kind of accessibility best practices and concerns), but accessibility is still just one of the many things we web developers have to take into account. It's important that our sites and applications are accessible for as many users as possible (I say users as it is broader than just people, it also includes crawlers etc), but it's virtually impossible to give everyone out there the best experience possible.
The difference between both opinions lies with the level of accessibility. It's not that either option will render the information inaccessible to anyone or anything out there, the question is who's given the most priority and who do we want to service best?
the tightrope dance
In the end it's all about balance. Compare what you gain with what you lose and make a decision based on that information. Now looking at Roger's arguments I can't say they are convincing enough to make me change my mind. It's not that I contest the things he says, but confusion between sighted and visually challenged users looking at the same screen seems like a very minor use case indeed. Confusion about focus order is a stronger point as this affects a bigger group of people (everyone using the keyboard to navigate), but as long as we're talking huge blocks of content (and not a single link that's positioned in a completely different area) I don't think this should be a real issue either.
On the other side of the fence lies structural validity (ie, is the order of elements in the source code logical). A popular use case here is sub navigation (usually found in a left sidebar, next to the main content of a page). Sub navigation is only relevant if the content on the current page is insufficient. To know whether the content is insufficient you have to read it first, so the sub navigation should be placed after the main content in the source. For visual users this is a little different, as they can scan really fast to judge whether to continue reading the main content (based on amount or structure) or to check the sub navigation for further drill-down. People relying on screen readers and other assistive tools don't have that luxury though.
We tend to read from left to right, so if you want to match source order to visual order the sub navigation should actually be placed in front of the main content. Now if you ask me, I prefer structural validity to raising the accessibility for a very limited amount of people, but maybe that's just because I put a lot of effort in creating structurally valid html.
conclusion
Accessibility has an important place in our job and currently it's being grossly overlooked. On the other hand, it's just on of the many factors that influence the judgments we make. In the end it's all about balance. Divide all arguments in two distinctive groups and weigh these groups against each other. Personal preference will always have an influence on the outcome as we still lack hard figures to back our arguments (how important is structural relevance compared to the group of visual/screen reader duos? Any numbers?), and maybe that's where experience will help you to make better calls. Just realize that definite answers are really hard to find.
To get back to my original question (how to raise awareness for accessibility once again), I believe its crucial for accessibility concerns to remain level-headed and useful, instead of going head-on against the current trend of neglecting them. We can grind hours about the finer points of accessibility, but for now there are more important issues at hand. Make people think about accessibility when they reach for the canvas element, turn it into an argument for choosing javascript frameworks or incorporate it into the newly emerging best practices. If we turn accessibility into a purist matter now, we will probably alienate people even more of this simple concept, digging our own grave. Just my two cents.

Comments
Jethro Larson
From a business perspective accessibility is just like targeting certain browsers. If IE6 is 2% of your audience and JAWS is 1%, then supporting JAWS is half as important.
Devs should try to remove requirements for using their site as much as possible as that has a lot of secondary benefits, but it all has a cost.
Niels Matthijs
Taking care of accessibility is indeed more expensive, but I don't believe the extra cost is that much. Of course you have to invest the time to learn the techniques, but once you've mastered them it doesn't take much longer to apply them in projects.
Accessibility is not something you add at the end, if you do it right from the start it won't cause you much extra development time. In contrast with getting ie6 to work :)
Jethro Larson
Testing it is tricky though. There's a lot of different impediments. Blind, deaf, colorblind, blurry vision, no mouse control, poor mouse control, difficulty using keyboard(everyone on mobile is like this), and anyone using a netbook running Vista is practically disabled.
Accessibility isn't just alt text, it's defined by every expectation you have of the user.
How many sites pass contrast check? Not even Yahoo pulls it off.
Niels Matthijs
True enough.
But if you know what to do from the start, then part of the testing becomes obsolete (or at least you won't need to change much afterwards). Most techniques don't require much extra work to implement if you do it right the first time, or if you built yourself a good personal framework with these accessibility measures built in.
If you see accessibility as something that requires changes after you've built your templates, then it becomes a serious hurdle indeed. Problem is that with all the fuzz about new styling possibilities (and an ever-growing backlog of browsers to supports) there's just little time left to master these accessibility techniques.