Accessibility is Hard: Toasts, Popovers, Jumbotrons, Pills… Are Ya Kidding Me?!?

Attila Vágó
Off Message
Published in
5 min readOct 13, 2020

--

A ton of yellow rubber ducks with red beaks.

There are extremely few things in life that make me want to throw rubber ducks in unrestrained fury against a solid wall. It’s a short list that consists of dry burgers, Iron-Man dying (seriously, Marvel?!?), gin and tonic without enough gin, and the exotic yet completely inaccessible labelling of components on the modern web! I can’t deny that three out of those four are beyond first-world problems. That last one, however… I’d argue that’s as universal as it gets. Well, for anyone who uses the web that is.

Among the trillion other things I do with my life, accessibility audits are one of them. Just to provide a bit of context, an accessibility audit is basically yours truly trying to use the website or web app with a (number of) screen reader(s), running a bunch of AXE tests on it, verifying contrast, and navigating via the keyboard only. Running an audit for me is a little bit like a very good multi-sensorial play at the theatre — like The Curious Incident of the Dog in the Night-time, for instance. It leaves you with a plethora of feelings. Running an audit is very similar. It’s fun, enlightening, jarring, and thought-provoking. So then why do I end up wanting to hurt rubber ducks?

Because… Reasons. Like toasts, snack-bars, popovers…

… you name it. That list is just about as long as the Smyths Toys queue every year on the 24th of December. Somehow, between 1991 and 2020, we — who design and write code for the web, the general industry — came up with incredibly fun, creative, exotic, but utterly incomprehensible names for our components. Comparatively, in the automotive industry, the wheel has been called a wheel since 1886 (look at me showing off my Googling skills). No one since decided to call it something else just because calling it a wheel wasn’t cool enough any more. Of course not. Why would they? Everyone understands the concept of a wheel, and how the number of wheels tends to correlate to anything between a unicycle and a 72-wheel truck or an obscenely long — probably candy pink — limousine. The bottom line here is that “wheel” is a convention, and having that convention is incredibly useful and efficient — dare I say, accessible — for pretty much the entire world.

Conventions like these however have been a lot less sacred on the web. Individuals using assistive technologies increasingly find themselves hearing words like “toast”, “popover”, “snackbar”, “card”, and many others. What copywriters, designers, UXers, and developers must be very mindful about is, that this terminology can be incredibly confusing for anyone using these assistive technologies. While it perhaps makes sense to identify (with caution) different styles of components internally as such during design and development, these exotic labels should never ever find their way into the end product. But they often do… so rubber ducks get hurt, and users get increasingly confused.

Because I am starting to run out of rubber ducks and I care about good UX for all, I decided I must turn my frustration into public wisdom and provide a definitive little design-label — accessible-label dictionary that everyone can reference for all eternity, or until Medium shuts down, whichever comes first. You can either bookmark this article or star the Github gist that contains the same list, but a little better formatted than what Medium allows (it being too cool to implement Markdown embeds that would enable rendering a simple table! — oh no… I’m out of rubber-ducks.).

On the left side you’ll find the exotic design term, while on the right the semantic, accessible term or implementation suggestion:

  • Floating action button (fab): button
  • Slider: input, range
  • Switch: checkbox
  • Breadcrumb: link
  • Stepper: there isn’t one, focus on describing the experience and make the step contents semantic
  • Tabs: tabpanel, tablist, tab
  • Card: doesn’t exist, focus on making its content semantic, and if it’s a list of cards, make sure the list is semantic and parsable, or use article if it makes sense
  • Accordion: doesn’t exist, focus on making its content semantic and navigable
  • Progress-bar: often what design wants doesn’t exist, just give the user periodic text updates on their progress, or get creative with the HTMLprogress tag.
  • Modal: dialog
  • Snackbar: alert, dialog, alertdialog
  • Avatar: button or image
  • Badge: it’s just text, if attached to an icon, just make it an aria-describedby
  • Chip: if clickable — button, if static — text
  • Pill: if clickable — button, if static — text
  • Tooltip: title or just use text via aria-describedby
  • Popper: input, select
  • Popover: dialog
  • Toggle button: button or input, radio
  • Unicorn: I’m only joking…
  • Carousel: doesn’t exist, use list
  • Jumbotron: (seriously, who comes up with these names?!?), doesn’t exist, use <section>
  • Bottomsheet: dialog
  • ActionSheet: dialog
  • Context-menu: select
  • Datepicker: select
  • Picker: select
  • Timepicker: select
  • Segmented Control: radio-button
  • Divider: <hr>
  • Dropdown: select
  • Expansion Panel: doesn’t exist, focus on making its content semantic and navigable
  • Hero section: doesn’t exist, just use <section>

Note: to compile the above list, I used three very popular component libraries: Material UI (React), Bootstrap (jQuery), Flutter (Android/iOS)

I am fairly certain there are a good few more out there, possibly even more exotic, and if you know of them, feel free to add them in the comments. If you know what the semantic equivalent should be, even better. If not, I’ll help you find out, and add it to the list!

The bottom-line here is really simple. Users interact with the browser, the web and the apps on a daily basis, and in order to help them get the most out of the digital tools we provide them, we absolutely must focus on removing the barriers of UX to which we currently expose them. No matter how much of a good place some of these component names come from, they are detrimental to great user experience and often a real blocker for individuals using assistive technologies. The point of software was always to educate, entertain or get a task done faster and more efficiently than before, and in order to achieve that, we — designers, UXers and engineers — must stick to the semantic standards established by the W3C and the operating systems our software runs on. This is not optional. It’s a universal business requirement.

Keep the lingo in the office, stay semantic out in the wild.

P.S. No rubber-ducks were harmed in the making of this article, and this song is indubitable proof of that.

Attila VagoSr. Software Engineer building amazing ed-tech software. Cool nerd since forever, writer of codes and blogs. Web accessibility advocate. Lego fan. Loves craft beer!

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Attila Vágó
Off Message

Staff software engineer, tech writer, author and opinionated human. LEGO and Apple fan. Accessibility advocate. Life enthusiast. Living in Dublin, Ireland. ☘️