Test in multiple browsers, potentially automated, over the net. Latency might be an issue, but worth knowing about, given how much I hate setting up browser test rigs.
The COI have recently published a draft of their browser guidelines for anyone developing a public sector website.
Frankly, I’m very unimpressed; they’re dangerous, vague in certain areas and over-specific in others, and promote some terrible ideas. I’d urge any designer or developer with an interest in this area to download the document and read it – it’s really not very long – and then leave feedback on the document with the COI through the appropriate form. The public have been asked for responses, and we have the scope to respond; if you feel as strongly about what’s in the document as I do, I hope that you will.
My own response follows.
As a web development professional, I’m very unimpressed with this consultation document, and would go as far as to suggest that some elements of it are actively harmful.
I appreciate the attempt to codify the need for effective browser-compatibility for all public sector websites. That said, the manner in which the document suggests which browsers to test is very poor.
All browsers are different, even though the HTML and XHTML specs remain the same. The purpose of browser-testing is not to ensure that sites look identical in all browsers; the purpose is to ensure that the site is usable in all browsers.
As such, lists of browsers to be tested in are dangerous; the best we can aspire to is to write good, valid code that is functional in all browsers, and priortise appearance for the most modern browsers.
I take exception to the notion that the browsers to be tested on are those which have >2% share of visits on a website. 2% of hits on a very popular public-sector website might account for a sizeable proportion of users, and to exclude them (especially if the lack of testing in their browsers leads to impared functionality) could well contravene the Disabilities Discrimination Act. Also, note that these statistics are not necessarily accurate, and may contain spoofed or inaccurate user data.
Going beyond the 2% hurdle, it would not be feasible to test in all browsers. The best solution is probably a form of graded browser support, much as Yahoo recommends, which itself is reviewed and updated over time, and which guarantees a minimum functionality in certain families of browsers, full support in others, and makes it clear which browsers simply are not supported. Browsers do not cost money; they are not complex tools to install, and developers should not be limited simply because a certain percentage of users on their website continue to user Internet Explorer 5.
Browser support should not be a series of boxes to check off, and it should not be specified retroactively based upon current users; it should be based upon accurate specifications and usage patterns, to ensure that public sector websites – many of which already have high production costs – are sustainable, maintainable, and functional for years to come.
As such, this preliminary draft has a long way to go before it accurately represents the state of web usage, not to mention web development, in 2008.