Web Accessibility

Web accessibility encompasses all disabilities that affect access to the Web, including:

• auditory
• cognitive
• neurological
• physical
• speech
• visual

Example:

Screen reader users: Blind Some low vision users Cognitive disability for processing text Learning disabilities

Web accessibility also benefits people without disabilities, for example:

• people using mobile phones, smart watches, smart TVs, and other devices with small screens, different input modes, etc.
• older people with changing abilities due to ageing
• people with “temporary disabilities” such as a broken arm or lost glasses
• people with “situational limitations” such as in bright sunlight or in an environment where they cannot listen to audio
• people using a slow Internet connection, or who have limited or expensive bandwidth

Accessibility for Content Authors

Links

• Should have descriptive text that clearly identifies the purpose and destination of the link.
• Make sure the link text makes sense out of context.
• Avoid using ambiguous link text, such as ‘click here’ or ‘read more’.

Example:

Screen reader users often scan through lists of links in isolation.

They do not have the surrounding context to help them understand what the link is for.

Alt text

• Write alternative text that provides information about the image.
• Be succinct and specific.
• Don't repeat information if there's descriptive text near the image.
• No need to include "image of ..." or "graphic of ..." as this already gets announced by screen readers.
• For purely decorative images, there's no need to enter alternative text.

Example - Informative image

An informative image that needs alt text:

W3C - Five examples of informative images

Example - Image and text inside a link

Incorrect use of alt text.

In this example, there's no need to add alt text to the image inside the link as it's decorative and the H3 link text is already read out.

<a href="https://www.screwfix.com/search?search=lowprice"> <img src="https://media.screwfix.com/is/image/ae235/assort_autumn1_UV_lowprice" alt="Low Price"> <h3>Low Price</h3> </a>

A screenreader will read out, "Low Price, Low Price".

Adding alt text to images is an important part of web accessibility. It allows visually impaired and blind users to process images on a page.

Alt-text is also shown when images do not load on a web page. Some users may also have images turned off in areas with slow internet access.

Missing alt-text as one of the most common accessibility failings.

Context is everything - detailed alt text examples

W3C - alternative text decision tree

Headings

Use meaningful, descriptive headings.

Add subheadings to group related paragraphs and clearly describe the sections.

Screen reader users often jump through the list of headings in a document so they can skip to the content they’re looking for.

Don't use bold instead of a heading, screen readers will not recognise them.

Colour and Contrast

• Don't use colour as the only way to explain or distinguish something
• Use text colours that show up clearly against the background colour

Text

Use simple language and formatting, as appropriate for the context.

• Write in short, clear sentences and paragraphs.
• Avoid using unnecessarily complex words and phrases.
• Expand acronyms on first use. For example, Web Content Accessibility Guidelines (WCAG).
• Use list formatting as appropriate.
• Consider using images, illustrations, video, audio, and symbols to help clarify meaning.

Don't use images of text.

Video and Audio

Provide transcripts for audio and video

Provide captions for video

Metadata

Page Titles

For each web page, provide a short title that describes the page content and distinguishes it from other pages.

The page title is often the same as the main heading of the page.

For pages that are part of a multi-step process, include the current step in the page title.

Help

Axe DevTools

Axe DevTools Chrome plugin can run tests and inform of accessibility problems. Manual testing is also needed as this tool will not automatically find 100% of errors or areas that could be improved.

Wave Evaluation Tool

WAVE can identify many accessibility and Web Content Accessibility Guideline (WCAG) errors, but also facilitates human evaluation of web content.

Users may quickly disable styles, identify headings, linearise the page into one column, change text size and background colour.

If you're disabling styles and images for an accessibility check:

• Does the information and reading order still make sense? For example, headings are right about the information they apply to?

• Can you still understand the information that images are providing through their text alternatives presented instead of them?

WAVE Web Accessibility Evaluation Tools

Wave Evaluation Tool for Chrome

Voiceover

Apple has a screenreader app called Voiceover, it's accessible from system preferences > accesibility. You can enable a shortcut to turn Voiceover on or off (triple click side button).

Basic commands:

• 'Control + Option + A' Start reading
• 'Control' Stop reading
• Next interactive element: Tab
• Previous interactive element: Shift + Tab

Full list of Voiceover commands

Talkback

Android has a screenreader app called Talkback.

Press and hold both volume keys for 3 seconds. To confirm that you want to turn TalkBack on or off, press both volume keys again for 3 seconds.

NVDA

NVDA allows blind and vision impaired people to access and interact with the Windows operating system and many third party applications.

Basic commands:

To start or stop NVDA: Press the "NVDA" key (by default, this is the "Insert" key) and the "Ctrl" key simultaneously.

Tutorials

Web Accessibility Tutorials

Courses

Digital Accessibility Foundations Free Online Course

W3C

Easy Checks – A First Review of Web Accessibility How to Meet WCAG (Quick Reference) Tips for Getting Started with Web Accessibility

Additional Accessibility for Developers

Text

When styling font, use relative values to define size (e.g., 1.3em, 130%). The page should be readable and functional when the text size is doubled by a user and that content reflows to a single column when it’s increased by 400%.

Check content is usable when you enlarge the text. In Chrome you do this by choosing 'Settings', and changing the 'Font size' from 'medium' to 'very large'. Also check content is readable when you zoom in with 'ctrl' and '+'.

Links

Use hidden descriptive text with visually hidden styles when there's not enough room in the UI.

Let the user know if a link leads to a download e.g., '(PDF)', or by explicitly including the word 'Download'

Images

Inline SVGs

Informative SVG images should have role="img" aria-label="Accessible Name example" attributes.

Decorative SVG images require aria-hidden="true" attribute to hide them from screen readers.

Forms

Form fields have visible and meaningful labels.

Make it easy for people to identify and correct errors.

ARIA and Role attributes

All interactive elements must have an accessible name.

aria-labelledby can be used to reference another element to define its accessible name, when an element's accessible name needs to use content from elsewhere in the DOM.

If there is no content that can be referenced to create an accessible name, use an aria-label e.g., when there's no space for text next to a search input.

Example - aria-labelledby

Example - aria-label

Use aria-describedby for when more verbose information is needed.

Dynamic content

When content updates dynamically, screen readers may not be aware. This includes screen overlays, lightboxes, in-page updates, popups, and modal dialogs.

Use aria attributes to inform users of the state an interface is currently in and if it changes, e.g., aria-pressed, aria-live, role=alert

It is preferable to use HTML where possible instead of ARIA:

• Use the native HTML button tag instead of the ARIA role of button.
• Use the HTML label tag instead of aria-label or arial-labelledby.
• Use the HTML5 nav tag instead of the ARIA role of navigation.

Keyboard users

• Interactions can be accessed with a keyboard.
• The keyboard focus is in a logical order and never trapped.
• Focus is always visible when moving through the page with the keyboard.
• Focus order should be logical with related content grouped together.
• Positive tab index numbers should be avoided.

Tabindex values of 1+ will receive keyboard focus before elements with no tabindex value (or tabindex="0") resulting in a navigation order that is different from the visual and/or screen reader order.

Instead of using tabindex, simply adjust the page's source code order to support a logical navigation and reading order, then use CSS to adjust the visual presentation.

• People who rely on keyboard access benefit from a logical, usable focus order.

• People can become disoriented when tabbing takes focus someplace unexpected.

WebAIM: Keyboard Accessibility: Tabindex

Deque University - Avoid Using Tabindex with Positive Numbers

Tables

Tables have head, body and foot structure, when appropriate.

Tables have proper headers and column attributes e.g., scope= "col".

A caption is used whether visible or for screenreaders only.

Don't use tables for layout only for tabular data, like a bank statement.

Styles

Check pages are usable when stylesheets are disabled

Carousel

Make sure that each image has alt text and can be navigated via the keyboard.

Screen magnification

Ensure on screen changes are obvious

Ensure key content is not contained within hover states or tool tips

Ensure priority content is positioned consistently

Accessibility Additional Notes

Accessibility is a necessity

15 to 20% of people require accessibility -- over 1 billion worldwide!

When a user is unable to complete their business, this may result in:

• total frustration and possible anxiety for the user as well as the waste of their time;
• loss of privacy/security for the user;
• loss of reputation for the organization;
• loss of revenue for the organization and
• possible litigation for the organization.

Overlap between the needs of seniors and users with disabilities

Many older people have age-related impairments that can affect how they use the web, such as declining:

• vision — including reduced contrast sensitivity, color perception, and near-focus, making it difficult to read web pages;
• physical ability — including reduced dexterity and fine motor control, making it difficult to use a mouse and click small targets;
• hearing — including difficulty hearing higher-pitched sounds and separating sounds, making it difficult to hear podcasts and other audio, especially when there is background music; and
• cognitive ability — including reduced short-term memory, difficulty concentrating, and being easily distracted, making it difficult to follow navigation and complete online tasks.

These aspects overlap with the accessibility needs of people with disabilities. So, websites, applications, and tools that are accessible to people with disabilities are also more accessible to older users as well.

ROI on accessibility work

• boost business by increasing your share of the market;
• enhance your brand reputation;
• drive innovation
• prevent possible litigation and
• set you apart as a leader in your industry.

The W3C site, The Business Case for Digital Accessibility, includes four business case studies:

• Apple
• Google
• Barclays and
• NPR Weekly Broadcast

POUR priniciples

The W3C Web Content Accessibility Guidelines (WCAG) defines four principles:

• Perceivable - Information can be presented in different ways; for example, in braille, different text sizes, text-to-speech, or symbols, etc.
• Operable - Functionality can be used in different modalities; for example, keyboard, mouse, sip-and-puff, speech input, touch, etc.
• Understandable - Information and functionality is understandable; for example consistent navigation, simple language, etc.
• Robust - Content can be interpreted reliably by a wide variety of browsers, media players, and assistive technologies.

WCAG 2.0 was published in December 2008, and has become widely adopted as the standard for web accessibility by many businesses and governments around the world. It defines 12 Guidelines under the four POUR principles. Under each Guideline there are more specific Success Criteria divided into three Conformance Levels: A, AA, and AAA. WCAG 2.0 defines 61 Success Criteria.

WCAG 2.1 was published in June 2018, to better address accessibility for people with cognitive and learning disabilities, people with low vision, and people with disabilities using mobile devices. WCAG 2.1 is fully backward compatible with WCAG 2.0, so that if your content conforms to WCAG 2.1 it also conforms to WCAG 2.0. WCAG 2.1 defines 13 Guidelines and 78 Success Criteria.