Creating Accessible Websites, Part 2:
For Web Developers

Are you developing your website for many types of users, or are you primarily developing for people who access websites in much the same way as you do? Do you know how dyslexic users, people who are colorblind, people with impairments, and others navigate the web? This week’s blog post is the second in a three-part series covering website accessibility with a role-based approach for web designers, web developers, and web editors. This contribution is meant for web developers. The previous was intended for web designers and the final is meant for web editors. In each post, concrete tips are given on how to create an accessible web site.

Page titles

Make sure that all web pages have a descriptive title that reflects the content of the page. Also make sure that web editors can enter page titles via the authoring tool (for example CMS).

Keyboard navigation

All content on a web page should be navigable both with a computer mouse and with a keyboard alone. This applies to forms, buttons and links for instance.

Some users are unable to use a computer mouse. These users rely solely on the keyboard to navigate web pages by tabbing through its content. For this reason it should always be visually evident where on the web page the tab indicator is located. Most browsers automatically show this with a dotted line around the content. You can also implement your own way of showing this.

Content sequence

When content for web pages is coded make sure that the content has a meaningful order, both visually and in the coding sequence. Some users navigate pages by this order. Ensure that the order of content is sensible when styles are disabled and when tabbing through content.


Make sure web page text can be resized up to 200% as a minimum, and still be usable and look sensible (newer browsers can zoom content and this is usually the way that assistive technologies do it as well).


In order for users to be able to render content in the correct language, it is important that the pages have a correct language definition in the HTML tag for a web page. The language tag should be ‘en’ for English pages for instance and ‘da’ for Danish pages and so on.

Also the CMS should give web editors the ability to highlight text that is in a different language than the rest of the page. The highlighting should add the lang=”” attribute into the code.


In order to make sure that the website is shown consistently across different platforms (such as operating systems and browsers) and ensure technologies can render content in a meaningful way, the standard for the format one publishes in should be complied with. If, for instance, you are publishing in XHTML 1.0 or HTML 5.0 the syntax rules for this format should be followed. You can check your web pages for syntax errors at:

Also make sure that elements are marked up with the correct tags. For example, HTML headings should be tagged as <h1></h1> (h1…h6).

Data tables should be tagged as <table> and web editors should be able to add descriptions to data tables via <caption>. Headings for columns and rows should be defined by the use of <th> and perhaps ‘header id’ and ‘scope’. If a complex data table requires explaining for users that need screen reader software, then this should be done via ‘summary’.

When writing text, web editors should be able to emphasize with <strong> and <em>.

When form elements are used, a label should be explicitly connected to each control and form elements that belong to the same group should be assembled. For instance a group of radio buttons should be grouped with <fieldset> and <legend>. There are a number of techniques to ensure this: Techniques for 1.3.1 and Techniques for 4.1.2.

User input

If the user is to enter information in a text field, make sure that if text is entered in an incorrect format the user is notified with text, and if possible help the user correct the mistake. When filling out a form that is part of a financial transaction or a legal commitment where data is changed, the input must either be checked by the system to avoid errors or the user should have the option of reading through the input before sending it. A third option is to allow the user to reverse the submission.


When web pages contain elements that are non-textual it is important to give a textual alternative describing the purpose of the non-text element. For non-text elements such as images, the HTML attribute for alt text is used (alt=””). It is important to note that proper alternative text reflects the purpose of the image and not necessarily what the image is of. The authoring tool (such as a CMS) should allow for entering alternative texts on images that are displayed on web pages. The alt attribute should always be tagged on all images, and should allow the web editor either to leave the field empty or give a description for an image. An alternative text is context specific, so it is poor accessibility practice to enter a single alternative text for every instance of a specific image when uploading to the media library. Your authoring tool should allow you to enter a new alternative text every time an image is used on a web page.

If a web page contains a media file, it should also be given a descriptive text either as an alt attribute or in the object tag on inline elements and the like.

Audio and video

When you publish audio and video on a web page, give an alternative format and add captions and audio description.

Make sure that all buttons and navigation in the video player can be used both with a computer mouse and with the keyboard alone. Give all the buttons and navigation text descriptions to help screen reader software.

For a video you should be able to enter a dedicated track for audio description and also the option to add captions.  If a passage of audio starts automatically, the user should be able to pause, stop, or control the sound volume.

User control

Some users need a long time to read and navigate web pages. Therefore, if a time limit is present on pages, such as a time out, users must be able to change the limit either by adjusting it, extending, or disabling it.

If content for moving, blinking or scrolling is added, it is also important that the user can pause, stop or hide this content.

In order for screen reader users to avoid having to listen to the same content every time they load a new page, provide the option of skipping blocks of repeated content. Repeated content can be a global menu (and local menu) and help functions. There are several techniques one can apply to ensure this. The easiest technique is to provide a link at the top of all pages that takes the user to the main content of the page (for instance the heading 1 on the page in the content section). There are other options as well: Techniques for 2.4.1.

When an element is to be altered by the user, such as a drop down menu, a radio button or the like, it is important that it acts as the user expects. Elements should not react solely from receiving focus or when the user lands on it from the keyboard. It should not react until the user has had the time to choose and confirm.

Blinking content

In terms of the above, specifically for blinking content, this should not happen with a frequency of more than three times a second, otherwise it may cause an epileptic episode for some users.

Learn even more about web accessibility by downloading our all-in-one digital accessibility e-book!




by Siteimprove
July 26th

Subscribe to Blog Updates