ARIA Authoring Practices on Accessible Date Pickers
Recently I wrote about Delta Airlines' date picker when booking a flight, as I found it really easy to use as compared to some other airline websites I'd tested in the past (VirginAmerica.com comes to mind). I wrote about the accessibility mechanics they'd used, including ARIA role=application and clever aria-label'ing to guide the experience. I even cautioned against that role as it often causes problems, which ironically in the case of Delta's date picker, was true. When I tested it again in JAWS and NVDA, I ran into the same issue reported by Bryan Garaventa: screen readers will frequently get stuck in the wrong interaction mode. Strangely it didn't occur every time I tested, but it was still bad enough that for the first time ever, Iâve removed a post from this blog.
Unfortunately, in pursuit of celebrating something working well, I used an incomplete testing methodology which showed a personal bias. Even by limiting the scope of a win to a single component, like a date picker: if it doesn't work in a major screen reader used by people with disabilities, highlighting it can spread bad practices. Delta did some things very well, undoubtedly. But not reliably working in NVDA and/or JAWS doesn't live up to the standard of an accessibility win. People who use those screen readers full-time should have a good travel booking experience, too! So instead, I want to highlight some true winners here: the group of people working together in the ARIA Authoring Practices group (APG) to establish a standard design pattern for accessible date pickers.
In a long-running post on GitHub, a discussion highlights some of the detailed interaction requirements for accessible date pickers. There are a few live examples in the thread, including a draft example in the Authoring Practices Guide and another one from Bryan Garaventa (who kindly sent this issue my way). I want to thank them for their dedication to getting this right, as standardizing accessible date picker mechanics is in everyone's best interest. I look forward to seeing a published solution for ARIA 1.1, so that developers know where to go for the most up to date and working examples.
Bryan's ARIA date picker could definitely be adapted for Delta.com. It would need to be refactored to include two months side-by-side (if possible) and use different styling, but it should definitely be possible to avoid role=application if followed very closely. Delta unfortunately used this role on the city picker as well, likely because they were having trouble with keystrokes in the autocomplete dropdown. Luckily, there are combobox examples in the ARIA Authoring Practices guide to reference, too.
Complex widgets like date pickers are really easy to get wrong; in fact, something working beautifully for some users may present barriers for others. Custom widgets require thorough testing to get right, especially on Windows and mobile screen readers due to their high usage by people with disabilities. You'll often hear accessibility professionals recommend using native HTML elements first. The unfortunate thing, however, is those browser defaults aren't always accessible, either...and our best bet is to come up with standard solutions that can be shared and implemented in various JavaScript projects. Accessible component libraries and guides are really helpful here.
So let my shame be an example to start with proven date pickers. Test in more assistive technologies and with more devices, and be honest with the limitations of your testing methodology so you can go back and test more before giving something the "ship it" stamp. (Listen to Leonie Watson user her screen reader with Bruce Lawson from Smashing Mag, while you're at it.)
It's okay to iterate and fix things for accessibility as you go along, as long as improvement work is actually happening. Focus on the browsers and technologies that people use the most, which can be gleaned from looking at your own browser analytics when paired with the WebAIM Screen Reader Survey. And don't be afraid to ask for a peer review....it just might open your perspective to who you're leaving out.
