skip to content

The Sun on Your Face

Blog Entry: Building an Accessible Web Page

A Basic approach to Building an Accessible Web Page


5th May 2010

Semantic HTML

My basic approach when I begin building a web page is to plan the structure of the page, and represent it from the beginning using semantic html. The elements that I decide to use and the order that I use them in should accurately reflect the content that they will represent. The HTML should never be used to artificially apply any presentation to the content e.g. an <h4> element should not be used to embolden text, but rather a font-weight style should be applied.

By planning the correct structure from the outset, we immediatley begin to make the page more accessible to screen readers that rely on the HTML to convey the correct information.

Having created a skeleton page, I view the page under different browsers to ensure it is usable and I validate the HTML using the W3C HTML validator tool.

Applying Styles Using CSS

The next step is to apply styles to the page. I always use an external styleheet where possible as it easier to maintain and represents a more scaleable approach. It is also more effective in seperating the structure of the page from the presentation layer that determines how it is displayed.

There are a number of accessibility issues to consider

The priority associated with these potential issues will depend on the projected audience for the site. It is impossible to make any website completely accessible to everybody, but we must try and make it as accessible as we possibly can to the majority of expected users.

Using Relative Units for Sizing

By applying relative size units to text and other page measurements, the layout of a page will remain more consistent at different resolutions and text sizes. Relative units include:

An em is a unit of measurement in typography. It was traditionally the width of the capital M in the font that is currently being used, thus it it is relative to the chosen font.

Percentage values are always relative to another value. That value may be another property for the same element, a property for an ancestor element, or a contextual value e.g. the width of a containing block.

The W3C CSS2.1 Specification (and the CSS3 working Draft) lists the pixel as a relative unit, but there is some debate as to whether it should be treated as such in context of an accessible layout.

The pixel is relative to the resolution of the viewing device so I tend to use them for border sizes, paddings, margins etc. However, I would always use a percentage or an em etc for setting a font-size as these units are relative the users font settings.

The fact that a px is relative to the viewing device may cause issues on mobile user agents where the viewing port is very different to a computer display. A mobile stylesheet that applies a single column with a width of 100% can circumvent this.

Applying a Flexible Layout

It is also possible to use CSS to alter the layout of a page depending on the resolution by applying a flexible fixed layout. For example, a 3 page layout can change to a 2 page layout at lower resolutions by manipulating the CSS so that the 3rd column moves beneath the first column. In this way we can avoid a horizontal scrollbar and the page remains usable at lower resolutions.


By planning the page initially using only semantic HTML, it should always be possible to view the page without styles. It is alos important that web developers and designers do not set up their pages to interfere with or override any user-defined sylesheets. The contrast on a page should also be considered - users should be able to distinguish the text on a page from any background colours or images. Colour blind users should also be accounted for where possible.

At this point I would revalidate the HTML and also use the W3C CSS validator to check the CSS. A number of tools are available for assesing the accessibility of a page, but the one that I use is the WAVE toolbar extension available for the Firefox browser. A Colour Contrast Analyser by Gez Lemon is also available as an Add-on for Firefox.

As well as the automated tools I also test the page against various version of different browsers at different screen resolutions and text sizes. this is an iterative process where I continually revisit the HTML and CSS until I am happy with the result.

Client Side Scripts

Once I am happy with the usability and accessibility, I add any required enhancements using progressive scripting. I ensure that there are no script errors and then test the new functionality again using a variety of different browsers at different resolution sand text sizes.

I again revalidate the HTML and the CSS and retest.

Screen Readers and Text Only Browsers

The final step is to test the pages using a text only browser and at least two screen readers.

The text only browser that I use is LYNX and the screen readers that routinely use are:

Demo versions of both these tools are available from


Text only browsers do not support graphics, or technologies such as CSS and Javascript. They can therefore give a good usability overview of a page with these technologies turned off. The Lynx text browser can be downloaded as a standalone application, or the url of the site to be tested can be submitted to the Delorie Lynx Viewer website and a view of the page as if it were viewed in Lynx will be displayed.

Command keys are primarily used to navigate the user interface of the standalone application

Windows Eyes and JAWS

All screen readers have a specialised web mode for reading web pages and active elements on a page e.g. links, form controls can be navigated using the Tab key (Shift + Tab moves the user backwards through the document). The tab sequence will follow the HTML structure of the page unless a tabindex attribute has been specified.

Windows Eyes