Feeling Cynical about Web Accessibility and Standards?
Shortly after I started working in the Higher Education web space (2001) I came across the brilliant post by Jeffrey Zeldman on A List Apart that lead down all sorts of paths towards web standards and accessibility. I wasn’t alone. I think many web folks that were dealing with the internet bubble bursting were inspired by Zeldman’s call to arms to change things and many had the time to explore the possibilities. I did what I could in my position to influence the University of Waterloo web space and in 2004 we had a XHTML/CSS layout that was clean and accessible which was finally let loose on campus in early 2005.
Things changed on campus and I spent more time on usability testing and meeting with the few students that relied on adaptive technology. I wasn’t put off by the fact only two people might notice the enhancements as I knew UW was doing the right thing by fixing things. However, all of the applications students and staff rely upon were not going to be fixed or changed with even the course management system saying it was section 508 compliant but that version was even less usable than the main user interface. A problem that I have observed is that accessibility laws or regulations seem to force people under the covers in the HTML to make things work in screen readers (sometimes) but people ignored how usable the content or the application actually is.
It gets stranger by the day, developers demand unit tests they can meet to make the app accessible but there aren’t any… I don’t think. Laws and guidelines just compound the problem by giving people a false sense of compliance. In the case of learning environments most aren’t even all that usable but golly gee they are 508 compliant. It starts to drain hope.
Blame technology or developers?
A developer most certainly should make browser based apps (HTML/JavaScript/CSS apps) ‘professional’ grade by using semantic HTML, unobtrusive JavaScript, and sensible colour contrasts. That checks off a lot boxes in terms of Search Engine Optimization, re-usable code, dealing with rendering fun, and accessibility. There are different ideas of what it takes to make a web app or page accessible however, and I am not sure a developer should kill a load of time on certain things (that change with the project) like zoomable layouts—especially when browsers are implementing features that make that time wasted.
I am not sure that is inline with that Derek brings up in his post When is the right time for accessibility? as I think some (or a lot) of the things that are generally seen as making HTML as ‘accessible’ really should be the responsibility of a different team of developers (mainly those that make web browsers). I don’t disagree with the strategy of implementing accessibility later based on need and I think Derek’s post offers a bit of an olive branch to developers. You shouldn’t be expected to be all that accessible until you actually know that (a) people will use your product and (b) knowing how people will use your product.
What is my problem?
Honestly I don’t know. Call it a long winter, annoying problems repeating themselves for years, and new experts making the same mistakes.
I started this post sometime after I saw the small torrent of comments about a JavaScript framework which was summed up in Drew’s post The Cost of Accessibility. Drew is on that fence of innovation needs to take into account the reality of the web browser right now and I am not sure I agree.
At the same time I got into a few insane conversations about making the new job system for co-op on campus accessible and IE6 isn’t dead (like we had hoped) for an important 5% of our user base. Our development process makes it insanely difficult to spend time testing, fixing, and tweaking for accessibility (application is hiding behind a VPN and has a few other features that make it hard to access outside of our network). We use jQuery wisely, CSS, and HTML to the browser. AJAX is sprinkled in parts but nothing should depend on it. For a first version that isn’t really ready for user testing it has some good fundamentals but someone pulled the ‘yes but you are missing x’ and I just got deflated.
The problem, in my mind, goes back to the way people think about accessibility. The whole issue is an Art not a Science and certainly not engineering. Engineers have left us with this problem, with HTML, a stateless browser, and a crippled feature set that forces hacks, short cuts, etc. They are doing their part, slowly. Code artists like Derek Featherstone and Drew McLellan help spread the word and lower the barriers through simplified approaches and keeping the dialogue going.
HTML 5 gives me hope even if the Engineers aren’t too quick to drop it in our browsers! I am not really cynical 