We often get entangled in conversations about all the fine details of interface components. And we should! We need to have conversations about the right buttons, the right icons, and the best typographic pairings. Yet perhaps sometimes, we jump into these conversations a bit too quickly.
Like everything else, accessibility is expensive when it’s brought up late in the process, but it’s quite straightforward if we design and build with accessibility in mind from the start. In fact, we’ve even published an evergreen Complete Guide to Accessible Components, which hopefully gives all of us a great headstart for any kind of project.
In this issue, we look into some fine aspects of front-end accessibility — from accessible autocomplete and custom radio and checkboxes to hiding content responsibly, accessibility linter, and how to make content accessible to everyone with purchasing power parity.
On the Smashing side of things, we’ll dive deeper into accessibility at our upcoming SmashingConf SF in-person this June. We still have a few tickets left!
Until then, let’s make the web a bit more accessible, everyone!
— Vitaly (@smashingmag)
1. Accessible Autocomplete
A combobox (also known as “autocomplete”) might seem like a rather straightforward thing to do, but it contains quite some complexity, especially if you want to make sure it is fully accessible and caters for a flawless experience on mobile devices. The team at Adobe created an accessible autocomplete experience for the React implementation of their Spectrum design system. Daniel Lu shares some valuable insights into the component and the problems it solves.
- Design Systems
- Lovely Little Websites
- UX Guides, Templates and Career Ladders
- Useful Front-End Tools
- Design Systems
- Data Visualization And Dashboards
- Designing For Mobile
Looking for older issues? Drop us an email and we’ll happily share them with you. Would be quite a hassle searching and clicking through them here anyway.