Coding With Accessibility In Mind 101

One of the biggest mistakes in development is not making your website or app accessible from the beginning.

Many reasons are given, from it "not being in the budget" to "we don't need it for the MVP". The reality is that it should be done from the beginning. Not only are you excluding people from being able to interact with your content, but it can be more costly to revise inaccessible code later down the road. It's a complex topic with a lot to cover, so this post will not be an end-all-be-all. However, I'd like to encourage developers to learn the basics of a good foundation for building an accessible website or app, as well as questions to consider when reviewing their work.

😳 What is Accessibility?

Accessibility means ensuring your website or app is accessible (i.e. able to be used) by all users, regardless of how your website or app is accessed. These are some examples of questions to ask yourself:

Can blind users navigate with screen readers?
How about visually impaired and color-blind users?
If your app has videos, it there captions for deaf and hard-of-hearing users?
Should you add audio readings if your app features many articles?
Is it easy to navigate through keyboard for those with neurological disorders that make using a mouse difficult?
Likewise, if they use a mouse but have shaky movements, can they still click what they intended?
Is your site usable even without javascript?
Is it usable for communities without access to fast internet speeds?
Do images have alt text? (for screen readers and sight impairments)
Is the design high contrast enough? (sight impairments)

These apply not just to people with disabilities, but the elderly and temporarily disabled as well. Approximately 1 in 5 people have some kind of disability.

There is a large umbrella of users who fall under this umbrella with varying needs to be accounted for, and unfortunately a much smaller number of apps built with accessibility in mind.

Click here to understand the standards for accessibility set by the W3C.

In the dev community, accessibility is often referred to by A11y.

🔎 Getting Started: The Bare Bones

Using the right foundation for your code can help make your website or app usable by most right from launch. You can expect to receive specific issues reported by users, but it will be easier to tackle those cases as they come than if the whole site has numerous issues.

👏 Semantic HTML

Using the correct semantic HTML is the foundation for building accessible apps out the gate. (See: What are semantic elements?) Instead of binding a route action to a div, use a normal link. Forms should always be wrapped in a <form> element, as well as the header, footer, nav, articles, the main body, buttons, captions, and so forth. This also includes using header tags in the correct order (h1, h2, h3, etc.) to maintain the correct structure of the content. This not only helps the browser identify what elements can be tabbed by a keyboard, but also lets a user using a screenreader navigate more quickly to what they are looking for. (Don't underestimate what plain HTML and CSS can do! Read the article HTML Can Do That? for examples.)

⚠️ An Important Note About Link and Button Text

Link and button text should appropriately and clearly label the intended action.

❌ Poor Link Text

Click Here Learn More

✅ Better Link Text

Our Policies and Procedures Learn How To Submit a Claim

⚠️ An Important Note About Alt Tags

Often people understand they need an alt tag on an image, but then use them inappropriately. They are not meant to simply label the image with an image name; they are intended to describe the image to someone who cannot see it.

❌ Poor Alt Text:

A woman and a baby.

✅ Better Alt Text:

A woman with long brown hair holds her baby close to her chest, looking down at her child lovingly while they sit in the grass outside beneath a sunny sky.

A picture is worth a thousand words, but if they can't see the picture, you need the words.

Unfortunately with dynamic images, it can be difficult to get good alt tags or captions for images, particularly when user generated. Always allow users to add their own captions to their images and give them tips on how to write appropriate alternative text.

⚠️ Labeling an SVG

The easiest way to label an SVG is to edit the <svg></svg> content to include a title tag.

<title>This will display as alt text for an SVG</title>

🏷 ARIA Labels

ARIA (Accessible Rich Internet Applications) can help improve your HTML further to streamline a user's example. However, semantic HTML is always preferred. Here are a few common uses:

aria-hidden="true": aria-hidden will hide an element from screen readers. This is useful to add to elements which may contain content that is not useful for those on a screen reader, or if you have a screen reader only alternative with more helpful text.
aria-label="Close": aria-label gives a spoken label for an element. This is useful if you have a button with only an x button to close a window and wish it to have a more helpful instruction for screen readers.
title="Go To Statistics": title is similar to aria-label, and often used on links. This can be used to give more helpful text to describe a link than what is wrapped in the <a> tag.
role="button": role can give an element the same options as its semantic counterpart. However, this is strongly discouraged. You should always use the semantic element instead when possible.

There are many other ARIA attributes that can be used. While these are helpful to know, it's also important to understand that different tools may utilize these attributes accordingly. (See: Title and Aria-label Attribute Accessibility Use Case) For more, read ARIA - When HTML Simply Isn't Enough, as well as the sections on Good and Bad Practices.

Watching How A Screen Reader User Accesses The Web is also recommended. Smashing Magazine also publishes numerous articles about accessibility that are helpful reading.

⌨︎ Browsing With a Keyboard

Testing your site with a keyboard is fairly simple to do yourself. You'll want to be sure of the following:

Can you navigate through the page with your tab key, and in the ideal order?
Can you submit a button, link, or form with the enter key?
Can you navigate (open, close, click a link) the menu, both mobile and desktop?
Can you navigate through a select dropdown appropriately?
Can you backtrack?
Can you use the esc key to close a modal?
If there's a video or audio, can you play it? Pause it? Forward/Rewind?
Should they be able to tab through sections quickly, and can they?

For more on using a keyboard, see How to Browse Websites Using a Keyboard Only.

📋 Doing an Accessibility Audit

There are multiple ways to run an audit on your app. There is no one tool that checks everything, and while they can spot obvious mistakes and errors, do not take it as a final truth. Use multiple checking options, resolves errors and warnings the best you can, and do your own testing. Feedback from users who actually use the internet with a screen reader, keyboard, or with other impairments is immensely valuable and should not be overlooked.

Bookmarklets:

Websites:

🌎 Inclusivity Considerations

What does it mean to make your app "inclusive"? Making all users feel welcome, seen, and understood. Having an accessible app is part of the equation, but there are many contributing factors.

💬 Language

Are you using common terminology for the intended audience?
Can text be translated?
Are labels and button text clear by text alone?
Are captions on videos correct?

👁 Visuals

When using images or colored graphics of people, is it a diverse group? (gender, race, etc.)
Are icons meaning clearly understood without any text?
Is the layout clear for different color-blind variations? If using green and red for "good" and "error", this is especially important for those who can't distinguish between green and red. Adding icons can help add visual clarity without relying on color.

👤 Gender

We often default to simply male/female as gender options, but this excludes some users. If you're transgender, do you put the one you identify as? What should someone nonbinary or intersex put? While this data might be valuable for statistics, you're getting an inaccurate picture from this confusion. Also: is it really necessary? If you are asking their gender for the sake of a user profile, it may be helpful to ask their pronouns instead.

Consider a product listing site. If a user isn't comfortable using their real face as a photo and/or their name (or their name is gender neutral) but need to be contacted about a sale, it will make both the user and the messenger more comfortable to know how to address them. Help your users avoid being misgendered and the awkwardness of a correction.

Male: He/Him
Female: She/Her
Nonbinary: They/Them (Most common, but other nonbinary pronouns exist and may vary by culture – allowing a "custom" option is a great addition!)

Additionally, consider checking your app's copy for gender-coded language. While this has become a hot topic for job listings, it is a good practice to get into if you want your app to be available to all gender identities.

💯 Remember: Accessibility is a Team Effort

It can seem a lot to remember, especially if you're only starting out. Make a checklist for yourself, and take things one piece at a time as you work. Once you master the basics reliably, be curious! Ask others and do your own research on how you can make the experience of using your app or website better for everyone.

But most importantly, remember you are only one developer. It takes a team to build a great accessible app, and you should hold one another accountable to learn these important foundations and strive to do even more. Having one person on the team be the "accessibility expert" (often because it's relevant to them personally) is an easy trap teams fall into and places a heavy burden on one individual to know everything. Do not let your team do the same. Share knowledge and ensure every team member learns and utilizes it. When using a framework, addon, or plugin, check their documentation to see if they have accessible features already built in you can utilize.

This post cannot possibly cover every resource out there, but I hope it has helped shine a light on where one can start.

Let's build apps that are accessible for everyone! 👏

This post was originally published on the Kohactive blog.