Skip to content

Toggle service links

Web Standards

Creating a clear, consistent and coherent user experience.

Accessibility guidelines

If this is the first time you have referred to this standard we recommend that you read through the whole document to ensure you fully understand the importance of creating fully accessible web pages and linked content. These guidelines should be read in conjunction with our other standards.

Summary of key points

  • You MUST ensure your website design follows a consistent navigation scheme across all pages, and that the menus or other navigation mechanisms are located in the same place
  • You MUST provide a page title that describes the topic or purpose of the page
  • You MUST provide structural headers to convey the structure of your page.
  • You MUST provide a text based equivalent if non-text web content is integral to understanding the editorial content (video, audio etc.).
  • You MUST ensure that all functionality is available using the keyboard alone 

Introduction

The OU Web Accessibility Guidelines has been prepared as part of an overall digital governance review led by Digital Engagement. The working group that has produced them has drawn on expertise and representations from units across the university. It has liaised with SeGA (Securing Greater Accessibility), The Open University’s programme with responsibility for accessibility matters. ‘Web accessibility’ is defined as the practice of making websites usable by people of all abilities and disabilities. This document is intended as a practical working guide for use by:

  • anyone with responsibility for new web content (including third party content) 
  • anyone who develops new or existing web systems 

In addition, any organisations which are employed by the University to carry out work on its behalf (e.g. freelancer, agencies, contractors), must also be made aware of and follow these guidelines.

This document should be read in conjunction with our other web standards

W3C’s Web Content Accessibility Guidelines 2.0

The OU Web Accessibility Guidelines are based on the W3C’s Web Content Accessibility Guidelines 2.0(WCAG 2.0). The fundamental principles of the WCAG 2.0 are that web content and systems should be:

  • Perceivable – information and user interface components must be presentable to users in ways they can perceive 
  • Operable – user interface components and navigation must be operable
  • Understandable – information and the operation of user interface must be understandable
  • Robust – content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. 

In addition, The Open University has a legal requirement to present accessible web content.

This document also contains guidelines that are based on common accessibility issues that are identified in OU accessibility testing.  These guidelines are labelled ‘OU’ to distinguish them from WCAG guidelines.

This document sets out how these principles can be translated to practice, in terms of absolute requirements and ideal provisions. Examples are also given for reference. 

This document reflects step 13 of the BSI Web Accessibility – Code of Practice (BS8878, 2010), ‘Use web guidelines to direct accessible web production’. BS8878 is primarily about building accessibility into organisational practice and process where as WCAG 2.0 and these guidelines focus on the properties of the web pages. The code of practice is available from the BSI shop. OU Staff can access it free from the Library.

Exemptions and Third Party Content

If materials (including third party content) do not meet the guidelines then you must apply for exemption. Module Teams should check the accessibility of third party web sites where they are essential for achieving specific learning objectives and Securing Greater Accessibility (SeGA) has provided guidelines on doing this [See: Guidance for 3rd party material checking]. Whilst these OU Web Accessibility Guidelines may assist in assessing the accessibility of third party websites, the impracticality of applying the exemption process to all third party websites is recognised; especially where large number of such resources are involved; e.g. in the Library. If the accessibility of essential third party websites cannot be assured, alternative ways of achieving those learning outcomes should be identified for those students who experience accessibility problems interacting with them. The OU Web Standards include a process for requesting exemptions from the guidelines. If your website or resource cannot fully conform to these accessibility guidelines, see the requesting exemption page. It is possible to apply for a blanket exemption for large sets of third party resources. 

Queries

Further guidance for assessing the accessibility of materials can be found on the SeGA website. If you have any queries, please contact: Digital Engagement 

Translating the WCAG 2.0 guidelines into practice

Guidance on web accessibility in practice is given as:

  • Key principles for authors of new content, and 
  • Key principles for developers of new and existing web systems 
  • Ensuring the accessibility of third-party content 

1. Site Navigation

1.1 How do I help users navigate, find content, and determine where they are?

WCAG Reference: This corresponds to WCAG2.4

1.1.1 How do I make my website easy to follow?

Requirement: You MUST ensure your website design follows a consistent navigation scheme across all pages, and that the menus or other navigation mechanisms are located in the same place.

Why is this required? People will need to know what to expect. It can vary across devices, but should be consistent within that device.

Recommendations: Objects that appear on all web pages should be located in the similar place relative to each other on each page and are identified by the same name

1.1.2 Multiple navigation methods: 

Requirement: You MUST provide more than one way for users to move around your site.

Why is this required? Some methods of navigation will suit some people better than others. For example, people with cognitive impairments may prefer to work with a site map which provides an overview of the website.

Example: Provide a navigation menu, or a site map

Exceptions: Where web pages are generated as the result of, or a step in, a process, such as a payment process, or a registration process or assessment which you would not necessarily want to include in a site map. 

WCAG Reference: This corresponds to WCAG 2.4.5

1.1.3 What about locations? 

Requirement: You MUST provide information to help users identify their location within a set of web pages. 

Why is this required? This is a general usability issue affecting all users and should be established good practice. 

Examples: clear links back to the home page, use of breadcrumbs 

WCAG Reference: This corresponds to WCAG2.4.8 

2 Page Structure

WCAG Reference: This corresponds to WCAG 1.3

2.1 How do I make the purpose of the page clear (Page title)?

Requirement: You MUST provide a page title that describes the topic or purpose of the page.

Why is this required? This will help all users know which page they are on, but particularly screen reader users, who will hear the page title when the page loads.

Further reading: Further information on page titles can be found in the metadata standard.

WCAG Reference: This corresponds to WCAG 2.4.2

2.2 How do I provide support navigation to the main content? (Skip’ link)

Requirement: You MUST provide a ‘skip’ link to enable users to quickly access the main content of the page, where there are blocks of content that are repeated on multiple pages (e.g. header bars, navigation).

Why is this required? People, who use the keyboard to access web pages, including those who use screen reading software, will need to tab through all content at the top of each new page until they reach the main content. This can be time consuming, and can be avoided if there is a ‘Skip’ link which can take them directly to where the main content begins.

Note: Use of the standard OU Header and its associated tags provides this as standard.

WCAG Reference: This corresponds to WCAG 2.4.1

2.3 How do I make the purpose of a link clear? (Meaningful link purpose)

Requirements

• You MUST ensure that link text contains specific information as to the purpose of the link.

• You MUST also ensure that the code for links does not include erroneous text from surrounding content, i.e. ensure that the link text is as intended. (OU)

Example: Link text such as ‘Read more’ must be avoided, and text such as 'Read more about the conditions of transit workers' could be used instead, the extra text can be hidden from visual display so long as it is present for screen reader users.

Example: Text from surrounding content can accidentally be included in link text even when it appears to be visually correct.

Why is this required? Screen reader users may tab through links to skim web pages, or may use a command to list all links on a page. In these cases the links will be read out of context and any ambiguous links (e.g. click here, read more) will be meaningless. Any erroneous text included in links make the links less meaningful for screen reader users.

WCAG Reference: This corresponds to WCAG 2.4.4

2.4 How do I present the material? 

Requirement: A web page MUST be managed using style sheets for all presentational elements.

Why is this required? This allows users with their own specific visual requirements to apply their own styles sheets without losing any understanding of the structure of a page.

2.5 How do I structure the page?

Requirement: You MUST use the appropriate HTML mark-up to organise the structure of your page

Why is this required? Sighted users can understand the structure of a page by looking at it – headings tend to be larger, and often in a different colour. Non-sighted and visually impaired users cannot perceive structure this way, so they rely on their assistive technologies to explain a page’s structure by translating the HTML tags.

Example: All headings are tagged with the correct heading tag appropriate to their level, tables are only used to display tabular information (not for presentational purposes), and so on.

2.5.1 What sort of headings should I use?

Requirement: You MUST provide structural headers to convey the structure of your page.

Example: H1, H2, Table row headers, Table column headers.

2.5.2 What about sequences?

Requirement: You MUST use the correct HTML mark-up to organise the sequence in which content is presented.

Why is this required? This allows users of assistive technologies to understand that some content is to be read in a particular order, and that the order is significant.

Example: In a multi-column document, the linear presentation of the content flows from the top of a column to the bottom of the column, then to the top of the next column.

2.5.3 What about dropdown menus?

Requirement: If a site uses dropdown menus, you MUST ensure that they work correctly for keyboard users in all supported browsers.

Why is this required? Dropdown menus are an area of particular concern which often do not work properly or have browser differences.

2.6 How do I ensure sufficient text colour contrast?

Requirement: You MUST ensure an adequate colour contrast ratio for text.

  • Text that is less than 18 point (or 14 point if bold) has a contrast ratio of at least 4.5:1. 
  • Text that is greater than 18 point has a contrast ration of at least 3:1. 

Exception: Text that is part of a logo or brand name has no minimum contrast requirement.

Note - ‘Large scale’ is defined as 24px (18 point) text or 19px (14 point) bold text. It is acknowledged that point sizes are different for different fonts, but WCAG states ‘“18 point” and “bold” can both have different meanings in different fonts but, except for very thin or unusual fonts, they should be sufficient. Since there are so many different fonts, the general measures are used and a note regarding fancy or thin fonts is included.’ (From Understanding SC 1.4.3.)

Note: There are a number of online tools that can be used for checking colour contrast ratios, such as Juicy Studio.

2.7 How do I ensure that users can resize text?

Requirement: Text MUST be able to be resized up to 200% and remain readable without assistive technology. 

It should be checked that up to this level of zoom adaptive layouts do not cause problems. For example: truncated words; words overlapping with other content; or only one word of a sentence fitting on each line, causing the sentence to be displayed as a vertical column of text that is difficult to read.

Why is this required? Many users benefit from being able to enlarge the display, for example through the browser zoom settings, or browser ‘largest font’ settings. 

2.8 How do I justify text?

Requirement: You MUST ensure that blocks of text are aligned to either the left or the right, not justified.

Why is this required? People with dyslexia or some visual impairment find it much easier to read text when the spacing between words is consistent. Text that is justified can lead to “rivers of white” in the text which they may find particularly problematic.

Further information: Open University Copywriting guidelines

2.8.1 What about hidden text?

Requirement: You MUST ensure that text that is hidden on the page is also hidden from screenreaders (OU) unless the text is included specifically for screen readers.

Why is this required? Screenreaders can sometimes access text that is intended to be hidden, for example answer text in quizzes, or page tabs.

Guidance on ways of hiding text from screenreaders is available from WebAIM.

2.8.2 What about symbols and punctuation?

Requirements: You MUST NOT use symbols or punctuation to convey meaning except for mathematical purposes (OU). 

You MUST use punctuation appropriately (OU).

Why is this required? Screenreaders will use grammatically correct punctuation to read text in a meaningful way, e.g. a pause after a comma or full stop. However, under their default settings screenreaders may ignore symbols or punctuation such as asterisks, hyphens, slashes etc. that are intended to provide information or context.  

For example, asterisks to indicate required form fields, or slashes used as breadcrumb separators may be ignored by a screenreader. Such symbols should be replaced with graphics with appropriate alternative text to indicate their function.

Exception: Symbols and punctuation should be used when required, e.g. for mathematics and for correct grammar.

2.9 How many characters should I use across the width of a block of text?

Requirement: You SHOULD ensure that the width of a block of text (with default settings in common browsers) does not exceed 80 characters, or in the case of Chinese, Japanese or Korean character sets, 40 characters.

Why is this required? People with visual impairment and dyslexia find it difficult to keep their place in blocks of text displayed in long lines.

2.10 How do I space lines? 

Requirement: Body text line spacing (leading) MUST be at least one and a half times the line height.

Why is this required? People with dyslexia find reading more difficult if the lines are too close together.

2.11 How do I set the language?

Requirement: You MUST specify the default human language of your web pages in the HTML header using the method recommended for the version of HTML you are using

Why is this required? This will allow assistive technologies to use the correct language.

WCAG Reference: This corresponds to WCAG 3.1.1

2.12 How do I change the language?

Requirement: You MUST also specify and changes to the language of paragraphs or phrases in the text, except for technical terms, proper names, or words and phrases that have become part of the general language of the immediately surrounding text.

Why is this required? Some screen readers can be configured with multiple languages and voices in the language indicated in the mark-up of the webpage. This is particularly important in the web pages of language modules.

Example: If you would pronounce a phrase in a different manner, then it should be marked. In an English text Place de Barcelona should be marked as Spanish to ensure that the accent is given correctly. 

3 Page Content

3.1 Fonts

Requirement: You MUST use a sans serif font for main body text with a minimum font size of 12 pixels. (OU)

Why is this required? Sans serif fonts are generally more readable for all users, but particularly those with visual impairments or dyslexia.

3.2 How do I make non-text web content accessible?

Requirement: You MUST provide a text based equivalent if non-text web content is editorially important –integral to understanding the editorial content. 

Why is this required? Text is very accessible because it can be rendered in different forms: it can be read out by a text-to-speech engine (such as a screen reader), or translated into Braille. For users who cannot see the content, an assistive technology can read out its textual equivalent to them. Users with hearing impairments cannot access audio files, or the audio tracks of videos. If a text equivalent is provided, such as a transcript, then they can read that text instead.

Example: On a webpage about triangles, images of the different types of triangle would be considered editorially important, and therefore would require a text-based description of the triangle types as well as the images.

Exceptions: Activities that would be invalidated if presented as text, such as image recognition tests. However, if the activity is necessary for learning and test objectives to be achieved an alternative activity to meet this criterion should be created.

WCAG Reference: This corresponds to WCAG 1.1.1

3.3 Do I need alt attributes for images?

Requirement: All images MUST be published with alt attributes.

Why is this required? If an image is published without an alt attribute then a screen reader would inform the user that there is an image on the page, but would not be able to give them any information about it, causing frustration.

Exceptions:

  • If images are decorative then the alt attribute must be left empty (i.e. alt=””).This tells the screen reader to skip the image.
  • If an image has a caption with a sufficient description, then it is acceptable to leave the alt attribute empty.
  • Background images should only be used for decoration because they cannot have alt attributes
  • Background images are not visible when using high contrast settings

Requirement: If an image is a link and there is no other text in the link, the the image MUST have alt text which indicates the destination or purpose of the link.  When image links are adjacent to text links to the same destination, the image and text links MUST be combined and an empty alt attribute used (OU).

Why is this required? This reduces the number of links that screenreader users and keyboard users have to navigate.

3.4 How do I provide alternatives for time-based media audio/video?

Requirement: You MUST provide different alternatives for different groups of people. The specific requirements are listed on the next page.

Why is this required? The OU uses a range of audio/video material. Deaf/hearing-impaired people need access to the audio aspects of audio clips, video clips or animations. Blind/visually impaired people need access to the visual aspects of video clips or animations. People who have both visual impairment and hearing impairment need access to the audio and visual aspects of material.

Recommendations: For live audio, such as OU Live, WCAG recommends the provision of live text alternatives (e.g. through stenography) but this will not often be practical. Further guidance is available on the SeGA website.

Exceptions: These are listed in further detail below.

Note: The technical specification of the media formats and how alternatives such as subtitles and audio descriptions are provided are interdependent and also dependent on the intended player.

Further information: BSL interpretation of video or audio is not routinely provided by the OU, but this is an aspiration for the future.

Some alternatives support more than one disability group, for example captions and transcripts that are provided primarily for hearing impaired people are also beneficial for dyslexic people who may like to read as well as listen to audio/video and for all students in their study.

This standard deliberately does not cover the techniques for delivering accessible alternatives because these can change depending on the media, the platform, and over time. However it is useful to describe how some alternatives could be delivered. You should discuss delivery options with your media producer.

Audio description: is a specific technique of providing descriptions of the visual aspects of video. These are provided on a secondary soundtrack and the descriptions are inserted in the gaps within the original narration or dialogue. Some media players provide a button to switch audio description on/off.

Captions/subtitles: In the UK we use the term ‘subtitles’ to refer to on-screen text that serves as an alternative for hearing impaired people and text that is a translation of foreign language. In much of the world the term subtitles is used to refer only to translation and the term captions refers to alternatives for hearing impaired people. 

Captions/subtitles are delivered on screen. Some media players offer a button to switch them on/off.

Text alternatives: most text alternatives are delivered on a separate page linked to from above/below the original media.

Captions and transcriptions may be a benefit to students with no disability and should be openly made available to all.

WCAG Reference: This corresponds to WCAG 1.2.

3.5 How can I enable access to audio and video?

This table provides the standards for audio and video. Each row refers to a specific type of media, and the pairs of columns refer to the requirements of different groups of disabled people.

Media Type Disability Must:
Minimum alternative
Should:
Ideal alternative
Pre-recorded video or animation with soundtrack (includes OU Live) Hearing impaired For all Module Material: Captions (subtitles) of spoken content including relevant sound effects. For other material: Transcript of spoken content including relevant sound effects. Captions are the ideal alternative in all cases. British Sign Language interpreted version (not currently provided routinely but should be considered)
  Visually impaired Text description of visual content Audio description (separate audio track on video) of visual aspects (not currently provided routinely but should be considered)
  Hearing and visually impaired Transcript of spoken content including relevant sound effects and description of visual aspects  
Pre-recorded video or animation with no sound track Hearing impaired Indication to user that there is no sound.  
  Visually impaired Text description of visual content Audio description (separate audio track on video) of visual aspects (not currently provided routinely but should be considered.
  Hearing and visually impaired Text description of visual content. Indication to user that there is no sound.  
Pre-recorded audio (includes OU Live) Hearing impaired Transcript of spoken content including relevant sound effects. British Sign Language interpreted version (not currently provided routinely but should be considered)  
  Visually impaired No alternative needed  
  Hearing and visually impaired Transcript of spoken content including relevant sound effects  
Live video with soundtrack (includes OU Live) Hearing impaired An indication that sound is present and what the alternative provision is this this case  
  Visually impaired Text description overview of visual aspects, made available immediately after broadcast. Live description service (not currently provided routinely)
  Hearing and visually impaired Live description service (not currently provided routinely)  
Live video with no sound track Hearing impaired Indication to user that there is no sound.  
  Visually impaired Text description overview of visual aspects, made available immediately after broadcast. Live description service (not currently provided routinely)
  Hearing and visually impaired Live description service (not currently provided routinely)  
Live audio (includes OU Live) Hearing impaired Transcript of spoken content including relevant sound effects, made available immediately after broadcast. Live captioning. Live British Sign Language interpretation
  Visually impaired No alternative needed  
  Hearing and visually impaired Transcript of spoken content including relevant sound effects and description of visual aspects, made available immediately after broadcast. Live description service (not currently provided routinely)

3.6 How do I give instructions for selecting page items/navigating the site visually?

Requirement: You MUST NOT give instructions to users based on the shape or position of page items alone. If you use references to sensory characteristics such as shape and position, include a textual description as well; for example, such as “click on the round button labelled ‘Go’”.

Why is this required? Non-sighted users cannot understand these visual clues.

Examples: Do not use “click on the round button” or “click on the link to the right”. 

Further information: Can be found in The Open University copywriting best practice guidelines.

3.7 What about sound-based instructions? 

Requirement: You MUST NOT give instructions to users based on sounds generated from a page

Why is this required? Hearing-impaired users may not be able to hear the sound. 

Examples: Do not use: “Begin the quiz when you hear the alarm.”

Exceptions: An exception may be a text based on audio recognition skill

3.8 What about using colour?

Requirement: You MUST NOT rely on colour alone to convey information about the content of a page.

Why is this required? Users who find it difficult to perceive colour or who are colour-blind will be unable to tell which parts of the page can be actioned or clicked on or to obtain the information that was indicated by colour. 

3.9 What about pop-ups, overlays and lightboxes?

Requirement: You MUST ensure pop-ups, overlays, lightboxes, and other similar elements are accessible to the keyboard and assistive technologies (OU).

You MUST ensure that content and links underneath the overlay are no longer availble to keyboard users, or users of assitve technologies (the focus MUST be constrained within the pop until it is closed). 

Why is this required? Access for the keyboard and assistive technologies need to be built in to such elements. This includes moving the keyboard and screenreader focus into the element, then supporting navigation and closure of the element. It also includes ensuring these elements are visible and distinct under different colour and font size settings.

3.10 What about audio/video automatic play? 

Requirement: You MUST NOT allow audio or video with audio to play automatically on a web page.

Why is this required? If audio plays automatically any screen reader user will be unable to hear the output of their screen reader. 

3.11 What about playback control

Requirement: You MUST include a mechanism to stop or pause any audio content.

Why is this required? All users need to be able to control the playback on a webpage; in addition, screen reader users need to be able to control the playback of content on a page in relation to the screen reader output, to allow them to view the content in a timely fashion.

3.12 What about volume control?

Requirement: You MUST include a mechanism to control the volume independently from the system level volume.

Why is this required? All users need to be able to control the audio output from a webpage; in addition, screen reader users need to be able to control the volume of audio content on a page in relation to the volume of the screen reader output, to allow them to hear either one clearly.

3.13 What about images of text?

Requirement: You MUST NOT use images of text to convey information.

Why is this required? This is because images of text cannot always be resized without losing readability nor read by a screenreader unless they are provided with a suitable alt-text. If you are including logos on your page that are important to understanding the page’s contents, it is sufficient to provide alt text for that image that reads ‘<company name>logo’.

Exceptions: The only exception to this is if the presentation of the text is essential to the information being conveyed (for example, text that is part of a logo or brand name).

3.14 How do I use pre-recorded, audio-only content? 

Requirement: You MUST ensure that any pre-recorded, audio-only content, with the exception of audio CAPTCHAs, singing or rapping, either:

  • Does not contain background sounds; 
  • Contains background sounds that can be turned off; or 
  • Contains background sounds that are at least 20 decibels lower than the foreground speech content. 

Why is this required? This is to allow users with hearing impairments, who often find it difficult to understand speech when there are noises in the background, to differentiate between background noise and foreground speech.

Note - This 20db separation may not readily measureable, depending on production techniques, but the foreground sounds should be perceived at least as approximately 4 times louder than the background ones. 

WCAG Reference: This corresponds to WCAG 1.4 specific guidance is given in Technique G56.

3.15 How do I make web pages readable/usable under different user colour settings?

Requirement: Web pages MUST still be readable/usable when the user sets their browser to ignore colours or when they use operating system high contrast settings.

In practice this means not using colour on its own to convey information, for example not using colour on its own to indicate link focus, or to create sections.

Ensure that elements do not disappear under these settings, such as images, borders, rich text editors, and media player controls (OU).

Care should be taken using icons with transparent backgrounds to ensure they are visible against high contrast background colours (e.g. black).

You MUST NOT use CSS background images, unless the images are purely decorative, because these are not displayed in high contrast mode.

Why is this required? Some users with visual impairments or dyslexia find text much easier to read by adopting different colour contrasts. For example they may select a high contrast yellow text on a black background.

3.16 How do I provide enough time for people to read and use content?

WCAG Reference: This corresponds to WCAG 2.2

3.16.1 Timed activities: 

Requirement: You SHOULD NOT use timed activities except in exceptional circumstances like games.

Why is this required? There are many reasons why some people may require more time to complete tasks. For example, someone with mobility impairment may take longer to respond, and someone with low vision may take longer to read content or locate page elements.

Exceptions: Exceptions might include some activities in science, psychology, and simulations of real time.

3.16.2 Adjust timings

Requirement: If a time limit is necessary, you MUST ensure that at least one of the following options is provided:

  • An alternative activity: where the learning outcomes are the same 
  • Turn off: to provide an option to turn off the time limit before the activity begins 
  • Adjust: provide an option to increase the time limit by at least ten times the default setting before the activity begins. 

WCAG Reference: This corresponds to WCAG 2.2.1

3.16.3 Pause, stop, and hide:

Requirement: You MUST provide a way for users to pause, stop or hide any moving, blinking, or scrolling content that lasts longer than five seconds. See also Guideline 3.15. 

Examples: Examples here would include carousels and flashing alerts.

WCAG Reference: This corresponds to WCAG 2.2.2

3.16.4 Stop updates: 

Requirement: You SHOULD ensure that any updates or alerts can be postponed or stopped altogether by the user.

Why is this required? Updates can be very distracting to people with Asperger’s, and may disrupt screen reader users. (Guidance specifically related to possible risk of seizures is given under 3.15)

Exceptions: Emergency information is an exception to this, i.e. messages that warn of danger to health, safety, or property, including data loss, loss of connection, etc.

WCAG Reference: This corresponds to WCAG 2.2.4

3.17 How do I design content to avoid seizures?

Requirement: You MUST ensure that web pages do not contain anything that flashes more than three times per second, unless there is appropriate warning before the content begins.

Why is this required? Content that flashes may cause some users to have seizures. Removing all content that flashes more than three times per second significantly reduces the risk of seizures.

Example: A good example of this could be videos from news reels which contain flash photography. In this instance you must include a warning.

WCAG Reference: This corresponds to WCAG 2.3

3.18 How do I include new windows, tabs or overlays?

Requirement: You MUST warn users before opening a web page in a new window, tab, or overlay. 

Why is this required? Screen reader users in particular may find it very disorientating if they are taken to new windows without being informed.

Recommendations: To achieve this include the phrase 'Opens in new window/tab/overlay', or an icon with this alternative text, within the text of a link.

3.19 What about authenticated sessions? 

Requirement: You SHOULD ensure users can continue the activity without loss of data after they have re-authenticated, if an authenticated session requires a time limit.

Why is this required? Some disabled users have to take frequent breaks when using their computer because of fatigue or pain 

Example: If a user begins writing a forum post, leaves their computer for several hours, and returns to finish the post, they may be prompted to log in again because their authenticated session had a time limit. After the user logs in, their post should be successfully saved and available for completion and sending, rather than lost

WCAG Reference: This corresponds to WCAG 2.2.5

3.20 How do I label and group form elements? 

Requirement: You MUST provide meaningful labels to identify buttons and form elements.

You MUST also use fieldset and legend tags to indicate groups of radio buttons or checkboxes (OU). 

  • Labels SHOULD also include instructions, e.g. if a particular format or number of characters are required in a form field, this information can be included in the label 
  • You SHOULD NOT include instructions in placeholder text (OU). 

Why is this required?

  • Without correct labels and legends the screen reader may not correctly inform users what a button or form field is or how it relates to other form elements. 
  • Placeholder text is not read by screenreaders and so should not be used to convey instructions.

Further information: These are also covered in the copywriting standard.

WCAG Reference: This corresponds to WCAG 2.4.6, WCAG 2.4.10, WCAG 3.3

3.21 How do I identify errors in forms? 

Requirement: When submitting information using forms, any errors made by the user that are automatically detected MUST be identified on the web page, and the error described to the user in text.

Recommendations: 

  • You should list any error messages at the top of the form with a link to its associated field. This enables screen reader users to easily identify all the errors to be addressed in one location and makes navigating and correcting these errors easier. In addition, the field containing the error could be highlighted, a graphic asterisk and text message be placed next to the field to explain that it contains an error. 
  • Error messages can also be included in the ARIA (Accessible Rich Internet Applications) ‘describedby’ attribute.
  • You should confirm to the user that the form has submitted correctly and that no further action is required. 

WCAG Reference: This corresponds to WCAG 3.3.

3.22 How do I help users correct errors in forms?

Requirement: You MUST provide suggested guidance to the user, where there is an error, provided there is no risk to the security of the page or content.

Recommendation: Provide a suitable explanatory message explaining the error.

Examples: 

  • If the user incorrectly enters ‘18’ in a field labelled 'Number of widgets'. Instead of a message that does not provide guidance such as 'Invalid value', a suitable message would be ‘Must be between 1 and 10’. 
  • If the user enters ‘I do not have an email address’ in a field labelled ‘Email address’. A suitable message would be ‘Not a valid email address’. 
  • An example of not risking security would be not suggesting a correction for a mistake in a password field. 

3.23 How can I help users submit financial or legal information?

Requirement: You MUST allow users to review and confirm financial transaction or a legal commitment before submitting it.

3.24 How do I make changes in context accessible?

Requirement: You MUST ensure that all context change is initiated by the user.

Examples

  • Provide an "update now" button instead of automatically updating the content. 
  • An automatic redirection means a user is automatically redirected from an old page to a new page in such a way that he or she never realises the redirect has occurred. 
  • Ensure that screenreader focus remains under user control and is not moved to other areas of the page without the user initiating this (OU).
  • Ensure that if new content appears on the page as a result of user action that the user is made aware of that new content, particularly screenreader users (OU).

Exception: An exception is placing the focus in the first field of a login page.

WCAG Reference: This corresponds to WCAG 3.2.

3.25 What about refreshing web pages?

Requirement: You MUST NOT automatically refresh entire pages.

Why is this required?

  • When a page auto-refreshes, screen readers will begin to read the content of the page again. This can be very frustrating for screen reader users who may find it difficult to get to the end of the page before it auto-refreshes again 
  • If content (e.g. a 'breaking news' box) needs to update dynamically, this should be implemented by refreshing only that content instead of the entire page. (ARIA guidelines for accessibility in dynamic web pages which are not covered in this document may apply here.) 

3.26 How do I validate my website? 

Requirement: Your HTML and XML MUST be validated and used according to the appropriate W3C specification.

Why is this required? This is to help ensure that assistive technologies, which rely on mark-up languages being written in a consistent way across all sites, are able to interpret them correctly.

WCAG Reference: This corresponds to WCAG 4.1.1.

3.27 How do I develop my own user interface components? 

Requirement: If you plan to develop your own user interface components, you MUST ensure that each component can be uniquely identified and that any changes to states, properties and values of those components are notified to user agents, including assistive technologies. 

Why is this required? This is to allow assistive technologies the ability to read a component’s name, use, and its current value.

Example: Custom user interface components include controls that behave like buttons or checkboxes but do not use standard HTML tags for these controls. To achieve this requirement you must use the accessibility attributes that are available for the technology you are using. For example, use suitable ARIA attributes when creating any custom user interface components see WAI-ARIA overview . Similarly for Flash see Flash Techniques for WCAG 2.0 

WCAG Reference: This corresponds to WCAG 4.1.2

4 Keyboard Access: How do I make functionality accessible for keyboard users?

Requirement: You MUST ensure that all functionality is available using the keyboard alone, and there are no keyboard traps:

  • Where there are no industry-recognised standards, we should look to be consistent across our sites.
  • Keystrokes used to access functionality should not require specific timings.
  • Keystrokes used to access functionality should not require holding down more than one key at a time, or holding down keys for a long period.
  • Adjacent image links and text links should be combined where possible to reduce the number of tabs stops (OU).
  • Keyboard focus must be taken into overlays, pop-ups, lightboxes and similar elements (OU).
  • Keyboard focus must not be taken to invisible elements that the user cannot perform an action on (OU).
  • If an action makes the current element invisible, then the focus must be taken to an appropriate visible element.
  • Where focus can be moved to an element using the keyboard (e.g. using the tab key), it must also be possible to move away from that element using the keyboard
  • If anything other than the standard exit methods (i.e. tab, arrow keys) is required, you must inform the user.

Why is this required?

  • Mice and other similar devices require users to be able to see what is happening on the screen and are therefore not appropriate for people who are blind or who have low vision. For screen reader users the keyboard is the primary means of navigating the web.
  • People with manual or motor control mobility impairment (e.g. hand tremors) may find it difficult to control the mouse and may prefer to use the keyboard alone.
    • Holding down more than one key at a time, or holding down keys for a long period can be difficult or impossible for some users with disabilities.
    • Why is this required? Someone using the keyboard to navigate will be unable to proceed if they cannot use a keyboard command to exit particular elements of the page.

Example: Include links, menus, buttons, form fields, and drag and drops.

WCAG Reference: This corresponds to WCAG 2.1.1 WCAG 2.1.2

 

4.1 Focus Order:

Requirement: You MUST ensure that the focus order of elements on the page is appropriate for the structure of the page. 

  • It is important that the order in which these elements are presented is logical. You need to consider how people are going to use the page and think about the tabbing order for every page. Tab order should be closely aligned to structural order of the page.
  • Ensure that items located at the top or bottom of the page, e.g. ‘feedback’ or ‘back to top’ are included at appropriate points in the tab order (OU). 

Why is this required? 

  • People using the keyboard to navigate the page will often use the tab key to progress through the focusable elements of the page. 
  • If items receive focus at inappropriate points in the tab order it can cause the page to scroll in a disorientating manner.

WCAG Reference: This corresponds to WCAG 2.4.3

4.1.2 Focus Visible: 

Requirement: You MUST ensure that any elements on the page which receive focus when navigated using the keyboard are clearly highlighted when they are in focus.

Why is this required? This is to help people understand where they are in the page.

WCAG Reference: This corresponds to WCAG 2.4.7

4.1.3 Managing focus:

Requirement: You MUST ensure that the focus of assistive technologies stays within the user’s control, and moves to the part of the page that has browser focus (OU).

  • For example, screen magnifier and screenreader focus MUST follow when the user switches between page tabs.
  • For example, text-reading tools MUST be supported in reading the text under the mouse pointer and not reading other sections of text.

Why is this required? To ensure users know where the focus is, and are not disorientated.

5. References 

The OU Web accessibility Guidelines are based on the full W3C Web Content Accessibility Guidelines (WCAG) 2.0.

6. Document history

 
Version no. Date Author Comments
1 1 April 2014 Caroline Jeffreys First public version issued.
2 2 March 2015 Caroline Jeffreys Second public version issued.
3 October 2016 Caroline Jeffreys Third public version issued

 

Confused about MUST, SHOULD or MAY? The Terminology section explains when and why each of these terms are used, and what they mean.

Additional reading

The document, OU web accessibility guidelines conformance level, is a document which outlines how our guidelines map against the WCAG 2 standard, and was written by the working group chair and should be used as an aid when reading the accessibility guidelines.

Technical accessibility discussion forum

This forum is for technical accessibility questions and discussion. It is mainly intended for web and software developers but is open to anyone.