I’m not typically one going to random events, but having recently caught the Meetup bug, I found myself at the latest London Accessibility Meetup.
Accessibility is something we can all strive to focus on. While I’m aware of the obvious easy wins us as web developers can add into our markup, I know there’s plenty more I should be aware of. I figured an event like this would show me things I wasn’t even aware of.
Yep. Certainly did that.
This month’s event was held at the Barclays headquarters in Canary Wharf. It was very massive.
I was under the impression this was a small, local community event. That’s what it was before this event, by the sounds of it. Barclays had put out all the stops to make sure everybody was well catered for. Top marks to them.
While this was my first visit to London A11y, this was the seventh event they had ran. It sounds like they had built up a bit of a reputation too as they had managed to bag a couple of great talks from those at the top of their game.
Future Accessibility
First up was a talk by Alastair Campbell about how WCAG - the Web Content Accessibility Guidelines - were changing to keep up with the digital world as we know it.
WCAG 2.0 was introduced back in 2008. Since then there’s been countless innovations creating new interfaces these old guidelines can’t keep up with. When it was last updated VR wasn’t a thing. Heck, the touchscreen wasn’t even a thing. How do we make sure these new ways of interaction can be as accessible and open to all?
WCAG 2.1 is in the process of answering most of those questions. A lot of it is still up in the air, but they are in the process of narrowing down exactly what counts as “accessible” in these scenarios.
A big sticking point comes from what is testable. An example of what they wanted to include was parameters around simple language use. How do you go about measuring that? There isn’t any quantifiable metric that can be used to measure that, so it becomes quite an ask to add it as a goal to reach.
Designing, Building and Testing the GDS Autocomplete
The second talk of the evening was actually a triple header. Ed, Theodor and Rob had all worked on making an autocomplete component they could use across GDS that was accessible first and foremost.
Autocompletes typically have quite a familiar look and feel, but aren’t quite accessible. Sure, you can make sure everything is marked up correctly, but making sure it’s a frictionless exprience for everyone is a big ask.
After a bit of research they were able to make a country picker that not only completed the names of long countries, but also catered for common typos and alternative spellings for those countries. Clever aria-live usage means they can provide useful content feedback to assistive technologies. Even with all that, it still falls back to a regular <select> when JavaScript fails.
It was a long journey to that end goal, however. After all the usual in-house and automated testing they performed, getting it in front of real life impared users threw up more issues they weren’t able to predict. Thankfully a lot of their work had made the product useable, but by observing how these people interact with the component showed they had more work to do.
It was very interesting to see how a team like GDS can take what, on the surface, might look like a simple input method and show just how difficult it is to make things accessible for all. With all the knowledge, teamwork, time and (ultimately) money, you can make a component that not only works for everyone but can be deployed everywhere.
All in all, it was a very enjoyable event. It opened my eyes to what’s out there and just what’s needed to make sure everyone gets the same joy from the Web as we do. It’s certainly one I hope to get to again in the future.
