The best place to start is a Chrome Lighthouse accessibility audit. This will tell us the obvious things to fix. There are 5 problems to fix.
Background and foreground colors do not have a sufficient contrast ratio.
We should make the body color darker until we have at least a 4.5:1 contrast ratio. Otherwise it's difficult to read the text.
Document doesn't have a <title> element
We should add a <title> containing a unique title for this page.
Image elements do not have [alt] attributes
The <h1> contains an image of some text, and it doesn't have any alternative text. This means the title of the page is effectively hidden from screen readers.
There are two possible solutions: either add an alt attribute containing the title text, or replace the image with actual text, using a web font to make it look correct.
Cool trick: you can add &text=mytitle to a Google Font URL and it'll only load the characters required for that text. This is useful if you only need a custom font for a small piece of text like a heading.
Heading elements are not in a sequentially-descending order
The headings on the page jump from h1 to h3, then h4. We shouldn't skip the h2 level just because we prefer smaller titles for the drinks. We should use the right sequential heading levels and style the h2s to be smaller.
<html> element does not have a [lang] attribute
We should add a lang="en" attribute to the page so visitors know it's in English.
There are more accessibility problems that Lighthouse cannot catch automatically.
The nav menu toggle is not usable with the keyboard
We should use a <button> instead of a <div>, as they are focusable and usable with the keyboard by default. They're also announced as interactive by screen readers. It's possible to make this work with a div but you'd need to add a lot of custom JS.
The nav menu toggle has no label
The SVG icons might be obvious to sighted users, but a screen reader user has no idea what the button does. There are lots of ways to add labels. We could put some visually-hidden text inside the button, or add an aria-label to it.
In this case the simplest solution is to label the SVGs themselves, since we're already toggling them when the button is clicked. We can label an SVG by adding a <title> element inside.
The alternative text for the drink images is empty.
Empty alt text is fine for purely decorative images, but you could argue that these images add important information. They show the user how the drink should look, what glass it is served in, what garnish it should have etc. We should add alt text describing these things.
Links have no interactive styles.
There's no indication that the <a> tags are any different to the rest of the text. Links are styled blue and underlined by default—you need some way to indicate to users they can click them.
The CSS also disables the focus outline for links. This makes it impossible for a keyboard user to know when they have focused a link. You may think the default focus styles are ugly, but it's important to replace them with your own styles rather than disable them entirely.
"Read more" links are repetitive
There's no way for a screen reader user to know where each "Read more" link will take them (without listening to the entire href to figure it out). Link text should describe where the link will take the user—avoid generic "click here" or "read more" where possible.
In this case it might make more sense for the link to just be the title, which contains the drink's name.
No way to scroll the carousel with the keyboard
The horizontally scrolling drinks carousel is not controllable via the keyboard. Usually users can scroll the page with the arrow keys, but that doesn't work for scrollable containers.
We can fix this by making the carousel focusable with tabindex="0". Now users can tab to the carousel and use their arrow keys to scroll it.
Learn how different users browse the web to make your sites accessible to everyone.
It's important to remember that the web is for everybody. You should strive to build interfaces that are accessible to as many people as possible. This means specifically including users who often get left out: those with disabilities.
As developers we have both a moral and legal imperative to make sure our applications are accessible. A UI that can only be used by a sighted person with a mouse should be considered broken, just like a UI that isn't usable with a mouse would be considered broken.
This workshop will cover some of the ways disabled users browse the web, how to design/develop to meet those needs, and how to test your code to make sure that it does.
Don't make assumptions about how people will use your site
Strive to make your UI usable by everyone
Get out of your comfort zone when testing your UI
It's easy for developers to forget that people using their apps aren't necessarily like them. This can include both permanent disabilities, temporary disabilities, and even unavoidable technical limitations.
Here are some examples:
A colorblind user cannot perceive the difference between certain colours. If you use only colour to indicate what a button does they won't be able to use it.
A blind user cannot see your UI, and may use screen reader software to have the elements on the page read out loud by their computer. If you only communicate important information visually (e.g. using images) they won't hear it.
A user with a broken arm in a sling cannot use their mouse. If your UI doesn't allow them to navigate with their keyboard they won't be able to use it.
A low-income user may not have the latest iPhone. If your app only works properly on fast, new, expensive devices you are excluding them.
This document will mostly focus on keyboard and screen reader access, since those tend to be the predominant problems for web developers to solve. However that does not mean other disabilities are not important to consider when designing and developing interfaces.
If you're a non-disabled web developer it's possible you aren't aware of or haven't tried navigating the web using anything but your mouse. It's important to get a sense of how other people will be attempting to use the sites you build.
Many users cannot use a mouse, or find it easier to use their keyboard to navigate. This also applies to some visually-impaired users who will struggle to use a mouse if they cannot see the cursor.
You can scroll a web page up or down by pressing the up ↑ or down ↓ arrow keys. You can jump a whole "page" (equal to the viewport height) down with the spacebar.
You can also jump a page up or down using the Page Up or Page Down keys. On Mac keyboards without these keys you can use ⎇ option + ↑ or ↓.
You can scroll right to the top or bottom of a page using the Home or End keys. On Mac keyboards without these keys you can use ⌘ command + ↑ or ↓.
The most important key is "tab" ⇥. This will move your "focus" to the next interactive element on the page. For example links, buttons or inputs. This allows you to quickly jump between these elements, e.g. to fill out a form.
By default a "focused" element has an outline around it (in Chrome this is like a blue glow). You can "click" a focused button or link with the "return" ⮐ or spacebar keys. You can submit a form by pressing return whilst focusing an input.
Try using only your keyboard to navigate while you're reading the rest of this page.
Navigating via keyboard still requires you to know what content is on the page. Visually-impaired and blind people use "screen reader" software to read whatever is on the page out loud.
Most operating systems have a built-in screen reader now. macOS has VoiceOver, Windows 10 has Narrator and Linux has Orca.
Expand the relevant section below to get instructions for your operating system. Once you've got your screen reader working try to use it to navigate this page. It takes a bit of practice to get used to.
VoiceOver (macOS) You can activate Voiceover by pressing ⌘ command + F5 (or opening System Preferences and navigating to Accessibility > VoiceOver > Enable VoiceOver). By default VoiceOver shortcuts use the ∧ control and ⌥ option keys as a modifier. This is referred to as the "VO key" in [the docs](https://www.apple.com/voiceover/info/guide/_1121.html). Useful commands: - control: stop VoiceOver speaking at any time. - control + option + U: open the "Web rotor". Press ← or → to view all the headings/links/form controls etc on a page. - control + option + ← or →: move cursor to previous/next item. - Read more about [the basics of navigating with VO](https://www.apple.com/voiceover/info/guide/_1124.html)
Narrator (Windows 10) You can activate Narrator by pressing the Windows logo key + control + ⮐. By default Narrator keyboard shortcuts use caps lock ⇪ as the modifier key. This is labelled the "Narrator" key in [their docs](https://support.microsoft.com/en-us/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1). Useful commands: - control: stop Narrator speaking at any time. - ⇪ + S: read a summary of a webpage, including links and headings - ⇪ + ↓: start reading the document from the beginning - There are [lots of different ways to read text](https://support.microsoft.com/en-us/windows/chapter-4-reading-text-8054c6cd-dccf-5070-e405-953f036e4a15) so try exploring them.
Orca (Linux) Depending on which Linux distro you're using you may need to install Orca: ```bash sudo apt install orca ``` You should be able to run the `orca` command in your terminal to start it. By default Orca keyboard shortcuts use caps lock ⇪ as the modifier key on laptops. Read more in [their docs](https://help.gnome.org/users/orca/stable/howto_keyboard_layout.html.en). Useful commands: - ⇪ + S: stop Orca speaking. - ⇪ + ;: read the entire document from the beginning - ← or →: read previous/next character - alt + shift + H: show a list of headings - H and shift + H: read next/previous heading - There are [lots of other ways to navigate](https://techblog.wikimedia.org/2020/07/02/an-orca-screen-reader-tutorial/) so try exploring them.
It's important to bear in mind that people don't fall neatly into separate categories. For example lots of keyboard users still use their mouse too. Lots of keyboard users can see the page fine. 85% of blind people have some degree of light perception, and so they may still use visual cues, or their mouse.
Developers sometimes try to detect what "type" of user is on the page, so they can enable/disable certain things (e.g. only show focus outlines for keyboard users). This is almost always a bad idea—you cannot detect accurately, and even if you could it's better to provide as similar an experience as possible to all users.
Web accessibility (often abbreviated to "a11y") is governed by the Web Content Accessibility Guidelines (WCAG). This is a shared standard that includes different criteria you can check your site against.
WCAG is quite long and complex, so a quick way to test a site is to use The A11y Project's Checklist. This is a list of simple things you should do on every site you build.
The A11y Project Checklist
You can also use automated testing tools to catch some types of problems. Chrome comes with a "Lighthouse" tab in the Developer Tools. This can run different types of tests on a page, including "Accessibility". It will inform you of obvious failures like low colour contrast or missing image alt text. However it cannot catch more complex problems, like a custom component that cannot be controlled with the keyboard.
Most importantly you should manually test—use the page in different ways and see if you get stuck. Try to fill out a form using only your keyboard. Turn your screen reader on and see if critical information gets left out. This will help you catch broken interactions that automated tools cannot.
You're going to be identifying and fixing a11y problems on this example page. The page contains 11 failures; try to find them all.
Re-read The A11y Project's Checklist before you start so you can identify obvious WCAG violations.
Don't forget to use Chrome's Lighthouse tab to find easy problems.
You'll have to manually test with your keyboard and screen reader to find some of the issues.
Screenshot of a Lighthouse audit of this website