Designing Focus Styles That Actually Indicate Focus
Default browser focus styles are rarely accessible enough to be useful. The purpose of a :focus indicator is to show users exactly where they are on the page as they keyboard through it. Subtle or invisible focus states defeat that purpose, and removing the outline entirely leaves keyboard users with no way to track their position.
Improving focus styles can be done in several ways. Nic Chan's Tips For Focus Styles covers adding affordance through padding, offset, and properly configured outlines. Sara Soueidan's reference guide on focus indicators explores how to build WCAG-compliant focus styles, serving both designers who need accessibility context and developers who need to implement the patterns.
Beyond the basic :focus pseudo-class, :focus-within lets you style the parent element of a focused child, which can be useful for highlighting entire form fields or widget containers. Meanwhile, :focus-visible allows you to suppress focus styles during mouse or pointer interaction when those styles would be visually disruptive.
One caution with :focus-visible: making focus styles keyboard-only overlooks that not everyone relying on focus indicators is a keyboard user. Focus also signals that an element is interactive for pointer users, so removing that affordance can reduce usability for some people. Notably, Chrome, Edge, and other Chromium-based browsers have stopped displaying a focus ring when buttons are clicked or tapped.
Autocomplete That Announces Its Own Behavior
Autocomplete is a massive boost for data entry involving large sets of options — maps, data visualizations, or a country selector in a checkout flow. But the same component that accelerates input must also handle announcing options and selections to screen reader users.
The UK Government Digital Service open-sourced accessible-autocomplete, a JavaScript component following WAI-ARIA best practices. It lets you control when suggestions appear, display the menu as an absolutely positioned overlay, or select the first suggestion by default. The group also maintains a demo page with numerous accessible implementations to reference.
Adobe's team is tackling the same problem for React through the Spectrum design system. Daniel Lu discusses insights from building an accessible combobox in that context and the issues the implementation resolves.
Icon-Only Buttons and Links
Component patterns without visible text — a navbar of pure icons, social media links — are common, but making them accessible requires deliberate decisions about what assistive technology will announce.
Kitty Giraudel's article on accessible icon links walks through making an SVG Twitter icon accessible. The pattern involves adding visually hidden descriptive text, removing the SVG from the accessibility tree with aria-hidden, and setting the focusable attribute so Internet Explorer doesn't treat the SVG itself as focusable. The approach is then turned into a reusable React component.
Sara Soueidan and Scott O'Hara offer complementary deep-dives covering techniques for the visually hidden text that screen readers will read — whether via an .sr-only utility class, the hidden attribute combined with aria-labelledby, or aria-label directly on the button. Sara recommends not relying on the SVG icon itself to provide the label when you can label the button element directly.
There is also the broader question of when to reach for a link versus a button in modern applications. Marcy Sutton's piece distinguishes them clearly: links navigate to a new resource, taking users away from current context, while buttons change the state of the interface. Buttons are the right choice for opening modals, triggering pop-ups, toggling interface elements, or playing media. Vadim Makeev's article on when a button is not a button adds further perspective on element semantics in interfaces.
Disabled Buttons or Active Errors?
Forms that keep the “Continue” button disabled until every field validates are increasingly common. That approach signals something is incomplete, but it does not communicate what is wrong or how to fix it. If a user misses one error message buried in a lengthy form, the disabled button leaves them stranded without an explanation.
Hampus Sethfors argues that keeping buttons active and showing clear error messages is far more efficient. Disabled buttons only work well when every input's inline validation is flawless. If a disabled state is unavoidable, Sethfors suggests providing an alternative like a "I can't complete the form" button so support staff can help users who get stuck.
The standard disabled attribute also blocks focus entirely, not just interaction. Screen reader users at least need to know such a button exists and why it's inactive. Sandrina Pereira's suggestion to swap disabled for aria-disabled keeps the button focusable and allows it to trigger a tooltip explaining what's missing — while still conveying that it is disabled.
Cards, Clickable Regions, and Screen Reader Verbosity
Cards are flexible layout elements without a native semantic element or ARIA design pattern. Their accessibility issues depend entirely on the content and purpose. Heydon Pickering's work on inclusive card components looks at permutations of the simple card pattern, balancing sound HTML structure with ergonomic interaction.
The biggest pitfall is when entire cards become giant clickable regions. Screen reader users are forced to listen to verbose control announcements for each region inside the card; voice users may struggle to know what phrase to speak to trigger the call to action. Adrian Roselli's analysis demonstrates how planning the interaction model can avoid those problems.
The Nomensa team adds another perspective with an accessible cards and block links deep-dive. Among their recommendations, re-ordering document content for improved semantics is a simple and high-impact improvement.
Carousels With A Way Out
An accessible carousel sounds like a contradiction, and most implementations leave keyboard users trapped: forced to tab through every panel set with no alternative. At minimum, a hidden “skip” link should appear as keyboard focus approaches. Once all panel sets are traversed, focus should pass to the element that follows the carousel, naturally ending the experience.
Heydon Pickering recommends building carousels with list markup for grouping slides, explicit previous and next buttons, snap points to aid navigation, and linked items that are visibly hidden but removed from the tab order. His code sample uses IntersectionObserver, which may require a polyfill depending on your target browsers.
Close Buttons Everyone Can Reach
Close buttons appear in modals, ads, confirmations, and cookie prompts, yet their functionality is frequently limited to mouse users. The failure translates to screen reader and keyboard users stuck in an overlay.
Manuel Matuzovic's collection on HTMHELL catalogs eleven inaccessible close button patterns and importantly five variations that behave correctly. The recommended, simplest pattern is a real button with visible text paired with a visually accessible icon — ensuring screen reader announcements are not cluttered by the icon's appearance. Matuzovic provides a code sample with the working approaches ready to use.
Custom Checkboxes and Radio Buttons
Styling checkboxes and radio buttons consistently across browsers often pushes developers toward replacement techniques. Sara Soueidan's article on inclusively hiding and styling these controls walks through the tradeoffs of each hiding method. The critical details: the hiding technique must keep the element screen reader-accessible, the original control should stay positioned on top of its visual replacement for touch users, and it needs to be transparent rather than removed from the layout.
As browser inconsistencies have largely been resolved, Scott O'Hara takes a fresh look at the current state of custom control styling. His write-up covers what your CSS needs to account for now and how to add effects like animation without creating new accessibility problems.
Building Accessible Color Systems
Contrast ratios affect more than users with visual impairments — poor color choices also hurt people on older displays or in bright environments. Creating a palette that meets standards while remaining visually distinct is a real design challenge.
Stripe's engineering team took this on when they redesigned their color system. Their goals: pass accessibility guidelines automatically, use hues that are easy to tell apart, and keep consistent visual weight across the palette. Their blog post documents how they approached the problem and what they learned.
Checking Contrast With Realistic Tools
The contrast requirements vary by context. WCAG 2.0 AA requires 4.5:1 for normal text and 3:1 for large text, while WCAG 2.1 adds 3:1 for graphics and UI components like form input borders. AAA level is stricter: 7:1 for normal text and 4.5:1 for large text.
The Geenes tool from Gianluca Gini provides a detailed checker for catching contrast problems early.
Geenes lets you adjust hue ranges and saturation, then applies the resulting palette to one of three UI mockups. You can simulate various vision impairments to see how your colors hold up, then copy the code or export to Sketch for immediate use. Chrome and Firefox DevTools also include built-in emulation for vision deficiencies.
Automated Accessibility in Your Workflow
Missing alt attributes and non-semantic heading structures are easy to miss during development. AccessLint brings automated checks into your existing process: when you open or update a pull request, it reviews the changes and comments on any new accessibility issues before they reach production.
For testing with real assistive technology, Cameron Cundiff built Auto VO, a node module and CLI that runs automated tests with the VoiceOver screen reader on macOS. It's designed for developers, project managers, and QA who need repeatable tests but don't want to become screen reader experts. Cundiff's article explains the details of how it works.
Understanding Different Visual Impairments
Terms like protanopia, deuteranopia, and glaucoma are familiar to most designers — but what do those conditions actually look like on your site? Corey Ginnivan's Who Can Use tool answers that question directly.
Enter a background and text color, and the tool returns the contrast ratio plus WCAG grading. It goes further than the numbers by listing different vision types, showing how many people are affected by each, and displaying a simulation of your color combination for each condition — a useful way to understand the practical impact of color decisions.
Reimagining Comics for All Readers
Complex layouts like comics usually end up as flat foreground or background images because they're so intricate. Comica11y, an experiment by Paul Spencer, explores how far we can push that pattern. It's a comic reading experience that supports closed captions, keyboard navigation between panels, a high-contrast mode, SVG color blindness filters, programmatic bubbles, selectable and translatable text, LTR and RTL layouts, and adjustable font sizes.
The project demonstrates how even image-heavy content can be re-architected as a genuinely enhanced web experience rather than a static picture.
Component Libraries Focused on Accessibility
Most design systems cover the standard components — accordions, tables, carousels, dropdowns — along with typography and color tokens. Adam Silver's No Style Design System takes a different route, concentrating on accessibility and web forms specifically. Built alongside his book on form design patterns, it offers accessible components from autocomplete and checkboxes to password reveal, radios, selects, and steppers, with minimal CSS and clean markup.
For more advanced needs, Heydon Pickering's Inclusive Components covers accessible cards, data tables, notifications, sliders, tabbed interfaces, tooltips, menus, and toggles with full tutorials.
The Accessibility Problem of Cookie Prompts
Overlays and pop-ups are inherently tricky, but cookie consent prompts create particularly bad experiences for screen reader users. In her talk "Screen readers and cookie consents," Leonie Watson details cases where users glide past the prompt entirely without knowing it exists, or end up trapped in a consent flow they can't confirm — making the site unusable.
Sheri Byrne-Haber's Cookie banners and accessibility breaks down the recurring problems: visual appearance, focus traps, placement in the tab order, how acceptance works, and the disclosure format. Quentin Bellanger provides a working cookie modal example with an accompanying tutorial. Free open-source options like Osano Cookie Consent and cookie-consent-box exist, but may still need accessibility fixes.
Indicating the Current Page Beyond Color
Color alone is a weak signal for navigation state if your users include those with low vision or color deficiencies. Adding a second indicator like an icon solves that. Callum Hart explains his approach in "An Accessible Current Page Navigation State."
His technique inlines the SVG icon in the HTML, then uses aria-hidden to keep it out of assistive technology output. Sizing uses ems rather than pixels, and the aria-current attribute provides important context for screen reader users navigating the page list.
A Practical Dark Mode Reference
With Apple, Windows, and Google all supporting dark mode at the OS level, matching user expectations on the web takes planning. Adhuham's comprehensive dark mode guide breaks the problem into two halves.
The technical side examines how to toggle themes, store preferences so they hold across pages and visits, and use the color-scheme meta tag to avoid flash-of-incorrect-theme situations when the user agent styles load. Design considerations cover preparing images, shadows, typography, icons, and colors for the dark treatment. For testing beyond simple dark mode, Microsoft's documentation on styling for high contrast mode shows how forced colors standards prevent you from accidentally breaking that experience.
Making Data Charts Accessible in Practice
Data visualizations need particular care since they struggle to convey meaning without good markup. When Sara Soueidan and SuperFriendly built an accessible micro-site for Khan Academy's annual report, they used SVG as the foundation for the charts.
Her case study begins with the most critical decision — how to embed the SVG — then explains why ARIA roles won't make an SVG chart accessible and why she avoided the <figure> element entirely. A companion piece on accessible text labels tackles the labeling choices that make charts readable in the first place.
Data Visualizations That Everyone Can Read
Data visualizations are most useful when they make large amounts of information quick to grasp. Sarah L. Fossheim’s series on accessibility in data visualizations collects guidelines, examples, and do’s-and-don’ts for designing charts and graphs that don’t leave anyone behind.
Her core advice: don’t rely on color alone to convey data, avoid bright and low-contrast colors, and lean on patterns, shapes, labels, and legends to clarify what’s shown. Each article in the series comes with examples and resources for further reading. Fossheim has also put together a review of US presidential election data visualizations, which is worth a look.
A Charting Library Built for Reliability
Torstein Hønsi created Highcharts after failing to find a simple charting tool to display snow depth measurements for a family cabin. The library that emerged is built on JavaScript and TypeScript and works with any back-end database or server stack.
Highcharts covers line, bar, area, column, and advanced chart types, adapts charts intelligently to any screen size, and includes accessibility features for visually impaired users. It’s free to try, and free for non-profits, personal websites, and school projects.
Date Pickers That Play Nice Everywhere
Plenty of date picker libraries exist, but a solid one should work across browsers without heavy dependencies and meet major accessibility requirements. Duet Date Picker fits that bill: it’s WCAG 2.1 compliant, works in any JavaScript framework or none at all, and supports configuring minimum and maximum allowed dates. The whole thing weighs about 10kb minified and Gzip’ed, including styles and icons.
If you need an alternative, Airbnb’s React Dates is accessible, mobile-friendly, and optimized for internationalization.
Dividers With a Personal Touch
The <hr> element is usually the most forgettable part of a page — just a plain horizontal rule. Sara Soueidan shows how to style them with CSS and SVG, replacing boring lines with her site’s signature birds sitting on a wire. Her write-up covers how to style horizontal rules and how to keep them semantic and accessible as they adapt to different contexts.
` styled as birds on a wire. (Large preview)
Getting UX Teams to Think About Accessibility
How does a design team start treating accessibility as a first-class concern? Elise Livingston shares the processes she created at Qualtrics to make software design more inclusive.
Her most effective move: add accessibility information to every design document. Each design handed to engineering now includes keyboard behaviors, labels, and semantics. That doesn’t just improve the final product — it pushes the team to consider disability-centered scenarios from the start of the design process.
Fixing Forms Once and For All
Checkboxes, radio buttons, select elements, dropdowns — everyone rebuilds the same components over and over. These resources help get them right the first time.
Sarah Higley’s “<select> your poison” is a deep dive into the intricacies of the <select> element, covering editable and multi-select variants, usability comparisons with real data, and practical recommendations. Stephanie Eckles’ Modern CSS Solutions series includes articles specifically on custom checkboxes, radio buttons, select styles, inputs, and textareas. Sara Soueidan has written a detailed guide to inclusively hiding and styling checkboxes and radio buttons, and Adrian Roselli’s code examples offer a view of under-engineered toggles.
Hiding Content Without Breaking Accessibility
Making something invisible while keeping it available to screen readers is trickier than it sounds. Kitty Giraudel summarizes the different HTML and CSS techniques for hiding content and when each is the right choice.
The goal, she notes, is to avoid big gaps between what’s visible and what the accessibility layer exposes. Giraudel lays out three main scenarios. If content needs to be hidden from both sight and the accessibility tree — a closed dialog or offscreen navigation, for example — use display: none or the hidden attribute. If it should remain visible but be hidden from assistive technology, aria-hidden="true" works for decorative visuals like icons. To hide content visually but keep it accessible for screen readers — say, a label for an icon button — use the visually hidden CSS declaration group.
Footnotes as Jump Links Done Right
Footnotes are essentially jump links. That means screen reader users need to know that a link is a footnote reference, not just any link. The aria-describedby attribute handles that, CSS counters number each reference, the :target pseudo-class highlights the footnote a reader has jumped to, and a back link returns them to the original spot in the text.
Kitty Giraudel details the full technique in a piece on building accessible footnotes. If you’re working in React, there’s also a guide to accessible footnotes with React and the react-a11y-footnotes library for use with Eleventy.
Getting Inputs Right
WebAIM’s 2019 analysis of the top million websites found that under one percent of pages were error-free. Semantic HTML is the foundation of making sites usable for people relying on assistive technology. Oscar Braunert’s article on inclusive inputs starts with sharing the basics and working together, then gets into the practical details.
The techniques start with a look at WAI, ARIA, and WCAG, then move through ways to make inputs more accessible without changing the user interface. Braunert’s advice: if in doubt, just do it — nobody will notice, except the users who will thank you.
Links: A 360-Degree View
A link involves more decisions than it first appears. Rian Rietveld tackles the whole territory of writing, designing, and coding links in “The perfect link”.
The article covers when opening links in new windows or tabs makes sense, how to write understandable link text, how to handle links to email addresses, phone numbers, and files, and what to consider when wrapping an image in a link. Rietveld also addresses underlining, hover and focus styles, semantic matters, and internal linking.
Keyboard Navigation That Covers an Entire App
Solid keyboard navigation helps more than just people who can’t use a mouse — it also benefits power users who want shortcuts. The team at Discord extended keyboard support to almost everything in their application. Their case study walks through how they tackled the problem and describes one particularly tough challenge: showing users where focus is on the page in a consistent way.
Since existing Focus Rings solutions weren’t up to the job, the team built their own from scratch and made it open source.
Rethinking Hover Menus
Mega-drop-downs that open on hover come with plenty of usability issues — they’re inconsistent, confusing, and need an alternative on mobile. Mark Root-Wiley argues that it’s time to replace them with unambiguous, accessible click menus.
In his article, Root-Wiley goes into the fine details of building an accessible click menu, with references from his research. The approach starts by building a CSS-only hover menu using li:hover > ul and li:focus-within > ul to reveal submenus. JavaScript then creates the <button> elements, sets the aria attributes, and attaches the event handlers. The finished result is available as a CodePen example and a GitHub repo.
Media Scrollers and Modals
Building a responsive media scroller that behaves well across TVs, phones, and desktops requires more than just a set of thumbnails. Adam Argyle’s step-by-step walkthrough shows how to layer behavior on top of a semantic foundation. The component starts as a plain <ul>, and CSS is used to create a smooth, grid-snapping scroll experience for the media or product thumbnails inside.
JavaScript contributes a roving-index interaction pattern so keyboard users can skip past a long list of items, and the experimental prefers-reduced-data media query can switch the whole scroller to a lightweight mode when network conditions call for it.
Modals get more complicated fast once accessibility enters the picture. Building one that is fully accessible means solving the classic focus trap. Eric Bailey’s detailed explanation of focus management covers the essential steps: identify the first and last focusable elements inside the modal, hide everything outside that boundary, move focus into the modal, monitor for tab presses that escape, and finally restore focus to the trigger element on close.
The native dialog element seems like an ideal shortcut here, but it currently has significant accessibility problems. Working within the Shadow DOM adds its own set of focus management challenges. Where support exists, the inert attribute cleanly removes and restores page content from tab order; for older engines, polyfills are available from Google Chrome and the WICG. If you don't want to build it from scratch, several maintained scripts handle the hard parts:
- Scott O’Hara’s accessible-modal-window provides reliable behavior as a dependency-free script.
- a11y-dialog Next by Kitty Giraudel is a lightweight (1.6 KB) solution that traps focus, toggles
aria-*attributes, and closes on overlay click or Escape. Be careful not to confuse it with previous version (6.1.0), which depends on the<dialog>element and thus inherits current implementation and accessibility gaps. - Parvus is an open-source image lightbox with no dependencies. Adding a
.lightboxclass to the link wrapping an image offloads all behavior to the script.
Forms, Preferences, and Skeleton Patterns
Password fields are a common stumbling block. "Show password" buttons and inline hints do help catch typos, but they introduce their own accessibility missteps. Nicolas Steenhout’s tutorial outlines how to properly wire the show/hide button with a switch role plus aria-live or aria-pressed states, and how to support autocomplete attributes so the form stays usable for everyone.
Not all users react to motion the same way, which is why the prefers-reduced-motion media query belongs in any animation plan. Elijah Manor’s blog post distinguishes how to handle CSS, SVG SMIL, and JavaScript animations with techniques such as @media, matchMedia, and a custom React hook.
The prefers-reduced-data query intends to honor users on slow connections or limited data plans. While not yet supported natively in browsers, it can be tested via Polypane and Chromium. Tatiana Mac’s no-motion-first approach suggests isolating animation styles in their own stylesheet and loading that file only when reduced motion is not set. Kitty Giraudel offers implementation guidance for a reduced-motion mode in her banking UI example.
Skeleton screens present a particular problem for screen readers. Many implementations rely on aria-busy="true", but only a handful of screen readers actually pay attention to it. Adrian Roselli’s More Accessible Skeletons offers a CSS-based workaround: target any node with aria-busy="true" and use display: none so sighted and non-sighted users experience the same loading state.
Skip Links, SVGs, and Tabs
Skip links lose their value when they are visually hidden with display: none, which removes them from both the screen reader and keyboard experience. Paul Ryan’s skip-link tutorial demonstrates the standard pattern of pushing the link off-screen with CSS and bringing it back on :focus. Eric Bailey’s comments suggest adding skip links ahead of sections that contain dense interactive content, like tables of contents and blocks of iframes.
SVGs are long past simple shapes. Color contrast, dark and light modes, and reduced motion are just a few of the considerations for styling and animating them. Carie Fisher addresses these concerns in “Accessible SVGs: Inclusiveness Beyond Patterns,” collecting tools, demos, and examples related to SVG accessibility.
On ARIA-heavy widgets, handling keyboard input and focus management remains a tightrope. Heydon Pickering’s article on tabbed interfaces explores enhancing content sections into proper tab panels — a code example illustrates the technique. There is also the consideration, raised by Adam Silver, that some screen reader users aren't used to arrow-key navigation between tabs; that debate is captured in a GitHub issue about all tabs appearing in the normal tab order.
TabPanelWidget covers many of those bases in a single, dependency-free solution. It starts with semantic HTML and becomes an accordion instead of cramping tabs into too little space. It uses ResizeObserver to detect when the layout must change; there is also a polyfill for older browsers. The widget is keyboard friendly and ships for vanilla JavaScript, Vue, React, and Angular.
Contents of Tables
Responsive data tables that keep their meaning for screen reader users are some of the hardest components to properly engineer online. Adrian Roselli has a thorough analysis on responsive accessible tables and another on under-engineered ones. One of the more effective workarounds he proposes is wrapping a table in a <div> assignment with the role="region", aria-labelledby, and tabindex="0" attributes to bring the container into keyboard reach. Inside the table, a <caption> ensures that screen readers announce context right away.
Some implementations go further: Roselli has examples for tables with expandable rows, sorting support, and fixed column headers.
It’s one thing to make content tables, and another entirely to experience how a screen reader actually moves through them. Leonie Watson’s article on navigating data tables walks you through the NVDA experience, from fetching a table to navigating its rows and columns. That exercise reveals the key insight: keyboard focus and screen reader focus are not the same concept. Making every single cell focusable actually forces keyboard users to hit far more tab stops than necessary; the document outline announced to the screen reader should instead define navigation well enough that non-interactive content doesn’t need real focus.
Building Toggle Switches That Work Everywhere
Binary choices — on/off, light/dark mode — are a common pattern, but a toggle switch needs to communicate more than just its current state. Sara Soueidan’s research into accessible toggle switches produced a solution built on two labelled radio buttons.
Because each radio button carries its own label, assistive technology announces two distinct options, the control is keyboard-operable, and no ARIA or JavaScript is required. Sara’s theme-switching example demonstrates the pattern, as does Scott O’Hara’s variant. The two labels are the key: this approach fails if a switch has only one. Scott maintains a repo of markup patterns for toggle switches for other cases.
Two other implementations are worth studying. Kitty Giraudel’s HTML/CSS-only toggle starts from a properly labelled checkbox, conveys state through both iconography and color, and degrades cleanly when CSS is off. Native focus styles remain customizable, a disabled state is included, and right-to-left layouts are supported. Adam Argyle’s step-by-step switch component also builds on a checkbox core: <input type="checkbox" role="switch"> inside a <label>. It works without CSS or JavaScript; CSS layers in RTL support, verticality and animation; JavaScript adds draggable behaviour.
Tooltips: Knowing What They’re Actually For
Tooltips explain a control or visual, but a label or a description?
Heydon Pickering’s tooltips and toggletips overview walks through that decision: whether content belongs in the accessible label or description dictates the ARIA properties you choose. He also advises avoiding title attributes and keeping interactive content — links, close buttons, confirmation controls — out of tooltips entirely.
- Sara Soueidan’s work on fully accessible help tooltips concludes that JavaScript is a requirement for truly interactive components.
- Sarah Higley reviews the complexity of tooltips under WCAG 2.1 and offers a code example demonstrating a robust pattern.
- Scott O’Hara keeps tooltip patterns in a GitHub repo.
- Adrian Roselli provides toggle examples that include disabled states, tooltips and RTL direction.
Media Players That Respect Captions And Keyboard
Viewers rely on captions for many reasons — noisy spaces, language comprehension or context switching — and on keyboard shortcuts like <space> for pause and arrow keys for scrubbing. Custom players frequently omit these essentials.
Accessible HTML5 Media Players catalogs several solid open-source options. AblePlayer stands out: keyboard-accessible controls, labels for screen reader users, speech recognition support, high contrast, captions and subtitles, chapters, text-based audio description and an interactive transcript with text highlighting. It plays YouTube and Vimeo content but relies on jQuery.
Alternatives include Vime.js — open source, lightweight, dependency-free and customizable. Plyr and PayPal’s Accessible HTML5 Video Player are comparable; the PayPal player is vanilla JavaScript, ships as a React component for keyboard-only and screen reader users, and falls back to the browser’s native controls when JavaScript is unavailable.
What Screen Reader Users Actually Hit
For sighted users, a missing alt text or unlabelled button is a minor annoyance. For blind and visually impaired people, it can be the difference between using a site independently or not at all.
Screen reader user Holly Tuke lists the five features that frustrate her most — missing alt text, autoplaying video, unlabelled buttons, poor heading structure and inaccessible forms — with fixes for each. Chris Ashton’s article covers common screen reader issues that get overlooked when conversations focus purely on semantics and keyboard access.
Testing And Research: Where To Start
Automated testing has limits: screen readers and voice control software still require manual verification. That’s where a11ysupport.io helps. Created by Michael Fairchild, it is an active, community-driven resource that documents what assistive technologies actually support, and contributions are welcome. For standard patterns, the WAI-ARIA Authoring Practices remains the reference for roles, states and properties.
Checklists And Resource Hubs
For keeping accessibility front of mind, the community-run A11Y Project aggregates guidance that spans from basic principles to audits and community building.
Its curated list, maintained by Hannah Milan, tracks 200+ plugins, tools, articles, case studies, design patterns, standards and the project’s own checklists. Missing something? Tools can be submitted for inclusion.
When “Accessible” Components Aren’t
Custom selects, autocompletes and date pickers promise time savings, but claims of accessibility often fall apart on closer inspection. Hidde de Vries points out that even components following the ARIA Authoring Practices Guide line-by-line can disappoint, because that guide makes no claims about screen reader compatibility or user experience.
His checklist for evaluating components covers the essentials: How did the authors test, and with whom? Are they transparent about their approach’s limitations? Who built it? It includes community-sourced tips for judging whether a component will meet its accessibility promises.
Closing Notes
The accessibility community has produced an enormous body of work over the years, from Steve Faulkner's series on semantics to Léonie Watson's writing on accessibility more broadly. Listing every contributor here is impossible; the field is richer for all of it.
Inevitably, this guide will have missed useful techniques, tools or resources. If you know of something worth including, feel free to flag it in the comments — the aim is to keep this reference current and genuinely practical for building reliable, accessible components without reinventing the wheel each time.
Stay accessible.
Acknowledgments
Special thanks to @jamsandwich, Courtney Heitman, Stephanie Eckles, Adam Silver, Daniela Kubesch, Tanisha Sabherwal, Manuel Matuzović, Vadim Makeev, Kitty Giraudel, Ian James, Juha Lehtonen, Heydon Pickering, Shivani Gupta, Jason Webb, Alex Kallinikos, Scott O'Hara, Sara Soueidan, Sasha Chudesnov, Adam Liptrot, Holger Bartel, Kim Johannesen and everyone else who contributed their expertise to this project.
