[Testing for accessibility]

Reference browsers

The answer to the question 'for which browser should a web site be optimised' seems simple: all browsers. As is indicated on the home page, it is not advisable to design with a specific browser in mind. On the other hand, modern browsers offer features that can enhance the usability of a web site considerably, but that are not available in older or less advanced browsers. This document is an effort to explore the standards and recommendations that modern browsers are based on. It also tries to define criteria for what makes a browser a reference browser.

Functional compatibility

A browser can be designated as a reference browser when below-mentioned recommendations and standards are sufficiently supported. They are open and well documented guidelines for web publication, developed by or under the supervision of a standards organisation or the World Wide Web Consortium (W3C). There are several reference browsers. Together with the requirement that the functionality of a web site must be equal in all reference browsers, this means that the use of browser or operating system specific functions is not allowed.

This way, optimised usability of a web site is not limited to a single browser or a single operating system. "The power of the Web is in its universality", Tim Berners Lee once said. The inventor of the web has an important point here: the common practice of basing web sites on 'standard products' rather than on real standards is an dangerous development. First of all, it excludes groups World Wide Web users. Another danger is that the rest may become subject to the arbitrariness of a monopolist.
A biological ecosystem thrives on diversity; the same rule applies to the 'web ecosystem'!

Recommendations (W3C)


HTML 4.01 Transitional (loose.dtd)
HTML 4.01 Frameset (frameset.dtd)
XHTML 1.0 (transitional of frameset.dtd)
ref: www.w3.org/TR/html4 en www.w3.org/TR/xhtml1

Document Object Model

DOM level 1
DOM level 2
ref: www.w3.org/DOM/DOMTR

Cascading Style Sheets

ref: www.w3.org/TR/REC-CSS1 en www.w3.org/TR/REC-CSS2


WCAG 1.0 priority 1
ref: www.w3.org/WAI en www.w3.org/TR/WCAG10

Standards (ECMA)


ECMA-Script 262 (Standardised JavaScript/Jscript)
ref: www.ecma-international.org/publications/standards/ECMA-262.HTM

Rendering engines

The heart of each modern browser is a HTML/XHTML/CSS/JavaScript rendering engine. Browsers with the same name normally use the same rendering engine for different operating systems; the differences are mainly the appearance - the user interface - and sometimes stability and speed. One exceptions is Microsoft: Internet Explorer for Windows and for Macintosh are in fact two browsers that are basically different, the only thing that they have in common is the name.
Rendering engines that support the above mentioned standards are (in alphabetical order):

    the Linux/Unix browser Konqueror and Apple's new browser Safari are based on this engine
  • NGLayout (also known as 'Gecko')
    the base of browsers such as Firefox, Mozilla, Netscape, Chimera/Camino and Phoenix
  • Presto
    Opera from version 7 has this engine 'under the hood'
  • Tasman
    the rendering engine of Microsoft Internet Explorer for Macintosh
  • Trident
    the fundament of Microsoft Internet Explorer for Windows

Reference browsers


  1. A maximum of one browser per rendering engine can be designated a reference browser.
  2. The rendering engine of the browser should be available for at least two operating systems: BeOS, FreeBSD, Linux, Mac OS, OpenVMS, OS/2, Unix or Windows. Versions or distribution do not caount as separate operating systems;
  3. If criterium 2 cannot be met, a browser does apply if the market share on the operating system is fifty percent or more. The operating system itself must have a market share of at least five percent;
  4. A final release of the browser must exist (no beta software);
  5. When two browsers are equally qualified, the open source product is preferred.
Name of browser Version Engine multi platform Engine Open Source Browser Open Source Market share
> 50%
Reference Browser
NGLayout Firefox 1 Yes Yes Yes No Yes
KHTML (Linux) Konqueror 3 Yes Yes Yes ? Yes
KHTML (Apple) Safari 1 No Yes No Yes Yes
Presto Opera 7 Yes No No No Yes
Trident IE Windows 6 No No No Yes Yes
The following browsers do not meet all criteria:
NGLayout Netscape 6 / 7 Yes Yes No No No
? Netscape <= 4 Yes No No No No
? Opera <= 6 Yes No No No No
Tasman IE Mac 5 No No No No No
Trident IE Windows 4 / 5 No No No No No
? IE Windows <= 3 No No No No No

The reference browsers are Firefox version 1, Konqueror version 3, Opera version 7, Safari version 1 and Internet Explorer for Windows version 6. Firefox and Opera qualify because they are available for several operating systems and IE for Windows and Safari because of the market share that these browsers presently have. IE for Windows is a reference browsers, despite the fact that the support CSS2 is sub-standard by the opinion of experts.

Netscape version 7 is in many ways equal to Mozilla 1.01. This browser is the main 'donor' for Fireox. Because Firefox and Mozilla are open source products, Firefox was chosen over Netscape. The choice for Firefox over Mozilla can be explained by the fact that Firefox is only a browser, Mozilla also consists of an email program and a news reader.
Lately, Internet Explorer for Macintosh version 5 has lost a lot of market share in favour of Safari. For that reason, it is no longer considered a reference browser. Moreover, Microsoft has announced that is will no longer invest in further development of the Mac version of Internet Explorer.

Reference browsers and accessibility

WCAG, the accessibility guideline from W3C, is different from the other recommendations and standards in the list. A browser by itself cannot guarantee the accessibility of a website. For web designers, WCAG offers guidelines on how and in what context recommendations and standards can be used in the most sufficient way. Content should be accessible in a wide variety of circumstances: with modern browsers, with assistive hardware and software and even with low functionality viewers. By integrating WCAG in the list of recommendations and standards, accessiblity is guaranteed. Therfore, information should be accessible in all browsers and with assistive devices, while usability can be optimised for mainstream use.
A deprecated standard such as HTML 3.2 is not part of the list: backwards compatibility is built-in when a higher version of HTML is used in combination with WCAG.

It is possible to use features that are supported by the newest browsers, without sacrificing accessibility. However, it is important to incorporate accessibility in the concept of a web site. Three strategies are possible: graceful degradation, graceful transformation and providing a link to an alternative page.

Graceful degradation

In case of graceful degradation, web techniques such as Dynamic HTML (DHTML), JavaScript, Cascading Style Sheets (CSS) or specific plug-ins are used. In case these techniqes are not supported, navigation and information are still accessible. The result is a web page that is accessible under all circumstances.
A nice example where graceful degradation is applied: www.overheid.nl.

Graceful transformation

In case of graceful transformation the basis is 'plain and simple' HTML. When supported by the browser, standard HTML elements can be assigned more advanced or totally different properties: the HTML elements are being 'transformed'.
An example of this technique can be found in the article on accessibility of drop-down menus (in Dutch).

Accessible version of a web site

If, after best efforts, you cannot create an accessible page, you may provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. The less accessible page should comply with as many guidelines as possible. A simple example: every image must have an ALT attribute.
The use of a special, accessible version of a web site is not recommended. It often leads to new and different problems: the redirect of users to the proper page can be problematic. It normally is not very difficult when a user enters the web site on the homepage, but it is a different story when a deep link or a search engine was used to get to a page. Another argument against the use of accessible versions: sometimes it is used as an excuse for not paying attention to accessibility on the regular version of the web site.
Synchronising structure and content of both versions can be troublesome: it means an extra effort and continuous monitoring. In practice, it often goes wrong sooner or later and the accessible version of the site is forgotten when changes are made to the site.


Accessibility guidelines exist for software for authoring and for viewing web pages. The Authoring Tool Accessibility Guidelines (ATAG) cover the first category and the User Agent Accessibility Guidelines (UAAG) cover the second.
WCAG, ATAG and UAAG together are the foundation of the Web Accessibility Initiative of W3C. At present, conformance to UAAG is not part of the requirements for reference browsers. Possibly this aspect will added later.

Doctype switching

The reference browsers are capable of doctype switching, allowing HTML pages to be rendered according tot the specifications of W3C. For certain doctypes, the browsers switch to standards compliance mode. When this is not the case, the browsers interpret by themselves how the maker of a page may have meant the HTML to behave: this behaviour is called quirks mode.
What a design looks like across browsers in quirks mode is more of a guess than in standards compliance mode. Web designers who know the HTML specifications well (and know how to apply them!) can use doctype switching to their advantage.

More information

Raph de Rooij
version: 14 November 2004

[Up] [Homepage]