Web Accessibility Basics for Beginners
Tags: beginners, a11y, codenewbie, webdev
Published: 2023-02-15 05:41:05


*What is web accessibility, why is it important, and why should we start learning about it now when we're just starting ourselves?*

---

Disclaimer: This first blog post in the series will be more philosophical than the other posts in the series. I'll be providing context for the more technical lessons we'll dive into in later posts.

## Why I'm Interested in Web Accessibility

First, you should know that anytime I say "beginner developer," I'm also referring to myself. I began my journey toward a new career in software development recently. I've been drawn toward this field for many years, though. So what started me down this path? Accessibility.

Before programming, I spent seven years working in a college disability resources department. I helped students work around barriers posed by course materials not designed with differing abilities in mind. Those students, in turn, taught me a great deal about what ‘accessibility’ means for users. I discovered how widespread accessibility issues are in the apps and tools many of us take for granted. 

Here's a small sample of the problems my students and I encountered:

-   A publisher's proprietary software students had to use to read their digital textbooks (the only format available). It claimed to be "accessible" but lacked the proper structure for screen readers to navigate effectively.

-   Course management systems that were too cluttered and complicated. This made it difficult for someone with any issues with executive functioning to keep track of courses and assignments.

-   A billion-dollar company's popular statistical analysis software. Users could not adjust the font size of the minuscule numbers on the screen.

In each of these situations, inaccessible technology made life harder for students. Working around these issues created more work for them to get things done. The extra effort needed put them on unequal footing with their peers. For instance, in the last example I shared, the only workaround available for this student with low vision was using the screen magnification settings built into their laptop. This required them to learn a new way of navigating not just the program, but also their computer with the many keyboard shortcuts needed. All this on top of learning statistics (of all the difficult subjects)!

I was frustrated on behalf of my students. Technology was supposedly "the great equalizer," yet it seemed to create more issues than it resolved. Moreover, when working with the vendors, it seemed like all they could offer me were more workarounds and not actual accessibility solutions.

## Why I'm Writing This Blog

With all this, I became curious to learn more about what happens “under the hood” that makes a given piece of technology ‘accessible’ (or not).

Of course, just as if I were to open up an actual car hood to see what was happening underneath, I was perplexed and overwhelmed when I took that first look. How are all these parts connected? How do they work together? Where is that leak coming from? I felt that way as an end user trying to find solutions for my students. I still feel that way now that I have some knowledge of software development, but at least now, I have more context.

I hope to provide you with a better understanding of that context by sharing my thoughts and findings in this blog. I'm learning the nuts and bolts of how this works with you.

Before we go further, let's talk more about what "accessibility" means on the web.

## Accessibility in a Nutshell

To make a webpage accessible is to ensure that anyone can use it, whether or not they have a disability.

As it turns out, people with disabilities constitute much of our potential userbase. The Centers for Disease Control and Prevention estimate that around 1 in 4 adults (26%) in the United States experience a disability. The World Health Organization puts this statistic at 1 in 6 people (16%) worldwide. (See the ['CDC's Disability Impacts All of Us' infographic](https://www.cdc.gov/ncbddd/disabilityandhealth/infographic-disability-impacts-all.html#:~:text=Up%20to%201%20in%204,have%20some%20type%20of%20disability.) and the [WHO's 'Disability' fact sheet](https://www.who.int/news-room/fact-sheets/detail/disability-and-health) for other statistics related to disability in the US and worldwide.)

**Disability** covers the many physical and mental conditions impacting mobility, cognition, independent living, hearing, vision, and self-care. It's a broad category, and there are a wide variety of barriers users with disabilities may encounter when accessing content on the web. Because of this, there is no concrete definition or standard that says, "my page is now accessible." Accessibility is not a one-and-done checklist item but an ongoing process. But, thanks to the World Wide Web Consortium (W3C)'s Web Accessibility Initiative, we do have several helpful guidelines—the [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/) to be precise.

The guidelines themselves are dense and technical, so you don't need to dive too deep down this rabbit hole yet as a beginner developer—for today, know they exist. (As an interim resource, MDN has a set of helpful articles unpacking various aspects of WCAG, [Understanding the Web Content Accessibility Guidelines](https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG).)

However, now is the perfect time to start thinking about WCAG's four user-centered principles of accessibility, also known as POUR.

## Our Goal: Design POUR Websites

To be accessible, our websites should be:
-  **P**erceivable
-  **O**perable
-  **U**nderstandable
-  **R**obust

Let's unpack these principles a bit.

### Perceivable

Users should be able to take in our content even if they're missing one or more of their senses: sight, hearing, or touch (as of this writing, smell and taste are not used on the web—yet...).

Two examples of making content perceivable are providing captions for audio and video content and alt text or image descriptions for visual content.

### Operable

Users should be able to enter inputs and interact with our content regardless of which hardware they use (keyboard, mouse, screen reader, mouth stick, etc.).

One example of making content operable is ensuring that all of a site's functionality is accessible using a keyboard alone. Another consideration would be testing that the site functions as expected in both mobile and desktop environments. We don't want to exclude users whose disability makes navigating the web easier on a handheld device such as a tablet or phone.

### Understandable

Users should easily know how to interact with our site.

Some examples of making content more understandable include using as plain language as possible—particularly when giving instructions on how to interact with the site—laying out content consistently and logically, and ensuring that any interactive elements like forms are labeled clearly and work predictably.

### Robust

Users should be able to interact with our content regardless of which browser, plug-ins, and assistive technology they use.

One example of how this comes up: our users may be most familiar with using their assistive technology in one browser in particular. As developers, we'll want to ensure our content is cross-browser-compatible.

For more information about the POUR principles of design, I recommend looking at the nonprofit accessibility advocacy group WebAIM's library of resources (which you may find easier to digest than the raw standards themselves), including their article [Constructing a POUR Website](https://webaim.org/articles/pour/). I'll revisit these principles as we explore more technical content in the following blogs.

## Conclusion

Programming and web accessibility are both complex. Trying to make sense of either of them on their own can be intimidating. If you're reading this, you're already working through figuring out that programming one. Yet, even though that accessibility piece looks daunting, and we already feel like we have our hands full with just getting our first lines of code to work, as beginner developers we should start wrapping our heads around these concepts now. We want to get into good habits early and make sure everyone can enjoy the things we create. I've learned from experience that it's much easier to make something accessible from the start than to make it more accessible later on. More importantly, accessibility is a crucial design consideration—not a "fix."

With the tools we're learning now, the power to design amazing user experiences is at our fingertips. With that power also comes responsibility. As developers, we are responsible for ensuring that the wonderful things we create are accessible to anyone who might use them.