Accessible Interaction: An interview with Derek Featherstone

An edited version of this interview appears in Chapter 5 of A Web for Everyone.

Derek Featherstone is founder and lead of Simply Accessible, a consultancy that works to bring accessibility into organizations through consulting, training, workshops, and support. Derek is a well-known and well-respected advocate for accessible user experience, moving beyond technical accessibility to support good and successful experiences for everyone.

Interactivity is a complex challenge for accessibility, making sure sites and apps are operable in different ways on different devices. We wanted to learn from Derek how best to approach a moving target like accessible interaction.

People are the starting point

Concern for people is the primary driver for Derek and his colleagues at Simply Accessible. They approach projects from the user’s perspective, starting with questions such as: What do we already know about people who use the site? What are their goals and motivations? What is this page or screen here to help them accomplish?

From there, they consider how the design and flow impacts the success of people with and without disabilities. “It has to be about the people who are actually using the site or application to accomplish something. If it’s not about them, then what’s the point?”

Best accessibility techniques are constantly changing

Derek’s team works from a knowledgebase of accessible techniques, built over many years of user research and usability testing, learning how people use the web. Building on those known techniques, they use observation and experimentation to come up with better techniques for coding, designing, and writing content that improves the user experience.

A lot of our work is experimental, even if it’s not fully classified as experimentation. Every technique that we come up with is our best technique at the time, until something better comes along. There’s a constant iteration that happens in the techniques we use.

This iteration is core to their practice because there is always room for improvement when it comes to accessible user experience, particularly with interaction, where new widgets and modules regularly appear on websites and apps.

We see a problem, we find an issue, and we pop a message into the team Basecamp: ‘Here’s an issue we found today, here’s the behavior of the form or link or whatever, and here’s how we think we can solve it. Can you code it up?’ Then we’ll put it through technical testing to make sure it’s compatible with different assistive technologies. And then we’ll roll it out and test it with users with disabilities. A lot of what we do is that kind of iteration, trying to explore different techniques.

Technical remediation can help make interaction accessible

Most often, Derek’s team is called on to take an existing website or app and make it accessible. Often, the designs are visually rich and appealing, and they convey information and relationships among elements in a visual way. However, those visual details are not always in the code. “The designs don’t convey the same information under the hood as they do visually.”

Take, for example, social media sharing badges. Most are embedded within a page using iFrames, and can be difficult to understand and use for someone who can’t see what’s displayed on the screen. For instance, many don’t have alt-text that accurately reflects the contents of the badge, such as the state and status of different buttons. Visually, you can tell whether an item has been liked or shared, but the code doesn’t contain the same information.

Derek and his colleagues have been working on a script for making social media buttons and badges accessible, one that would make state and status information available in the code where it’s available to assistive technology. This accessibility add-on then becomes part of their toolkit, to use on projects that include social media buttons and badges. But they also hope to influence the makers of these elements to incorporate their techniques directly into the elements.

We know it would be better if these elements were natively accessible. We also know that change doesn’t happen right away. Both solutions are needed. We keep our fixes on file so we can use them while the people in charge of social sharing badges work on making them more accessible.

Derek prefers to build in accessibility rather than provide technical remediation. “Our entire team views accessibility as part of the overall user experience and not as a separate thing that needs to be done afterwards.” However, in practice, clients very often come to accessibility late in the process, when there is little hope of changing the course of the design to produce a more accessible outcome.

Quite often people come to us with a completed site that has already been approved by management. For us to look at something and suggest a design change ends up being quite difficult to do. What we usually do is say, given what you’ve designed, here’s what you need to do to make it work in a more accessible way.

Integrated accessibility produces the best outcomes

But in some projects, they are brought in early and remain part of the team throughout the project, through implementation and execution. Projects handled this way are the most successful.

“What it comes down to is having people switched on right from the beginning of the project. They understand accessibility as more than a technical checklist.” With an early commitment, accessibility becomes part of the well-established user experience practice, integrated into defining requirements, user research, and carrying through to design iteration and execution. “One of the most important things to achieve success is to have all accessibility touch points built into the process right from the beginning.”

Tools help teams integrate accessible components

Derek and his colleagues have worked on several large-scale projects, and have had good success providing teams with tools that made it easier to build accessible products.

Everybody is overwhelmed with work that needs to be done, the amount of work that needs to be done, and how soon it needs to be done. Everybody wants things yesterday. Our strategy is to give everybody the tools they need to get the job done.

Simply Accessible gives teams an accessibility guide, integrated into the organizational style guide or branding guide. They create a code repository and pattern library containing elements such as modal dialogs or tool tips that can be easily dropped into code. The interactive elements are reviewed and validated for accessibility from a code, design, and testing point of view, including testing with people with disabilities.

One of our goals is to eliminate excuses. On projects, somebody makes choices about the timeline, and that means somebody else has to say, “We don’t have time for accessibility because we have this deadline of ‘x’.” We think about all the different pressures people feel when building a site and try to address them.

With this approach, communication is the greatest challenge. People working on the project need to know the requirement to use the library and other resources, and understand the implications of not using the tools. Otherwise, these resources may be overlooked or elements modified in such a way that the accessibility benefits are lost.

The most influential tool for accessibility is clear purpose

In cases where Derek has been able to influence design, the best tool in guiding an accessible process has been clear purpose–“Asking the original question, what is the purpose of this page and what are we trying to help people do.” In practice, we often use patterns and designs the way they’re always used, and add in expected features, without considering the goals and the necessary actions to support the goals. “That’s our most influential technique. And once we get answers, we can start asking questions like, how does somebody who uses voice recognition software because they don’t have the ability to use their hands, how are they going to activate that particular type of control?”

The #1 reason for them to use the site is to work with this widget, but they can’t because they’re using voice recognition software, and the widget is designed in such a way that the voice recognition software user won’t know what to do to activate it in the first place.

Starting with clear purpose and specific goals, the task is to design a solution that everybody can use to accomplish the tasks.

Solutions come from different places

Solutions aren’t always directly supported by design. In some cases, it’s the access technology that makes a design accessible.

Derek tells a story of a woman who needed a very specific design approach for accessible interaction. She was a quadriplegic, but had enough strength in one arm to lift her hand and operate a large touchscreen. “She didn’t have dexterity in her fingers, but she could make a fist and use the middle knuckle of her index finger to tap the screen.” Her greatest challenges in using websites were radio buttons and checkboxes, which were too small for her to activate accurately. Derek created a user stylesheet she could install in her browser that would resize radio buttons and checkboxes 10 times the size they normally appear.

“No designer would ever allow or think to include in their designs such large controls. It’s a solution that was only necessary for her.” But the story illustrates that accessible interaction isn’t about finding the one solution that works for everyone. “We can create one solution that works for most people’s abilities, but there are some people that need accommodation for their disabilities that a designer or developer can’t take into account in their work.” In these cases, the work of the designer and developer is to make the design flexible and adaptable. That way browsers and assistive technology can take elements of the design and adapt them to meet the specific needs of the user.