Do you need to provide or to purchase an accessible website or other digital product but don’t know how to go about it? You’ll likely need to create or analyze an Accessibility Conformance Report (ACR) which is created from a Voluntary Product Accessibility Template (VPAT). You can download the VPAT templates on the Information Technology Industry Council (ITIC) website.
There are four different versions of the VPAT:
VPAT Rev 508: Revised Section 508 standards – the U.S. Federal accessibility standard
VPAT Rev EU: EN 301 549 – the European Union’s “Accessibility requirements suitable for public procurement of ICT products and services in Europe”
VPAT Rev WCAG: WCAG 2.1 or ISO/IEC 40500 (equivalent to WCAG 2.0) and WCAG2.1, W3C/WAI’s recently updated Web Content Accessibility Guidelines
VPAT INT: International; incorporates all three of the above standards
Here are some great resources on how to leverage VPATs and ACRs:
Summary: This article suggests that the custom select dropdown is overused. The ARIA combobox pattern to create one is very complex and has inconsistent support. Instead, the native HTML datalist element should be leveraged to create a similar UI control, and its support is pretty good. Code snippets, keyboard testing results, and basic screen reader testing results are provided.
Customizing a Select is not ideal
Due to extreme complexity, and usually spotty accessibility support, customizing an HTML select element is not recommended. There have been many noble attempts, but at the end of the day, it’s just not worth the many, many hours that web designers and developers and testers dedicate to this. And often it’s not needed; much of its demand is due to ill-perceived competition and designer narcissism. It’s always better to use native HTML.
Autosuggest adds even more complexity to the problem of customizing a native HTML select. The ARIA combobox pattern is appropriate for implementing autosuggest, but it’s inconsistent between ARIA versions, very intricate to implement, and there are many nuances and different levels of support by browsers and screen readers.
Enter datalist
We can address this issue by simply implementing the native datalist HTML element in conjunction with an input element. Doing so (and not customizing via ARIA) eliminates a huge amount of code complexity, code weight, design inconsistency, testing time, etc. The result is a control which functions like an autosuggest dropdown and text can also be entered into the input field.
The datalist element is defined in the spec as:
a set of option elements that represent predefined options for other controls. In the rendering, the datalist element represents nothing and it, along with its children, should be hidden.
Example of the datalist element in Chrome.
Datalist support
Datalist has been around for years now, but only recently has browser support and its accessibility been good enough to consider using. Check out datalist on CanIUse.com for info on browser support (that’s a lot of green!)
In a recent Tweet from Paul Adam, he states “HTML <datalist> Tag seems accessible enough now to recommend over an ARIA combobox”. Support could be improved (see testing results below), but all things considered, I agree. His tweet includes a screenshot of VoiceOver using the element, with Safari it appears.
The beauty of the datalist element is simplicity. Straight forward, semantic, and simple HTML – and no JavaScript needed! Here is an example – a label, an input, and the programmatically associated datalist element which contains the options.
<label for="browser">Choose your browser from the list:</label>
<input list="browsers" name="browser" id="browser">
<datalist id="browsers">
<option value="Edge">
<option value="Firefox">
<option value="Chrome">
<option value="Opera">
<option value="Safari">
</datalist>
Testing datalist
I’ve done some keyboard and screen reader testing using this datalist test page on CodePen. Support isn’t perfect, but overall it’s pretty good!
Keyboard testing results
After testing with Chrome, Firefox, and Safari, it seems Chrome on both Mac and Windows provides the best keyboard support.
Chrome (Mac and Windows):
Caret icon appears on focus
Option list appears when typing (option list also appears on focus)
Option list appears via spacebar
Option list appears via down arrow
Arrow + Enter to select an option
Escape closes the option list
Firefox (Mac and Windows):
Caret icon NOT displayed on focus nor by default
Option list appears when typing
Option list DOESN’T appear via spacebar
Option list appears via down arrow
Arrow + Enter to select an option
Escape closes the option list
Safari:
Caret icon displayed by default
Option list appears when typing
Option list DOESN’T appear via spacebar (note that with VoiceOver on, it appears with VO + spacebar)
Option list DOESN’T appear via down arrow
Arrow + Enter to select an option
Escape DOESN’T close the option list
Screen reader testing results
Screen reader usability seems adequate but could use improvement. Here are a few details. No mobile testing was done.
NVDA + Firefox
Upon focus, outputs “Choose your browser: combo box has auto complete editable blank”
Upon opening the option list with the down arrow, outputs “blank” then after down arrow again, “list, Edge 1 of 5”
NVDA + Chrome
Upon focus, outputs “Choose your browser: combo box has auto complete editable blank”
Upon opening the option list with the down arrow, outputs “Autofilllistexpanded, Edge1 of 5″
VoiceOver + Safari
Upon focus, outputs “Choose your browser:, list box pop up, edit text”
Upon opening the option list, outputs “Suggestions list visible”
JAWS + Chrome
Upon focus, outputs “Choose your browser: edit combo. To set the value use the Arrow keys or type the value.”
Upon opening the option list, outputs “Autofill. List box expanded. Edge, 1 of 5. To move to an item press the Arrow keys.”
Navigating the datalist example on the CodePen test page using NVDA on Firefox.
Wrapping Up
Browser support for the HTML datalist element is getting much better, especially on Chrome. Although support isn’t perfect—and nothing is—it’s still pretty good. Is it time to start using datalist instead of heavily customizing similar controls with ARIA? I believe it is, especially considering the vast amount of product development time it would save compared to customization.
Fun! Accessibility Daze — a GAAD (Global Accessibility Awareness Day) rap song via YouTube. A transcription is inline below.
Lyrics:
GAAD’s the celebration, this year a musical potion. Sight, sound, touch for all a sonic solution. AWOL, Coop, y’all ready to set it in motion? Yeah.
We come from many places with different biologies to celebrate GAAD and accessible technologies. Why we do what we do, it isn’t a mystery. You just have to go back in time and learn a bit of history.
It started way back in 2011 with nothing more than a blog post by Joe Devon. He was ashamed by devs’ lack of inclusivity, so he suggested we raise awareness of accessibility. Joe’s idea, it was really quite simple. On this day, the idea, it would ripple. Jennison saw the post and had a revelation to help Joe form a foundation, ain’t that amazing? Yeah.
Give them a standing ovation, they made it happen. Bring attention to tech exclusion, that’s why we’re rappin’. Digital access for all is our mission, so bring us your attention, show you how to make a difference. Get ’em.
One in six people on Earth have disabilities. It’s not a lie, the largest minority unequivocally. When sites and apps aren’t built to be accessible the experience is tough, and we need to be more flexible. Visual, auditory, motor, even cognitive, 1.3 billion, all the same, no one’s prerogative. GAAD is the first step to clear the haze. We’re here to pave the way through accessibility days.
Did you know that most sites and apps, they ain’t accessible? The worst part is most bugs are easily addressable. We can’t be followers. No, we got to be the leaders. Alt text on images enabling screen readers. Closed captions available when you play a video. Accessible content should be nothing more than trivial. Motor disabilities can make it impossible to interact with sites when navigation’s illogical.
Maybe with AI, we can open a eye to UI that’s usable without batting a eye. Whether they can’t use their eyes, ears, or any other senses, enable your websites. Don’t put up any fences. I said “screen reader” before, but let me rewind. It helps the dyslexic and others, not just the blind.
We can all make a difference all of the time. Don’t call me crazy. Just design your app to meet the W-C-A-G.
SPEAKER: Find out how to get involved. Visit accessibility.day. Glad to be GAAD — Global Accessibility Awareness Day.
A visually-hidden CSS class, as it’s often named, is used to visually hide textual content from sighted users but expose it to screen reader users. This is a common practice in web development, too common in my opinion. Another name for the class you’ll come across is “sr-only” (which I believe stemmed from Bootstrap but was modified in version 5). The properties of the class are complex and implemented in different ways.
So technically, this may be true—a native HTML attribute for the same functionality would be somewhat useful. But it’s not anywhere near the importance of other, more foundational needs. My point is that, in the big picture, a native visually-hidden should be much, much lower on the priority list. So low that it’s a bit discouraging to hear folks requesting it.
What the web really, greatly needs is the following:
Web developers who practice semantic HTML.
Designers who don’t want to customize every single UI element.
VPs who prioritize usability and accessibility.
Designers and VPs who prioritize usability and accessibility over the latest visual design trends (which most of the time cause accessibility problems).
A lot less adverts, pop-ups, notifications, and other UI shyte.
These fundamental needs will go tremendously further for usability and accessibility than any HTML attribute, ARIA attribute, automated testing tool, Figma plugin, etc.
Also, as web professionals, we don’t want to encourage the use of visually hidden text but discourage the use — in favor of universal design, creating the same design and experience for all users. This will also save a lot of time and hassle during the SDLC.
