In the 16th episode of the AAArdvark Accessibility Podcast, hosts Natalie Garza and accessibility expert Natalie MacLees discuss the importance of integrating web accessibility from the very start of the development process for developers and agencies. They tackle common misconceptions held by developers, the necessity of educating clients, and the legal implications of inaccessible websites.
Natalie G: Hello everybody and welcome to the AAArdvark Accessibility Podcast. My name is Natalie G. I’m the Mic MC here and with us today is…
Natalie M: Natalie M. Accessibility expert.
Natalie G: Yes, and in today’s podcast, we are going to do the part two to last week’s episode, where we talk about web accessibility when building websites from scratch. This one is geared towards developers and agencies, basically, anybody who is actually making the website.
Natalie M: Professionals who build websites.
Natalie G: Professionals who build websites. And so we’re gonna start off with why is it important to build a website to be accessible from scratch?
Natalie M: Yeah. So we touched on this a little bit last time, but I think it’s worth doing a quick review. Your favorite metaphor, Natalie, you can’t put the chocolate chips in the cookie after it’s baked. So the best way to end up with an accessible website is to build it to be accessible from the very beginning.
It is the most cost-effective option. If you try to come back and make an inaccessible website accessible later, it’s going to be very expensive, very time-consuming, and very difficult, and the end result won’t be as good. And accessible websites are important, of course, because that way, there are no barriers to customers or users to the website.
Everybody has equal access to all of the information and services. The user experience of an accessible website is better for everybody who uses the site. You get a little SEO boost. And you can avoid legal risks ’cause people do get sued for having websites that aren’t accessible. And you could look at increasing your audience and potentially your revenue by about 20% if you are inclusive and allow everybody to easily use your website.
Natalie G: Yeah, and that means everything on your website, like the checkouts, like the memberships, like the ability To give your website owner money.
Natalie M: Make donations to a nonprofit. Yep. All of it should be accessible.
Natalie G: Yeah, and there’s a lot of misconceptions that developers have when it comes to making accessible websites.
Natalie M: They do, they do. A lot of developers don’t, you know, we talked about in an earlier episode how there’s a real lack of accessibility training in any kind of web development training. If it’s there at all, it’s often just one unit that’s kind of tucked in, in the middle of the class, and it’s not taught holistically throughout the entire curriculum.
And because of that, developers often make a lot of assumptions and think, “Oh, it’s really difficult. It’s really time-consuming. It’s expensive. It will constrain what we can do. It will constrain the design. Can’t be fancy and beautiful.” They’ll think, “Oh, we aren’t gonna be able to build certain kinds of functionality.
And the website is not gonna be as modern or fun or as exciting if I have to make it accessible.” And so they’re reticent to kind of dive in and figure out how to make that all happen.
Natalie G: Yeah, I think there’s, just like, an untrue tie with accessibility and, like, maybe government websites. ’cause when I think of accessible websites, I just think of government sites. And they’re all horrible. But they’re horrible for other reasons, not just because they’re accessible.
Natalie M: Yes, that’s true. Government websites are just baseline horrible, and it has nothing to do with accessibility.
Natalie G: No. So when it comes to selling accessible websites, if you’re a professional, you’re an agency, what stuff do we have to keep in mind?
Natalie M: So you are the professional. So somebody is hiring you because of your expertise to do something that they can’t do themselves, which is to design and or develop. A new website, and it is your responsibility as a professional to inform the client about what they actually need and to guide them to make the right decisions.
And if you are thinking of accessibility as an optional add-on, or like an optional upsell, that is the wrong approach. Every website should be accessible out of the box, and you should be educating your client about why that needs to be the case. Why accessibility is important and why you are going to build it into the site from the beginning and help guide their decisions along the way so that they end up with an accessible product at the end.
Natalie G: Yeah, it’s not something you can tack on months later.
Natalie M: It’s not something you can tack on months later, and it’s not something that I would consider optional for any website. Because any website that you put out there, and this includes if you are building a, like an intranet for internal company use because there are going to be employees of the company who are going to need an accessible platform to go in and request their paid time off or adjust their HR records or to access company resources that is going to need to be accessible as well.
So you’re not off the hook if it’s not a public-facing website, either. It’s just, it’s a really important thing, and you put that out into the world, and now you have a legal liability that if somebody tries to use that website and can’t because you didn’t build it to be accessible, now you’re gonna get a demand letter, or you’re gonna get a lawsuit. Because somebody couldn’t access that resource.
Natalie G: Mm-hmm. Does the demand letter or lawsuit only apply to the person who owns a website or it also trickles up? Trickles up? Also, goes back up to the developer?
Natalie M: Yeah, so that’s an interesting question, actually, because right no,w it’s just the owner of the website, but there is a law here in California where I live. That they are trying to give the builder of the website, so the developer, the designer of the website, responsibility for that accessibility so that you, as a web developer, could be sued if a website that you’ve built is not accessible.
Natalie G: Yeah, so what you’re saying is that accessibility should just be a core feature of your offerings.
Natalie M: Yes, it should be a core feature of your offerings, and it should be something that you are talking about with a client from the very first call that you have with them.
So, I was telling you about a LinkedIn thread that I saw a few weeks ago. I won’t name any names, but somebody said, “Ugh, we’re 10 months into a big project, and the customer just told me it needs to be accessible.”
You should never end up in that situation because. It should have been the other way around, right? The developer should have told the customer 10 months ago this needs to be accessible. It shouldn’t have been coming from the client or the customer, right to the developer.
That information should have traveled the other way from the very first conversation they had about the project. That should have been something that they were talking about. It shouldn’t be something that’s coming up from the client’s side 10 months later.
You are the professional, so you are the one who knows what it takes to build a successful website, and you need to be the one who’s in charge of that and informing your clients what they need when they are hiring you to build that website for them.
Natalie G: Yeah, because 10 months later, it’s like you’re treating it as an add-on. Right? At that point, you’re just gonna have to rebuild the whole website.
Natalie M: Yeah. 10 months later is too late. And that is, that’s on the developer. That’s the developer’s fault at that point.
Natalie G: What if clients try to give you pushback and say, well, can I get a discount if I don’t want my site to be accessible?
Natalie M: Yeah. So I run into this situation a lot as a web developer. You know, I ran my own agency for a decade. And clients would often say things like that, “Oh, I don’t have any users who have disabilities,” which is a silly thing to claim because, of course, they do. “I don’t need that. Can we just not do that?”
And I would, take the opportunity to educate them about accessibility and why it’s important. And most of the time that would be sufficient and they would be on board and they would understand why it was important. There were some clients who were really stubborn about that and were just like, “No, I really don’t think this is something I need.
I don’t wanna pay for it.” And at that point I, I can give them two options. You can go to somebody else ’cause I’m not gonna do that, right? Or, I would give them a little, like I would send them a little acknowledgment by email that would just say like, “Okay, well, if you don’t want me to do this in an accessible way, I just need you to acknowledge this email that says, I’ve advised you that this needs to be accessible and that.
You are acknowledging that you’ve received that information and you understand it, and that if somebody sues you because of this not being accessible, you are not gonna hold me liable because this was your decision.” And sometimes that was enough to make them decide, “Oh, okay. Yeah, no, we can just make it accessible.”
Natalie G: And in turn, would they agree to your prices?
Natalie M: Yeah. Yeah.
I never negotiated on prices.
Natalie G: Would it be a good practice to send something like that for every single project? ’cause after the website is delivered, a lot of it falls out of your control.
Natalie M: A lot of it does fall out of your control, I don’t think you have to have some people sign something like that every time. You might have a little something in your contract, like I would have a warranty in my contract, for example, that would just say, “Hey, if there’s any issues, you need to report them to me within 60 days or 90 days, or whatever it would happen to be.
And after that, I’m not responsible because you’ve been the one taking care of the website and changing the content and all of those kinds of things. And it’s out of my hands.” So you could just have something like that in your contract, I think that would say, after a certain period after launch, it’s just not, it’s not your responsibility anymore.
Natalie G: Even if you have them like on a retainer.
Natalie M: Yeah, the warranty would expire even if they were on retainer. Because you don’t get, you don’t get infinite work on your website forever with the, you know, for no additional cost. So, you know, the retainer would cover what the retainer covers, but there would be a separate contract for the retainer, and that would cover.
The work specified there, but the original development of the website like that coverage would end at some point.
Natalie G: As the developer, as the agency, would you give your users or your clients like a guide or like a manual to help maintain the website?
Natalie M: Oh yes, absolutely. And also training in how to do it accessibly. So I have like a pretty standard training that I’ve developed over time for content managers and how to, like think about color contrast and link text and things like that. And I would walk them through that and then leave them a recording of the training so that they could refer back to it at any time.
And yes, they always had a, like a guide to walk them through how to do different things on the website and make updates. Sure.
Natalie G: Okay. So as the web developer, as the agency, you have to be upfront with them.
Accessibility should be a core feature, but then there’s the added training part to help users maintain the work that you did.
Natalie M: Yes. I would just include that as a standard part of a web design package and, you know, price that in from the very beginningand make it clear to the client that that’s something that they’re getting as part of your services.
Natalie G: Yeah. Which it may sound like a lot of work, but in the grand scheme of things, you’re adding more value to your services.
Natalie M: That’s a lot more value. Yeah. When they get not just a new website, but they have a guide, and I had a, like, a way that I would build it right into the website so they didn’t have to keep track of a, you know, a separate document or something like that. It would be built right into their website, like a little guide on how to use it.
How to do different things, how to make different updates, and then some notes on when they needed to call me. Here’s a situation you can’t handle on your own. Call me. I’ll take care of it for you.
Natalie G: Yeah, and not only does add more value, but it gives you the ability to charge more for your services, like against other web developers, against other agencies, you are worth more money. You have more knowledge.
Natalie M: You have comprehensive services that are gonna cover everything. You know, they’re not just, you’re not just gonna dump a website on them and like, “Oh, well, it’s your responsibility now. You gotta figure it all out.” Yeah. They’re getting a much better product at the end. They’re, they’re getting this knowledge of how to use it and they’re getting education and how to.
Keep their website accessible and I would include social media training. So if you wanna be using Instagram and different platforms and sharing content there, here’s what you need to keep in mind for accessibility. So I would really give them this comprehensive package and any web development agency has the ability to do that.
Natalie G: Mm-hmm. Yeah. So going back to building the sites, why does it need to happen in the initial stages? I mean, we covered a little bit.
Natalie M: Yeah, because if you try to come back later, if you try to build it like that person on LinkedIn, you’ve been working on something for 10 months, and then you try to go back and make it accessible. It’s gonna be really difficult because you’re gonna have to reverse a lot of decisions that you made earlier.
So maybe you’ve made some design decisions about how form fields look, or color schemes and things like that, that now those decisions have to be redone, which then means whole parts of the website or the application need to be redone. If they were just done accessibly from the beginning, you wouldn’t have to redo things.
You know, it takes an equal amount of time to build a form one way or another. And if you’re gonna build it accessibly, it doesn’t really take extra time to do it. But if you have to do it twice, well now it takes twice as long because you built it inaccessibly first, and now you need to come back and build it accessibly and it’s gonna take twice as long, just by definition.
Natalie G: Mm-hmm. Yeah. Or if your theme is not accessible or the add-ons you chose are not accessible.
Natalie M: Yeah. You end up having to undo and redo a lot of things, and sometimes the undoing actually takes time. So now we’re over double time because now we have to, you know, here’s something that took an hour to do, now I’ve gotta spend 20 minutes undoing it, and then another hour redoing it. And now we’re over doubling the price, right?
Natalie G: Mm-hmm. Yeah, and I mean, at that point, you might just have to eat those costs yourself. Right? Because you already charged the client.
Natalie M: If you told the client that you were gonna build something accessible and then you didn’t, yeah, you need to eat those costs.
Natalie G: Mm-hmm. So gets really messy if it’s not done from the very beginning.
Natalie M: It does get very messy, very expensive, and very frustrating.
Natalie G: When you start from the beginning, you also get to set the accessibility standards for the team early, the rest of the developers, the rest of the content managers.
Natalie M: Content managers, the social media managers, the designers, the UX people. Yes, everybody’s aware, but this is something we need to be keeping in mind. Yeah.
Natalie G: Cause, like once everybody’s added their content, everybody’s added their blog posts, their pages. And then you say, “Oh, actually, you guys had to keep the headings in mind. Now you have to go through 30, 40 different pages,”
Natalie M: Yeah. Now you need to go back through them all. Check all of your headings, check all of your link texts, check all of your colors.
But you could have just done that from the beginning.
Natalie G: And then we also wanted to talk about automation and manual testing. Catching issues early.
Natalie M: Yeah, so it is a good idea to have some kind of accessibility check built into your development process. So there are libraries that you can use where every commit you make to a GIT repo is going to automatically get run through some basic accessibility checks to make sure that you’re not introducing accessibility issues that can be detected automatically.
So that’s a really handy thing to do. You could also set up an accessibility checker. Usually there’s some kind of a development site or a staging site that everybody is updating on a regular basis. You could have some kind of a checker running on that website. Something like AAArdvark, for example, could be hooked up to that website and run a scan every day to check for any issues that might get introduced.
But you would also wanna be doing manual checking of the website as well. So every developer should be testing everything that they’re doing with keyboard alone before they check it in, open up a screen reader, right, and just check it before they check it in. And then there should be an accessibility professional who’s kind of doing final checks on everything as well.
Natalie G: Yeah, because trying to do that at the very end of the project.
Natalie M: It is not gonna go well. It’s not gonna go well, and things are gonna get missed, and you’re not gonna end up with an accessible website at the very end. You do wanna be doing that all along the way. Yeah.
Natalie G: Mm-hmm. I have an extra question.
Natalie G: Okay. When you keep clients on a retainer, is checking in on the accessibility of their site part of that?
Natalie M: It could definitely yeah.
Natalie G: Okay, so every single, maybe month or two weeks, whatever your retainer is, you can say, “I’m gonna go through your website, I’m gonna tab through it, I’m gonna use the screen readers, and do just a quick check and let you know about any issues.”
Natalie M: Yeah. Yeah. That would absolutely be a great thing to include in a maintenance retainer.
Natalie G: Yeah. And again, this is stuff you can charge more money for. You’re more valuable.
Natalie M: Yeah. You build up this knowledge. It is. It is an income opportunity for sure, but also a chance to make the web a better place and more inclusive.
Natalie G: Yeah. ’cause there’s a lot of stuff on websites like contact forms, checkout, appointment booking.
Natalie M: Forms to leave reviews or write comments.
Natalie G: And if people can’t use those, they’re going somewhere else.
Natalie M: Yeah. They’re gonna go somewhere else. Yeah. Forms to leave donations for nonprofits.
Natalie G: Mm-hmm.
Natalie M: Yeah.
Natalie G: Alright. Do you wanna wrap up with where can web developers go to check on the accessibility of their projects?
Natalie M: Yeah, they could come over to AAArdvarkaccessibility.com and you could hook up a development site that you’re working on. You could hook up a client site that you have under maintenance if you made accessibility part of your maintenance package and run scans on a regular basis, daily, weekly, or on demand, and get back reports and keep track of how your accessibility is improving.
And you can also use it for manual testing. So if you’re gonna say, “Hey, as part of my maintenance package, I’ll manually test five pages of your site a month.” You can definitely use AAArdvark for that as well.
Natalie G: So go check out AAArdvark at AAArdvarkaccessibility.com, get your homepage scanned for free. Sign up. Register for an account. It’s free. No credit card required. And with that, we’re going to end the AAArdvark Accessibility Podcast. This is episode 16. Thank you guys for joining us, and we’re gonna talk to y’all next time.
