Accessibility and Prototyping: Axure in Conversation with Jennifer Sutton

This interview is a companion piece to our new Approachable Guide to Prototyping for Accessibility with Axure RP.

Jennifer Sutton of JSutton Media first caught my attention at UXPA 2015, where she participated in a panel discussion with the refreshingly (brutally?) frank title of "Promoting Accessibility on Projects with No Accessibility Aspirations". When an audience member asked whether UI prototyping tools could have a place as part of an accessibility-friendly project despite their outputs not necessarily working well with screen readers, Jennifer responded with a remark that surprised me, coming from a web accessibility expert who also happens to be someone who is blind: "It's not all about the screen reader."

I sat down with Jennifer earlier this year for an extended conversation, hoping she'd expand on the thinking behind that statement.

"I think this really can and does happen … where project leaders say, 'accessibility is screen readers, and oh my god I don't understand this, it's too hard and it's too scary, so we'll just dismiss it completely.' … But there's a lot of accessibility that people can understand that isn't the screen reader." Things like adequate contrasts, sensible link labels, and hierarchical page structure can be couched as general usability issues and can thereby be approachable entry points for considering accessibility on a project where it might not otherwise be a top priority.

su_pullquote align="right"Sneak it in. Don't tell people — just do it./su_pullquote

I asked her what a well-meaning UI designer can do if a project's stakeholders truly have "no accessibility aspirations" and are maybe even hostile to the notion. She had three short words for me: "Sneak it in! Don't tell people, just do it."

After we'd finished laughing about that, she clarified that her advice was less about subverting project goals — not recommended — and more about staying educated as a design professional. That way, at least your initial designs can be aligned with accessibility best practices. "And then if stakeholders fuss about it, you might have to give a little. You might not be able to get the perfect contrast ratios. But you could get closer than if you started out with stuff that was bad, outright wrong."

The idea isn't to abandon screen reader users but to be realistic about which accessibility goals can be accomplished on which projects. On a project like the redesign of the World IA Day 2017 website — read our profile of WAID's Amy Espinosa for more about that — where accessibility is an explicit priority, designers can proudly and boldly aim for a high standard. (In the case of the WAID site redesign, the particular high standard used was WCAG 2.0 Level AA). But Amy, for her part, echoed Jennifer's practical and incremental approach on projects whose stakeholders are less familiar with accessibility considerations: "I don't think people realize how easy it is to make just a few adjustments and make things more accessible."

So what can you, the accessibility-aware Axure RP expert, do to guide your project to an outcome that's friendly to people with all types and levels of disability? Quite a number of things, it turns out. Check out our new Guide to Prototyping for Accessibility with Axure RP for a thorough list of practical tips for the Axure RP user. For my full interview with Jennifer, please read on. During our conversation she made reference to a wealth of other valuable articles and resources, and I've linked to those throughout the text when available.

Kip Mitchell of Axure: Accessibility specialist Aidan Tierney has said that "accessibility issues are predictable". To what extent is that true? Are the challenges just around implementing accessible solutions, or are there continually new fundamental types of problems that we're solving? Jennifer Sutton: I would say that because technology is always changing, there are always new problems and new ways to solve problems. When it comes to rich web applications, you've seen all the stuff about WAI-ARIA. They're working on ARIA 1.1, the best practices. There are a few new things being added there to try to make it better. They're working on WCAG 2.1. There are a number of new success criteria being proposed. There's a push to be focusing on folks with different cognitive disabilities, and what would be the success criteria. But the general types of disability that you're talking about are well-established. The approaches evolve, and the ideas evolve as technology changes as things get implemented, "oh, that wasn't quite right, we need to fix it this way, but the concept behind it is still the same, but we now have a better idea based on what we've seen in the wild." But the general concepts and the general kinds of people with disability are pretty clear.

su_pullquote align="right"A lot of accessibility is usability, but it matters even more. It makes a bigger difference. It has a stronger benefit. Wayfinding helps you — but it's essential for some people, or else they can't function. Color contrast helps you in the sun, but it's essential for some others./su_pullquote

A great entry point for UX folks who want to learn about the types of disabilities their users could be experiencing is the set of personas developed by Sarah Horton and Whitney Quesenbery in their book A Web For Everyone. Personas are risky in and of themselves because people get them in mind and they never evolve them based on feedback that they get or audience changes or whatever. But one of the things I liked about the personas that Whitney and Sarah have in that book is that they're not just disability-centric; they didn't just go down the list of disabilities and have a persona for each. They added complexity to these personas so that it wasn't just disability that they were building them on. They built them with other demographics, like age, English as a second language, all these other things. They were richer than personas sometimes are, and I think that's important. Based on what I read in usability, I think most people are trying. Whether they can actually do it in the real world is another question, but most people are aware and trying to make these rich personas that reflect the reality of customers.

Axure: I'm interested in this idea of the imperfect work environment or the imperfect project, where accessibility is not necessarily the first thing on everyone's list. Some of the project stakeholders might be unfamiliar or less familiar than others with the ideas, and maybe even less motivated due to personality, or maybe they even "don't care" about accessibility — they're actively dismissive. How do you work toward accessibility objectives on a project like that? Can you? Jennifer: Here's my answer to that: sneak it in. Don't tell people, just do it. And I'm not the first person to say it either, by the way. (Ed. note: Tomas Caspers spoke on the subject in 2011 though unfortunately I can't find video of this talk; here's Carie Fisher of Mediacurrent on the subject in 2016.) Pretend you're a designer, and you believe in contrast. And you know the tools that you can use to check your contrast, and you know the contrast ratios for WCAG AA. So you just put that in your design, and you don't say anything about it. But, if you get asked, then you explain; but you don't volunteer unduly. Now, if you work at a company with an interest in accessibility, sure, brag about it. "Hey, I did what I'm supposed to. This is why these contrasts are this way." But if they're not paying attention and you know that they should be, just do it. And then if they fuss about it, you might have to give a little. You might not be able to get the perfect ratios. But you could get closer than if you started out with stuff that was bad, outright wrong.

su_pullquote align="right"People say, "accessibility is screen readers, and oh my god I don't understand this, it's too hard and it's too scary, so we'll just dismiss it completely." There's a lot of accessibility that people can understand that isn't the screen reader./su_pullquote

Another thing you can do is make the case by relating it to something a non-disabled person can understand. You can say, "well, this grey. Even in the sunlight, nobody can see it, and I'm 25 and I still can't even see it in the sun." You just get closer; closer to what they want, while staying as close to best practice as you can.

Axure: I like that specific example, the idea that you would take a website outside on a mobile phone and look at it in full sun. Because I can't see hardly anything on my phone in full sun. Jennifer: Yes, that's an example people have used. It's something anybody can understand. A lot of people think, "contrast is for old people. And we don't have old people that visit our site because we're young and cool." So it's good to meet people where they are and come up with examples that anyone can understand.

Axure: What about the business case? I'm sure this will be different for every product, project, and business, but have you ever been brought in as a trainer because someone had some success with making the point that more attention paid to accessibility will be good for the bottom line? Jennifer: The W3C web accessibility initiative has a page on making the business case. And they have a few use cases, but what you'll see when you look at them is that they're old. They've had a lot of difficulty trying to get more use cases because people are nervous about putting themselves out there. You might make a bunch of changes, and you might see an increase, and you might think that it has to do with accessibility, so you'd be willing to put yourself out there. But then two years later, you might change your site again, and then you don't want that visibility because your new site might be completely different and may not have prioritized accessibility in the same way. So you're locked in at that point. The other place to look for business case stuff is Karl Groves. He has a whole series of posts about making the business case.

Axure: It seems that a lot of accessibility concerns can be framed as usability concerns. A designer can take this attitude, like, "well, Apple's design guidelines say that a mobile button has to be at least 44 pixels tall, and Apple's great at design, so who are we to make these tiny, ugly buttons." It's about looking modern, it's about being on the cutting edge, and then you can say or not say that it happens to be good for accessibility too. Jennifer: Whitney Quesenbery is famous for saying that accessibility and usability are twins separated at birth. It gets back to your point. A lot of accessibility is usability, but it matters even more. It makes a bigger difference. It has a stronger benefit. Wayfinding helps you — but it's essential for some people, or else they can't function. Color contrast helps you in the sun, but it's essential for some others. I see a lot of times, people contact me and they say, "I see this problem, where does it fit into WCAG?" Well, you could cram it into WCAG if you wanted to, but why? If you have user research that tells you it's a problem, whether it fits into WCAG or not, it's a problem.

su_pullquote align="right"Pretty much any design pattern you hate, if you look it up, comma, accessibility, I bet you'll find something./su_pullquote

For example: I had somebody working on a web application — very much an application and not a website — and it had a tools section on the landing page with certain tools under it, and then it had another tools section on a different page with other tools under it. And the users without disabilities were confused. So my client was asking me, can you use — there's something in WCAG about making things the same across pages (success criterion 3.2.3). And I said, "WCAG really focuses more on pages than it does on a web application, but why would you need to use WCAG? These people are telling you they're confused. Even if the developers don't like it, it's true. If they then choose not to do anything about it, maybe because the application has unique needs, that's their business. But you have the evidence."

Axure: At UXPA 2015, I saw you speak as part of a panel discussion titled Promoting Accessibility on Projects With No Accessibility Aspirations. In response to a question about prototyping tools and accessibility, you said something that really stuck with me: "It's not all about the screen reader."