The importance of Web Accessibility: how to build an accessible website

Posted by on Dec 17, 2011 in blog, copywriting | No Comments

1. Introduction


Accessibility in its broadest sense is the ease with which one can access, read and understand the information on a web page. It is influenced by many factors including disability, the browser being used and the functionality supported by the user’s browser.  In order to design an accessible site, the web developer must adhere to standards and practices which will result in a website that is cross-browser compliant, available across all hardware platforms and accessible to those with physical, visual or cognitive disabilities (estimated to be about 1 in 10 people), and by extension, any enhancement software that these individuals might use to access and browse the internet. The most important fact to remember is that the content of the site is what the user is there to read and it should take precedence over presentation where ease of access is concerned.

In short, an accessible website can be browsed and understood by anyone, regardless of visual impairment, physical or cognitive disability, choice of browser, device or personal preferences.

Types of disability and general considerations

Aside from the challenges of coding a website which caters for disabilities, developers need to deal with the simple fact that HTML is a constantly evolving language and that its features are supported variably from one web browser to the next. Thus the first consideration must be cross browser compliance.  In order to achieve this, graceful degradation of code is vital. As the browser reads code, it skips anything it cannot understand and reads the next thing. Graceful degradation means that when using new features in HTML, they must always be followed by the older features as an alternative so that anything new not recognised by the browser will be replaced by older features.

Next, the platform on which the internet is accessed must be dealt with and the developer must produce a design which is available across diverse platforms such as mobiles, tablet PC’s, gaming consoles, laptops and home computers.

The technologically limited should also be considered – people with slow connections or low bandwidth will be heavily affected by download speed (e.g. poor infrastructure in third-world countries or people using mobile devices), so the designer should try to ensure the fastest load speed possible.

Finally, accessibility concerns regarding disabilities must be addressed and each type of disability presents its own set of considerations which affect the design process. Listed below are the most common types of disability and some general notes on the challenges faced by users and designers. A more detailed examination of certain aspects follows thereafter.

1. Visual impairment

Colour-blindness:  These are individuals who have difficulty seeing colour or distinguishing between colours. Colour-blindness is usually either monochromatic (the user can only see black, white and shades of grey), red-green colour-blindness (the most common, where red and green are indistinguishable) or blue-yellow colour-blindness (where blue and yellow are indistinguishable).

The web developer needs to be very careful about using colour to convey information when considering colour-blindness. Another consideration is the use of colours for text and backgrounds as the wrong combinations may be rendered indistinguishable to a colour-blind person.

Poor eyesight / low vision: These users will often increase the default size of the text on a page or use magnification software (e.g. Zoomtext) to scan the page. Some may use the magnification software in conjunction with a screen reader. It is important to remember when designing, that magnification software only highlights small areas of the screen at a time and that scrolling or moving content will most likely be unreadable because of this.

Blind:  The blind generally use screen reading software (such as JAWS or Windows Eyes) to browse web pages. Some (but not many) use a refreshable Braille interface. The screen reader reads content as it appears in the HTML code, and the most important consideration here is that content and presentation are kept separate (by means of stylesheets) and that content is presented in a logical order, with the main content as close to the beginning of the body as possible.

In addition, pages and vital information must never be dependent on images alone and all images on the site must have descriptive ALT tags (unless they are for decoration only, in which case they can be named alt=”” which will be passed over by the screen reader). Important to remember is that users of screen readers use the keyboard only and not a mouse, so the site must be navigable by keyboard.

2. Auditory impairment

All audio material on the website must have a textual representation in the form of a transcript if the site content is to be available to deaf people. Transcripts are also useful to people working in very noisy environments or people without access to speakers. The developer could consider asking for signing to be made available on very important video presentations.

3. Physical impairment

This refers to people who are permanently disabled or temporarily injured and are unable to exert fine motor control and have very limited or no use of a mouse. Depending on the disability, they will use voice navigation software (such as Dragon Naturally Speaking) or devices which approximate the functionality keyboard tabbing. In designing, the absence of fine motor control must be taken into account when deciding on the size of page elements.

4. Cognitive and learning impairment

This refers to people who have difficulties with memory, problem-solving, perception, conceptualisation, reading and comprehension (e.g. dyslexia, learning disabilities). Some of these users make use of ‘browse aloud’ software (e.g. Textic) with which words are spoken aloud as they are highlighted in the text. With these disabilities in mind it is important to use simple, easy language and avoid large blocks of complicated text on web pages (which improves general readability too).

With all these considerations in mind, there are many tools out there to aid in the development of accessible websites which aid in the testing of sites and code to ensure they pass the standards as set out by the W3C.

2. Features

What follows is a more in-depth examination of some features and associated considerations with respect to accessibility.


The most important thing about tables and accessibility is that they should never be used for layout, and only ever used to display tabular data. Screen readers will read across a table and then down to the next row, which means that site content becomes completely jumbled if tables have been used for layout.

If tables are being used to present tabular data, it must be laid out in a logical order and the use of spaces at the end of cells and breaks at the end of rows is recommended. The use of rowspan and colspan are not recommended and complex tables with multiple levels of headings and well as the use of columns of empty cells should be avoided. Tables can be captioned using the <caption> tag to make them easier to identify, or they can be summarised using invisible text or the summary attribute, which is read by the screen reader but does not appear on the page.

The <th> (table header) tag can be used in place of <td> and <tr> tags to contain data such as column and row headings. Tables can also be divided into grouped sections using <thead> (containing the header elements like labels), <tbody> (containing the actual data) and <tfoot> (containing column totals, etc) tags. Using the <thead> tag allows the body to scroll while the head remains static, which is useful for devices with limited screen space like mobile phones.


Navigation as discussed here applies to both the actual navigation bar, and to methods of navigating about a page and between pages.

The most important thing to ensure with the navigation bar of the site is that it remains consistent throughout the site – this is not just general good practice, but also assists those with difficulty seeing or concentrating to always know where they are on a page. The navigation bar should stand out from the rest of the site and be distinctive with respect to colour and contrast so it is not confused with any of the other elements of the page. The links on the bar should be very clearly named and descriptive, they should make it easy to access all the content on the site and they should also be of sufficient size to present a big enough target to those who have limited motor control (meaning sufficient padding around each link and the use of the ‘display: block;’ property).

Also, it is regarded as a good idea to place certain elements at ‘expected’ places on a page (such as the search bar on the top right), which aids those using screen magnifiers (which show only a small portion of the screen at once) to know where to look for them.

For people using screen readers, it is vital to include ‘skip links’, placed before the navigation in the code, allowing the user to choose to omit having the reader software read out the full navigation code and to have the main content as close to the top as possible. These links typically skip to the most commonly used features; ‘skip to main content’ and ‘skip to search’, ‘skip to sitemap’ for example.  They can be made invisible by being absolutely positioned off the screen so that the screen readers will read them in the code, but sighted users won’t actually see them. Hidden text can be used anywhere on the site to provide context or information to the blind.

For navigation within a page the accepted practice is to use heading tags (h1 to h6) for heading up sections instead of just larger font sizes, as screen readers can differentiate headings as the starting point of a new segment of the page, allowing the user quick access to areas of interest. The page heading should be h1. Large font sizes and possibly different colours should be used for the headings to aid those with poor eyesight.

For links within a page, it is important to provide descriptive link text as opposed to links which say ‘click here’ (e.g. view our financial records vs. click here for our financial records). All links on a page should have a focus state with a different colour, which assists users in knowing where they are on a page when navigating by keyboard. Important links can also be assigned keyboard shortcuts by using the ‘accesskey’ attribute.

Having a sitemap is an essential for accessibility – it should be easy to find, logically laid out and easy to read.

Images which require the user being able to see them and click on a specific spot (such as an image map) should not be used for navigation without some form of supplementary navigation. Moving targets which require mouseover action to access them should never be used for links or to convey important information.

Form navigation is also an important consideration and the rule of thumb here is that the form instructions and information should always come before the form fields in the HTML, as the blind user will need to know what to do with a field before filling it in. Instructions should also be clear and explicit about the type of content required, allowable content and whether the field is required.  Form elements should also always be correctly labelled, which aids not only the blind, but also those with reduced motor control, as the text becomes clickable. Forms must all be tag navigable for keyboard-only users.

Relative font sizes

Poorly sighted users will often either change the size of the default text on a page, or zoom into the page to read the text. Text must therefore be resizable and the page must not break if the user zooms into it. The use of fluid layouts is important here.

Using relative font sizes is simply specifying which text on a page is larger or smaller than other text on the page, all of which is relative to the default text size that the user has chosen. Relatively sized fonts scale smoothly when being zoomed, whereas absolute font sizes can pixellate. Some browsers have issues altering the sizes of absolutely sized fonts.

Relative font size is define using % or em, and fixed font size using point size or pixel values (px or pt). Often, base font size will be defined in the body CSS (in pt) and then all other font sizes are percentages of that.


Frames are largely obsolete and seldom used anymore and for the purposes of accessibility, they should only ever be used to fulfil a function which cannot be achieved by any other means. Frames present screen readers with huge navigability issues and cause confusion with backward navigation and other functions.

In cases where frames must be used, the content must always be provided in an a alternate <noframes> version for the disabled user. This presents hassles with maintenance, especially if there is a lot of dynamic content on the page.

Javascript and scripting libraries

There are several considerations to bear in mind when it comes to scripting, the most basic of which is that all content on the site must be available to the user even if the scripting is not. Disabled users cannot always take advantage of the added functionality offered by scripts and some users will simply have JavaScript support turned off in their browsers. Any content and navigation provided by scripting alone will be inaccessible.

It is important that scripts are coded to degrade gracefully and ensure the content is still available to the user. Ideally a <noscript> version of the page should be present, offering the user the same content minus the scripting. Browsers which support scripts will ignore the noscript version.

Any scripting should be device independent, meaning that it should work independent of mouse or keyboard input – any information produced by a mouse hover, for example, would be unavailable to disabled users. Scripting must also not interfere in any way with a user’s ability to navigate with a keyboard (such as onchange functions).

In terms of cross browser accessibility, all HTML produced by scripting functions must be validated by testing the code in a validation application, and not just assumed to be correct.

File distribution

File distribution refers to the distribution of files from a website in a downloadable format. The most important consideration for optimum accessibility is to make sure that the file is available to as many users as possible.

Clearly, plain text is the most universally accessible format but it does not allow for document formatting. Offering the user a choice is generally the best route – for text documents, the most accessible option is PDF (portable document format) which is accessible across most platforms. Word documents are now more accessible and can be recognised across several platforms including Windows, Mac OS X and Open Office.

For compressed files, the most commonly used types are .rar and .zip – again, in order to maximise accessibility, offering users a choice would be the best option.

World-wide issues

World-wide issues include things like time zone, date format and currency indicators. Bearing in mind that visitors to the site will be from all over the world, time zones should be specified for time sensitive information and the date format should be internationally recognised.

Location information should be explicit and not a localised abbreviation (such as ZA for South Africa) and currency information should be universally accessible (a currency converter application could be used).

Extra character sets may be needed for a site that is to be published in languages other than eglish that use characters not found in the standard English alphabets (e.g. Chinese or Arabic).


Once all these factors have been taken into account, it is possible to build a website that is both attractive and functional, but also accessible to those with a wide range of special needs. Extensive testing is required and the use of an accessibility audit such as the one that follows is a good idea. There are many applications out there that you can test the site against which will test not only for accessibility issues but will also help improve your code by validation (checking the code against predetermined standards) and linting (checking the code for commonly made mistakes).







3. A Brief accessibility audit checklist


1. Does all auditory and video content have a transcript?

2. Is the webpage visible and easily readable when viewed in monochrome? – A screenshot of the website changed to a monochrome image in an image editor should show this too. Has it been tested by a service like Vischeck to make sure it can be easily read by colour-blind viewers? –  .

3.  Are content and presentation separate?

4.  Does code degrade gracefully?  This applies to both the HTML and any scripting on the site – is all the content on the site still available in an understandable way even of scripting is not supported and regardless of the browser used?

5. Can all moving elements on a page be paused, stopped or turned off?

6. Is any important information conveyed using moving elements anywhere and if so, is the information available elsewhere?

7. Is the design of the page device independent? Can it be navigated with any device (mouse, keyboard, phone keypad, etc) ?

8. Is the site compatible across all the major browsers: Internet Explorer, Firefox, Opera, Safari and Chrome?

9. Does the site work in a text only browser such as Lynx?

10. Can the site be successfully viewed across a range of devices e.g. mobile phones, tablets, small and large screens?

11. Is the navigation bar consistent throughout the site, clear and distinct from other elements on the page?

12. Have ’skip to’ links been included before the navigation bar?

13. Is content clear, simple and easy to read?

14. Are all headings marked up with ‘h’ tags?

15. Do all images on the site have ‘alt’ attributes?

16. Is all field information presented before fields in forms?

17. If a ‘captcha’ module is used, does it have an auditory component?

18. Can you successfully zoom into and out of the site without the text pixellating? Can you adjust the default font size successfully?

19. Has the html and CSS been validated by the W3C markup validation service?

20. Has the code been tested by a linting service to pick up common mistakes?

21. Has the site been assessed by Bobby, an application developed by the Center for Applied Special Technology (CAST), which analyses web pages and identifies accessibility problems.

22. Have the site been checked by WAVE, the Web Accessibility Visual Evaluator which highlights all the elements in a page and examines their accessibility-

23. Has the site been viewed by a disabled person? Invite disabled people to view and comment on the site.

24. Final checklist:

Has the site been checked with:

–          Images turned off?

–          JavaScript turned off?

–          Frames turned off?

–          Sounds turned off?

–          Using keyboard only?

–          Stylesheets turned off?

–          Screen-reader software (such as JAWS)?

–          Magnification software?

–          Across multiple browsers?

–          Across multiple devices