Web Accessibility 101. A Gentle Introduction

A couple of weeks ago I knew close to nothing about accessibility. I had a rudimentary sense of what it means but past that nothing applicable. I’m still miles away from any kind of mastery but here is some cool stuff I learned that will give you an introduction and a way to start making your website more accessible. Being aware of accessibility will make each one of us a more thoughtful developer.

With the web invading every facet of our life, accessibility(also known as a11y) becomes even more important to be aware of. Although this is not a new concept, — Web Content Accessibility Guidelines(WCAG) were first published way back in 1999 — a lot of people are only now learning about it.

So what is web accessibility?

Web accessibility means that people with disabilities can use the Web

The above statement, simple as it may sound, advocates for a great vision and possible future, where literally everyone will be able to benefit from what the Internet has to offer*.* If you don’t suffer from some kind of disability you might take your ability to access the Web for granted. But for a substantial percentage of the population, this is not the case. Some ever-changing statistics further prove this point. It is estimated that around 3.8 million in the US alone have some kind of visual disability and that is not counting other forms of disabilities. 217 million people worldwide have moderate to severe vision impairment and about 15% of the world’s population has some sort of disability, making accessibility an issue that affects literally millions of people. WebAIM conducted a study only to find that close to 98% of the top 1 million websites don’t offer full accessibility. All the above and more contribute to the widening of the “digital divide”.

The good news is that the web is inherently accessible, giving us all the options and tools we need. The bad news though is that we as developers often lack the knowledge to apply them.

Making your Code be Heard

People with a visual impairment will most likely use a screen reader to navigate through the Web. Making our code available to interact with screen readers will make a world of difference, making users able to interact with a website. What screen readers actually do is pick up on the information we provided from the elements in our code.

Besides reading the main content of a webpage, images are too part of the main content. The alt text in an img tag exists to provide some context of what one would see in the image even if they can’t actually see it, and that is what screen readers read. If you have puppies, you could provide some descriptive alt text like “Cute little puppies play with each other under a tree in the grass”. Saying just ‘puppies’ is not very helpful since it doesn’t give any kind of context. Alternatively, if you want your screen reader to skip the alt text to can just leave it as an empty string.

// Screen reader will catch on this
<img src="..." alt="Cute little puppies play with each other under a tree in the grass" />

// Screen reader will skip this
<img src="..." alt="" />

Similarly you want to provide a label tag to every input element in a form. Every label tag accepts a for attribute that corresponds to an input’s id. Alternatively you can wrap the label around the input and omit the for and id relationship.

<form>
  <label for="name">Name</label>
	<input type="text" id="name" />

	<label for="age">Age</label>
	<input type="number" id="age" />
</form>

// wrapped label
. . .
	<label>
		Name
		<input type="text" />
	</label>
. . .

In general, you want anything that is important in your website to be labeled even if the label tag is set to hidden.

Semantics

A common ‘anti-pattern’ is using div elements for everything. And I say that in quotes because there are websites out there that use div elements for everything yet the website is very accessible. They went on to do extra effort to mimic the accessibility functionality of other elements. We will see an example later on.

We often take this approach because these types of elements have no styling, where in fact we shouldn’t have thought of markup being responsible for styling in the first place. Similar tags that have no accessibility functionality are the header, footer, and aside. The button, input, and textarea do have accessibility functionality out of the box sort of speak.

We might get in the habit — as many design systems and libraries do — to abandon native elements and fix their own from scratch using other elements to make them more customizable or due to design decisions. But what this does is lose some accessibility functionality that is provided from these native elements.

div’s are not focusable so a screen reader can’t read them. If you wanted, for whatever reason, to make a div behave just like a button and be detectable as well, then you would use the role property. This will change the semantic meaning of the div element to be of button.

<div role="button">I pretend to be a button</div>

In order to be selectable, we can add the tabindex property. Adding tabindex makes an element focusable.

<div tabindex="0" role="button">
  I pretend to be a button
</div>

Note: tabindex takes three kinds of values:

• Negative(-1) which means it should be focusable but not reachable via keyboard. (You might use JavaScript instead)
• 0 means it is reachable via keyboard depending on its order and where it is placed
• Positive means this element will be prioritized, no matter where the element is placed in the DOM. You can think of this, similarly to how z-index works

But we are not done yet. Unlike the button or input elements that can be used alongside the label tag, a div element can’t. So here is where aria-label comes to play. By adding it gets a label-like functionality like so.

<div aria-label="I want to be a button" tabindex="0" role="button">
  I pretend to be a button
</div>

Since this is not really a button you have to define your events to handle the enter and space key to mimic the button’s behavior.

aria-label add’s a label to something. The aria-labelledby does exactly the same thing but it can link by id. This is handier if you have a very long description and you don’t want your label to be overblown.

// short label
<a aria-label="Visit John's Twitter Profile" href="/twitter.com/john">
  My Twitter Profile
</a>

// long label
<div class="visuallyhidden" id="aria-id">Visit John's Twitter Profile. It is extra good and juicy.</div>
<a
	arialabelledby="aria-id"
	href="/twitter.com/john">
		My Twitter Profile
</a>

Note: You will probably need to hide the div element so it makes sense to use some kind of generic class for that like visuallyhidden. Anything you don’t want to be visible you push it out of the screen.

You can read more on how to use ARIA on MDN which has thoroughly detailed documentation.

Live Regions

Another important accessibility feature is live regions. What this does is make screen readers read again parts of the page that have been updated. Either it is a notification or someone liked your post, a screen reader must be able to catch this kind of behavior. To do so you can use the aria-live.

<div aria-live="assertive">This might take a few minutes . . .</div>

// after a while
<div aria-live="assertive">Form submited successfully</div>

When the content inside the div changes, the screen reader will read it again. Passing the value assertive will make the screen reader stop everything it does and read it, while the polite value will wait until the screen reader is finished and then it will read the now changed content.

Skip Link

When you first visit a webpage often times you have the navigation on top that stays the same throughout the site. If you press the Tab key to navigate the page users might find it tedious to press the tab key 30 times — depending on your navigation items —, to find the main content of each page. The skip link is a technique that is often used to take you to the main content skipping the repetitive stuff. You can do so by appending an a tag that is hidden at the top of your body element that targets the main content through an id. Usually, you will see this being placed at the top left of the screen with the first Tab stroke when you land on the page.

Tab Trapping

This is a useful way to limit the screens readers reach. For example, if we have some kind of modal with a form we wouldn’t want the user to navigate outside the modal in another place in the website.

For further reading: Designing for Keyboard Accessibility | Accessible Technology

Visual Considerations

An accessible website is not only for people who can’t see. The Internet is not being primarily used by people who have perfect vision or no vision, but instead, there is this huge range where a lot of people have some kind of visual impairment. Some might have a very limited field of vision due to a disability, so it would make sense to have anything that is relative to each other to be close to each other and not scattered across the screen(for instance, having a call to action on the left side of the screen and a possible error or warning on the right corner). That is one case. Some will see a text of color red on a black background blurry and so on.

Some people might be sensitive to motions and animation happening on the screen, like if they have a condition that causes seizures. Many of them will most likely have to configure their system to bypass those kinds of behaviors in their environment. You can detect that with the prefers-reduced-motion CSS media feature and adjust your code accordingly and have this kind of functionality in the Web as well.

Final Thoughts and Further Reading

All the above by no means cover everything, but some version of the Pareto principle holds true here as well. If you apply 20% (even less) of what is out there accessibility-wise your users will benefit greatly(more than 80%). Remember that a small ripple goes a long away, so go on and help someone today.

Introduction to Web Accessibility | Web Accessibility Initiative (WAI) | W3C

A11y Coffee

Microsoft Design