The product team at Understood is responsible for building digital experiences like websites and mobile apps. But we have an even greater responsibility. It’s our job — our mission — to make our products fully accessible for people with disabilities.

Developers and designers have a shared, global set of accessibility standards. They’re called the W3C Web Content Accessibility Guidelines, or WCAG. These standards act as a toolkit for developers to ensure that users with visual, auditory, motor, and cognitive disabilities have equitable access to websites and applications.

At Understood, our product team considers compliance with WCAG standards a crucial starting point. In fact, we recently joined W3C, the consortium that sets these standards. And we’re excited to weigh in on new guidelines under development that focus specifically on people who learn and think differently.

WCAG is a critical accessibility tool because it gives every web developer around the world shared benchmarks and targets. To define success against shared targets, you need a shared checklist. But when you’re designing for a wide range of people, a checklist has limitations.

Once a website or app has reached the highest level of WCAG compliance, there’s almost always room to improve accessibility even further by putting the person first. We aim beyond compliance to true inclusion.

No part of a user’s life experience is less important than another, and it would be impossible for a user to visit our site without bringing those experiences with them. So that’s our foundation. Because there are so many different ways to interact with our products, we treat inclusion as a mindset and as an ongoing process.

Accessibility as a mindset: Our approach

We build inclusively from the ground up. Our designers and developers try to genuinely internalize the experience of our users, from concept to delivery. That helps us catch potential issues at the outset, so we don’t have to retrofit accessibility features.

We meet the human as a complete person, considering disability one of the many aspects of life that can inform a user’s experience.

At Understood, we focus on supporting the 1 in 5 individuals in the United States with learning and thinking differences. We know that if our products work well for them, they’ll work better for everyone else, too. For example, creating a more accessible experience can also benefit someone who might be in a rush, juggling a child in one arm, or in a heightened emotional state.

Does it “pour”?

The WCAG standards are broken down into four themes, which we remember with the acronym P.O.U.R.

• Perceivable: Can the user find the feature?

• Operable: Can the user interact with the feature?

• Understandable: Can the user identify the feature for what it is, and get the information they need from it?

• Robust: Does the feature function as expected?

Using the P.O.U.R. principles, anyone can start thinking about a feature’s accessibility without needing encyclopedic knowledge of W3C guidelines. We use P.O.U.R. as a shorthand way to gauge whether a feature will be accessible for people with differences and disabilities. This can help us spot areas of opportunity that might not be captured by WCAG.

For example, we once considered adding two features that would provide more content in the bylines of articles. But using P.O.U.R., we determined that more content in a byline would add too much unnecessary information before the body of the article. This could make our primary content less perceivable, especially for someone with ADHD or another learning and thinking difference. It’s possible the user would assume the article required a lot of prior knowledge or a large time commitment. Or they could just lose interest and navigate away.

Although the P.O.U.R. principles are useful for accessibility, we can apply the principles more broadly as a way to consider any reader’s needs. For example, we once considered changing our link style to a reddish highlight, which at first glance seemed to tick all the boxes. It worked from a visual design standpoint, and it met the relevant WCAG standards. However, user research surfaced that this style didn’t quite “pour” for teachers, who associate red highlights with errors and edits. Teachers also happen to make up a large percentage of our audience. So, we reconsidered.

By committing ourselves to being analytical in this way, we widen our definition of accessibility. We meet the human as a complete person, considering disability just one of the many aspects of life that can inform a user’s experience.

Building blocks

We build our digital products piece by piece, like a LEGO construction. So we start testing for inclusion when building the smallest elements on our site — links, text, buttons, toggles, and more.

If these elements “pour” and pass WCAG tests, we feel comfortable combining them into slightly more complex components. And if those components pass the same checkpoints, it’s likely that even more complex ones will pass, too.

Checking our work

It’s important for our team to start the development process by imagining how users might experience a feature. But it’s also critical that we do what we can to find any accessibility gaps once we get to the execution stage.

To gather data on what works best for our users, we’re constantly running usability tests, user interviews, and automated tests of our site. These best practices are also a great way to confirm that our work is inclusive and to find ways to meet the needs of the people who use our site the most.

But we don’t stop there. We work with the Center for Accessible Technology to make sure that whatever we’re putting into the world is as accessible as possible. They use their own software and expertise to run additional checks on our products. And they employ people with different kinds of disabilities to offer feedback on how to make our site work better for them.

The right thing to do — even when there’s no right answer

Inclusive design is an exciting challenge because, beyond the W3C WCAG principles, there’s no one “right answer” for how to be fully inclusive. The technology in this realm is still developing — not to mention the sheer number of audiences to consider.

There’s always room for growth. Cultivating an accessibility mindset isn’t always easy, and it’s not a perfect science. But by combining universal standards with empathy and creative thinking, we can get closer to our goal of building features that work for the wide range of human experience.

Matt Weinberg is a product designer at Understood, focused on design systems, inclusivity, UX, design ops, and recreating the wonder of Web 1.0 in the age of the newsfeed.