CSS-only Widgets Are Inaccessible

March 25, 2023; 2 Comments

Usually.

I originally titled this InacCSS-onlyible. I even made this typographically, er, distinct image. Then I realized it was silly and will instead use the neologism in a talk so I can hear the groans IRL.

Interactive widgets powered with only CSS are relatively common as people are playing with all the ways CSS can respond to, or create, interactions. CodePen contests are a great venue to see these experiments (which hopefully are never moved to a live human-facing project).

The problem with many of these examples is they need to convey their state (such as expanded or not), properties (think of relationships), or values, and (sometimes) dynamic names. While CSS is ideal to show these visually, they need to be passed to accessibility APIs so they can be conveyed to users of assistive technologies.

Not everything that relies on CSS for interaction is inaccessible. There are always going to be exceptions, but those are (and should be) rare.

Examples #anchor

I know folks do better with examples, so I have grabbed common ones.

Disclosures #anchor

It is very common to see a checkbox used as a trigger to hide or show content. Its use in “hamburger” navigation is sadly common, but I often see it with arbitrary expando patterns, such as this fork of an image gallery I made more accessible than its source:

Originally this was coded with a checkbox. A screen reader user would have no idea why there is a checkbox. Since the images are displayed even in the collapsed state (as black boxes), a sighted screen reader user could be confused why their alternative text is announced. A keyboard only user may wonder why it does not fire on Enter↵.

By changing the trigger to a <button> with aria-expanded, a screen reader user will know the trigger is for a disclosure and it fires on Enter↵. By adding aria-hidden="true" when collapsed, those images will not be exposed to that same user. This particular design means simply toggling a hidden HTML attribute or the CSS-only display: none will not do the job.

In short, script is needed to manage the expanded or collapsed state as well as the programmatic exposure of the images when reduced to tiny icons. It is a simple disclosure widget with an extra requirement.

Please do not use this example for a real project. It has other issues; I created it simply to demonstrate how easily a CSS-only widget can be tweaked for a baseline of WCAG conformance and a modicum of accessibility affordances.

Toggles #anchor

This example is a control to toggle dark or light mode (from a site offering copy-pasta-ready code) that is also quite inaccessible:

This fake toggle uses a hidden checkbox, so it cannot be activated with the keyboard. This also means a sighted screen reader user cannot activate it without grabbing a mouse. Bear in mind that the code in this sample is scraped from the demo, not from the downloadable package(s).

It is fine to use a checkbox as a toggle, incidentally. Though maybe save it for when you plan to progressively enhance the control and/or flipping the toggle will only take effect when the user submits it. In other words, plan to add a submit button when using a checkbox.

The site also offers a button version of the control, but that button does not convey its state. For that to happen, it would need to use aria-pressed and alternate its value between true and false. Then you hang styles off it, visually reinforcing its programmatic state.

I tend to prefer a button as a toggle in this scenario if you can count on JavaScript being available and flipping the toggle has an immediate effect. For most theme toggles on sites, this is the preferred approach.

As an aside, as of this writing my site uses buttons for the theme toggle. If JavaScript is not available, it uses links with a query string which spares the user having to also press a submit button.

Sorting #anchor

I have seen a few efforts using CSS to sort content. They generally follow variations on re-ordering the visual layout using the order property or repositioning items in a grid track.

The following video captures an experiment from 2018 that visually re-orders rows in a table. It demonstrates it as experienced in JAWS using table navigation.

Sorry, your browser doesn’t support embedded videos, but don’t worry, you can download it. The caption file is also available in case your video player can import it. Visually the table rows are sorted, but their row position announcement and navigation order never changes.

From an interface standpoint, an accessible sortable table would use aria-sort on a column header to convey its current sort state. The header cell would also include a control that can be operated by keyboard (a <button>, for those keeping score).

Programmatically, the sorting operation would restructure the DOM so that the new first row would become the first row in the DOM, the new second row moves into the second row spot, and so on. Otherwise you have both meaningful sequence and focus order WCAG violations.

Wrap-up #anchor

Any person, post, article, tweet, expert, fortune cookie, company, etc., that claims its CSS-only interactive widget is accessible is probably wrong.

While it may not be intentional, it is incumbent on you to confirm the accessibility because the person making the claim often has not.

accessibility, css, usability, UX, WCAG

Other Posts

2 Comments