A Complete Guide To Accessible Front-End Components

Stephanie Eckles’ Modern CSS Solutions for Old CSS Problems highlights plenty of useful modern techniques to solve plenty of challenges, but some articles from her series are dedicated to forms: CSS custom checkboxes, styled radio buttons, select styles, inputs, and textareas.

On her blog, Sara Soueidan goes into detail explaining how to inclusively hide and style checkboxes and radio buttons. Bonus: Adrian Roselli’s code examples provides additional insights into under-engineered toggles. Fantastic resources to use right away and style forms accessibly.

Hiding Content Responsibly

How do you hide content responsibly to make it invisible but still accessible for screen readers? Kitty Giraudel summarized different ways of hiding something, be it with HTML or CSS, and when to use which.

As Kitty suggests, you might want to avoid having too many discrepancies between the visual content and the underlying content exposed to the accessibility layer. The more they are in sync, the better. Kitty defines three different scenarios to help you assess when to use which technique: If you need to hide something both visually and from the accessibility tree (show/hide widgets, offscreen navigation, or a closed dialog, for example), use display: none or the hidden HTML attribute. If you need to hide something from the accessibility tree but keep it visible, use aria-hidden="true" (valid cases are visual content void of meaning, icons). And, last but not least, if you want to hide something but keep it accessible, use the visually hidden CSS declaration group (e.g., for complementary content that provides more context, such as for icon buttons or links). A great overview.

Accessible Footnotes And Sidenotes

In their essence, footnotes aren’t much more than jump-links — links to the description of a source, either placed at the bottom of the document, or in the sidebar, or appearing inline, a little accordion. However, as footnotes are jump-links, we need to ensure that screen reader users understand when links are references to footnotes — and we can do it with the aria-describedby attribute. The counter for every link would be implemented via a CSS counter. With :target, we then highlight the row which the reader has jumped to, and we provide a back-link back to the actual footnote place in the content.

Kitty Giraudel goes into detail explaining how to build accessible footnotes, and you can also check how to build accessible footnotes with React and use react-a11y-footnotes to build them in React with Eleventy (thanks to Kitty Giraudel for the tip!).

Accessible Inputs

In 2019, WebAIM analyzed the accessibility of the top one million websites, with a shocking conclusion: the percentage of error-free pages was estimated to be under one percent. To make our sites inclusive and usable for people who rely on assistive technology, we need to get the basics of semantic HTML right. With its credo of starting small, sharing, and working together, Oscar Braunert’s article on inclusive inputs is a great starting point to do so.

Starting off with the basics of WAI, ARIA, and WCAG, the article explores how to make inputs more accessible. The tips can be implemented without changing the user interface, and, as Oscar puts it: “If in doubt, just do it. Nobody will notice. Except some of your users. And they will thank you for it.”

The Perfect Link

A link is a link is a link, right? Well, there’s more to a link than just a clickable word or image. With her article “The perfect link”, Rian Rietveld examines how to write, design, and code a link that works for everyone on every device.

Rian covers the question if a link should open in a new window or a new tab, how to make link texts understandable, how to handle links to an email address, telephone number or file, what you need to consider when embedding an image in a link, when to underline it and how to deal with hover and focus styles, as well as semantic matters and internal links. A 360-degree look at the topic.

Accessible App-Wide Keyboard Navigation

A well-thought-out concept for keyboard navigation benefits everyone: It enables people who can’t comfortably use a mouse, assists screen reader users in interacting with an application, and it provides power users with more shortcuts to work as efficiently as possible. Usually, keyboard support is limited to specific shortcuts, but the team at Discord decided to go a step further with their application and expand keyboard support to, well, everything.

The case study “How Discord Implemented App-Wide Keyboard Navigation” shares valuable insights into how they tackled the task — and the challenges they faced along the way, of course. One turned out to be particularly difficult: How to consistently indicate where focus is on the page? As existing solutions for Focus Rings didn’t work out, the team had to build their own solution from scratch and made the code open source. If you’re facing a similar challenge, this one’s for you.

Accessible Tap/Click Menu

Is it still a good idea to design mega-drop-downs opening on hover? Probably not. Hover menus have plenty of usability and accessibility issues, as they are inconsistent, confusing and of course need an alternative solution for mobile devices. In fact, Mark Root-Wiley suggests that it’s about time to drop hover menus in favor of unambiguous and accessible click menus.

In his article, Mark goes into fine details of how to build an accessible click menu, along with useful pointers and references from his research. The idea is to start building the menu as a CSS-only hover menu that uses li:hover > ul and li:focus-within > ul to show the submenus. Then, we use JavaScript to create the <button> elements, set the aria attributes, and add the event handlers. The final result is available as a code example on CodePen and as a GitHub repo. This should be a good starting point for your menu as well.

Accessible Media Scroller Components

How would you go about creating a responsive media scroller component that works on TVs, phones, and desktops alike? Adam Argyle takes you through the process step by step.

Designed to host thumbnails of media or products, the scroller component is built upon a <ul> with accessible markup. CSS transforms the humble list into a smooth scroll experience that showcases the images and snaps them to a grid. To add some finesse, JavaScript facilitates roving-index interactions, helping keyboard users skip traversing a large number of items, and, last but not least, the experimental prefers-reduced-data media query turns the media scroller into a lightweight experience, if necessary. Clever!

Accessible Modals

You might have a simple modal or overlay on the page, perhaps to confirm customer’s input, or to show a couple of photos in a gallery, or just to confirm user’s preferences. In all these cases, building an accessible modal will turn out to become quite an adventure, also know as a focus trap.

As Eric Bailey explains in detail, you’ll need to identify the bounds of the trapped content, including the first and last focusable item, then remove everything that isn’t within it, move focus into the trapped content, listen for events that escape the boundary, restore previous state and move focus back to the interactive element that triggered the trapped content.

Ideally, we’d use something as simple as the dialog element in HTML, but unfortunately it has massive accessibility issues. With the Shadow DOM, managing focus isn’t easy either. We can use the inert attribute to remove, and then restore the ability of interactive elements to be discovered and focused. For older browsers, we can use inert polyfills from Google Chrome and from WICG.

• Scott O’Hara’s accessible-modal-window is a reliable fully accessible script to use.
• Kitty Giraudel maintain a11y-dialog Next, a lightweight (1.6 KB) script that traps and restores focus, toggles aria–* attributes and closes dialog on overlay click and Escape. It’s important not to confuse this version with previous version (6.1.0) as it relies on the <dialog> which which still lacks in implementation support, and has lingering accessibility issues.
• You could look into Parvus, a simple, accessible, open-source image lightbox without dependencies. In a typical scenario, we’d have an image linked to larger version of the image. With Parvus,, it’s enough to add a class .lightbox to the link wrapping around an image, and the script does everything else for you automatically.

Accessible Password Fields

“Show password” and password hints make form fields more usable. They help users figure out if they mistyped their password as well as what pattern is acceptable when they create a new one. However, as it turns out, accessibility is often lacking when it comes to these things.

To help you improve the situation, Nicolas Steenhout takes a closer look at show/hide password accessibility and how to make sure that password hints are helpful to everyone. From enhancing show/hide buttons with a role of switch and aria-live and aria-pressed to supporting autocomplete, Nicolas summarized everything you need to know to make the web a bit more accessible in this regard.

Support User Preferences With prefers-reduced-*

Not every user is the same, and while some users love animations, others may have medical issues concerning motion. The prefers-reduced-motion media query lets you toggle animations on and off, but there are even more solutions to manage animations depending on a user’s preference. In his blog post, Elijah Manor addresses different techniques such as @media, matchMedia, and a custom React hook to address CSS, SVG SMIL, and JavaScript animations.

When it comes to making your content accessible to everyone, there’s another prefers-reduced-* media query that is worth knowing about — even though it isn’t supported by browsers yet (but you can emulate it in Polypane and Chromium browsers): prefers-reduced-data. It indicates when a user wants to use as little data as possible — if their connection is slow, for example, or if data is limited.

• Tatiana Mac has written a very thorough piece on Taking a no-motion-first approach to animations, suggesting to place all animation-specific styles in an animation-specific stylesheet and serve it only if the visitor hasn’t indicated “Reduce motion”.
• Kitty Giraudel provides guidelines on Implementing a reduced-motion mode in an example of a banking UI and a code example as well.
• The Polypane team summarized what you need to know about the media query to future-proof your site already today.

Accessible Skeletons

Skeleton patterns tend to lack a meaningful way of presenting themselves to screen readers. They often use aria-busy="true" when a widget is loading, but only few screen readers actually honor the attribute. So how to do better?

As Adrian Roselli suggests, you could use CSS to find any node with aria-busy="true" and set it to display: none to achieve the same effect for screen reader and non-screen-reader users. In his article “More Accessible Skeletons”, he takes you through the process step by step. The demo works across browsers with current releases of JAWS, NVDA, VoiceOver, and TalkBack.

Accessible “Skip” Links

Especially on pages with a large amount of navigation, moving between sections or around the page can be frustrating and annoying. That’s where “Skip” links can be very helpful. Unfortunately, it’s not uncommon to see “Skip” links being implemented but hidden away with display: none, and as such, unavailable to anybody (including screen reader users and keyboard users).

In How To Create a “Skip content” Link, Paul Ryan provides a step-by-step tutorial on how to implement an accessible skip content link. Basically we use CSS transform to push the skip link off the screen, but bring it back on screen on :focus. In the comments to the article, Eric Bailey also noticed that we could provide skip-links before sections of content that contain lots of interactive items, or items that can be tough to navigate through (such as table of contents and iframes).

Accessible SVGs

Talking about SVGs: what we can do with SVGs today goes way beyond the basic shapes of yesteryear. Not only can we describe SVG icons, but also style and animate them. If true inclusiveness lies beyond patterns — what other factors should we consider when designing and developing accessible SVGs?

That’s exactly the question that Carie Fisher is answering in her piece on Accessible SVGs: Inclusiveness Beyond Patterns. In the article, Carie takes a closer look at SVG color and contrast, light and dark modes, SVG animation, reduced motion and plenty of tools focused all around accessibility. You’ll also find demos and code examples in the articles, along with detailed explanations and pointers for further reading.

And if you’d like to dive deeper into the complex world of accessible components — not only related to SVGs — we’ve just published Carie’s piece on accessible code patterns.

Accessible Tabs

Your interface might be using tab panels, but to keep the content of these tabs accessible to keyboard-users and screen reader users, we need a very careful and deliberate exposition of visual design and ARIA semantics. In Tabbed Interfaces, Heydon Pickering goes into detail trying to figure out just the right solution to respect keyboard behavior and focus management. He suggests to progressively enhance sections into tab panels (code example) (thanks to Daniela Kubesch for the tip!).

As Adam Silver notes, screen reader users who are less savvy may not know to use arrow keys to switch tabs. There’s an argument to make all the tabs focusable in the normal tab sequence with little intervention from developers to change the way tabs work via keyboard.

Alternatively, TabPanelWidget is a responsive and accessible solution for tabs. It relies on plain old semantic HTML, and turns into an accordion whenever the tabs cannot fit entirely (thanks to ResizeObserver but there’s a polyfill for browsers that don’t support it yet).

The script is not only a semantic and accessible solution, but also a responsive and versatile one to help you create Tabpanel and accordion widgets for the web. It is keyboard-friendly and available as a vanilla JS library (or as a widget for Vue, React and Angular).

Accessible Tables

There are plenty of accessibility issues related to tables, but the biggest challenges is to turn a visual representation into a linear series that will be read aloud meaningfully by a screen reader, without omitting any important information. Fortunately, Adrian Roselli has been spending a lot of time exploring the challenges and solutions of accessible tables.

In his post on accessible tables, Adrian suggests to wrap the table in a <div> with role="region", aria-labelledby and tabindex="0" to ensure that a keyboard-only user can tab to the container, that the table receives focus and <caption> within table to ensure that it’s properly announced to screen readers. Adrian also provides a code example for a responsive table, as well as tables with expandable rows, sortable table and fixed table headers.

How Screen Readers Navigate Data Tables

Have you ever tried to navigate a table with a screen reader? If not, you should check out Leonie Watson’s article on how screen readers navigate data tables. It shares precious insights and shows what matters to create frustration-free tables that can be used by anyone.

In the post, Leonie uses NVDA to move to a table, navigate its content, and find specific information. The appropriate HTML elements (or ARIA roles) inform her about the characteristics of the table and give her access to keyboard commands specifically for navigating the table’s content.

An interesting takeaway: Keyboard focus and screen reader focus are not the same thing. Contrary to what you might have heard, you do not need to make each cell of a table focusable with a keyboard to aid navigation. If the content inside the cell is non-interactive, you’ll likely make keyboard users work much harder to navigate the table than you intended. You can also watch a Smashing TV video with Léonie on How A Screen Reader User Accesses The Web (73 mins).

Accessible Toggle Switches

Whenever our forms provide a binary selection to our customers — on/off, dark/light mode etc. — we could use a toggle switch. The switch needs to serve a couple of purposes: it needs to clearly explain the current selection (and that’s clear not that often at all!), it needs to explain that there are two options, and it needs to be obvious enough for customers to understand how to switch between them. When Sara Soueidan was looking into how to build a toggle switch, she of course spent quite a bit of time looking into how to build an accessible toggle switch.

Sara’s solution uses two radio buttons, each with its own label, announced to assistive technologies as a couple of separate options, accessible via keyboard, and has no additional ARIA or JS requirements to function. The outcome is a theme switching toggle code example, and you can also take a look at Scott O’Hara’s code example.

It’s important to note that Sara’s radio button toggle switch is accessible because of its two labels. So if a toggle switch does not have two labels, this would not be a pattern to use. You can find markup patterns for toggle switches in Scott’s repo. (thanks to Scott O’Hara for the tip!).

Kitty Giraudel also shares a tutorial for a small HTML- and CSS-only implementation of an accessible toggle that you can tweak at your own convenience. The base for the accessible toggle is a properly-labelled checkbox. It conveys its status with both iconography and color and doesn’t leave any artifacts if CSS is not enabled. The toggle comes with native focus styles that can be customized, a disabled state, and it supports right-to-left orientation, too, if necessary.

Last but not least, Adam Argyle takes us step-by-step through the process of building a switch that is responsive and accessible.At the core of Adam’s approach is a checkbox <input type="checkbox" role="switch"> inside a <label> which has the advantage that it doesn’t need CSS or JavaScript to be fully functional and accessible. Loading CSS brings support for right-to-left languages, verticality, animation, and more. Loading JavaScript makes the switch draggable and tangible.

Accessible Tooltips And Toggletips

A component that’s closely related to icon buttons is a tooltip. Literally “tips for tools”, they are little pieces of information that explain the purpose of a control, or a visual, that otherwise could be misunderstood. Every time we want to explain why we need a particular piece of personal information in a checkout, that’s where we’ll probably be using a good old tooltip. So, how do we get them right?

Heydon Pickering’s Inclusive Tooltips and Toggletips provides a very thorough overview of pretty much everything needed to build an accessible tooltip. That means deciding whether the tip’s content should be provided as the label or description and choose ARIA properties accordingly, not relying on title attributes and avoiding putting interactive content such as close and confirm buttons or links in tooltips.

• Sara Soueidan, of course, also goes into fine intricacies of building a fully-accessible help tooltip and concludes that JavaScript is imperative to make fully-accessible interactive components.
• Sarah Higley also explains the complexity of tooltips and released a code example that shows a reliable pattern in action.
• Scott O’Hara has a GitHub repo on tooltips,
• Adrian Roselli provides plenty of code examples for toggles as well, including demos with disabled tooltips and RTL-direction.

Accessible Video/Audio Players

It’s not uncommon to see viewers frequently using captions when watching a short clip or a lengthy movie these days. We might be consuming the video in a noisy environment, or perhaps we can better understand written language, or perhaps we are currently busy with something else and need to look up something quickly without having to resort to headphones. Beyond that, how often do we use keyboard’s <space> to prompt a pause, or key arrows to move back and forward? Still, many video players and custom solutions don’t provide this functionality out of the box.

Accessible HTML5 Media Players provides an overview of accessible audio and video players. There are plenty of great open-source options, e.g. AblePlayer seems to be one of the reliable ones. It includes a full set of player controls that are keyboard-accessible, properly labelled for screen reader users, and controllable by speech recognition users, features high contrast, supports closed captions and subtitles, chapters, text-based audio description, an interactive transcript feature and automatic text highlighting. It supports YouTube and Vimeo videos. Hower, it depends on jQuery.

Alternatively, you could look into Vime.js as well: fully open-source, lightweight, fully customizable and without third-party dependencies. Other great options like Plyr and Accessible HTML5 Video Player by PayPal are similar. The latter is fully accessible to keyboard-only users and screen reader users, written in vanilla JavaScript, is additionally provided as a React component, and falls back to browser’s native controls if JavaScript is unavailable (thanks for the tip, @jamsandwich!).

Website Features That Annoy Screen Reader Users

A missing alt caption, an auto-playing video, unlabelled buttons, poor use of headings, inaccessible web forms — what might seem like a small issue for sighted users can make the difference between being able to use a website independently or not for blind and visually impaired people. Holly Tuke knows this from her own experience.

To raise awareness for common accessibility issues, Holly summarized five annoying website features she faces as a screen reader user every single day, and, of course, how to fix them. Chris Ashton also published a piece explaining common issues that screen reader users have, which are often neglected in conversations focus on semantics and keyboard-accessibility alone. Little details that make a huge difference (thanks to Alex Chudesnov for the tip!).

But First, Accessibility Support

There are many different ways that assistive technologies interact with browsers and code. Since it’s still not possible to fully automate screen readers and voice control softwares, we are left with having to do manual tests. And that’s where a11ysupport.io comes into play.

Originally created by Michael Fairchild, this community-driven website aims to help inform developers about what is accessibility supported. It’s a project that is active and contributions are always welcome, so start testing away. Also, it’s always worth checking the WAI-ARIA authoring practices which describe essential semantics, roles, and ARIA necessary for common components and patterns (thanks to Stephanie Eckles for the tip!).

Accessibility Resources And Checklists

Accessibility is incredibly important, but, unfortunately, often overlooked. The community-driven A11Y Project attempts to make digital accessibility easier, providing designers and developers with the know-how they need to build beautiful, accessible, and inclusive experiences.

From the basic principles behind accessible design to conducting an accessibility audit, and cultivating community, The A11Y Project takes a 360 degree look at the topic. You’ll find articles just like quick tips, tips on books to read, newsletters to follow, as well as handy tools, groups committed to accessibility, and much more.

Repository Of Accessibility Tools

Do you ever get that itching feeling of forgetting something before shipping a project? Well, checklists are known to be the key to keeping an overview of things that need to be done and taken care of before the final showdown. When it comes to accessibility, there’s a growing list of tools and resources that are bound to help you keep an eye on things: A11y Resources.

Curated by Hannah Milan, this list was initially created to keep track of more than 200+ hand-curated accessibility plugins, tools, articles, case studies, design patterns, design resources, accessibility standards, and even checklists. Of course, you can always submit a tool if you see anything missing.

Third-Party Component Accessibility

Reusable components like custom selects, autocompletes, or date pickers are powerful helpers. However, a lot of third-party components that claim to be accessible turn out to be only partially accessible once you dig a bit deeper. As Hidde de Vries points out, even components that implemented the ARIA Authoring Practices Guide 1:1 can be critical because the guide doesn’t make claims about screenreader accessibility or user experience. So how do you find those components that are truly accessible?

Hidde published a checklist of questions you can ask to have a little more certainty about the accessibility of a component: How did they test? Who did they test with? Are they open about pros and cons of their approach? And who created the component? He also shares some valuable tips from the community that help you assess whether a component that claims to be accessible will live up to its promise.

Wrapping Up

There are definitely dozens and hundreds of important guidelines by incredible people in the accessibility community, such as Steve Faulkner with a huge series of articles on semantics and accessibility and Leonie Watson with a huge series of articles on accessibility in general. It’s impossible to list everyone, but we are sincerely grateful to every contribution.

We probably have missed some important and valuable techniques and resources! So please leave a comment and refer to them — we’d love to update this post and keep it up-to-date for us all to be able to get back to it and build reliable, accessible components faster.

We sincerely hope that these tools and techniques will prove to be useful in your day-to-day work — and most importantly help you avoid some time-consuming, routine tasks.

Stay accessible!

Thank you! ❤️

A huge 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 everybody else who has been passionately working all around accessibility for the contributions to this article. Community matters.

More On Accessibility

• CSS Auditing Tools
• CSS Generators
• Untangling The Complex World Of Accessible Patterns
• Designing With Reduced Motion For Motion Sensitivities
• I Used The Web For A Day Using A Screen Reader
• Accessibility In Chrome DevTools
• Things You Can Do With CSS Today
• Also, subscribe to our newsletter to not miss the next ones.

Further Reading

• Cute Easter Wallpaper
• Fantastic Wallpapers That Will Blow Your Desktop Away
• Beautiful Dual-Screen Desktop Wallpapers
• 100 Really Beautiful iPhone 4 Wallpapers

(il, cm, mrn)