Steve Fenton

<< May | June | July >>

Wednesday, 8th June 2011

An update on the Web Accessibility Shocker I reported on Saturday. First things first, I'm not going to name and shame (although I am tempted). I've had a good think about this and I'm concerned that naming the organisation wouldn't just damage their reputation, but could also damage the efforts of other people who are trying to make the web inclusive of everyone. So with that particular aspect cleared up, let's talk about the accessibility checker that should shudder at validating itself.

I actually contacted the organisation in question and while it is difficult to share a lot of their response without giving away who they are, suffice to say they didn't take my feedback very seriously. This is the response (minus incriminating names and web addresses).

As noted, this is a technology preview and we have not polished accessibility yet. However, I don't think there are any form elements in the interface that are not labeled (sic).

I'm also curious about your comment regarding "poor mark-up" - what do you mean? And how does this impact accessibility?

Regarding JavaScript, the functionality provided by this tool is only available via JavaScript. We outline some of the reasoning for this decision at [...].

Ground Up

I accept that this is a technology preview and things might not be polished, but there is a popular phrase among technology companies about "chewing your own dog food". Can you imagine the W3C releasing an HTML validator that contained invalid HTML? Of course not, they would run the validator HTML through the validator to check it.

On top of that, isn't it easier to write a page properly in the first place, rather than bodge together some nasty HTML and CSS with a view to re-visiting it at some later date? It doesn't take any longer to write correct HTML, so why broadcast a message that suggests that it takes longer to write good web pages or that a page of this low calibre simply needs a polish (we all know the appropriate simile to use here).

Form Labels

Erm. "I don't think there are any form elements in the interface that are not labelled". There isn't actually a single <label> element on the form. I actually hope that there has been a mis-understanding along the lines here, because they must know what a label is. The form elements each have a description, but it is not enclosed within a label tag that marries it up to it's partner element.

If you don't know what these label elements are or how they help with accessibility, read the W3C HTML Techniques For Web Content Accessibility.

Poor Mark-Up

Or indeed, "poor mark-up" in inverted comma's as if this is a matter of opinion. There is a detailed analysis in the previous article on this, but I will summarise...

Div-itis. Literally meaning "inflammation of the divisions". Each selection box chunk on the page consists of no less than seven divisions. On top of this, all seven have a class - this is class-itis (you don't need classes everywhere when you can traverse the document structure in CSS and in JavaScript!).

There is also the mis-use of the definitions-list element, which in particular adds incorrect semantics to the page, which does actually affect accessibility - typically being read out by screen readers as (disclaimer, no two screen readers are the same!)

Definition list of "n" items. [dt element] equals [dd element]

And as we remember, there actually aren't any dt elements in the definition list.

Mark-up matters, not just for accessibility but also for credibility.

CSS

Remember that despite having some CSS files, there were still tons of in-line styles? Why is that a problem for accessibility I hear you cry... Here's the answer. If you need a high-contrast display, or larger text, or a specific colour pallet, browsers give you the ability to override the style-sheet on any web page with your own style-sheet. This essentially replaces the theme of the web page with a style that makes it easier for the user to read and interact with the page.

The problem is, in-line styles disturb this harmonious facility. Accessibility fail.

JavaScript

Heaven knows I am one of the keenest JavaScript developers south of Ecmaland, but the method I use to develop JavaScript applications is to make things work in plain HTML and then enhance the flip out of them with the JavaScript. Why do it this way? Because the Internet is supposed to be inclusive. That means everyone with a web browser should be able to use your web page, application or funky little widget.

There is an accessibility angle on this, because some screen readers specifically state that they don't support JavaScript and there are subtle issues that can be caused when you update portions of a page that is being accessed by a screen-reader (some screen-readers ignore the updated content, some screen-readers interrupt the user with the update). It also isn't just about accessibility because although there are only between 1% and 2% of users with JavaScript disabled in most territories (USA 2.06%, UK 1.29% - source Yahoo October 2010) - this actually means that 388,000 of the UKs 30.1 million people with Internet access haven't got JavaScript for whatever reason (be it preference, policy, tool-set or device). Let's re-cap. It's 388,000 people - you would have to book Wembley stadium 5 times in order to preach to all those people that they should enable JavaScript. Let's not even think about what 2.06% of the USA Internet population might be (okay then - lets! It's 5,484,224 according to Internet World Stats from their June 2010 stats - they got their Internet access stats from Neilsen Online).

And anyway. It really isn't difficult to make stuff work without JavaScript. We have progressive enhancement (which is my preference) and we have graceful deprecation (not a bad option either). Read about both progressive enhancement and graceful deprecation at Opera.

And in reference to the link I omitted here:

We outline some of the reasoning for this decision at [...]

I would just like to note the following... The article in question asks for feedback on whether anyone has any good reasons on how JavaScript can make a page less accessible. There are comments aplenty supporting the fact that your page is not automatically inaccessible just because it has JavaScript (we know this to be true, because we can use the techniques we discussed just now) - and also comments reminding everyone about how a page is actually not accessible if it only works when JavaScript is enabled. There were also a few cheeky references to the websites own articles and reports - reports that contained criminal 3D pie charts.

And is there anything in their checker that seriously couldn't work without JavaScript? Well, you would lose the website overlay of the report's findings, which is actually not a particularly useful feature of the checker anyhow (when I tried out the tool, I spent most of my time in the side bar, looking at the list of findings - the site overlay is cool, but not essential).

Summary

Bearing in mind I followed a link on the "technology preview" that asked for feedback and bearing in mind that I gave some good honest feedback, I'm a bit disappointed that the response was of such poor quality.

The one glimmer of hope is that the preview has gone missing for the moment, which makes me hope these issues will actually be addressed.

And finally, if you are actually asking for feedback, consider the following a reasonably useful template for responding to people who take the time to send it.

Dear Steve,

Thank you so much for taking time out of your busy schedule to send us feedback about our accessibility checker. Without feedback such as yours we might put the tool live with all these problems still to be fixed and we would look totally stupid, so you've saved us from ourselves.

It will actually take us very little time to tidy up the form on the home page of the checker - we think we will use standard HTML controls and maybe some HTML5 and CSS3 with the relevant poly-fills because we know that this will make the World a better place. It might take us a little longer to sort out the other page, because it has lots more funky stuff going on - but we want to make this a shining example of accessibility on the Internet so we will make it happen. We also acknowledge the nearly 6 million people in the UK and USA who might want to use our checker and who (for whatever reason) don't have JavaScript enabled.

We especially appreciate your time and effort because we know your Wife has already gone to bed and that you would love to be asleep right now, but because you felt so strongly about the values that we endeavour to protect, you are sat typing up this article at almost midnight instead of being tucked up all warm and cosy.

Thank you once again and all the best,

Fred Cain & Dave Jive (Made-up names)