In this course, Accessibility refers to the conviction that everyone deserves equitable access to the web, regardless of physical or mental disabilities and differences. When we create inaccessible applications and websites, we’re saying “You’re not welcome here” to a significant portion of our users—something we obviously never want to do. When we don’t know the basics of accessibility, it can be easy to lead to inaccessible experiences for our users, even if that isn’t our intention. By understanding the foundations of accessibility and learning to identify when something is inaccessible, we can begin to create products that are considerate, inclusive, and highly effective.

Why accessibility?

Accessible development is one of the places where it can be easiest to fall into analysis paralysis. There’s always something we feel like we need to double-check first, something we heard someone else is doing, or just a vague feeling that we don’t yet know enough to start tackling accessible coding ourselves.

Meanwhile, our websites and applications (and more importantly, our users) are stuck with inaccessible content. Ignoring accessibility is not a solution; even if we aren’t feeling completely confident, it’s still better for us to try than to give up. The best thing we can do is to start writing accessible code to the best of our ability with the acknowledgment that we might make a mistake! After all, that’s how we approach other aspects of development.

We code things to the best of our ability, adhering to the current best practices and web standards. Sometimes we make mistakes—whether those are bugs or architecture approaches we would have done differently in hindsight—but we still ship an application that is (hopefully) functional.

An illustration of a computer window showing the following “</>”
An illustration of a computer window showing the following “</>”

Accessibility is good business sense

A common misconception related to accessibility is that accessible features will only benefit a small subset of our users and are therefore not worth the investment of time and resources. On the contrary, not only are there more users who need accessible features than we might think, but accessibility also improves the user experience for everyone, even those users whom a feature wasn’t built specifically for.

It’s part of our job as developers to create experiences for our users that are enjoyable and that bring users back to our websites and applications over and over again. Good UX (user experience) is more than just a nice thing to do; it's also good business sense. Products that are easy to use and understand will inevitably do better in the marketplace than products that are difficult or unintuitive.

Accessibility requires inclusivity and empathy: the ability to think about and build products for users who are different than ourselves and who have different needs and goals. As we can imagine, that attitude towards development will, by nature, create products that are easier and more pleasant to use. Accessible websites and applications make the Internet better for everyone.

An illustration of a handshake
An illustration of a handshake

Anything is better than nothing

Accessibility is the same. It functions on a sliding scale, not an on/off switch. We code accessible features to the best of our ability based on what we know right now and the current accessibility-related guidance. It might not be perfect 100% of the time, but anything is better than ignoring accessibility entirely. After all, code doesn’t get carved into stone, right? We can always refactor something once we know a better approach. As the old saying goes: “Don’t let perfect be the enemy of good.”

It can be easy to build up the idea of accessibility in our heads into something so large and intimidating that we can always find an excuse for putting it off. But in reality, writing accessible code is just a series of small to moderate adjustments to our development processes, doable by developers of all experience levels. After all, as tech workers, learning new things is just part of the job description! Frameworks, libraries, best practices, trends, and even coding languages themselves change and evolve. Once we start thinking of accessibility the same way and recognize that it’s not an optional upgrade, we can start building accessible development into our existing work processes and patterns.

What we’ll cover in this course

In this course, we’ll begin with the basics and then narrow down to the specifics. We’ll build a firm foundation of what accessibility is and how people use assistive features. Then, we’ll explore the specifics of implementing accessible features in your UIs (user interfaces) and code.

Accessible user interfaces

In this unit, we’ll explore the visual choices that make for accessible user interfaces. We’ll take a deep dive into the world of color, including value and contrast, how to communicate information without relying on color, and how to handle multiple color themes in a single application. Then, we’ll look at the structure of the page itself, including how to lay out a page in an accessible way and ensure it’s still accessible on small screens, the guidelines for fonts and headings, and how to write text that’s clear and understandable.

Press + to interact
An illustration of a hand tapping an icon of a puzzle piece on a tablet
An illustration of a hand tapping an icon of a puzzle piece on a tablet

Accessible HTML

Once we have a firm handle on the visuals, we’ll take a look at the code that makes it all happen. By learning how the browser implements our code and the accessibility tools and features in the browser (such as the accessibility tree), we can gain a fuller understanding of why accessible code makes such a huge difference to our users. We’ll explore semantic HTML, the importance of page titles, how to write accessible forms, and more. Finally, we’ll tackle the infamous WAI-ARIA attributes, something many developers feel they should include for accessibility purposes but aren’t sure exactly how to use.

Press + to interact
An illustration of a computer monitor showing a code editor, where a gear is also shown in the lower right corner
An illustration of a computer monitor showing a code editor, where a gear is also shown in the lower right corner

Navigation without a mouse

Not all of our users will use the web the same way that we do. Many people use alternate navigation systems and assistive technologies to more comfortably get around online. We’ll discuss the different ways our users navigate our websites and applications and then dive into how we can write code that supports (not hinders) these methods.

Press + to interact
An icon of a hand with two fingers extended beside a left and right arrow, depicting a swiping motion
An icon of a hand with two fingers extended beside a left and right arrow, depicting a swiping motion

Alternate ways of presenting information

Unfortunately, everything we want to include in a website or application isn’t going to be fully accessible. Some things, like audio, video, and multimedia, simply cannot be made 100% accessible. However, that doesn’t necessarily mean that those things can’t be included—it just means that we need to find alternate ways to communicate the content to our users. In this unit, we’ll discuss the limitations of certain types of media and what we can do to present information in other ways so that no one is excluded.

An illustration of a head, overlayed with a gear
An illustration of a head, overlayed with a gear

Challenges

In addition to the quizzes at the end of each unit, there are also several coding challenges at the end! These coding challenges will present sample website pages that include many common accessibility mistakes. This is our chance to put what we’ve learned into practice with a real-world situation: identify and correct accessibility mistakes in a codebase.

How to implement what we learn

As in most things, the best approach is to start small and work our way up. Once this course is completed, we recommend focusing on small pieces of a website or application and making them as accessible as possible. This is especially useful if that element is a component that’s used repeatedly throughout the application or website, such as a button. Start by adding accessibility into these small, reusable components and get it for “free” as you scale. Then, when that component is used in other components (and those components in other components, etc.), you’re building on a foundation of accessibility.

This helps the work feel less intimidating. When we look at an entire existing application and think about adding accessibility from scratch, it can feel overwhelming—which means we’re more likely to come up with a reason why we can’t do it. But you don’t have to make the whole application accessible today; today you’re just making an accessible button! Even replacing just the inaccessible buttons across the entire project with accessible buttons is a huge win for our users.

Pick out a handful of the base elements that get used over and over again throughout the website or application. Then, review whether they meet the standards discussed in this course. Consider adding this accessibility upgrade for one component each sprint—or maybe commit to tackling one each week. The most important part is to set a realistic and sustainable pace. It’s far better to get the work done slowly than to burn out before the task is complete.

An illustration of a signpost with arrows pointing in two opposite directions
An illustration of a signpost with arrows pointing in two opposite directions

Accessibility is crucially important and significantly impacts the user experience of a website or application. It might seem intimidating at first, but once we get started, we’ll quickly see that it’s not so scary after all! Accessibility is one of those subjects where it can be easy to spend hours and hours researching—there’s a lot of great accessibility-related content out there! However, make sure not to get stuck in the research phase and put off the actual implementation. Any improvements we can make are better than ignoring accessibility entirely! Break it down into manageable chunks and start implementing some of the ideas from this course.