Untangling The Complex World Of Accessible Patterns
How do we know which patterns are good, better, best when it comes to accessibility? Is it better to use an established pattern/library or create new ones? With the myriad of choices available, we can quickly become caught up in a web of confusion on this topic.
Originally published on Smashing Magazine
March 16, 2021
Marc Benioff memorably stated that the only constant in the technology industry is change. Having worked in tech for over 15 years, I can confirm this. Fellow tech dinosaurs can attest that the way the web worked in the early days is drastically different than many of us could have even imagined.
While this constant change in the technology industry has led to innovation and advancements we see today, it has also introduced the concept of choice. While choice — on the surface — may seem like an inherently positive thing, it does not always equal rainbows and roses. The influx of technological change also brings the splintering of coding languages and the never-ending flavors of programming “hotness.” Sometimes this abundance of choice turns into overchoice — a well-studied cognitive impairment in which people have difficulty making a decision due to having too many options.
In this article, we will attempt to untangle the complex world of accessible patterns — one step at a time. We will kick things off by reviewing current accessible patterns and libraries, then we will consider our general pattern needs and potential restrictions, and lastly, we will walk through a series of critical thinking exercises to learn how to better evaluate patterns for accessibility.
What A Tangled Web We Weave
Overchoice has crept its way into all aspects of technology, including the patterns and libraries we use to build our digital creations — from the simple checkbox to the complex dynamic modal and everything in between. But how do we know which pattern or library is the right one when there are so many choices? Is it better to use established patterns/libraries that users encounter every day? Or is it better to create brand new patterns for a more delightful user experience?
With the myriad of options available, we can quickly become paralyzed by the overabundance of choices. But if we take a step back and consider why we build our digital products in the first place (i.e. the end-user) doesn’t it make sense to choose the pattern or library that can add the most value for the largest number of people?
If you thought choosing a pattern or library was an already daunting enough process, this might be the point where you start to get worried. But no need to fret — choosing an accessible pattern/library isn’t rocket science. Like everything else in technology, this journey starts with a little bit of knowledge, a huge heaping of trial and error, and an understanding that there is not just one perfect pattern/library that fits every user, situation, or framework.
How do I know this? Well, I have spent the past five years researching, building, and testing different types of accessible patterns while working on the A11y Style Guide, Deque’s ARIA Pattern Library, and evaluating popular SVG patterns. But I have also reviewed many client patterns and libraries on every framework/platform imaginable. At this point in time, I can say without qualms that there is an innate hierarchy for pattern accessibility that starts to develop when you look long enough. And while there are occasionally patterns to avoid at all costs, it isn’t always so clear-cut. When it comes to accessibility, I would argue most patterns fall into gradients of good, better, best. The difficult part is knowing which pattern belongs in what category.
Thinking Critically About Patterns
So how do we know which patterns are good, better, best when it comes to accessibility? It depends. This often invoked phrase from the digital accessibility community is not a cop-out but is shorthand for “we need more context to be able to give you the best answer.” However, the context is not always clear, so when building and evaluating the accessibility of a pattern, some fundamental questions I ask include:
- Is there already an established accessible pattern we can use?
- What browsers and assistive technology (AT) devices are we supporting?
- Are there any framework limitations or other integrations/factors to consider?
Of course, your specific questions may vary from mine, but the point is you need to start using your critical thinking skills when evaluating patterns. You can do this by first observing, analyzing, and then ranking each pattern for accessibility before you jump to a final decision. But before we get to that, let’s first delve into the initial questions a bit more.
Is There Already An Established Accessible Pattern
Why does it seem that with each new framework, we get a whole new set of patterns? This constant reinvention of the wheel with new pattern choices can confuse and frustrate developers, especially since it is not usually necessary to do so.
Don’t believe me? Well, think about it this way: If we subscribe to the atomic design system, we understand that several small “atoms” of code come together to create a larger digital product. But in the scientific world, atoms are not the smallest component of life. Each atom is made of many subatomic particles like protons, neutrons, and electrons.
That same logic can be applied to our patterns. If we look deeper into all the patterns available in the various frameworks that exist, the core subatomic structure is essentially the same, regardless of the actual coding language used. This is why I appreciate streamlined coding libraries with accessible patterns that we can build upon based on technological and design needs.
Note: Some great reputable sources include Inclusive Components, Accessible Components, and the Gov.UK Design System, in addition to the list of accessible patterns Smashing Magazine recently published (plus a more detailed list of patterns and libraries at the end of the article).
What Browsers And Assistive Technology (AT) Devices Are We Supporting
After researching a few base patterns that might work, we can move on to the question of browser and assistive technology (AT) device support. On its own, browser support is no joke. When you add in AT devices and ARIA specifications to the mix, things begin to get tricky…not impossible, just a lot more time, effort, and thought-process involved to figure it all out.
But it’s not all bad news. There are some fabulous resources like HTML5 Accessibility and Accessibility Support that help us build a greater understanding of current browser + AT device support. These websites outline the different HTML and ARIA pattern sub-elements available, include open source community tests, and provide some pattern examples — for both desktop and mobile browsers/AT devices.
Are There Any Framework Limitations Or Other Integrations/Factors To Consider
Once we have chosen a few accessible base patterns and factored in the browser/AT device support, we can move on to more fine-grained contextual questions around the pattern and its environment. For example, if we are using a pattern in a content management system (CMS) or have legacy code considerations, there will be certain pattern limitations. In this case, a handful of pattern choices can quickly be slashed down to one or two. On the flip side, some frameworks are more forgiving and open to accepting any pattern, so we can worry less about framework restrictions and focus more on making the most accessible pattern choice we can make.
Besides all that we have discussed so far, there are many additional considerations to weigh when choosing a pattern, like performance, security, search engine optimization, language translation, third-party integration, and more. These factors will undoubtedly play into your accessible pattern choice, but you should also be thinking about the people creating the content. The accessible pattern you choose must be built in a robust enough way to handle any potential limitations around editor-generated and/or user-generated content.
Evaluating Patterns For Accessibility
Code often speaks louder than words, but before we jump into all of that, a quick note that the following pattern examples are not the only patterns available for each situation, nor is the one deemed “best” in the group the best option in the entire world of accessible patterns.
For the pattern demos below, we should imagine a hypothetical situation in which we are comparing each group of patterns against themselves. While this is not a realistic situation, running through these critical thinking exercises and evaluating the patterns for accessibility should help you be more prepared when you encounter pattern choice in the real world.
Accessible Button Patterns
The first group of patterns we will review for accessibility are ubiquitous to almost every website or app: buttons. The first button pattern uses the ARIA button role to mimic a button, while the second and third button patterns use the HTML <button> element. The third pattern also adds aria-describedby and CSS to hide things visually.