Here a few notes for analysts and journalists that might chance upon this blog.

There’s a piece entitled 2.1bn HTML5 browsers on mobile devices by 2016 – ABI Research quoting some laudably specific figures:

By 2016, more than 2.1 billion mobile devices will have HTML5 browsers, up from just 109 million in 2010.

Before the expansion from “just” 109 million to “more than” 2.1 billion makes you rush out and leverage your portfolio, we need to know what our anonymous author means by the term “HTML5 browser”.

If you define an “HTML5 browser” as one that supports all features of HTML5 then there are precisely zero in existence. (You’d need to define “HTML5″, of course, but that’s another story.)

If you define an “HTML5 browser” as one that can consume some HTML5 features, then all browsers are “HTML5 compliant”.

Please, dear analyst/ journalist friend, define what you’re talking about before giving precise figures and talking about accelerating adoption. (I’m always up for being contacted – email bruce at this domain – if you need to check something out, by the way.)

Our anonymous author quotes a Mark Beccue saying “I believe that Apple will be the key driver of HTML5″. Mr Beccue is, of course, at liberty to believe what he wants. Until my nephew was three, he believed that there was a creature that lived in the toilet called The Poozilla (I’d like to apologise to him publicly here). Believing it doesn’t make it true.

There are many claims to be the “driver” of HTML5. Opera began it, of course; Ian Hickson edits the spec and works for Google so you could argue that Google is a driver. As you like, and whatever gets you a better headline.

The truth is that browser manufacturers are driving it collaboratively because if browsers don’t render HTML interoperably, developers will use some proprietary technology instead. (This doesn’t have to be a prosaic truth: the fact that all browsers are working together on HTM5, if not on other technology, is quite a story.)

Consumers benefit from interoperable webpages: most people use multiple devices and browsers; it’s stupid if you can use your bank website on your work machine, but not your Linux netbook or phone. There are significant advantages to HTML5 over HTML 4 for developers.

Mr Beccue (or the anonymous author channelling Mr Beccue, as we are denied any link to Mr Beccue’s full analysis) believes that Flash will imminently disappear:

One important HTML5 feature, video, is making a play to challenge the popular Adobe Flash Player plugin software…“I think the disappearance of Flash is closer than people think”

There are numerous reasons why Flash may be a more appropriate way to deliver your video content. Perhaps you need DRM, or adaptive bitrate streaming, for example.

Also, dear journalist/ analyst, it’s fair to point out that there are numerous problems with multimedia on Apple’s iOS:

• HTML5 video issues on the iPad and how to solve them
• Unsolved HTML5 video issues on iOS
• Audio Sprites (and fixes for iOS)

Mr Beccue (or the person quoting Mr Beccue) has presumably failed to realise that Flash does more than merely play video. This is an important point if you’re proclaiming its imminent demise.

If you want access to the paid-for report by Mr Beccue,
GigaOM has a similar article (which helpfully tells us “the HTML5 is very important”) that links to HTML5 for Mobile Devices and Tablets by ABI Consulting.

In the table of contents, we see conclusion #1: “Mobile Is the Primary Focus of HTML5″. A brief look at the HTML5 Design Principles shows that this is simply wrong:

Features should be designed for universal access…Features should, when possible, work across different platforms, devices, and media.

I enjoyed the Forbes journalist’s balanced appraisal of Flash and HTML5 in the piece Why Opposing HTML5 And Flash Is Nonsense, and agreed with his conclusions.

However, he gives a list of “facts” asserting “These are not interpretations or opinions. These are facts.”

As it’s just possible that another journalist or analyst might be impressed by Forbes’ vehemence and quote these “facts” without question, let’s give them some critical examination.

You do not build a web site in Flash. The only way to build a website is to use HTML pages, and then to embed Flash elements in them.

This supports the author’s thesis that talk of all-Flash websites is an impossibility. Well, yes, technically. But Flash can be embedded using two lines of HTML, neither of which has any visual manifestation (see Blankety-Blank example) so this doesn’t mean much.

Less than half of installed browsers are HTML5 compliant, with different levels of compliance.

As our wikipedia chums would say “Citation needed”. And, please dear Analyst, see above for the absolute necessity to define “HTML5 browser” or “HTML5-compliant”.

The video element in HTML5 is perfect for basic video players, but Flash and Silverlight are much more suitable for advanced video feature (streaming, caption, interactive features and miscellaneous video effects)

Really? I very much like the text-based synchronised subtitles available on things like Playr or mediaelement.js, which are HTML5.

Streaming is also completely possible with HTML5 video. “Miscelleaneous video effects” needs definition before you can claim that HTML5 can’t do them. (It’s been possible to do things like edge-detection, blend, greyscaling for a couple of years with SVG + native video – see http://www.dahlström.net/svg/filters/video/video-filter.svg in Opera, for example).

The iPony Club

Finally, Business Insider has a video in which “Facebook Investor” Roger McNamee exhibits the kind of breathless anticipation about “HTML5″ that is more commonly found in the minds of the prepubescent heroines of a specific genre of children’s fiction as they describe the prospect of riding Misty Mane, their new pony, for the first time. (From 8’58″ onwards.)

I address the paraphrases, as they’re what get quoted and picked up:

HTML5 is going to change everything. “In HTML5, an ad is an app, a tweet is an app, everything is an app.” “It’s a blank sheet of paper, and creativity rules again.”

I’m not sure how “a tweet is an app” makes any kind of technical sense. And, much as I like HTML5, this isn’t the Renaissance – we’re not seeing some massive resurgence of human creativity because of a new DOCTYPE.

In HTML5, you don’t need to have display ads: Amazon can have a section of its store as an ad. So if you’re reading a book review, you can buy the book right from the page.

As you’ve been able to do for 10 years.

Because HTML5 can make sites rich and interactive, engagement on a site can go from seconds to minutes.

Flash can make sites rich and interactive. So can HTML 4. The key here is “rich and interactive”, not a particular DOCTYPE.

The iPad is the training wheels for HTML5.

Seriously, have a lie down.

(Added January 2012: the offending video by McNamee:)

What a load of nonsense!

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.

One day, I am going to get rich by doing post-implementation reports on public sector websites (if such a thing as “public sector” remains, of course).

From my experience at the Law Society, and reading reports such as this one, I could easily produce a template document citing the usual reasons for the deadline-breaking, budget-demolishing usability atrocities that get commissioned, and then I’d just slot in the client organisation’s name and charge them a few grand.

I would use the Birmingham report as a basis, as I’ve already paid for it with my council tax and it lists (or hints at) all the depressingly usual suspects:

• Scope creep
• CMSs are bought off-the-shelf, massively customised to the point that they’re unstable and no-one knows how they work any more
• organisational disdain for their own employees’ accumulated vital knowledge and experience
• obsessive organisational risk-aversion
• managers with no understanding of how the web works being put in charge of projects
• PRINCE2
• endemic mis-communication

Joking aside, I’m not qualified to judge how accurate this report is, but it rings true, except for one vital area.

The report’s authors offer advice on enhancing the accessibility of the site. The advice is wrong.

I can’t find the names of the authors to judge their qualifications to pontificate on accessibility but the inaccuracy of terminology of the assertion “W3C rules state that an ‘alt tag’ should be used on all images” makes me uncertain that they really know what they’re talking about (there is no “alt tag” as there is no alt element in HTML).

Section 13.3.2 says

…a visually-challenged visitor should be able to increase the font-size and to change text and background colours to make the site legible for him or her. It is possible for an individual to change the font size using their browser settings but it is not possible on the BCC site to do this on the web pages themselves.

I challenge the assertion that you need text resize widgets on the page. It wastes space, only works per page (unless you set cookies), and requires JavaScript. At the very least, this should be usability tested with representatives of those who would allegedly benefit.

Section 13.3.3 says

… Browsealoud (http://www.browsealoud.com/ ) is recommended by many bodies including the RNIB. Many visually-impaired people use the system and it is enabled on many government and local government websites – including a subsidiary standalone site of the BCC (www.adultcareinbrum.org.uk – see below).

Systems like these allow a visitor to listen to the content of a site, thereby making it accessible to those with visual, literacy, and dyslexia challenges.

We recommend that Browsealoud or another similar system be implemented on the main BCC site.

Browsealoud costs money. It’s basically a plugin that reads text, but has none of the navigational functionality that fully-fledged screenreaders have. The site owner pays to have their web site added to a whitelist contained within the plugin.

Extensions such as Opera’s Voice (select text, right click, “speak”), Firevox for Firefox, built-in screenreaders on the operating system such as Micrsoft Narrator or Apple Voiceover perform this job without requiring the council to spend money, and (most importantly) at greater utility for the consumer. Browsealoud (or similar plugin) requires that the user learn a new way of interacting with this specific website; using the alternatives I list above enhance the user’s experience on every site she visits.

It appears that during development of the site, Birmingham City Council procured four third-party accessibility audits of the website, all of which mention non-resizeable text (but recommend setting it in CSS with relative units rather than coding text resize widgets). None recommends browsealoud or similar plugins.

I hope that Birmingham does not follow the two accessibility recommendations of the post-implementation report, until it can demonstrate that the authors of that report have significantly greater experience and knowledge of accessibility than the authors of the 4 accessibility audits I obtained under my Freedom of Information request.

This is a personal post and not the opinions of my employer, wife, children or hamster.

Birmimgham also features in another of my Usability Atrocities with its legendary Strategy to develop Short Breaks for Disabled Children.

The day’s events went very well indeed; our presentations gelled well together, and good questions were asked.

Here are my take-homes about the state of the UK’s public sector accessibility, synthesized from questions and coffee-break conversations.

• Accessibility is often seen as a problem of technical compliance rather than a human rights issue. Therefore, content producers see it as some techie’s problem rather than their problem. But they’re not called the Web Content Accessibility Guidelines for fun…

• Further compounding the box-ticking attitude of senior management is the artificial competitive attitude brought on by predatory companies’ so-called “league tables”, which are assessed by robots.

• The distressingly-rampant leprous elephant in the corner of the room is PDF. The public sector likes PDF, as it allows a document to be “put on the web” easily. These documents need to go “on the web” because of the need for transparency and freedom of information. It is possible to make accessible PDF, but it’s very very hard.

• There are a lot of unscrupulous companies who prowl the public sector selling the snake-oil of “triple-A compliance”. Anyone claiming “triple-A compliance” is lying and should be completely ignored, and preferably thrown out of the building before being reported to Trading Standards Officers.

• The people at the coal-face genuinely care about accessibility, but there’s so much bullshit and ballyhoo from vendors and snake-oil salesmen that people are confused. Or deliberately hoodwinked. Hopefully, we were able to cut through some of the smoke and mirrors.

If you attended the event, or work in the public sector, does that seem an accurate summary?

Thanks to the PSF chaps and Dan Champion for a delicious meal and well-organised conference (Photos).

Our unhappiness is due to their wasting public money on a site that does not meet the level of accessibility required in their own spec, and the fact that the DTI have said that “if further changes are to be made to the website the cost will be met by DTI”, so presumably, Fresh01 (the suppliers) will not be required to put their mistakes right at their own expense (if indeed, the DTI’s answers show that it’s the supplier’s fault).

We want to know why this shoddy procurement, development and supplier monitoring happened, and what will be done to prevent it reoccurring. Therefore, we’ve sent further questions to the DTI as a request under the Freedom of Information Act.

The questions

1. Did the DTI take legal advice on what level of WCAG conformance constituted compliance with the DDA? If yes, please provide a copy of the advice received.
2. If no legal advice was taken, what was the rationale behind specifiying WCAG level AA conformance in the original specification?
3. Please provide a full copy of the document referred to in the response to my previous enquiry – ‘Invitation to Tender for rebuild of the website, brief for customer research, design & information architecture, and usability testing phases’.
4. Tendering: was the decision to award the contracts made on price alone? Please provide copies of all DTI reports/investigations during the tendering phase of all shortlisted suppliers’ ability to deliver an accessible website conforming to WCAG level AA. Please list the qualifications and experience of commissioning accessible websites of those who picked the successful suppliers.
5. What provisions existed in the contract for a contractor failing to adequately satisfy the deliverables specified in the requirements document?
6. How did the DTI monitor deliverables against the specified requirement of WCAG level AA, and the validity of the code? How regularly were these checked during the project? What processes were followed by the DTI to assess the completed website against the deliverables in the requirements document?
7. At which point in the project did the DTI drop the requirement for AA conformance? Please provide documentation on why this decision was taken, and whether legal advice was taken.
8. The Usability Company (now Foviance) claim to have been employed as the accessibility and usability agency for the redevelopment of the DTI website (www.theusabilitycompany.com/news/newsletter/dti.html [Link co-incidentally broken; Google cache]). What was this company’s precise role in the project, what was the value of the work they carried out, was this included in the costs of £175,000 quoted in the response to my original enquiry, and why was the company not mentioned in the response to my original enquiry?
9. Are Fresh01, Fujitsu, The Usability Company (Foviance) or Percussion still on any list of the DTI’s preferrred suppliers?
10. Has the DTI amended its processes for procuring web design work since Fresh01 were commissioned? Is there an organisational requirement to use PAS78 as the basis for any future commissioning work?
11. What action is being taken to address the deficiencies of the new DTI website? Who will bear the financial burden of this remedial work, and what is the estimated value of the work?

When the reponse comes in, we’ll publish it here, along with any reply from Fresh01, who are cordially invited to respond.