The Accessibility Pattern Paradox

Every framework release seems to bring its own set of components, widgets, and patterns. The result is a landscape saturated with options — and a well-documented cognitive phenomenon known as overchoice, where having too many possibilities makes decisions harder rather than easier. For developers building accessible interfaces, this abundance creates a genuine dilemma: stick with established patterns users already know, or craft something new for a more tailored experience?

The answer, unsurprisingly, depends on context. But the goal should always be the same: choose the pattern that delivers the most value to the largest number of people. This is less about finding one perfect universal solution and more about developing a framework for evaluating what works — and what works best — under specific conditions.

Good, Better, Best

After five years of researching, building, and testing accessible patterns — including work on the A11y Style Guide, Deque’s ARIA Pattern Library, and evaluation of popular SVG patterns — an innate hierarchy begins to emerge. Most patterns fall into gradients of good, better, and best when it comes to accessibility. Only occasionally are there patterns to avoid outright.

The challenge lies in determining which category a pattern belongs to. That determination requires critical thinking, not just a checklist. When evaluating a pattern’s accessibility, three foundational questions provide a starting point:

  • 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?

These questions won’t cover every scenario, but they establish a baseline for observing, analyzing, and ranking patterns before committing to a decision.

Why Reinvent the Wheel?

Each new framework tends to spawn its own ecosystem of patterns — a constant reinvention that can frustrate developers and, more importantly, is rarely necessary. Beneath the surface, the core structure of these patterns is largely identical regardless of the coding language or framework wrapper. Just as atoms combine into molecules, the fundamental “atoms” of interface code remain consistent across implementations.

That’s why streamlined libraries built on accessible base patterns are valuable. They allow developers to adapt patterns to specific technological and design needs without starting from scratch. Reputable sources for such foundations include Inclusive Components, Accessible Components, and the Gov.UK Design System, along with the pattern collections Smashing Magazine published.

Once a few base patterns are identified, the next consideration is browser and assistive technology support. Browser support alone is challenging; layering AT devices and ARIA specifications on top adds significant complexity. Yet this step is far from impossible — it simply demands time, effort, and careful thought.

Resources like HTML5 Accessibility and Accessibility Support help bridge the gap. These sites document HTML and ARIA pattern sub-elements, include open source community tests, and provide examples across desktop and mobile browsers and AT devices — giving developers a clearer picture of what will actually work in the field.

Contextual Constraints

After filtering for base patterns and browser/AT support, finer-grained questions about the pattern’s environment come into play. Content management system constraints or legacy code considerations can quickly narrow a list of viable pattern choices down to one or two. Conversely, more flexible frameworks may accept any pattern, shifting focus to making the strongest accessibility choice possible.

Beyond the technical environment, other factors weigh into the decision: performance, security, SEO, translation, third-party integrations, and more. Equally important is who creates the content. The chosen pattern must be robust enough to handle limitations around editor-generated and user-generated content — not just the controlled content a developer might test against.

Patterns don’t exist in a vacuum. They live in browsers, on devices, inside frameworks, and within content workflows. Evaluating accessibility means considering the entire ecosystem — and then making the best call with the information at hand.

Weighing ARIA, Native Elements, And Hidden Text

The following pattern groups are not exhaustive, and the “best” pick within each set is only the strongest of the options being compared. The point of these evaluations is to practice the kind of reasoning you will need when real-world pattern decisions come up.

Button Patterns

Buttons appear on nearly every interface, so they are a natural first case. The first pattern simulates a button with the ARIA role="button"; the other two use the native HTML <button> element, with the third adding aria-describedby and a visually hidden CSS technique for extra context.

Good: role="button"

<a role="button" href="[link]">Sign up</a>

Better: <button>

<button type="button">Sign up</button>

Best: <button> with a visually hidden description

<button type="button" aria-describedby="button-example">Sign up</button>
<span id="button-example" class="visually-hidden"> for our monthly newsletter</span>

The first pattern looks simple, but its accessibility story is more complicated. ARIA role="button" actually has slight advantages in some assistive technology pairings — voice control support in particular — compared to the native element. However, the native <button> has been around since HTML4, is fully supported across browsers, and ships with keyboard interaction, focus management, and activation behavior built in. The ARIA version requires you to implement all of that yourself.

This is where the first rule of ARIA applies: don’t use ARIA when a native element works. ARIA is powerful but risky in the wrong hands. The WebAIM Million report found that pages with ARIA present averaged 60% more errors than pages without it. Adding ARIA does not automatically make a pattern more accessible — it often makes it less so.

The third pattern pairs the native button with aria-describedby pointing at a visually hidden element. It is more complex, but it builds an explicit relationship between the control and additional context about its purpose. When comparing these three options, that added context makes it the strongest choice.

Contextual links provide screen reader users with more information than is visible on screen. The first pattern uses CSS to visually hide supplementary text. The second and third routes use aria-labelledby and aria-label, respectively.

Good: visually hidden text

<p>“My mother always used to say: The older you get, the better you get, unless you’re a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Better: visually hidden text with aria-labelledby

<p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden" id="quote">Read more Golden Girl quotes</span></p>

Best: aria-label

<p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever’s in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

All three patterns render identically on screen, but the code and the assistive technology experience differ. The visually hidden text approach does not create a formal relationship between the link and its descriptive content, so the association is weak. Still, it generally works, which puts it in the “good” category rather than higher.

The choice between aria-labelledby and aria-label is trickier. The W3C ARIA spec says their purpose is the same: providing an accessible name for an object. But aria-labelledby takes precedence when both are present. There is also documented trouble with automatic translation of aria-label content.

That sounds like an argument for aria-labelledby — except the spec also says that when a visible label is not feasible or desired, authors should use aria-label and should not use aria-labelledby. Context matters. For projects without heavy translation needs, and given that aria-label is easier to implement, it edges out aria-labelledby in this comparison.

SVG Patterns

SVGs are code rendered visually, and assistive technology may skip them entirely without an explicit role. Each pattern below includes role="img". The first uses <title> and <text> with visually hidden CSS; the second swaps <text> for <desc>; the third adds aria-labelledby with an ID to the <title> and <desc> elements.

Good: role="img", <title>, <text>

<svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" style="enable-background:new 0 0 511.997 511.997;" xml:space="preserve">
    <title>The first little pig built a house out of straw.</title>
    <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>...
</svg>

Better: role="img", <title>, <desc>

<svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" style="enable-background:new 0 0 511.997 511.997;" xml:space="preserve">
    <title>The second little pig built a house out of sticks.</title>
    <desc>Sadly, he too was eaten by the big, bad wolf.</desc>...
</svg>

Best: role="img", <title>, <desc>, aria-labelledby

<svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" style="enable-background:new 0 0 511.997 511.997;" xml:space="preserve">
    <title id="pig3house">The third little pig built a house out of bricks.</title>
    <desc id="pig3wolf">Thankfully he wasn't eaten by the wolf.</desc>...
</svg>

In the first pattern, the <title> and <text> elements do share a parent SVG element, so there is an implicit association. But testing shows that only 3 of 8 browser/assistive technology combinations heard the full message — despite the W3C SVG spec describing text data as readily accessible to visually impaired users.

The title child element represents a short text alternative for the element... and the desc element represents more detailed textual information for the element such as a description.

The second pattern swaps in <desc>, which mirrors the traditional alternative text and long description model of <img>. Test results are similar — 3 of 8 combinations heard the full message — but that support lands on JAWS, VoiceOver desktop, and VoiceOver mobile, reaching more mainstream assistive technology users. That, plus simpler markup, puts it ahead of the first option.

Adding aria-labelledby to the <title> and <desc> elements in the third pattern pushes support to 7 of 8 browser/assistive technology combinations. The trade-off is that some combinations read duplicated title and description content. Hearing the same information twice is a minor annoyance, though clearly preferable to the alternative of not hearing it at all.

The Cost of Too Many Choices

Having options in technology is generally a good thing, but there is a point where the sheer volume of available patterns and libraries can become overwhelming. When it comes to picking accessible patterns, teams can usually resolve basic questions about library support, browser and assistive technology compatibility, and framework constraints by consulting the right data sources.

The harder questions surface when we shift focus from the patterns themselves to the people using them. The choices we make have direct consequences for whether users can accomplish their goals. As Prof. George Dei puts it:

“Inclusion is not bringing people into what already exists — it is making a new space, a better space for everyone.”

Spending the extra time to evaluate patterns critically and select the most accessible options leads to a more inclusive space that reaches more users on their terms.

Useful Resources

Support and Compatibility Data

Pattern and Component Libraries

Smashing Editorial