I had an interesting chat with some colleagues this morning about Web Standards and Web Accessibility on websites. I passed around a website article to my team from an organisation which preaches User Experience and Accessibility and I was extremely surprised to find out their site didn’t meet W3C Markup Validation or WAVE (Web Accessibility Evaluation Tool) standards.
This raised an interesting point – is it school-boy error that they’ve not made their site fully accessible or is it a case of hypocrisy?
If you’ve got a few minutes, go on-line to the sites above and test some sites which sell User Experience or are dedicated to web standards and accessibility. You’ll be surprised. From W3C’s point-of-view, they practice what they preach. If you validate their page against their own tool, surprise surprise, it passes fine.
I’m not going to name and shame organisations as there may be valid reasons why their pages don’t pass these standards. Perhaps they’re limited to what their CMS (Content Management System) can do. Maybe, they’ve tested using W3C and WAVE but have accepted a certain tolerance of accessibility errors. For the record, it’s not just W3C and WAVE that have been checked. Other links from W3C’s Complete List of Accessibility Tools have been checked against the sites I’ve previously tested and the same issues are found.
I asked my team – “Is W3C the be-all and end-all in accessibility and code validation”?
My colleagues provided a good response. As a local government organisation, when we want to procure a service, we have to be sure that the supplier we get is best fit and best value. We might decide to use these Accessibility tools as criteria to evaluate the tenders. In a market of extreme competition, you’d expect to see an eye for detail and that starts at making sure sites are as accessible as possible.
It’s important to have validated pages so you can be assured that your site works well on a wide number of browsers, shows that it’s machine readable (so it helps with Search Engine Optimisation), is a sign of professionalism and above all, helps people with accessibility problems.
Comments are welcome.
Tags: accessibility, markup validation, UCD, UX, web standards
August 1, 2012 at 6:38 pm |
I’m glad you acknowledged that sometimes the technology we use won’t cooperate. It is disappointing when you want your site to be compliant—accessible to people with disabilities— but a CMS plug-in can’t produce a compliant experience. I’ve seen that with a forms plug-in, which requires more work to be accessible. How do you prioritise the added work? Here’s a hypthetical example: Blind people cannot drive, so how pressing is it to make a parking-permit application form accessible to screen readers? If we choose to defer a task, is a deviation from the standard always serious? If you see wiggle room in the previous question, then what does it mean if a site fails an automated accessibility/compliance test?
One thing you didn’t mention is complexity, which can also introduce additional rounds of work. For example, you can review your site’s fonts, get everything working well in all browsers—or so you think—but then prerelease testing identifies problems that you missed, so you need another font review at the last minute. Or you release with some small fonts—a legibility issue—and some headings that are indistinguishable from body text on some mobile devices—a usability issue—and do another round of work, later.