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:

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.)

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

Click Here Learn More

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:

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:

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:

See also the W3's Web Accessibility Evaluation Tools List.

🌎 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

👁 Visuals

👤 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.

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.