Snakeoil, local government, accessibility and HTML5

As we’ve seen from the £585 icon fiasco, in which Reading Room charged the Information Commissioner’s Office a large sum for a 32-by-32 pixel favicon, the public sector is a credulous and top-heavy environment in which to develop websites. (Disclosure: I once had to maintain some code by that agency.)

In the public sector, many websites sit in parts of the organisation that are managed by people who don’t really understand the Web. They may be Marcomms folks, used to traditional media, or IT Directors who are comfortable with Service Level Agreements, purchasing Enterprise-level software. But both breeds of manager are fair game to be frightened witless by the requirements to have accessible web sites.

There is a website monitoring and compliance tool that’s very popular with local government and public sector managers, as it does a battery of automated tests, marks websites as passing or failing. (See Gez Lemon’s old-but-gold Testing Invalid Content with Accessibility Validators to see why this might be more of a box-ticking exercise than a useful approach.)

The monitoring tool is less popular with the web people who actually do the work as the compliance reports and league tables that the vendor produces often require coding for the tool rather than for accessibility or best practices.

A correspondent writes that the tool didn’t properly score her HTML5 pages and had the following email exchange with the tool vendor.

Nice lady:

The issue seems to be because we are using the HTML5 doctype on our site. All of the checks being performed seem to be trying to validate us as HTML4 – which is wrong.

Snakeoil salesman:

HTML 5, as a ratified standard, does not yet exist so there is only the initial draft proposal to work to, so as yet we have not started work on testing HTML 5. (See answer below about timings on using HTML 5.)

Nice lady:

The HTML5 syntax is much more relaxed and allows for a combination of HTML4 and XHTML standards. So errors being produced for things such as wrongly using self-closing tags are false.

Snakeoil salesman:

We do not believe this to be correct, even for HTML 5.

Nice lady:

HTML5 is new – but the doctype is fully supported and recognised by all browsers.

Snakeoil salesman:

This is incorrect. HTML 5 does not yet have a “doctype” (as a method of signifying the document type). No browsers at all implement the HTML 5 document parsing method as far as we are aware.

Nice lady:

Developers are being encouraged to use HTML5 as the best way to ensure your pages will last a ‘long, long time’.

Snakeoil salesman:

We are not aware of anyone that is encouraging people to use it, but if it is true that someone is then they are misguided and mistaken.

Here are advisories from the head of the W3C team working the HTML 5 spec from early October 2010.
W3C: Hold off on deploying HTML5 in websites &helip;

And in terms of ensuring pages last a long time HTML 5 parsers are backwards compatible with HTML 4 in any event, so documents written today in HTML 4 will last at least as long as HTML 5 documents, with the added advantage that they are actually supported by existing browsers.

For these reasons we do not currently support HTML 5 and have no plans to do so in the immediate future.

So if you would like to use any of the new HTML5 elements, canvas or multimedia or ARIA to aid accessibility, just make sure that your boss doesn’t pay money for Snakeoil Monthly report.

10 Responses to “ Snakeoil, local government, accessibility and HTML5 ”

Comment by Jamie

Hiya Bruce,

Ah, the joys of the public sector… i did some work for one recently who demanded that the website be web 2.0 compliant and a have the correct certificate to prove it. *sigh*

I think part of the issue is generally the sorts of companies working with the public sector, if the local organisations that i know are anything to go buy they are only interested in accessibility as a checkbox and even then they are happy to ignore it the moment they feel no one is looking. Or of course, it does not even feature to begin with.

Of course, this ‘expertise’ is very expensive too

Grrr,

Jamie + Lion

Comment by Gareth

I think it’s about getting the individuals with the knowledge further up the chain to be included with the sales and pitches and not just sit behind a computer building things all day long, that stops the client being promised the world and allows them to have an insight into the workings of areas such as accessibility and standards.

It’s a shame that when it comes to large corporate site builds, time is money and quality is pushed aside to meet tight deadlines.

Comment by John Foliot

Heya Bruce,

The following are true statements:

1) “HTML 5, as a ratified standard, does not yet exist” – it is instead a fluid, ever-changing living specification which can change between Thursday and next Monday: a page that is conformant on Thursday may be non-conformant on Monday. (When you are managing sites that have 1,000s of pages, this is a non-trivial issue to oversee)

2) “No browsers at all implement the HTML 5 document parsing method as far as we are aware.” – at this writing I believe only beta builds of FireFox 4 use an actual HTML5 parser (http://www.mozilla.com/en-US/firefox/beta/features/) [I guess we should split this down the middle, as 1 beta browser now implements HTML5 parsing]

While it does appear that your Salesman is slightly off in his responses, those responses are rooted in a basic truth – no enterprise quality conformance monitoring solution exists today. It is but another indication and reason why a solid immutable standard is important: it allows third parties to also build tools to an established benchmark, with the assurance that what they are testing for (in terms of validity or conformance) can continue to do so for a measurable future: HTML5 affects more than just browsers.

These compliance tools can be simple spider and report tools, or part of larger interoperability systems that do integrated accessibility, security and code validation monitoring (See: http://www-01.ibm.com/software/rational/offerings/websecurity/webcompliance.html or http://hisoftware.com/ as but 2 examples), and while they may be uncommon tools in the toolbox of most readers of your blog, they are valuable and important tools none-the-less for large companies and other organizations that are managing distributed teams of web authors across the enterprise.

Comment by Bruce

Yup, agreed that (1) is a problem here.

(2) is true, but the snakeoil salesman is confusing DOCTYPE with parsing algorithm – presumably believing that the former triggers the latter.

“No enterprise quality conformance monitoring solution exists today” – that’s also true, but has always been true for HTML 4.01. You can’t do automated accessibility testing. You can test some things, but not all.

Comment by John Foliot

True dat for accessibility, but I didn’t say accessibility exclusively – the tools I mentioned do code compliance, check for broken links, monitor potential security issues and can even check for marketing and internal policy compliance. They can use algorithms similar to the W3C code validator, but allow for bulk evaluations across the enterprise, including content behind corporate firewalls. Very few Fortune 500 companies are going to insert static URLs (one at a time) into that resource, it simply doesn’t scale. The tools I mentioned can do that for HTML 4.01 and XHTML 1.1 today.

Comment by Bruce

But checking for broken links, monitoring potential security issues and checking for marketing and internal policy compliance doesn’t require any HTML5 spec to check against.

Comment by John Foliot

Here, let me get that for you, you missed a nit to pick….

My friend, the point is, these large enterprise tools are a one-stop evaluation tools that do multiple checking for various things, and along with all the other bits and bobs, one of them is that they check for code compliance. Developers of these multi-purpose enterprise tools need to have solid, intractable standards to develop against, so that the new software build can be created and then shipped (and or patched and pushed to existing current clients). This cannot happen every time the ‘living spec’ has a hiccup and changes the current rule-set – there is no sustainable business model in that (heck even the browsers cannot ship the new features in sync, so authors are left with using shims, polyfills and all other manner of *HACKS* to overcome these shortcomings today).

Browser developers might have a vested interest in the Möbius loop race that is “the best browser this week” but for mere mortals there needs to be a beginning and an end, else we too are forever chasing a finish line that does not exist. This reality is borne out by the ‘excuses’ your poor salesman is offering to his client, no matter how poorly worded they were.

Comment by Benvie

It’s funny then how poorly built the websites for nearly all large enterprises are, especially those in the public sector.

Comment by Martin

I think I can guess exactly which company you are talking about. We dropped them like a rock a few years ago, not because of this, but because getting a high score made management assume that accessibility was ‘done’.