Remediation or Rebuild? — Amber Hinds and Steve Jones

>> PAOLA GONZALEZ: Welcome, everyone, to WordPress Accessibility Meetup, Remediation or Rebuild with Amber Hinds and Steve Jones. We have a few announcements today. If you want to connect in between meetups, the best place to do that is in our Facebook group. There we talk about anything and everything related to accessibility. If you have a question about accessibility, if you’re pretty good about accessibility, you want to be part of the community and answer questions for other people, this is a great place for that. You can join our group on facebook.com/groups/wordpress.accessibility. You can also find upcoming meetup events and past recordings in one place. Yes, this meetup is being recorded, and we usually post the recordings about two weeks after the event. You can find those at equalizedigital.com/meetup. If you want to stay updated with our upcoming events, news about accessibility and anything and everything in between, you can join our e-mail list, and you can do that at equalizedigital.com/focus-state. You can also tune into our podcast where we put up the audio version of these meetups, and also conversation talks about accessibility.

You can find our podcast at accessibilitycraft.com. We are seeking additional sponsors for the meetup. The WordPress Foundation told us we have to– we’ll find sponsors if we want to have ASL or captions at our meetup. We would appreciate if anyone would like to sponsor us. You can always e-mail us at meetup@equalizedigital.com if this is something that you’re interested on, or if you have any suggestions for the meetup or need any additional accommodation. That e-mail goes to both me and Amber. That’s the best way to contact us.

Who are we? We are the organizers of WordPress Accessibility Meetup. We’re Equalized Digital. We are a mission-driven organization and a corporate member of the IAAP focused on WordPress accessibility. Our WordPress Plugin Accessibility Checker scans for accessibility problems and provides reports on the post-edit screen to make building accessible websites easier. You can find us at equalizedigital.com.

We would love to thank our live captioning sponsor today. We have Kinsta. Kinsta provides managed hosting services for WordPress. It is powering 120,000 business worldwide, and based on the user reviews, it is the highest-rated managed WordPress host on G2. It has everything you need, including an unbeatable combination of speed, security, and expert support. Powered by Google Cloud and the fastest C3D and C2 servers combined with CDN and Edge Caching.

Your sites are secured with Cloudflare Enterprise, protecting you from DDoS attacks. All plans include free migrations, and the first month of the starter plans is completely free, so you can try the service risk-free. You can find them at kinsta.com, and we always like to remind attendees if you would like to thank our sponsor anywhere on social, you can find them on all the socials at Kinsta, and let them know that we appreciate them for sponsoring Meetup.

Now we have our upcoming events. Next week, we have an Accessibility Checker Webinar with Chris Hinds. If you’ve been on the verge of knowing if you need a tool for accessibility, and if you maybe have been thinking about accessibility checker, this is the best place to get your answers for that, and that’s going to be on Wednesday, on May 7th at noon, Central.

Then our upcoming meetups are Selling Accessibility Panel Discussion with Amber Hinds, Bet Hannon, Gen Harres, Ron Zasadzinski, and Scott Tobin, and that’s going to be on Monday, May 19th at 7:00 PM Central. Then at this same time slot, the first Thursday of the month, we’re going to have ARIA for Beginners with our own Maria Maldonado, and that’s going to be on Thursday, June 5th at 10:00 AM Central.

I’ll be looking forward to this day. We are going to be part of Global Accessibility Awareness Day this year, and it’s going to be on Thursday, May 15th. We usually hold a webinar or a panel discussion, but this year we wanted to do something more impactful. The way that we’re doing that is that you can join us celebrating GAAD by pledging your time to improve accessibility in WordPress. You can do that by working on your own website, working on plugins or themes, anything related to WordPress accessibility.

I will post the link in the chat right after I’m done with the announcements, so you can pledge your time, you can pledge anywhere, whatever time you want available, even an hour. That’s going to make a huge impact for GAAD. I think I’m done with that one.

It’s time to introduce today’s speakers, Amber Hinds and Steve Jones. You may have seen them here and there, so I’m not going to be doing long introductions. Amber Hinds, CEO at Equalize Digital, and Steve Jones, CTO at Equalize Digital. You guys can take it away.

>> AMBER HINDS: Awesome. Now it’s always fun doing this switcheroo with sharing screens and all that. Steve and I– he might be better than I am. I will tell you, I’m not super great at watching the chat while I’m speaking, so we will definitely do Q&A at the end. Paola will come back to do that. There is a Q&A panel where you can post your questions, so I would definitely say if you want to post them, do that for us there, and then we’ll answer them at the end. I always forget which button I’m supposed to press.

We’re going to talk about remediation or rebuilding and how you determine what the right path is. This is something that people ask us all the time. Basically, we have a lot of accessibility issues on our site. We know that it’s not great. Should we fix them or should we start over? We’ve had people come and ask this that had a website that was 10 years old. We’ve had people ask that that have a website that’s one-year-old, and they’re realizing, “Darn, our dev team did not do what we thought they were going to do. Is it fixable?” That’s basically why we decided to do this presentation because it’s a question that I think a lot of people have all the time.

And at a high level, we do a sales or strategy assessment, look at what accessibility checker’s outputting, just a quick manual audit of the homepage, not a full audit, but just a manual look at what’s happening on the homepage, header, footer, navigation menus, and then a dev assessment. We’ll talk about each one of those in greater detail, but that’s the high-level of things we look at.

From a sales standpoint, what we’ll consider is things like, how old is the website? If it’s brand new, the person who asked us that had a one-year-old website, obviously, the idea would be, “Well, can we fix this?” Because putting a lot of effort into a new rebuild or budget into that when you’ve just done it is overwhelming. If it’s really old, then maybe it is time to just rebuild from scratch anyway.

Some of the questions that can help you to assess that is, does the aesthetic still represent the brand? Are the colors still right? Is the language still right? Even just the layout and the design, does it do what needs to be done to represent where the organization is right now? Then, is the website meeting goals or getting the desired numbers of conversions? Of course, that can be very different depending upon what website it is.

On e-commerce, it’s easy. Are you making enough sales? On a service-based company, it might be about numbers of lead forms submitted, that sort of thing. Is the website moving people where they need to be and eliciting the number of page views that you want and the number of actions taken on those pages that makes sense for the entity?

Another one is, is the website easy for the content team to edit? Steve will talk more about this when he talks about the dev assessment, but we have gotten into websites where we found that the entire homepage or some other pages was completely hard-coded in the theme, or things that maybe they’re not hard-coded, but they’re using a specific page builder or editing system that the content team doesn’t understand. That could be an argument potentially for doing a rebuild.

Also, we’ll ask questions about what changes might be coming in the future that might be added to or edited on the website. Sometimes, knowing that there’s going to be a huge shift in focus for an organization is an argument to rebuild, but also, sometimes that’s an argument not to, because sometimes they’re like, “Well, we don’t want to do any major work until that’s done because our whole team is busy developing this new product or working out what the organizational shift is going to be for services,” or that kind of thing, philosophy kind of stuff that would get in the way of doing a full rebuild.

It is interesting. Sometimes that’s an argument, “Let’s do a rebuild right now because we know that we’re going to launch all these other products and we want to make sure that they’re really showcased in a way that they aren’t on the current site,” so it makes sense to just rebuild in order to align with those organizational goals, and then sometimes it may be the opposite. Really being aware of what’s coming in the future, and the future isn’t necessarily three months. It could be a year from now. Really asking people to think out ahead. What should we be aware of?

Then we’ll just generally ask abroad, what else do we know about the current tech stack of the non-tech people on the team? Obviously, you still need to have a dev come in and do an assessment, but it’s good to just get general ideas. Are there a lot of plugins that they have or a lot of custom things, or are there third-party integrations that they have to continue integrating with? Just getting a broader picture from those teams because sometimes they have organizational knowledge that we just don’t have, we’re coming in to initially assess something.

Then we do the accessibility audit. Like I said, sometimes we’re doing this as part of a sales process. Our partner, Chris, is sometimes doing some assessment before he sells them on a remediation plan or rebuild plan. This isn’t a full accessibility audit with an accessibility specialist. This is more of a– I’m going to call it a non-technical person looking and doing some basic checks that anyone can do.

What are the scores in Accessibility Checker? I have on the screen here an example of a report that’s got 39.53% pass test, 230 unique errors, 947 color contrast, 388 warnings. You can see, there’s a lot of issues with color contrast, some empty paragraphs tags, ARIA hidden, broken skip or anchor links, those sorts of things listed out here in this screenshot. Looking at that score from the automated scan of the whole site, because it’s really helpful to have a picture of what the whole site is like, which is why the bulk scanning is really helpful.

Then doing just some basic manual checks like, can I tab to things, and is there a focus outline on the homepage? Does the navigation menu open with a keyboard? That’s something that you don’t have to be an expert to be able to test. You may not know how to fix it, but you can certainly identify that it’s not possible to use the navigation with a keyboard even without being a developer.

Doing those assessments and looking at it and trying to figure out where are some of these problems coming from? Having a lot of issues isn’t necessarily an argument for a full rebuild, and the reason for that is that, sometimes, when you have a lot of unique issues, it’s because the content has a lot of unique issues. Rebuilding might not necessarily resolve that because you might just import in all those blog posts that have accessibility problems from the past 10 years. It’s not necessarily a quantity, it’s more of trying to figure out where do we think they’re coming from? Are they global issues or issues in templates versus issues in post content? That sort of thing.

Sometimes we’ll then hand off to Steve and say, “Hey, can you do an assessment on some of these problems and figure out, are they fixable?” I’m going to hand off to Steve right now and he’s going to tell us what he would do when we go to him and we ask that question.

>> STEVE JONES: I do have the benefit of some of the initial audit information that comes through and the information from the sales assessment. Sometimes, before I get to a full dev assessment, there may be an at-a-glance where I’ll just pull it up and give it a quick little audit myself, but then you want to go into a full dev assessment. This is where you have access to the code base, you have access to the WordPress install and you want to go through it with a fine-tooth comb. Here’s a few things that you want to be mindful of and looking for.

The theme, is it a custom or a commercial theme? There’s pluses and minuses to both and you want to check both for, are they modern, or are they a legacy code base? Is it an old theme that is no longer maintained? Is it a custom theme that is coded with custom fields rather than a more modular block approach? Those are some things you want to look at in regards to the theme.

The plugins, are they accessible? We’ve done enough remediations and we’ve remediated enough plugins at this point that we have a list of plugins that we know are fairly accessible out of the box and we know which ones are fairly inaccessible out of the box. You want to assess what plugins those are and if they’re maintained and if they’re filterable. The reason why a maintained plugin is so much better than one that’s not is because we’ve created a lot of relationships with plugin devs and we want to be able to go back to that plugin dev and request an accessibility fix to the plugin. If they’re receptive to that and they can turn that around quickly, that helps us immensely. It’s also not just a benefit to the current remediation we’re doing, but it’s a benefit to ongoing remediations that we do later on and the whole WordPress community as a whole.

Finally, are the plugins filterable? Some plugins are built from a standpoint of being extended. Are there proper actions and filters that we can hook into and make any remediation change that we need? Conversely, there are plugins that are pretty closed and hard to modify and you have to do an overlay fix or something and that’s not as preferred. The code, is it clean, modular, and easily to maintain?

We’re actually pulled down the code and we’ll go through it, we’ll look at it. Does it have a build process? Was the client able to provide any of that information to us, how it’s set up? Does it have a read-me that explains how to build the assets on this? A lot of times you can run into situations where a build process has not been followed. There are build scripts inside of this theme, but somebody has modified a built files such as a compiled CSS file has been directly modified. If we were to move forward with this remediation, we would have to reconcile that. That could be a lot of code for us to take on.

You want to really go through that theme with a fine-tooth comb and ensure that you’re able to make the changes that you need to make and that you’re able to compile the files without breaking their website or overriding issues that were generated from a poor dev workflow by a previous developer.

Then performance. Does the theme have a heavy use of animations or complex JavaScript components? On the animation side, the reason why this is important is it could be a lot of work for us to remediate if those animations don’t respect [unintelligible 00:19:04] reduce motion. That just adds to the complexity of our remediation.

Complex JavaScript components. This could be like a tab panel or even a kind of a whole little JavaScript-like application inside of a website or something as simple as a carousel. Those things a lot of times are very, very hard to remediate, especially when you need to announce changes, state changes in dynamic components like that. It’s not that it can’t be done, but it’s something that when you’re doing your dev assessment that you need to be mindful of and you need to take note of because it will extend the remediation timetable out.

The editor. Is it the block editor? Is it the classic editor? We’re to the point now where the block editor is old enough that we have legacy block editor themes. Whereas block themes were created initially with– you would generate your own CSS to handle the block CSS output, but now we have the theme.json file. You will see a hybrid of the two as well.

Say it’s an older block theme that uses styles from the theme and not the theme.json file in– a new block comes out. I think Amber stated that there was a website she was working on where she wanted to use the group block. Well, the group block doesn’t have any styles with it because it doesn’t utilize the theme.json. It wasn’t fully supported.

You want to be really mindful of things like that. I think maybe I’d even go a step further to say that depending on the level of compliance that the organization needs, you may even need to consider the WordPress core backend and not just the core backend, but the backends that the plugins create as well, because in some situations, the backend of WordPress needs to be accessible as well.

Page builders. This is where things can get really interesting because not all page builders are created alike. There are some that are much more accessible forward and there are some that are very inaccessible forward. You need to be very mindful of if this website is using Elementor or Divi. Those are page builders. I’m not saying that one is better than the other. I’m just saying you need to be mindful that if a page builder is being used, that you may have more complexity in being able to get to the markup that you need to edit to make things accessible.

I’ll tag onto that too. Probably more of a thing to be aware of than even that it’s a page builder is that it doesn’t use a lot of page builder add-ons. Say Elementor add-ons, a lot of those add-ons aren’t created by Elementor and don’t go through the same level of workflow and accessibility assessment when they’re being created. We’ve found that the add-ons, a lot of times, are much more inaccessible than the page builders themselves, so you have to be aware of that.

>> AMBER: Can I chime in for a second, Steve?

>> STEVE: Yes, absolutely.

>> AMBER: I had a thought as you were talking about both page builders and then calling back on the animations. One of the things that comes up with this is that sometimes in a page builder scenario, those things aren’t coded in in one global space. I remember once we had a website that was built with Elementor and all these elements were flying in in a very non-accessible way. It was just the amount of time to go in and remove that animation because you had to do it on every layer, which was almost every section on every page, or sometimes it was the header and the paragraph and the button, five times in one section. That’s something interesting to consider too with page builders.

>> STEVE: Yes, totally. I’ll tag onto that too, a lot of times with page builders you could find your CSS in a lot of different places. For developers and content creators, if I’m trying to remediate a page builder, a lot of times I’m searching, “Where is this style?” I’ve already inspected it. I see that it’s there on the page, but where is it? Is it on the component? I think Elementor calls them widgets. Is it on the widget? Is it in the customizer? Is it in the theme? Is it in a plugin? You can definitely go on a hunt for things like that when using these types of page builders.

>> AMBER: Which adds to remediation time.

>> STEVE: Exactly. I think that’s what this overarching is about. A lot of it’s about assessing how much time this is going to take us and really, is this worth remediating? To jump back in, hosting, you got to consider the hosting. Are there any limitations with staging or their continuous deployments or the Git-based deploys? Is it a Pantheon multi-dev environment? That’s going to be much harder or much more– not harder, but much more rigid of a development workflow than if it’s something you just have FTP access to that you can push up to and things like that.

You have to consider those things. Is there a deployment? Is there any kind of approval process? Is there a pull request approval process that the client currently has that you have to fit into?

With that, workflows, are there strict approval or development processes? This really turns out to be the biggest roadblock that we run into a lot with remediations, even over all the technical things that I just went through, is that if you’re remediating a website, a lot of times you’re finding a way how your dev team is going to fit into the current workflow the client has.

Typically, they have a workflow, and I’m not saying that the workflow is always very good, and they don’t always follow modern practices. You can do what you can from a technical standpoint to help steer them towards a more modern workflow, but a lot of times, you have to work within their framework. Unlike if you’re building a new website, you’re building it from scratch, you’re doing it in your workflows and you have full control.

Then there’s approval processes. When we make a change, it needs to be reviewed, it needs to be approved, and then it can be deployed. That process can get very lengthy depending on how much time that client has to review those things, because a lot of times when they go into a remediation, remediating websites is not part of their job. This is a bolt-on to their job because they need to meet compliance or they’ve decided internally that they want to be compliant. Sometimes this is a bolt-on to their current job responsibilities and it can seem overwhelming. You have to work with them very closely to try to integrate with them and not disrupt their jobs too much.

I think with that, I’m handing it back to you, Amber, right?

>> AMBER: Yes. You know what I might say? We didn’t make a slide for this, but I feel like listening to what you’re saying, there almost should have been a slide that’s client or team assessment. [laughs]

>> STEVE: I think we can have a whole talk on that.

>> AMBER: This could apply not just for, “I’m an agency doing it for clients.” This could also apply to, “I’m an in-house developer and I’m working on my company website and I have to assess this.” It’s interesting, you talk about, what is this approval process? We’ve had someone recently be like, “I need at least seven days turnaround on anything.” That slows down remediation, but at the same time, it’s not necessarily an argument for a rebuild because those people also might not have time to test an entire new website. Sometimes that’s an argument for remediation because it’s like, “Here’s a small thing you can look at.”

>> STEVE: I’ll tag onto this, the workflow part that we’ve found very helpful for us, is that I actually will now put together a full workflow document that they can review and approve like, “This is the full dev workflow on how we’re going to remediate, how we’re going to approve and how we’re going to launch these changes.” I feel like that’s helpful for us and that’s helpful for the client to all be on the same page.

>> AMBER: This leads us to when does remediation make sense versus a full rebuild? Where we’ve landed is, there’s a few different reasons. If it’s minor to moderate issues, then it’s definitely always cheaper to remediate if it’s mostly small problems that are not super complex to fix.

The thing about color contrast that’s interesting is it can seem major because sometimes you have to recolor literally everything, but actually that’s a really small change because CSS fixes, versus, the entire header menu, every accordion, every tab component and everything that’s interactive doesn’t function with the keyboard. Okay, that’s a lot more complex. Really looking at the complexity of the issues, how hard they would be to fix.

Remediation also makes sense when the site is otherwise modern, maintainable and achieving organizational goals. If they don’t think anything needs to be redesigned anyway, then it makes more sense to remediate. You’ll have people that will come to you and say, “I really hate our website,” or, “Can we do this at the same time?” Then they’re like, “I want to redesign this entire page.” You’re thinking, “Maybe this is when it wouldn’t make sense to remediate.”

Really, when we’re talking remediation, typically the design doesn’t change much unless it’s an accessibility mandated design change, but otherwise, it’s really just changing the underlying structure. If that site is otherwise meeting goals, then you would probably just keep the design and you would just fix the underlying structure.

Budget constraints or challenges with getting approval for a complete rebuild. We have definitely had clients where I thought their website should have been rebuilt. One that we had last year that we worked on, and they were fabulous, I loved them, they were a state-funded entity. Their website, I don’t even know, Steve, do you have any guess on how old this website was that was all built with hard-coded stuff in?

>> STEVE: At least 10 years.

>> AMBER: I would guess at least 10 years old, just based upon how the code looked. At the time, this website was built with what was a very modern approach to building WordPress websites, which was using advanced custom fields, flexible content areas because it was built before the– It had to have been built before 2018 because that’s when the block editor was released, or right around that time and dev still didn’t trust it.

It was built before that, and it was really challenging to edit and frustrating. The whole entire footer was not even built with widget areas. That’s how old this was. You’re right. It was more than 2018. It was probably way older.

>> STEVE: ’15.

>> AMBER: It was just hard-coded in the theme. That takes what is sometimes a content specialist job like, change the phone number or change the links to have more meaning, a remediation kind of thing that normally we’d have a content specialist, not a developer do, and now suddenly a developer has to do it, which if you’re paying different roles, different things, or that kind of thing, that might not work for your organization.

I thought it should have been rebuilt, but the reality of their budget was they could get approval to remediate accessibility. They could not get approval to build a whole new website. That’s why they had a website that was so old, and that was even frustrating for them at times. They had a marketing person who came in, and she’s like, “I just worked on a Squarespace website recently and it was so easy.” [laughs] I had to say to her, I was like, “Please don’t let this experience reflect on WordPress because this is not modern WordPress.”

That is the thing. Sometimes you have to go with where the money is and where the money can be allocated from, particularly with government or nonprofit websites. There may be restrictions. When they get in trouble with the feds or with their state or any other legal complaint, it is typically very easy for them to get budget for remediation, but it can be very difficult to get budget for a rebuild.

The other case when remediation makes sense is short-term– if they have short-term compliance goals. We really want to be as compliant as possible, as quickly, we need really rapid improvement of our website. Our entire navigation menu doesn’t work and if I can get that to work tomorrow, it needs to work tomorrow, those kinds of things. That is when remediation makes sense. I mentioned a lawsuit or a government fine-mandated remediation because with remediation, you are typically going to start getting fixes much sooner than you would ever have an entirely new website designed and built in.

What does this journey look like if you decide to remediate an existing site? At a high level, three different things have to happen. First, there needs to be some sort of accessibility audit and logging of issues. The development and the content team has to go in and fix those issues, and then you have to re-audit to confirm that everything was fixed.

Now, of course, this might happen multiple times. Things might loop back like, “Oh, hey, this isn’t quite perfect. Can you go back?” Then they work on it some more and then you retest it again. Those are high-level “what happens.”

The traditional approach to this- and if you go to some of the really large accessibility companies who have been in our space that don’t work in WordPress, the traditional approach to this is that they do the audit first, and it’s a large audit covering whatever scope or number of pages that they have in scope over many weeks or potentially months. They log all of the issues and then they deliver a single large report.

It’s a very waterfall approach where the auditing team does all their work, then they stop, then the content development, the people who actually can edit the website do all of their work, and then they are done, and then they say, “Hey, we’re done now.” Then they get another audit.

Now, sometimes though, we did some work and we get a retest, we did some work and we get a retest, does get batched out in that way, but the initial audit is always a big chunk of time in front. What we’ve been doing and what we think works really well is we do what we call rapid remediation. It’s like an audit and fix as you go. Instead of auditing 10 pages first, let’s audit the header. Let’s fix everything in the header. Let’s audit the whole homepage. Let’s fix everything in the homepage. Those sorts of things, or let’s look at what’s global and fix those problems so that you can get more fixes, like I was saying, much faster.

Now, it’s not usually like, “My whole navigation menu is broken, we fix it tomorrow,” [chuckles] because there’s some dev overhead on that. That said, there are two different approaches. I would say when you’re looking at your website or a client’s website and trying to decide, I would encourage you to not say, “the whole thing has to be audited first,” and to do this, “Let’s audit, fix, audit, fix,” just because you will get better results, and that’s more of the spirit of a remediation, I think, and a continuous integration, continuous process.

Of course, there are pros and cons to remediation. Even if you think hearing that list that it’s the right fit, it may not be. What are some other things they should consider, Steve?

>> STEVE: It’s not always a magic bullet decision to go one way or the other to remediate or rebuild. They both have their benefits and their downsides. These are the benefits and downsides to remediating. You get faster fixes. Like Amber just stated, you do it more in a cycle approach. You take a batch, you make the changes, you get them approved, you deploy those in an incrementally fashion, that way you’re showing movement and value real quick and compliance right away. Especially if you’ve been under any legal threat, it definitely moves a lot faster when you’re able to do this iterative approach.

A lower upfront cost. Obviously, if you’re just paying a monthly fee for a remediation and it’s much more easy to get approved, like Amber said, than a large full build that’s going to– A lot of times these are government or higher education organizations that would require to go out for RFP and then having a lengthy approval process there. A lot of times it’s just easier to get that lower monthly cost approved and signed off on.

Then there’s minimal disruption. We stated that a lot of times when we do a remediation, we’re not going to really modify the overarching structure of the website. We’re going to go in and we’re going to try to surgically fix the inaccessible portions of the website.

The downsides. Technical debt. This is always something that I’m very mindful of as a technical person is that the site may need a future rebuild anyway. In the case of the website that we remediated that was built with the old ACF fields, that was definitely where we were like, “This needs to be rebuilt.” Then we’re like, “Well, based on how the budgeting works out on this, we’re going to have to push forward with the remediation even though there is a lot of technical debt here.”

When we got in, we did try to clean some things up. There were some modules, I think a filterable table or something like that, where we actually did completely pluck that out and we built our own solution for that. It was built with some dynamic content. It required some ARIA live work for announcements and things like that. You want to be mindful that you’re not contributing to that technical debt. That could be a downside that through the remediation that you add to the technical debt, it’s not always best, but sometimes it’s a necessary evil that you have to do to be able to remediate.

What that is, is the patchwork code, inconsistent solutions across the website. Maybe something’s fixed in one way on this page or in this module, but then we’re not aware of that or we haven’t fully assessed every single module and every block and every page, and we create our own solution over here that’s a little different instead of where you would approach it from a global approach.

If this is a problem in many places on the website, let’s put one piece of– Developers don’t like to repeat themselves, and sometimes you could end up doing that when you have to do a remediation or you have to– A plugin is not maintained or it’s not extendable or the developer is not receptive to quick turnarounds on accessibility fixes to the plugin. Those have to be resolved sometimes with a JavaScript solution that’s overlaid on top of the problem, and it fixes it with JavaScript.

While that’s okay, the problem can come up is, what if that plugin developer actually does fix that problem at some point in time, and then our solution that we’ve laid on top of the plugin actually conflicts with what they’ve fixed? It can be a future problem. You want to be very mindful of that as a developer when you’re making these implementations, that those future collisions don’t happen, but there is definitely the potential for that when you push forward with a remediation.

Then any hidden complexities, so fixes that break other things on the websites. We see this all the time with development, especially when we’re dealing with page builders that have per-page or per-widget solutions and we make a change to, say, just something as simple as a text decoration change in the footer and then we, unintendedly, modified something in another page. That’s always a potential and always a thing to really be mindful of and look out for.

When to rebuild. Obviously, if a redesign is already planned and this, a lot of times, is what we talked about in the sales assessment and this, a lot of times, will be brought to the surface during that. If they’re planning to do a rebuild in the near future, it’s probably best to hold off on accessibility remediation until that happens and make accessibility a fundamental part of that rebuild. Sometimes, they’re under a legal review to be compliant and they can’t even wait that short period of time.

Themes and plugins are outdated and unsupported and I think we’ve touched on this quite a bit. If you’re not able to work within the plugins, you can’t find a replacement, you can’t get a developer to remediate the plugin itself, we can’t overlay something on top of it. There definitely are situations where the theme and the plugins are just so bad or poor that it’s best to rebuild.

Of course, again, the themes and plugins lack the filters and overrides, that goes with what I just said. The page builder produces inaccessible or rigid markup. Not all page builders are created the same, which I stated earlier, but some of them actually let you get into changing the element. I can change a div to a nav. I can add attributes. I can add ARIA attributes to certain things. Other page builders are very rigid and they won’t even give me the ability to add attributes which really limits our ability to remediate, so that’s definitely a case where it’s time to think about a rebuild.

The custom theme has poor unmaintained code structure, hard-coded templates. I want to touch on the hard-coded templates just a little bit. In WordPress, you can create a template and you can hard-code the whole thing. It doesn’t work in the block editor, there’s no custom fields, it’s just straight up hard-coded PHP, HTML, CSS. That becomes very problematic because it’s just– A lot of times you’ll notice that’s just one templates that way.

We recently came across a remediation project where it was a block theme, but there was an HTML block added to the theme and in the HTML block was a full hard-coded page, a full hard-coded page template.

>> AMBER: Starting with the style tag.

>> STEVE: Style tag, JavaScript tag, all the markup inside of the HTML block. Of course, we have to just delete that and rebuild it in the block editor. If your whole theme is that way, then that’s definitely time to really start thinking about a rebuild. I’ll touch on this again, the editing content is difficult for the theme. This is something that gets surfaced in the sales assessment as well.

The reason why this one’s probably at the top of the list of when it’s time to rebuild is because, if the theme’s not built in a way that the content editors can build pages that are accessible, then you’re fighting an uphill battle here. If with every page that’s created or post that’s written and every block that’s used inside those, creates inaccessible markup and an inaccessible page, you’ve got a inaccessibility generating tool. That is definitely when it’s time to really think about rebuild. You rebuild it, and then all the tools that the content creators use create accessible code.

>> AMBER: I really like if we can, when we remediate, help make it easier, but sometimes it just doesn’t make sense or budgetarily, you can’t do all of that, and then it ought to be rebuilt because people should– I don’t know. I come from the standpoint of a website owner should be able to edit their own website if they want to. Maybe they don’t want to, but if they want to, they should be able to and it shouldn’t feel painful to them.

>> STEVE: The pros and cons of rebuilding. Just like with remediating, there’s pros and cons to rebuilding as well. The benefits here, and this is a huge one, accessibility first. The design and code are built to meet WCAG guidelines from the start. This is the whole shift-left thing we always talk about. Start thinking about accessibility when you’re designing all the way at the very beginning. If that’s implemented from the start all the way through the process, you’re going to end up with a very accessible product.

Sustainable practices. It’s easier to update, scale and avoid repeating old mistakes. This is what I just talked about. If your blocks create inaccessible code, your content creators are going to be creating inaccessible code. With a rebuild, you can build all those blocks and all those custom fields to be accessible out of the gate and you have the assurance that you’re handing off to your client something that they can produce content that is accessible in.

Team alignment. A clear, modern structure makes training and ongoing QA easier. When we used to rebuild websites, we would always end the project with client training. We could go through and we can train them on the best practices on how to build their posts or pages to maintain accessibility moving forward. If we’ve done the things by shifting left and building accessible blocks and widgets and things like that, then they will be able to use those and maintain accessibility.

Then the ongoing QA. A lot of times when we do remediation, we do the remediation and the clients go into a period of QA where we’re just looking at the website over time to see what they’re creating. Is it maintaining accessibility and things like that? That’s definitely a lot easier to maintain with a brand new website that is built with accessibility in mind. What are the downsides of rebuilding a website?

Longer development timeline, of course. If you’re going to rebuild a website, you got to plan for it, you got to do discovery, you got to design, you got a whole development build phase. A lot of times, you don’t rebuild without thinking about the content. There’s a whole content entry or a content cleanup phase as well. Your timeline is going to be stretched out. If you’re under a deadline to be compliant, this can definitely be a hard thing to navigate.

Larger teams may be needed. If you’re doing a rebuild, of course you need project managers, designers, content leads, developers. There’s a lot of collaboration that it takes to bring a large website or even a medium website to the market, and a higher initial cost, especially true for large complex websites. A lot of the higher education, a lot of government websites are very large content-heavy websites.

It’s definitely going to be a very high initial cost. It’s going to be a bulk cost upfront rather than a lower cost spread throughout several months or even years. Those are the pros and cons of rebuilding. Amber?

>> AMBER: One of the things that Steve touched on a little bit when he was talking about maybe you have to replace a plugin or something, is that it’s not always just remediating and doing a little bit of code tweaks or rebuilding. Sometimes it’s more of a mix-and-match approach. I have a screenshot up here of the Highland Community College website, which is one that we have been remediating for a long time and we continue to do work on it every month for them.

This is one of those where there’s a lot of post types and a lot of things that they couldn’t get a budget for a full redesign. Structurally, there’s not a lot of redesigning happening. I’ll tell you, I don’t love the way their header looks visually. You all might also not like the way their header looks visually, but it was like, “All right, let’s fix the functionality of the code that’s behind it,” that kind of stuff.

On the other hand, we’re working within the existing theme, but there were some components or some page templates that were completely rebuilt from scratch during the remediation process like the way that people can sort and filter their classes that are available for each semester or their events calendar. They had a hard-coded custom event management tool that it was very not accessible and it was custom, and so it was like, “You know what, let’s just rip this out and let’s replace this with the events calendar with some modifications that we made for accessibility.”

It’s so much better than having a custom event management platform that doesn’t get any updates and has a bunch of code– We could have remediated, but it made more sense to replace in that instance. Really, you might not be making an all-or-nothing decision here. You might decide to remediate within the existing theme, but also replace certain plugins, components, or page templates completely.

One tool that I came across recently that’s neat, I’ll give it a nod, we haven’t used it yet, but I’ve been milling over, and so I thought I’d share this, interesting, is Theme Switcher Pro, which is a new tool. What it does is, it allows you to have two active themes on the website and then you could assign– Oh, look, I’m getting balloons. [laughter]

>> STEVE: Balloons, celebrating Theme Switcher Pro. [laughs]

>> AMBER: Apparently, I don’t know. Zoom. Oh, fun Zoom. I feel like I should get an affiliate something for that now. [laughs] Anyway, it allows you to have two active themes. You could have the main theme that exists, but you can switch page by page to a new theme. I was talking to Brad from WebDevStudios and they said that they put this out there because they had clients come to them that couldn’t really budget for a full rebuild but, like we’re doing with remediation, could budget for a rebuild over time. This is what allowed them to do that. It’s a neat concept, and I’ve been thinking this really has interesting applications for accessibility remediation.

Not that I’m trying to sell you on a plugin, but I think there’s a lot of interesting tools out there that allow you to mix and match your approach and figure out what works best for the specific website or organization.

For fun, and I think we can throw a link to this in the chat, and we’re pretty much at question time, but I did, earlier today, publish a post on our website that has a quiz that I made, which is fun, to ask questions like, “How old is the site?” “Does the current design still reflect the organization’s brand?” All of these things that we’ve talked about. If you want to, I would say go here. You can ask it to email results to you, but you don’t have to do that, so it’s not like we’d know who you are.

It’s a fun tool to just play around with. It might get you thinking about the questions and things like that, if you’re working on your organization or for your clients, how you might be able to measure that, so it’s fun.

I would say we’re pretty much at question time. I’ll throw up here before we take questions. We’re both on X. I’m HeyAmberHinds, Steve is SteveJonesDev. We’re both on LinkedIn and in our Facebook group too, if you think of something after this meetup, but of course, we’re happy to take questions now. I would love to hear from anyone who has played around with that quiz on– what they found, [chuckles] and if they agree with the results, you can tell me that because maybe I need to change my waiting on answers.

>> PAOLA: That was a great talk, Amber and Steve. We’re going to go into the Q&A. I did see one question come in. If anyone else has a few more questions, just pop them in the Q&A box. To start us off, the potential client’s website is made with Joomla. Is there an audit check for this? I’m guessing this is asking for any automatic tool to check for accessibility.

>> AMBER: I don’t know about Joomla, I know Drupal tools. Do you even know of an automated checker for Joomla, Steve?

>> STEVE: I don’t know any that integrate into it, but you could use Wave to do a per-page basis analysis of accessibility. I said Wave, there’s a browser add-on called Wave that will help you evaluate that, but that’s on a single-page basis. You’re not going to get a full site report.

>> AMBER: There’s a couple of SaaS solutions. One of the most commonly known is Siteimprove, which works on any site. I will tell you it’s pricey, [chuckles] starting at $50,000 a year kind of pricey. That may or may not be a fit for your website or your client, but that will do anything. I’m sure it would do Joomla. The Drupal tool that I’m aware of is Editoria11y, which is a tool created by Princeton University and it integrates in– Let me see if I can find it. It’s always a race because Paola is really good at finding links.

>> STEVE: [chuckles] You get double links.

>> AMBER: I know, but I’m like, “Who’s going to find it faster?” Look, she found it faster. She always finds links faster than I do.

>> STEVE: One point for Paola.

>> PAOLA: You were speaking and I was typing.

>> AMBER: That’s the one I’m aware of that integrates into Drupal. I will say, we’re WordPress folks. We’ve been WordPress for a long time, but Drupal, especially with this most recent Drupal 8 version, has been doing a lot just for accessibility. It’s interesting. If you’ve ever thought about exploring other CMSs, it’s worth exploring. The biggest thing to be aware of with Drupal is Drupal doesn’t always do backwards compatibility.

When you build a website in it, you are setting yourself up for a known end of life. That’s how we’ve gotten some WordPress website builds in the past because they’re like, “Our Drupal site hit end of life and is no longer being supported, and so we were being forced to rebuild our website.” You have to decide if that’s something you’re okay with.

>> STEVE: We’ve even had some discussions about our Accessibility Checker WordPress plugin, about porting it to different platforms. I will tease that we have been exploring some options on how to bring accessibility checker to more than just WordPress people, so keep an eye out.

>> AMBER: It is in works, it’s just not today.

>> STEVE: Not today. [chuckles]

>> PAOLA: That’s great. Another question. This is specifically, I guess, for Equalize Digital. When taking clients, do you search for WordPress-only remediation and turn away others?

>> AMBER: It’s interesting because our remediation plans are WordPress only. If somebody needs remediation outside of WordPress, then we won’t work with them. Now, our auditing, we audit everything. We’ve audited lots of websites built with lots of different tools or frameworks, even if they’re not in a CMS, and web applications and mobile applications, and all kinds of stuff. If somebody has something else, if it’s a more complex application, they usually have a developer. If it is not, and then they only want auditing.

If it is something like Shopify, then we will typically refer them to someone we know who works with Shopify, or we’ll say, “We can audit it, and then if you don’t have a Shopify developer already, we’ll help you find one who can work with our reports and know what to do.” That’s the way we’ve been approaching that. Just for us, it’s easier for us to stick to WordPress. That does mean that if you are a Shopify or a Squarespace person, we’re not your competition.

[laughter]

>> STEVE: Yes, totally. WordPress runs the gamut. There’s a lot in WordPress to support, as we just talked about with all the page builders and plugins, and stuff. It’s good to be specialized in that area.

>> AMBER: One thing I’ll say too, I hesitate to recommend ever that if someone comes to you and they have a website built in a different CMS and it has a lot of accessibility, that you force them to do whatever platform you do. Now, it might be right. It might be right that they have– like I was talking about, the one that they were in Drupal, and it was end of life, or even maybe they’re in Drupal that’s still a supported version. You’re like, you have a lot of problems, it needs to be rebuilt. Here’s my case for why WordPress is better.

There are cases where it makes sense to move them into what you do, but there are also cases that I’ve seen– we had a client once, and this was a long time ago, but they came to us for support. They had a WooCommerce website. They had originally been a Shopify store. They got recommended to a developer, they liked the developer. The developer is like, “All we do is WordPress, so we’re going to build you a WooCommerce store. It’ll be great, you’ll love it.” They talked them into it, and then they weren’t very good at providing support.

They ended up finding us for support, and they had us on a, I don’t know, 10-hour-a-month dev maintenance contract because their store needed that much support for years. Maybe two or three years in, they said, “It is not you, but we are going to go back to Shopify.” I was like, “Yes, we saw it. We saw the writing on the wall.” It can be the right choice to get someone to move CMSs into the one that you do, but it can also not be the right choice. It might be better to remediate in their current CMS instead of trying to fit them into something else. I would just be really careful about that when you’re assessing that kind of stuff.

>> PAOLA: That makes a lot of sense. Going on to our next question. I’m in the process to rebuild a site and try to figure out a price quote. Any recommendations on how to do it? I know it is complex.

>> AMBER: Steve.

>> STEVE: Go high.

[laughter]

>> STEVE: Figure out a price and double it. [laughs] This is a huge question. I think you alluded to it when you’re saying it’s complex. Pricing a website is super hard. A lot of times we would figure out a price and double it because we knew it always ends up taking twice as long as we always think it takes. A lot of times, you’re at the whim of how the client works as well. Like, what’s that relationship with the client going to be like? Is it going to be smooth? Is it going to be difficult?

A lot of times, we found that the lower budget projects, a lot of times, the clients are a little more hard to work with because a lot of times the money’s coming out of their pocket. With the higher-end projects, a lot of times, the money is coming from an organization, so it’s a little easier to move forward. I don’t have a rubric here. Our COO, Chris Hinds, might have some good tips, but I don’t have great answers for you on how to price it. We’d have to go through it line by line and see what’s required and what’s needed, how you’re building it, like what’s your overhead, all kinds of things. How many developers do you have on your team? Is it just you? It’s a big question.

>> AMBER: Chris definitely, I know he built– really magical at spreadsheets. He built this spreadsheet that he could plug in things like how many custom post types, how many custom designs, all this stuff. It would output a price that is based on our hourly rate and how much time he thought things took. Paola did share a link in the chat to some information about pricing accessibility, but I would say, reach out to him because he might have general thoughts on just pricing rebuilds in general.

If you’ve never done accessibility and this is the first website that you are going to promise accessibility on, I would assume that some things might take you twice as long because there may be some plugins in your tool set that you’re going to realize you cannot use. Then you either have to spend time finding a different plugin, or you have to build something custom instead of using an off-the-box or off-the-shelf solution.

>> STEVE: I would caution too a little bit, and I know probably in that link that Paola shared, we’ve had a lot of talk about pricing accessibility and things like that in websites. I would make website a part of the holistic quote. I wouldn’t itemize it out because that just gives the client too much of an option to just, “No, I can’t afford that. Let’s just strike that out.”

>> AMBER: Get rid of the accessibility. You should have an accessibility built into every line item that you already have. Into design, into dev, but don’t tell the client what percent that is.

>> STEVE: When we were doing custom websites, still, for us, we weren’t going to build it if it wasn’t accessible. Our company is built on top of accessibility. It’s our main mission here. We never wanted to give them an option to opt out of the accessibility, so definitely just built it into the whole package.

>> PAOLA: Thank you for that. Going on to the next question, a previous nonprofit employer of mine did a big website remediation with a marketing firm. The remediation was not accessible. They decided to use an accessibility overlay as the main translation tool for clients who speak many languages. Is there a better WordPress translation plugin for this?

>> AMBER: I didn’t even know that accessibility overlays could do translation, so that’s interesting.

>> STEVE: I didn’t either.

>> PAOLA: I just found out, too.

>> AMBER: I would say definitely use a specific translation plugin. I think the one that we have found that works the best is G Translate, is that what it’s called?

>> STEVE: Yes.

>> AMBER: Only in a very specific setup, which is the dropdown setup. If you use the one where it opens in a modal, none of the modal or any of the stuff that’s in there is accessible. You need like the plainest version of it possible, where it’s a dropdown that is in there. That one is the one that works the best from an accessibility standpoint.

>> STEVE: I’m curious about the remediation was not accessible. I’m curious if the translation was only part of the overlay. Was the overlay handling other accessibility issues? I think there’s an overarching answer here. The answer is if anybody says they’re going to remediate your website and they are going to implement an overlay, you’re immediately going to be in trouble.

>> AMBER: I would say if you work in-house somewhere and you’re trying to determine the vendor to go with to help you with remediating your website, I would ask them what their approach is, and if they recommend using an overlay, I would not select that vendor. I think, what was it? A third of the lawsuits last year were against websites that already had that. One of our remediations last year was against someone that was using UserWay or was to remediate a website that was using UserWay, and they had already been sued twice while having UserWay on their website.

That’s the thing. You don’t necessarily just get sued one time by one person.

[laughter]

>> AMBER: They had been sued twice, and the second time, they were like, “Okay, now we need to actually fix this because clearly this overlay is doing nothing for us.”

>> PAOLA: That makes a lot of sense. We have another question coming up. What about the legal responsibility for the web agency?

>> AMBER: I’m going to say right now, neither Steve nor I are attorneys. [chuckles] We cannot give you legal advice. However, we have two really great things that you can go listen to if you want– look, I got balloons again.

>> STEVE: More balloons.

>> AMBER: It’s in numbers. I don’t know.

[laughter]

>> AMBER: I don’t know what my Mac is doing. On our podcast, very recently on accessibility crafts, maybe Paola can find the link for these because she’s good at that. Richard Hunt, who is an attorney who specializes in ADA and he defends businesses that got an ADA lawsuit, so he’s coming from that side of thing. He was on the podcast. He also spoke at Meetup, was it last month, Paola? Or the month before, maybe?

>> PAOLA: The month before, I think it was February.

>> AMBER: The podcast episode is very much of a walkthrough what happens when you get sued and what do you do. The Meetup talk is more about what the legal implications are. What I can more broadly say as far as the United States right now is there’s not anything that specifically says in my understanding that a web agency is responsible. Ultimately, it’s the website owner. That said, if you don’t follow through on your contract or if you overpromise something and then you don’t deliver on it, there was a case in California that was a $2 million settlement because the agency said they’d deliver something that was accessible and it wasn’t and they got in trouble for fraud.

It wasn’t an ADA case, it was a fraud case.

>> STEVE: There was an RFP involved in all that, and they had made–

>> AMBER: It was a government website.

>> STEVE: They had made a hard promise that it was accessible. They promised. You got to be careful in your language of your contract on how you speak about accessibility. Not a lawyer again, I’m going to say, but listen to those resources that Paola put links to. You got to make sure you’re covered. I think in the United States, like Amber said, the agency a lot of times is not going to have a lot of recourse unless you’re making big claims. I think there’s an overarching thing here, too is if you’re selling accessibility, be a decent human being and make it accessible. Then you don’t have to worry about it.

If you’re implementing a website for somebody, even if you acknowledge the components inside of that website in the client’s accessibility statement that aren’t fully accessible, then you’re going a long way to cover your tracks.

>> AMBER: One thing that Richard did say in that podcast episode was he said that there’s this concept which has been around for a long time in the law, which is that professionals are supposed to do things in a workman-like manner, which basically– and I put quotes around that because that’s the term legally, which basically means you’re supposed to deliver your work to what would be considered a good standard for whatever work you’re doing. A plumber shouldn’t deliver leaky pipes because that’s not a good standard for a plumber.

He was drawing a connection with websites and accessibility that, increasingly, especially with a lot of the laws around the world requiring this, that it is becoming more of a standard that websites should be accessible. 15 years ago, you could get away with being like, “I’m not going to build you a mobile-responsive website unless you pay extra,” but now, the standard is it will be mobile responsive, and if it’s not, you did not do your job. What he was saying in that episode was that the standard is becoming pretty clear that if it’s not accessible, the developer did not do their job in a workman-like manner.

I don’t think we’re far from there potentially being laws, and there was a talk of one in California, which it didn’t move out of committee, but that would go against the agencies or the developers of websites, and require them, or they would be in trouble. There is also some repercussions too. If you don’t do accessibility, you might lose business.

>> STEVE: Reputation.

>> AMBER: We had people a couple of years ago that when Chris was doing sales conversations, he would bring up accessibility, and then they would end up working with us. They would say, “One of the deciding factors was that you were the only person who told us about this requirement. No one else even mentioned it.” It was a differentiator.

>> PAOLA: Even then, sometimes with the agencies, it comes down to the tools they use as well. It comes down to, for example, the overlays, they do make those claims that everything is going to be accessible. However, the tools that are more predominant in the sphere of accessibility, they do say you have these past tests. They do not say your website is 100% accessible. They do say “This part is accessible. This test has the accessibility test.” It does come down to all of the tools that you use and your language and the way you go about it and explain it to your client as well.

Then, going on to the next question, which is similar about overlays. Speaking of overlays, I’ve come across several public government-supported sites with the little accessibility icon on it that the person clicks to have a panel slide in to adjust viewer’s text side contrast. Is this an overlay?

>> STEVE: Yes, of sorts. Now I will caveat a little bit here that there is two components to the overlay plugin that they use. There is the overlay factor, and that is them using AI or JavaScript to try to fix everything in one fell swoop in a generalized manner on the website, without taking individual consideration for– when I code or my team codes a JavaScript solution to fix a problem on a website, we’re doing it individually for that particular website, for that particular problem. The overlay is taking a generalist approach to fixing it.

Even in our accessibility checker plugin, we have some fixes. You can check a box to fix certain things, but then our accessibility checker re-scans the page to ensure that our fix actually did what it says it’s going to do. There may be scenarios where our fix actually doesn’t implement correctly on this particular solution. That way, we want our plugin to still say, “hey, even though we said we could fix it, we re-scanned it and we actually can’t fix it.”

I think that’s one part of an overlay, Where they’re actually actively trying to fix things. Then there’s another piece, it’s called a widget. It’s like-

>> AMBER: Toolbar.

>> STEVE: -a toolbar that has some tools to make text bigger or to change the color contrast, or things like that. I don’t think that the toolbar inherently makes it inaccessible, or if you see a toolbar that you’re like, “Oh, they’re using an overlay, this is bad.” I think a toolbar could be implemented and the website still be accessible. Now I would say we’re at the point in the web that a toolbar is not necessary anymore. There’s enough built into the browser. There’s enough with CSS and media queries where we can detect if they like dark mode or if they prefer reduced motion, things like that. There’s enough there.

Then with font sizes these days, using ems to scale fonts or rems to scale fonts based on the zoom level of the website. I think there’s enough there. We can achieve it without a toolbar. I think they’re a thing of the past, but I think you could have one and it still be accessible, but it has to be implemented correctly. I would say, just don’t do it. Make sure the website’s made to be accessible out of the box.

>> PAOLA: That’s a great answer. We do have another question. How do you typically find clients as a new player in the industry?

>> STEVE: We’re old players.

>> AMBER: That one’s hard.

>> STEVE: We’re old players in the industry. [laughs]

>> AMBER: What’s our advice for someone who’s new to this that wants to do more accessibility work? Content creation has worked really well for us, which is a combination of we create blog posts or we write blog posts. We have a podcast, we have some of that kind of stuff. SEO has been pretty helpful. Speaking has worked really well for me. I’m not just talking about going to WordPress meetups. You want to go wherever you think your customers are.

If there’s a restaurant association meetup, restaurants frequently get sued for accessibility, in your town, you might contact the organizers and be like, “Hey, can I come give a free presentation about accessibility to the restaurant association meetup?” They might not know, and they might be interested. I would say that general networking. I would definitely reach out to your existing customers. There are ways to go about communicating to them without making your– everyone’s always afraid to do this, and I know I was too, going to them and saying, “When we built your website, accessibility was not in scope, or accessibility was not a big thing.

This is becoming something that cannot be ignored. I know that there are accessibility problems on your website, so let’s talk about what a remediation–” These are prime for remediation plans. Maybe they already have a maintenance plan with you where they pay you some amount every month to update their plugins, and big, small text changes or something on their website. You could add on a couple of hours a month to also do remediation plans over time.

I have a whole meetup that talks about how we do our remediation plans, but you can add these onto your care plans if you have them. I sometimes will use pivot points too. For example, in June, the European Accessibility Act is starting enforcement. If you have any customers that potentially reach into the EU, you should reach out to them now if you haven’t already, and be like, “Hey, this law is coming into enforcement and it’s going to impact you. We need to talk about a plan for making your website accessible.”

I think people are afraid because they think their clients sometimes are going to think, “You built me a crappy website.” Really, what that’s going to do is that’s going to tell them you’re monitoring laws related to their website and you are trying to offer them the best solution. You have their best interest in mind. I would recommend looking at things like that.

>> PAOLA: Thank you for that. We also have a talk in a few weeks about selling accessibility, where we’re going to have a panel. It’s going to be on May 9th at 7:00 PM Central. If anybody’s interested, we’re going to have a few questions talking about how to sell accessibility, and we’re going to have a Q&A portion at the end as well. Coming up to– yes, go ahead, Amber.

>> AMBER: Oh, I was just going to say, and for that one, we intentionally got people in very different ranges. We have someone who runs a very large company with 40 employees. We have a freelancer that has one or two contractors that sometimes helps her. We have a very broad range of people, so it should hopefully apply to everyone’s businesses.

>> PAOLA: That’s great. We have another question coming in. If you’re remediating the site, you can use an overlay until remediation is complete?

>> AMBER: We don’t.

>> STEVE: No, I would not.

>> AMBER: If the overlay is already there and they come to you, there might maybe be an argument for keeping it. I will say, I saw this once on a website where it was built with Divi. If you know, out of the box, the navigation menus don’t function with Divi at all. With the overlay there, you could actually use the keyboard to access the navigation menus. Now they did something really weird, which is that they didn’t open down. They actually opened up and shifted the entire website down, which was hilarious.

If it hadn’t been for one of our clients, I would have literally made a video and put it on YouTube-

[laughter]

>> AMBER: -because I thought it was so funny. I was like, “I don’t know how to redact all the things in it,” so I didn’t. Here’s the thing, it’s not the way we would do it. As web professionals, we all just think, “That’s horrible,” but at the same time, it is definitely better than not being able to access it at all. In a scenario like that, I don’t know if the second that client comes to you, you say, “Turn off the overlay.” You might say, “Keep the overlay until we at least have the navigation menu functioning, and then turn off the overlay.”

You might figure out what that is, but I would never have a client come to you that doesn’t have an overlay and say, “Go buy this for three months while we fix things.” I wouldn’t do that.

>> STEVE: What I might do is maybe go a step further, and if they don’t have an accessibility statement, I’d add one and put in the timetable to replace that overlay, and that it’s actively going to be replaced. Just for the mere fact that, depending on the overlay that you use, your client is co-opting the claim that that overlay makes. If that overlay makes a claim that websites using this are 100% accessible, and we’ve seen the overlay get sued, and we’ve seen the site owner get sued, you just want to be careful about the claims that the overlay is making.

You may be able to cover yourself to some degree by acknowledging in an accessibility statement that you’re using it, and then definitely define the timetable to replacement for that.

>> PAOLA: Thank you for that. I think we’re coming up at time. Amber and Steve, I’ll let you guys look forward so you can have any parting thoughts, and let everyone know where to contact you.

>> AMBER: I would say, I don’t know, because we’ve shifted a little bit from remediate to rebuild, so I don’t know if I have big, parting, magical thoughts. Maybe Steve is better at that. I’ll talk for a minute so he can think of some. I guess maybe the biggest thing I would say is just starting or putting effort in is really important. The accessibility statement, like Steve mentioned, is really helpful. Even if you decide, “Hey, we’re going to rebuild first,” I would still put an accessibility statement on that tells people how to contact for help if they can’t access some of the content, give them an alternate means of doing that so that that’s available right away.

Probably the easiest place to find me is in our Facebook group or on X. I’m heyamberhinds on X.

>> STEVE: I think as far as remediate and rebuild, I think it’s good to consider that. I think it’s good to consider it from the standpoint of the client more than yourself, because sometimes the decision on whether to remediate or rebuild will have a financial component, whether plus or minus to you as well. Just like when we talk about overlays and whether or not we should use those, is that in the due diligence, the good due diligence of the client to use those or not use those. You always want to be thinking about the client when it comes to accessibility and setting them up for success.

Amber even stated, even as far as moving platforms, like if somebody comes to me from Drupal, I want to move into WordPress because I make WordPress. That’s a decision for you. A lot of times you have to put you aside in these situations and think about what’s best for the client. If you put the client first in those evaluations on whether or not to remediate or rebuild, I think you’re setting them up for success. I think in the long run, it will benefit you the most. You can find me. I’m on X, probably most active, stevejonesdev. You can find me at equalizedigital.com. stevejones.blog. That’s about it. I’m on the Facebook group too, but Amber might have to elbow me to go look at it if you tag me in something.

>> AMBER: Oh, I guess other closing thought I would say, please consider on May 15th, doing something to help accessibility in WordPress. It could be contributing to WordPress, the project itself, but it doesn’t have to be. It could just be doing something for your clients or yourself, and go to that GAAD page on our website, equalizedigital.com.gaad, G-A-A-D 2025, and make a pledge. We would love to have a really big impact where everybody does a lot for accessibility in one day.

>> PAOLA: Thank you, everyone. With that, I guess we are done. Thank you for participating. Bye.

>> AMBER: Bye.

>> [01:27:45] [END OF AUDIO]