Accessibility doesn’t end once you’ve remediated issues or passed an audit. In this episode, we talk about what accessibility looks like in practice after the “fixes” are done. We dig into why accessibility must be an ongoing process, share the tools and workflows that make continuous monitoring easier, and explore how organizations can build accessibility into their everyday WordPress development and content practices.
Listen
Watch
Links Mentioned
Transcript
Chris: Welcome to the Accessibility Craft Podcast, where we explore the art of creating accessible websites while trying out interesting craft beverages. This podcast is brought to you by the team at Equalize Digital, a WordPress accessibility company, and the proud creators of the Accessibility Checker plugin. And now onto the show.
Amber: Hey everybody, it’s Amber, and today I am here with Steve.
Steve: Hello everyone.
Amber: And Chris.
Chris: Hey everybody.
Amber: And this is episode number 140 of Accessibility Craft. So if you want to get show notes and a full transcript, you can find those at AccessibilityCraft.com/140. We start every episode with a beverage.
Today’s Beverage
Amber: What are we drinking today, Chris?
Chris: We are trying a special flavor release from OLIPOP, which is like a health branded soda.
And it’s their crisp apple flavor. They claim this is going to be like mashing sparkling apple juice and gummy apple rings together into one. So, I’m expecting a lot of apple flavor and some sweetness, but this is kind of a health forward soda.
Amber: Are gummy apple rings normally sour, or they’re just sweet?
Chris: I think they’re a little tart, but mostly sweet.
Amber: Who has eaten gummy apple rings on this podcast?
Steve: I don’t know.
Chris: Not since I was…
Amber: No one?
Steve: I don’t know exactly what you’re talking about, but is it healthy?
Chris: You ever see like the peach ring candy, Steve?
Steve: Yeah, yeah, yeah. But Apple?
Chris: I think they have an apple version of that. They’re like usually green. So it should be like tart.
Amber: So are you guys into the OLIPOP trend? Is that big in Ohio? And do you guys drink this normally, Steve?
Steve: I mean, I see it around sometimes. It’s not like a regular thing, but sometimes when you go to parties you see people will have ’em.
But I will say this, that Chris sent a case of this to our house and I think there’s only two left.
Chris: Oh, okay. So this bodes well.
Steve: My wife and kids cracked into this pretty hardcore and drank ’em all. I had to say, Hey, you guys gotta save one of those for me. Like you can’t drink ’em all.
Amber: So that means they’re good and maybe we’re gonna thumbs up this beverage.
Steve: Yeah. Yeah.
Amber: I’m not, I haven’t been too into the OLIPOPs, but I feel like my mother-in-law and she’s like super health, nutty. Like this is the kind of soda that they buy. And our kids like it when we go to their house.
Steve: Is it real sugar?
Chris: This is one of those, it has the prebiotics in it, so it has like fiber and stuff in it, and then it’s lower sugar. I don’t know what their mode of sweetening is.
Amber: I don’t see sugar. It has apple juice concentrate, root what does that say? Cassava root syrup, apricot juice, lemon juice, stevia, Himalayan pink sea salt, natural flavors. So no, there is no sugar in this. No actual sugar.
Steve: Well, there’s…
Amber: Puts me on the fence.
Steve: Yeah.
Amber: Because I’m always weird about Stevia, leaves a weird taste in my mouth. I don’t know.
Steve: Well, it’s got 13 carbohydrates, but six are from fiber. It’s not that horrible. So five sugar carbs.
Chris: Yeah, so 40 calories a can.
Amber: This is how you know we’re all in our forties because we’re talking about how many sugar carbs we’re gonna get from our pop.
Chris: We definitely evolved past the younger person’s does it taste good or not, and not really paying attention to what’s on the label.
Steve: Us people in our middle age, we want to eat our calories, not drink them.
Amber: Yep. That is pretty much where I have landed too. But it is vegan and paleo and it, and the can it, it’s got a yellow background, but it’s, I don’t know. Is it a Yeti? Yeah. It kind of looks like a little snow monster guy holding up an apple. It’s a cute little illustration.
Steve: Yep.
Chris: All right. Well, I’m gonna crack open mine. I have not had this flavor. The flavor that they make that I really like is grape, but since this was a seasonal release and I’ve never had it before we went with this one.
Amber: I brought a pint glass today because I wanted to see what color it was. I was curious if it would be like apple cider colored. So here we go.
Chris: Yeah, definitely you smell the apple, but I also have like a metallic smell. I don’t know if that’s just the can, but, or maybe it’s the apricot? Maybe that’s what’s coming through?
Steve: Yeah, I think it is. It’s so not super strong, but on the other…
Amber: It looks like champagne. It’s not the dark apple cider color that I was sort of thinking it might be. It didn’t have a lot of like foam on the top when I poured it, you know, like root beer does. But it’s definitely pretty bubbly.
Chris: Yeah, it’s just like lightly carbonated apple juice is kind of all I’m getting. It’s very simple. It’s definitely sweet.
Amber: I don’t know if I like it.
Steve: Is it too sweet for you? Is that what it is?
Amber: It’s, yeah. I mean, that’s not, I don’t really drink pop at all. I don’t like apple juice. Like literal apple juice I think is one of the most disgusting drinks I have ever had in my entire life. I do like apple cider. Because that’s not as sweet or something. I don’t know what the difference is.
Steve: It’s concentrated, yeah.
Amber: Yeah. This to me maybe tastes a little bit, it’s weird, like it has a light apple flavor. Like it’s not as heavy as you would think from an apple juice, which I guess makes sense ’cause the juice is being cut by carbonated water and stuff. But it definitely has just like a lingering sweetness in your mouth. That to me is what I associate with Stevia that I don’t really like.
Steve: Oh really?
Amber: I don’t know. I feel like I can feel it.
Chris: Yeah. Drinking this. I think it’s not what I was hoping it would be.
Amber: What you want it to be?
Chris: Like, I was hoping it would be more tart, to balance out the sweet.
Steve: So more like cider.
Chris: Yeah. Yeah. That’s what I was hoping for. So it didn’t quite hit the mark for me. Especially ’cause they’re calling it crisp apple. To me, this is kind of like a, red delicious apple, which is like the worst of the apples. Like it’s not…
Amber: Yes.
Chris: You know, it’s not giving Granny Smith or Honey Crisp or some of the better apples.
Amber: When we lived in New York and we could walk and pick apples like Cortland apples from our neighbors orchard, I liked those, but apples that you buy at the grocery store or that they have, I don’t know if you’re at like a hotel buffet, breakfast in the morning. They have the apples and the bananas sitting there. I would never take one of those apples or want to eat it. I don’t know. So maybe that’s why it’s not totally getting it for me. And I still don’t understand what prebiotic means.
Chris: I like apples, but I like them with or in other things and not on their own.
Steve: Yeah, like pie.
Chris: Uhhuh.
Amber: Oh, I like apple pie. Apple pie is a breakfast food.
Chris: All right. Are we ready to vote on this one?
Amber: Yeah, I’ll go first. I give it just one thumbs down, I don’t think I would choose to drink more of it.
Chris: I’m in the middle on this one. I would have it again if there were not other choices and I was craving a soda, but it’s not something I’m gonna go outta my way or be excited to have.
Steve: On my own, I probably would be neutral, like in the middle. Given the fact that the kids like it so much and maybe ’cause of the sweetness I’ll give it one thumbs up by merging in the family’s vote.
Amber: So you might buy it again, maybe not for you, but for other people in your house.
Steve: My wife might buy it again. I don’t know if I would.
Amber: Averages you up.
Steve: Yeah. Yep.
Amber: This is probably one of the first beverages where we have had one of every rating.
We almost always agree. Or we have one person who’s different from two. So this is kind of an interesting beverage there. I feel like our listeners should go try for themself and figure out where they are.
When do we shift from accessibility remediation, to accessibility maintenance?
Amber: So I wanted to talk today about sustaining accessibility on WordPress websites. You know, it’s not just checking off the boxes and now you’re done. What does accessibility look like over the long haul? And I think we’ve had some interesting conversations about this internally and then also of course, we have them with our clients. And so I thought maybe this might make a good podcast episode.
What do you guys think?
Steve: Let’s do it.
Chris: Sure. If we’re talking about sustaining accessibility for the long term, I think that kind of the underlying thing there is that assumes that remediation has finished or is over, right? So what indicators would suggest that it’s time to shift from we’re auditing and fixing to, we’re just maintaining now?
Amber: Do you wanna go first, Steve?
Steve: Yeah. I mean, I think there’s certain thresholds where you can make that consideration and I think, I mean, we kind of started by saying, a project has ended, right? But now we’re kind of sidestepping, when does it move from ended to maintenance, right? And I think there’s, you know, there’s certain places you can get to. There’s certain level of compliance that you can reach either through your automated checks and your manual auditing to get the website to a place that it’s all accessible right now. Now nothing guarantees it stays that way, but we can say it’s all accessible now and we need to monitor this moving forward.
And I think that’s what you’ve solved most of the issues that can be identified in an automated tool, and you’ve actually done the manual auditing as well. But there’s a lot that goes into ongoing, maintenance and, you know, a lot of internal processes in your company or with your website that you need to utilize to ensure that ongoing.
But that’s kind of what I would say once you’ve gone through those initial steps and you can consider it, Hey it’s, I’m gonna go out there and say, spoiler alert, it’s not ever done. But this is a point in which you could kind of switch over to monitoring.
Amber: Yeah. I mean, in our audit and remediation plans we have them a lot of times start on really high numbers of hours per month depending upon how many problems they have and how quickly they wanna get those problems fixed. And if I’m giving some concrete examples, some of the things that we’ve used in the past to be like, okay, you’re at a point now where you could maybe drop to a smaller number of hours because it’s not an emergency, is all of their top pages that get traffic in Google Analytics have zero problems.
So some number of top pages. All of the core pages in their user journeys have no problems. Or we look at what’s in Accessibility Checker, ’cause we use Accessibility Checker on all of these. And maybe the only thing that’s left is links to PDFs, right?
So it doesn’t necessarily have a 100% score and Accessibility Checker because maybe they have 500 links to PDFs and they have to create a plan on either removing them or replacing them or remediating them. But all of the actual pages in Accessibility Checker and HTML content on the website, it has been totally remediated.
I think another thing that we have used in the past as well with colleges and universities that have been in trouble with the Department of Education is , that external body who is also checking the website, comes back and says, okay, you’ve made enough progress now that you’re not in trouble anymore. So they might have very specific pages that they’re looking at or certain types of content or certain user journeys. And so when that body says you’ve made enough progress, then sometimes we can say, okay, maybe we slow down and we’re gonna continue working on the other content that they haven’t checked.
You don’t have to feel like you’re in such an emergency that you have to be dedicating many hours every week or every month to the remediation, and now it’s more in a maintenance or ongoing plan.
Why isn’t accessibility a one-and-done thing?
Steve: Yeah. So I kind of alluded to this, but why is accessibility not a one time project and what risks are there in treating it that way?
Chris: So I’ll start. I think the chief risk of treating accessibility like a one time project is the overwhelming majority of websites, unless maybe you’ve built a single static HTML page that contains only text are living, breathing things.
So you have content editors coming in and modifying, updating or changing content. You have plugins and themes or components that are being updated at the code level. And then you have third party integrations. So if you’re, you know, integrating payment forms or web forms or resource libraries, or any number of other things there’s also accessibility considerations with those external platforms.
So for all of those reasons and probably more, accessibility can’t be considered one and done. It doesn’t mean that it takes the same effort the entire time, right? Like it’s not always this massive 40 hour a week project, but it does take consistent effort and thought.
Amber: Yeah. The other thing that I might add there is that over time guidelines and best practices and our understanding of what accessibility is can change.
Different laws might come into play that require different things of websites or newer versions of web content accessibility guidelines. We actually just had this conversation on the WP Accessibility Day organizing team because we have a couple forms that ask people to verify their email address, and in WCAG 2.2, you’re not supposed to ask people to reenter information, so actually that email verification that makes them retype, it is no longer WCAG conformant it in a 2.2 standard. That wasn’t a standard that existed before, but now it exists. And so we need to make a change in order to make sure that our website complies with this newer standard level. So that’s another thing, you know, just keeping in mind. And I think it is very similar to how we think about security or privacy or search engine optimization.
I don’t think any of us would ever say, my website is secure now. I’m done. My website is optimized. I’m done. Websites and the internet changes. I don’t know, what do you think, Steve? Every day, every minute?
Steve: Yeah. I would just tag on to that too, you know, just like with the laws and the standards evolving over time your internal team evolves over time too and you have to mitigate against churn. And , a lot of times you implement accessibility best practices in your company and then say that team turns over time, they leave the company, new people come in. And you’ll find yourself at a place where you have to retrain or you have to re-implement these rules or re-explain the importance of following these accessibility rules. So I think that’s an ongoing effort as well is churn within your own company.
Amber: Yeah. I think too, if you forget to explain things and you have a new content creator, if you’re not monitoring them on a regular basis, they could be adding significant problems to the website. You know, every time they add a new page or if they have the power to install plugins.
Let’s talk about that a little bit. After remediation and that big spike of time over however many months where we’re doing intense rebuilding of things. Now you’re in that maintenance mode.
What does ongoing accessibility maintenance actually look like?
Amber: What do we think that ongoing accessibility looks like in a day-to-day practice? And I’m wondering, Steve, maybe if you could talk about this from a dev perspective, and maybe Chris could chime in on the content side?
Steve: I think at a very high level that you need to have this stuff built into your PR and your deployment processes to make sure that there’s checks for these certain things. That there’s linting and there’s component checklists and even some level of user and keyboard testing that is done with each pull request to ensure that you’re not introducing you know, inaccessible stuff into your stack, into your theme, or your plugins that you’re using. ‘Cause that can just completely circumvent the efforts of any content creator if it’s not done at the development level.
Amber: So you mean like you don’t think anybody should just go install a plugin on production, it needs to be put somewhere else and tested first before put on a live site?
Steve: Yeah, I think so. And I think smaller websites a lot of times will, oh, I need this feature, right? Say I’m writing post and I want like a bulleted list of all the headings on my post, right? Well, this plugin does that and I install it, but you know, okay, that plugin doesn’t have proper headings, it’s not in a list, things like that. And we’ve started to get a little bit better about this even in our own organization where we’re not so, oh, here’s a plugin, install it, run it. And now it’s Hey, we wanna do this, these plugins do it. Let’s have the development team kind of review ’em and make sure you know that the output is accessible. And not just that, this goes into like security things too. Was this plugin even created with best practices, from a security standpoint? And you wanna do the same from an accessibility standpoint
Amber: And performance too.
Steve: Yeah, exactly. Yeah.
Chris: So on the content and just general operational side, I think training and documentation are big ones and developing those, around accessibility specifically, or integrating accessibility components into existing trainings or existing documentation for your content teams and for other teams as well. Just to make sure that they’re considering the areas or the domains that they have control over that they’re considering accessibility in those areas or domains.
So for content creator that might be saying something like, Hey, we have this accessibility scanning tool. And on this site when you publish or before you publish, check to make sure that you’re not adding problems and try to resolve any problems. And here’s the point of contact on our team if you encounter an issue that you don’t know how to solve, right? Those sorts of things.
The other one I think is somewhat what Steve was alluding to, where you’re, you know, you’re evaluating solutions before you just install them on your website. And not to do that, just willy-nilly right, to have a process there.
But I think accessibility can also tie into procurement processes a little bit, particularly at the institutional level. So if you’re a larger organization, making sure you’re talking to your procurement teams who are going out and working with various departments, like selecting different softwares that you might be using, and making sure that accessibility is a component of that procurement process.
If you’re buying a new accounting system that’s gonna allow customers to come in and make payments may be part of that process for evaluating it should be to ask all of the solutions you’re considering to furnish you with an Accessibility Conformance Report. And if they can’t, maybe that doesn’t disqualify them, but maybe you ask them for supplemental documentation or anything they do have, right? Or you in independently test in house if you have the capability, right?
And then finally I think ongoing accessibility, definitely having, at the very least some sort of automated monitoring system in place because that doesn’t require a human being or human work hours. You can use a tool like Accessibility Checker to automatically scan your website, and anyone hit save or publish, it’s going in, it’s checking 45 different checks, I think is the latest count, and it’s finding issues that might get introduced. Or marking issues is solved if they’re solved. And it can’t find them anymore.
How can Accessibility Checker help with ongoing accessibility?
Chris: And that actually leads me to another question which I already pre-answered a little bit, but I know there’s more to it. What are like the myriad of different ways that Accessibility Checker can help maintain accessibility on WordPress sites over time versus just getting you to accessible?
Amber: I think a good point there is that every time content is edited, it’s being checked. I think sometimes people might think, oh, I only need an accessibility checking or auditing software when I’m doing remediation.
But the reality is you need those automated checks anytime a content creator is adding a blog post. So unless you have a website that is static that gets zero content changes, you need that and you want that scanning. And then you, as you mentioned, Chris, there needs to be training, or maybe Steve mentioned that, but you need to train your team that just like they go to the SEO box and they check their SEO score and make sure it’s green or whatever the happy color is for their plugin, they also need to check Accessibility Checker and they should not be publishing any content that doesn’t have a 100% in Accessibility Checker.
I’ll say also going back to that, what is the line like for us on remediation. When remediation is done, anytime you were to create a blank post or page, it’s always going to say 100%. Which means that then when the content author comes in to add something new, if they don’t see 100%, it means they created a problem. And so I think that is a big way that accessibility auditing can, but also we have some fixes and I wonder if you could talk about those, Steve?
Steve: Yeah, and when you talk about accessibility is finished , does that mean you can uninstall Accessibility Checker right? And I want to kind of highlight some of the reasons why uninstalling Accessibility Checker is probably a really bad idea, and which you two just alluded to, a lot of those things. But we also have fixes like Amber said, and what the fixes do is the fixes actually are defensive against somebody doing something bad. Something inaccessible, right?
So if they say that you’ve decided to be accessible, you don’t want links opening in a new window, right? So you can enable a fix in the plugin to prevent links from opening in a new window. Or you can actually put the proper accessible warning that they do open in a new window.
So if one of your content creators actually do that, the plugin is like, Hey, we’re not gonna allow that, it’s gonna fix it on the front end for you. And also Amber said, getting to that a hundred percent before you publish, right? So, without keeping Accessibility Checker installed, it’s hard to keep that at a hundred percent because there’s actually warnings in there that require a manual review.
So when you get a warning, you go look at it, you check to see if it actually is an accessibility issue, and then you can actually put in an Ignore with a message on why. And that gets stored and that gets saved over time. So Accessibility Checker actually is keeping a log of your manual review at that point.
I think in that way it helps aid you in the ongoing maintenance of accessibility. Chris, do you have more to add to that?
Chris: Yeah, just a small thing, which is, I was thinking about the fact that probably no one would be like, I’ve done enough SEO, I’m gonna uninstall my SEO plugin, right? No one would probably be like, okay, I haven’t been hacked in a while, I’m gonna uninstall my security plugin.
I think it’s important just with those other examples, like this is all part of a holistic quality stack, if you want to call it that. And none of these things stop , whether it’s SEO or security or accessibility, it’s this ongoing effort that has to happen.
Amber: Yeah. You know the other thing too that I thought of, and I think we might be adding a notice to this, to our pro plugin. You can tell me if I’m wrong, Steve, but when we were talking about testing new plugins or plugin updates. So you could, on your staging server, hopefully that’s where you’re doing it, you run all your plugin updates and then you can in Accessibility Checker Pro run a full site scan. And then you can check and see what the difference was in your score, and that might be a fast way. Now, of course, you should still do some manual testing because automated can’t catch everything.
But that could be a very fast way to know, oh, these plugin updates are going to introduce a problem, and I don’t want to run these updates on my live site, I need to go back to the developer first and say, Hey, did you know that it introduced this bug?
Steve: Yeah, and I would tag onto that too, that Accessibility Checker itself is not a static plugin. And when you decide to use Accessibility Checker you actually are adopting the full user testing knowledge of our whole base of users. Hey, I, this rule seems a little off, right? Or I did this, here’s the scenario. This is this, correct? And then we’ll go through and we’ll reevaluate a rule. And if we determine that, hey, that was maybe a false positive or a false negative on our end, we’re modify the rule, we’ll make it better.
We’ll throw that scenario into our testing suite and then the, that will go out in a release. So when you update Accessibility Checker, the rule is smarter and may find accessibility issues that it wasn’t finding before. So you’re getting our knowledge of continually improving this plugin, but also the whole user base giving us feedback on how it works.
Amber: So a thing I think that is worth noting on the Accessibility Checker, like continually monitoring, was we were talking about, yes, it does do some like background scanning, but a person still has to look at those reports, whether they’re the person authoring a new piece of content or whether you’re going on a monthly basis, running a full site scan and then going and reviewing for any new issues or you’re doing manual testing on the front end.
How does manual testing fit into ongoing accessibility montioring?
Amber: Maybe Chris, you could talk about this a little bit, but what role do you think manual testing plays in ongoing monitoring, and how frequently does it need to be done?
Chris: I think manual testing is essential for ongoing monitoring. A automated testing tool, and we’re clear about this in our documentation, is only going to catch a percentage of the issues. And the more hyper specific the tools checks are to a particular CMS or system, the better and more accurate it’s gonna be. But no automated testing tool is perfect, so you have to test manually and you can do that with in-house people, if you have people who are skilled up and understand how to use screen readers and how to test with a keyboard.
Or you can partner with an external organization if you want. But I would say the cadence somewhat depends on how active and how complex your website is and what you think your risk profile is to be frank. Like not just around lawsuits, but just around like potentially causing a serious issue for a user, right? Because that’s part of risk too. You want to make sure that you’re serving your users effectively.
If you’re something like an e-commerce company I would say quarterly at least, you should be doing manual tests, if not monthly. If you can sustain that. If it’s like an informational or a brochure site where there are multiple different methods to achieve the outcomes that someone’s trying to achieve by interacting with your business or your organization. And it’s not solely reliant on the website, i.e. that’s a very roundabout way of saying your website is less important and less essential operationally, maybe every six months or every year. I would say every year is kind of a minimum for a manual spot check.
And that kind of aligns with what our monitoring plans are. So we have monitoring plans that customers engage with us on post remediation, and there’s, you know, there’s a monthly one, there’s a quarterly one, and then we have every six months, and annual.
And we can do custom ones as well. But those are kind of how those interact and kind of where I would draw the line.
Amber: Yeah, I think too, the other thing would be just looking at specific pivot points where the website is having significant changes. So if you’re building a brand new landing page, or if you are installing a new plugin, or if you see a current plugin has some sort of major version update, that significantly changes and it is probably worth doing manual testing at that time, not just automated.
I think there’s also a line too, I would say generally anyone creates content, should understand how to just do some keyboard testing through, can you get to everything? Can you know, submit with a return key and a space bar when necessary? All of those sorts of things. But then maybe at a less frequent cadence, you have specialists come in that can do the screen reader testing.
How can developers adjust workflows to maintain accessibility?
Chris: So that’s on the content and kind of the organizational side, the high level. Steve, thinking about development teams specifically, how can they bake accessibility checks into their workflows?
Steve: So this is rapidly evolving with the onset of AI, but traditionally you know, you want to have some kind of pre-commit thing set up. We do this a lot where with our code bases, where we have pre-commit rules that where you can’t even get to GitHub unless you fix the issues in your IDE before you submit to GitHub. So, you could run pre-commit things, you know, and these are typically like on the code side, like ES Lint or PHPCS, but there’s also, you can do some stuff with axe and I think there’s Sa11y, I think it’s called.
There’s an API, you can even run the lighthouse API, to run checks against. Some of this stuff requires a browser, so you would need to implement like something like playwright, which is like a virtual headless browser. There’s some extensions for like VS Code that can do some linting for accessibility in the browser. But that typically only works on JavaScript in HTML. It doesn’t work on PHP. PHP presents a big challenge in doing some of these accessibility linters, but we’re in this new AI age, right? And that kind of kind of ups our abilities and our options here.
So in our dev workflow, we run, AI reviews on all of our PR commits, and so we use like Code Rabbit and Gemini and even Open AI’s codex now has a PR review. Code Rabbit is the more premium one we use. And Code Rabbit will find, it’ll run some of these accessibility linters in the backend and it will actually find and highlight and identify accessibility issues on your pull requests. And we’ve had a lot of success with that.
And basically it just does a PR review and opens an issue and a lot of times it even provides the fix and you can just apply the fix right from there in GitHub, you don’t have to actually go do it all yourself. But there’s also a lot of like more interesting things coming up with MCP servers. That’s the model context protocol servers, which is basically like the new API for AI agents. Using those alongside with things like Google Playwright to run a headless browser, you can do integration tests where it actually opens the page, these are automated scripts that go through and click on certain things and run certain tests and test for certain feedback.
So there is a whole wealth of options these days and the AI stuff is making it easier and quicker and making it a priority within your development team to implement that in your workflow.
Amber: I’ll note for anyone who did register for WordPress Accessibility Day, if you missed this talk, you can still go watch it in Zoom, I think through October 31st. Or otherwise it’ll show up on WordPress Accessibility Day YouTube. But, Helen from GitHub gave a really interesting talk called Continuous AI for Accessibility, Leveraging Tools for Faster, More Inclusive Development, and I think they are making axe linters available to everyone. So definitely go watch that talk. Maybe if you wanna learn a little bit more about what Steve just talked about, because there’s more clear demonstrations.
How should organizations document accessibility for better long-term outcomes?
Steve: So that’s a big overview on the technical side and how to implement that in your workflow. But let’s jump back a little bit and talk about training or documentation. What training and documentation helps non-technical team members avoid introducing new accessibility issues?
Amber: I can take that one. I would say the best examples I can think of is if you go look at any of the major universities’ websites and you just search for accessibility, a lot of them have really great examples of how they’ve documented how to create accessible web content for non-technical people, because they sometimes have hundreds of websites that are edited by faculty member and students and staff workers, and all kinds of people who are not, you know, they know how to write, but they’re not web experts or accessibility experts. But I would say at a minimum, if we’re talking non-technical, you wanna look at whatever it is that you allow content creators to do in your WordPress site.
So if they can only edit in the main area, then you really just need some documentation probably on maybe not even color contrast because if you’ve fully controlled that and taken away their choice to choose colors, you might not need that. But if you have that, they need to know and they need to understand about color contrast, heading levels, selection, having some sort of documentation on that. Alt text for images.
I would really suggest that you need to have some clear documentation around like linked documents or PDFs. ‘Cause that comes up a lot. Establish a process for getting those checked if they don’t know how to check them, or potentially an Accessibility Checker, we have a feature where you can block any user from uploading PDFs except for like administrators, or you could assign that to whatever user role you want. So you could have a process where maybe your regular content creators can’t upload a PDF, but then you’ve documented, okay, what do you do if you want a PDF and they have to go get it tested by this other person at your organization who’s an expert in PDF accessibility. Once they confirm it’s good, then that person can upload it. Or the webmaster can upload it or whatever that might be. So I would say that is helpful. I would recommend at a minimum, based upon the churn at your organization, probably you need to have some sort of webinar or internal training at least six months, every six months.
Maybe it needs to be more frequently, but even if you don’t have a lot of churn, people forget stuff. So you should have refreshers at least once every six month as some sort of, all hands meeting that applies to all of your people who edit your website that just goes over you know, things people are missing.
So what you could do is you could go look at Accessibility Checker, full site reports, and monitor those and then figure out a list of these were all fixed, but now these issues are coming back up. We do this with our clients. We get on a call with them and we say, Hey, so in the last three months from our prior quarterly stand, here’s what we noticed that got introduced. We’ve fixed them, but let’s actually walk through and I’ll share my screen and I’ll show them in the editor, where they, what they missed or what they could have done differently to not introduce that problem. Again, so I think that’s a good way to use Accessibility Checker to kind of alert yourself to stuff that might be happening behind the scenes, and then use that to develop a training plan.
Steve: Yeah, and I think that if you are using Accessibility Checker, you don’t have to necessarily create all that technical accessibility documentation yourself. It comes along with the plugin. So if that content editor is editing the page and you know, and they get a alt missing warning, they can go down to the issue and click on our documentation. We have very in depth documentation on how to properly add that alt text.
How much does all this cost?
Amber: Yeah, so I think this is interesting, and maybe you can answer this question, Chris. But this whole time we’ve been talking about this is an ongoing thing, and it’s something that you don’t just do as a one-off project. Well, that of course means that there’s an ongoing cost associated with it. How do you think organizations should budget or plan for accessibility and ongoing maintenance in that sense?
Chris: So I think, the investment that goes into accessibility should scale up or down with the organization’s total budget. I don’t know if I can say that as a certain percentage, right? But I think at minimum the budget should involve, the time of maybe a couple of accessibility champions on the team, putting together some trainings and some free resources, and maybe having the free version of Accessibility Checker running on the site. And I’m talking about a very resource strapped organization that has very little to spend, right? You can even invest time and energy in free tooling and putting together lists of resources for your team, even if you have $0 to spend on this, and that will help you maintain some semblance of accessibility. Maybe not to the best level you potentially could, but it would be something.
I would say as organizations get into the, you know, small business territory, which is, you know, half a million to 5 million revenue. You should at the very least be budgeting for some form of automated testing tool. If you have one website, that’s $149 a year for Accessibility Checker. And then a monitoring plan should cost, again, depending on the size of your website and the scope of the monitoring, it should cost from somewhere between one and four thousand dollars a year, to have manual monitoring done on your team’s behalf.
And then training might be another thousand to two thousand a year. So we’re talking about a very tiny percentage of a budget of 500,000 to 5 million. It would be sub 1% or even sub a tenth of a percent, depending on where you are in that range. Above 5 million, I mean, there’s even more that can be done right around like user testing, focus groups and routine audits. And if you’re a product company, you know, having formal accessibility documentation produced and maintained, right? There’s even more that can be done. But Amber, it sounded like you wanted to add.
Amber: Oh, I was just gonna say, I would actually advocate for anyone that’s in that 500,000 plus range they need the Small Business plan. And the real reason for that is that includes our audit history add-on. It includes the CSV export, which if you have teams that rely on GitHub, sometimes they wanna be able to put these things into GitHub issues quickly. Or into project management tools, especially if you get into really big companies. Maybe they’re using Jira, I don’t know.
So I would say you probably wanna budget at least to have that Small Business plan. ‘Cause that also gives you multiple site licenses, which means you can be running it on production and on your staging and on your dev environment. And testing in all of those ways.
Steve: Speaking of licenses so, we were traditionally an agency and we’ve got, you know, a good set of legacy customers that we host their websites and we do website maintenance packages on and things like that.
And there are certain plugin licenses that we will buy and share across all the customers on those maintenance plans. When it comes to Accessibility Checker, like should you know, small agencies, freelancers, should they be buying the license for their clients or should the client be purchasing the license?
Amber: Yeah, the way I think we’ve always thought about this is this something that we’re going to use on many sites? And if so, it is way easier for us to manage if we have our own license and we don’t have to worry about, oh, the client forgot to renew their credit card number, credit card, and it now suddenly it’s not working.
So, so we’ve done that verse, you know, if it’s a one-off or maybe only one or two clients are gonna do it, then we usually will tell them, okay, you need to go buy the license for this, because it doesn’t make sense. So I would say from an agency perspective, you wanna think about are you rolling this out to all of your clients or a good number of them included in some sort of plan.
And then it definitely makes sense for you to just own the license and have that connection. Or maybe not. If it’s part of an initial website build, let’s say maybe you use your license to build, but before launch, you tell them to go buy their own so that you know that it’s going to be maintained without you having to do it.
Do you have thoughts on this, Chris? From like the budgeting perspective?
Chris: The thing that I will usually tell agencies is it kind of depends on their own business model and whether they’re trying to have customers on lengthy retainers and improve like the stickiness or the lock-in on those containers, or containers, excuse me, retainers.
The more holistic of a solution you can offer your customers as an agency, and if you’re bundling, you know, a bunch of premium plugins and features with hosting and with maintenance, the more that you layer onto that, if it’s producing a positive outcome for your customers, which accessibility scanning and fixes would. That’s just another way to keep them in. But if on the other hand, if you’re more of a, you know, churn and burn and get them out the door and get the next project going it may behoove you to have your customer purchase the license, if you’re not doing any sort of maintenance.
We share our final thoughts!
Amber: Yeah, so do either of you have any final thoughts on how we might shift clients or stakeholders mindsets about, it’s not just a checklist item that’s done, but it’s accessibility is a continuous process.
Steve: Yeah, I think I’ll take the development angle here and say that development specifically in the WordPress world, development never stops with a WordPress website.
It may appear on the front end that it stops, or it may appear to a site owner that it stops. But any site maintainer knows that a WordPress core is constantly being updated. WordPress plugins themes are constantly being updated and therefore, any number of changes could be made to your website at any time, so it is always advantageous to be proactive and constantly monitoring the accessibility of your website.
Amber: Yeah. You know what I might add on that, this is kind of an interesting thought, but our friend Kyle from the admin bar, he has this PDF that he sells. It’s really cheap, like 30 bucks or something. That’s called the website owner’s manual. And he basically, he made it to give to his clients to motivate them to stay on maintenance plans. And then it worked so well that he started selling it. And we’ve never bought it. I’ve never seen it, but like I see people in the Facebook group sharing about it. But basically, like you said, Steve, they don’t realize how much happens behind the scenes. And so if somebody’s eh, that’s okay. I can just do it myself.
It’s oh, okay, well here you go. Here’s your instruction manual. And it’s like a 40 page document, something, all these detailed instructions for like how to update plugins, how to do all the maintenance things that you have to do. And suddenly they come back and they’re like, actually, nevermind. Your plan feels really good.
So maybe part of what needs to be done to encourage people to think about accessibility as this ongoing thing is you need to document, like create that big list, you know? And I mean, certainly, it’d be pretty easy to draw and maybe we can work on something here for ours that shows like’s how it’s gonna stay…
Chris: Not to interrupt, but Amber it sounds like you came up with a banger of an idea for our content pipeline.
Steve: Yeah.
Amber: Apparently I’m coming out with one right now.
Steve: Yep.
Amber: Write something that’s basically what are all the accessibility things that has to be done on a regular basis. And then if you hand that off to your client or to like VP at your organization or whoever it is that decides on budget and you’re all like, well, here’s the deal.
You could do this, or we could hire this great dev who will do it for us, or consult accessibility consultant who will do it for us, and also here’s a software that saves us a bunch of time because nobody has to go manually check for images missing alt text. It just finds them and tells you, right?
Like I think there’s ways to show the amount of work that it takes that then maybe motivates people to understand why they have to invest in it in an ongoing basis.
Chris: And I’ll close this out here just by sharing like the agency business angle of this for our agencies and freelancers listening, treating accessibility as an ongoing engagement, just like you would SEO or website maintenance or anything else, is a way for you to serve your customers better and improve their outcomes while making more money on an ongoing basis.
So win for the customer. Win for you. And the sooner you treat it that way, the sooner you’re going to have another lever you can pull to grow your monthly recurring revenue as a business owner.
Steve: Perfect.
Amber: Well, I can’t think of a better end than that.
Steve: All righty.
Amber: All right.
Steve: Cheers.
Amber: Well we’ll see you guys back here in two weeks.
Chris: Gonna finish my apple juice. Bye everybody.
Thanks for listening to Accessibility Craft. If you enjoyed this episode, please subscribe in your podcast app to get notified when future episodes release.
You can find Accessibility Craft on Apple Podcasts, Spotify, and more. And if building accessibility awareness is important to you, please consider rating Accessibility Craft five stars on Apple podcasts. Accessibility Craft is produced by Equalize Digital and hosted by Amber Hinds, Chris Hinds and Steve Jones.
Steve Jones composed our theme music. Learn how we help make thousands of WordPress websites more accessible at EqualizeDigital.Com.