Building an accessible future with PatternFly
--
When designing and creating software, it’s easy to imagine the experience of others like yourself. You see the page, understand the context, and can imagine what things might be like for someone like you using it. It’s easy to forget that we’re not all the same though, and often some groups can get forgotten. That’s where accessibility comes in.
The goal of software accessibility is to remove barriers and create inclusive product experiences that work for everyone, regardless of ability. Based on 2019 CDC reports, about 26% of people in the United States alone have a disability, which means that 1 out of every 4 adults has a disability. This group is not as much of a minority as we often imagine.
If you break your arm and it’s now in a cast, you might struggle to use a mouse. Now imagine using your application and trying to continue your work. Would you be frustrated trying to use your keyboard to navigate? Breaking your arm might temporarily disable you, but others live this as their norm. Or perhaps your co-worker suddenly loses his sight, now needing to rely on a screen reader. Would he still be able to keep working on your product? These are everyday considerations that we shouldn’t forget — especially when working with a design system like PatternFly.
PatternFly has often led the way in accessibility within design systems. When building out components for designers and developers to use, conversations have materialized behind the scenes to make sure that these components are accessible to all users. But what does this really mean for a design system, and what does PatternFly do to help achieve this?
Considering all use cases
Usually when someone is talking about accessible web applications, they’re talking about just the site experience alone, not in the context of a design system where a user will take a component and then use it in their own project. When considering accessibility within PatternFly, we have to try to consider all the use cases that someone might use it.
For example, we can’t hardcode labels because we don’t know what you might be using that component to show. Let’s say you have a dropdown component in use. If PatternFly added a label that says “dropdown,” that isn’t exactly very explanatory when used by products. To make it accessible, products would need to put a label describing what that dropdown is meant to show in their usage.
PatternFly works to make the building blocks of a web application as accessible as possible, but users still have to make sure they’re creating an accessible building from those blocks. Someone can give you the wheelchair ramp, but you have to make sure that when you add it to your building, it leads to the front door.
That being said, while we’ve built out these accessible components, we discovered that when you’re constantly progressing forward with development, regressions can happen pretty easily. We were finding it difficult to know where we were accessibility wise. Were we still progressing forward? That’s when we decided to start doing monthly accessibility audits. This way, we could determine exactly where we were on the map so that we could continue to progress forward.
Accessibility audit
When it comes to testing, accessibility testing tools can give you a solid foundation. They point out obvious violations and can lead you in the right direction to make your work accessible.
However, automated accessibility testing is still pretty limited in terms of what it can do just yet, so it’s challenging to know how experience falls when it comes to keyboard interaction and screen readers without manual testing. It also made us decide what screen reader we were going to focus on. Between the top screen readers of NVDA, JAWS, and Voice Over, Voice Over was the obvious choice for us. The majority of our designers and developers work off of Macs, where Voice Over is built in and pretty easy to use, making it the easiest to support of the three. It can be difficult to please all three screen readers, so having a starting point to pinpoint our focus was essential.
With all of this in mind, we broke our audit into three categories of testing: axe testing, keyboard interaction, and Voice Over testing.
- Axe testing: Using axe testing (based on the Axe Browser extension), we tested for clear violations of WCAG standards to give us the base foundation for accessibility.
- Keyboard interaction: Manual keyboard testing showed whether all interactive items are navigable by keyboard. Can a user get there and interact with it?
- Voice Over testing: With screen reader manual testing, we looked for the main considerations: Can you get to it, can you interact with it, and is it clear and understandable to use by each method?
Creating a good user experience
Making something accessible is two fold. First, it’s a question of whether there is an experience available for assistive technology users at all. Is it completely inaccessible and therefore a bug? Or second, is it just a bad user experience and needs an enhancement?
For example, not having a label on a form input could make it inaccessible since the user has absolutely no idea what they’re supposed to enter. Or there could be a label, but it’s just unclear, making it a bad user experience. Going through the PatternFly audit, it was important to make the distinction so that we truly understood all accessibility considerations.
The next step from there is consistency. Do all similar components have the same interaction pattern? We should try to ensure that if they’re expecting an interaction pattern, we don’t throw them off with new controls each time. If you’re a keyboard user and press the enter key on a dropdown toggle, you’d likely expect that same interaction for all similar components.
There is a lot of research out there recommending best practices, but there are definitely times where these are tough questions and require a good bit of discussion and debate over what is the best user experience. Screen readers, in particular, require additional considerations. Screen reader users can’t get the context of the page visually the way that sighted users can, making it essential to have good page structure, semantic HTML, and content that is clear and descriptive without being overwhelming.
Addressing our findings
So how did we address what we found?
A design system’s accessibility issues can be segregated into three different categories: issues with the components themselves, the examples presented, and the composition of the page as a whole.
When prioritizing issues found, we first and foremost care about our components. If it’s in our control, it should be accessible. Then we prioritize our examples and our documentation pages as a whole. Showing consumers the accessible way to handle each use case is extremely helpful and increases the likelihood of proper accessibility in products.
We added the ability to automate axe testing and added an axe validation check to the CI Build ensuring that every addition to our code gets tested by axe first. All issues were recorded and prioritized, we evaluated current documentation and labeling, improved the structure of all of our pages, and took on specific component accessibility issues. Since we finally know where we are on the map, we can ensure that we’re moving forward. Every day we’re taking steps forward to be as accessible as possible.
A work in progress
There’s still more progress to make, and we’ll keep working towards the ideal in the accessibility field. We’ll continue auditing where we are, working through issues, evaluating new code, and communicating about accessibility.
Our goal is to bridge the gap between PatternFly accessibility and product accessibility. We prioritize making our components accessible, but our next step from there is to empower our users to use these components in accessible ways. We care about our users. Whether you’re using your mouse, your keyboard, or a screen reader, PatternFly will always work towards giving you the best user experience possible.
Have a UX story of your own? Send your ideas our way. More writers and fresh perspectives can only make PatternFly’s Medium publication stronger.
