UK government draft browser guidance is daft browser guidance

By Bruce Lawson | September 8th, 2008 | Filed in Accessibility, Action, Browsers, General, Web Standards (general)

This blog post is superseded by UK government browser guidelines: good sense prevails.

Last friday, the UK government’s Central Office of Information (COI) published a public consultation on browser standards for public sector websites:

This guidance has been developed to assist those delivering public sector websites to determine which web browsers to use for testing. Public sector websites have a responsibility to be inclusive and not exclude groups of users but it would be impractical to test websites on every available browser.

So far, so apparently reasonable. I’m pleased to see that the COI advises that browsers on Windows, Mac and Linux be tested, that assistive technologies be tested, and it’s good that the draft guidance recognises that different sites have different target audiences.

But the central premise of the draft guidelines is fundamentally flawed.

Playing the numbers game

The central message of the draft guidelines (which are not available in HTML, only Word (280K) and PDF (160K)) is that public sector webmasters need not test in less-popular browsers.

If a browser appears in visitor logs as being below an arbitrary percentage of total “unique visitors” then it should not be listed as being “fully supported” in the site’s accessibility or help pages.

It may be listed as "semi-supported", which is defined: "A browser is semi-supported if the content and navigation works but the website does not display as intended”. Intended by whom? Are we back to the bad old days when webmasters strove for pixel-perfect rendering, even on governmental sites which are largely content-driven rather than design-dependant?

This page is best viewed with Browser X

The COI says “Avoid using statements such as, ‘this page is best viewed with Browser X’", and then goes on to advocate pushing users to change their browser.

There are many reasons why people use minority browsers, like Opera, Flock, Camino, OminWeb, Konqueror and the like (full disclosure: I work for Opera). A large percentage of visitors to the WaSP website use browsers other than the Web’s most numerically popular browser, for professional or political reasons. Others use a smaller browser for accessibility reasons, or because it’s familiar, or because they prefer the user interface, or just because they like it. Choice and personal preference is the heart of an open Web.

But the COI believes that it’s legitimate to suggest that visitors to government websites should change their preference, working methods and computer setup because of its testing policy. The example browser support policy statement, that they advise publishing on an accessiiblity or help page, says (my emphasis):

[Website name] has been tested on a wide range of browsers:

[List supported browsers here]

We advise you to upgrade your browser version as far as your computer allows and if possible to one of those listed above. However, the following browsers should also provide access to all of the content and navigation on the site:

[List semi-supported browsers here]

In short, in order to save costs on testing, the COI is advocates browser upgrade. By encouraging people to move from minority browsers to majority browsers, it works against the minority browsers ever increasing their market share in that sector, and the public sector is a big sector. It also sets a terrible example to organisations outside the public sector who are only just being cajoled out of the “build for IE” mindset.

Swimming against the tide

In the introduction to a document that wishes to help webmasters save money by limiting the range of browsers used for testing, it says that "how to code for browser compatibility" is "out of scope". This is bizarre; how can the single most effective way to reduce the cost of development be considered out of scope? This goes completely against the recent rise of the standards movement led by the WaSP, which was founded in 1998 to fight for standards that reduce the cost and complexity of development.

The guidelines note

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.

This is entirely back-to-front. The guidelines should be advocating a specific development methodology: they should recommend designing to Web Standards. Costs will be driven down, even if testing is performed across more browsers, because there will be fewer inconsistencies and less recoding to fix inconsistencies.

The COI should also advocate publishing information in open formats, such as HTML, and practice what it preaches.

Respond to the consultation

All UK and European developers have the right to respond to this consultation, which closes October 17, 2008. We hope that you will do so, because UK government websites have a lamentable track record, and we invite you to post your response on your site and link to it in the comments below, to inspire others.

Your Replies

#1 On September 8th, 2008 11:26 am » UK government draft browser guidance is daft browser guidance replied:

[...] can read the rest of this blog post by going to the original source, here [...]

#2 On September 8th, 2008 11:27 am UK government draft browser guidance is daft browser guidance replied:

[...] Original blawson [...]

#3 On September 8th, 2008 12:06 pm Wait till I come! » Blog Archive » UK government browser guidance in dire need of upgrading replied:

[...] Bruce Lawson checked the guidelines in detail and responded to them on the WaSP blog [...]

#4 On September 8th, 2008 12:07 pm Michael replied:

Thanks for this post. I’d read the guidelines and lost the will to live, let alone write about it! But I shall respond to the consultation.

#5 On September 8th, 2008 12:14 pm Chris Heilmann replied:

Gee, this is discouraging. Let’s hope our feedback will make things better. I’ve blogged about this and I am trying to point them to the graded browser approach we’re taking here which covers both the support issues and is pointing forwards instead of backwards.

#6 On September 8th, 2008 3:21 pm Robert replied:

I’m not sure I can get fired up about this if I assume they are making a good-faith effort to come up with good guidelines. Honestly, I think they are fairly practical.

Browsers used by 2% or more of users on any given site will be IE6, IE7, and FireFox. Mac and Linux MUST be supported, so the site would have to support the two most popular browsers in each, at least. Those would probably be a Gecko and a WebKit for sure, and maybe Opera. Lynx support is recommended so that any device can access the content of the site. Of the “minority browsers,” you listed, all except Opera are WebKit and Gecko browsers. Assuming the browser developers didn’t do anything silly, the rendering should be the same across them. Opera typically renders very similarly to WebKit and Gecko (not pixel perfect, but you decried that concept). It is VERY rare that I’ve developed a site that some portion didn’t work with Opera (and that usually had to do with more advanced JavaScript / DOM problems with SELECT elements).

In real life, I ensure support for IE 6, IE 7 and the latest Safari, FireFox, and Opera. If there is a new IE beta, I’ll test on it, too. Once I really knew how to code sites, I stopped checking in Lynx to make sure things worked (because I coded them in such a way that they would work). I feel confident that my decisions for supporting these browsers will provide a usable site in other browsers that use the same rendering engines. So, based on the document, I’d still be doing exactly what I do now, which is a realistic (and probably more far-reaching compatibility check than most non-standardistas would do) method for developing sites for desktop browsing.

Given that you live in the UK, it’d be your tax dollars that pay for compatibility testing to all these minority browsers that use the same rendering engines as the major browsers. So, I guess it’s your right to respond to them however you like since you’ll be paying for it.

#7 On September 8th, 2008 3:43 pm Lark X-RAM replied:

“Public sector websites have a responsibility to be inclusive and not exclude groups of users but it would be impractical to test websites on every available browser”

“The central message of the draft guidelines is that public sector webmasters need not test in less-popular browsers.”

So what, you guys from OPERA ASA must finally accept the world how it is made…

Having since years (almost 10 IIRC) reached only a market share well below under 1% in the meantime, does not entitle you to make thousands of people do some extra work. Instead you should ask yourself why your success is not coming to the fullest as you seem to be deserving it and why you are still offended by the fact, that people prefer other, even only recently emerged browsers.

All your users would be much better off if you would listen more carefully to those, who are NOT those already convinced fan-boys, but normal people who don’t have an IT background and only want a browser they can USE!
Without any hassle on installing, updating, using, normal browsing, online banking, visiting secure sites etc.

Telling them how standards compliant and how secure your browser is, and leaving them alone when some task can’t be fulfilled is just an elitist, but nevertheless silly point of view, not to speak from the stupidity in driving them away to other browser so that they could get their job done.

What do you expect?
Such is life…

#8 On September 8th, 2008 4:20 pm Martijn ten Napel replied:

#9 On September 8th, 2008 5:39 pm Jake Archibald replied:

This feels like a bit of an overreaction to me. “Semi-support” is a concept we have at the BBC although we call it “level 2″ support.

It’s not explained awfully well in their documents, but it sounds like the intention is the same as ours. For level 2 browsers we must ensure the content is accessible but design and javascript can be minimal or even absent. The easiest option is to include the CSS / JS in such a way that the level 2 browser fails to load it, so it gets plain HTML.

The browsers we support are also based on browsers are users are using and trends in those numbers. Is there a better method? When you’re being paid by the public it’s difficult to justify spending their money on supporting browsers an insignificant number of them use. There needs to be a cut off point somewhere, although 2% seems a bit high.

Also, while I don’t agree with the “We advise you to upgrade your browser version…” line, it appears as part of their browser support policy (not every page) and it’s hardly bad advice. A newer version of the browser they’re using will most likely have less security bugs.

As for “how to code for browser compatibility” being “out of scope”, I assumed they meant it was out of scope for that document. In fact, they may have recognised it should have a document of its own. At the BBC we have separate working groups for the browser support guideline and XHTML integrity guideline etc (some people sit on both groups). How to code is out of scope for the browser support guideline working group in terms of output, but it’s not ignored. As I said, this is an assumption, if they aren’t going to create coding standards then they’re in the wrong.

It’s a draft, some bits need clearing up and explaining better, but is it really that bad?

Jake.

#10 On September 9th, 2008 4:10 am Chris Heilmann replied:

About the comment of Lark X-RAM: Please keep Opera out of this, WaSP is not Opera and if you have beef with them, please contact Bruce directly.

Let’s not confuse matters here.

@Jake: I agree with what you are saying but a guideline that does not mention progressive enhancement is to me quite outdated. You cannot say you support browser XYZ and ask people to upgrade, you have to build your code defensively and let it recognize good standards support. The way the guidelines stand now is as short-sighted as testing for document.all was.

#11 On September 9th, 2008 4:11 am Wendy replied:

I would say at least you HAVE guidelines- (I don’t think most of our government even know how to access their email let alone what accessibility is) but then that’s just it- to even START pushing for guidelines in SA we would need a valid example, and this isn’t really what I was hoping for

#12 On September 9th, 2008 4:19 am WaSP Member blawson replied:

@Jake: You said ‘I don’t agree with the “We advise you to upgrade your browser version…” line, it appears as part of their browser support policy (not every page)’ – that’s very true, and my article is ambiguous; I’ve amended it for clarity.

I have no problem at all with graded browser support, but it should be graded on capability, not popularity.

The guidelines are draft (which is why I urge everyone to comment on them, so they can be sharpened up) but they read (to me) as if they assume that a browser they haven’t tested (because it’s niche) is automatically incapable and needs upgrading. That’s not true at all.

@Lark X-RAM – you’ll notice that I don’t only mention Opera; there are a whole range of smaller browsers that could be hurt by this. But I would love to have a discussion with you about Opera’s deficiencies; Please email me at brucel at opera dot com.

#13 On September 9th, 2008 4:34 am Björn Hagström replied:

The agency (Verva) in charge of setting standards for public sector web sites in Sweden translated their guidelines into english (pdf, 1,3 MB) in april 2008. They have worked hard in promoting standards for many years now and the swedish (original) version of this document is a few years old by now. I think they have a very sensible approach and I would suggest that you browse thru the document if you have the time. This is how they solved this issue:

3.3.2 Develop the website according to a standard rather than for a specific browser
Priority 1
Browser development is moving towards better conformity with existing standards. Thus, choosing to follow web standards ensures that code will function in future versions of the browser. Doing so also facilitates usage for users who use the website with other tools.
The basic principle is that no one may be excluded from accessing the presented information. To do this, design (layout, colours, font) must be separated from content (informative text, images and sound), and correct semantic markup must be used. This allows recipients of information to transform content into the most suitable format themselves.

…

Backward compatibility
There is no obligation to support browsers that substantially deviate from the standard. This primarily applies to older browsers. They will still be able to show content, but layout and formatting may not be displayed as intended. It is seldom cost-efficient to make adaptations for these browsers or to supply special versions of content for them.

Testing techniques
It is possible to use W3C’s validation tool in order to check if a page follows the selected standard for markup code: http://validator.w3.org. The tool can proceed from links to pages or uploaded HTML code for pages that are not yet publicly accessible. There is a corresponding tool from W3C that can be used to check if there are style sheets: http://jigsaw.w3.org/css-validator/

Testing the website’s development should primarily be done in a browser that best supports the standards; adaptations to other browsers can be done afterwards. It might at times be necessary to forego design and layout to enable the website’s information and services to be accessible to all users.

The browsers that most commonly appear in browser statistics today are the most recent versions of Internet Explorer and Firefox. Others that appear are versions of Netscape, Mozilla, Opera and Safari.

New browsers are constantly appearing, which means it is even more important to develop according to a standard. There are still differences in terms of how well browsers support and interpret the different standards, so the website should generally be tested in as many browsers as possible.

…

PS 3.3.1 is named “Follow standards” and should probably be read together with 3.3.2 that I quoted above.

#14 On September 9th, 2008 8:50 am Jon Hicks replied:

“Having since years (almost 10 IIRC) reached only a market share well below under 1% in the meantime, does not entitle you to make thousands of people do some extra work. ”

This is not about Opera, it’s about any small-use browser. The guidelines will encourage browser-sniffing, and the other WebKit browsers (Omniweb, iCab, NetNewsWire, etc) will get shoved out, simply because they’re not called Safari, rather than whether they’re capable or not.

It’s the wrong approach completely. Code to standards, not browsers.

#15 On September 9th, 2008 1:38 pm Jake Archibald replied:

Ok, I think there’s a confusion around what we each mean by “browser support”.

I code to web standards then test the site in (at least) the browsers I’m required to support. If a bug exists in one of the supported browsers then I need to work around it.

“Browser support” doesn’t mean coding it for IE, but rather making it work in IE.

Browser support should be based on popularity (among other things like usage trends) rather than capability. Opera 8 dwarfs IE6 in terms of capability, so should Opera 8 get more of my time?

No! That would be mad.

In the audience I develop for Opera 8 is extremely rare whereas IE6 is the majority. Some people have no choice but to use IE6 (many corporate environments) whereas Opera users tend to update quickly. Working around Opera 8 bugs would be a waste of time and public money.

In this model, if a browser came out that was spec-perfect, it would work flawlessly on the site despite being absent from the support list. If the browser had bugs, and stats showed its popularity was rising, it would be added to the support list and have its bugs worked around.

@Jon Hicks: “Code to standards, not browsers”, almost. It should be “Code to standards, then browsers”. You must develop sites that work for your users, and your users are using browsers.

To sum up, for me “Browser Support” means “browsers whose flaws you need to cater for”.

Jake.

#16 On September 10th, 2008 1:54 am stainless steel ring replied:

It is hard to believe that a government is not demanding from its suppliers that the websites should conform to open webstandards, to ensure that every citizen should be ablt to at least navigate through the content delivered by its government.It is seldom cost-efficient to make adaptations for these browsers or to supply special versions of content for them.

#17 On September 10th, 2008 3:22 am Robert Whittaker replied:

I agree almost entirely with what Jake said in #15 above.

I’ve only had a quick look at the document so far, but my first impressions are that it does a reasonable job of explaining why it’s important to test in browsers, and setting a standard for which browsers Government sites should be tested in. What seems to me to be missing is the “code to standards first” and “graceful degradation” philosophies, so that any (new or old) browsers that have sufficient standards support should get a usable website even if they haven’t been explicitly tested.

(The use of the word “Standards” in the title of the document is a little confusing / misleading too I think. Wouldn’t it be better to call it something like “Browser Testing Policy”?)

#18 On September 10th, 2008 6:05 am Jon Hicks replied:

Jake, I’m not suggesting you work around Opera 8 bugs at all. Yahoo Graded Browser Support is where it’s at. If a browser is capable, it shouldn’t be excluded, particularly in the example I gave of WebKit. I keep hearing the extra testing cry, but that simply doesn’t have to be the case.

After all, if you only support certain browsers, then your website statistics will only enforce that, and not tell the true story of people trying to use the sites concerned.

#19 On September 10th, 2008 7:06 am Adam Bailin replied:

Hi, I work for COI and was responsible for developing the draft browser guidelines. Thanks to everyone that has responded to the consultation so far. The number of responses is ~400, which is great!

I agree that websites should be coded to conform to W3C standards such as XHMTL and CSS. This is the subject of a different guidance document on technical standards. Admittedly, it needs updating and it will be the subject of a future consultation.

In addition, the accessibility guidelines require technical standards compliance for public sector websites as part of the double-A committment.

I recognise the fact that coding to web standards means that websites are more likely to work across a wide range of access technologies (para 40). However, I still need to test my website to make sure it works.

The focus of this document is very much on testing websites. Once a website has been developed, it is tested on a range of browsers but the question is, which to test on? Testing on every browser would be impractical. Looking at usage statistics provides a helpful way to decide which browsers to test on to ensure that the majority of your users are having a good experience.

I’m not suggesting that anything below 2% is not supported, but it does provide a useful cut-off point for determining what to test on (para 16).

I hope that the guidance is not seen in opposition to the web standards movement. I see it working very much alongside solid, standards-compliant code.

Please also forgive the lack of an HTML version at this stage. When the final version has been approved, it will be made available as (standards-compliant) HTML.

#20 On September 10th, 2008 8:20 am Graceful Exits » Blog Archive » UK government demonstrates lack of comprehension of web standards replied:

[...] can read a breakdown of the worst bits on The Web Standards Project, but here’s the feedback I just emailed [email protected]: [...]

#21 On September 10th, 2008 8:23 am Cole Henley replied:

1) A list of browsers tested on should not equate to a list of supported browsers.
2) If the public sector strives for accessibility and inclusivity (which, I think we would all agree, it should) then support on the basis of demographics is not an ideal approach.

My thoughts and response at http://cole007.net/blog/38/browser-whores

#22 On September 10th, 2008 8:32 am Bruce Lawson’s personal site : Jottings, a hello, releases, apologies replied:

[...] written a piece for the Web Standards Project about a new government consulation on proposed guidelines on browser testing. Sounds yawnorama, I know, but please read it and respond to the government: if it goes [...]

#23 On September 10th, 2008 12:05 pm AlastairC replied:

@Jake: I completely agree (especially coding to standards, then browsers), however, the people reading that standards document may take wildly different approaches from you!

For example, I tried accessing hotmail with Chrome, and got a “please update to IE/Firefox/Safari” message…

So in terms of the document, something along the lines of Björn Hagström’s outline from the Swedish guidelines is much more appropriate.

It discourages the ‘numbers game’ mentality, and should lead to better coding longer term.

#24 On September 10th, 2008 4:09 pm Joanne Finch replied:

As a website designer who has worked on various Government websites and along side many a Government web team, I’m glad to see the Government taking the time and effort in order to help web teams make the most of their budgets when it comes to browser testing.

I have to agree with many of the comments here, in that I’m disappointed the document doesn’t advocate XHTML & CSS standards with more vigour. The extract Björn Hagström has posted from the Swedish public sector document expresses the need to adhere to standards clearly and with common sense. I do recognise that this document isn’t about “how to code for browser compatibility” but I think it is essential to mention standards due to the vast cross over and impact, between the two subjects.

But even this does not deserve the slating the document has got from Bruce and others. I have to agree with Jake in that a line needs to be drawn when it comes to browser testing, as it is public money after all and some government departments, LA’s etc can, shall we say be a little overzealous in their attempt to be all inclusive; I have previously worked on at least one public sector website that spent nearly half their budget on browser testing.

As long as designers/developers code to standards and minority browsers such “Opera, Flock, Camino, OminWeb, Konqueror and the like” render standards correctly, then their shouldn’t be a problem with only testing on larger browsers such as IE, which less face it, need the work a rounds due to their rendering issues.

I think with a little bit of re-writing and a bit more emphasis on standards this document with make a good starting point for public sector web teams to form a common sense, browser testing policy.

P.S. I will be submiting my comments, and posting my own blog post on the document in the next couple of days.

#25 On September 11th, 2008 5:45 am Ben Hayes replied:

In the browser support policy statement, there should be no need to make specific suggestions about which browser people use. How about something like this:

“This website has been specifically tested on Internet Explorer versions 6, 7 and 8, Mozilla Firefox version 3 and Safari version 3. However, it should work equally well with any modern, standards-compliant browser. If you are experiencing problems with your browser, please check that you are using the most recent version, as this may help to solve the problem.”

#26 On September 11th, 2008 6:25 am Tony Crockford replied:

I’m a little concerned that there’s some out of context reporting here.

My reading of it is that the guidelines help government webmasters
develop a browser standard against which they *guarantee* their sites
to work.

it isn’t, per se, a ‘code for browsers’ manifesto.

it says:

“This guidance is for all website managers, web
developers and web testers delivering public sector
websites. It is designed to help you decide which
browsers and operating systems to test your website on. ”

I have a browser standard:
http://www.boldfishclient.co.uk/go/browsers

which I cribbed in part from Yahoo’s graded browser support
http://developer.yahoo.com/yui/articles/gbs/

so I support the move to create, and maintain a list of browsers
against which sites have been tested.

I agree that the ‘building sites for browsers’ approach is utterly
wrong, but then “how to build a government web site” is covered here;
http://www.cabinetoffice.gov.uk/government_it/web_guidelines.aspx

where it is clear that they support building to web standards.

so, in context, – build to standards, test and guarantee a range of
browser support, seems an eminently sensible approach.

#27 On September 12th, 2008 6:00 am Dirk S replied:

A mon avis Monsieur Hayes a tout à fait raison. Il ne faut pas de suggestion specifique, quel browser aide les gens à accéder à l’internet…

#28 On September 12th, 2008 2:24 pm Not talking about it « Let me think about that … replied:

[...] as I rather like my job. Besides, one of my colleagues who worked on drafting the paper has already replied very eloquently to the blog article on webstandards.org that was picked up by The Register for their story in the first place and there’s little for [...]

#29 On September 12th, 2008 9:06 pm ThePickards » Blog Archive » Public Sector Browser Standards replied:

[...] 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 [...]

#30 On September 13th, 2008 9:15 am Capability, not Popularity | aboutCREATION replied:

[...] Design, English Bruce Lawson recently brought to our attention the UK government’s Browser Standards Draft 0.13. Basically, the draft recommends using browser popularity (2% or more usage), rather than [...]

#31 On September 15th, 2008 3:56 am Darren Taylor replied:

Bruce while I agree with some of your points I don’t support your idea that Gov should be testing sites in a wealth of browsers. I say this as someone who does extensive testing on sites before go-live, as part of a successful set of standards and policy set here in NI. The reason for my non-support is because it’s just not cost effective nor practical. I work in a modern environment (see workplace2010) which means my resources in terms of IT equipment are limited. I test sites in the most popular browsers (as I see it) IE, Firefox, Safari and in different screen resolutions. I accept that more testing could be done but is it a good use of my time? Should tax payers money be used to employ me to spend hours looking at a site on browsers that less than 1% of potential users have and which, by the way, are likely to have no problem anyway?

#32 On September 15th, 2008 10:04 am WaSP Member blawson replied:

@Darren – you make a good argument (as does Jake Archibald). My argument isn’t that you should test in everything. My argument is that the guidelines say that “you must publish a list of the browsers you have tested your website on” (paragraph 8) which I believe disadvantages the smaller browsers that are, as you say, likely to have no problem anyway, by making people think that by not testing them, you somehow suggest they are inadequate or old or insecure.

There is also the naff advice: “We advise you to upgrade your browser version as far as your computer allows and if possible to one of those listed above [List supported browsers ].”

That gives the message that a browser that’s not listed in the supported browsers (because it doesn’t have enough market share to be deemed worth testing) is somehow inferior to the ones that are listed, even though it might be just as capable or more capable.

Encouraging people to upgrade from a capable browser to another is wrong; it perpetuates market leadership, it puts a burden on the user in order to save money for the government department. It’s also unnecessary.

You ask “Should tax payers money be used to employ me to spend hours looking at a site on browsers that less than 1% of potential users have”.

I ask, should tax payers be asked waste their time upgrading browsers because government departments don’t do Yahoo-style graded browser support?

#33 On September 21st, 2008 3:17 pm Best of the rest - 38η εβδομάδα 2008 | Tsevdos.com replied:

[...] ευρωπαϊκού κράτους. Από μια πρώτη ματιά που έριξα, συμφωνώ απόλυτα με το post του Web Standards Project, το οποίο εξηγεί πως το σκεπτικό που [...]

#34 On September 21st, 2008 7:26 pm Steven Clark replied:

Having just resigned from a Tasmanian (Australian) State Government web design team that tests only on IE6 / IE7, latest firefox and latest safari – on Windows XP… I may be biased. When I did checking on Opera the question was why? When I mentioned JS disabled users would not be able to use site search (I mean WTF?) again I was asked – do you mean the 3 people using Linux?

It is very hard when people who are in positions being patted on the back for this stuff (career successes to date) have an invested interest in remaining that way. New ideas = risk IMO. My message to the public sector – cut the chaff.

When the government assess the cost of testing websites across multiple browers (and gov’t websites aren’t usually that complicated, more bloated) then how about they check how much tax they’re getting off the community to provide the services expected of them? I think that is the missing part of this conversation. Government aren’t just providing websites gratuitously, they’re meant to provide all of us with a certain level of information / public disclosure / access to services.

Just my 2 cents from recent experience.

#35 On September 21st, 2008 7:28 pm Steven Clark replied:

Sorry, I forgot. They also checked on Mac OS X whatever they had installed…

Is that what our tax dollars pay for?

#36 On September 21st, 2008 7:32 pm nortypig » Blog Archive » UK Gov’t Flawed Browser Support replied:

[...] way to go, but be damned if they’re going to recommend these practices. Their slightly flawed browser support policy is disappointing – what do taxes get spent on if not providing public services and access to public [...]

#37 On September 21st, 2008 8:34 pm UK Gov’t Browser Guidance is Flawed (Here Too) : StevenClark.com.au replied:

[...] was only a short time and the WaSP (Web Standards Project) published an article titled UK government draft browser guidance is daft browser guidance explaining why the COI have it so bloody wrong. The WaSP ask, may not display as intended by [...]

#38 On September 24th, 2008 7:43 am Dominic replied:

UK Madness!
It should not be about the browsers, All browsers should be up to scratch so you do not have to worry what your web page looks like in different browser!
It also does not deal with browsers say on the mobiles phone or other devices such as the playstation

#39 On September 30th, 2008 2:52 am Corey Mwamba replied:

Having previously worked in libraries (four years ago) and having a terrible experience of the I.T. implementation there, I’m actually wondering HOW they’re going to implement this standards approach.

Our local government’s I.T. was handled by Capita RAS who would only install MSIE on the computers. When I created a learning resource for English as a Foreign Language students, I had to take the work home, do it on Opera, and then test it at work. It’s all well and good writing the document, but they’re going to have to allow their employees to USE different browsers first.

#40 On October 2nd, 2008 10:41 am msn adresleri replied:

I work the company which is interested in this article so we’re having to look at these guidelines. I think that this work is ultimately a good info about thi subject, it will help the processing which need thi kind of infos.

#41 On October 3rd, 2008 7:56 am Newsletter: September — a blog entry for the Multipack - A Community of Web Developers & Designers in Birmingham replied:

[...] They’re a bit shit. Fortunately they’ve asked for feedback, which ‘pack member Bruce Lawson responded and has written on the Web Standards [...]

#42 On October 4th, 2008 11:03 pm games replied:

@msn adresleri
Which company do you mean?I didn’t understand your post in fact.

For the topic it’s good to see goverments to take care of public sector websites.UK is doing great job.

#43 On October 7th, 2008 5:15 am WaSP Member blawson replied:

Bruce Lawson here, with my Opera hat on rather than my WaSP hat.

I’ve published the formal Opera response to the guidelines, which argue that they

are anti-competitive, as they perpetuate dominance in the browser market by giving the impression that alternative browser products are inferior, and those who choose to use them are not worthy of consideration,
inconvenience users unnecessarily by asking them to install new software,
do not promote best practice development and may lead to more expensive development and testing,
are too fragmented,
insufficiently “future-proof” Web sites, by ignoring methodologies which would ensure compatibility with mobile phones and other devices,
ignore plug-ins which have capabilities independent of browsers, and
do not sufficiently ensure accessibility by disabled users.

#44 On October 9th, 2008 8:41 am Βρετανικές web οδηγίες. Τι λάθος έκαναν; | Tsevdos.com replied:

[...] Από μια γρήγορη ματιά που τους έριξα, οι οδηγίες προσβασημότητας (accessibility) δεν διαφέρουν και πολύ από τα διεθνή standards, έχουν γράψει με άλλα λόγια τα ίδια πράγματα σε κάπως πιο επιχειρηματική γλώσσα (έτσι μου φάνηκε τουλάχιστον). Προσωπικά δεν θα έμπαινα καν στην διαδικασία να διαβάσω οδηγίες που έχουν να κάνουν με το web, εάν αυτές προερχόντουσαν από κάποια άλλη χώρα, ωστόσο το Ηνωμένο Βασίλειο έχει μεγάλη επιρροή στην Ευρωπαϊκή Ένωση και τις ευρωπαϊκές αποφάσεις, ιδιαίτερα σε θέματα τεχνολογίας και καινοτομίας. Μέσα λοιπόν σε όλον αυτό τον όγκο των πληροφοριών, το Web Standards Project παρατήρησε ένα τραγικό λάθος και αμέσως ξέσπασε μια μεγάλη διαμάχη ανάμεσα σε αυτό και �…. [...]

#45 On October 14th, 2008 3:32 am Clerkendweller replied:

User security should be tested at the same time as “functionality”. Not whether particular browsers are more secure than another – but whether the browsers used by the public (whatever they may be) can be used to damage the user, their privacy, their system or their data when accessing a particular public sector web site. Older is not necessarily less, or more, secure – just different.

#46 On November 9th, 2008 8:16 am herrenuhren replied:

#47 On November 16th, 2008 1:54 pm تعليم replied:

For the topic it’s good to see goverments to take care of public sector websites.UK is doing great job.

see u

#48 On November 27th, 2008 2:52 am nui replied:

I ask, should tax payers be asked waste their time upgrading browsers because government departments don’t do Yahoo-style graded browser support?

#49 On November 27th, 2008 2:56 am nui replied:

I ask, should tax payers be asked waste their time upgrading browsers because government departments don’t do Yahoo-style graded browser support?

#50 On December 1st, 2008 7:08 am Flug replied:

@Textlinktausch: On the one hand I agree with you. Following the 80/20-principle it is just ineffektive to test your site on every single pee-browser. The problem here is, that the government has to ensure accessibility. So the question is where to draw the line.

Return to top

Post a Reply

Comments are closed.

Working together for standards The Web Standards Project