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.

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.

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.

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.

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.”

There’s a concept I’ve been fumbling for as I’ve been reading up on accessibility, while having your statement in mind. I’m not sure if there’s a best term for it. Charlotte Spencer has called it “incremental accessibility”, which I think is apt. It’s the idea that you can have a population — people who are blind, for example — that’s a small percentage, and of course you don’t want to leave them out, but you also don’t want to fixate on them at the expense of considering people who have low vision, or who have cognitive disabilities, and so forth. You don’t want to throw up your hands and say: “This will take us three months — we don’t have time for it.”

Jennifer: I think this really can and does happen in the mainstream. 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. And there are things that can also help screen reader users, like accommodating people without disabilities who use the keyboard. You can have people with low vision who do use screen readers too, who could benefit from maybe not perfect screen reader access, but some screen reader access in combination with low vision. In other words, better keyboard access could help low-vision people who use a keyboard [in combination] with [speech recognition software] Dragon, etc.

Axure: Right, and people with disabilities aren’t a monolith. There are lots of little things that can help different groups. I recently learned that there’s a setting in iOS, an accessibility mode that allows animations to be turned off, and I wondered why that mattered.

Jennifer: It’s because parallax effects are tough for folks with vestibular disorders. I think Web Axe had a post about [vestibular issues and parallax].

Axure: Is infinite scroll bad for accessibility? Because I personally really dislike it, so I’d love to say that it’s bad for accessibility.

Jennifer: It’s definitely been written about! (Ed. note: here’s a Web Axe article about infinite scrolling and accessibility.) Pretty much anything you hate, if you look it up, comma, accessibility, I bet you’ll find something. With infinite scroll, the main thing is to be able to control it with a “load more” button. There’s a [similar] thing in WCAG called “pause, stop, hide” (success criterion 2.2.2). They talk about it in terms of carousel. If something’s going to be changing more often than every five seconds, you need to be able to control it.

Axure: I was talking to Amy [Espinosa] about how, when they put together the World IA Day 2017 site, they aimed for WCAG AA compliance throughout. And there is a AAA level, but she said that a fully AAA-compliant site wasn’t realistic — and maybe even impossible for them. Because not all types of content can even meet the AAA level, so there is no such thing as a fully AAA-compliant site, practically speaking, if you’re building a site made to be used by lots of people as opposed to just an example, a technical experiment.

Jennifer: Exactly. And those are the only ones that I know of that are AAA, where that was kind of the point of the thing. That’s why all of the legal stuff always says WCAG 2.0 AA. There’s a lot in AAA where if you can do some of it here and there that’s awesome, but frankly, in my experience, you’re lucky if you can get even close to AA.

That’s why people use the “accessibility is a journey” analogy. And it’s not something that you can just do once and then you’re done, because as a site changes, people could break accessibility, people could put in new stuff that requires more thinking about accessibility. So it’s not just like you do an accessibility assessment, do everything it says, and then you’re done. That’s why I like [to do] training, because it teaches people how to do it better going forward. And also to figure out how they can put in strategies in their testing and other processes to not only make it accessible when they add new stuff, but also to keep it accessible as they maintain what they had.

Axure: What are the accessibility resources you refer to the most in your work?

Jennifer: One document that I always refer to, because it’s clearest to me, is Understanding WCAG 2.0. (Ed. note: we’ve been linking this site throughout the article.) And they give examples that always seem to me to be “more in English”. The problem with WCAG is that it’s really a standards document, and people think that they can just read the recommendation and they’re going to know what to do, but it’s not really geared to them. What’s really geared to developers, designers, and everybody else are the supporting documents: the techniques document, quick reference, the “understanding” document. The recommendation itself isn’t really meant for them. It’s used in all of the policy stuff.

A lot of times people just go straight to the recommendation and have the same impression as about screen readers, “oh my god, accessibility, it must be this hideous recommendation that I don’t understand, so I give up.” Even people in the accessibility space sometimes reinforce the impression, they give these presentations where they talk about how hard it is, where they point out that if you print it out, it’s so many millions of pages. But the recommendation isn’t meant to be printed out and read by most “real people”. The supporting documents are what help you do your day-to-day work. Those are the practical documents.

I think people, especially if they haven’t had much experience with people with disabilities, first of all they’re afraid. They can’t imagine what it would be like, and they’re also afraid of doing things wrong. So then they don’t do anything. That’s why some of the analogies, like the phone thing [in sunlight] is a good one: because it’s not scary. People can relate to it.

People just have a general fear of disability. Accessibility becomes a part of that, unfortunately. That’s why emphasizing that there are little things you can do is so important. Sometimes you feel like it all has to be done perfectly or else you can’t do any of it. But no site is ever one hundred percent perfectly accessible. I think the goal is to know what it means to make it better, and to try to get there.