“Accessibility shouldn’t be a separate consideration”

Adam Bextream talks process, priorities, and his hopes for the future of inclusive design.

With a winning combination of subject-matter expertise, technical know-how, and great hair 😉, Product Manager Adam Bextream has been one of the driving forces behind Learnosity’s efforts to produce a more inclusive product. Here, he shares his thoughts on the importance of making accessibility a natural part of product development.

What accessibility projects have you been working on of late?

Well accessibility is intertwined in all user-facing projects, so we don’t work on standalone accessibility projects per se. When implementing any UI build, accessibility is just a part of the whole UX and engineering process. Aside from new projects, accessibility is also central to improving legacy functionality, addressing reported issues, and informing our general day-to-day activities.

What’s the process when starting a project? How is accessibility brought into the conversation? 

We’ve been committed to accessibility for a long time at Learnosity. There are so many people here who are passionate about inclusive products that these days I find it’s not something we artificially bring into the conversation. It’s just a natural part of any product discussion.

Operationally, work gets divvied up as follows: the Product team ensure accessibility is in the project scope. The UX team spec it, then the Engineering team implement and QA test it to ensure it meets the highest standards. That’s the division of labor at a basic level, but what ties it all together is the collaboration that happens between teams. There’s a unifying focus and passion across all business units.

How do we prioritize our accessibility work? 

We treat accessibility as we do any user experience and base our priorities on user impact. 

From what I’m seeing of how things are developing at Learnosity, accessibility is becoming less of a separate priority discussion and more an intrinsic part of the product’s overall UX.

What products or services have you recently used that impressed you with their approach to accessibility? 

The first thing that jumps to mind is seeing a lift installed at a local railway station. I live in a city where some 44% of stations are not independently accessible. It might take a year or so but eventually, residents with mobility challenges (wheelchair users, parents with buggies, or travelers with heavy suitcases) will have their needs met without needing to travel several stations up or down the line to get to one that caters for them. 

Timothy Whalin, a UX designer at Amazon, wrote in a Medium post:

“Accessibility is not a feature. Visible labels is not a feature. Color contrast is not a feature. Screen reader labels is not a feature. These are bugs. If a customer cannot use your product for an issue out of their control, that is a bug. Those bugs should be prioritized above developing new features.”

It’s a strong opinion. What are your thoughts on it?

I think Tim is trying to illustrate how accessibility is sometimes not given level footing with other work when it should – and as a bug rather than an enhancement. But how would you prioritize a bug that blocked a non-accessible user from using a product compared to a bug that blocks an accessible user?

In other words, I agree with the overall sentiment but I’d extend it to say that if any user can’t use your product because of an issue that’s out of their control, then that’s a bug that needs to be addressed as a priority.

Given it’s an evolving area, how do we stay on top of accessibility best practice? 

We want to ensure that everyone at Learnosity is conscious of inclusive design and equipped to deliver inclusive products. So we run accessibility training for engineering, UX, support, and product teams. These sessions have been great at raising awareness and getting important conversations going.

Our teams also attend conferences, workshops and meetups as they arise. When we’re scoping solutions, we reference WCAG directly and use various online engineering and UX forums. Knowledge sharing is a big part of our evolution as product builders, so the teams here swap any useful information they find – whether it’s implementation guides, online resources, or general articles.

It’s exciting to see such passion across the company. People from different teams are genuinely interested in deepening our collective knowledge and keeping a dialogue open so we can educate everyone on the importance of inclusive design.

Any words of wisdom for other product developers looking to make accessibility a core part of what they do?

Probably the one you’ll hear most often is build everything with accessibility in mind. Build it into the project because retrofitting is hard. It’s true – trust me, I know!

Beyond that, my advice is not to think of accessibility as an isolated component of a project that needs to be implemented. It should be interspersed throughout a project. From considering the UX interactions of accessible users to using good code practice and adding assistive content as you code. Make screen reader testing your best friend throughout the testing process too.

Ultimately, I’d like to see a time where we don’t talk about accessibility because it’s no longer a separate consideration. It’s just part of the overall user experience of a well-designed, inclusive product.