How we could all benefit from Betagov's accessibility work

Accessibility is the subject of the latest post on the Government Digital Service blog: having had their fingers burned in the ‘alphagov’ phase of work, by consciously ignoring the subject, it’s clear they want to be seen to make it a priority into the beta phase.
Léonie Watson writes:

Tom Loosemore has said: “… we want to make the most easy to use, accessible government website there has ever been”. Those of you who know something about web development on this scale will understand what a challenge that is. Those of you who know me will also recognise it’s a goal I thoroughly believe in. So, what are we doing to achieve that goal? Simply put, we’re planning accessibility in from the outset and documenting the accessibility steps we take throughout the website’s lifetime.

I’ve posted a comment on her article, which I’ll reproduce here for the record. You’ll instantly note a common theme with my recent inflammatory post about departmental publishing.

As you’ve noted, accessibility is very hard to get right: you’re conceding that you might not even score a ‘perfect 10’, even though you’re ‘planning [it] in from the outset’. And as [previous commenter] Keith says, for small organisations, it’s prohibitively expensive to even buy the rulebook, before you even begin to implement the rules.
If government is hiring experts, consulting widely with users, and (hopefully) delivering exemplary results, it seems like a tragic waste for the benefits to be locked into a single website.
Wouldn’t it be fantastic if one of the outputs from your work were to be a reusable, customisable front-end theme for an open-source, widely-used publishing platform, like WordPress or Drupal? You could enforce certain ‘must have’ accessibility practices in the page templates, whilst still giving people plenty of scope to make it look and feel like their own site – via a parent/child theme arrangement, or a ‘theme options’ screen.
You could then release that theme publicly – giving web developers everywhere a robust base on which to build their sites. Imagine all those common accessibility headaches being solved, before the first line of custom code is written.
(I’m not suggesting this would solve all problems instantly, of course. And there’s still plenty of scope to cause all sorts of new problems in, say, a child theme’s CSS. But you’d certainly be giving people one heck of a head start.)
The fact is, very few organisations have any real motivation to get accessibility right. But Government has a moral obligation to do so. And you’re spending our taxes to do it… so I’d argue we all have a right to enjoy the fruits of that labour. Central and local government, public and private sector.
Issuing a list of rules seems a very old-fashioned way to encourage / enforce good practice. You have an opportunity here, to do something much smarter than that.


BBC News site: too wide, too tabular

I’ve given it a fair crack over an extended period, but I’ve reached my conclusion: I just don’t like the redesigned BBC News site. In ‘standard’ conditions, a desktop PC running at 1024×768, it’s clearly an improvement: brighter, more airy, less cramped. But away from the norm, they’ve broken the golden rule of any revamp: don’t make anything worse.
As any website’s usage data will show, most people are now running a 1024×768 screen resolution. And monitors are just getting bigger, right? Wrong. I have four ‘web devices’ I use on a regular basis, and the two I bought most recently – an Asus Eee (classic edition) and a Nintendo Wii, both of which have sold like hot cakes – don’t operate at the larger resolution. So when I look at the majority of pages on the BBC News site, I have to deal with arguably the Number 1 no-no in web usability: horizontal scrolling.
(Curiously though, I see the second-level / subject homepages – eg UK or Politics – the page body remains sized for 800-sized screens?)
What’s infuriating is that (a) for all the BBC’s army of supposed design and usability managers, consultants and experts, nobody considered these widely-used devices worthy of appropriate support; and (b) it doesn’t have to be like that. CSS-based coding using DIVs could allow the site to work ‘well enough’ at 800-width, whilst looking its best at 1024. Instead, the site continues to use TABLE markup for layout, in clear breach of W3C advice dated 1999(!):

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

When I do a coding job, most of my time is spent working with DIVs and CSS, trying to make designs work acceptably across all browsers and all common setups. It’s not fun. TABLEs would be much easier, much quicker and much cheaper for clients. But coding with DIVs is unquestionably the right thing to do.
The BBC isn’t alone here: the major UK news sites are all – without exception, as far as I can see – forcing screen widths beyond 800 pixels. The Telegraph also uses a TABLE approach; whereas the Guardian and Times don’t. But we expect higher standards from the BBC. And that’s what annoys me most. Like a lot of people, I used to advise that whatever the BBC was doing, we all should be doing too. I don’t feel I can say that now.
Am I just being too idealistic here? And where does it leave government’s commitment to dated accessibility rules: what’s the point, when sites with receiving many times more traffic – the sites which define the typical UK user’s internet experience – are imposing a contradictory de facto standard? I’d be more than happy to go back to TABLE coding.