Speaking & Events

Accessibility: A Catalyst for Change

September 18, 2024

I had the privilege of joining the legend, Mike Paciello, on the HearSay podcast. We talk about accessibility as a catalyst for change, working on productivity software, and how whether AI can help or hurt accessibility.

Event Details

Date: September 18, 2024

Video

Accessibility: A Catalyst for Change

Transcript

Gerard Cohen: I always tell people that accessibility is a catalyst and a magnifier for change, and it could be either good or it could be bad. Mike Paciello: Hi, and welcome to the HearSay podcast. I'm your host, Mike Paciello, Chief Accessibility Officer here at AudioEye. For the last decade, Gerard Cohen, a good friend of mine, has created and advised accessibility teams that have enhanced accessibility for millions of people worldwide. When he first started, I remember him enhancing accessibility on popular financial platforms at Wells Fargo, and then he has moved on to productivity platforms, including the pre-Elon Twitter. Currently, Gerard drives the Atlassian design system accessibility team, where he collaborates with an incredible team to bring accessibility features to popular platforms like Jira, Trello, and Confluence. Hey, Gerard, good to have you here with us on the HearSay podcast. We're really excited to have you, and I'm looking forward to talking to you. We talk about decades of being in the work of accessibility in your experience. Just from a personal level, what's your elevator pitch? How did you get into accessibility and what are the moments that you're most proud of through your career? Gerard Cohen: Yeah, it's interesting. So I've been doing accessibility enough to know that not everyone cares about accessibility in the same way. In most cases, it's something that people aren't just aware of or had exposure to. So a lot of times, people will, when I tell them what I do, will say something like, "Oh, I never thought about that," or, "I didn't think disabled people could do that or would want to do that." And so that's the first thing for me to make the point like, "Why not? Why wouldn't disabled people want to do that? After all, disabled people, they're still people." So after that, for me, it's important to know what that person does or cares about most and then personalize the message specifically for them. And again, it's based on types of exposure they've had to people with disabilities, but some people may automatically get the social and human aspects of it, and that's great. I love it when I meet those people. Some people won't — salespeople, they want to make more sales, so I talk about the uncapped market potential. People in legal, maybe they care about laws and regulations, and it's very easy to talk about that. Designers, they care about simplicity and providing a great experience for customers and users and talking to engineers. Engineers are pretty much always looking for something to set themselves apart in the job market at least. And even talking to QA people, QA people are interested in finding more bugs. So I tried my hardest to personalize the message so that it's a real connection. And as much as you can do that in an elevator pitch, the idea is not to sell someone automatically, but just to get them to ask and be interested and curious to learn more about it so that we could talk once we're walking out of the elevator, if you will. Mike Paciello: That's one of the things that I've enjoyed about our personal relationship. Now, you and I have known each other for at least 10 years, probably pushing 15, and I'm thinking back to our days at Wells Fargo, and one of the things that I've always enjoyed and appreciated about you is that you've got a well-rounded view of the entire ecosystem of accessibility. So for you, it really is about the user, it is about the user experience and making sure that it's an enhanced, optimized environment for people with disabilities. So I really appreciate your comments and thoughts on that, Gerard. Gerard Cohen: Yeah, it's something when you're working deep in accessibility, especially in the ways that I've been able to contribute, you kind of do have to be a person that wears a lot of hats, so you have to understand the social aspects of it, the legal aspects of it, and of course the day-to-day tasks around design and engineering and stuff like that. So I've been very fortunate to be able to work with a lot of great people, learn from a lot of great people, and ultimately, we're all looking for the same thing. We're just trying to make sure people can do what they need to do as quickly and efficiently as possible. Mike Paciello: Yeah, exactly. One of the reasons why we're so excited, I mean myself personally, having you on the show, is simply because of all the work that you've done in the industry, your work at Wells Fargo, your work at Twitter, and now at Atlassian, it's really sent a benchmark for a number of folks that are in the industry. Tell us a little bit about your work in bringing accessibility to the productivity platforms and the tools, the apps that you've worked on, you use on a daily basis. Gerard Cohen: So starting at Wells Fargo — and maybe we could talk about how I got into accessibility — but starting at Wells Fargo really set it off for me. But at that point, I was working on the commercial side of things, which is really our customers, we were providing products and services to small to jumbo-sized enterprises. We weren't providing accessibility for wellsfargo.com and checking accounts, so I couldn't do anything about that kind of stuff. That was a completely separate department. So me and my team, we worked on the commercial side of things, and it was software that people use every day in their jobs for business banking or payroll, basically the way businesses move money around. So very early on for my team, we understood the mission and we saw it as we need to make this software as accessible as possible so that disabled people can do their job effectively. And I think it's something like 22% of people with disabilities actually have jobs. So it's a very low amount of people with disabilities that are employed, and so many of those jobs that they do have are in environments that aren't prepared to support people with disabilities, unfortunately. A lot of times, even in the industries that we work in, a lot of times you're focused on external customers and you forget about internal. So the software that we were working on was for people doing their jobs. So with these environments that weren't set up for people with disabilities, it meant that disabled people have to work even harder and a lot of times without even disclosing the fact that they have a disability because of the fear of how their co-workers and maybe their managers and how people would treat them. So it became a matter of being able to contribute to the independence of people with disabilities, understanding that this is how people make a living and everyone deserves to make a living, everyone deserves to be independent and be able to do things on their own. And so for us, that was our mission, was making sure that people who were working with these companies and doing finance and accounting-type stuff, that they were able to do what they needed to do as easily as possible. And that was at Wells Fargo. It's the same at Atlassian. So here with a bunch of great people trying to make sure that everyone can benefit from increased productivity tools. Mike Paciello: Even in those commercial apps, were you able to actually work side by side with individuals with disabilities outside of, say for example, usability and user testing where maybe you call in a sample set of users who are using those apps? Did you yourself get to work side-by-side with people with disabilities? Gerard Cohen: I did. It was far and few between, unfortunately, especially with UXR, that kind of thing, because there were financial applications, there's a lot of regulation and legal requirements and all kinds of interesting things around that. So our customer base was actually really small in comparison to some of the other products that I worked for. It was really maybe 200,000 people at most, even though it was spanning very large customers. So the footprint was really small in comparison to, say wellsfargo.com or even Twitter or Atlassian. So the opportunities, a lot of times what you have to do is you kind of have to try to find as many people within your inner circle as possible. So finding people within the company that had disabilities and really talking to them. I got to meet a lot of really great people that I had no idea were across the bank — systems analysts, people that weren't even working in jobs related to user experience or accessibility. They were just doing everyday jobs. So it was very important for me to speak to them and make sure that getting their lived experiences was something that was really, really important to me. So whenever possible, meeting and talking to people internally was really important. Mike Paciello: That's where I think as an engineer and a designer, contextual inquiry as a methodology is a great thing to apply when we're working with individuals with disabilities because how they work in their personal workflow is not the same by and large as individuals without disabilities. And so to understand that, to grasp it, to watch a user go through an application and that workflow is something that I think every engineer and every developer should understand and go through. Do you agree? Gerard Cohen: 100%. I think seeing how people used the software that I was working on really, really impacted me in a different way. I have a story, actually. There was one project we were working on, it was an internal project, and actually, it was a hackathon is what it was, and the task was to redesign and re-event our internal time-tracking software. So basically, this is where you would go to if you needed to request time off or if you needed sick days, those kinds of things. And, of course, the team that I was on, that we assembled, was very much so interested in making it as beautiful and accessible as possible because the software we're currently using was not the best. It was really old, very legacy. And so, one of the things I did was, as I said, I reached out to a disabled systems analyst. He was actually a screen reader user, blind screen reader user, and I went and I just talked to him and asked him. I was like, "Hey, so would you mind walking me through how it is that you go through and request some time off?" And he was very happy to help. "Oh, sure." So he walked me through and he basically talked me through, "Okay, so I would start doing this, I would start doing that." And I think the second to last step, he was like, "And this is where I would stop." And I was like, "What do you mean this is where you would stop?" He was like, "Well, actually, I can't get past this point." I think there was a dropdown that maybe wasn't labeled properly or is in a completely different part of the screen, and he said, "I have to stop here." And I asked him, "So how do you request time off?" And he told me, he's like, "Oh, I have to have someone else do it for me." Mike Paciello: Unbelievable. Gerard Cohen: Yeah. To him, it was like, "Okay," and thankfully, he had people around him that were able to help him with that, but I thought it was terrible. Here's a person that needed help to ask for time off. And something as simple as that, something that sometimes may be private, you don't necessarily need to tell people that you're taking time off and those kinds of things. He would have to ask somebody to help. So there was a lack of enablement and independence there. So it was, hearing those kinds of stories and seeing people use software and the different ways they use it is definitely impactful for anyone who's in charge of or taking part in creating these user experiences. Mike Paciello: Yeah, that's a great experience and I hope the folks in our audience get too—that it resonates with them. It is absolutely critical that we involve users with disabilities as part of our design and our development. In QA, we tend to always just fall back on, "Well, we'll just have them test it, test it with a screen reader, test it with a screen magnifier." That kind of a thing. The reality is we get a lot closer to the accessible user experience that we're going for if we actually work side by side, walk them through like you did, and then hey, if we discover a bug or, in this case, a literal fault in the application, we could catch it then and improve it. Good stuff, Gerard. I appreciate that. Gerard Cohen: Yeah. If I can talk for a minute about the practical reasons why it's difficult. Anytime you could get someone with a disability to try out your software, and the best time is at the start. If not then, right now is a good time to do it. One of the practical reasons that a lot of people don't realize when they wait until the end is a lot of times, some of the things that you run into are very fundamental to the design or the functionality of the feature that you're actually building or designing. And when you wait till the end, a lot of times the people that were there at the beginning making those decisions, whether it was project managers or designers, a lot of times what happens is they've already moved on to a different project. Those decisions have already been made, they've already been approved. And so in order to say, "You know what? We didn't hit the goal here. We missed a very important factor," it's hard to make that decision to roll back, and this is a lot of times why you see experiences that may not be the most accessible actually make it out into the real world, because the best intention is, "Okay, we'll get back to it, but we all know that day, there's always something else to fill in that day that comes in the future when you're supposed to fix it." So it's always better to do it as early as possible because you may have to redesign something, and you want to be able to have the people that made those decisions take part in that and be aware of it. So it's also a learning experience too. They take that wisdom, that knowledge that they've learned, and they can apply it to everything else versus just trying to fix a bug or something to just move on to the next stage. So it is very important to do as early as possible. Mike Paciello: Yeah, I totally agree. I often encourage designers and devs alike: build a good, strong requirements document and a pattern library, and those should integrate all of the accessibility features and functions that we know are critical to the user experience. So that's a great touch point and I appreciate the experience, Gerard. So you've seen the benefits in a lot of the organizations that you've worked with and where by and large accessibility is being prioritized. There's usually a set of steps or maybe some sort of lifecycle workflow process that the teams use, yet we're seeing a shift in organizations where they're de-prioritizing accessibility initiatives, and that is so foreign from the world that you and I have come from over these last years. Why do you think that that's occurring? Gerard Cohen: Mike, I don't know if we have enough time to talk about how I really feel about this, but I'll say that I think it's mostly a lack of awareness and just a lot of misconceptions to accessibility. A lot of times it's looked at as a blocker or at least a speed bump to creativity or productivity. Maybe sometimes the feeling's like, "Oh, this is going to cost too much." And sometimes unfortunately, it's just ignorance or just straight up ableism. Sometimes that's the experience as well. But like I said earlier, some people, they really think, "Oh, disabled people wouldn't want to do that," or, "We don't have disabled customers or not enough disabled people to make a difference." So these are some misconceptions that I think are very prevalent in a lot of organizations today, and it makes it easier for them to say, "Oh, we'll do that later," or, "We won't worry about it right now." Or a lot of times it's like, "Oh, this is just an experiment, or maybe it's just MVP." So they kind of rationalize themselves out of making sure something is as accessible as possible from the start. Mike Paciello: Would you agree with me that most of those decisions though are actually done at the business level, not so much at the engineering level? Gerard Cohen: My experience is the further you get back into organizations, so we often talk about shifting left, me with the engineering background I have, it's very rare for me to encounter an engineer that doesn't want to be accessible. It's just something they don't know, they want to learn it. It makes them, they kind of geek out on it. Designers as well, to them they understand the business value of, "Oh, doing this will make more people enjoy my designs." It's when we start getting into the business areas and business groups that they have a different priority. To them, we need to ship as quickly as possible so we can move on to the next project. And so they're always looking at ways to like, "What's really the priority here?" And it's very easy for them. When they don't understand accessibility, even if they know it's something they have to do, if they don't understand the real impacts to it, it's very easy for them to push it down towards the bottom of the list where eventually other priorities take hold and it ends up getting left out. So, I would definitely have to say most of my struggles in getting things to be as accessible as possible usually ends up being on the business side of things for sure. Mike Paciello: Yeah, I think it has an awful lot to do with — compliance is a factor. In and of itself, generally speaking, compliance has this negative connotation. As you said earlier, it is always used as a cost of doing business as opposed to, "Hey, here's a feature that's going to change the world and make it bring in more customers, more users," which is what we want from a business perspective. But I've had the same experience as you. By and large, from the shift left experience all the way to the back, to the front. And when you're doing the QA, designers, developers, and testers, they're all in. They're all in. They may not know it, they may not fully understand it and grasp the concept, but once they learn it, they get, it and they'll usually apply it. Gerard Cohen: Yeah. It's really difficult because a lot of times I think business people, like you said, there's compliance aspects to it. I think sometimes they play a game of chicken. I've experienced and heard some- Mike Paciello: Oh, so that's interesting. I've not heard that. Go ahead. Gerard Cohen: Yeah. I think it's kind of like, "Well, let's find out if anyone complains." Or I've actually heard someone say, "Why don't we just wait until we get sued?" Which is a horrible plan for accessibility. Like I said, it's a way of playing chicken. I think we have right now, there's too much dependence on, specifically for accessibility and disabilities, there's too much of dependence on metrics, on user metrics. And as you know, Mike, right now, it's very difficult to know whether someone with a disability is using your software. You really shouldn't, right? Mike Paciello: Right. Yeah, it's law, right? Gerard Cohen: There's privacy aspects to that. Unless you ask permission and you intentionally ask for people to disclose, it's impossible for us to know the difference between, "Okay, here's a population of users that's not disabled versus that are." So it's hard for them to understand that if we do this, the percentage of increase that you see is actually coming from disabled people versus like, "Oh, no, it's just non-disabled people." So I think there's a little too much reliance on the metric side of things, and I think that's why it's harder for business people to kind of make that case. Mike Paciello: Yeah, that's a great point, Gerard, and I totally agree. I think people are looking for payback quite obviously. They're thinking, "Well, I've made an investment, you've told me more users will come because we're making it available to more users." But the metrics are really kind of leaning, they become leaned on too much and therefore become an asset to the business, which doesn't work from an accessibility perspective because as you said, privacy laws and whatnot prevent us from really tracking users and what their disabilities really are. So how do you know if a blind person's using your application or not, right? Gerard Cohen: Yeah. It really shouldn't matter, to be honest. At the end of the day, it's still a user that's trying to get a job. One of the things, a lot of times as I get into conversations with people, like I said, they kind of play a game of chicken where it's like, "Well, let's just wait until somebody complain." But as I mentioned earlier, a lot of times people with disabilities will not disclose. They shouldn't have to, it's nobody's business to be honest, but a lot of times they're not going to complain because the complaint automatically discloses they have a disability or that they're having a hard time with a particular piece of software. So a lot of times that complaint won't even come in. They just kind of push through it and work harder. Something that may take a non-disabled person may be a minute to go through, could take someone with a disability, depending on what it is, could take five minutes. And so what happens is they end up staying later, they work through lunch maybe. They work a lot harder, because they're not going to complain, and so business people waiting to hear for complaints from the disabled community, it makes things harder for us for sure. Mike Paciello: On a personal level, how would you change things or what do you think needs to be changed so that everybody is more in or at least making business decisions that are more supportive of accessibility? Gerard Cohen: Mike, that's a great question. So I think the most important thing is awareness and training. That's usually where I try to start with. I think everybody needs to be bought in from top to bottom because a lot of times people feel that accessibility is just an engineering problem to solve, but really everyone has a part to play. And when I'm talking to people, like I said earlier, everyone has their own motivations, their own priorities. So it's really just trying to make sure that I'm educating them and exposing them to the reasons why it's important for them in their craft or in their business responsibility that accessibility is important. But after that, I mean, the one thing that I always recommend people is just take it one step at a time, really. You hear a lot of people in the community say progress over perfection, which is something that Meryl Evans, who's probably after you, one of my most favorite people in this space coined that term, but honestly, I kind of have a spin on that because I don't think disabled people are looking for perfection. I think they just want equity and independence. So what I like to tell my teams is something slightly different, and it's really just progress is all that's required from you, and our goal is to make things incrementally better than we did yesterday. And the last thing I tell people is this is no different than any other important initiative. If you're starting at a huge backlog of accessibility-specific bugs, you treat it the same way as you would any other backlog of bugs. If you need to know what disabled people are thinking or liking or doing, then you do UXR and ethnography. It's all the same. Everyone understands these concepts, and I'm just here to get you to expand your scope, to be more inclusive and really just be more honest with your reflection of humanity, to be clear. Mike Paciello: Yeah. You've touched on a couple of things that I've... Now, for years I was saying it's all about making a commitment to progress. We know, I mean, this goes back to my early days when I was working and consulting with Adobe, and Acrobat and PDF were brand new technologies and everybody was fighting against them just the same way we're seeing some of the organizations fighting against overlays and AI and automation. Back then, it was all about PDF and Acrobat, and now you were ruining taking pictures of words and how are we ever going to be able to... And what I explained to the folks on the Adobe team that is, "Look, show a commitment to progress. We know you're not going to be able to solve all of the problems of what this new technology that has a place in our ecosystem, in the technology ecosystem, but make a commitment to progress towards accessibility. And then, be transparent." Or you talked about being trustful. So when you make a commitment, don't over promise and under deliver, as your say goes, but show what you've done and where you've going. People with disabilities will buy into that. As long as you're being communicative, as long as you're being trustworthy, as long as you're being transparent about what you're doing, they will support you. Gerard Cohen: Yeah, that's a great point. It reminds me of my team at Twitter and what we were trying to do. Obviously, going from Wells Fargo to Twitter, I wasn't used to how fast we got feedback from people using Twitter. I mean, it was instant. They're tweeting back at us. Once they get your personal handle, they would tweet, I would get tweets all the time, people complaining about stuff. And one of the things that we did with our main account was we started to monthly post the work that we just finished, the work that we were starting, and then stuff that was coming up in the future. And that made a big difference, and we were very transparent. We were very honest and said, "Hey, our best intention was, I know we said last week or last month we were going to get this feature out. Unfortunately we couldn't do it, but here's what we're working on." And we got such a great response from that. It was never perfect. We had a lot of work to do, it was a small team, we had a short amount of time. But having that transparency and commitment gave everyone the trust they needed to know that, "Hey, if it was up to us, we'd snap our fingers and everything would be done." It was a progress and we were working through it, and they trusted us that we were doing our best to make those incremental steps. So definitely sharing that. It's tough for some organizations, I know. It was a big risk for us, but it was Twitter, so we were able to do that. I don't see Wells Fargo, something as serious, being able to provide those kinds of updates, maybe just because of, like I said, heavily regulated, but having some kind of communication with the community is absolutely imperative to gaining that trust from the community. Mike Paciello: It was an interesting call-out that you just made in relation to immediate feedback, user feedback in the Twitter-sphere, versus slow mechanical error systems that were forced you at Wells Fargo. So that's an interesting dynamic depending on the type of organization. But how about now, let's say Atlassian and the products that you're delivering there, do you see any major differences in approach or in activity in that environment versus say, Wells Fargo, the commercial banking or Twitter where you're doing more one-to-one/peer-to-peer user? Gerard Cohen: Yeah. I'd say Atlassian is a lot closer to Wells Fargo in the sense that I'm working on a design system. I'm really, really super far removed from the people that are actually using our products. But the interesting thing is because Atlassian, most of Atlassian's user base are designers and engineers, they kind of understand the work that we're doing. So feedback comes in and it's super detailed. It is really fascinating to see the feedback that comes in month to month, where people are really just picking out particular portions of a screen or functionality and giving really good feedback. So in that sense, it's a lot better than Wells Fargo, not the same as Twitter. Also, the thing that's missing is, again, on Twitter, it was very easy to understand that someone was talking about maybe some functionality or a portion of the app that wasn't accessible. Whereas at Atlassian, I don't really get that specific feedback other than from my friends and peers that worked in the industry. I get text messages and emails all the time like, "Hey, what's going on with Jira? I can't do this thing," or Confluence. So that anecdotal feedback and that personal relationship with people really helps too. Mike Paciello: Yeah, knowing some of our common friends, I can just imagine who they are. Hey, let's change course here just a little bit. What are the biggest misconceptions about accessibility or an accessibility implementation that you see in your work? Gerard Cohen: Well, so many. I already talked about the misconceptions that accessibility was a blocker to creativity or productivity. That is very prevalent, but I come across a lot of just fundamental accessibility myths. And again, it depends on how much exposure you've had to people with disabilities, but a lot of times people think disability is someone in a wheelchair or a blind person with a cane, but there's such a large gradient of people with disabilities, and even if we can break them down into maybe five disability types, a lot of times people will have more than one disability. And so a lot of times people think that you can only be born with a disability. I hear people say that versus unfortunately, maybe there's an accident or a disability caused by illness. We're getting through COVID right now. There's a lot of things that are coming up based on that. A lot of people are waking up to finding out that maybe they've lost some hearing due to COVID. There's just so many things that are coming out of COVID. Or for me personally, it's even just getting older, you know? Mike Paciello: Yeah. Gerard Cohen: As we age, most likely, you'll start to move a little bit slower, you start to hear a little less. So like I said, there's so many gradients to disabilities and how someone can develop or be born or experience a disability. So that's one of the biggest myths because we're all working with people that unfortunately, they're sighted mouse users, and that's the experience they're used to, and they think that that's the way the rest of the world is. So just the exposure of no disability, majority of them, you can't even see. And like I said, since people aren't going to disclose them, they don't have a right to, I mean, they don't have to, you're probably working next to somebody with a disability if we believe the stat that a minimum 25%, let's just say the US, minimum of 25% of people in the US has a disability, that there's somebody in your office that has a disability that you don't know about. So I like to remind people sometimes when you say those horrible things about people with disabilities, which I hear unfortunately, you could be saying that about someone either that has a disability or maybe has a child or someone in their family has a disability. So you really got to think about it, how we're talking and treating people with disabilities Mike Paciello: As you're talking, I'm thinking, and now that we're more into a digital society, that's much more likely to happen. I mean, eventually we'll all be avatars and we'll be talking to each other and you won't know whether a person has a disability or not because they're just an avatar and they've created themselves with whatever features that they want to have, so it'll make you quite interesting as the future moves on. Gerard Cohen: Yeah, I'm not necessarily sure I'll be one of those people with the avatar. I very much so enjoy my- Mike Paciello: Yeah. Gerard Cohen: But that's the thing about digital applications and products and services is, again, it's an equalizer. It doesn't matter if you have a disability at all. Someone should be able to do something, and I think that's the best thing about the internet is it doesn't matter if you have a disability, if you do the right things, if you implement accessibility, then anyone can do anything. Mike Paciello: I wondered, I'm just thinking off the cuff here, I did a lot of work on persona development with Whitney Quesenbery and... Oh my goodness, what's her name there? Sarah Horton. How could I forget Sarah? They did an awful lot about developing personas around individuals with disabilities, describing what their capabilities were and what their daily life was like. Wouldn't it be cool if we could develop those personas and then adapt them to myself as a user in an interaction that I'm doing in a digital space? So now I really get the feel and the real sense of what it means to be blind, be an individual who's perhaps missing limbs, finger dexterity, limitations at that level, no voice, the inability to be able to speak, or to be a person with Parkinson's or MS, where speaking quality is tempered by the disability that I have there. Putting on those personas, and actually operating in that environment and learning how those users live every day, I see that as a value add somewhere down the line. Gerard Cohen: Possibly that could work with some people, but a lot of times what I like to do is educate people around situational disabilities or temporary disabilities. For example, when I was working in a Bay Area riding BART and you're holding on for dear life and you're trying to do something with just one hand, or maybe you're holding a baby. And I've done this a lot too, I'm at work and I'm eating a pizza while trying to do my job on the keyboard. These are situational disabilities that you find yourself in. Maybe I had a really bad night's sleep, and it's taken me a little bit longer to connect the dots and answer so many questions that I have to. These are situational disabilities that I think everyone can relate to, they've been throughout the course of their workday. And they could see why, "Yeah, it'd be nice if I had something to help me with those things. Maybe I'm taking some medication that makes me a little bit drowsy. I can't take time off from work, unfortunately, I still got to push through it." A lot of people have jobs where they don't have the luxury of just saying, "Hey, I don't feel good. I'm going to take the day off," so they got to push through. Maybe it's some drowsy medication. It'd be nice if there was some kind of affordance or assistive technology that can help people get through those things. And people understand those stories. They go through them every day. So you don't necessarily have to go through the extremes of simulating someone missing a hand or those kinds of things. So I think there's ways that we can get people to empathize with those situations. That would be really helpful. Yeah. Mike Paciello: Empathic design. Yeah, I agree. So let's talk about a subject that you and I, sort of our favorite subjects, you and I often talk about. We've reached that point now where AI and automation have become the key to next generation technologies. How do you see that working for or working within the accessibility ecosystem? Gerard Cohen: Yeah, we talk about this a lot. And again, I don't know if we have enough time to talk about how I really feel. Mike Paciello: Yeah. Gerard Cohen: Honestly, I'd be happy if we can get AI to just replace using divs with buttons and provide more labels, and maybe automatically correct color contrast, then maybe we'll be able to retire sooner. But I look at AI as any other technology. It has the opportunity to improve the quality of life for people with disabilities, which is what I'm most interested in. And on the flip side, it could also do a lot of damage. I'm interested in AI that is used to augment capabilities versus replacing humans. I think that's the key. And I think AI, like any other technology, has the opportunity to bridge a gap a little bit more, but it's really important. We need interfaces to AI to be accessible. That's the thing. How are people interfacing and using AI? That needs to be accessible from the beginning in order to make a big difference, otherwise it's going to widen the gap at an even greater pace. Mike Paciello: Yeah. We are hearing a lot in our own community about fear of bias and edging out individuals with disabilities because of these new technologies. My own personal feeling is like every new technology, it's going to take time. There's going to be a notion of maturity that we just have to let it play out. When we first were using the web, it was all character-based, it was all text. That's all it was. When Tim was working with the browsers, he was just working with the text-based browser. Not long after that, Mosaic came around and now all of a sudden we had graphics that came into it, and then applications started to develop. But we're talking 30 years ago now already, and still there's an awful lot about the web, particularly around accessibility. That requires more maturity, more definition, more discipline. So why would we not apply the same principles to AI, to automation, especially where accessibility is concerned? Because again, you and I have talked about this, what I worry about the most is scale. And as much as I believe as anybody, and I started a whole company built on this, that manual intervention usability are a core besides designing accessibility up front are a core principle. We are never going to be able to keep up with the rest of the world at the pace that we're going right now if we just leave it at that level. Do you have thoughts about that? Does that make sense? Gerard Cohen: Yeah, definitely. Automation is absolutely important for some of the most basic things that we have to deal with. I was joking when I talked about divs as buttons and form labels, automation could take care of those things. The static analysis of those things, very easy to detect and fix, but the goal is not to, again, I don't think, at this point, we're really far off from completely replacing any kind of manual intervention. The goal for me, at least when I'm introducing automation, is to free up the manual people from having to check and test all those things, let them really focus on the experiential side of things. So the actual flow like, "I need to create a Jira ticket. I need to do a bank transfer. I need to post a tweet." If we can reduce the repetitive stuff and let the machines do that, if you will, computers are really good about doing the same thing over and over again. Let the computers do that, let automation do that, and we can free up for better human testing with the experiential side. I think we're still a long way from going to that, but that's my goal when I'm introducing automation. And the other thing is really, automation in my opinion, has two stages. There's the first stage when it's originally introduced, when it's really used as an educational piece. This is how you get people to learn like, "Oh, I forgot something, or I didn't do something that I was supposed to." After a while, it ends up being muscle memory because again, as humans, we don't want to see that red text, those errors anymore, so we're going to do what we need to fix that. And then you get to a point where those aren't an issue anymore. It's muscle memory, and now the second life of the automation is really just like early detection at the end of the line in case something gets missed. So I think automation certainly has a really big part to play in what we're trying to accomplish. Mike Paciello: Yeah. And I think it will help us address remediation better too, faster, better. Again, like you said, the low hanging fruit kind of stuff. Tackle that, get it done, and then we can really put the science with the engineers at that level working on the hardcore stuff, and it's stuff that's coming down the pipeline that we're just starting to touch the surface of resolving and solving. As we're winding down here, Gerard, one last question. So you've worked now with a number of companies on accessibility initiatives and programs within those organizations. What business value have you seen this focus bring to companies you've worked with? Gerard Cohen: Yeah. I always tell people that accessibility is a catalyst and a magnifier for change, and it could be either good or it could be bad. So, in my opinion, the companies that I've worked with that focus on accessibility, they usually have better code quality, they have more innovative designs, they all benefit from customer loyalty and great brand recognition. Internally, employees are happier because it's a more inclusive and supportive environment. Everyone loves and deserves working in a safe place. So it sounds like a dream, but I've seen it happen where companies that focus on accessibility. And again, nobody's perfect. Everyone's got their priorities, everything's a progress, but in my opinion, those are real impacts and benefits to focusing on accessibility. Twitter, to me, was the most inclusive place that I've ever worked at. Absolutely loved the culture there. Again, it wasn't perfect, but people understood the mission, they understood, and so I think when you have a culture that's based around inclusivity and making sure we have to treat everyone with respect and dignity and provide that level of service and independence with the products and services that we're providing, then it's just better for everyone. So again, it's just a catalyst for the good side of things. Mike Paciello: Yeah. Excellent. Very good. Thanks so much, Gerard. Gerard Cohen has been our guest today here, now with Atlassian working on, again, what he's great at, working on software, working on tools for developers. Gerard, it's great having you here with us today. Thanks so much for being on the HearSay podcast. Look forward to catching up with you again soon. Bye. Gerard Cohen: Definitely. Thank you, Mike. Take care. Mike Paciello: HearSay is produced by Sojin Rank, Mike Barton, Mariella Paulino, and Missy Jensen. Edited by Alex Dorrier. If you enjoyed this podcast and don't want to miss future episodes, subscribe to our YouTube channel. Thanks again for joining us, and we'll see you next time.