Episode 12

Headshot of Marcy Sutton

with Marcy Sutton

On today’s episode we sit down with Marcy Sutton—a senior front end engineer at Deque Systems, where she works on accessibility. We talk about the intersection and differentiations in performance and accessibility. Marcy explains that there’s a huge audience that’s being missed by not making your website accessible.

Unfortunately, if it’s not something you have a personal connection to, it may not occur to you to think about. We talk about how most companies become interested in accessibility after they suffer a lawsuit, and how Marcy’s teaching us ways we can be proactive instead of reactive. We look at tools on how to make our sites more accessible and who to make them accessible for. We also talk about the metrics to use to measure success and usability.

Direct Download

Transcript:

Katie Kovalcin:

Welcome to the Path to Performance, the podcast for everyone who likes making really fast websites. I’m your host, Katie Kovalcin.

Tim Kadlec:

And I’m your other host, Tim Kadlec. How’s it going, Katie?

Katie:

It’s goin’ well! How’s it goin’ up there in the northern part of the country?

Tim:

It’s [laughs] . . . we always talk about the terrible weather podcast it would be but, you know, it is starting to get cooler. It’s almost fall.

Katie:

Are pumpkins. . .is pumpkin spice a big thing up there?

Tim:

Oh yeah, I mean, pumpkins are a big thing. We have like a whole pumpkin fest.

Katie:

Oh! Ohio did too.

Tim:

Oh yeah, it’s a thing. Oh did they?

Katie:

Yeah.

Tim:

It must probably be a midwest thing. Yeah, it’s like, it’s actually a big deal, it’s like a flagship of the year cuz you’ve got pumpkin fest where our population suddenly balloons for one day because apparently it’s a big draw. We get a lot of people who come up to this thing and there’s, you know. . .

Katie:

Is it like. . . is it in your town?

Tim:

It’s in Three Lakes which is like a five-minute ride away. So it’s right in the area. It’s at the high school. I don’t know why they call it a pumpkin fest to be honest with you cuz like there’s pumpkin decorations but it’s mostly just, other than that it’s not like super pumpkin themed. There’s a lot of pie.

Katie:

Yeah, the one in Ohio, it was in Circleville, which is like an hour or so outside of Columbus and they. . .I think they have like the biggest pumpkin contest and stuff like that so people grow like these enormous pumpkins and there’s all sorts of pumpkin food. It’s like a serious pumpkin fest. Although I don’t think I’ve ever gone to it maybe a long time ago…

Tim:

Yeah, the kids love it. They usually have some sort of a firefighter guy dressed up as a dog or something [laughs].

Katie:

Wait, why?! [laughs]

Tim:

I don’t know! Cuz kids love that, like walking, talking dog-like. . .

Katie:

Oh like a mascot costume, not like . . . not like a Halloween costume where he just has like his face painted or something.

Tim:

No. It’s like a mascot thing. No. Yeah, it’s a big deal cuz pumpkin fest is also the last day the local ice cream shop is open so then after that you’re stuck going to the grocery store for the rest of the year until next summer so it’s always a sad day.

Katie:

Oh, that is sad. RIP Summer.

Tim:

Exactly. So! Enough about the weather, so you don’t do pumpkin fest out in New Orleans.

Katie:

I don’t think there’s one. There’s voodoo fest but that’s a music festival and I assume that there will be a large Halloween celebration but I haven’t seen any pumpkins. I don’t know if they do pumpkins down here yet.

Tim:

Cool. Ah, performance?

Katie:

Performance! Well, today we’re focusing a little bit on well, not a little, a lot a bit on accessibility and the little bit of the intersection of what that means with when you combine performance and accessibility. It’s a really great conversation. Marcy is an expert on accessibility so we are very grateful that she shared her intense, deep knowledge of accessibility with us.

Tim:

Yeah, Marcy’s been doing great, great accessibility work for a long time and she’s been really focusing now on sort of the intersection . . . and we’ve danced around it a little bit here and there at some of the podcasts, like the tie between the two so, great conversation about making that a little more explicit.

Katie:

Yeah, I think we’ve talked a lot about just kind of the same cultural shift that needs to happen for both of these things but I was really excited that our conversation kind of led into a bunch of different UX type implications where those things kind of come together and things like that, outside of just the cultural shift that needs to happen so it’s a really great one! And I hope that everybody enjoys listening to it as much as I loved recording it.

Tim:

And we’re back with Marcy Sutton! Hi, Marcy! Welcome to the podcast.

Marcy Sutton:

Hello!

Tim:

For people who are listening who maybe aren’t aware of who you are or what you’re doing could you give us a little bit of background?

Marcy:

Sure, I’m Marcy Sutton. I am a senior front-end engineer at Deque Systems where I work remotely on accessibility tools for web developers so browser extensions, node APIs, basically tools to help you figure out what you need to fix for accessibility or what you’re getting right.

Tim:

Nice! That was a nice succinct. . .like, that was really well done! Nice little intro. So, I think this is great cuz I think Katie and I were talking about where we wanted to go here with season two and some of the topics we wanted to talk about and one of them that came up was sort of this . . . I think we’ve danced a few times, probably, in introductions and stuff and even with the discussions we had with . . . when we had somebody from Filament Group on last year like this idea of performance and accessibility being pretty closely linked. And that’s kind of. . . your name came up right away because this is something you’ve actually spent some time talking about and diving into is this connection between the two fields. Which . . . it’s a really interesting space. Like, so, how did you get into, you know, accessibility, I guess, let’s start there, what brought you into accessibility? What got you interested in that?

Marcy:

For me, I was working at an agency that had a client partner who had been sued for accessibility: Target, the retailer in the US. So when I got tasked on those projects they said, “You need to make this accessible so we’re going to have you train with Target’s QA team and their accessibility team and through that engagement I met people with disabilities. Two of those teammates, actually, I work with at DQ, funny enough but it really was that face to face and over the phone meetings with Steve Sawczyn who’s blind and I really started thinking about it in my own time. Like if I would post something to Facebook or Twitter . . .

So, actually when Steve followed me on Twitter I was like, “Oh, well, first of all: there’s a client following me now and, second of all: he’s blind!” So if I ever tweet something like a project or a funny article or anything I started going, “Well, would Steve be able to consume that information?” And from that point on I never forgot it, like it’s always in my mind, no matter what I’m doing. Sometimes I don’t post stuff because I just don’t wanna take the time to caption it. And so it was really that empathetic change of thinking that it went all the way through my work and I found a lot of value and a lot of creative and technical challenges in accessibility that helped me get outta bed in the morning and made this job really awesome. Now I work at an accessibility company completely so I get to think about really interesting developer challenges and go out and speak at conferences about it and it’s turned out to be something really wonderful.

Tim:

And it’s really important developer challenges. I think one of the things you talked about or mentioned there I guess is how you needed that personal interaction to that . . . that you know personal connection to really get you interested in it and invested in it and that’s I think that’s one of the challenges . . . you know Paul Lewis has called accessibility one of the three unsexy pillars along with security and performance. And I think that’s one of the challenges of that, right? Is that if you are in a situation where you don’t have anything inhibiting the way that you use or interact with devices or the web it’s really one of those things that can be kind of invisible to you.

Marcy:

Totally, yeah and it’s not just development, it’s definitely part of design. I would argue that some of the bigger accessibility problems stem from designers not thinking about it so my approach is . . .

Katie:

Oh yeah!

[Everyone laughing]

Marcy:

Yeah. My approach is to really bring everyone along and make it so that it’s not . . . you’re not getting beat up for it and harangued over it. It’s more like, “Hey, you can start now” and make people feel encouraged to pick it up right now and not feel bad that they haven’t done it before because when I got into accessibility it was like a club and I saw the way people talked about it before and I think there is still value in those narratives but there’s a whole audience that was just being missed and they weren’t being engaged.

And I’ve really found good feedback from just trying to bring people along it’s funny, to make accessibility more inclusive: sort of dog food the idea and just make it more accessible so that people know . . . like for performance and security, for example, you can’t expect people to be experts in all of these things. And that’s sort of what Paul . . . if I remember his article correctly, it was that those three sexy—unsexy—pillars just often were forgotten about. And so what specialists can do for the rest of our industry is to really find those easy wins and put them in formats that people can consume them so you can move the needle on these topics instead of expecting the general audience to all of a sudden become experts in these three unsexy pillars. So that’s worked out pretty well for accessibility.

Katie:

Sounds like there’s a lot of similar parallels kind of like what we’ve started the podcast on—kind of like introducing people to performance and ways to get everybody across the team thinking about it in easy to digestible kinds of ways um what sort of resistance or difficulties do you encounter when introducing people to it? Or do you like also encounter people who are like, “Well, we made the colours accessible, we’re done here!”? And sort of, how do you kind of keep them moving and pushing further and further along the spectrum?

Marcy:

Um, yeah, well there’s the people who don’t do it all. And sometimes it’s, you know, there’s someone who is really engaged on a team and they have resistance in within their company and, sadly, with accessibility sometimes, it takes the threat of legal action to actually get funds, you know? Get money to that team to actually start doing the things that they’ve been wanting to do but short of having legal action brought, cuz that’s not what we want. We want it to be proactive and if you’re thinking about accessibility earlier, as with these other unsexy pillars, it means that you can say what a good experience is and you can work at it more creatively instead of being reactive to a lawsuit or a threat of a lawsuit.

Tim:

So do you get people thinking about it and invested in it right from the kickoff? Is it like..

Marcy:

That would be ideal…

Tim:

. . . day one basically?

Marcy:

Yeah, that would be ideal. So the best thing that could happen would be to have in your discovery meetings, like the most successful project I ever remember working on was a corporate website that was one of the first responsive websites and when we were doing design work flows and really thinking about what the design would look like, I was brought in as a developer to prototype these designs and make sure that they would work because they had to be accessible, they had to be responsive. So that ended up being really successful because we iterated on ideas really early on and so we could check out ideas that didn’t work before we got all the way down the path of, “Well, we’re committed now”.

And so in an ideal world, you would prototype these things early on and include accessibility in those prototypes but often that’s just not realistic. Sometimes, as an accessibility person, I’ll get brought onto a project way later, you know, after style guides are finalized and there’s all of this—like that’s often where you hit the resistance, it’s just because you’ve entered the process too late to make a big impact in that way and so it’s really about just finding whatever ways that you can insert accessibility into the process that’s realistic. So it’s not always an ideal world. I don’t always get to prototype really early designs. But there’s still ways you can improve keyboard support and imporve things for screen readers. So it’s really just identifying whatever wins you can find and trying to make progress.

Tim:
How do you make those a little bit more physical? So like, one of the things that has been a recurring thing in all of our conversations with everybody on this podcast about performance is, you know, the people who are having success, integrating it inside their organizations or finding ways to expose performance throughout. You know sometimes that the form of the performance budget, sometimes it’s these big dashboards or Lara talked about having the huge monitors that show the performance of a site in different locations you know that’s just constantly there throughout the company office. What do you do for accessibility then to make these things more visible? Like if there’s, you know, any of these plethora of issues? How do you make it obvious that they’re there and they need to be addressed?
Marcy:

Yeah, well, there’s some guidelines that you can follow for accessibility including WCAG which is the Web Content Accessibility Guidelines, those are a set of standards that you can go into things like colour contrast, keyboard support, um there’s a bunch of success criteria for all of these different parts of accessibility and when you are doing them well, the number of violations that you might have, um, so the tools I work on, all of the audits you can run on a website, each one of those rules is mapped back to these success criteria. So if you’re doing really well, your number of violations will be low. If you’re not doing well, you have a lot of failures. And so that’s a metric that you could use to sort of say, “Hey, we’re failing all of these criteria!” And you can gameify it a bit and try to get that number lower and often people respond well.

It’s like, “Give me a checklist of things to fix and I’ll prioritize and work through it” And I think that is probably the most tangible way that you could work through accessibility issues is just working through the WCAG success criteria keeping in mind that being compliant and technically accessible is not the same as being usable, user-friendly, intuitive, all of those things are a bit harder to qualify but just having the basics. Like, making it work with a keyboard, I think if you’re failing to do any of those things, actually following those success criteria could make a big difference.

Katie:

So you’ve given a talk recently on accessibility and performance and the intersection there. Can you talk a little bit on what that intersection is and how they impact each other and why they’re both so important?

Marcy:

Yeah, so I started to see, you know, where accessibility and performance overlap and where they sort of differ. I mean, performance a lot of times in just the web industry I would see, “Oh, we’re making our site look like it’s loading faster by putting little divs with lines in it so you think there’s content loading”. Well, that’s really visual treatment, so if you’re using a screen-reader that content really hasn’t loaded yet and so that page is probably not usable to you yet even though cognitively if you could see the screen, you might think it’s loading okay. Like all of that perceived performance stuff really only applied to people who could see the screen.

And so I wanted to dive deeper into what are the things that would be blocking someone with a disability who relies on the keyboard or a screen-reader or some other assistive technology. You know, what are the slow-downs for people using those devices? And so this was actually born out of a conversation that I had with Tim, I sort of joined on after the conversation had been going for awhile, but it was all about, for a screen-reader and other assistive technologies what was happening in the browser as it would load and, you know, when—there’s this thing called the accessibility tree and we were totally geeking out over how that process works.

And so I ended up doing some more research on that and doing these talks and it was super interesting to learn about the accessibility tree. I actually got in touch with some people at Mozilla and asked about the internals of the browser. And this tree structure, in case you aren’t familiar with it, it’s parallel to the DOM and it’s really similar to the DOM but it’s only accessibility information. And so the biggest takeaway was knowing that there’s this structure that’s being updated as you’re manipulating the DOM and it might be stalled by the DOM loading. So, most people don’t even know that that structure exists or that screen-readers even exist. And so part of it was educating people about the platform—the web platform and how it’s used in screenreaders. But it was things like, well basically all of the things that Paul Irish had lined out about causing reflow and repaint—turns out all of those things, or most of them, impact the accessibility tree as well. Loading scripts that just take forever to load and maybe you’re blocking user input being the UI thread is locked.

So I looked at a lot of stuff like that and I really came away with pushing people to not customize everything. Like, I know as designers it’s really tempting to want to have custom form controls for everything but as a web developer you might cringe at that idea knowing that the cross-browser styling situation for form controls is just miserable. It’s tough to do visually. It’s tough to make them accessible as well, if you’re trying to really customize them. It’s like a bag of spiders with those—as, I’m trying to remember who coined that term: the bag of spiders but um it was really about pushing back to say, “We can’t customize all of these things!” We end up pushing so much more code to the user to try to customize them with CSS and Javascript that it’s like, you’re never gonna be as—it’s never gonna work as well as the native select.

And so it was funny that by the end of the talk I sort of came out saying, like, “Only use native form elements!” And there were two reasons, one, the browser defaults do so much right and they just work and, two, if you are trying to override all of those defaults and customize your own thing, you end up a lot more code over the wire and you’re waiting for that to download before you can use the site. And so it was all of those kinds of practical things that came out of that talk.

Katie:

It’s so interesting that, like, when I first got into web design it was, like, customizing all the things and oh, wow, look at this really fancy textured background of a fixed width site with all of these super custom elements and wow look at all that design can do and as the years progress more and more of that gets scaled back which is, like, fine cuz now I kind of see using native elements and stuff in the right ways or just doing, like, the minimum styling you can get away with without, like, totally destroying the native elements and stuff and that collaboration between the designer and developer now to me is like more of a signifier of good design. Like, oh okay, it’s fast and it’s accessible and it’s all of these other things rather than like…

Marcy:

Pretty.

Katie:

…the most visually - yeah, pretty, for lack of a better of a word, experience and it’s just kind of interesting to me how that all comes full circle. And also when you’re talking about perceived performance and how that impacts non-visual, that just blew my mind. I had never thought about perceived performance from a non-visual or animation solution.

Marcy:

Yeah, I mean—my example where I have a video of cnn.com loading and you see a bunch of stuff on the screen. There’s ads, there’s videos, there’s content but the screen-reader is struggling to get to a hundred percent. So you just hear the percentage process counter over and over again from all of the iframes loading and it’s a pretty crappy experience—

Tim:

Yeah, I was just gonna say, that’s really interesting because like, as Katie said, we’ve talked a lot about perceived performance as being like—I mean it’s not something—you don’t just do it instead of performance, it’s a thing you do sort of with the performance optimization. But it’s what you apply in situations where things are a little slow and you can’t quite address that. I mean, is there any equivalent in accessibility or is it basically, you really just need to focus on how quickly you can get this stuff down to the browser so the browser so the browser can get the tree created as quickly as possible. Or is there anything to do in a situation where it is a little slower?

Marcy:

Um, I think if you’re following all of the best practices it’s really about getting your assets loading quickly and executing. Not just looking like it’s loading fast but actually making it execute fast so that the UI thread isn’t locked up, you can type, you can use things. If it’s a universal app, making sure that when it upgrades that the user’s focus isn’t lost. That was another area that I experimented with for this talk. But I think if you’re doing a lot those best practices to get your site to already be fast. That will be the biggest improvement that you could make. But there are some critical things like that list of things that cause repaint and reflow in browsers that Paul Irish listed out. If you’re doing any of those while the page is loading, I mean—that’s—again with the best practices but just trying to defer anything costly until the site has already loaded so that, you know, not scroll jacking, not trying to—if you’re trying to hide and unhide a bunch of things when it loads—we’ve all seen the slow, the flow sites that’ll like pop up in modal when you’re like already halfway down an article.

There’s just a lot of stuff that isn’t put there for the user. It’s like a marketing thing. It’s so hard to resist. The people above you saying, “No, you have to put this in”. Sometimes it’s not up to us. But I think there’s some stuff like CNN loading a million ads—it’s gonna be hard to fight back with the ads team. So there’s some pragmatism and reality that we can’t always develop things exactly how we want but the biggest problem on those—on CNN for example, seem like there’s just so much stuff being pushed to the user that it takes time to load it even when you’re not using a screen-reader. So I think they just needed their site to be faster in general. But as far as the accessibility tree, I mean—given that it’s parallel to the DOM, I think if you’re doing—really just trying to streamline things and get it to load faster, that would make a big improvement.

Tim:

I always think it’s interesting to see like all the interconnectedness of all of this stuff, right? Like we were talking about accessibility and performance and now when you’re talking about like this—just trying to think as you’re talking through this, without the ability to fall back on some sort of a visual design hack to improve the way it looks it’s performing and it’s really about that raw performance. Now you start to get back—that CNN example, you start to get back into the territory of finding ways to figure out what the primary content is on that page and get that primary content down and then potentially, you know, lazy load or delay the other things. I mean, would that be potentially helpful in at least getting some usable experience out there and how would you handle making sure that once that lazy loaded stuff comes into play, the stuff that comes in a little bit after the load, that it doesn’t disrupt the experience?

Marcy:

Yeah, I think if you can lazy load stuff that would make a huge difference cuz it’s all being pushed to the user at once. So that really the screen-reader is like 90%, 90%, 90%, 95% - it’s like struggling to get to 100% because it’s trying to load the aggregate DOM. Where if we could defer any of that content loading until later—if it’s ad content, good luck fighting that fight [laughs]. Lazy loading the ads might be a tough sell. It would be a huge user improvement—user experience improvement but if it comes to content you’re trying to lazy load. Like if it’s way down the page or something, you could notify a screen-reader user with a passive—or I guess the word I’m looking for is polite, a polite ARIA live region.

So you could say, politely to the user, after everything else—if there’s any other announcements happening, it could say “New content loaded”. And so that way they know that there’s new content on the page that wasn’t there from the get-go but it wouldn’t be like shoved down the pipe all at once. So I think there’s some graceful ways that you could lazy load content and notify a screen-reader user without taking their focus to the new content, you could just tell them there’s new content. That helps a lot.

Katie:

I’m super unfamiliar with kind of how screen-readers work and stuff. Do they get ads? Are ads delivered there? And what’s the click through rate for those? Like I can’t imagine—

Marcy:

It depends what’s in them. So I hear blind friends sometimes talk about how they can just skip over those. I don’t know too much about the ad experience but it’s just like any other content, if there’s no alt text then you’re waiting for something to load that you can’t consume anyways so that’s even worse. But yeah it’s kind of a super user hack to be able to just completely skip by the ads cuz their not accessible. It’s pretty cool actually.

Katie:

Yeah, like I was just thinking if like, for compliance reasons and the legality of that stuff like if ads just shouldn’t even be on screen-readers [laughs].

Marcy:

I actually don’t know that much about the accessibility of ads other than I know that people do not push accessible content all the time and so often you can just skip over it but you are still waiting for it to load even if you can’t see it.

Katie:

Yeah, exactly.

Marcy:

We should talk about performance budget, like that’s just such a missed opportunity, yeah you’re downloading stuff that’s costing your budget as a user but you can’t even consume it. So it has some interesting things to dig into there for sure.

Tim:

One of the other ties that you’ve made—that I’ve seen you make I think in the talk as well—is with performance and accessibility is not just in terms of how quickly the accessibility tree is created but also performance from a user interactive perspective. I guess what I mean, you gave an example in the talk about how many strokes on a keyboard it takes to complete a task or I think that was it or am I making this up?

Marcy:

No, that’s exactly it. I found a research paper, an academic paper from 1980. I just went and looked up the year that it was published and it was all about—like, I found it just searching the internet for the keywords “keyboard performance” and I found this academic paper and it was all about tracking the number of keystrokes it would take an expert level user to complete a task. So it was like a performance metric for user interfaces but it was for expert level users who are already that power user group so it just really—talk about blowing your mind open. That one cracked my head right open and went, “Woah! That’s an interesting way to think about performance”. Because think about senior citizens using the web or people with cognitive disabilities using the web. It might take them more time and a lot more study of your interface to figure out how to use it and so it’s really advocating for simpler interfaces, simpler language and user testing to see how long it actually takes people to compete tasks

And I think that that is super interesting after working on interfaces where I would put myself in the expert level user group and I was having trouble with these interfaces. And it seemed like the design team on that project was not designing for their audience, they were designing for themselves. Especially when they would redesign an existing feature and I would find out the motivation for it was because they were tired of looking at it. Like that is just—you’re designing for the wrong reasons, for the wrong people. And so some user testing would highlight how complex these interfaces were. I mean, things were only shown on hover, they were really tiny icons with no labels that were not very obvious and so that sort of research put into words that thing that I couldn’t quite—it’s like, I feel like this is bad but I couldn’t quite put words to it and when I found that paper I was like, “This is it”. There is a known problem here and it’s existed since 1980. That you should make your interfaces simpler.

Tim:

I think that’s such a fascinating intersection—cuz it’s so very clear at that point like when you start—I mean really you could look at this, like you said, as a performance thing. You know, how many keystrokes or how many clicks does it take to get to this point? But it’s also very clearly an accessibility concern, it’s also, you know, something that designers—from the design level, on the information architecture level, you’re looking at how you help a user complete their task in as few strokes as possible. It’s a very clear intersection of all of these things, all at once, in one nice, tidy little metric. I kind of like that. That should be a thing, that’s not a thing but it should be a thing that’s a little more commonly looked at I think.

Marcy:

Yeah, this is a sort of trivia question that I do not have the answer to but when did the first mouse come about? Was that after after 1980?

Tim:

Oh, wow, I think I used to know. I don’t off the top of my head.

Marcy:

Because that would mean—if the mouse came about after that paper was written that those interfaces were just all keyboard. And we’re finding to get keyboard support on modern interfaces—gets people—you can put a click of it on a div or custom element or whatever. So a lot of what I talk about is actually making interfaces work for the keyboard. So yeah just super interesting, how that paper was written and we’re sort of applying our own take on it but the underlying problem is still there. That one blew my mind right open.

Tim:

I think most of the time that we’ve been talking about accessibility on this—like even at the start of this podcast—and certainly where I see it most often discussed in terms of the industry. It’s always focusing on screen-readers and how they apply to people who are, you know, visually impaired. But what you were hittin’ on with keyboard strokes—there’s—and you talked about senior citizens and stuff, the accessibility is so much more broad than just this is a person who can’t see and so we need to make it accessible to them through some sort of a screen-reader. There’s—it’s such a—accessibility is about the inclusivity and there’s so many different groups and so many different variabilities there in terms of what could potentially be hindering access. Can you dive into that a little bit? Because I think that that’s one of things, like, you were talking about how accessibility can be difficult to get going in and it felt like this club at first. And I think that that’s one of those really important barriers to break down. If you stop and think about all the different ways that somebody could have difficulties interacting with a device or with your website, it starts to be a little overwhelming and intimidating to be quite honest.

Marcy:

Yeah, definitely. And there’s definitely articles I’ve seen go around that are talking about user testing of tabs and how these known patterns that we hang our hat on maybe don’t work that well for users. I think it’s important to look at the big picture and see how much help we need just getting the basics.

So following checklists and getting those top ten accessibility things addressed is absolutely the place to start and then once you’re beyond that, it’s important to look at your user base and your product and get more specific if you’re gonna really move the needle for accessibility on our product. Getting user testing done with people with disabilities can help you get answers—because checklists are general, there sort of a big paintbrush, you know, broad strokes to get the basics which can have a huge impact on a really big audience of people so that’s why we do it. But when you start to get more specific, if you do some user testing you can highlight issues with your specific interface and your design that would be hard to get otherwise cuz you know you’re designing it, maybe you’re sort of designing it for yourself a bit even though you don’t want to admit it.

Because I totally do that myself. And so getting another group to look at your interface can get you some more actionable feedback specifically for your product. So I think that’s sort of the next level but often we’re just getting in at the ground floor, trying to get people to do the basics. So it’s kind of a layering effect, start with the basics and then push for some user testing. Just because it’s—in an hour of user testing you could get some really interesting insight. So I’m a pretty big advocate for that just cuz I’ve seen what a big—it can totally switch your way of thinking about something.

Katie:

Are there sort of lo-fi ways to conduct user testing with people with disabilities, like how do you find users that have all levels of abilities to come in and test? I’ve worked at agencies before that have been just like, “Whoever says they can come in and test, that’s how it works”. And I think a lot of people have sort of just guerrilla level tactics for doing user testing and I’m just curious how you reach out to those users.

Marcy:

Yeah, so the first group you could look up is called Knowbility and that’s K-N-O-W, like ability but knowbility. They have a program to help do that matching of people who need user testing done with testers. And so that’s a really great organization to find people to help you testing because it is sort of hard to find those people but I usually use Twitter is a really great way to reach out to people. The #a11y is—there’s lots of people all over the world that follow that hashtag so—If you wanted sort of the guerrilla tactics, if for some reason Knowbility is too big of an organization, you can just grab people who are more than willing to help you test something because people just want to be included. Because people with disabilities are often early adopters. And so people who are early adopters are like, “Yes, we want to get this thing to work”. They would be more than willing to help you do some user testing. But I would definitely check out Knowbility because I’ve heard that they do that sort of thing. So there is precedent. I know it can be a bit challenging to get user testing in the budget at all so hopefully by saying, again, how valuable it is that it can help people remember that at critical times and push for it in your organization.

Katie:

Totally, that’s really awesome. I had never heard of that organization before and I will look them up.

Tim:

Is there a way—you talked about the difficulty of getting budget, is there a way to—and I know that like I think, I don’t know if you mentioned this site specifically but you have the Accessibility Wins site where you had been highlighting things where like people succeeded and stuff. So I know it’s—I like that. I always feel like it’s a little bit more powerful to have a positive examples or positive examples for something versus—like I’m more of a carrot than a stick kinda guy. But how do you get the budget internally within an organization using the carrot approach? Like what carrots can you dangle? Like, from a stick perspective, like you said, it’s the fear of ending up being another very public lawsuit like the Target thing was—but what is like—what are the carrots that you can provide to management to get the budget for it and to, if you’re a designer, to your developers, or if you’re a developer, to get your designers to focus on it. Like what carrots can you use within an organization to advocate for this?

Marcy:

Well, yeah, it’s hard. If you’re—if you have any easy wins going on. If you’re the developer and you’re like, “Oh I put in this thing”. Getting feedback on that good feature can get some more momentum to do more. Like if you had something you did really well and submitted it on my blog, Accessibility Wins, as you’ve mentioned, I take submissions so if there was like—if I were in this position as a developer and I were trying to get more, I’d say, hey, write to me, Marcy Sutton, the blog person, and say, “Hey, I wrote this really cool feature, I’m trying to get more momentum at my company. Can you write about it?”

Because I found that this sort of outward feedback, I dunno if it’s ego driven or what but people seem to respond to feedback outside their company, good or bad. Often times it’s bad. Or even just politely saying, “Hey, can we talk about this?” It happened recently with—I don’t really wanna say the company’s name but I tweeted about their colour contrast and I didn’t say it rudely. I just said, “Hey, can we talk about your colour contrast?” And I’ve heard from people at that company that that really lit a fire internally. They’ve been putting more resources behind it. And it wasn’t like a—you know—I didn’t totally like make them feel bad. It just was enough outside pressure to get them to actually make a change. And I don’t see that that would work at every company but, especially with designers, I feel like there’s some sort of ego driving thing, this force that you can sort of apply pressure and people will go, “Oh, other people are talking about our product, we should do that”. So it’s almost like somewhere in between the carrot and the stick because you wanna get people to go, “Oh, crap! We need to make progress on that!” But you don’t wanna beat people up with it so that they’re like, “No! I’m getting beat up” cuz no one responds well to threats and that kind of feedback so it’s somewhere in the middle between the carrot and the stick.

Tim:

It’s sort of like getting poked with a carrot, I guess. I’m trying to think of what that would be like if we extended the metaphor to uncomfortable—

Marcy:

It’s like point it out so that you feel like, “Oh I need to do that” but don’t make people feel so bad that they don’t wanna work with you, you know?

Tim:

Yup, definitely. So you’ve done this now. Not you but the hypothetical person listening to this and is like, “This is great, I wanna do this within the organization. I’m gonna start doing that”. What are the first steps? Is the first step to find that first simple win? Or is it to do a full-blown—try to use some sort of an auditing tool to identify a whole bunch of stuff and prioritize? What are the first steps that you do now to start making this a reality within your organization or on your website or application?

Marcy:

I would definitely use an auditing tool. There’s a number of them out there. I work on one called Axe. But you could use a tool like that to help you figure out—with those basics I mentioned—figure out what you’re doing right and wrong and once you’ve got that sort of list, I guess depending on your role at the company. You don’t wanna be spending all your free time, like you should be getting paid to do your job so time dependent, I think you should be able to come up with a list of things that get prioritized cuz you often can’t—even though I want to redo all of the headings on the site, I can’t go and do them at once. I have to work them into feature work. You know, get it on the calendars so we can see when things will get done. But if you had a list that you present to your team and say, “Hey, here’s some things that we could do to make our site more accessible and here’s why”.

I think you can make some pretty compelling reasons. If it’s—I dunno—there’s something in between “We need to do this” and “Here’s a list of things that we can do” that makes it a lot less scary when you have actual tasks that you can pick up and you can assign hours to them and estimates. Because when you’re running a business you have to figure out how long things will take and so I think that’s where getting a budget, if you actually have numbers that you can present, say, “Here’s how long this is gonna take. If we focus on this part this sprint and that part next sprint, we can really make progress.” I think that’s how you can actually get it in motion instead of getting a big fat no.

Tim:

Yeah, it’s always nice to have something concrete, yeah.

Katie:

I could be totally mistaken but is there not a new law going into effect in upcoming months to make all of this a hard requirement?

Marcy:

It depends where you live and what industry you’re in. But I know for airlines, the Air Carrier Access Act recently went into effect so airlines absolutely. In Israel, they just had some mandate recently that websites need to be accessible there. In the US, the Department of Justice has been starting to put more weight on the accessibility guidelines that we have. So we have Section 508 and Section 504 which are parts of—so government funded websites have to be accessible. And I’m not super knowledgeable with the legal situation there.

Someone who is really knowledgeable is Lainey Finegold and she just wrote a book called Structured Negotiations like going on around the interwebs this week. And she is a disability rights attorney with years and years of experience in these kinds of lawsuits. And so just this past week there was an accessibility summit and she did a really great talk and her book probably has some of the same information but yeah there’s absolutely more weight being put on digital businesses. Like if you are a big application or product that a lot of people use, like airlines, banks, you know, public accommodations that people need to use—it’s not okay anymore to completely ignore accessibility and so the legal system in the US is starting to recognize that. It’s pretty slow. We’ve been waiting on updated digital guidelines for years and so that’s a bit of a drag. There is a lot of legal risk so, yeah, you’re right, eventually—

Katie:

That’s one way to move the schedule up and time line to be a little quicker.

Marcy:

It is, yeah, that’s sort of why I say it’s in between the carrot and the stick. Because that is the ultimate stick: the legal stuff and so if you need to resort to that, do it. It’s sad but true that that’s how a lot of accessibility progress is made. With the Air Carrier Access Act—that was actually really great, I had been doing talks on airlines, one in particular I gave a really hard time. I guess it was about two years ago. A big angular app that was—Wired wrote about it and they said it was sexy interface and whatever but it was completely inaccessible which drove me bonkers. But with Air Carrier Access Act, airlines are legally bound, as they should be, to make their websites, kiosks, mobile apps accessible. There’s part of that mandate that says they have to have user testing, which is amazing because that can make the biggest impact. If you’re technically compliant, it doesn’t mean that it’s usable or user-friendly but if you’ve tested it with users, you can really make something awesome that works for a lot of people.

Tim:

Do they have specific requirements about like the degree of user testing? Or how you go about—I just think that’s really interesting. I didn’t know that was part of the—

Katie:

Yeah, will they release case studies?

Marcy:

Hopefully, yeah. I haven’t gone through the process so I’m not super knowledgeable about it but I know that that is one of the biggest wins in that Air Carrier Access Act is that they included user testing. So it’s taken organizations awhile. I think they extended some of those deadlines cuz it was like—some companies, you know, I think the deadline was like last December and in November, they were like, “Hey, what are we gonna do about this Air Carrier Access Act? Like, can we get accessible in a month?” And for some of those systems, I mean airline systems have been around—they like layer on top of each other and they’ve been around for awhile so getting things to be accessible when you have that much legacy can be a challenge. And so it’s just really interesting that that’s how progress is getting made for airlines. It was a legal mandate, so there’s a lot of value in that.

Tim:

Well, I would pay good money actually to sit in on a talk where somebody did a case study of that. Like, taking a huge legacy airline site and making it accessible. If anybody is listening and was involved in that, you have to turn that into a talk because—

Marcy:

That would be amazing, yeah.

Katie:

Yeah.

Marcy:

Well if I hear of anything I’ll let you know. I go to an accessibility conference every spring called CSUN. It’s Cal State University Northridge’s Centre on Disabilities—it has like a ridiculously long name so we call it CSUN. But it’s an accessibility and technology conference that’s been running for thirty years—I think thirty-one years—I forget what year it is now. It’s older than me. But this conference, I mean people come from all over the world to talk about accessibility and so often there are people from airlines, banks, that’ll come and do sessions. So if I see anything that is along those lines I’ll be sure to let you know.

Tim:

That’s incredible. Is that conference equally accessible like if somebody’s listening and is just getting into—is that equally accessible to somebody just starting with accessibility or is more angled towards people who are knee deep in it?

Marcy:

Oh, it’s for everybody. I went a couple of years ago. I’d been working as a web developer and I was really interested in accessibility but I wasn’t at an accessibility vendor. It was just purely out of self-interest. So I went and it was one of the most beneficial things to me personally and in my career that I’ve done. Now it’s sort of part of my job to go and do talks there. There’s all different kinds of levels, some of them are technical, some are not. It’s interesting the variety of stuff that you get. There’s a big scientific track as well so people—because it’s through a university there’s scientific talks and papers that people put in too. It’s a bit of a big party. I love it. I love that community. But there’s all kinds of topics and case studies that people come and talk about. If you can make it to in San Diego in March, I would highly recommend going to CSUN.

Katie:

Awesome.

Tim:

Thank you so much for this. This was fantastic, in fact—

Katie:

This was amazing!

Tim:

Yeah, this was one of—definitely one of my favourite conversations we’ve had—like really, really good.

Katie:

I’m just like zoned out. Like I was listening to a podcast about accessibility. Just like, “Wow, I’m learning so much”

Marcy:

You’re like, “Wait, this is my own podcast”.

[Laughing]

Marcy:

Cool, well I’m glad to hear that. That’s awesome.

Tim:

So if anybody wants to keep up with what you’re doing or if there’s—if they wanna follow you and what you’re working on and stuff—where would people go to do that?

Marcy:

Ah, sure. So my Twitter: @marcysutton is probably the easiest cuz I often post things that I wouldn’t post on my own blog cuz maybe I’m highlighting someone else’s work or—my Twitter account’s pretty active. My blog Accessibility Wins I still update periodically, I need to go update it with some new content. But those are probably the two easiest ways to keep track of what I’m up to. I have my own site too, marcysutton.com. I tend to save those posts for like bigger epics. Like if I’m writing something—like there’s a blog post about accessibility and performance there. That one I really wanted to capture everything I had forgotten to say in a talk or wasn’t quite the right format. So I write about things there too. Those tend to make the rounds whenever I write something. But right now—oh, I’m also an Egghead contributor, I post videos on Egghead on how to do accessibility so there’s that as well.

Tim:

Oh yeah. Very good! I’ve actually watched a few of those, they’re excellent…

Marcy:

Whoo hoo!

Tim:

…and they’re free, right?

Marcy:

They are, yeah. Only free ones so far.

Tim:

Awesome. Well thank you so much. This was awesome.

Katie:

Yeah, thank you.

Marcy:

Yeah, thanks for having me.

Tim:

Thank you for listening to this episode of the Path to Performance podcast. You can subscribe to the podcast through iTunes or on our site, pathtoperf.com. You can also follow along on Twitter @pathtoperf. We’d love to hear what you thought, so feel free to drop us a note on Twitter or leave a raving and overly kind review on iTunes. We like to read those. And if you’d like to talk about being a guest or sponsoring a future episode, feel free to email us at hello@pathtoperf.com.