Principle Of Web Accessibility

#webdev #beginners #css

## Quick Summery

An accessible product can be daunting to build, particularly during development, if accessibility isn’t considered from the beginning. At times, it can feel like throwing random ARIA attributes at the wall to see what sticks. There’s so much nuance and technical depth to consider that many find it easier not to consider it at all. However, this article will demonstrate three keys for approaching and developing accessible content without making you feel lost in the weeds.

How many times have you heard this when asking about web accessibility?

It’s something we’d like to do more of, but we don’t have the time or know-how.

From a broad perspective, web accessibility and its importance are understood. Most people will say it’s important to create a product that can be used by a wide array of people with an even wider range of needs and capabilities. However, that is most likely where the conversation ends. Building an accessible product requires commitment from every role at every step of the process. Time, priorities, and education for all involved, so often get in the way.

Performing an accessibility audit can cost a lot of time and money. The results can cost even more with just design, development, and QA (Quality Assurance). An audit becomes even more expensive when considering the other heavy investment. For every role, the learning curve for accessibility can be steep.

There’s so much nuance and technical depth when learning about web accessibility. It’s easy to feel lost in the trees. Instead, this article will take a look at the forest as a whole and demonstrate three keys for approaching accessibility naturally.

The POUR Principles Of Web Accessibility

It may sound too simple, but we can break web accessibility down into four core principles: Perceivable, Operable, Understandable, and Robust. These principles, known as POUR, are the perfect starting point for learning how to approach accessibility.

PERCEIVABLE

What does it mean for content to be perceivable?

Let’s say you’re experiencing this article by reading it. That would mean the content is perceivable to people who are sighted. Perhaps, you’re listening to it. That would mean the content is perceivable by people who engage with content audibly.

The more perceivable your content is, the more ways people can engage with it.

Common examples of perceivable content would be:

Images with alternative descriptive text,
Videos with captions and/or subtitles,
Indicating a state with more than just colour.

A terrific real-world example of perceivable content is a crosswalk. When it is not safe to cross the street, there is a red icon of a standing figure and a slow, repeating beep. Then, once the streetlights change and people can cross safely, the icon changes to a green figure walking, and the beeping speeds up. The crosswalk communicates with understandable icons, colours, and sound to create a comprehensive and safe experience.

OPERABLE

Operable content determines whether a person can use a product or navigate a website.

It is common for the person developing a product to create one that works for themselves. If that person uses a mouse and clicks around the website, that’s often the first, and sometimes the only, experience they develop. However, the ways for operating a website extend far beyond a traditional mouse and keyboard.

Some important requirements for operable content are the following:

All functionality available by mouse must be available by the keyboard.
Visible and consistent keyboard focus for all interactive elements.
Pages have clear titles and descriptive, sequential headings.

UNDERSTANDABLE

What good is creating content if the people consuming it can not understand it?

Understandable content is more than defining acronyms and terms. A product must be consistent and empathetic in both its design and content.
Ways to create an understandable experience would include:

Defining content language(s) to allow assistive technologies to interpret correctly.
Navigations that are repeated across pages are in the same location.
Error messages are descriptive and, when possible, actionable.

ROBUST

In a way, many of us are already familiar with creating robust content.

If you’ve ever had to use a compiler like Babel to transpile JavaScript for greater support, you’ve created more robust content. Now, JavaScript is just one piece of the front end, and that same broad, reliable approach should be applied to writing semantic HTML.

Ways to create robust markup include:

Validating the rendered HTML to ensure devices can reliably interpret it.
Using markup to assign names and roles to non-native elements.

The POUR principles of web accessibility lay a broad (if a bit abstract) foundation. Yet, it can still feel like a lot to consider when facing roadmaps with other priorities.