Public Sector Browser Standards
The COI have published a new consultation document — Public consultation on browser standards for public sector websites. (Spotted via Bruce).
Now before reading what the document has to say, I’ve read Bruce’s opinion on it.
the central premise of the draft guidelines is fundamentally flawed.Bruce Lawson: UK government draft browser guidance is daft browser guidance
The reason Bruce is complaining is because the consultation document seems to suggest that minority browsers do not need to be as well supported; and that the COI is advocating people upgrade their browsers.
Not having read the document yet (I’ll get to that in a moment); Bruce says that the document works against minority browsers, because if you use a ’semi-supported’ minority browser, you will be encouraged to upgrade to a better supported browser … in other words, one with a bigger market share.
So that’s what Bruce had to say. Now on to the guidelines themselves…
Your browser standard must be based on the most popular browsers accessing your website.COI Browser Standards - DRAFT
This sounds sensible, but is not necessarily so. It then tells you to go and get the browser usage from your server log files. However, my experience in Local Government tells me that the biggest viewers of local government websites are … local government employees.
Therefore any corporate ’standard’ for internal browser use (anyone still using IE6, for example?) will lead to a massive boost to the statistics for that browser. While it is sensible to look at what browsers are being used to access your site, you need to discount your own employees — after all, you need to be responsible to the public, not yourselves.
The list [of tested browsers] should be part of your ‘Help’ or ‘Accessibility’ section and directly linked from the home page.COI Browser Standards - DRAFT
Ah. While I recognise that it might be useful to know what browsers/versions a site has been tested on, this should not be part of the accessibility statement. Back in 2006 (?) Rosie Sherry wrote something called Showing web accessibility statements the door because they were usually full of nonsense which was of no benefit to disabled users — stuff like which level of WCAG a site claims to adhere to, how the site has been tested, which browsers it has been tested with — you know, all the standard self-congratulatory stuff which is of no benefit to users with disabilities.
We’ve already argued this through once: let’s not clutter up the accessibility pages themselves with this sort of nonsense again, okay? (I don’t mind it being linked from the accessibility pages though, if you must)
Public sector websites have a responsibility to be inclusive and not to exclude groups of users. This means that your browser standard should be to be as inclusive as possible. However, this needs to be balanced against increased testing times and costs.COI Browser Standards - DRAFT
This is perfectly sensible and reflects the reality of public sector web development. Nice to see they’ve got that one nailed. However, now we’re getting near the tricky bit Bruce didn’t like…
There may be specific browsers that you choose not to fully support because they are either old or unpopular.COI Browser Standards - DRAFT
It then talks about the percentage market share a browser should have before you consider supporting it. It does get slightly misleading, however saying things like
The two most popular browsers on each supported operating system must be supportedCOI Browser Standards - DRAFT
The two most popular browsers? Or browser versions? If internet explorer is the most popular version on Windows, does that mean I can just support IE7? Or must I support the most popular browser versions? In which case I might be perfectly okay to support only Internet Explorer for windows?
Surely this can’t be right?
The most popular browser available on Mac should be supportedCOI Browser Standards - DRAFT
Eh? The most popular browser on the Mac? That’s funny, I could have sworn you’d just said…
The two most popular browsers on each supported operating system must be supportedCOI Browser Standards - DRAFT
So which is it to be?
Now I suspect from what they are saying (and from the ‘worked example’ in the appendix) that what they mean is any major browser version (IE6, IE7, FF2, FF3 etc) with over a 2% market share needs to be tested, and even if it doesn’t have a 2% market share, you still need to support the most popular two versions for each operating system.
Unless obviously it’s a Mac, in which case you just support one. No, wait, I’m confused again…
And then we have the ‘web standards’ issue:
These guidelines do not advocate specific development methodologies, for example graceful degradation or progressive enhancement. However, it is widely accepted that sites conforming to open web standards such as XHTML and CSS are more likely to work well across a wide range of browsers.COI Browser Standards - DRAFT
If it is widely accepted that conforming to open web standards means your site it more likely to work well across a wide range of browsers — and it is — then why on earth don’t these guidelines advocate it? It’s like saying “this is industry best practice, but you don’t have to do it; however we do want you to listen to our specific methods for determining which browsers have certain market shares”.
For goodness sake, why? Sites that conform to standards will work well in all major browsers — except maybe IE6, but the sooner that’s not a ‘major’ browser any more the better. If you conform to web standards, testing will be easier, and it will be less likely that you’ll need to make any significant changes as a result of it.
Web-standards based development would also mean that a lot of smaller, standards-friendly browsers (such as Opera) will be supported almost by default.
So failing to advocate standards-based development in this case is nothing short of madness.
- A browser is supported if the content, functionality and display all work as intended.
- A browser is semi-supported if the content and navigation works but the website does not display as intended.
COI Browser Standards - DRAFT
Um… what happened to functionality? If the content and navigation work but the basic function of the site doesn’t (for example, if you are unable to calculate housing benefit), then the site isn’t semi-supported. It’s useless. You need the word ‘functionality’ clearly included as a requirement for semi-supported, too…
The document then suggests that various things like ‘form-filling’ are required to test functionality. You need more than this. You need to ensure that when you fill in a form, the data is submitted properly and to the correct location. This was one of the major problems of the SOCITM report — sites were considered to be transactional if they had a form — nobody cared what happened once you’d pressed that submit button.
Testing must go beyond that submit button…
I’m not wishing to say that these guidelines are rubbish, that they are poor, or anything of that sort. They have faults, but that surely is the point of a consultation exercise; expecting a consultation document to be perfect is like expecting the alphas or betas of a browser to be without flaw — it’s unrealistic, and it’s not what they are supposed to be.
The guidelines do have flaws, but like I say, they’ve got the reality of public sector web development and testing pretty much nailed, so that’s a good starting point. If they listen to the feedback they get, and act on it, I’m sure they could end up with a decent standard; but they do need to pick up the current issues.
Hello. I am 
Probably not appropriate for me to comment directly on this - as I work for COI, but this isn’t directly my area - other than to say thanks for you input. I’ve forwarded this to my colleague, who is responsible for this (although I assume you will have sent feedback direct too?).
Another COI colleague has blogged about ‘not talking about it’ too, just in case you’re interested
[...] But on the positive side, the consultation certainly got a lot more coverage and interest than we can usually hope for. After the initial storm, we started getting a lot of varied, interesting and very thoughtful responses from people who, by now, had had enough time to have read the actual consultation paper, for example at Puffbox.com and The Pickards. [...]
Jack what I get from this document is that COI are using Google analytics to help them set their browser standards. What happens if your stats package isn’t as comprehensive and doesn’t give this info? Are COI saying you need to improve your stats package or supporting the use of Google analytics? That’s fine if they are, I just wish they’d say it!
I’m not comfortable with the references to testing sites with screen readers and voice recognition software. Why single these users out? What about people with motor impairments, are they saying ensure tab order is correct? Of course not because that’s a priority 3 checkpoint yet a pretty important one if the tab order is totally illogical. I think COI would be better with a catch all statement here saying the site should be tested with WCAG 1.0 AA compliance in mind, referring to Delivering Inclusive Websites,. However, not wishing to go over old ground, anyone looking for more info on this subject will probably spot the weaknesses of this document immediately.