Accessibility
tutorial html a11y- Disclaimers
- IRL Accessibility
- Why is accessibility important?
- Empathy
- Disabilities
- Accessible Devices
- W3C, WAI, WCAG, ARIA
- Improving Accessibility
- Testing Accessibility
- Summary
- Learn More
Now you know how to use HTML to build a website, and how to use CSS to style that website. You might even know how to use JavaScript to make your website interactive, although thatâs not a strict prerequisite for this guide.
This guide introduces a concept called accessibility, which is the idea that your website should be usable by everyone, including folks with vision, motor, and neurological disabilities. This guide also introduces a few techniques you can use to make sure your website is as accessible as possible.
Disclaimers
Before we dive into accessibility, I want to say that Iâm still learning about this myself. Iâm especially self-conscious about talking about disabilities, because I donât want to accidentally say something hurtful or ignorant. Iâve tried my best to research the right way to talk about things, but I recognize that I might get something wrong. When thatâs the case, please help me learn by letting me know.
Iâll also mention that Iâve tried my best to make Happy Coding as accessible as possible, but I definitely havenât fixed every bug. If you notice something, feel free to let me know.
IRL Accessibility
Before we talk about web accessibility, take a second to think about accessibility in the real world.
Youâve probably seen accessible devices in real life before. Here are a few examples:
- Wheelchair ramps that help wheelchair users enter a building.
- Brail signs that help people who are blind understand whatâs around them.
- Pedestrian crosswalks that help people cross the road.
- Side note: these can be a great example of accessibility! At a single crosswalk you might see a curb cut instead of a step, patterned markings on the ground, and auditory signals in addition to visible lights and signs.
One thing worth noting is that many accessible devices improve the experience of everyone. For example, wheelchair ramps also help people pushing a stroller or a cart, or people who have difficulty climbing stairs.
Why is accessibility important?
Accessibility is important for a few reasons:
1. Itâs the law.
Many laws exist with the goal of preventing discrimination against people with disabilities. Historically, these laws were about peopleâs behaviors and the physical world: businesses generally need to provide an entrance thatâs accessible by folks using a wheelchair, for example.
But more recently, these laws have grown to include not just human behavior in the physical world, but also technology like websites and computer applications. In other words, there are laws that require your website to be usable by everyone. This includes folks with disabilities that prevent them from seeing the screen or using a mouse and keyboard. Companies have been sued for having websites and apps that arenât accessible!
2. Itâs good for your webpage.
Accessibility is not just the law, it also benefits your page directly. Exactly like installing a wheelchair ramp in the real world makes it easier for everyone to enter a building, making your website more accessible improves the experience of people with disabilities, but it also improves the experience of everyone else as well.
For example, you might increase the size of buttons on your page to make them easier for people with vision disabilities to click on. Congratulations, you also made them easier for everyone else to click on as well! How often have you been annoyed trying to click a tiny button when youâre browsing the web on your phone? Fixing accessibility issues improves your site for all of your users.
Search engines generally prioritize accessible sites, which is another way that accessibility benefits your page.
3. Itâs good for you.
Because of this (and the threat of being sued), accessibility is a popular topic in the tech industry right now. Being able to talk about accessibility in an interview improves your chances of getting a job, and understanding accessibility can help you after you get a job. So accessibility is also good for you!
3. Itâs good for the people who use your site.
Iâve listed the above reasons because theyâre all true, but for me personally, thatâs not why I care about accessibility. I care about accessibility because I care about people.
That might sound a little melodramatic, but I think about it this way: who am I building my webpage for? Is it only for people who look like me? Only for people with the exact same abilities as me? Or am I building it for everyone?
For example, I know that every time I upload an image without alt text, Iâm making it harder for people who are blind to use my site. Why wouldnât I want to fix that?
The answer to that question is generally either âI donât know how to fix itâ in which case this guide is meant for you! Or itâs âI donât have time to fix itâ in which case Iâd encourage you to think about the people at the other end of that equation.
Empathy
I donât want to belabor the point too much, but I honestly believe that the most important takeaway I can offer is a sense of empathy for the people using your website. Seeing your users as people is more important than understanding semantic HTML and ARIA attributes, because that sense of empathy is harder to look up. W3Schools doesnât have a tutorial on caring about other humans.
With this in mind, I strongly encourage you to learn more about the experiences of people with disabilities.
W3.orgâs User Stories is a good place to start. I also recommend checking out Tommy Edisonâs videos.
Empathy Challenge
To really put yourself in the shoes of somebody with a disability, try this challenge:
- Take out your phone
- Enable the screen reader (see below for how)
- Familiarize yourself with your screen readerâs functionality
- Now use your screen reader to use an app that you use often. How does Twitter or Instagram work with a screen reader? Can you use the app with your eyes closed?
- Now use your screen reader to use your website.
How did that work? How did you feel? What was easy or difficult about the experience?
Disabilities
To understand accessibility, it can help to think about the different types of disabilities people using your page might have. Here are a few examples:
- Color blindness. What does your site look like for folks with different types of color blindness? Are you using good contrast?
- Limited sight. What does your site look like for folks with vision issues? What happens when you zoom in or increase the font size?
- Blindness. How does your site work with a screen reader?
- Deafness. Do any videos on your webpage have captions?
- Limited mobility. How does your site work with keyboard navigation, or a switch device?
- Neurological disorders like dyslexia and ADHD. How does your site work for folks who think differently than you do?
- Injuries. If I injure one of my hands, can I still use your page?
I hope these examples get you thinking about the different kinds of contexts people bring to your webpage. And remember that improving accessibility makes your site easier to use for everyone! For example, increasing the size of the buttons on your page will make your site more usable for folks with limited mobility, while also making it more usable for folks viewing your site on a small mobile device, or for folks wearing gloves who canât click on tiny buttons. Everybody wins!
See Diverse Abilities and Barriers for more examples.
Accessible Devices
Now that you have a rough idea about some of the disabilities folks might have, letâs talk about the ways that might impact how they use your site.
Screen Readers
Screen readers do pretty much exactly what it sounds like they do: they read the screen. This is especially handy for folks with sight-related disabilities who might not be able to see whatâs on the screen themselves.
Most computers and phones come with a screen reader. Try enabling yours now!
- On Android, enable TalkBack and then go through the TalkBack tutorial
- On iPhone or Mac, enable VoiceOver for iPhone or VoiceOver for Mac
- On Windows, enable Narrator and then go through the Narrator tutorial
You can also install the Screen Reader Chrome extension. Itâs a little incovenient because you canât turn this extension off without uninstalling it. But this is what I use most often for testing screen reader behaviors.
Switch Devices
Switch devices let users interact with a computer using a button or switch. This is especially handy for folks with limited mobility, who canât use a keyboard or mouse.
Keyboards, Mice, and Screens
You might not think of these as accessible devices, but I might argue that theyâre the most common accessible devices in the world! People with disabilities use these devices all the time.
W3C, WAI, WCAG, ARIA
The world of accessibility has a lot of acronyms- starting with accessibility itself, which is often abbreviated as a11y! (There are 11 letters between the a and y.)
This can be pretty confusing, so here are a few youâll see pretty often.
- W3C is the World Wide Web Consortium, which is the organization that decides how the web should work. They decide on new HTML tags and CSS rules, among many other things! Read more about W3C on Wikipedia.
- WAI is the Web Accessibility Initiative, which is the part of W3C that works on accessibility. They publish recommendations for how to improve your websiteâs accessibility, as well as proposals for changing the web itself. Read more about WAI on Wikipedia.
- WCAG is the Web Content Accessibility Guidelines, which are the recommendations put out by the WAI. Read more about WCAG on Wikipedia.
- ARIA is Accessible Rich Internet Applications, which is a set of HTML attributes that help improve your contentâs accessibility.
- Note: You only need ARIA attributes if you have content thatâs not already accessible. See the semantic HTML section for more info.
Improving Accessibility
If youâre new to accessibility, you might be expecting a list of rules you can follow to make sure your site is accessible. But it doesnât really work that way! Because there are so many different ways your website might work, a lot of accessibility is subjective: how hard is your site to use? How painful is it for the people using it?
In other words, accessibility isnât an either-or, yes-or-no thing. Instead of asking yourself âis my site accessible?â, Iâd encourage you to think about it as a spectrum: How accessible is my site? What about it is hard to use, and how can I improve that?
This can be a little frustrating, especially if youâre used to the very precise nature of writing code. So with that said, here is a list of things you can do to improve your siteâs accessibility.
Semantic HTML
HTML tags tell a browser what type of content to display: an <h1>
tag is a heading, a <button>
is a button, etc. This is called semantic HTML, because the HTML itself conveys meaning. Accessible devices also rely on semantic HTML tags to know how to behave: a screen reader might let a user navigate by headings, or a switch device might let a user click on buttons on the screen by pressing a physical button.
Itâs also possible to create elements using <div>
tags. Letâs say you wanted to create a custom button: you could start with a <div>
tag, and then add some CSS to make it look like a button, and some JavaScript to do something when the user clicks it.
But <div>
tags donât supply any meaning, other than an arbitrary division of content. If you use CSS to indicate that a <div>
should be treated like a button, it might be obvious to sighted users that they can click on it. But it wonât be obvious to screen reader users, because the screen reader wonât announce the content as being clickable.
Hereâs an example with non-semantic HTML:
See the Pen by Happy Coding (@KevinWorkman) on CodePen.
View the non-semantic HTML example fullscreen.
Try opening that page and using a screen reader to navigate and click the button. It doesnât really work, because the screen reader doesnât recognize that the divs represent headings and buttons!
Hereâs the same example with semantic HTML:
See the Pen by Happy Coding (@KevinWorkman) on CodePen.
View the semantic HTML example fullscreen.
Try this version of the page with a screen reader. Now navigating by headings works, and the button is announced as a button!
Itâs fine to use tags like <div>
when you want to group some content without adding any meaning to that grouping. But whenever you want to communicate meaning to your user, use semantic HTML tags rather than arbitrary tags like <div>
or <span>
.
If you canât use semantic HTML, see the aria-role
section below.
Alt Text
Images are another pain point for screen reader users. A sighted user can look at the image to know what it is, but blind users have to guess.
Hereâs an example that uses images without alt text:
See the Pen by Happy Coding (@KevinWorkman) on CodePen.
View the images without alt text example fullscreen.
Try opening that page and using a screen reader to read the contents. Because the images donât have alt text, the screen reader reads out the file name, which isnât very helpful!
Instead, you can improve an imageâs accessibility by providing an alt
attribute, like this:
<img src="cat.png" alt="A cat frolicking through some red flowers." />
Hereâs the same example with alt text added:
See the Pen by Happy Coding (@KevinWorkman) on CodePen.
View the images with alt text example fullscreen.
Try this version of the page witha screen reader. Now the experience is a lot more meaningful!
If you canât provide an alt
attribute, see the aria-label
section below.
Empathy challenge: Try navigating a photo or video-centric app like Twitter, Instagram, or TikTok with a screen reader. What percentage of posts contain alt text?
ARIA Attributes
In situations where you canât use semantic HTML or provide alt text, you can add special attributes that provide extra information to accessible devices. You can read more about ARIA attributes on MDN, but the two attributes youâll see most often are:
aria-label
The aria-label
attribute is meant for situations where you have an interactive element like a button, whose content is an image, where that image does not have any alt
text.
Hereâs an example without ARIA labels:
See the Pen by Happy Coding (@KevinWorkman) on CodePen.
View the buttons without ARIA labels example fullscreen.
Try opening that page and using a screen reader to click one of the buttons. Because the images donât have alt text, the screen reader reads out the file name, which isnât very helpful!
Hereâs the same example, this time with ARIA labels:
See the Pen by Happy Coding (@KevinWorkman) on CodePen.
View the images with alt text example fullscreen.
Try this version of the page with a screen reader. Now each button is announced with the right label!
You donât always need to specify the aria-label
attribute. If a button contains text, or contains an image with alt text, then you donât need to specify the aria-label
attribute. ARIA attributes are for situations where you canât otherwise provide the information.
role
The role
attribute is meant for situations where you canât use semantic HTML. There are many available ARIA roles, like heading
, dialog
, and button
. Use these when you have a non-semantic element thatâs acting as a semantic element, and you canât use the semantic element for some reason.
Hereâs an example with non-semantic HTML without any role
attributes:
See the Pen by Happy Coding (@KevinWorkman) on CodePen.
View the non-semantic HTML example fullscreen.
Try opening that page and using a screen reader to navigate and click the button. It doesnât really work, because the screen reader doesnât recognize that the divs represent headings and buttons!
To improve this, you can add role
attributes to each of the non-semantic elements:
See the Pen by Happy Coding (@KevinWorkman) on CodePen.
View the ARIA role example fullscreen.
Try this version of the page with a screen reader. Now the headings are treated as headings, and the button is announced as a button.
Note: You should only need to use a role attribute if for some reason you canât use semantic HTML.
This is bad, because it uses a non-semantic tag to represent a heading, and doesnât specify the heading role:
<div>This is a heading!</div>
This is better, because it provides the role
attribute so accessible devices will recognize it as a heading:
<div role="heading">This is a heading!</div>
This is best, because it uses a semantic tag and doesnât need a role
attribute:
<h1>This is a heading!</h1>
Focus Behavior
Many accessible devices rely on the focus to interact with a webpage. To see what I mean, try pressing the tab key on your keyboard right now. That should move the focus to the next focusable element- probably a link or a button. Press tab again to move the focus to the next focusable element, or press shift+tab to move the focus to the previous focusable element. Press the enter key to interact with a focused element.
This is how people interact with webpages and other applications without a mouse. Many accessible devices rely on the focus behavior as well, which makes it very important to get right.
If your focus behavior is wrong, you might see situations where the focus moves to off-screen elements, or where you canât focus an on-screen element, or where elements are focused in the wrong order. You can often fix focus issues either using semantic HTML or by adding a tabindex
attribute depending on how you want an element to behave:
tabindex="-1"
means an element canât be focused by the user. This is often used on hidden elements that will become visible later.tabindex="0"
means an element can be focused by the user. This is often used for non-semantic elements like<div>
tags that wouldnât otherwise be focusable.tabindex="1"
(or any other positive number) means the element can be focused after any elements withtabindex="0"
. This is generally discouraged, and you should place your elements in your HTML in the order they should be focused.
The focus should also be visible, so you can write CSS that changes the focus styling, but you shouldnât hide it.
Sizing and Spacing
Links and buttons that are too small can be hard to click. Youâve probably experienced this yourself if youâve ever tried to browse the web on a small mobile devices. This is even more difficult for people with mobility issues.
See the Pen by Happy Coding (@KevinWorkman) on CodePen.
View the tiny buttons example fullscreen.
With that in mind, WCAG recommends that clickable elements are sized at least 44x44 pixels. This is mostly for elements like navigation links and interactive buttons- elements like inline links can be the same size as the surrounding text.
Similarly, elements that are too close together can be hard to click. WCAG doesnât have an official spacing recommendation, but generally, 12 pixel spacing is a reasonable minimum.
See the Pen by Happy Coding (@KevinWorkman) on CodePen.
View the big buttons example fullscreen.
Contrast
If your background color and your text color donât have enough contrast, your text can be hard to read. Here are some examples:
This is especially difficult for people with vision-related disabilities. That doesnât mean you canât change the colors in your webpage, but you have to make sure the colors you choose have enough contrast to be readable. Here are some examples:
If you donât know whether your colors have enough contrast, you can plug them into WebAIMâs contrast checker to make sure.
Testing Accessibility
How do you know if your site is accessible? Like I mentioned above, parts of accessibility are subjective: How usable is your site? So I wouldnât think about it in terms of a binary, yes-or-no question: is my site accessible? Instead, I would think about it as a more open-ended set of questions: How accessible is your site? What pain points do different users have? This is why I talked so much about empathy at the beginning. Putting yourself in other shoes goes a long way towards answering these questions.
But with that said, here are a few things you can do to test your siteâs accessibility.
Manual Testing
Start by testing your site yourself. How usable does your site feel?
Look for things like focus behavior, sizing and spacing, and contrast.
Try using your site with a screen reader. Can you do everything you can with a keyboard and mouse? How painful is it?
It can also be really helpful to get other people to use your site. Whatâs obvious to them? Whatâs not obvious to them? Whatâs easy or difficult? Whatâs confusing?
Developer Tools
Your browser comes with a powerful set of developer tools that help with debugging and getting more information about your webpage- or any webpage!
These developer tools include accessibility checkers that scan a webpage and let you know about certain accessibility issues. These wonât catch everything, but theyâre a good partner to manual testing.
On Chrome, you can use Lighthouse. On Firefox, you can use Accessibility Inspector.
Try running your developer toolâs accessibility checker on this website right now!
Accessibility Scanner
Android offers an Accessibility Scanner app that can scan apps and websites to generate accessibility reports. Try installing it and scanning the apps you use, this website, and your own website!
Note: Iâm not as familiar with iPhone, so let me know if thereâs an equivalent app on iPhone!
Again, these automated checkers are not an alternative to manual testing, but they can help steer your way.
Accessibility Checklist
Like Iâve said a couple times, accessibility is not an either-or, yes-or-no box that you can check. Itâs more subjective: How does your site feel? How inconvenient is it for users of accessible devices? What pain points do your various users face?
So there isnât really a set of specific, technical rules that I can give you to make sure your site is accessible. The best thing I can suggest is to approach your design with empathy. How do your decisions affect the people using your site?
But with all of that said, here is a very rough list of steps I follow when Iâm trying to improve a siteâs accessibility:
- Check out the code.
- Are you using semantic HTML? If not, are you providing ARIA attributes?
- Do all of your images have alt text or ARIA labels?
- Manually test your site with a mouse and keyboard.
- How usable is your site with a mouse and keyboard? What pain points can you fix? If your site isnât usable with a mouse and keyboard, it wonât be usable with accessible devices!
- Are interactive elements and buttons at least 44x44 pixels, and spaced 12 pixels apart?
- Do the background and foreground colors have enough contrast?
- Is the focus behavior reasonable? You should be able to focus on every interactive element, in a reasonable order, without focusing on off-screen elements.
- Can you use your site using only a keyboard, without a mouse?
- Manually test your site with a screen reader.
- Can you do everything you can do with a keyboard and mouse?
- How does it feel to use a screen reader? What parts of your site are annoying or broken with a screen reader?
- Use your developer tools to test the site.
- What issues are detected? Fix them, and use them as hints for what to manually test.
- Try other automated accessibility checkers, like Androidâs Accessibility Scanner.
- Understand that there are people on the other side of your webpage. Put yourself in their shoes, and try to understand how they use your site.
Summary
Accessibility might feel intimidating, especially if you havenât though much about it before. But remember that the most important concept in accessibility is not knowing which HTML tags to use or what styling to add- itâs having empathy for the people who use your site.
A little empathy goes a long way, because it lets you understand your site from the perspective of the people who use it, even if they donât look like you or have the same abilities as you.
Although "edge case" is unintentionally so right on because if you are the user with the edge case, you experience this digital precarity where your access is routinely destabilized and off you tumble from the platform #ethicalCS
— Chancey Fleet đđ©â𩯠(@ChanceyFleet) September 27, 2018
Learn More
Comments and Questions
Happy Coding is a community of folks just like you learning about coding.
Do you have a comment or question? Post it here!