What is a11y?

A11y is a numeronym for "accessibility" – the 11 stands in for the eleven letters between the first and last letters of the word accessibility. At its core, a11y's meaning is digital accessibility, just a shorthand for the longer word. In web and software development, a11y refers to building digital products so that people with disabilities can perceive, navigate, and interact with them, typically by following standards like the Web Content Accessibility Guidelines (WCAG).

At a glance

Why is a11y important?

The term a11y is used across developer forums, conference talks, and job titles. This shorthand version gives people a quick, searchable way to flag content as specifically about digital accessibility, rather than "accessibility" in its broader sense, which might mean anything from building ramps to writing plain-language policy documents.

As a result, it’s become a hashtag commonly used by developers and accessibility practitioners, but is now gaining more familiarity outside that community.

The concept behind a11y is what’s important.

According to the CDC, more than 1 in 4 adults (28.7%) in the US have some type of disability, and for many of them, an inaccessible interface is not a minor inconvenience – it can prevent them from completing a job application, booking a doctor's appointment, ordering food online, or even reading a news article.

When you build websites and digital platforms with a11y in mind, you're removing barriers for people who use screen readers, switch devices, voice commands, or keyboard-only navigation – along with people affected by cognitive disabilities, low vision, hearing loss, or limited mobility.

There's also a legal and business dimension.

In many countries, digital accessibility is a legal requirement, not just good practice. Laws like the Americans with Disabilities Act (ADA) in the US – increasingly applied to websites by courts and regulators – and the European Accessibility Act in the EU mean organizations that ignore compliance face a real risk of not just alienating customers but also incurring accessibility lawsuits.

An added benefit is that accessible design tends to produce a better user interface and a better user experience for everyone, not just people with disabilities.

As well as improving the user experience, following accessibility principles can also help designers optimize their pages for SEO, as many elements that make a website accessible to people, such as alt text, also make it easier for search crawlers to parse.

Equal access is the most important goal, though.

A11y asks you to treat access to digital content and services the same way you'd treat access to a physical building or a public service – as something people are entitled to, not a nice-to-have you get to if there's time left in the sprint.

For the disability community, that shift in framing changes when accessibility gets considered during a project, not just as an afterthought – or even completely forgotten.

How does a11y work?

A11y is a practice you apply throughout development, not a single technology or a piece of code you install.

Day to day, that usually means working through WCAG's four principles: content should be perceivable, operable, understandable, and robust.

Those principles cover everything, including text alternatives like descriptive alt text on images, keyboard navigation, consistent navigation patterns, and accessible forms with helpful error messages.

In practice, teams build a11y into their workflow at several points. Semantic HTML is the foundation – using a <button> instead of a styled <div>, for example, gives you keyboard support and screen reader compatibility for free.

Where semantic HTML alone can't describe a complex interactive element, WAI-ARIA attributes fill the gap, adding roles, states, and properties that assistive technologies can read.

Testing is the other half. Automated tools can catch a meaningful slice of accessibility issues, such as missing alt text or poor color contrast, directly in the code editor or the CI pipeline.

Automation is only a first pass, though: manual website QA testing with real assistive technologies confirms a page is genuinely usable.

Accessibility can’t be treated as a single pass at the end of a project. Teams that incorporate a11y into their workflows effectively make sure it’s a part of the practical steps at every stage:

• Reviewing designs for color contrast and focus order before development starts.
• Writing semantic markup and descriptive alt text as components get built.
• Running both automated and manual checks before anything ships.

Retrofitting accessibility into a finished product is almost always slower and more expensive than building it in from the start.

A11y example

A common way a11y shows up in a developer's daily work is through linting. The eslint-plugin-jsx-a11y package, a widely used static checker for React and JSX codebases, checks JSX code for common accessibility issues before it ever reaches a browser.

Consider this button, built with an icon and no accessible label:

<button onClick={handleSubmit}>
  <svg aria-hidden="true">...</svg>
</button>

With the plugin's jsx-a11y/control-has-associated-label rule enabled, this kind of pattern gets flagged during development, prompting a fix like:

<button onClick={handleSubmit} aria-label="Submit order">
  <svg aria-hidden="true">...</svg>
</button>

The second version gives assistive technologies a name for the button, so a screen reader user hears "Submit order, button" instead of an unnamed "button" with no clue what it does.

A11y vs. WCAG

A11y and WCAG aren't competing terms; they describe different layers of the same goal.

A11y is the commitment to maintaining accessibility standards and building inclusive digital experiences that work for the widest possible audience. WCAG is the reference point that turns your a11y commitment into testable requirements. The current version, WCAG 2.2, organizes those requirements around the same four principles covered above.

Most teams use both: a11y as the mindset that shapes decisions early, and WCAG as the checklist that verifies the result.

It's an important distinction when you need to achieve compliance. Compliance is a WCAG question with a defined answer: a given page either meets a specific success criterion at a given level, or it doesn't.

A11y is a broader question about whether real people with disabilities can actually use the product, which a compliance checklist alone can't fully answer.

WCAG conformance at Level AA is often called the gold standard for accessibility compliance, but hitting that benchmark is the floor for good a11y, not the ceiling.

Common mistakes or misconceptions

• Treating a11y and WCAG as interchangeable – WCAG compliance is a strong signal of accessibility, but you can technically pass every automated check and still ship an experience that's confusing or unusable for someone who relies on assistive technology. Passing a checklist and being genuinely usable aren't the same achievement.
• Assuming automated tools catch everything – Automated scanners are useful for finding structural issues at scale, but they can't judge whether alt text is actually descriptive or whether a page makes sense when read aloud in order. You should still use manual testing and get feedback from actual assistive technology users, even in a mature a11y program.
• Treating a11y as a screen reader issue only – Screen reader compatibility is one part of it, but a11y also covers keyboard navigation, cognitive load, flashing elements that can trigger seizures, captioning, and color contrast – among other things. Designing only for visual impairments while ignoring auditory, motor, or cognitive disabilities still leaves a large part of the disability community without equal access.