#222 Marcy Sutton photo journalist turned web dev and accessibility expert

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

[00:00:00] Marcy Sutton:
You're making other choices about how to code something and how to implement something. So putting some accessibility stuff in there is just, I just considered it part of that regular decision making process, and I didn't ask for permission. I would just do it, and sometimes it did require me to stay a little bit later. because I was still learning and still trying to figure it out, but I'm pretty sure I would have been trying to figure out whatever it was anyway, even if it wasn't accessibility related, it could have been some kind of advanced scripting with JavaScript that I was trying to figure out too. So I think it was just the staying late to get it done Factor was more of a, a mark of my experience level at that time. But I, I do look back at that time, kind of with a, a fond memory of just being kind of a rebel and just doing it. Anyway, ,

[00:00:58] Tim Bourguignon:
Hello and welcome to Developers Journey, the podcast, bringing you the making of stories of successful software developers to help you on your upcoming journey. I'm your host Tim Bourguignon. On this episode 220, I receive Marcy Sutton. Marcy is an independent web developer who focuses on accessibility, accessibility testing, and user experience. Her contribution was recognized by O'Reilly in 2016 with a web platform award. When away from the keyboard, Marcy can be found hiking with a dog, riding bicycles, adventuring in her camper van, or cooking something delicious. Or by the time you hear this podcast, maybe she will be busy doing something else. We'll see if we talk about it. Marcy, welcome to dev journey.

[00:01:46] Marcy Sutton:
Hi. Thanks for having me.

[00:01:48] Tim Bourguignon:
Oh, it's my pleasure. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the Dev journey lights on. If you would like to join this fine crew and help me spend more time on finding phenomenal guests than editing audio tracks, please go to our website: devjourney.info and click on the "Support me on Patreon" button. Even the smallest contributions are giant steps toward a sustainable devjourney journey! Thank you. And now back to two days' guest. So Marcy, as you know, the show exists to help the listeners understand what your story looked like and imagine how to shape their own future. So, as is usual on the show, let's go back to your beginnings. Where would you place the start of your dev journey?

[00:02:40] Marcy Sutton:
Gosh. Well, I think the most relevant part of it is when I entered the workforce after college, I had in my mind that I was going to be a photojournalist, and that's what I studied in college, but I entered the workforce right as stock photography websites were coming online and everyone and their mum was a photographer, which is great, great for them, but the job market was severely impacted to the point where working at a newspaper was not going to pay the bills and keep me employed, especially as an entry level photojournalist. So I had to pivot, and I had really enjoyed. Any programming classes that I took in photography school, and I'd built websites before that too with Geo Cities and geeking around on computers, So that gave me some confidence that I could pivot into web development, and that's really where my, my journey started, was going, I think I need something more reliable in this job market and that pivot. Absolutely the right move to make

[00:03:54] Tim Bourguignon:
So did you just snap your fingers and boom, you were web developer?

[00:04:00] Marcy Sutton:
I tried that. . It's kind of funny, I, I did some quote freelance. You could see me doing air quotes, but I didn't know what the heck I was doing at all. And I do admire, like, look back at that time and admire the confidence that I had when I knew so little. When you really get in over your head, and I could sell people on letting me build their website, but could I build it? Probably not.

[00:04:28] Tim Bourguignon:
How did you pull it off?

[00:04:30] Marcy Sutton:
Websites that just didn't really meet the needs. But I mean, come on. If you're hiring someone who's like early twenties, who. I don't know how confident or like how professional in experience could someone really be at that point, especially at the prices that I was charging. So, I mean, I, I don't feel bad really because I look back at that time and like they come on, they had to know what they were getting, what they were for coming . Yeah. Or just, yeah, it's like hiring students, you know, you're getting student work and so the expectations are, are, should be aligned with that. Um, and they had something, you know, they got a website out of it. It just might not have had a fully functional e-commerce solution attached to it. And in the, gosh, that would've been around 2006 maybe. And so the tooling and available options for things at that time was very limited. I was playing with Drupal and stuff, which was Ooh, okay. Hard. It was hard. But I ended up going to school again at the Art Institute of Seattle where I could continue with this creative direction, cuz I had all this photography skill. But I really applied it in a web development program and tied it all together. And kind of what came out of that was this narrative storytelling. Ability where I could translate things visually into something interactive and something on the web, cuz that was what I was so passionate about. And so that's really how I went from photojournalism into a more lucrative and steady career as a web developer. And through that Art Institute experience, I got an internship at a design firm in Seattle, and it was that networking piece of an instructor at school connected me with a design firm and that, I think that's my first piece of advice is that networking piece is critical. Who, you know, really,

[00:06:35] Tim Bourguignon:
Unfortunately, I must say it is, it is massive. It really has so much of an impact. You can apply all you want if you have the right connections. It's so much faster, so much more efficient. You get open doors. This is. I'm torn between amazing and appalling.

[00:06:52] Marcy Sutton:
Mm-hmm.

[00:06:53] Tim Bourguignon:
It's, it depends on, on, on which end of that you are. So, Yeah.

[00:06:57] Marcy Sutton:
And that's harder now. I was gonna say, it's harder now that we're all remote because you're not necessarily connecting in person in the same way. So that's, that's a unique challenge that we have now, which we didn't in 2006 or whenever. That was

[00:07:13] Tim Bourguignon:
kind of, I mean, if you were putting the effort or, or if you had the right, the right connection from the get go. Did, did you do it intentionally? Back then?

[00:07:20] Marcy Sutton:
I guess 2000. So the time I'm actually thinking of when I went from student to working in the industry was more around 2009. Mm-hmm. . And part of it being a school program was that you had to get an internship as part of the program, so mm-hmm. , I think that was something I was kind of forced to do. Okay. But that, that's a good thing. It was. It, it, the downside of that is you're in school, so you're paying for tuition and you're trying to go get a job. So it's sort of unfair to the student in that position because you're paying to get work experience. But hey, it, it ended up being really worth it cuz I made that connection and I got my foot in the door. Mm-hmm. , which is the hardest part.

[00:08:07] Tim Bourguignon:
Mm-hmm. where I'm jumping ahead, but how did you, what was your strategy in, in the subsequent years to continue this networking when you were not forced anymore to do it?

[00:08:20] Marcy Sutton:
Going to events. So that first design firm job. Was great. It was great experience, but I was the only in-house developer, and so I felt like my learning, like learning opportunities were a bit limited. I didn't have peers that I could really learn from and kind of a programming collective, and I really yearned for that experience and so, I was still had my sites on companies that had more of a programming discipline, and I found that by going to local events, and at the time it was the AIGA, the American Institute of Graphic Artists, because I had come from art school and so I was kind of tapped into the design side of things, but that was because it was design and development were so closely coupled and in agencies, I was able to get into development jobs kind of by going to these AIGA events. So I land ended up landing at a bigger agency where I could work with other developers, and that's where I found accessibility. So once I found that, My whole career path just it, it exploded. And so, yeah, I was kind of always looking for what's that next thing that I want to learn, You know, where do I wanna get to? And accessibility I luckily found along the way. But in agency life, you're producing work on a fast timeline and it, the website might only live for 30 days or three months. Mm-hmm. , so it doesn't have that long life that you really look for with software quality and testing. And I remember turning to my coworker, being. Do we do any software testing? Like what's this testing thing with automation? And he, he said, No, we don't really do, You can go figure it out on your own though if you want. like, does this work? I don't wanna, like, who wants to work in their free time for no reason. So I was already looking to the next job then, you know, I'm already looking to find a company where software engineering is more professional and. Long living, you know, long living software applications that have a higher quality. And so I was always looking over the horizon to, what's that next thing? Where do I wanna get to with my skillset? And accessibility was constant, but I kept trying to push my software engineering experience and not get stuck.

[00:10:51] Tim Bourguignon:
Mm. I see. How did this accessibility topic enter your, your daily life, if you were on, on a, on a schedule, really pushing, pushing, pushing. Probably just probably very driven by, by customer demands and has just to meet what they want and you don't do any, any gold plated stuff on top is just bare minimum. And outdoor. How did accessibility come in?

[00:11:14] Marcy Sutton:
Yeah, well it's interesting, so. . My first lesson in accessibility is that in the United States at least, there is a legal reason if you get sued for accessibility in the court system. You are obligated to make your website more accessible. And it's unfortunate that it works that way because that's so reactionary. And if we could be more proactive about it, we can do much more interesting work and actually design accessibility into. What we're creating. But I was assigned to work on the Target account, so this agency had really great clients, like huge names. I'm, I'm still really proud of the fact that I got to work with such big brands and target the US retailer being one of those. They had been sued for accessibility. . And so as a developer on that account, I had to learn it. I had to teach it to other people. Mm. And that was really where it was born. And it was interesting. That wasn't the only brand that I would work on. Like I would work on Nintendo or Xbox or whatever was put in front of me at the time. And I would sneak accessibility into those projects too. , which those clients didn't have it written into their contracts at the time. They didn't really care. Now they care. It's, they've either been sued now or. It's just more mainstream. Mm-hmm. . Cause that was probably around 2011, 2010, 2011 timeframe. And so it's definitely more mainstream now and more companies have had litigation. Mm-hmm. . So it's, it's been cool to, to see it grow and the, the people aspect is what's kept me fascinated, like the legal part. That was kind of the impetus for me getting into it was the fact that this client had been sued and it became a requirement. But what kept me interested was learning that there's people who wouldn't be able to access our websites and web applications otherwise. That got my attention. Like that's really what made me care was like, Oh, whoa, if we don't do this, we're discriminating. Mm-hmm. like how you can't, I couldn't forget that. Yep. That was just permanently implanted in my mind that. This is just what you do. And so every now and then I come up against someone who tries to say that it's not a wise business decision or it's why bother for small percentages of users. And I just, it's such a different mindset than how I operate. I'm like, Why not ? Yeah. It could be you. You could have a disability tomorrow that's, it could be your child, your parent, it could be anyone. So I never, Yeah, it's hard for me. Empathize with folks who are just so like closed mindset when it comes to accessibility because it's really, it's a quality issue. You know, It's like if you're proud of your craft and you're really, you care about what you're putting out there, like why wouldn't you wanna make it accessible and solid and robust? But then it's also a civil rights issue, so, With all that information, Like how do people still have this discriminatory mindset? I just, it baffles me .

[00:14:34] Tim Bourguignon:
I, I hope we're on the, on the, the, the late tale of this and, and it's soon will be, will be in the past, but yeah, I, I remember what, what opened my mind about this was a conference talk by one of the accessibility experts of Mozilla back then. And he was very interactive, so he was, he was asking for websites on stage and people were just throwing websites, and he went at it as if it was blind, and looking at it, Okay, how would I go at it if I was, And the websites were so crappy, it just couldn't navigate in anything cetera. It was just, And at some point he found one that was really well written. And he said, Okay, now let's explore this one. It has all the tags, so the H1, H2, H3, I can search the content. I see navigation. I can go here and there, et cetera. He was faster than everyone in the room to find information, how those pages structured, et cetera. And so he said, Well, accessibility starts with the small things. If you page is well structured, you can navigate If all the elements are there, you can navigate, you can see what's there, et cetera, and you don't have to to have fancy UX designs, et cetera. It starts with a small thing, and if you have this already, it's already a good step and then make the next one. It just re blew my mind. Before that, I was really imagining, okay, now I have a giant checklist of stuff I need to go through and I have to pay attention to this or that. Yes, at some point, but start with one step, and then another one. And it really, uh, de dramatized this starting there. And really from there, from from there on, accessibility was always there, but really needed this, this, uh, wake up call. I, I say

[00:16:09] Marcy Sutton:
yeah, the fundamentals, they really are important to remember cuz it can be overwhelming. Just before this call, I, I was working with a client and he was sort of like, Hard on himself for missing out on, you know, not being able to keep on top of everything. Mm-hmm. , and that can be overwhelming. And so I always just say, think of the fun fundamentals, you know? Mm-hmm. , you're working with semantic elements, like you were saying, your headings and. Other semantic structure and then making sure can you reach and operate everything interactive with the keyboard. Mm-hmm. , like, start there because there's, Yeah. It can get really complicated when you're trying to meet the demands of a creative team who's just, they're so thinking about the mouse user experience mm-hmm. that trying to factor in how is it, how is this gonna work with the keyboard? Like if you just think through and, and actually test how does it work with the keyboard? It can make some of those complex questions. Just the complexity just sorts of melts away because you just get down to the basics of like, how does this function, Can I use it? And so good solutions emerge when you just try to keep it simple. and ditch your mouse for a day. .

[00:17:27] Tim Bourguignon:
That's a crazy experience. , but we should all do it.

[00:17:30] Marcy Sutton:
Uhhuh, one day a week at least. . Yeah. ,

[00:17:34] Tim Bourguignon:
did you manage to, to shut down this part of your brain when you navigate? Not not for, not for work, Navigate around or you always wearing these, these accessibility goggles.

[00:17:44] Marcy Sutton:
Ugh. It, it, it is really hard to shut off, but I still use my track pad on my computer. I mean, I, I do have to make sure that I'm testing in all the places. So I'd say I, I do kind of keep a, a balance somewhat, but I'm also always trying to remember that. because I am able bodied for the most part. I really don't wanna assume that I know, like we need to get feedback from people who are disabled, who really do need the keyboard and do need screen readers and do need voice navigation because they're gonna give us such great insights about things that we just, we think we know, but we don't. And so, I try to keep a healthy reality check that I, being a very experienced person, that's still, I still have biases and I still don't necessarily have the, the perspective that's necessary to get the best feedback on something. And so I think that's okay. We just, we have to remember that when we're in our work and we're making recommendations and people are trying to decide like it does this work or, or is our job done? It's, my answer is usually, Okay, well who can we get this in front of? Who actually does rely on the assistive technology so that we can make sure that it works?

[00:19:03] Tim Bourguignon:
Very good, very good approach. When, when did accessibility take over your, your daily work, meaning? You were not doing websites and doing accessibility on the side, but really focusing on accessibility in your day to day work?

[00:19:16] Marcy Sutton:
I would say it was pretty much a direct switch, uh, back in like 2010, 2011, because I weaved it into my daily development practice. Okay. And I, being a web developer, have really tried to keep development at the center of what I'm doing and so, I didn't like morph into an accessibility auditor who produces spreadsheets, and I've had to really maintain that boundary. Like people ask me, Can you audit our site? And I go, Nope, I can't because I am a developer and I don't wanna get stuck producing spreadsheets. I just don't. And that's important. Like don't get pushed into making, you know, deliverables that you just don't really wanna do. HTML email is another one that I remember. Like if you put it on your resume because you have experience in it, guess what? You're probably gonna get more work doing that thing. So be, be thoughtful about it, , because if you want to be coding user interfaces like I do, or you want to do something that you're really passionate about, you have. Put effort in that direction to make sure that you don't get led astray. Mm-hmm. , you know, not get accidentally turned into a project manager just because somebody thinks you're organized and it happens to women intact a lot. I've, I've been there too, and so I've had to corral my career back, get it back on the rails of where I want it to go. . And so being very clear about what deliverables I'm willing to work on that, that it comes up all the time in my consulting career. And so I try to just be really clear that I am not an accessibility auditor because I don't wanna produce, use spreadsheet. I could test your user interface. And it's almost like working on a team as a, a lead or staff level engineer. Testing something out and giving feedback, like I might not be the person to implement the fix, but I can talk with engineers kind of on an architect level and give feedback and code reviews and maybe write docs about it, but that's not my favorite either, So yeah, I guess that's piece of advice Number two is figure out what tasks and day to. Things really just get you in a flow state because you wanna hang onto that. Otherwise, work is such a grind, , you can get so far off track and then be like, Oh no, I don't, I don't wanna do this.

[00:21:48] Tim Bourguignon:
you realize after the fact, you realize that after the fact and say, Shoot, where, where, where did I take the wrong path?

[00:21:55] Marcy Sutton:
Come on. Yeah, . I actually had a director level person say that to me at once. He's like, you know, I really, it's almost like I heard this guy go through the thought process as he was, He was confining in me that he completely understood me not wanting to become a project manager. And just like, I remember him saying, as a friend, I support you in sticking to whatever career path you want. And, and it was almost like an act of saying that out loud to me. He went, Oh, shoot, I'm, I'm off track. And he quit and went back to engineering.

[00:22:28] Tim Bourguignon:
Yeah. Nice. I think it has a name even, isn't it, Peter's Law, I think it's a, people rise to the level of, to the first level of incompetency or something like this, where people are, are, when they're good, they just get raised and get raised, get raised, and then they come up to a place where they're not happy anymore. Yeah. And, but a few have the courage to say, Well, no, and let's go back to one level down where I really was happy. Yep.

[00:22:56] Marcy Sutton:
You have to watch out for that

[00:22:58] Tim Bourguignon:
You do indeed. You do indeed. When, when you were trans... I mean the transition was pretty fast, but when you were not, not known in the accessibility space yet, how did you find the right projects to work on, where people would care, what people would listen to you and would let you? Explore this thing that might not be a given for everyone. Where some people might say, as you said at the beginning, Well, we're just going fast. We're just pushing products out the door and the testing, No, we don't test. And so I, It might react the same with accessibility. No, we don't Accessible . I'm not sure that's a word, but so how do you, how do you find those projects so that you are, don't end up doing one project after the next, which doesn't let you do.

[00:23:39] Marcy Sutton:
Hmm. Good question. I mean, at the time I was lucky enough that it was a requirement, . Okay. So it was a, it was part of the expectation that I learned it, and that was just part of it. But for those other client projects that I was working on at the same time, those didn't have that same. Contract requirement and so I just did it anyway. Okay. , you're not purchasing, I mean, this is, I mean, you're making these subjective choices about how to build something and you know what CSS class names to use and how to, You're making other choices about how to code something and how to implement something, so putting some accessibility stuff in there. I, I just considered it part of that regular decision making process and I didn't ask for permission. I would just do it and sometimes it did require me to stay a little bit later because I was still learning and still trying to figure it out, but I'm pretty sure I would have been trying to figure out whatever it was anyway, even if it wasn't accessibility related. It could have been some kind of advanced scripting with JavaScript that I was trying to figure out too. So I think it was just the staying late to get it done Factor was more of a, a mark of my experience level at that time. And. But I, I do look back at that time, kind of with a, a fond memory of just being kind of a rebel and just doing it anyway.

[00:25:11] Tim Bourguignon:
I'm sure you still are, but I think I just realized bias of mine in the question I asked you. I think I assumed that doing. I'm making air quotes now, accessibility work is gonna be on top and your answer was no. You're doing it right. And it doesn't necessarily take much more time. Sometime it does, but, but not necessarily, or most of the time, and that's how I interpret your answer, most of the time it's just doing it right from the get go and it will be accessible, but you're not putting extra effort to make it accessible. So just do it right. And then it will be in your day to day work and that. Did I get that right?

[00:25:51] Marcy Sutton:
Yes. I, I do think that it, there are some very realistic in time that it does take, and I've heard some estimates up to 30% or so. Okay. Like if you want to sort of pad estimates up front, but that's across an entire project, like including requirements gathering and design. And cuz we can't try and shoehorn in accessibility in the development phase like, There's some patterns that just you, you can't code your way out of and make them accessible. But where I really think it, it adds time is, is in testing. Like we have to test more places. We have to. Spend more time than just clicking through with a mouse. So that is a very real thing that we have to factor in. And sometimes that's where teams give pushback. But I mean, the alternative to not doing it is way more costly. Like that 30% upfront is such a worthy investment because you make a more robust, better designed product or or whatever you're making. And if you. If you didn't do any of that, trying to do it after the fact is gonna cost way more time and money. And if you get sued, then that's just the worst. Mm-hmm. . So there's like, it does take some investment upfront, but it's so worth it, especially because if it's accessible, that could mean more customers, like more people can use it And if you're the only. You know, if you have competitors and you're the only product that's actually somewhat accessible, guess what? You're gonna win out because you have more competitive edge in among users and in spaces where accessibility is a requirement, like in education and government, there's all kinds of spaces where to be procured as a software solution. There are legal mandates that things be accessible, and so trying to add that in after the fact nightmare. I mean, try to make something mobile friendly after the fact, like, Good luck with that ,

[00:27:59] Tim Bourguignon:
what you did, sprinkle some responses on top of it and it works, doesn't it? Yeah.

[00:28:04] Marcy Sutton:
That's, that's very expensive to do.

[00:28:07] Tim Bourguignon:
Yeah. As you can see, I, I've been away from, from development for a while. So Now I imagine your sprinkling stuff, , I don't wanna go into the checklists, but on, on top of your mind, do you have a few examples of, of things that are really no brainers? To develop nowadays and which will really increase the accessibility and on the, on the, on the older end of, of the scale, things where you say, Okay, this is where I get the most pushback, pushback from teams. When I say, Hey, we should do this. I say, Oh no, this is really gonna be hard. Or, or, or taking us a path we don't wanna go into maybe some examples of both extremes.

[00:28:42] Marcy Sutton:
Sure. Yeah. I think a lot of the semantic. Stuff that we can put under the hood is an easy win. Like using headings, you know, H1 through H6 headings to create a content structure. Those are great and screen readers because you can navigate by headings and navigate around the content to kind of get an overall picture non visually of what's on the page and other similar semantic HTML elements, at least in the web space. And so those are easy wins because you. Putting those into your code as a developer and that who's gonna push back on that Mm-hmm. . So that's easy and it can really help with the non-visual experience in a assistive technologies. keyboard access is amazing too, cuz if something only works with a mouse, it just, it is such a shortcoming of an application to have things that don't respond to keyboard access, screen reader access for interactivity kind of layers on top of that. So yeah, we have to have the keyboard parts to enable screen reader interactivity on top of that. I guess the question,

[00:29:53] Tim Bourguignon:
when you mean a keyboard access, you don't mean just the tab order, you also mean probably the, the visual cues of where you are, the maybe shortcuts going, going here and there, interacting and entering, for instance, on a, on a, on a button. That's really. triggers the whole form, et cetera.

[00:30:08] Marcy Sutton:
Yes. So reaching that tab order piece that you were mentioning, so being able to reach something with the keyboard. Mm-hmm. , that's usually where it starts to fall down immediately is something's just like a click event on a div and you can't, you can't reach a div so making things, buttons and really keyboard interactive and making it sure that you can see where you are on the screen. So having some sort of a visual outline or indicator. Mm-hmm. . Mm-hmm. . And then you. More sophisticated patterns from there where, yeah, there's other, other navigation conventions like using the arrow keys for certain patterns or the escape key to close things. And where I really enjoy getting into is the sort of nitty gritty of JavaScript patterns and applications where you're managing keyboard focus around the application and trying to make that more ergonomic. And it can get, it can get complex for sure, but there's an opportunity to do stuff that's really intentionally accessible and ergonomic that you couldn't do with a plain HTML document. Mm-hmm. . So I live in this space where I don't make out JavaScript to be some kind of villain. I think it's, it can be used responsibly to create things that are way more interactive. Mm-hmm. that are more aligned with what users expect nowadays. . So I love JavaScript, but we want to be responsible with our use of it. And that's unfortunately where a lot of the problems come in is that like with JavaScript click events you like, everything is a nail within the hammer. You just like, Oh yeah, , make it clickable, . And there's some fundamentals missing there about interactivity. And so yeah, interactivity is one of my passion points of web development because it's user driven and really trying to architect code solutions that are robust enough to, like, maybe you wave your arm in front of a screen and it, your code is architected in such a way that you're like, Oh sure, we can make this respond to this event cuz it's coded in a professional way or whatever. So I think the, the keyboard piece is all about that interactivity. and where I see pushback, I mean, usually it's just a lack of education and people get real. I don't know. I had someone just this like two days ago on Twitter, be really naying about the value of accessibility and it was kind of around this space of like, it's too few users to care. Man, they got schooled. But , that's totally not the case. But an area where I do get active pushback sometimes is in design. Like if we're using a lot of iconography that doesn't have text labels on it and or color schemes, it's usually like that translation from design to development. Mm-hmm. , sometimes you have to go back, have a discussion about how to change the design so that something is more accessible. that can get a bit tricky because sometimes that, like if it's in the brand guide, the colors that we're using, that's like a huge conversation that you might not win. And so it, it can get complicated like the more. Like the larger the problem space grows across disciplines. Mm-hmm. . Mm-hmm. . Mm-hmm. , like creating something that's more obvious to users and not this like slick patterns that you have to interact with to even know that they're interactive, like dots that are buttons that don't have labels on them, or. There's all kinds of patterns like that where I think if our creative colleagues were seeing someone use voice dictation or a screen reader to navigate, they'd go, Oh, Oh, okay. I see . I see the problem. But they're so, we're so disconnected from these different experiences that sometimes as a developer, you're the messenger to try and. Get this empathy or compassion piece and depending on the power dynamics in your work. Whew. Trying to get, trying to manage up and trying to like inject feedback back in a process where the clients maybe even already signed off on something. That is where it gets tricky. Yeah.

[00:34:36] Tim Bourguignon:
All right. How would you approach such a discussion? I mean, would you go right it with examples with, Hey, have you thought about this kind of person in this context? Who wouldn't be able to, to tackle it and see how people react? What works, what doesn't?

[00:34:52] Marcy Sutton:
Yeah. Well, it ultimately depends a lot on who you're working with and kind of what persuades their personality types. That's true. Yeah. . So there's kind of a people skills angle that you have to consider, which is hard. , it's like, you know, not, not in our job descriptions to be psychologists, but , but often, but often using standards and guidelines like the web content accessibility guidelines are pretty hard to argue with. So using something like that to have clear requirements, So make it more concrete than an opinion. and really how you message it, and this is the art of accessibility, is like being professional and friendly, but firm about it at the same time. Like you don't wanna be adversarial, but you wanna be real about what's at stake. Mm-hmm. . And so just being very informed and clear about what the problem is and how to solve it. Like the more information that you bring to that discussion, the more likely it is that you're going to. Action on it. Mm-hmm. , but always, yeah, trying to highlight the user impact. That's really important because when you have, just have so much on everyone's plate to try and prioritize things. User impact and kind of, you know, how, how critical is this problem? It can just help us sort through the, the large volumes of issues that we need to prioritize. And so the web content accessibility guidelines can help a little bit there because there's different levels. There's A and AA, and sometimes I'll find an issue and be like, Man, that's, you know, I found that issue. It's real. It seems really important. And then I look at the Tag, which is. Short shorthand name for web content accessibility guidelines. If it's AAA, it's like, okay, well that's, that would be nice to fix. But we have all these single A issues like keyboard issues and really like fundamental problems, like we have to prioritize those first. Mm-hmm. . And so kind of thinking in this user impact priority way of working can help cuz then it shows your teammates that you're. You're not just coming at them with like every, every problem that you can find and you're like emotional about all of 'em because like, ah, I care so much. It's like, well, okay, we have to prioritize somehow. And I feel like that's kind of a more of a senior lead level skill that you develop. Is this, I don't know, skill to be able to prioritize and scope things. Mm-hmm. . So the more that you can kind of pre scope or pre-filter, Yeah, all of those. It helps the discussion. All those ingredients. Yeah. You're coming at your team. Really help me. Help you or . Let's try and get some answers and be clear on what it is that is the problem and who it affects. Mm-hmm. , and we can work through how to fix it.

[00:37:55] Tim Bourguignon:
Indeed may, maybe, maybe that's gonna be the, the, the advice I'm gonna ask for you I mean, you gave, you gave a lot of advice already, but are there some, some tools beside the WCAG that can automate part of this and give you really some, if, if you're more junior, if you don't have the, the seniority to really stand you on both feet and say, Hey, we have to do this and you need. Some help in convincing there some tools. They can test your, your website and give you, I know the top 10 A single A's that can tell you. Well watch out, do all the low hanging fruits and you're not covering this and you should really start there. Is there something to, to, to, to, to back you up.

[00:38:32] Marcy Sutton:
Yes, there is, and that is a really helpful thing to know about. So there's tools like the Axe extensions, it's Axe. That same underlying accessibility API is also part of another tool from Microsoft called Accessibility Insights. And so either of those tools, they're browser extensions that you can run and they will highlight issues. And tie them to the web content accessibility guidelines. Mm-hmm. , the challenge is that those automated tools only cover a, a percentage of what can be found, You know? Mm-hmm. , if you have a human tester, they're gonna find a lot more stuff. So the estimates I've heard from the kind of semi-automated. Checkers like that are anywhere from 30 to 50%. It's kind of slowly creeping up, but it's always gonna be a subset of what can be found. Mm-hmm. . And then doing that, the keyboard testing pass that I was talking about, like tab through, can you reach and operate everything that a mouse user can do and the access accessibility extensions. Sometimes they don't know what they don't know. Mm-hmm. . And so if you have click events on divs, They aren't gonna find that necessarily for various reasons. And so that's where some manual testing comes in. But those keyboard issues are often a, a level A violation in WCAG and so, mm-hmm. , That one is pretty foundational and worth becoming familiar with because the extensions won't catch it. And you can go to your team with really concrete reasons why. We need to fix this. This is a level A violation for WCAG, but the stuff that is uncovered with the extensions, is amazing cuz it highlights it for you. You didn't have to find it with your, your own eyes and and hands and it will give you some suggestions of things to fix. And so if you get through all of that stuff and fix it, you'll be in way better shape. Mm-hmm. . So yeah, the tooling is, Awesome.

[00:40:34] Tim Bourguignon:
I, I imagine, How much are we talking about when, when you say, for instance, just the, the single A of WCAG, how are we talking about the document 500 pages along and, and 300 different points to look at? Or, or is it like the OWASP It's just the, the, the top 10 or top 20 things, uh, or somewhere in between probably?

[00:40:53] Marcy Sutton:
It's like, Man, that's a great trivia question and I'm actually really shocked that I don't know the number of success criteria. I think it's probably. around 50 maybe. Okay, that's a totally wild guess. So they're numbered. 1, 2, 3, 4. There's like four categories. Perceivable, operable, understandable, and robust. Mm-hmm. . And within those kind of four categories, it's broken down into different success criteria at the the various levels. And so if you only prioritize the level A and AA that. Not all of them. Mm-hmm. , it is more than 10, like the OWASP top 10. But yeah, I think it's, it's not 300 pages either... so

[00:41:34] Tim Bourguignon:
if it's in the ballpark or something like 50, I mean mm-hmm. this is manageable. You, you schedule learning one every, every day and you are almost done at the end of the month. And so that's, that's kind of a, bringing it back to a, to a smaller, manageable level. You're not, you're not drown into, into a document from the get go and just don't know where to look and, and you just skip entirely because too much.

[00:41:57] Marcy Sutton:
There are 78 in Waka 2.1. I just had to look it up

[00:42:02] Tim Bourguignon:
Let's make it two months . One per day in two months, you're done. Yeah.

[00:42:06] Marcy Sutton:
At least for the beginning. And not all of them will apply necessarily. Like if you don't have any audio or video on a page, you won't have like that won't be relevant. You won. Yeah. You know, you won't necessarily need to put a transcript or a closed caption on something if you don't have a video on it. They're not always relevant to the, the context of what you're working on, but there's definitely some basics in there that are worth becoming familiar with because they'll get you aware of things that you just might not think about, especially in areas like cognitive accessibility, making things that, like if you have,

[00:42:43] Tim Bourguignon:
What was this I didn't get that?

[00:42:45] Marcy Sutton:
Cognitive. So cognitive, Sorry. Yes. Yeah. If you have a, a learning disability mm-hmm. or traumatic brain injury or seizures or, and lots of things that affect how people interact with computers in different ways. Not necessarily mobility or being blind, but something with the way your brain works. So, There's success criteria for that too. Mm-hmm. . And so it can really, it just helps to give you a fuller picture of what to be thinking about. One thing I will say is that WCAG can be hard to understand sometimes, like it's a big standard document and. . It's kind of vague, like they are, They try to make it as as good as they can and it is awesome. But sometimes you're like, What? What does this mean, ? And so they're supporting documentation you can look at it's like understanding or how to meet or even just like if you know which success criterion you're trying to figure out, you just. Type it into the search and go look for other articles on it and things. There's, yeah, it's definitely understandable that not all of that stuff is gonna be immediately clicking with you. You know, it took me a long time to be able to use it at the level I do now too.

[00:44:00] Tim Bourguignon:
Like, standards always are. Yeah. Scratch your head and you read it again and again, and then you start to understand what might be happening, and at some point I say, Oh, now I get it. So you have to stick with it. Well, this has been very insightful. Thank you very much. I, I think I, I, it has opened a new door or a new window onto a topic I had not looked into for a while, so thank you very much for that.

[00:44:26] Marcy Sutton:
Thank you. Yeah, we really do need all the help we can get when it comes to accessibility, so always happy to be the messenger.

[00:44:34] Tim Bourguignon:
So where could people interact with you and maybe ask some more questions or start a discussion with you?

[00:44:39] Marcy Sutton:
Sure you can find me on Twitter @MarcySutton and I, You alluded at the beginning of this, it is call that I might be away from the keyboard. And so at the time of recording, I'm about two weeks away from having my first child, So she's been sitting here listening in the whole time and inside of my belly, but. I at the time that this airs, I will have, my life will look very different. So , who knows what my Twitter will be like by then, but I'll be starting to come back to, to tech stuff. And in the meantime, I'm launching a project called Testing Accessibility. And so that's a series of workshops that I've, I've done them live previously and so we're launching this self-paced online workshop that you can take. And so it. Text and videos kind of woven within so you can learn at your own pace. So that will be ongoing from, you know, the time of recording this podcast onward. It's sort of like Kent C Dod's, Epic React or testing JavaScript. Mm-hmm. , but accessibility focused and it's got both technical stuff and kind of design thinking and more of this people skills type stuff that we've talked about. So, I'm sure I'll be in and out of the tech space just to keep that train going cuz it's, I have these two giant launches, like literally within two weeks of each other, so it's pretty wild.

[00:46:07] Tim Bourguignon:
So good luck with that I know there is one to prioritize over. the other one

[00:46:10] Marcy Sutton:
there is funny timing.

[00:46:12] Tim Bourguignon:
Yes. It, it always is , but I'll add links in the show notes to all the, the, the, the things you mentioned, your testing framework, testing a course, your Twitter, the different extensions we talk about, and the, So just a scroll down and you will find all this right away at your fingertips. Marcy, it's been a blast. Thank you very, very much.

[00:46:32] Marcy Sutton:
Thanks so much for having.

[00:46:34] Tim Bourguignon:
And this has been another episode of Episode's Journey and we see each other next week. Bye bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you like the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appear on on our website Devjourney.info/subscribe. Creating the show every week takes a lot of time, energy, and of course money. Would you please help me continue bringing out dues inspiring stories every week by pledging a small monthly donation? You'll find our Patreon link at devjourney.info/donate. And finally, don't hesitate to reach out and tell me how this week's story is shaping your future. You can find me on Twitter. I'm @timothep or per email [email protected]. Talk to you soon.