Government Browser Standards consultation
Browser Standards Draft
10 September 2008
Dear Sirs
Re: Web site accessibility and “browser standards draft”
http://www.coi.gov.uk/documents/guidance/browser-standards-draft-v0-13.pdf
I fear there is a fundamentally incorrect assumption behind your consultation document on web site accessibility in the guise of “browser compatibility”.
I agree with the premise of your consultation, that Government and other web site owners should be assured that their sites will be accessible using all commonly used browsers, and on special browsers designed for the impaired.
However I believe this aim, of correct display on the most commonly used browsers, may be better achieved by ensuring adherence to the underlying standards which all conforming browsers – the majority – implement. This as distinct from creating something which “works” on particular browsers by quirk, rather than because it is correctly designed and programmed.
However this latter “design by quirk” is a major risk of recommending that web sites just developed by testing with the majority browsers, rather than requiring that the job be done to accepted and common interoperability standards – those for HTML, XML, and ECMAscript (Javascript). These standards are clear, public, and universally accepted as defining the means of correct interoperability, and they are backed up by freely available validation software.
As a result it is a simple matter to ensure that the web site output is correct and interoperable. This can be done as a routine part of development, even automatically, thus keeping costs down. Full browser compatibility checks can of course still be done but will be less necessary; for day to day use a check with one standards compliant browser will assure compliance with them all.
Your example in Appendix A supposes that every office of Government would have to review every function of every web site some six times, not a task likely to enthuse the tester and not one which is likely to be performed to consistent standards by the time the tester gets to the fifth or sixth browser. I would agree that reviewing your work on a browser is an essential part of the development cycle, but you will appreciate that reviewing every feature of a site by a human on each of four or five browsers, to ensure that it looks right and works right, is not a task that it is efficient to do very often.
By ensuring web site output that is compliant to standards, as a regular intermediate validation step in web site production, you can be assured that as browser standards also strive towards compliance, you and the browser developers are working towards common goals of interoperability.
Another risk of just “developing to browser standards” rather than “developing to interoperable standards” is that browsers come and go and so do their quirks.
It is likely that some Government web sites may be in service for several years without any functional change being needed. It is inefficient to rewrite every site just to produce new output should vendor A, for instance, release a new version of Outernet Exploder which rewrites the rules on the quirks for “most common browser”. However even Outernet Exploder is very likely to have a “standards” mode, which can be invoked just by making the correct declaration of standards compatibility in the web site output.
A third benefit of building web sites to standards is that most if not all browsers for the impaired actually use the interoperable web standards in order to function. These standards define ways to provide alternative renderings as needed, and if you work to the standards, you are automatically as functional as possible, whether it is for Lynx or a special browser for impaired needs.
This can be as simple as providing meaningful “alt” texts on images, and destination titles and descriptions on hyperlinks, or provision of audio alternatives via standard HTML tags, or can help full cross-device compatibility by ensuring that all active (Javascript or Java) content also has HTML form-based alternatives available for those browsing on restricted devices.
Again this can all be achieved and verified by the use of public validation tools as a regular and integrated part of web site development procedures.
Use of common standards also aids in reorganisations. By means of CSS, two quite dissimilar web sites can be made to resemble one another without loss of function. I have made such a merge in my own web site between two web site production software tools, and because they both produce compliant HTML, it is simple to split the functions of my web site between them and still achieve a common look and user interface. I can also easily choose to keep formerly functional URLs in use as aliases, even when I reorganise the outer pages of my site to reflect the owner's changing priorities, as Government web sites will assuredly also have to do.
I believe this would be a major advantage in combatting “link rot” in Government web sites – something which has recently plagued my own use of the reorganised Disability Discrimination web sites, having invalidated all references from outside web sites as well as my extensive collection of Disability Discrimination bookmarks from prior to the reorganisation.
Finally, by mandating conformance to testable standards, work can safely be tendered out if desired, to strictly comparable cost bases, and still easily verified as meeting acceptance criteria.
In this way all users can be quite sure that your site will work correctly in any browser they choose, leading to user choice and empowerment, and your commitment to widest user availability is demonstrated to the widest possible audience.
In its present form I cannot agree at all with the Browser Standards Draft, and I hope you will give serious consideration to the points stated above.
Yours faithfully