Everyone knows that developing a government website can be a challenge. One of the most common development concerns is Section 508 compliance. However, while Section 508 compliance is important, it should not be a developer’s only concern when testing a website. One area of web development that I find so often overlooked by government developers is browser compatibility.
For security reasons, many agencies are restricted to using Internet Explorer. Here at the National Defense University Press, we use an IE7 browser setup to render as IE6. However, as a developer, it is essential to test in other browsers; it goes along with site accessibility. Unfortunately, it is one of the steps so many developers forget about.
W3Schools stats from January 2010 show that 46.3% of visitors are using Firefox, 14.3% use IE8, 11.7% IE7, and a meager 10.2% run IE6. These stats are relatively in line with what I observe in our monthly web statistics. Unfortunately, this means that only 10.2% of our site visitors are seeing the site as we see it in the browsers on campus. This makes testing even more important.
However, if you’re developing a site internally and your browser usage is restricted, how can you be expected to test? I ordinarily will test my sites on a computer that’s not locked down and will step through and view the site in all the top browsers: IE6, IE7, IE8, Firefox, and Safari. This allows me to test roll-over effects and other site actions. However, if I’m in a pinch and making a relatively minor update, I’ll use a simple screenshot rendering site for browser compatibility like Browser Shots or Adobe’s BrowserLab.
Every browser behaves differently and it’s important to understand that you don’t have control over which browser your visitors will be using, so you need to be prepared. In most cases differences between browsers will be slight, however occasionally a browser will render something so differently that it causes major accessibility issues. It’s your responsibility as a developer to test for these issues.