172: One Page, Many Problems: Accessibility in SPAs, Recess “Mood” Calming Orange Vanilla

By /

This week on Accessibility Craft, we’re taking a behind-the-scenes look at the design and development of the new Issues Explorer in Accessibility Checker Pro. We discuss what it takes to build an accessible single page application (SPA), how React changes the accessibility testing process, and why focus management, live announcements, and state changes are critical to creating a great experience for keyboard and screen reader users.

We also share what we learned while updating Accessibility Checker’s Accessibility Conformance Report (ACR), how AI fit into the design and development process without replacing human expertise, and why accessibility remains a release blocker for our team.

Along the way, we review Recess Mood Calming Orange Vanilla Soda, a sparkling beverage with magnesium and adaptogens that earned unanimous approval from the panel.

Episode Outline

  • Tasting Recess Mood Calming Orange Vanilla Soda
  • Why we updated Accessibility Checker’s Accessibility Conformance Report (ACR)
  • Publishing separate ACRs for the Free plugin, Pro plugin, and add-ons
  • Accessibility improvements uncovered during product testing
  • Contributing accessibility fixes back to WordPress Core
  • A behind-the-scenes look at the new Issues Explorer in Accessibility Checker Pro
  • How AI helped with planning, prototyping, development, and code review
  • Accessibility challenges unique to React and single page applications
  • Managing focus, live regions, and state changes for assistive technology users
  • Building reusable, accessible components with WordPress
  • Why accessibility issues block releases at Equalize Digital
  • How accessible software reduces support requests and builds customer confidence
  • The story behind Chris’ “Accessibility Issues Explorer” adventure poster

Links & Resources Mentioned

Save 10% on any Accessibility Checker plan with coupon code AccessibilityCraft.

Tune in to Accessibility Craft conversation episodes like this one every other Monday.

Accessibility Craft is hosted by Amber Hinds, Chris Hinds, and Steve Jones. They are experts in digital accessibility and creators of software, courses, and specialized services that have made millions of websites more accessible through their work.

To learn more about us, you can visit our website.

Listen

Watch

Youtube video

Transcript

Chris Hinds: Welcome to Accessibility Craft, where we explore the complex challenges and emerging trends that are shaping digital accessibility, while sipping on unique craft beverages. This show is proudly produced by Equalize Digital, The most trusted name in WordPress accessibility. Join us every week as we break down accessibility news and share the expert strategies we’ve used to help make millions of websites more accessible.

Grab a drink, the show starts now!

Amber: Hey everybody, it’s Amber and I’m here today with Chris.

Chris: Hello everybody.

Amber: And Steve.

Steve Jones: Hi everyone.

Amber: And this is episode number 172 of Accessibility Craft, which means you can find show notes and a full transcript if you go to accessibilitycraft.com/172. What are we drinking today, Chris?

Today’s Beverage

Chris: We have a returning beverage producer here. It’s been a while. We tried a mocktail from them previously. We are trying Recess’ Mood Calming Orange Vanilla Soda. I have it, I stuck it in a koozie to keep it cold here. But, yeah, They say that it contains magnesium and adaptogens infused in sparkling water to help you feel calm, cool, and collected. I don’t think there’s any actual drugs in this, alcohol or anything else.

Amber: Oh good, thank you.

Chris: I think it’s, I think it’s just a a kind of a woo-woo…

Amber: You know what, though? Actually…

Chris: (Cross-talk) beverage alternative…

Amber: So sometimes I’m like, “Is it fake?” However, I will say this without going too much into detail, but our pediatrician recommended that we give magnesium supplements to one of our children to help her with her feelings. And it’s just like a normal, like chewable vitamin.

So it’s like she gets a multivitamin, she gets a little extra of that, and I do think it helps a little bit. So maybe it’s real because a doctor said so. I don’t know. Maybe magnesium does work.

Steve Jones: I don’t know if this is an accessibility problem, but I can’t read this, can… it I have to, hold on.

Amber: The font size is really small. It’s got okay color contrast

Steve Jones: There we go. No, maybe it’s just my eyeballs. The readers help.

Amber: Steve has glasses? I have never seen you wear glasses before.

Chris: No, no me either.

Amber: Like…

Chris: I was gonna say that those glasses are awesome. I love the thick frames, man.

Steve Jones: Yeah, well these are just readers that you can get…

Chris: Oh.

Amber: Oh, they’re not prescription?

Chris: Great Value reading glasses?

Steve Jones: This is, this is 45. This is what happens when you hit age 45.

Chris: Yeah.

Amber: Yep. It says, “We canned a feeling, a sparkling water to help you unwind with magnesium, adaptogens, and no fake stuff to get you to that place you want to be.”

Chris: Yeah. The other reason I picked this is because the season we’re in, it’s summer, right? It’s Fourth of July has just happened, , at the time this is airing, and we’re like, we’re in the thick of the heat, and just something about an Orange Creamsicle sounded really good to me when I ordered this.

And so, why I chose the flavor. But I’m excited to crack these open and see how they taste.

Amber: Yeah, look.

Chris: A the end of the episode, we’ll see how relaxed we are.

Amber: It’s an antidote to modern times.

Steve Jones: Ah, that’s what we need.

Amber: How’s it smell?

Steve Jones: Creamy, orange-y.

Chris: Yep.

Amber: Oh.

Chris: I appreciate that it’s not super sweet. I’ll lead with that.

And the orange and the vanilla feel balanced, which is nice. A nice long finish on the vanilla too. The vanilla really is sticking with me.

Steve Jones: Yeah. It feels more vanilla than orange to me. But I mean, I get the orange, just not… It tastes like a creamsicle though.

Amber: Yeah, it’s interesting for it being more like sparkling water-y verse soda. It is very light on the sweetness. It does have that kind of creamy flavor to it or almost mouth feel too. It’s interesting.

Chris: It reminds me back in my restaurant days a very long time ago, during the summer months I would do like a pie of the week as a dessert ’cause nobody did pies, and so it was me trying to be different than the other restaurants around us. But , one of my go-to pie flavors in the summer was an Orange Creamsicle pie, and like a chocolate cream pie or banana cream pie, those sorts of things? We’d do like a vanilla custard inside the pie shell, but we would add a little bit of orange zest, and then candied orange with it, and some like toasted meringue, and it was a killer summer pie ’cause of that citrus. But this flavor makes me think of that a little bit, especially with the heaviness on the vanilla. It’s really good.

Amber: So when you do meal planning for next week’s meals for our family, now that you’ve said that, I kind of feel like that ought to be on the list.

Chris: That ought to be on the list?

Amber: Yeah.

Chris: Maybe it should be.

Steve Jones: Yeah.

Amber: Pie is a very summer dessert, I feel like.

Steve Jones: Yeah.

Amber: I mean, I don’t know, and fall, but yeah, pie.

Steve Jones: Yeah. Good key lime or lemon meringue.

Chris: Yeah, any citrus-based pie in the summer I feel like just flies. It’ll disappear like the second it’s done being made. It’s best.

Amber: The other thing I noticed about this that’s kind of interesting is it contains 21% juice, which is a lot more than some of the other beverages we’ve tried on here. A lot of times their fruit flavor is coming from artificial or quote natural flavorings, but not juice. So I’m like, how natural is it?

I don’t know. Like oils or extracts, I guess. But I think it’s actually coming from some juice.

Chris: Yeah, it’s got pear juice concentrate and tangerine juice concentrate. And this is interesting, I don’t think I’ve ever seen this on ingredient list before, but they’re doing an orange vanilla tea infusion with water, rose hips, apple, papaya, and hibiscus-based teas, to get some of that flavor.

Amber: Yeah.

Chris: All these their magnesium adaptogen blend with a bunch of different trace minerals and vitamins.

Steve Jones: Interesting that like Amber said, in the mouth, like it almost coats your mouth and makes it feel creamy.

Amber: Do you like that feeling or does it bother you?

Steve Jones: Doesn’t bother… I mean, I think it tastes good. I like the taste, so like maybe, I don’t know, it kind of gives you the whole cream experience, like creamsicle.

Amber: Yeah.

Chris: Yeah. I mean, the, I don’t know. I feel like it’s not our generation, right? But Steve, are your kids doing the dirty soda trend up there in Ohio? Ours are all about it.

Steve Jones: I mean, my kids aren’t too into soda. I think the oldest one will have a Dr. Pepper from time to time. But we do have friends that their kids are into it, and they even have a little, at the 4th of July celebration, they have a tent, and they do the mixed sodas…

Chris: Oh, cool.

Steve Jones: Taking pop and mixing it with all kinds of different things.

Amber: Flavors and stuff, yeah, and cream.

Steve Jones: It… Yeah, it is kind of a thing.

Chris: My kids will make them at home, and this, like the texture of it really reminds me of the ones where they’ll put like a little splash of cream in the Dr. Pepper or the Coke or whatever it is when they bring those home. They’ve done a good job with this I feel and I’m gonna give my rating. I think this one’s a thumbs up from me. I’m probably pulling more of these out of the fridge and drinking them when it’s hot outside, which will be for the foreseeable future. I don’t think these are gonna last very long.

Amber: Yeah, I’ll give it one thumbs up too. I like it.

Steve Jones: Yeah I will caveat this. I kinda was tipped off that this was pretty good because I think my wife has already started going through the pack quite heavily herself.

Amber: Hey, save one for me for the episode.

Steve Jones: I know. I mean, I think it w- I don’t know what you sent us, 12 of them or whatever, but yeah, my wife’s already made her way through quite a few. But I’ll give it a thumbs-up. I think it’s pretty good.

Accessibility Conformance Report Updated for 2026

Amber: Awesome. Well, I thought it would be worth calling out before we dive into our conversation about single page applications and accessibility that we recently updated our accessibility conformance report for Accessibility Checker. So anyone who’s listening, if you want to find that the report is available on our website right now in the documentation.

Chris: But Amber, I thought we already had published an ACR for Accessibility Checker a while ago. Why did we do this? Why update it?

Amber: Yeah, so we have had a ACR available for Accessibility Checker since 2021 because we decided that was really important and we always recommend that WordPress plugins act like other software and other software publishes these. But as you can imagine, a lot has changed in the plugin since 2021.

I actually think, and I will admit I’m a little embarrassed that it took us a while to do this because when we looked back at it, we realized that when we drafted this front-end highlighting did not exist. So as you can imagine, a lot has changed, and it is always really important when you have a software product or a website maybe where it is changing frequently that you update that on some sort of regular basis. We’re striving to do this more frequently moving forward, but of course, that is why we did it, because our past one was out of date.

Chris: And, do we expect any more ACR updates to be coming in the near future, or do you think this one’s gonna be the way it is for a little while?

Amber: So what is worth noting is that this, previously we had an accessibility conformance report that tried to cover both Free and Pro, and what we’ve decided to do moving forward is to have separate accessibility conformance reports for all of the separate plugins, because that allows people to drill down and just get the information, like if they’re only using the Free plugin or if they’re not using one of the add-ons for Pro, then they don’t have to worry about that as much.

So we have published the one for Free. Hopefully by the time this episode comes out, we will also have the updated report for Pro. But our next thing is we’re working through our CSV Export add-on, our Audit History add-on, the Multi-site add-on, so we will have separate accessibility conformance reports published for all of those as well.

Steve Jones: Yeah. So in your guys’ testing, and this kinda puts the product guys, the development team on edge a little bit when we go through this process, but did anything surprise you? Anything that came up that required any deeper discussion?

Amber: Well, so I’ll say I was really happy. Maria did a lot of testing, and she opened individual issues. And yes, there are a few things right now that are not totally perfect, because that is the nature of software. But one thing that made me really happy was it seems like most of what she found was in older stuff like in the metabox for example, which we are… I know you’re doing a bunch to work through and resolve that.

There was one thing related to WordPress Core that I had never noticed before, which means I clearly missed this when I did our original testing on the ACR. But did you guys know that on mobile, the footer in the WordPress admin is hidden?

And so what happens is that if a user zooms in enough, anything that’s in the footer container in WordPress admin goes away and is not available. So for us it’s like an upsell, but also the WordPress version that is currently visible and like other plugins could be putting other things. So I ended up being like, “Okay, well, yes, we could force a fix for this on our plugin screens, but actually the better fix is I went and opened a Trac ticket for WordPress Core,” ’cause I was like, “Hey, you probably shouldn’t be doing this.”

And that’s interesting because I saw somebody, they always go and try to figure out when did this problem get introduced? And it’s oh, it’s been that way since 2013.

So us doing this work on our plugin will hopefully make WordPress better also. I imagine there’s a couple things, Steve, when you get in and start triaging, that you’re gonna be like, “This is caused by Gutenberg.”

Steve Jones: Yeah.

Amber: “We can’t fix it.” Especially the one or two things that did come up related to the sidebar. I think there was one that I remember flagging in my testing, and it’s that there’s a button included in a heading tag instead of right after it?

Steve Jones: Oh.

Amber: In the sidebar itself, and I think I, I remember…

Steve Jones: I’m certain that’s a Gutenberg issue, ’cause the button has to be… Like, you can’t put things outside the title. It has to be inside the title of that component.

I will echo too that I think in my glancing through the tickets, we haven’t done a full triage of all of it yet, and got these all slated for being remediated. But the, is that a lot of it does pertain to the classic WordPress metabox. So in recent versions of the plugin, we have introduced a sidebar, which we’ve talked about on here in, in our changelog livestreams that we have.

And actually those two pieces one can be used without the other, right? You can use the metabox on its own, or you can use the sidebar on its own. So a lot of these accessibility issues are related to the old metabox. Should we actually convert it to a real table, right? Do we need to update labels on buttons and things like that. And the way that the accordions work inside of there. But if those are an accessibility blocker for some users, we do have an alternative, which is the sidebar, and you can go to the settings and disable the metabox altogether.

Amber: If you’re in the block editor. Where this gets rough is if you are using some sort of plugin that creates a post type that doesn’t support the block editor. So I think we do fully intend to make the metabox as accessible as possible and resolve all these issues, right?

Steve Jones: Yeah, I mean, I think the long-term goal here is to have a unified experience between the metabox and the sidebar, where we pull kind of the sidebar into being the same thing that’s in the metabox. There’s challenges there, whereas we are leaning heavily on using WordPress block editor components build the sidebar that aren’t available when it’s not a block editor. So we would have to export those components and kinda manage those on our own to be able to utilize those in a non, block editor experience. So there’s some challenges there, but…

Amber: Yeah, maybe a future podcast episode. When you get to that, we could talk all about that. How do you use block editor stuff in a non-block editor environment?

Steve Jones: There you go.

Making SPAs Accessible

Amber: But I think that actually relates a little bit to what we wanted to talk about today. This is obviously a little bit of a follow-up to your Changelog live stream that you did with William a couple weeks ago which we’ll definitely link in the show notes for people if they want to catch up on that.

So I don’t know if we’re going to go super deep into everything that makes up the Issues Explorer, but I did want to talk about the accessibility challenges, and I know on that connection back to the block editor, William had said he was trying to replicate some of the things that you guys built for the block editor and the sidebar in a different WordPress admin page.

So maybe that is a good tie-in there as well to some of the challenges.

Steve Jones: Yeah. So, we have created a new view inside of our Pro plugin called the Issues Explorer, and historically we had the open issues page, we had the fast track, we had ignored items and global ignored items, and these were four separate experiences when you would dismiss from one place, they would end up in a whole ‘nother page that you would have to navigate to. And if you wanted to switch between the current rule check that you’re looking at, you’d have to go back a page and/or use a dropdown to switch context. We’ve taken feedback that we’ve gotten over the last five years, through our own dogfooding of our own software and through feedback from users and just some, just some back-and-forth UI work that we’ve done to kind of try to create a better experience.

We’ve unified this all into one single-page application you can quickly go through and audit and remediate your accessibility issues at a glance and with with few clicks, all staying on the same page.

Chris: Amazing. And using it is amazing. I would like to get way more into this, including to start with how AI played a role in this new unified experience that you all built. But before we get into that, let’s take a quick commercial break.

Brought to you by Accessibility Checker

Steve Jones: This episode of Accessibility Craft is sponsored by Equalize Digital Accessibility Checker, the WordPress plugin that helps you find accessibility problems before you hit publish. Thousands of businesses, nonprofits, universities, and government agencies around the world trust Accessibility Checker to help their teams find, fix, and prevent accessibility problems on an ongoing basis.

New to accessibility? Equalize Digital Accessibility Checker is here to teach you every step of the way, whether you’re a content creator or a developer, our detailed documentation guides you through fixing accessibility issues. Never lose track of accessibility again with real time scans each time you save, powerful reports inside the WordPress dashboard, and a front end view to help you track down hard to find issues.

Scan unlimited posts and pages with Accessibility Checker Free. Upgrade to Accessibility Checker Pro to scan your website in bulk, whether it has 10 pages or 10,000. Download Accessibility Checker today at EqualizeDigital.com/Accessibility-Checker. Use coupon code AccessibilityCraft to save 10% on any plan.

Using AI to Accentuate Product Development

Chris: And we’re back. Steve, can you talk about how you approached using AI for this new Issues Explorer, where you applied it, and how helpful was it?

Steve Jones: Well, so you know, AI was used in the building of this, and let’s be honest, AI’s used in the building of a lot of stuff these days. And what we’re going through right now with AI, I think, in the development community is a complete retooling of our workflows. And I wanna underscore tooling as that the AI is the tooling that we are using.

It’s no different than tooling that we’ve used, such as iDEs right? That actually help you do code completion, that actually help you lint as you’re writing code, right? Those are all things that were assisting you in creating it. And now we’re bringing AI the fold here, and we’re using it to assist in the typing and the execution of our code. What we’re learning through that process is that there is still a need for an engineer i-interjected in between that AI and what that end product is.

But yeah. So we go through, and we know what we wanna build. We build a bunch of issues. We actually use AI to generate all the issues for what we’re gonna build. If you use AI, you know what plan mode is. We use plan mode to really think through things thoroughly. We create all the issues. We use Linear to manage those. They all go in there, and then we utilize AI to go through those issues and start to work on them. Then, then PRs get opened, and then we have CodeRabbit, and we got Gemini, and we got CodeX that go in and code review the code that the AI created right?

So it’s very integral to our workflow, but in the end, there, there becomes a bottleneck where those things can happen a lot quicker than before. Whereas, the first 80% of the project can move really fast now, like extremely fast. The last 20% of the project goes extremely slow now because that’s when, William or I or another developer has to come in, or a tester, somebody needs to come in and test this for accessibility. Did the AI really follow accessibility best practices, right?

And we have to test these things. And in the end, it’s not to, it’s not to replace the developer. It’s not to get something quicker. It’s to actually accentuate the developer and actually make a version one that is better than we could have made, in the old days by writing everything by hand. So it’s not a cop-out. It’s not a, it’s not a quick way to get to something. It’s tooling to help you accentuate your current workflow and actually make better, more secure software on the first iteration.

Amber: Yeah. I think also you used some AI for the designing, and what I think is really interesting about this switch for us is we went from having a very WordPress-y admin experience for our plugin. The tables looked very similar to the way the tables look if you go to the posts screen , right? It very much was like the WordPress way, I guess, which, let’s be honest, is not very visually appealing.

And then, and also isn’t a single page application. Like, if you do a bulk edit on the post screen, the whole page reloads, and then there’s a notice up top that doesn’t get focus and screen reader users might not see, right? This is a very dated way of notifying people or making things work.

There’s a lot of things in core WordPress where it it should be a button because it’s an action, but the way it works in WordPress is we just link to the same page with the URL parameter and then… Right? So it just reloads the page with the URL parameter, so now this is a link.

It’s it’s super confusing and weird. And then we went to this, we’re gonna have what you said was a React single page application that just exists in a WordPress shell. So the whole design and everything got opened up because we weren’t doing it. And I’m curious, I know you think you used AI a little bit to create some of the designs, and I’m curious how you prompted it. And did you find that it did an okay job with accessibility at the design phase, or were you already finding problems, like color contrast wasn’t good in the designs that it created?

Steve Jones: Yeah. So I mean, I think this underscores the rate at which the way we do our business is changing, right? So we talked about our sidebar, which we released approximately, I don’t know, six months ago or so, right? And when we went through that phase of UI/UX work, we did it in Figma. I actually went in and laid it out in Figma. Now there was some AI help in there where, Figma has an MCP server. But the way I used it in that regard was I would connect with the MCP server to actually just have it look at the UI/UX and give me UI/UX feedback. Is this good UX? Do these terms make sense? Should I do this? And then I would, go into Figma and move things around, right?

And then when we came to doing the Issues Explorer, Claude Design had come out, so, but at that time it was still… it might still be beta now, but was beta, but you had to use your own credits, but and you had to use API credits to do it.

And Claude had given me some free API credits. And so I burned through those trying to come up with kind of the initial look of what this would look like. And since we had gone through the Figma phase, right, where we put all of the sidebar stuff in Figma, which, has fonts and typography terminology and things like that. And we have other Figma files with, some of our branding and our logo and all that. So I was able to go in there and create a design system of Claude Design, a-and then I used that design system to build out this initial Issues Explorer layout. I ran out of tokens because it eats tokens like crazy to make designs.

And I actually found that Claude Design was kinda clunky. I would ask it to make changes, and it would, it would change something over here but not over here, or it wouldn’t understand what I’m saying. So I actually exported that whole thing. It was actually a working prototype. And it was nice that I could click on it, and could record a video and send it to the team and say, “What do you guys think about this?”

Right? And without us going through m-months and months of coding. And so I exported that out of Claude Design, threw it into a repository. So we have a repository with this, all this prototyping, and then I just rolled up normal Claude code with it. And I started actually designing and prototyping with with prompts. And I actually took it from… Now what it initially came out with was really cool. It had Kanbans and all kinds of stuff. I think I showed it to you guys.

Amber: Yeah.

Steve Jones: It was…

Amber: I still think maybe a Kanban might be cool in Accessibility Checker Pro’s future, right, for being able to assign issues.

Steve Jones: Yeah.

Amber: A certain WordPress user and then that user can action them and ask for review. Maybe someday.

Steve Jones: Yeah, and we’ve laid the groundwork for that. We just haven’t rolled that into the version one. The prototype had a lot of that stuff, so I had to start paring things back, right? And then I was like, “Well, does this really work with the sidebar that we have already created and the modal we have already created in the single instance view? Can we create a unified experience?” Like, when you pop open an issue to start actioning upon it, is this a unified experience? I already learned how to do it in this context on a single-page issue. At the global level, it should be kind of the same experience. So I did spend a couple days going back through this, and I don’t think I saved any time by using a prototype.

But I think I, I got a feel for how the application would work, and when we went to development, it really helped a lot, ’cause we could actually feed a working prototype into Claude Code, and it could really build the UI really quick, because it was essentially already built.

But as far as the accessibility question in that regard, now, in the prototype, I didn’t do keyboard testing and things like that. But color contrast, I think that out of the box, it didn’t really get all the color contrast right. It was using a, like a lot of people would, a swath grays, right? In a modern design, it’s like you got these really light grays on top of these kind of muted bluish grays, right?

And so when we got into this a little bit further, I think even before we sent it off to you guys to do some, auditing on we had a lot of color contrast things that we had to resolve on the development side, because we didn’t fully address it in the prototyping phase.

Efficiency, Scalability, and Not Reinventing the Wheel

Chris: Yeah. And I’m, curious, like we’ve done the prototyping, the building, all of that. When you were doing the actual build can you take us through if there was much that you could actually use like out of WordPress Core or like piggyback on that? Or is this just its own self-contained thing that exists, right?

Steve Jones: Yeah, we could use a lot of WordPress components. So the beautiful thing about using React is it’s kind of already there now in WordPress. We don’t have to have this kind of raw React load into the system because it’s there. We don’t have to necessarily pull in a third party UI library because WordPress has a UI library. And a lot of accessibility work, of people kind of rag on Gutenberg a lot and the block editor, but it’s come a long way. We have to give a little bit of credit where credit’s due that, a lot of work has been done to make it more accessible, to make these components more accessible.

So if you adopt that into your plugin, one, you’re unifying the experience inside of WordPress, and two, getting a lot of that audit remediation work that’s already gone into those components. So yeah, I mean, we’re using check boxes, we’re using radios, we’re using panels, m- modals buttons, drop-downs. I- in the Issues Explorer there’s a way to filter. You can filter out by things, but it’s a, it’s a button drop-down, and then you click on a, on an area to filter, and it actually opens into another panel, and then you can click back. That’s a WordPress component. So yeah, there was a lot that we could utilize that was already there.

And on top of that doing the sidebar already and having the single modal that gets opened from the sidebar, there’s components in there that are like collections of components. So we have our dismiss panel, right? So our dismiss panel has it’s an accordion which the accordion is a WordPress component. It’s got a radio field in there for the dismissed reason, which is a WordPress component. It’s got a, a text area, which is a WordPress component. But they’re all collected into a, an accessibility component so that so that we have our own panel that can be used in other places.

Now, what we had to do in that regard to get this over into another plugin is we had to turn it into an export that can be an an export, JavaScript export in the free plugin that we can then import into the Pro plugin. So we’re kind of, we’ve got this mix of our own components that compile core components that are exported from free and then utilized in Pro. The beautiful thing about it now is between the two plugins, like if we wanna change the dismiss panel, like I think recently Amber opened an issue to reorder the dismissed reasons inside of that component. So now we go to the… That’s in the free plugin. We go to the free plugin, we reorder it, we open a PR, we submit it in, and now that’s available in both plugins. Like with…

Amber: You only have to change it one place, and it will go everywhere. Yeah, I think that’s probably the direction that you want to see development going, right? There are a lot of great plugins on WordPress.org, but there are also some plugins that are, like, some random person coded it or had AI code it, and they aren’t maybe thinking as strategically about the bigger picture, like maintainability, scalability, like how could it grow bigger which I know you all put a lot of effort into.

And on your changelog, you showed just the difference in performance. I think something that on the old thing would have taken, 10 seconds for a page to load, now it just happens almost instantly which is really cool. But I think it’d be worth us talking about some of the challenges around making a single page app particularly from an accessibility standpoint, because I do think that there can be a lot.

Accessibility Considerations in SPAs

Amber: And I’ll maybe start off by talking a little bit about what’s different when we’re doing accessibility testing in a single page app versus testing a web page, or any software in general. I would say it is interesting, like the kinds of issues that you have to look for in a WordPress plugin, for example, if you’re auditing it, are very different than the kind of issues you would look for on a website.

Obviously, you should use a screen reader all the time no matter what you’re testing, but it is even more vital to do screen reader testing in a piece of software that is a plugin that allows people to interact with it in very complex ways. Because I think we noticed there’s a lot of challenges with just React out of the box around status messages and are people being notified when they dismiss an issue or if they open or close a modal or if they filter things, because we have all these really cool filters now.

And so I do think there was definitely some differences there in how we had to approach auditing and some of the issues that came up. And I’m curious what your thoughts were, Steve, on how you addressed some of those issues, if there was anything particularly challenging, and what you might recommend for other people that are building React apps like this.

Chris: Well, and I want to piggyback, too, for the dumb non-developer guy question, which is a lot of this just around managing and surfacing state changes because the page isn’t loading again? Or is there something deeper going on th- that…

Amber: Focus too.

Chris: … makes this harder? Okay, focus, all right.

Steve Jones: I mean, those are all great questions, and I think y-you kind of, you tipped on something pretty important. Yeah, state change is key when you’re working on a single-page application, right? Because I think we take for granted a little bit in traditional applications where you are afforded a page reload, right? When a page reload happens, in a way, you have an accessibility “out” because the whole page is reloaded. It’s on the screen reader user to go through and discover what’s changed for the most part, right? You can still announce on a page refresh to kinda help them along, but whereas…

Amber: This is a gap, I think, in Web Content Accessibility Guidelines because the status message success criterion only applies if something changes on the current page.

Steve Jones: Right.

Amber: So right now, if you’re following that you don’t get a fail if you just reload the page. So what I was talking about earlier in the episode about, oh, you can do a bulk edit on the post screen, and then it will reload the page and say, “Five posts were updated.”

If the screen reader does an announcement, it’s not technically a WCAG failure. However, let’s be real. That is not a good user experience for a screen reader user.

Steve Jones: Right.

Amber: So I th- I think what you’re talking about is it can actually be better, but it is definitely a…

Steve Jones: Yeah, yeah, totally.

Amber: … frustration on my part, right, in the WCAG is missing this.

Steve Jones: Well, so yeah, exactly. So the beauty of a single-page application is that it, it gives you this experience and the things just happen and page reloads don’t have to happen and, page reloads and then it’s back at the top of the page and, things can just happen super quickly. They’re snappy, right?

Whereas before a page would refresh and that same interaction could happen, but for a screen reader user, they’ve got to explore the accessibility explorer or the to, or the Issues Explorer to find what changed. And that’s really like even though like you said, it’s not a WCAG violation, it’s not a good user experience. When it comes to a single-page application, when those state changes happen, like they’re not gonna hear anything out of the box. So first and foremost, if you’re building a single-page application, build a mechanism for speak, for announcing changes, right? Don’t try to… and maybe look for a library.

And going back to our previous, topic here was, what can we get out of the box with WordPress to help us along? WordPress comes out of the box with Ally Speak, right? And we can target Ally Speak and we can push things in. And to that, it’s a live region that, we can make it assertive or polite, right? and those things are built in. And when we make a dynamic change to a page, we can easily push it into Ally Speak and hopefully have it. Now we have run into some weird bugs with Ally Speak and VoiceOver and we have opened an issue with WordPress core to help fix it.

So we get the fix in our plugin that all of the half of the internet using WordPress gets the fix too, right? So that kinda is number one, i- is make sure you have a way to announce state change, right? And, two, be- being very mindful of focus and focus change. Like where, when you make a change, where does this focus need to go? And I think in the end, if you really get those two pieces right, that like you can create a, an experience for a screen reader user that is far superior to page refreshes. And, it can be compliant now that it’s dynamic content.

Now, with dyn- dynamic content, you actually have to make it compliant. It actually has to announce to meet the criterion, right? So I will say too we pushed this over to Amber and her team for remediating it, we, this is kind of how product development goes, right?

We are rushing to get this thing out, right? We are pushing and pushing. We have a little bit of a luxury here that we have such a good auditing team that we can lean on. We probably left a few things that, that for them to find that, because we knew that was gonna be kind of a stopgap before we would release.

Chris: That like maybe you could have found if you had spent your time testing instead of building out more of a feature or whatever.

Steve Jones: Which w- is, it’s a priority thing w- when you’re building software. It’s always what’s the thing that moves this along, right? And for us, it was kinda like, let’s get this over to them. We can keep moving, and then they can give us the feedback. We got a lot of great feedback. Some of it was tricky. A lot of it was pretty easy to fix. I think in the end it’s, we always talk about not just making software that checks for accessibility. We make software that is accessible that people can actually, people that use assistive technology can actually use themselves to check for accessibility, right?

Making Sure Accessibility Stays a Key Priority

Amber: Yeah. I will say on that note, it is worth highlighting that I know you wanted to release this earlier than it got released, but we opened issues and what we don’t do, which is different from some dev teams, is we don’t say, “Okay, well, we’ll release it and we’ll just follow that up in a patch.” For us, we we decide that there are certain…

We prioritize our accessibility problems, and there are a lot of accessibility problems that are blockers to release. And I mean, I’m proud of us for doing that, ’cause I know it’s hard and I know when you’re, like, really excited, you’re like, “I wanna get this out there,” and you’re like, and it, it is easy for teams to be like, “Well, what percentage of our users are scr-” Right?

But at the same time, we’re like, “We’re gonna practice what we preach.” And so it took a little longer, but in the end that is the right thing to do. It’s the same thing we don’t release… People have been like, “Well, why don’t you put the meetup recording the next day? You have the video.” And I’m like, “I’m not gonna release a meetup recording without proper captions.”

And I’m sorry it means everyone has to wait longer.

Steve Jones: Yeah.

Amber: It means everyone has an equal experience. It’s not just the deaf people who have to wait longer. And I think that’s the right thing to do and I would hope that more companies would start working that way and be like, “We’re not going to release software with accessibility issues.”

So…

Chris: To add to that, thinking outside of just the dev, QA, release pipeline, there are other… And customer base too, right? Those are some stakeholder groups, but there’s another major stakeholder group or groups that, depending on the size of your company, that you can consider, and those are, like, your support teams your sales teams. And if you are pushing out inaccessible stuff that maybe gets the accessibility fixes get backlogged, in your support conversations, that’s gonna come up very likely, especially if you have a customer base of any amount of size beyond a few dozen people. Statistics say you’re gonna have a not insubstantial set of your customers are going to maybe encounter barriers.

But the other big one, and I have a specific anecdote for this. I was talking to a university system in California, who has since used our product on many hundreds of their websites, usually the free product, but a few of their departments have bought paid too. But one of the things that came up, they had the, one of their accessibility team leads on there, and I could hear in her voice that she thought she was asking me a checkmate sales guy kinda question, which was, “Well, how accessible is your product to users with disabilities?” I think she thought it was, like, a checkmate question, like she was… Like it was gonna be a gotcha.

I was like, “Oh, you should try it.” And I was like, “Right now, if you want,” because I had the total confidence that she was gonna have a good experience. And she fired up her screen reader. I don’t think I’ve told either of you this story. She fired up her screen reader and got her… using her keyboard, going through it, had her screen reader announcing, and she was like … And on the demo, and she was like, “Huh. Huh.” And she was like, “Wow.” And I was like, “That’s right.”

If you wanna give your sales team and your support teams a win, prioritize accessibility, ’cause it doesn’t just effect your release pipeline

Amber: Yeah. There was an episode we could also link here in case anyone missed it with Taylor, who used to work at Liquid Web on the LearnDash product team, and she had said that when they did a ton of accessibility releases following an audit that we did for them and then they, really focused on accessibility within LearnDash, they saw a significant drop in support requests, which saves them money.

Steve Jones: Yeah.

Amber: Right?

Steve Jones: I’ll t- I’ll tag onto that too. Not just accessibility, but like security and c- code quality o- overall. Like I, think our support for Accessibility Checker is well below industry standards from what I see from other product companies, and I think it’s…

Amber: You mean our support reque- like the number of supports we get is below…

Steve Jones: Thank you.

Amber: Our support is not below industry standards. We provide very high value support.

Chris: If anything, it’s above average because we have extra time due to the lack of support requests because everyone can just use it.

Steve Jones: Yeah, totally. And so if, if you follow standards and that you really take those extra steps to make sure that, it’s secure as, as secure as you can it with the tools that you have, and it’s accessible and that, the code quality is good and that it it actually works, right?

And it doesn’t conflict with other stuff, I think you can really save yourself a lot of time in, in fielding a lot of support things. I do wanna touch a little bit on, it’s easy for us to say, “Just make it accessible before you release it,” right? ‘Cause I wanna dive into kinda the developer team mentality a little bit around that, and I don’t wanna, I don’t wanna say that, like it’s just, it’s just easy for us to do that. When a whole slew of r- audit changes comes through the pipeline, it’s I mean, we get it, too. It’s “Oh, man, this is a lot.” Or and then you y- you kinda you start to kinda get a little visceral response to it. You wanna kinda push back on some of the issues, right? You wanna make them justify it a little bit for release.

But then, after you cool down after a day and you start to go, “Oh, no, this is the right thing to do. Let’s get– let’s see what we can get in before the release,” is there… We do prioritize. Is there some of these that don’t have to make it for release? And I will say there were probably 30-some issues open, and there’s probably only three or four that are not going in the release.

That’s a high percentage that we are like, “Yeah, we’re gonna get these all in,” right?

And…

Chris: Well, and I’m sure that the ones that got left for a future release are probably the least critical. Because that’s the other thing to understand as product teams is there are levels of criticality to Web Content Accessibility Guidelines and to accessibility deficiencies. Not every single accessibility deficiency represents a total blocker, although to be clear, many of them could in the right context.

But if there’s limited time, right? Do the critical high and mediums. Leave the lows, like if you have to. Obviously all is better, but do what you gotta do.

Steve Jones: Yeah, they will all make it in. And a lot of them are caveat too. It’s there’s a little bit of a bug with Ally Speak in, in, in the Mac VoiceOver utility, right? the way to remediate that, to actually kinda make it work, is to put in a slight delay, which actually violates guidelines, right?

Just build your own? Do we not use Ally Speak? Do we build our own announcement just for this one widget because, the accessible DOM is b- being updated, but VoiceOver’s not catching the update, right? Do you actually add in a 100-millisecond delay so it actually works just for the time being until we can get Core to fix it, and, then we get to get…

So it’s sometimes the things that don’t get released are caveats like that. We’re, we’ve got a partial support for it if you’re using, know, NVDA or Orca or something. It’s…

Amber: Or JAWS, yeah.

Steve Jones: Yeah.

Is Accessibility Harder to Implement in SPAs

Amber: Do you think… I think just as a wrap up, I’m curious, do you think that accessibility is harder in single page applications or React based applications versus traditional WordPress PHP setups?

Steve Jones: I mean, I don’t know if that’s an accessibility question or if that’s a, an, a software engineering question. And the the way I, the reason I say that is because once you get into making a app and you start to see the advantages of componentizing certain parts of your application, and you have a mechanism for, announcing state change. I think once you have fundamental things and you have an understanding of how to make React in the first place, React is harder than PHP. Let’s it’s…

Amber: So just building the single page application is way harder than building a traditional WordPress plugin. Yeah.

Steve Jones: Right. Now, is the…

Amber: Yeah

Steve Jones: … accessibility of one or the other harder? I don’t know. I would say that there’s probably more accessibility work that, custom work that you have to do to ensure changes are announced in a single-page application than you have to do in a PHP application or, some other static or just even a HTML application if you’re still doing that kind of thing. Because you are afforded that page refresh, and it is an out, but is that a better experience? I don’t know.

Maybe it’s a little bit more work to announce state change, I feel like the experience for a screen reader user assistive technology is a better experience in the end and it mirrors the better experience that we’re trying to make for the, the mouse user as well.

We want this to be one page. You get your table of items. You click on an item. You get a side panel that pops up, and you can still see the other issues behind them. You can action on that. You can close it, go to the next one, and we want that experience to be seamless between mouse and keyboard.

We Share a Ridiculous “Inside” Joke

Amber: Yeah. I think, I mean, I think it is way better. I think, Chris, when you tested it, you liked it a lot, and I think your response was enough to…

Chris: So good. And I’m glad you said it, Steve, that it’s yeah, it may be harder to build, but also it being a single page with the accessibility attention paid to it makes it a better experience for those users, but also for everybody else, because I cannot tell you how much of a pleasure it was to use this compared to the version before that had, three or four different views and slightly fiddly different workflows for each view depending on what you wanted to do. And yeah, you could accomplish a lot of the same goals in that old system that you can accomplish in this one, but it required way more clicks, maybe a bit more of a cognitive load, and the background or the knowledge to know what you were supposed to do and where you were supposed to go.

Whether, whereas with this next one, it was just like, I know intuitively, even if I maybe haven’t seen this before, but I just kind of understand the back end of WordPress just generally, I know exactly what to do. if I, even if I don’t I’m going to figure it out within a click or two. And it’s it’s amazing what y’all have put together. Nothing short of amazing.

Amber: Chris liked it so much that his reaction caused Steve to create a very funny AI-generated image that I’m fairly certain right now, I think we should just make the featured image for our podcast, so it’s gonna show up in your podcast players. But maybe we can just stick it in the show notes, too, for folks who are accessing this on a browser or YouTube and not in a podcast player.

Chris: Well, as the editor of this, I also have special powers like being able to put it right here visually for people, which this is my note in the transcript to do that. So you’ll…

Amber: Yeah, I mean, so someone with a deep voice needs to read, the title of this image which shows Chris as I don’t know, what is this? Like 1920s…

Steve Jones: Indiana Jones?

Amber: Style. Yeah, Indiana Jones style explorer. He’s holding up a compass and he’s got an issues map and a bag with a patch that says WCAG 2.2: Build for Everyone. But maybe somebody that is, has a better voice for this than me can read the title of that graphic.

Chris: The ’90s action movie announcer. In a world full of accessibility issues, right?

Amber: Do it.

Chris: In a world filled with missing alt text, low contrast, and keyboard traps, one explorer dares to follow the issues map. Armed with semantic HTML, ARIA landmarks, and an accessibility compass that always points towards inclusion, Chris is the Accessibility Issues Explorer. Discovering barriers, creating access for all. Coming soon to a podcast player near you.

Amber: Yeah. Well, I think that is a wrap. I am so excited about this feature. Folks who have Accessibility Checker Pro, you have it. It’s there. We’d love to hear your feedback on it. If you haven’t, if you don’t have Accessibility Checker Pro, you only have the free version, it’s worth going to our website and spinning up a demo, and it will just load one up on a, an instant WordPress website.

You can play around with it and see it there totally for free if you wanna do that as well.

Chris: Bye everybody

Steve Jones: All righty. Cheers.

Amber: Bye.

Thanks for listening to Accessibility Craft. If you found this episode valuable, please help us reach more people by subscribing, reviewing, or liking the show, and sharing this with your colleagues. Accessibility Craft is a production of Equalize Digital Inc. Steve Jones composed our theme music. To learn how Equalize Digital can support you on your accessibility journey, visit us at EqualizeDigital.com.