Season 4 Episode 7 Mar 24, 2021

What You Need to Know About Accessibility


Accessibility is more than just screen readers


In this episode, we talk about accessibility with Crystal Preston-Watson, quality and accessibility engineer at Salesforce, and Marcy Sutton, web developer and accessibility specialist, who we have consulted with at Forem.


Ben Halpern

Forem - Co-founder

Ben Halpern is co-founder and webmaster of DEV/Forem.

Suzanne Aitchison

Forem - Software Engineer

Suzanne Aitchison is a software engineer at Forem. She is passionate about accessibility and maintains a tutorials site for accessible web development (particularly with reference to React).


Marcy Sutton

Modern Sole Design LLC - Owner/CEO/Lead Engineer

Marcy Sutton is an independent web developer working with organizations to improve accessibility in digital products and services. She brings years of experience working on multiple JavaScript frameworks and accessibility testing tools to her consulting work, making an impact through training and hands-on accessibility engineering.

Crystal Preston-Watson - Quality Engineer

Crystal Preston-Watson is a quality and accessibility engineer dedicated to making innovative, inclusive and accessible applications for everyone. She is currently a quality engineer focused on accessibility at

Show Notes

Audio file size









[00:00:01] BH: A common scene in technology companies everywhere, big conference table with the CTO on one end, developer teams on the other, the showdown. We have an idea, “Will it get funded?” More companies are feeling the pressure to go faster and stay ahead of the competition. Projects that have long timelines or no immediate impact are hard to justify. DataStax is sponsoring a contest with real projects, real money, and real CTOs. If you have a Kubernetes project that needs a database, the winner will get funded with a free year of DataStax Astra. Follow the link in the podcast description to submit your project. It’s time to impress the CTO and get your project funded.


[00:00:41] Eyes glaze over from debugging a remote Kubernetes service? Instead, run your service locally in your favorite debugger and instantly find the problem. Ambassador Telepresence is the easiest way to debug microservices on Kubernetes. Spend more time fixing problems instead of reproducing them. Ambassador Telepresence is free to use for teams with unlimited developers. Get started today at


[00:01:07] is a hands-on learning platform for software developers. Learn anything from Rust to system design without the hassle of set up or videos. Text-based courses let you easily skim back and forth like a book while cloud-based developer environments let you get your hands dirty without fiddling with an IDE. Take your skills to the next level. Visit today to get a free preview and 10% off on annual subscription.


[00:01:35] Get ready to level up at New Relic’s virtual event, FutureStack 2021, on May 25th through the 27th. Join your fellow data nerds from around the world to learn, inspire, and rack up experience in 50 interactive sessions, 12 hands-on labs, and a 24-hour hackathon. FutureStack is your cheat code for observability. Engineers from across the industry will lead you through topics like Kubernetes, DevOps strategies and observability. Then join us to relax with some Minecraft on Nerd Island. Registration is free at Game on!




[00:02:17] MS: The counterpoint is that making it compliant doesn’t necessarily mean it’s a good experience. So there is this experiential measure that we need to look out for.


[00:02:38] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a co-founder of Forem.


[00:02:46] SA: And I’m Suzanne Aitchison, Software Engineer at Forem. Today, we’re talking about accessibility with Crystal Preston-Watson, Quality and Accessibility Engineer at Salesforce, and Marcy Sutton, Web Developer and Accessibility Specialist who we’ve consulted with at Forem. Thank you both so much for joining us.


[00:03:03] CW: Yeah.


[00:03:03] MS: Thanks. Happy to be here.


[00:03:05] BH: Crystal, can you tell us about your developer background?


[00:03:08] CW: So I have like a roundabout way where I started in like development. I actually started in journalism and I was a web editor at an alternative weekly in Denver, and then moved over to a bigger newspaper that’s no longer here, the Rocky Mountain News, as an interactive producer there. I did a little bit of like HTML and CSS working on like interactive features. And then obviously journalism had a very rough time around 2008, 2009. And I was like, “Yeah, I’m going to just go lean in more into the whole tech part.” So I started freelancing, doing kind of front-end development. This is all self-taught. I went to a couple colleges and dropped out of them very fast. None of it was for computer science. This was something I did on the weekends, freelance tour a couple of years, and then had this kind of crisis of like, “What do I want to do? Do I want to stay in front end? Do I want to go into back end?” And a former coworker at one of the newspapers I worked at was like, “How about quality assurance?” And I started in the quality assurance testing route in 2013. And then in 2016, that’s where kind of things started picking up with accessibility, one, because my vision started getting even worse. So that was kind of these things. I was like, “Yeah, I can’t really see what I’m doing anymore.” And also, I got my first accessibility testing ticket, which was Test with JAWS and I had no clue what JAWS really was and kind of the rest is history.


[00:04:59] SA: And Marcy, how about you? Can you tell us a bit about your developer background?


[00:05:03] MS: Yeah. It’s interesting, Crystal, hearing about your background being in journalism because I went to college for visual journalism. And similar timeframe around 2009, I was looking at the job landscape for visual journalism and it was not looking good. So I also pivoted to web development and became a front-end developer, landed some jobs. I became a developer at a small design firm in Seattle. And my second job in the industry was at a bigger agency called POP. It was at POP that I was assigned to work on the target account and target the retailer in the US, had been sued for accessibility. And so as the lead developer on the target account, I was exposed to accessibility on the job. I didn’t know anything about it. I learned, I quickly became really passionate about it because I saw the impact that I could have in my work and could never turn that part of my brain off from that point on. The more I learned, the more interested I got and it’s really something cool to be able to innovate in ways that are more inclusive. So over the years, I’ve gotten more into public speaking and trying to get that spark lit for other people in the industry. And it’s been a really cool journey to see because I remember doing talks at places like JSConf and the light bulbs that went on for acquaintances that I made at those conferences. And now I’ve seen them go on to become accessibility champions. And I really love building accessible user interfaces. That’s the core of what I like to do. So since doing my kind of rounds through companies in the industry, I’ve now gone independent and I’m a consultant. I do some accessibility training. The opportunities in this industry are amazing and it’s really neat to get to spread that impact around and encourage other people to get into accessibility.


[00:06:57] BH: Can you try defining accessibility for us?


[00:07:02] MS: Sure. Yeah. To me, accessibility means that people with disabilities can use the websites that we build. They can participate in the development and design process of creating for the web. So not only the end user experience being accessible to people with disabilities, but the authoring process as well.


[00:07:21] CW: Yeah. It’s something I say and I forget where it started from, but accessibility is a human right. There shouldn’t be a question of everyone being able to really access the things that they need to. And I get very upset when I experience where places are like, “Oh, it’s supposed to be for everyone and everyone can use this and it’ll make your life so much better.” And when you go to it and that’s not true, and it’s only for a very small segment of the population. And what you’re saying is only some people get to make their life better with your products because screw the other people who are not in your target demographic, even though you’ve said that everyone’s in your target demographic.


[00:08:14] BH: Crystal, can you get into a little bit about the relationship between quality assurance and accessibility inherently?


[00:08:21] CW: A lot of companies, when it comes to accessibility, they just want to test for it. And that’s kind of their first booray of like, “Well, we need to be accessible, so we should just test our stuff to make sure it’s accessible.” And there’s no really thought. So that’s kind of where I feel a lot of companies get their start in accessibility is that it starts at testing because there’s a question of, “Is our platform accessible? Is our software accessible?” And then they’ll test for it. And then it gets kind of fuzzy from there because if you’re starting at the end, it’s a huge problem because it’s like, “Okay, well, you’ve just found out, no, it’s not accessible because you didn’t do anything before to make it accessible.”


[00:09:10] MS: Yeah, I totally agree that accessibility needs to be in the inception of the product, but there’s some humility that needs to go into that and acceptance that it’s not going to be perfect. I mean, perfection is something that we chase and never quite get there with perfect accessibility. So having that openness and humility to accept when you’ve gotten it wrong and keep iterating and keep improving it and try not to make false promises because I have seen that as well where companies will claim something as accessible, but they haven’t really tested it or haven’t had the compassion of what that user experience is actually like for someone with a disability. So yeah, you could say that it’s accessible, but has it really been tested for people who aren’t in that target demographic that they’ve assumed? So we’re constantly trying to improve it, keep it going, make improvements whenever we can and try to move the needle in big ways and small ways, but it takes some kind of curiosity and humility as I said to just keep at it.


[00:10:17] SA: Yeah. You mentioned there that it’s not really a case of accessibility being either is accessible or it’s not accessible. So how do people measure what is accessible? How do you know if your project’s accessible?


[00:10:31] CW: I think with that, this is the thing, I know a lot of places and a lot of people when companies want kind of one metric of like, “This is how something can be accessible,” and you really can’t do that. I mean, it really depends on the product, the platform, the software. It’s a holistic thing and it doesn’t start in testing. It doesn’t start in development. It starts when it should start at the very inception of that product. Sometimes there are products that are ideas that are formed, and by the very idea that it is, it’s already inaccessible, and then it just gets worse from there. There’s always certain tests you can do, no matter what you’re testing, when it comes to accessibility. There are certain things you could do when it comes to development that you can do somewhat, no matter what you’re developing and the same with design. You have inputs and stuff like that. But also, what really matters is that you’re taking what that product is and really think about how will people use this and not just our very star target persona, but everyone, someone that has permanent disabilities, temporary disabilities, someone that’s new, like when it comes to like screen readers. It’s like, well, obviously someone who uses a screen reader has been using a screen reader all their life. Nope, that is not true because I am someone who has come very late to using screen readers and I don’t use it in, I guess, a “perfect way”. I use voiceover in Chrome and I’ve been told you shouldn’t do that, but that’s what I use and I’m old and I don’t want to change.


[00:12:24] MS: There are some metrics that we can measure against, especially using the web content accessibility guidelines. There are success criteria that have been agreed upon over decades now and they’re actively developing the web content accessibility guidelines all the time. So we can aim to meet some of those success criteria and do a lot of good for accessibility. The counterpoint is that making it compliant doesn’t necessarily mean it’s a good experience. So there is this experiential measure that we need to look out for, test with people, make sure it works, make sure it works with the keyboard. I’m a big fan of automated testing. And so I think that could be a component of ensuring something is accessible, is having automated tests for keyboard support and running against APIs, like XCore and Wave. So there’s some automation that we can use to free up some human energy for more nuanced things, those experiential kind of judgment calls that you really need a human to evaluate and determine is this usable, is this accessible, but at least some of the low-hanging fruit of technical problems that can be caught with automated testing, we can kind of get that out of the way. And that can add up to this whole experience of trying to make something accessible, not spinning our wheels, like trying to find an incorrectly spelled attribute in the markup or something like that.


[00:13:55] BH: How has the culture around accessibility within the developer community changed in the last few years?


[00:14:01] MS: Well, I’ve seen it evolve quite a bit from being something somewhat niche into a more mainstream topic, like I’ll see accessibility as a major component in conferences of talks that they’re looking for. And I even remember getting into public speaking and starting to get talks accepted that were technical topics with accessibility kind of bundled together because that’s what I was interested in. And folks in the industry were just like, “How are you getting these accepted? We can’t get these talks accepted.” And it was like some friction earlier on. And then since then, I’ve seen it become a really desired topic by organizers. So I think that it’s something that people are really hungry to hear about now. There’s also way better tooling for developers. So I think it becoming more mainstream as part of using Lighthouse and various developer tools. That’s certainly impacted the culture because, I don’t know, it makes it more approachable, dare I say more accessible. It makes it a little bit easier to uncover that low-hanging fruit. You don’t have to be a super WCAG expert to make a difference with accessibility. And so I think that lends itself well to kind of infiltrating the mainstream.


[00:15:19] CW: Yeah. Having more people that are just aware of accessibility, maybe they’re not thinking about it forefront every single day, but just having someone just read something, attend a presentation, it really does help. Something I told my husband is that I would love to work my way out of a job that accessibility is just something. And people are like, “Why are you getting paid for this? Everyone understands that things need to be accessible, that accessibility is key and it’s important.” It’s like, “Yeah, I’ll go retire early.” No, I wouldn’t. But I would find something else to do.


[00:16:04] MS: You can pivot to security.


[00:16:05] CW: Yes. Oh yeah.






[00:16:26] BH: Sick of your laptop overheating every time you try to run your Kubernetes application locally? With Ambassador Telepresence, you can intercept your services on your local machine so that you can develop on your services as if your laptop was running in the cluster. Never worry about running out of memory again no matter how complex your Kubernetes application gets. Ambassador Telepresence is free to use for teams with unlimited developers. Get started today at


[00:16:56] New Relic’s Application Monitoring Platform gives you detailed performance metrics for every aspect of your software environment. Manage application performance in real time, troubleshoot problems in your stack, and move beyond traditional monitoring with New Relic One, your complete software observability solution. Get started for free at


[00:17:18] To connect with the team behind New Relic directly, join The Relicans. The Relicans is a new community hub designed to help developers create cool projects, inspire one another, level up and learn in public. You can start a discussion about your favorite programming language, ask a question about software observability, share tutorial, and lots more. Join today at




[00:17:46] BH: Can you speak to your career progression in terms of having impact through the development side and also the advocacy side?


[00:17:54] MS: Yeah. For me, impact is all about making a mark and leaving the world better than you found it. And so for accessibility, there’s the act of incorporating it into pattern libraries and the actual design and code, which I’m trying to get back to more with this sort of direction I’ve gone off on with the public speaking to be doing that kind of nuts and bolts implementation of accessibility. That’s what I really enjoy. But I also found making a mark and leaving it better than you found it means like trying to use your position and knowledge to inspire other people, to leave their work better than they found it. And so the advocacy part for me is all about trying to do the right thing with accessibility, like always being honest about your efforts, like writing accessibility statements on websites to try and bring the information front and center on a given website so that people know that accessibility is being taken care of in that space, but that it’s not necessarily perfect. So for me, advocacy is about showing up doing the work, but being accessible about it, like sharing information in accessible formats, describing what’s on screen as you are presenting so that you’re actually presenting it accessibly. So for me, advocacy is always about keeping people with disabilities in mind as part of my community and who I’m out there talking with. And so I think the biggest successes I’ve seen in my career were like seeing the effects of someone going from not knowing about accessibility to then implementing it on a website or saying, “Wow, that really clicked for me.” It’s like I’m living vicariously through the other people’s wins, and that has just been the coolest thing to see.


[00:19:49] BH: Can you talk about the balance between teaching and doing in the work you do now as an independent contractor going into companies?


[00:19:56] MS: Yes. Teaching and doing, I’m constantly kind of balancing those two things, like doing being getting in there, evaluating code. In some of my engagements, I get involved with the organization by stepping in and doing, reviewing pull requests, checking out code, giving feedback on it, and the act of doing ends up teaching the team of like how to do an accessibility code review. And so I tend to do both of those interchangeably, but I am really trying to get back to more doing, because the teaching part after so long, you need like fresh ideas and fresh experiences to be a good teacher. And so I think for a lot of developer advocates, we’re always trying to keep our development skills sharp because teaching is awesome, but you also need that kind of expertise behind it, of what you’re actually teaching people. And so I kind of fluidly go back and forth and trying to gear my independent work now, getting back to more doing. I recommend figuring out what you thrive at and what you’re going to be the most successful at. And for me, that’s been finding the things that just get me excited and get me out of bed in the morning, and that’s user interfaces.


[00:21:13] BH: Crystal, do you find yourself doing teaching at Salesforce?


[00:21:17] CW: Yeah, like teaching or researching and informing developers and testers about different things and strategies when it comes to accessibility. So I do a lot of conferring with developers on, “Let’s talk about semantic code and please just don’t use Aria.” Yeah. So that’s something I do like to do, but like what Marcy said, I really also want to make sure I’m keeping in like the doing as well. And so I’m definitely going back on my own kind of time doing a lot more development projects. I’m also learning a lot more about assistive technology beyond screen readers because that’s something that tends to be like a pretty prevalent myth that web accessibility is only for blind, visually impaired, and there are a lot of other assistive technologies out there that need to be considered when you’re creating accessible products. So I want to make sure because, yes, I have firsthand knowledge with screen readers, but I want to make sure I understand the switches and how they work. There’s a lot of different assistive tech out there as I am learning right now.


[00:22:34] SA: We actually had a really great interview in one of our sister podcasts, CodeNewbie, with the founders of a tool called Serenade, which lets you like code vocally. One of the creators had developed a repetitive wrist injury and couldn’t be productive typing anymore.


[00:22:50] MAN: And it got to the point where 20 minutes of typing I would be in pain very quickly. The company at the time was great. They were saying, “Look if there’s any solution out there, we’re happy to pay for it.” So I tried a bunch of different ergonomic setups and saw a bunch of doctors. I read a bunch of self-help books that people were recommending. I looked at a bunch of dictation solutions out there. None of these things really worked for me and got me to a place where I could be productive again.


[00:23:22] SA: And I feel like a lot of people forget about those kinds of physical disabilities as well, things like repetitive strain injury. When they think about accessibility, we don’t tend to think of those kinds of things. I don’t know if that’s something either if you could speak to as well.


[00:23:39] MS: I’ve had repetitive strain injuries myself and have found a renewed passion for making things supported by the keyboard. And so I have at times kind of appeal to developers’ kind of selfish nature of like, “This could benefit you.” People like you sort of have mixed feelings about appealing to the selfish nature. People should be willing to do the right thing for folks other than themselves as well because it is the right thing to do, having compassion for the user experience that you’re creating. But there are so many different ways that people need to navigate the web. And that is really the power and the beauty of accessibility is that we can make things that are more ergonomic with people’s bodies in all of these different aspects. And so I think it is really interesting to hear about these tech solutions that work for folks who can’t use a keyboard anymore. It is so important that we have an accessible authoring experience.


[00:24:42] CW: I guess I don’t have as much of an issue, like appealing to the selfish nature of people because I’m one of those people who were like, “I got to get it done.” My grandfather always had this thing. It’s like, “You never leave money on the table.” And that’s something I always go when I’m speaking to like stakeholders. It’s like, “Okay, if I can’t appeal to their heart or their mind, I’m going to appeal to the wallet.” And it’s one of these things I wish people did just do things because it’s just the right thing to do. This world would be so much better, but I literally just had a conversation with someone where it’s like, “Well, older people won’t play video games.” And I’m like, “Well, what do you do now? You play video games, right? What will you do when you’re 70 years old? You’ll probably want to play video games.” And so just to get them to think about, “Hey, video games should be accessible.” And I also say that I’m kind of a little bit selfish in why I’m doing this advocacy work with accessibility. I believe it’s the right thing to do, but also I am losing my sight and I’ve always kind of worked with one eye and now the vision in my one good eye is slowly going away and I’m like, “I want to do things even if it gets to the point where it’s like I am fully dependent on the screen readers and the other assistive tech, I still want to do things. I still want to play video games. I still want to make crap post on Twitter about stupid things.” I mean, that’s the reason why I do what I do. It’s the right thing to do. When Hitman 10 comes out, I still want to play Hitman because it’s my favorite game.


[00:26:37] BH: What are some other accessibility issues that you both think are often overlooked?


[00:26:42] MS: People with cognitive disabilities. So making sure interfaces aren’t unnecessarily moving and flashing that might distract someone or harm someone who is really sensitive to movement on the web. And so some resources that I have leaned on or recommended, there’s some really great information from the W3C’s Web Accessibility Initiative. They have some web accessibility perspectives, videos, and lots of information on this holistic practice of accessibility as it relates to many different people.


[00:27:16] CW: Something that’s somewhat related is the cost of assistive technology and also developing for the newest assistive tech, because the thing I think a lot of people are unaware of, assistive tech is expensive and not everyone has the latest MacBook. They may not have even a 2018 Mac, but they’re dealing with 2014, they’re dealing with a PC that really doesn’t have a lot of power. So they’re working with assistive tech software that is very old and very out of date and understanding how that works. Also, a lot of people live in areas where the internet is not great, it is not the fiber optic, whatever, like the fastest internet speeds. They’re still on DSL. And depending on what your platform is, what your software is, what your product is, you really do need to take that into consideration. And that’s not just for disabled people. That’s for call your users as well because the digital divide is a real thing and it affects a lot of people. And there’s still a lack of consideration for that when it comes to the people that use products, but especially when it comes to disabled people using websites and software.


[00:28:49] BH: Beyond squashing independent accessibility issues as they come, are there bigger software design principles around maintaining the flexibility, such that one can develop software for the unanticipated accessibility issues?


[00:29:03] MS: What comes to mind for me is via a website or a web application that users come back to a lot, allowing it to be personalized, having really flexible infrastructure that supports flexible experience so that users can configure it, have settings and those kinds of things. I think if you build your applications such that it could enable personalization, it would be more flexible, robust. You have switches you can kind of toggle on and off. So if you can build it the whole way, that would be pretty powerful. You’re not so hard-coded in one direction, yeah, try to think of adding personalization after the fact could be very difficult. That’s what comes to mind for me in terms of making something that’s accessible that can try and meet more people’s needs. We can try to use heuristics and improve on CSS focus. If you’ve heard of “focus-visible”, that’s a web standard space direction to try and turn on focus outlines in ways that mouse users don’t hate, putting it plainly. It’s what I call “Button Focus Hell”. It’s gotten a little better, but it’s still a bit error prone when you have devices like voice control, which can be picked up as a mouse in some cases. So for meeting users’ needs, if we can make something that’s robust enough that they can just force-focus outlines to be on all the time, that kind of thing, yeah, that’s what came to mind for me.






[00:30:58] BH: Chances are, like other software developers, you learn better by doing than just watching. Unfortunately, most online learning platforms still have you passively sit through videos instead of actually getting your hands dirty. is different. Their courses are interactive and hands-on with live coding environments inside your browser so you can practice as you go. They’re also text-based, meaning you can skim back and forth like a book to the parts you’re interested in. Step up your learning in 2021. Visit today to get a free preview and 10% off of an annual subscription.


[00:31:33] A common scene in technology companies everywhere, big conference table with the CTO on one end, developer teams on the other, the showdown. We have an idea, “Will it get funded?” More companies are feeling the pressure to go faster and stay ahead of the competition. Projects that have long timelines or no immediate impact are hard to justify. DataStax is sponsoring a contest with real projects, real money, and real CTOs. If you have a Kubernetes project that needs a database, the winner will get funded with a free year of DataStax Astra. Follow the link in the podcast description to submit your project. It’s time to impress the CTO and get your project funded.




[00:32:18] SA: So we talked a bit about what accessibility is and all these different things that we can do for users. But if you’re a developer now who maybe is just starting on that journey towards becoming a bit more accessibility focused, making more inclusive products, like are there some top sort of practices or habits that you would recommend to them to get started?


[00:32:41] CW: The number one is learning HTML and CSS, if you’re starting out. I know with a lot of bootcamps, and I actually went to a bootcamp like a few years ago, there was very little time that was spent on learning HTML and CSS and I guess what we would call Vanilla JavaScript. It’s really important. I feel that sometimes devs are fighting against the code. And when it comes to HTML5, a lot of that accessibility is baked in. And so you don’t need to reinvent the wheel for a lot of things. A lot of this kind of goes into why ARIA gets a bad rap. I’m not saying this is true of everyone and this is just in my personal experience that a lot of devs don’t learn those basics like right off, like the first thing. And then once they’re kind of tasked with dealing with accessibility, there is a kind of mad scramble because usually a lot of times this is done under very strict and hard deadlines where they’re like, “I have to make something accessible,” but they don’t have that kind of inherent knowledge. And so usability is not great. And so it’s kind of one thing. If the usability is not great, is it really as accessible as it could be?


[00:34:08] BH: So you talked a little bit about ARIA, which stands for Accessible Rich Internet Applications, and as a set of attributes that define ways to make content and web applications more accessible to people with disabilities, why wouldn’t someone want to use this?


[00:34:23] CW: It gets a bad rap because what usually happens is like I’ll interact with a feature and, “Oh, it’s inaccessible,” and what I find there is a lot of ARIA, like attributes that have been used on it because usually what’s happened is that it’s an old feature, old code, and so it’s like, “Okay, we need to make this accessible now.” And instead of maybe going back and refactoring, and that is adding HTML5 elements, and a lot of times it’s because people can’t go back to refactor. It’s like, “I can’t go back to refactor. So what I’ll do is. I’ll use ARIA,” but they may not have a good grasp of how they would go about doing that. So it becomes this jumbled mess. ARIA inherently is not bad. I think that should be said. It’s just that if you don’t understand why you’re doing it, then it becomes bad. It becomes this mess of like, “I’m making everything accessible. Here’s this. Now it has a role of like, “This is a now live region. Okay. I did it.” And it’s like, “Why did you do that?” It’s like, “Because I made it accessible.” It’s like, “Okay.” I’m joking, but that’s kind of what it is, is that ARIA is seen as you shouldn’t use it and that’s not true because it definitely has its place, but it’s one of these things that you definitely need to know why you’re using it and how to use it and when you really shouldn’t use it.


[00:36:01] MS: Yeah. So it’s kind of twofold. If you’re trying to retrofit something, that’s a bit of a code smell. I remember trying to fix something in a very large software application that output HTML, and it was so complicated. I couldn’t even change it from outputting a div to a real button. So the fix was go and dynamically append a roll of button onto it. That is such a bad code smell. It was like the grossest code I’ve ever written in my life because the true fix would be to go back, like Crystal said, and refactor that into semantic markup. But then there’s also the fact that it’s an accessibility layer. I’ve seen people make up attributes, which you can’t do it. There’s a standard set so that sometimes folks get that wrong. But planning this accessibility information onto your page, you have to test that somehow. You have to use a browser extension or a tool to highlight if you’ve done it incorrectly, because there are some attributes that they need certain hierarchical structures in your markup to work correctly or certain parents or children or other attributes that you combine together. And so there’s that testing of this kind of under-the-hood layer that might be missed. So developers might just slap some ARIA on it and then they don’t ever go and test it to see what effect it actually had in assistive technology. So there’s lots of ways to get it wrong. And I think that we’ve seen quite a bit, that web pages are often less accessible with all this ARIA slept in there because it’s sort of half baked. So yeah, the first rule of ARIA is don’t use it, unless you have a really good reason and you’ve read up on it. Yeah, it does have a bad rap because it’s easy to get wrong. But it can be useful at the same time.


[00:37:46] SA: So when you’re approaching a new project, so maybe some applications that already exist, you’ve mentioned being dropped into these big apps already have problems, what are your processes for making sure that you get things on the right path? In terms of accessibility, what sort of steps do you take to start making an improvement there?


[00:38:08] MS: I would tab through it with the keyboard and see if I can reach and operate controls, kind of do a health check of what’s the status of this application, run it through some browser extensions and sort of like a workflow that I follow that’s repeatable. And so I go and do that analysis of what’s the state of this thing and figure out who are the stakeholders that need to be. We talked about advocacy and training, like who are the people who need to be trained on this so that they can fix their own work? You have to analyze the situation and see to not only fix a problem but get to the root cause of it. If there’s color contrast issues, do we need to train the design team? So there’s some sort of documentation that needs to be written. Going back to working on Forem, we created a line item in the PR template on GitHub. And so little prompts to get people to address it in their own work because as the lone accessibility engineer or consultant, you have to be able to delegate some of that work as well because you just can’t fix it all yourself or maybe you fix it once and then it regresses again. So the goal is to figure out what’s wrong with it, the really high impact issues that you can prioritize and then find ways to solve it at its most root level. So they don’t just keep cropping up again and again.


[00:39:32] CW: Definitely agree, like definitely going in and just taking a spin with like a keyboard, for me, especially if there is a mobile site or there’s a big push for mobile, since I spent a lot of my time on my phone and that’s my main screen reader, I will just pull it up on my phone and just kind of like, “What if some random person who’s not working there, how would that happen? How would I feel?” And coming at it from a holistic way, how can I really make accessibility that’s something that’s just ingrained and just a part of everything?


[00:40:14] BH: Why don’t we finish up with the question of what are some of the biggest misconceptions about accessibility?


[00:40:22] CW: The one that really does keep coming up for me is that disabled people don’t use the internet. It’s still a huge one that I can’t believe is still like a lot of people think in 2021, that’s not even remotely true. I mean, the internet, the web is not a luxury anymore. We’re not in like 1995 where maybe one house on the block had AOL dial up and everyone would stand around and be like, “Ooh! It’s making a noise.” And I should say least when it comes to like the US, it is vital that you have access. And that means that if you’re a disabled person, you need the internet and you need to do things on the internet, like applying for benefits and other services. Lot of that stuff is online now. And so that’s a huge misconception. That’s the number one thing for me.


[00:41:27] MS: That’s such a huge topic. We really do see that in all kinds of online services. Companies say, “Oh, that’s not part of our audience. That’s not on our roadmap.” Yeah. But it needs to be. That’s really what we’re advocating for is so that people can do more online shopping and entertainment and have careers in technology as well. It’s such a huge opportunity. Technically speaking, some misconceptions I’m seeing, a big one is that JavaScript and accessibility are enemies or something. HTML and CSS really are a foundation for creating accessible websites. But for interactivity, JavaScript and ARIA go very well together. You need JavaScript to change ARIA states and things like that. And so making rich interactive experiences that are accessible, JavaScript has a big part to play in that. So I love that trifecta on the web platform of HTML, CSS, and JavaScript and encourage people to learn about what you can get for free from HTML, such as focusability. Another misconception I’ve seen, sort of a common mistake, is engineers will put the tab index attribute on things like headings and landmarks, because they don’t understand that a screen reader has other navigation methods and you don’t need to hit the tab key to reach everything. So I think really understanding that foundation of HTML, that would clear up some of those technical misconceptions.


[00:43:02] SA: Crystal, Marcy, thank you both very much for joining us today.


[00:43:05] MS: Thanks so much for having us.


[00:43:15] SA: Thank you all for listening. This show is produced and mixed by Levi Sharpe. Editorial oversight by Peter Frank and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM Eastern, or if you want to start your own discussion, write a post on DEV using the #discuss. Please rate and subscribe to this show on Apple Podcasts.