Notes on Birmingham Council website post mortem

The city I live in, Birmingham, launched a new Council website. It made the headlines because it was three years late, and considerably over-budget. I’ve been reading their post-implementation report Web CMS Project Post Implementation Review – Final Report (PDF, 440K) (check out the humane URL of that document: thank goodness for the new Fatwire CMS!)

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:

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 ( ) 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 ( – 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.

10 Responses to “ Notes on Birmingham Council website post mortem ”

Comment by Anthony Williams

I’ll echo your comments on BrowseAloud – their representatives continually try to get us to use it on our website, but it’s very, very expensive.

Whenever I ask them to explain what benefits they offer over and above existing screenreader software, the sales representatives didn’t offer anything of value.

Comment by Matt Machell

I remember being appalled by this the first time I saw it, what I like most about that report is the wonderfully understated: “We understand that the website has not had the benefit of a specialist web designer”.

I also noticed that they recommend “Implement font-size and colour options”, which again smacks of people looking for magic bullets rather than trying to understand the issues. A viewpoint borne out by the use of a SiteMorse report (remember them?) to show how the site has improved.

Comment by Bruce

Stuart, plenty of whitespace. And that’s proper man’s code too:

<div style="padding-top: 10px; padding-left: 30px; padding-right: 30px; padding-bottom: 10px; background-color: #ffffff" class="highslide-html">
<div class="highslide-body"></div>
<div style="text-align: center;"></div>


Comment by simon gray

I don’t disagree with your conclusions, but I think you’re not quite right on a few points.

Firstly, I like every other web professional cringes at the term ‘alt tag’, but I really do think we’ve lost the battle on that one, & to bring people up every time they use it just smacks of churlishness – instead consider the term to have become part of the normal English language instead, like ‘log on’ as a synonym for ‘visit’ – & at the end of the day, even for web professionals it sometimes is just easier to say ‘alt tag’ than to say ‘the alt attribute of the img html element’.

Secondly, with the statement

text resize widgets on the page. It wastes space, only works per page (unless you set cookies), and requires JavaScript.

I believe you to be at variance with the actualité; it’s perfectly possible to create text resize widgets which don’t require ECMAScript – admittedly to do so would require cookies (be it session or persistent), but that pre-supposes using cookies is a bad thing. It isn’t, and never has been.

The topic of text resize widgets themselves is, of course, a whole religious war of itself – personally I’ve never seen what’s so wrong of providing the choice to the user of coding the site in such a way that the savvy user can use the ctrl+ & – keys to change the text size, or so that the user with my mother’s level of capability can just click the button on the screen. No kittens are harmed by offering both possibilities.

Comment by Bruce


“Firstly, I like every other web professional cringes at the term ‘alt tag’ … consider the term to have become part of the normal English language instead”

Which is why, if Mr Site Owner mentions that, it’s fine. But this report gives recommendations that web professionals must act on, and which contradicts 4 reports by other web professionals, so its incorrect jargon makes the quality of the advice suspect.

I prefer “alt text” myself.

R/e scriptless text resize widgets: are you suggesting that they be links that go to the server with a query string like /size=bigger and then the server drag in as different style sheet and send that?

Presumably that’s possible, but why do it? And where do you stop? A widget to select font colour, another widget to choose serif/ sans-serif/ comic sans are all possible, and all “give the user choice”, but why cover the page with site-specific widgets when the functionality is available for free in every browser and operating system.

Comment by simon gray

Yep, ‘alt text’ is my preferred construction, too.

Passing a variable through the querystring would be the way I’ve done personalised display before. You ask why – my answer is ‘because it will almost certainly be easier for the user to do that than to set to and write their own stylesheet to import into their browser’ – it’s a big enough ask to get my mother to cotton on to using ctrl+ to resize text herself, never mind learn css (or learn how to import somebody else’s css). Don’t forget, the majority of web users type URIs into the Google (or Orange, or BT) search box on their browser home page rather than into the address bar itself – that’s the level of capability we have to remember. And if a site designer was to implement the level of choice you’re suggesting as an extreme, then I’d suggest having a separate personalisation page rather than having a row of widgets on the top.

I’m not saying site designers should provide personalisation options – all I’m saying is, where the site has been properly constructed to allow people to do their own personalisation the ‘proper’ way, there’s nothing wrong with additionally providing those options on the page itself.