Form styling limitations are an accessibility issue
Posted 27th November 2020 in Accessibility, CSS and Development
I enjoyed a brief summary of the things people are looking for in CSS from Chris Coyier on CSS-Tricks:
Just clicking the reload button a bunch, I get the sense that the top answers are:
- Container Queries
- Parent Selectors
- Nesting
- Something extremely odd that doesn’t really make sense and makes me wonder about people
So I visited the What’s missing from CSS site and hit the reload button.
What Chris doesn’t mention, which I saw a couple of times, was form styling. There are a few key form elements that are difficult/impossible to style, and even require a lot of extra markup and some seriously hacky CSS. I’m thinking of <option>s in <select> and <datalist> elements, <input type="file" />.
I wonder how much <div>-based, ARIA-fuelled (if we’re lucky) custom-built alternatives could have been avoided if we had just been able to style those problem elements easily in CSS cross-browser?
I’ve noticed a fair bit of noise about this lately, including:
- Styling a Select Like It’s 2019
- Design systems, frameworks and browsers, a talk by Nicole Sullivan
- Can we please style the
<select>control?! - Improving form controls in Microsoft Edge and Chromium
- The Current State of Styling Selects in 2019
- Dropdown Default Styling
Just the other week, in fact, Stephanie Stimac from the Open UI Project wrote for Smashing Magazine about plans to make those problematic form controls more stylable:
The ultimate goal is to provide developers with a high degree of flexibility over appearance and extensibility of controls
Hopefully we’ll see browsers start to allow deeper custom styling of these problematic elements, so that designers can better rely on what the browser provides, and developers can use all of the out-of-the box accessibility benefits and lack of technical debt that using native HTML brings.