To meet WCAG 2.1 Principle 1: Perceivable, you need to make sure users can recognise and use your service with the senses that are available to them. Here's guidance on each of the elements you'll need to check are compliant against this principle.
To meet WCAG 2.1 Principle 2: Operable, you have to make sure users can find and use your content, regardless of how they choose to access it (for example, using a keyboard or voice commands).
To meet WCAG 2.1 Principle 3: Understandable, you have to make sure people can understand your content and how the service works.
To meet WCAG 2.1 Principle 4: Robust, you must make sure your content can be interpreted reliably by a wide variety of user agents (including reasonably outdated, current and anticipated browsers and assistive technologies).
Post your questions, qualms and conundrums over on the Teams channel and we'll happily offer our advice and wisdom!
First up on the checklist, let’s ensure your images, icons, avatars and logos have alternative (alt) attributes attached to them. If you’re using any of the above to visually convey messages, you’ll need to think how these are best communicated to users who are unable to digest this content, for example a person using a screen reader. Follow the action below for best practice on testing and actioning, in scenarios at the University.
Next up, we have captions and transcripts. There’s no doubt that video and audio content can help to make web pages and course curriculum more engaging. However, they can also erect barriers unless delivered with accessibility in mind. When delivering content like this, you must keep accessibility and usability at the heart of what you’re delivering, captions are clearly added to videos and transcripts provided for audio content. Full guidance is available for best practice around producing accessible multimedia.
We need to ensure that the interfaces that we build are intuitive for all audiences. For those who navigate using just a keyboard, tabbing a page should be simple and predictable. Navigation has a natural and recognisable feel, with reading from left to right and down sections to the base of the page. Check your site reflects that pattern using the full guidance provided.
Take a handful of todays most visited websites, and you’ll instantly be able to identify familiar elements across each. Strong heading structures, scannable content and striking actions. Visually, we can understand these structural elements and have a level of comfort in navigating and locating information we require. This is super important too for those who can’t interact with elements visually, so this section is all about how we correctly markup features to create rich, fair experiences for everyone.
Some users have difficulty perceiving text if there is too little contrast between foreground and background. The W3C Web Content Accessibility Guidelines 2.1 define specific contrast ratios that must be met in order comply at particular levels. In order to meet the guidelines at Level AA, text or images of text must have a contrast ratio of at least 4.5:1 (or 3:1 for large text).
When designing the colour scheme of a website, web page, or document, be sure to consider whether there is sufficient contrast between foreground text and background. Use the tools listed in the standards and guidelines to check the colours you’ve selected.
Avoid using visual characteristics such as spacial references (example “click the circle on the right”) or colour to communicate information (example “required fields are in red”). When providing written instructions consider whether the instructions are likely to make sense to a person who is accessing the page with a screen reader or Braille device.
An image of text refers to when readable text is presented inside an image, including text that has been presented in a fixed image form in order to achieve a certain visual style.
The Web Content Accessibility Guidelines (WCAG) recommend avoiding using images of text if you expect the text to be read by the user, unless it’s necessary such as in a logo or brand name, in which case the alt text should be the same as the text in the image.
Responsive web design is an approach aimed at delivering flexible web page layouts to provide optimal viewing across a wide range of devices. It allows for easy reading and navigation on a variety of different-sized devices – from oversized desktop monitors to mobile phone screens – with a minimal amount of resizing and scrolling. Instead of building multiple sites for multiple device types, designers create one site that responds to each type of device that accesses it and delivers the appropriate output.
Users with low vision seek ways to resize text without adding horizontal scrolling to the page. Additionally, fixed, non-fluid sizes cause overlapping or cutoff text when a web page’s text is resized. Similarly, tables and non-fluid pages used to lay out content cause reading order issues for users of screen readers. One size fits all sites do not fit the needs of users with disabilities. Responsive design principles, including fluid layouts, benefit users with disabilities on desktops as well as on mobile devices.
Users can easily change the default font size in their browser. All major desktop web browsers have built-in functionality that enables users to zoom in (Ctrl with the Plus key (+) in most Windows browsers, Command with the Plus key (+) in most Mac browsers). By default, modern browsers preserve the proportions of the page so the content gets larger without changing the layout.
However, in some cases users prefer simply enlarging the text, not the entire page, since the latter may require horizontal scrolling which makes reading the page content difficult. Some browsers support this functionality. Also, users can easily change the default font size within their browser preferences, which has the same effect. When users zoom into text or increase their browser’s font size, the page content should still be readable.
Many users are physically unable to use a mouse, and might be navigating through the page using keyboard alone. Testing a website with keyboard requires no special tools or skills–just try navigating your website or using your program using the keyboard only; don’t touch the mouse.
Websites sometimes feature slideshows or carousels that provide a gallery of self-updating images or teasers for news stories. These features present a variety of potential problems for users with disabilities, and in order to be accessible, must be designed with techniques detailed in University guidance.
Given this diversity among people, it’s difficult to predict how much time to allow for a given task. However, if security concerns or other factors require a time limit to be enforced, it’s important to be sure users are warned in advance before the time limit expires and offered an opportunity to extend their time.
Content that flashes or flickers can trigger seizures in susceptible individuals. Therefore flashing or flickering content should be avoided.
The best technique for addressing this issue is to avoid using content that flashes or flickers. Not only can it cause seizures, but it’s likely to be annoying or distracting for users in general. If you must use content that flashes or flickers, test your content using methods described in the additional details within University standards.
People with vision can quickly glance at the layout of a web page or document and easily find the content they’re looking for. If they’re able to use a mouse, they can even click on a link or other control within that section of the page. However, other users, including screen reader users, people who navigate by keyboard, and people using screen magnification, are unable to find and jump to content with similar ease unless the page is coded properly.
Web pages and documents should have titles that describe their function or purpose. This is helpful for all users, but is especially helpful for blind users, as the title is typically announced by screen readers as soon as a new page is loaded in the web browser or a new document is loaded in the reading application.
Link text should be unique within a page, should be meaningful when read out of context, and should help users to know something about their destination if they click on it. Link text such as “Click here” and “More” fail to meet these criteria. Consider the various ways users interact with links:
- Screen reader users can generate a list of links and navigate them alphabetically. Redundant or ambiguous link text such as “More” is meaningless in this context.
- Users of speech recognition technology can select a link with a voice command like “click” followed by the link text. Therefore it is also helpful to use unique link text that is short and easy to say.
Individuals have adopted a variety of methods for finding content on websites. Some people prefer search, others prefer navigation menus, and others prefer site maps. For some users the choice might be dictated by a particular feature’s ease of use. For example, some users with disabilities might find that it’s easier to use search than to operate a dropdown menu. In order to address the diverse needs of all users, multiple means should be provided for finding content on your website
Provide multiple means of finding content on your website, for example:
- Provide a Navigation menu
- Provide a Search feature
- Provide a Site map
Some computer users are physically unable to use a mouse. Others prefer using keyboard because it’s often more efficient. Computers in general, and web browsers specifically, can be operated with keyboard alone. In web browsers, users can use the tab key to jump between focusable elements (i.e., links, form fields, and any other content that has been added to the tab order with the HTML tabindex attribute). However, it is often difficult for keyboard users to tell where they are on the page. Designers must take care to ensure that it is easy to tell which item on the page currently has keyboard focus.
Event handlers are triggered by a browser or user event - such as when the page loads, when the user clicks the mouse, or when the time is 8AM. Some event handlers are dependent upon use of a mouse (or touch) or keyboard. These are called device dependent event handlers. Other event handlers are device independent and are triggered by both the mouse/touch and keyboard, or by other means.
To ensure accessibility, use either a device independent event handler (one that works with both the mouse and the keyboard) or use both mouse dependent and keyboard dependent event handlers.
Communicating in a simple, concise manner is an incredibly important consideration when designing your website. Here's some things to think about, for more detail, view University standards on producing accessible copy:
- Use bullet points and subheadings to break up the text
- Front-load your subheadings, titles and bullet points, putting the most important bit first
- Avoid block capitals
- Write in short sentences
- Use simple vocabulary
- Use words that are easy to understand
- Avoid using abbreviations without first introducing the full context
Many screen reader applications support multiple languages, and can switch on-the-fly between supported languages, using the appropriate voice and rule set for the current language. However, currently screen readers are unable to determine what language a document is written in, or if the language changes within that document. Therefore it is important for authors to define the language of the document or web page, and to identify the language of any blocks of text that deviate from that default language.
Identifying the language of the entire web page or document, as well as its individual parts, helps to ensure that screen readers will correctly pronounce the content.
Web users have certain expectations about what will happen when they tab onto a button, click in a form field, or select an item from a combo box. These sorts of behaviours are historically one step in a process in which the user first gives focus to the item (e.g., they enter a form field), then they make a selection, then exit the form field, and ultimately submit the form after they’ve made their selections.
If any of these steps prematurely triggers a change of context such as opening a new window, moving focus to a different component, going to a new page, or significantly re-arranging the content of the page, this can be very disorienting for users, especially screen reader users, screen magnification users, and other users with disabilities.
Even if forms are coded properly for accessibility, users may make mistakes. They may inadvertently skip required fields, or enter invalid information. A well-designed online form provides helpful and timely feedback to users so they can easily correct errors and resubmit the form. When providing feedback to users, it’s important to ensure that feedback is accessible to screen reader users. The following techniques can all contribute toward accomplishing this.
Using standards-compliant HTML increases the likelihood that all web browsers and assistive technologies will correctly handle your content. If your code contains errors or tags that are not part of the HTML specification, screen readers and other assistive technologies might fail when trying to render the content for users. Even pages that seem to look fine in a web browser might have unseen problems for assistive technology users.
There are many additional reasons to validate your HTML:
- Validating mark-up can help in your debugging efforts if your web page exhibits unexpected problems.
- Valid mark-up provides a better cross-browser, cross-platform, experience and gives you maximum control over how your page is displayed.
- Valid mark-up will help with future compatibility as it will have the best chance of being backward-compatible with new technologies.
- Properly formed HTML renders faster than HTML with errors. This means less load on servers and client browsers.
- A site that validates using proper HTML is a sign of professionalism.
The intent of this Success Criterion is to ensure that Assistive Technologies (AT) can gather information about, activate(or set) and keep up to date on the status of user interface controls in the content.
When standard controls from accessible technologies are used, this process is straightforward. If the user interface elements are used according to specification the conditions of this provision will be met.
If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies.
ARIA is a W3C specification that stands for “Accessible Rich Internet Applications”. It consists of markup that can be added to HTML in order to clearly communicate the roles, states, and properties of user interface elements. This information helps screen readers and other assistive technologies to better understand the elements on a web page, and to provide a user interface that enables their users to effectively interact with those elements.
For example, imagine a web page where a user is able to click a button to trigger some action on the page. When they click the button, a message appears at the top of the page informing the user of their success or failure. Using HTML alone, screen reader users would have no idea that this message has appeared, and even if they suspected it had appeared, they might not be able to easily find it. With ARIA, the developer could simply add role="alert" to the container where the message will appear. Then, when the content of that container changes screen readers will interrupt the user by announcing the message content. The user’s focus will remain in their original location so they can resume their work.
If you are developing dynamic, rich, interactive user interface elements for web pages, they must include ARIA markup or there is very little possibility of their being accessible.
