Evaluating Web Sites for Accessibility with the Firefox Web Developer Toolbar
In a previous issue of Ariadne , I gave a brief overview of Mozilla Firefox - external link  and introduced a few of its most useful extensions. In this article, we will use one of these extensions, Chris Pederick's Web Developer toolbar - external link , to aid us in a preliminary assessment of a web site's accessibility.
Although awareness of web accessibility has steadily increased in recent years, many web developers are still uncertain about how to evaluate their sites. The relative complexity of documents such as the W3C WAI Web Content Accessibility Guidelines (WCAG) 1.0 - external link  and the wealth of—sometimes contradictory—advice found on sites dedicated to the subject can leave developers wondering about the practical aspects of testing.
Often developers lack time or training and simply rely on one of the many automated testing tools such as WebXACT - external link , Cynthia - external link  or Wave . But even those mechanical checks need to be supplemented (and, to avoid false positives, counter-checked) by manual checks.
Based on some of the WCAG 1.0 checkpoints, this article aims to provide a quick outline of how Mozilla Firefox and the Web Developer Toolbar can help with these manual checks.
Provide a text equivalent for every non-text element
Users of screen readers and text browsers (as well as those users who have disabled images for faster browsing over slow connections ... and not forgetting search engines) can't see images included in a web page. Web authors need therefore to provide a textual alternative for the browser to use in these situations.
First, we must ensure that there are no images which are missing an
altogether: Images > Outline Images Without
If images are used purely for visual embellishment or as a spacer to influence
the layout, they should be marked up with an empty
(also referred to as a "null
src="/media/graphics/articles/evaluatingwithfirefox/sample.jpg" alt="" />
It would be better to relegate these visual stylings purely to Cascading Style Sheets (giving adequate margins and paddings rather than spacers/shims and assigning the images as a non-repeating background to the relevant markup element), but if your pages still use images for these purposes they can be identified via:
Lastly, we replace images with their
Ensure that all relevant images have an adequate and equivalent text alternative. This should be succinct, accurately represent any text present in the image and/or convey the purpose of the image.
Create documents that validate to published formal grammars
Web pages which use proprietary markup (special tags or style rules that only work in a particular browser such as Internet Explorer) or contain syntax errors (e.g. wrongly nested or unclosed elements) can cause problems with cross-browser compatibility: proprietary features may not be supported, and while one browser's error-handling routines may be quite lenient and compensate for messy syntax, other browsers may fail to render a page with broken markup.
The Web Developer extension provides a quick way to submit the current page (be it a "live" page already available online, or a document being developed locally) and its related style sheets to the W3C's HTML  and CSS validators  via the menu: , , , HTML.
Use style sheets to control layout and presentation
Pages which use HTML markup
to achieve a certain visual presentation (e.g.
table elements for layouts, text/link/background
body attributes) can cause problems for
users who wish or need to override the way a site is displayed (consider for
example a user with dyslexia who may require a specific combination of foreground
and background colour or a particular typeface). To check if a site's layout
is controlled via style sheets, we simply disable all styles with .
If the result is a page that looks unstyled, the site is indeed using CSS.
The following three checkpoints all relate to the correct use of HTML markup.
Use header elements to convey document structure and use them according to specification
Mark up lists and list items properly
Mark up quotations. Do not use quotation markup for formatting effects such
These items relate to the correct use of HTML markup. Assistive technology, such as screen readers, can take advantage of structural information provided by these markup constructs and offer users additional functionality in order to navigate a page more easily. Conversely, these markup constructs should not be abused for anything other than their intended purpose.
The Web Developer Toolbar can give a visual overview of a page's structure without the need to delve into the actual source code. First, we must ensure that in the extension's configuration the "Show element names when outlining elements" option (under) is enabled.
Selecting thecommand, we can now check that headings are indeed marked up as headings, lists are proper lists, and that elements are not being misused purely to achieve a certain presentational effect.
Specify the expansion of each abbreviation or acronym in a document where it
In a similar vein to the previous checkpoints, we can test for the presence of appropriate markup for acronyms and abbreviations (where expansions are presented visually to mouse users as a tool-tip when hovering over the element; correct abbreviation or acronym markup can be automatically expanded by screen readers when voicing a page).
As abbreviations and acronyms are not block level elements in HTML,
acronym as custom elements
to outline via .
Do not use tables for layout unless the table makes sense when linearised
In screen readers and text browsers, the reading order is determined primarily the be the order in which text appears in the markup (also referred to as "source order"). For tables, this has the effect of reading any cells sequentially left to right, top to bottom. Depending on how a table-based (multi-column) layout is constructed, content that appears to make sense visually may be read completely out of order once linearised.
If your page still makes use of layout tables, linearise the page and ensure that the content is presented in the right order:
Note that this checkpoint does not apply to data tables used to present tabular information (e.g. a spreadsheet of numerical data).
Organise documents so they may be read without style sheets. For example, when
an HTML document is rendered without associated style sheets, it must still
be possible to read the document
As with checkpoint 3.3, the quickest way to manually check that a document still makes sense without style sheets is to disable them.
Ensure that pages are usable when scripts, applets, or other programmatic objects
are turned off or not supported
The next two checkpoints can be approached in a similar fashion.
For scripts and applets, ensure that event handlers are input device-independent
For scripts, specify logical event handlers rather than device-dependent event
These two related checkpoints can be tested by simply using both mouse (or equivalent pointing device) and keyboard-based navigation (i.e. tabbing through all script enabled links present on a page) and ensuring that everything 'works' in both modes.
Create a logical tab order through links, form controls, and objects
The tab order of elements which can receive focus via the keyboard is determined by the order in which they appear in the markup. As with the previous checkpoints, this can be tested by navigating the page via the keyboard (tabbing through links, form controls etc) and ensuring that the order is indeed correct. Particularly complex forms with multiple inputs that were created and edited in a WYSIWYG (What You See Is What You Get) application (such as Macromedia Dreamweaver's page view - external link  or Microsoft VisualStudio - external link ) can often look ordered on screen, but have an underlying markup that makes users navigating via the keyboard jump from one part of the form to a completely unrelated one.
As with the test for checkpoint 5.3, correct source order—which determines a document's tab order—can also be checked by linearising the page.
Provide keyboard shortcuts to important links (including those in client-side
image maps), form controls, and groups of form controls
Although the subject of whether or not to provide
accesskey attributes is
a controversial one (see the articles by noted accessibility experts Derek
Featherstone and John Foliot of WATS ), we can nonetheless
make any accesskey assignments present in the current page visible via:
Avoid deprecated features of W3C technologies.
Related to checkpoints 3.2 and 3.3: even when particular markup constructs
(especially in transitional doctypes) validate against the official specifications,
the W3C may have flagged
them as being "deprecated"; these features are included purely for backwards
compatibility. An example of a deprecated HTML element
is the previously mentioned
font tag, which should be abandoned in favour
To identify the presence of any deprecated elements in the current page, we can usedeprecated elements.
Associate labels explicitly with their controls.
When users with screen readers tab their way through a page containing forms,
their browser's focus naturally lands on the individual form controls. To
understand what type of information or interaction the current form control
is expecting, these users may have to backtrack before/after said control
in order to find any possible textual labels relating to it. However, HTML offers—through
convenient and unequivocal way of associating the control and the label directly.
Assistive technology such as screen readers can take advantage of this element
and correctly announce the correct label for the current form control.
Additionally, labels can also benefit sighted users navigating pages with a mouse, as they can be clicked in order to activate and/or place the focus on their associated controls. In the specific case of checkboxes and radio buttons, this results in a much larger "clickable area", which can be particularly helpful for users with limited dexterity.
A very quick visual check takes advantage of this "side effect": when viewing a form, use the mouse to click on text labels. If the related form element is being activated, or the focus is moved to the associated input, then the page is indeed using labels correctly. For an overview of all form controls and associated labels present on the current page, you can take advantage of thecommand.
The Web Developer Toolbar is a powerful extension for Mozilla Firefox which can, in combination with other extensions such as Gez Lemon's Table Inspector - external link  (taking care of checkpoints 5.1, 5.2, 5.5 and 5.6 relating to data tables) and a solid understanding of accessibility principles, facilitate a large number of manual checks required by WCAG 1.0. Although it can't make all potential accessibility problems of a particular page immediately apparent to developers, it is nonetheless an effective tool which can be used to great advantage as part of an overall Web accessibility design workflow.
- Lauke, P.H., Ariadne 42, January 2005 "Mozilla Firefox for Rapid Web Development and Testing" - external link
- Mozilla Firefox product page - external link
- Chris Pederick's Web Developer Toolbar extension - external link
- W3C Web Accessibility Initiative Web Content Accessibility Guidelines 1.0 - external link
- Watchfire WebXACT - external link
- HiSoftware Cynthia Says - external link
- Wave 3.0 Accessibility Tool
- W3C Markup Validation Service - external link
- W3C CSS Validation Service - external link
- Macromedia Dreamweaver product page - external link
- Microsoft VisualStudio Developer Center- external link
- Featherstone, D. and Foliot, J.,WATS articles on Accesskeys- external link
- Gez Lemon's Table Inspector extension - external link