I’ve heard this pronounced like alley, like ally, as a-eleven-y, or as a-one-one-y.
I’ve not yet found concrete evidence that the a11y numeronym was in use before the founding of Twitter, but I wouldn’t rule it out. Regardless, the numeronym was certainly propelled into widespread usage thanks to Twitter’s 140-character limit of old — shaving accessibility’s 13 characters (roughly 9% of 140) down to four characters (roughly 3% of the limit) is certainly enticing.
In long-form prose, I try to avoid abbreviations where possible, including a11y, since I generally hold that abbreviations are more often for the writer’s benefit than for the reader’s. Unless a11y appears in a proper name (such as The A11Y Project, the #a11yTO conference, or Pa11y), I prefer to write out accessibility in full, and generally recommend others do the same.
That said, I still think a11y makes for a useful hashtag on social media — as Eric Bailey points out, searching for accessibility can get you a wide range of results, stretching the meaning as vague as general approachability, whereas searching a11y tends to pull up accessibility practitioners.
While the term is most often used to refer to tooling that was specifically designed for disabled people to use, such as screenreaders or wheelchairs, in its broadest sense, assistive technology can refer to just about anything that makes disabled people’s day-to-day lives easier regardless of the intention behind the design. For instance, password managers might not have been designed with disabled people in mind specifically, but the fact that they help mitigate strained memory or help people skip past potentially cumbersome typing, alleviating pain points that disabled people in particular might face when setting up secure passwords, means that password managers could very well be considered assistive technologies for some people.
In computing, assistive technologies come in several flavors:
Sometimes, assistive technologies are a bring-your-own affair, such as when people use their screenreaders on a site. Other times, the assistive technology will be supplied by the user experience itself, such as captions for video content.
]]>Having sufficient contrast between two colors especially benefits low-vision or colorblind readers. On the other hand, extremely bright colors and high contrast can trigger migraines.
Color perception is fundamentally subjective. However, from a testing perspective, it is useful to have a more concrete determination of contrast that we can point to decide whether two colors are too low contrast to be used together. Color contrast algorithms are mathematical formulae which output contrast ratios, numerical representations of the contrast between two colors. Contrast ratios are used as benchmarks for contrast-centric accessibility requirements.
Currently, the industry standard (and, in jurisdictions which require WCAG adherence, the legal standard) for measuring color contrast is the WCAG 2 color contrast algorithm. The WCAG 2 formula outputs ratios ranging from 1:1 (comparing any color with itself) to 21:1 (comparing black and white).
Other contrast algorithms do exist — most notably, APCA, which was once in the WCAG 3 draft specification but was removed from the draft in . APCA differs from the WCAG 2 formula in that it takes more factors into account, such as font weight and size, as well as which color is the foreground and which is the background. If you want to use a contrast algorithm such as APCA, you can do so, but given WCAG is a legal standard in many jurisdictions, I would recommend treating any non-WCAG algorithms as supplementary to the WCAG formula, rather than as a wholesale replacement.
Success criteria marked as Level AA are part of the industry and legal standard that most sites are held to.
Success Criterion 1.4.3: Contrast (Minimum) ensures text has sufficent contrast against its background. Success Criterion 1.4.11: Non-text Contrast ensures that UI controls and necessary graphics have sufficient contrast against their background. Because text tends to be smaller and more intricate, text has a higher standard it needs to meet.
Success Criterion 1.4.3: Contrast (Minimum) (Level AA)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:
- Large Text
- Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
- Incidental
- Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
- Logotypes
- Text that is part of a logo or brand name has no minimum contrast requirement.
Success Criterion 1.4.11: Non-text Contrast (Level AA)
The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):
- User Interface Components
- Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
- Graphical Objects
- Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
Most teams and sites are not held to Level AAA conformance, but it may still be worthwhile to consider whether Level AAA criteria are right for your site. The Level AAA Success Criterion 1.4.6: Contrast (Enhanced) increases the standards for both text and non-text content compared to the Level AA criteria.
Success Criterion 1.4.6: Contrast (Enhanced) (Level AAA)
The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following:
- Large Text
- Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;
- Incidental
- Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
- Logotypes
- Text that is part of a logo or brand name has no minimum contrast requirement.
Identity-first language follows English’s convential word order, putting the disability-adjective before the person-noun.
Examples include:
Proponents of person-first language (also called people-first language or PFL) try to mention the person-noun before describing the disability, often by using a relative clause. Nominally, this is to distance the person from their disability.
Examples include:
This is a can of worms.
From what I’ve seen, most disabled people are either unaware that this has even been a conversation, or don’t have a strong preference.
When disabled people are opinionated on the topic, the impression I’ve gotten is that advocacy for person-first language feels like it comes from the outside, from nondisabled people aiming for allyship, and very rarely does it come from disabled people directly. Something worth noting here is person-first language’s proponents’ implicit assumption that disabled people would want to be distanced from their disabilities. Because of this, I will most often describe disabled people with identity-first language (though, if it fits the flow of the sentence better, I will use person-first here and there).
When referring to an individual with a known, stated preference one way or another, use that approach. To that end, I’d prefer to be referred to with identity-first language — or, at very least, I would prefer people not feel like they would need to awkwardly rework a sentence to accommodate person-first on my behalf.
If you don’t know an individual’s preference and can’t ask them, one thing you can do is see if any self-advocacy groups (i.e., groups explicitly composed of the group you’re trying to describe) have a lead you can follow. For instance, the National Federation of the Blind and the Autistic Self-Advocacy Network both advocate for identity-first language. While disabled communities are never a monolith, self-advocacy groups are likelier to have their thumb on the pulse for how individuals broadly feel on a given issue.
In United States digital accessibility case law, nexus is a strong connection between a digital experience such as a website or mobile app and the goods and services offered by a physical, brick-and-mortar public accommodation. Nexus is a test that American courts commonly use when determining whether businesses’ sites or apps are legally required to be accessible.
For most private businesses in the United States, the closest thing we have to a digital accessibility law is the Americans with Disabilities Act (ADA) — in particular, the ADA’s Title III, which lays out accessibility rules for public accommodations (specifically and significantly, for the full and equal enjoyment of the goods, services, facilities, privileges, advantages, or accommodations of any place of public accommodation
). Enacted in 1990 (but amended in 2008), the ADA’s Title III does not directly mention digital services. It does not even truly define public accommodation, except to provide a list of representative examples.
This means that courts have had to weigh in on whether websites and apps count as public accommodations for the purpose of the law. Courts disagree on this matter, and their opinions generally fall into three camps:
That third opinion is the most common one for courts to hold. For these courts, then, disabled plaintiffs would need to prove that there is a strong connection between a business’s website or application and the goods and services offered at a physical, brick-and-mortar establishment — in other words, that there is nexus between the two.
A strong, clear example of the nexus test could be grocery stores which allow you to place orders online for pickup. Pickup orders are a service of a place of public accommodation, but an inaccessible site or app could prevent a disabled user (including arguably many of the people who could benefit most from a pickup order service) from taking full advantage of the service.
In many cases, the site or app could just be one way out of several to access the goods and services, and yet courts might hold that nexus applies. For instance, the Ninth Circuit Court of Appeals held that Domino’s Pizza was required to make their site accessible, even though ostensibly many would-be customers could place orders in person or over the phone instead. The website was just one means of several for placing orders, and yet, because it provided an avenue to the goods and services of Domino’s brick-and-mortar locations, the Ninth Circuit Court of Appeals held that there was sufficient nexus.
On the other hand, courts that require nexus generally won’t rule that digital services without customer-facing brick-and-mortar establishments need to be accessible.
Screenreaders are most commonly used by blind and low-vision people, though they can also be used by anyone who struggles to read page contents, such as dyslexic readers.
While they are often conflated for each other, screenreaders and text-to-speech software are distinct products. Text-to-speech software generally focuses just on announcing text contents aloud. Screenreaders expose the whole enchilada: text contents, images’ alternative text, page structure, element states, and more. Additionally, screenreaders provide their users with more ways to navigate an application, such as skipping to landmarks or navigating between elements of a similar type. Additionally, screenreaders can provide their own modes for inputting information back into the application.
Depending on your operating system, the best-known screenreaders are:
Owing to its adoption as an industry standard, WCAG also often forms the basis for legal web accessibility requirements in many jurisdictions around the world, and courts often require adherence to WCAG as remediation steps following lawsuits.
The current version of the Web Content Accessibility Guidelines is WCAG 2.2, which became the W3C Recommendation in . Before that, WCAG 2.1 became the standard in , supplanting WCAG 2.0, which had been made the standard in .
Owing to the pacing of legal processes and case law, different versions of WCAG are the standard in different jurisdictions, but at this point, you can be reasonably confident that if a legal requirement points to WCAG, it will point to some 2.x version.
WCAG 3 exists purely as a very early draft version, and is likely many years out still. WCAG 3 is expected to substantially restructure requirements and what it means to meet them.
The Web Content Accessibility Guidelines have a hierarchical structure. They are first divided into overarching principles. Each principle is divided up into guidelines. Guidelines are further broken up to success criteria — the pass/fail requirements most web developers will find themselves working in. Success criteria are grouped up by conformance level, and WCAG helpfully provides some sufficient techniques that could be used as possible ways to meet the requirement.
The Web Content Accessibility Guidelines are broken up into four overarching principles: broad, north-star ideals about what it fundamentally means for web content to be accessible in the first place. These principles are:
Collectively, these principles are remembered with the mnemonic POUR.
Where WCAG’s principles mark broad, north-star ideals about accessibility, its guidelines make more specific assertions about what a user should actually expect. For instance, while the Principle 2, “Operable,” asserts that disabled people should generally be able to use an interface, Guideline 2.1: Keyboard Accessible asserts that part of making interfaces operable is ensuring that all functionality is usable via the keyboard.
Guideline 2.1’s numbering indicates that it is the first guideline to fall under the second principle (“Operable”).
Guidelines are further broken up into success criteria: the actual pass/fail requirements of WCAG. These are specific, testable assertions about how a webpage should work.
For example, the Guideline 2.1: Keyboard Accessible includes Success Criterion 2.1.2: No Keyboard Trap, which requires that:
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
This is testable; if in using a page with the keyboard, your keyboard focus gets stuck on a piece of the page with no clear or familiar way out, then the page fails this criterion.
Success Criterion 2.1.2’s numbering marks it as Guideline 2.1’s second success criterion.
As testable, pass/fail requirements, accessibility auditors and automated testing tools will generally point to specific success criteria when surfacing defects on a site.
Each success criterion is assigned a conformance level from among Level A, Level AA, and Level AAA, levels which generally go from most basic/fundamental (“A”) to loftiest (“AAA”).
The industry standard and most frequent legal standard is Level AA conformance. This means that Level AAA criteria are often treated as nice-to-haves, though it is absolutely worth evaluating whether any Level AAA criteria make sense for your experience or audience.
While success criteria assert binary pass/fail claims about what a given page/site must or must not do, they do not generally prescribe how web contributors should go about meeting the requirement.
That said, the Web Content Accessibility Guidelines documentation does provide informative resources that might be helpful for web contributors trying to address its requirements.
One such resource type is its Understanding documents. Each guideline and success criterion has its own Understanding page, which clarifies the intent behind the requirement, and provides possible ways to test for that requirement. For instance, Success Criterion 2.1.2: No Keyboard Trap’s Understanding document, Understanding No Keyboard Trap, explains whom the requirement is intended to benefit and describes a few examples of web experiences that could satisfy this requirement.
WCAG also lists sufficient techniques — approaches one could use to address a given success criterion. Technique G21 is one such example, providing several mechanisms a site could lean on for ensuring a user’s focus doesn’t get stuck somewhere without recourse, which would result in a Success Criterion 2.1.2: No Keyboard Trap failure. If a web contributor finds a different approach for meeting the criterion, then great! That works, too.
Finally, WCAG lists possible failures, describing certain UX patterns that would violate a given success criterion, with context as to why. For instance, Failure F10 notes that when multiple applets or content formats are mixed and matched, an overreaching plugin could trap the user in a given context with no way out, which would fail Success Criterion 2.1.2: No Keyboard Trap. This isn’t the only way the criterion could fail; just one way that it might.
]]>display: nonevisibility: hiddenheight: 0 and width: 0Browsers assume these elements are meant to be hidden for everyone, especially since toggling a style like display: none tends to be a more performant way to remove and reveal content than deleting the element and rebuilding it. As a result, browsers take these styles as indications to remove that content from the accessibility tree. In solely HTML land, the hidden attribute does the same thing.
But what if you want to hide content visually, but still expose it to assistive technologies? Visually-hidden styles (sometimes referred to as screenreader-only styles) are CSS rules which make an element invisible, similar to display: none, without removing it from the accessibility tree.
The version of .visually-hidden I’m currently using looks like:
.visually-hidden:not(:focus):not(:active) {
border: 0;
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
white-space: nowrap;
width: 1px;
}These rules hide the element by making it only a single pixel big and then clipping away that overflow. Because the element is still in the document order and, if applicable, could still be focused, this utility does not apply the changes if the element is currently focused or being followed as a link. For a more thorough breakdown, see The anatomy of visually-hidden by James Edwards on the TPGi blog.
This utility class has gone by other names through the ages. .sr-only (short for “screenreader-only”) is particularly common, especially thanks to its use in libraries such as Bootstrap (now using “.visually-hidden” as of Bootstrap v5) or Tailwind. Additionally, WordPress calls it .screen-reader-text and Drupal used to call it .element-invisible.
The following are a few common uses for visually-hidden styles. In some of these cases, using visually-hidden styles can be a hack for which it might be nice to have a more robust approach, but seeing as those approaches don’t necessarily exist yet, visually-hidden styles are the practical reality we have today.
Interactive controls such as buttons need accessible names, which will get announced by screenreaders when the user navigates to them, and which voice control users can use to target the controls with their commands. Usually, controls like links and buttons get their accessible names from their text contents. However, icon-only buttons don’t have text contents, meaning they lack an accessible name.
One way to remedy this is with an aria-label attribute, as in this sample markup for an “x” close button:
<button aria-label="Close">
<svg aria-hidden="true"> <!-- “x” icon --> </svg>
</button>This works perfectly fine for most sites! However, it introduces a tradeoff that might be an issue for some sites: aria-label does not reliably auto-translate and it might get missed in manual translation workflows, too. If internationalization and localization are priorities for your particular site, you might not want to lean on aria-label for populating buttons’ names like this.
Instead, you might opt to stick a visually-hidden node inside the button:
<button>
<svg aria-hidden="true"> <!-- “x” icon --> </svg>
<span class="visually-hidden">Close</span>
</button>aria-hidden NodeGenerally, we want to avoid micromanaging screenreader pronunciations, especially since many overrides make the user experience worse for braille display users and voice control users. This said, sometimes we might find that we do really need to replace some contents with a screenreader-friendlier alternative. One way we can do this is with a one–two punch of the visible but aria-hidden node with the visually-hidden, screenreader-friendlier node:
<span aria-hidden="true">
★★★☆☆
</span>
<span class="visually-hidden">
3 out of 5 stars
</span>Note: Sometimes, developers will try to resolve this by placing an aria-label on the static text node, such as <span aria-label="3 out of 5 stars">★★★☆☆</span>. However, unless you’re overriding the node’s role as well, using aria-label on most static text elements is invalid and therefore not well supported.
Skip links are same-page links designed to help keyboard navigators bypass hefty sections of the page. Most commonly, they’re used to skip over the main site navigation, which is generally repeated on every page, to get the user directly to the main page contents.
There’s no requirements that skip links should be hidden, but many sites opt to hide their skip links and reveal them when they get focused, so as to not clutter the experience for non-keyboard navigators. display: none would prevent the link from being focusable/
If you hide your skip links, make sure your visually-hidden styles do not hide the links when they’re focused. Otherwise, keyboard navigators wouldn’t be able to tell what they’re focused on or what it would do.
Developers can use live regions to trigger ad hoc screenreader announcements. However, live regions can be finicky, and so commonly, this takes the form of a single, global, page-wide live region. Given that such ad hoc announcements are generally meant to reinforce status updates that sighted users can see visually, devs generally opt to hide the global live region and leave it screenreader-only.
<div aria-live="polite" id="polite-announcements" class="visually-hidden">
</div>
<div aria-live="assertive" id="assertive-announcements" class="visually-hidden">
</div>Note: This use case could be addressed someday if the imperative ariaNotify API proposal ever lands. If and when it lands and is widely supported, sites could invoke ariaNotify() to trigger announcements on demand, without the need for any live region markup.
The name of the effect refers to curb cuts, the places where a sidewalk gradually slopes into the street. These were originally established in places like Kalamazoo, Michigan and Berkeley, California to enable wheelchair users to cross the streets and make their way around town. As a result, cities found that many pedestrians were making use of the curb cuts—skateboarders, cyclists, parents with strollers, people with carts or suitcases. Something instated with one group’s needs in mind had benefitted the general public along the way.
A more technological example of the curb-cut effect can be found in captions, which are ostensibly written for deaf and hard-of-hearing people, but which also benefit people with auditory processing disorder, people in noisy or public spaces where hearing media would be impractical or where turning up the volume would be rude, or people studying a language who could use further reinforcement of what’s being said.
I often see people bring up the curb-cut effect when they’re making the business case for investing in accessibility. The intent is to counter the notion that accessibility is pandering to a small, obscure minority, by demonstrating that more people can and will benefit as well.
This is a good thing! However, sometimes when people bring this up, they can do so in a way that I think can be self-defeating in the long run: by suggesting that it’s “not just” disabled people who stand to gain from accommodations or inclusive design. In other words, the advocacy can, by accident, incidentally reinforce the idea that benefitting “only” disabled people isn’t sufficient justification to invest in accessibility, but rather that accessibility still needs to benefit nondisabled people for validation.
Pitching accessibility features as general-purpose can also dilute the features’ usefulness for the disabled people they were built for in the first place. For instance, alternative text is generally intended for blind and low-vision users, who access the images’ alt text with their screenreaders. In recent years, social platforms have taken to giving everyone a chance to read the alt text without the need of specialized tooling, by way of an “ALT” badge/
In practice, design systems consist of any or all of the following:
A communication tip
If you ask five people what a design system is, you’ll get seven different answers. That said, people will often use the term “design system” to refer to just the parts they interact with — so a developer might refer to a component library as “the design system,” where a designer might use “the design system” to refer to the UI kit from their design tool of choice.
Information that might be found in an accessibility statement includes:
Animations can pose an accessibility issue on the web for people with vestibular disorders, who can find them severely nauseating, dizzying, or migraine-inducing. Some animations can trigger epileptic seizures. Neurodivergent people can find them particularly distracting or overstimulating. For affected users, animations can be disruptive at best and outright unsafe at worst. When properly supported, the reduced motion setting puts control back in the hands of these users.
“Reduced motion” does not necessarily mean “no motion.” Rather, it typically means that unnecessary animations will be disabled, and whichever animations remain are made less dramatic where possible. On many sites, however, animations serve as uncritical flourishes, and in these cases, it might be worth considering just turning off all animations altogether when reduced motion is active.
In CSS, we can detect whether reduced motion is active with the prefers-reduced-motion media feature:
@media (prefers-reduced-motion: reduce) {
/* Reduced motion is active */
}
@media (prefers-reduced-motion: no-preference) {
/* Default: Reduced motion is either not active or not a supported setting */
}Here, there are really two main patterns developers could take with these media queries:
@media (prefers-reduced-motion: reduce) media query to unset or tone down the animations.@media (prefers-reduced-motion: no-preference) media queries. This means that on the off chance that a user is visiting your site from a device or browser that doesn’t support a reduced motion setting, the site will default to the safest option of having no animations.These media queries will only impact animations and transitions that have been set in CSS. JavaScript-based animations should also respect reduced motion preferences, and can do so with a window.matchMedia() check.
Low-vision users might find forced colors mode useful for setting all webpages in a high-contrast palette. Meanwhile, people with migraines might use forced colors mode to set a muted, less stimulating, low-contrast palette. The fact that some people prefer to set lower-contrast themes is why accessibility practitioners, browsers, and operating systems have moved away from calling these features “high-contrast mode” over the past few years.
In some cases, users will access forced colors mode through their browser’s settings. In other cases, the user enables forced colors mode at the operating system level. On Windows, for instance, they could enable contrast themes, formerly known as Windows High Contrast Mode (WHCM). Other operating systems (I’m at least aware of Ubuntu and Android) have similar functionality. After enabling the OS-wide setting, the browser will pick it up and apply it to webpages automatically.
CSS allows developers to modify how a webpage appears in forced colors mode. When doing so, remember that the goal is to add clarity where it might have been lost, not to try to force your own aesthetic preferences or branding.
To check if forced colors mode is enabled, use a forced-colors media query:
@media (forced-colors: active) {
/* Forced colors mode is enabled */
}
@media (forced-colors: none) {
/* Forced colors mode is not currently enabled */
}In some limited cases, the exact original color of an element really matters, such as product swatches or chart legends. In this case, you can use the forced-color-adjust property to opt a particular element out of forced colors mode styling:
/* Default. Element will take on forced colors mode styles. */
forced-color-adjust: auto;
/* Element will not take on forced colors mode styles. */
forced-color-adjust: none;
/* Used to enable `currentColor` (or similar) in contexts such as SVGs */
forced-color-adjust: preserve-parent-color;When forced colors mode is active, elements’ colors are remapped to system colors, named color variables whose values have been set at the browser or operating system level. Other defined colors, such as those set with hex codes, color functions, or the transparent keyword, will generally be ignored by default (save for messing with forced-color-adjust).
As of January 2025, the CSS Color Module Level 4 draft spec defines these system colors:
AccentColor and AccentColorText, for accented user interface controlsActiveText, for the text in active links (links that are currently being pressed)ButtonBorder, ButtonFace, and ButtonText for buttonsCanvas and CanvasText, for document defaults (the standard page background and default, noninteractive text)Field and FieldText, for inputsGrayText, for disabled text (despite the name, won’t necessarily end up gray)Highlight and HighlightText, for text selectionsLinkText, for hyperlinksMark and MarkText for text highlighted through, for instance, the <mark> tagSelectedItem and SelectedItemText, for selected controls such as checkboxes or radio buttonsVisitedText, for hyperlinks to visited destinationsSome of these colors are defined in pairs/
By default, semantic HTML elements will be mapped to the appropriate system colors. In these cases, you shouldn’t even need to mess with system colors at all. These system color keywords will really only come in handy whenever you’re creating more custom widgets. When possible, try to stick to the system colors that most closely match the intended meaning or functionality of your component, to make sure your UI is as predictable as possible. For example, if you’re creating a custom button, use the button-specific system color keywords.
These “-ms”-prefixed proprietary properties or keywords targeted the former Windows High Contrast Mode specifically, and have since been deprecated in favor of the standardized forced colors mode properties:
-ms-high-contrast media feature, which was used to detect whether Windows High Contrast Mode was enabled. Use a forced-colors media query instead.-ms-high-contrast-adjust property, which was used to opt an element out of Windows High Contrast Mode styling. Use forced-color-adjust instead.At this point, you should probably only be using these WHCM-specific styles if you still need to support Internet Explorer and even still, you should include them alongside today’s standardized forced colors styles.
forced-color-adjust: none is an unavoidable foot gun, by Sarah Higley