Coding for accessibility

There are a number of coding methodologies that can help produce accessible web pages. These should be followed whether the page is hand–coded, generated by dynamic code or produced by a system such as a CMS.

Layout and structure

All HTML documents must have the doctype declared at the beginning of the document and the primary language identified. If there are any changes in the natural language of the document’s content the change must be identified using the lang attribute.

Every page must have a unique and meaningful title so that users can identify what page they are on. Pages with the same title can cause confusion.

The content on the page must be ordered in a logical manner so as to make sense to the user without any visual styling. Structural mark–up must never be used to provide visual effects and deprecated elements such as <font> and <applet> must not be used, instead use the latest versions if supported. Always use consistent styling and positioning of key elements on each page eg elements appearing on multiple pages such as site search must appear in the same place.

Always add ARIA landmark roles to appropriate sections of the page.

Device and software independence

Do not target specific devices or software (such as browsers). Write code so as to meet standards and where it is necessary to produce allowances for certain technologies use techniques such as conditional comments or feature detection to work around issues.

Ensure that all pages and functionality can be navigated and used with any input device, do not rely on a user using a mouse.

Progressive enhancement

Progressive enhancement is a strategy for web design that emphasizes accessibility, semantic mark up, and external style sheet and scripting technologies. Progressive enhancement uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web page, using any browser or internet connection, while also providing those with better bandwidth or more advanced browser software an enhanced version of the page.

Core principles:

  • basic content should be accessible to all browsers
  • basic functionality should be accessible to all browsers
  • sparse, semantic mark up contains all content
  • enhanced layout is provided by externally linked CSS
  • enhanced behaviour is provided by unobtrusive, externally linked JavaScript
  • end user browser preferences are respected

Graceful degradation

Graceful degradation describes how the document will behave when rendered in a user agent that does not support the most advanced technologies. Put simply, the web page must “degrade gracefully” when technologies such as CSS, JavaScript and even images are disabled. Content must continue to be accessible, and default browser functionality must continue to work.

Using the core principles of progressive enhancement techniques ensures that the web page will degrade gracefully, and that the fundamental browser functionality will not be lost. Graceful degradation is not to be used as a way to serve only the most advanced browsers with a web page. It should be used as an element of progressive enhancement, ensuring that content is not lost in less capable user agents.

Unobtrusive code

Unobtrusive code refers to the separation of the behaviour, presentation and content layers.

In practical terms this means that HTML event attributes, such as onclick, and the style attribute should be removed from the HTML completely and handled by external JavaScript and CSS, respectively.

This separation of technologies aids the maintenance of code, removing unnecessary, bloated code from your HTML and making it easier to find and modify. It re-purposes the developers HTML using it to describe a document’s structure, not its programmatic behaviour.

Core principles

  • Separation of presentation, behaviour and content.
  • Best practices to avoid the problems of traditional browser inconsistencies and lack of scalability.


Any functionality provided by scripting must also have a version available that fulfills the user goals and provides equivalent content without it. If any images or graphs are updated dynamically the changes must also be reflected in the descriptive text.

Do not create unexpected navigation (eg incorrect tabbing order, automatic new windows) via scripting. If using dynamic content, remember to update any ALT text to reflect the changed content. Don’t use JavaScript to emulate links, only use the <a href> element to mark up links, otherwise assistive technologies may not recognise them as links. Any scripting produced should also follow the same accessibility standards as HTML

Wherever possible ARIA states, properties and live regions should be used on scripted content to enhance their accessibility.

Showing and hiding of content

When visually hiding and showing content on a page care must be taken in the methods used. The following list describes the best method for each situation1.

  • If you want to hide content visually but have it accessible to screen reader users then do not use display:none. Instead use the off-screen technique or the clip method (both are described in Hiding Content for Accessibility) to hide elements only visually.
  • If the content you are hiding could also be useful to sighted keyboard only users, such as skip links, reconsider whether you really have to hide it. If you do hide it, make sure it becomes visible on focus.
  • If you want to hide something temporarily and have it display as a result of user interaction then display:none should be used. When using JavaScript to make content visible always use JavaScript to hide the content as well, or it will be hidden from non–JS users. Any controls for triggering the display or hiding of content must be available through any input device (such as a keyboard). This can commonly be achieved through using an anchor element as the control.

1. Based on an article by Roger Johansson