Listen
In this episode, Amber and Steve discuss the introduction of JavaScript scanning in Accessibility Checker, the reasons behind this change, and how we expect it to evolve over time.
Mentioned in This Episode
Transcript
>> CHRIS HINDS: Welcome to Episode 58 of the Accessibility Craft Podcast, where we explore the art of creating accessible websites while trying out interesting craft beverages. This podcast is brought to you by the team at Equalize Digital, a WordPress accessibility company, and the proud creators of the Accessibility Checker plugin.
In this episode, Amber and Steve discuss the introduction of JavaScript scanning in Accessibility Checker, the reasons behind this change, and how we expect it to evolve over time.
For show notes and a full transcript, go to “AccessibilityCraft.com/058.”
Now, on to the show.
>> AMBER HINDS: Hey, everybody. It’s Amber, and I’m here today with Steve.
>> STEVE JONES: Hello, everyone.
>> AMBER: And we don’t have Chris.
>> STEVE: No Chris.
>> AMBER: I don’t know what to do.
>> STEVE: We’re all sad.
>> AMBER: Yes. We’re going to talk a little Accessibility Checker WordPress plugin building in public kind of conversation, and Chris said he probably didn’t have to be here for that.
>> STEVE: No. Cool.
>> AMBER: Although I am going to miss him on introducing our beverage because he usually does a really good job.
Do you want to try?
>> STEVE: I’ll give it a try, but it’s not going to be as good as what Chris would do.
Today, we are doing the Mango Michelada. It’s by Estrella? OK, I’m going to mess this up.
>> AMBER: Jalisco.
>> STEVE: Jalisco. See, we just…
>> AMBER: Spanish. [chuckles]
>> STEVE: We just prepped this, and I’m already messing it up, and it’s a golden beer, as it says in Spanish on the can.
>> AMBER: Yes, Cerveza Dorada. I’m guessing.
>> STEVE: Made with Clamato. Mango Michelado, so in the notes we have, “It is a delicious twist on a classic Mexican staple, inspired by Estrella…” Say it again, Amber?
>> AMBER: [chuckles] Jalisco. Jalisco.
>> STEVE: “…Jalisco Culture and the Mexican mango cart vendors in LA. Golden Road Brewing created a mango-flavored beer blended with Clemento…”
>> AMBER: Yes, I think it’s Clamato Picante.
>> STEVE: Jeez, you are so much better at this. Why am I doing this?
Brewed in LA.
>> AMBER: I live in Texas. [laughs]
>> STEVE: Yes, you’re from Texas. OK, OK. Yes, this is…
>> AMBER: Not a lot of Spanish in Ohio, maybe. I don’t. [laughs]
>> STEVE: Yes. Yes. For a Midwestern guy like me, it’s difficult.
>> AMBER: So Chris got this because we had ended our last conversation when we were talking about Accessibility Checker. We chatted a little bit on that podcast episode about micheladas, and I hadn’t had any, so when we went to Mexico for CaboPress, I had a bunch, and they were really good, but they were, like, fresh made.
A Michelada is basically like a Bloody Mary with beer instead of liquor, so they take tomato juice and then they mix in some beer, and then usually, they put something like a lime spicy salt, like, on the rim, and it’s called Tahini, if you’re familiar with that, and I really enjoyed them in Mexico.
My sister-in-law is from Central Mexico, and they call them micheladas there, and so I asked for a michelada when we went to CaboPress, which is over in, like, the Baja peninsula, where we were, and they were, like, “Oh, that’s just central Mexico.” So apparently out there, they’re in Ojo Rojo.
>> STEVE: Ojo Rojo.
>> AMBER: Yes, so Chris got the one with mango in it, and I’m afraid it’s going to be gross. [laughs] I don’t know.
Also, this is a 25-ounce can. It’s, like, three cans in one.
>> STEVE: This is how you don’t get any work done on a Friday evening. [laughs]
>> AMBER: Well, it is Friday, and I don’t know what the weather is like for you, but it’s about 80 degrees here and it’s sunny, and yesterday, I was working with the slider and the windows open, and it was so nice, so it seems appropriate to have a beer. Hopefully, it will taste good. Otherwise, I’ll take two sips and then I won’t drink anymore.
>> STEVE: [laughs] Yes. Fifty degrees up here in the north. It’s not as pleasant as Texas.
It’s not-nice Friday, late spring, early summer weather for you.
>> STEVE: All right. Here we go.
>> AMBER: All right. I also have my Accessibility Craft pint glass that I got for myself off our shop, so I’m going to crack this open and pour it in and see what color it is.
>> STEVE: So this is going to taste like a V8, right?
>> AMBER: It’s going to taste like what?
>> STEVE: V8? You know, V8 juice, tomato…
>> AMBER: Yes, but that’s what’s weird. It has mango in it, so it’d be like V8 with mango and beer?
>> STEVE: And beer.
[laughter]
>> AMBER: We’re not selling this very well, Steve. We need Chris here. He would be selling this so much better.
All right, so color impressions with the pour. I’m going to say, first of all, when you actually get a michelada made by a bartender, it is way more tomato-y than this, which maybe makes sense, because maybe it’s harder to make it shelf stable or something in the can, but…
>> STEVE: It’s pretty clear.
>> AMBER: Yes. It’s more clear than I thought. It’s a really nice peach color, and it had a good amount of foam, but not too much, and…
>> STEVE: Here we go.
>> AMBER: It smells like mango.
>> STEVE: Smells like mango. Not so much like a beer.
>> AMBER: It smells more like mango than tomato. Do you smell tomato?
>> STEVE: No.
>> AMBER: No. [chuckles] Yes. All right. All right. I’m going to try it.
Your face. All right. What does it taste like to you? [chuckles]
>> STEVE: Oh. It’s got, like, a real bitter sourness to it, doesn’t it? Maybe that’s the tomato.
>> AMBER: Yes, I don’t get bitter at all.
>> STEVE: Like a warm… Like a spice… Like a…
>> AMBER: So that’s probably the clamato, I would guess.
>> STEVE: Oh, yes. Like a chili powder, right? Is that what clamato is?
>> AMBER: Yes. When we did it, like, you put spice around the rim, and so I’m guessing maybe they used a spiced tomato juice.
I don’t think it’s bad. But I think the mango, to me, wars too much with the tomato. I think I’d rather have a regular michelada without also putting fruit in it. I don’t know.
>> STEVE: Yes. I will say, this is quite different than anything I’ve tasted on this podcast.
>> AMBER: It doesn’t taste like beer to me, honestly.
>> STEVE: No, not at all.
>> AMBER: Does it taste like beer to you?
>> STEVE: Maybe beer with a bunch of chili powder in it.
[laughter]
>> AMBER: Also, is it spicy to you? I don’t think it’s spicy.
>> STEVE: It’s not spicy, but the spice is definitely something I’m not used to with a drink like this.
>> AMBER: Yes, so in the, I guess, closest part to the ingredients, it says, “Beer with mango juice, natural flavors, and vegetable juice for color.” So I think I’m a little disappointed because I expected it to be more tomato and less fruit. Or I don’t know. Maybe I shouldn’t, because the can literally says “mango,” and has pictures of mangoes all over it.
>> STEVE: Yes, yes.
>> AMBER: It’s got to be less alcoholic than drinking an actual beer because it’s mixed with juice, right?
>> STEVE: Yes, yes.
>> AMBER: Where does it say what the alcohol percentage is?
>> STEVE: I was looking for that earlier and I didn’t see it. Maybe we have to read the fine prints.
>> AMBER: Oh, wait. Yes, “3.5% alcohol per volume.”
>> STEVE: Oh, yes.
>> AMBER: So this is like half a beer.
>> STEVE: It’s very low.
>> AMBER: Yes, so if you don’t like as much alcohol content, then you might like this.
>> STEVE: Yes.
>> AMBER: It’s more relaxing and less of a buzz, maybe. I don’t know. To me, I think the flavor is interesting enough that I want to keep tasting it, so I’m trying to figure it out.
>> STEVE: Yes.
>> AMBER: It does leave a tomato flavor in my mouth. I just don’t get it while I’m drinking it, but the aftertaste is tomato.
>> STEVE: Yes, totally. For me, it seems like after you drank it, it’s a bit odd? Like something I’m not expecting it. Like you said, “What’s going on here?” And it’s a little spicy on the end of it on my tongue.
>> AMBER: Yes.
>> STEVE: Maybe that’s what they’re going for. But not much beer flavor at all.
>> AMBER: Yes. It does not taste super beer-y to me. No hops, none of that bitterness that I would expect from that. It’s interesting. It’s like maybe a good “summer-day-by-the-pool” kind of thing. I would be curious if Estrella makes a normal micheladas, and if so, I would probably try it. I don’t know if I would get the mango again, but I’m probably going to keep drinking it during this episode. [chuckles]
>> STEVE: Yes. But maybe not 25 fluid ounces. Maybe we could do like a little…[laughs], you know, 12-ounce can or something.
>> AMBER: Yes. The can really big. I could probably shout to Chris, and be, like, “Hey, do you want to have the rest?”
>> STEVE: [laughs] Yes.
>> AMBER: Because even after filling the pint glass, the can still feels mostly full. [chuckles]
>> STEVE: Yes, yes, yes. Very interesting, yes.
>> AMBER: All right, so we’re going to talk because we haven’t had a chance, and it’s been quite a while since we’ve talked about what’s going on with the plugin, and there was a really big release right before Christmas. I actually wrote the blog post about this release in the car on my laptop, and then I was, like, “Can you go check it for me?” On my way to Iowa to visit my family, we released a new way of scanning for things.
So I’m wondering, can you talk a little bit about when we first built the plugin, how you were scanning for problems, and what’s changed?
>> STEVE: Yes. I can try to boil this down to the most simplest terms I can, because this could be a whole episode just on that alone.
>> AMBER: [chuckles] Yes.
>> STEVE: So our Accessibility Checker plugin, the way it was originally designed was, when it scans a page, it actually uses an HTML DOM Parser, and it’ll actually scrape the page for all the HTML elements and collect those, and it’ll also scrape the page for all CSS, whether that’s in a style tag, or it’s included, or it’s inline.
So it’ll go through and try to collect all those things together, and then it’ll run through all of our rule checks, so we have quite a few rules, 30 or 40, that it runs through in checks, and it uses that scraped information to make the evaluations.
So that’s how we originally did it, and the reason for doing it that way is, our plugin is a little different, and running our plugin inside of WordPress has a lot of challenges and limitations.
You see others, like a Siteimprove or Monsido, right?
>> AMBER: Yes.
>> STEVE: These are SaaS services that run isolated of WordPress, so it goes out and grabs the URL, scrapes the page, right? Or actually, it brings the URL over and probably renders it in a virtual DOM, and then evaluates all the information. That way, everything’s kind of done isolated away from the website, so it’s little impact to the website, right?
>> AMBER: Yes.
>> STEVE: Out of the gate, that was not really a possibility or something doable for us to roll up a virtual browser inside of WordPress, right?
>> AMBER: Yes. I mean, is it even possible? So you’re talking about something like Puppeteer?
>> STEVE: Yes, yes, exactly. Like Chrome Puppeteer, yes.
>> AMBER: And setting it up so it would basically say, “render this page.” Yes.
>> STEVE: Yes. I don’t know that it’s possible. I mean, it may be possible with some very clever hackery, right?
>> AMBER: [chuckles] Yes.
>> STEVE: But I think you would have to load maybe all of node. It would be very complicated.
>> AMBER: And we’re building a plugin that we don’t know what kind of server environment it’s going to be on.
>> STEVE: Yes, yes.
>> AMBER: Sometimes it’s on a really nice, managed host that has a lot of resources. It’s not a shared environment, and sometimes, it’s on a very inexpensive host that might have hundreds or thousands of websites on the same server.
>> STEVE: Right, right. Yes, different resources, and that’s been a huge challenge all along as well.
So that was fine, right? As the plugin progressed over the years, technology has been changing a little bit too, right? We now have CSS variables, and CSS variables present a whole new challenge to the plugin in scraping and evaluating styles.
>> AMBER: Because it has to figure out what the hex code is actually for. That’s why? For the variable?
>> STEVE: Right. Yes, and I think there’s always been a challenge of inheritance, like, with the way we’re doing things, because we’re essentially trying to assume what a rendered page looks like, right? We have a good set of rules that don’t require CSS evaluation, and those run really smooth, right? But we do have a set of rules that we have to know what the font size of something is, right? We need to know what…
>> AMBER: So like color contrast.
>> STEVE: Yes, color contrast.
>> AMBER: There are different rules for different size fonts.
>> STEVE: Yes, yes, so we were doing our best to assume what the rendered page looked like, and as CSS variables became popular and more heavily used, and with the block editor coming out and the block editor utilizing CSS variables itself that it injects on the page, the inheritance from variable to variable can be quite the algorithm to figure out what that end value of that style really should be.
So when evaluating for accessibility, the best thing to do is to evaluate the fully rendered page. Fully rendered as in the DOM’s rendered, styles are applied, and the JavaScript is all executed, and then you run your evaluation.
So I think what started happening is through our support channels, we start to get… Well, we think there’s some false positives, right?
>> AMBER: Yes.
>> STEVE: So that leads us to start saying, “Well, what do we do now?” “Do we build a Sass that evaluates these things?” But that’s a big undertaking, and the unique…
>> AMBER: Well, beyond that, you know, we had all these conversations of us being a background of WordPress developers, and do we have the knowledge in-house? Would we hire someone? Would we bring someone in? I’ve heard of companies where they hire a third-party company to build their thing, and then they just have to maintain it, and, like, what would that look like on an ongoing basis with the SaaS?
Although I think the other thing with the SaaS that I kept coming back to was, I wanted to have a meaningful free plugin, so if all of the scanning is happening on a server that we own, now there’s a cost to us every time somebody requests results. It might be tiny. It might be fractions of a penny, but that adds up, and I’m thinking, well, if someone’s working on a page and they’re scanning it 10 times, maybe, every time they change something or add a section or a lot, that could start to add up on a per-page, so then we’re, like, would we limit people? And then we’re starting to say, “Oh, you can…” Which we’ve seen that.
There’s another plugin in WordPress directory that does what ours does, but in their free version, you can only scan 20 pages or posts, and I am a realist and I know not everyone is going to be willing to pay for an accessibility tool. I hope someday that’s different. But a personal blog or a very small micro business that they’re just starting out and they don’t even know if they’re going to make any money, right? Or they’re, like, “Well, I make $20,000 a year off my website,” right? They’re probably not going to pay for that, and so I kept thinking, we need to still keep it in WordPress, and not have this extra cost where they have to pay, because I want at least a based website to be able to use our tool for free and make their stuff accessible.
>> STEVE: Yes. I think to that, too, like, it’s not just the cost and limiting the scans. The unique thing about the Accessibility Checker is that it does these things in near real time as you’re editing. If we’re to send stuff off to an API, we’re not going to be able to have as seamless of a real-time feedback as possible, because depending on our install count and how many people are hitting the API at a certain time, it could end up being queued for some time, and that’s how all the other ones work, to the best of my knowledge, right?
>> AMBER: Yes. The ones we have experienced with, like Monsido, Siteimprove, even Pope Tech, which uses the WAVE API, it’s just scheduled once a week, and then it queues through it, so depending on how large the website is, it might start on Tuesday and finish on Thursday, right?
>> STEVE: Yes, yes.
>> AMBER: But it’s just like a standard, “this is when this starts once a week.” There’s no real-time feedback, and you can do password-protected sites, but it can’t do, like, a draft, non-published post on… Right? Like, what we’re able to do is draft posts, which is helpful, I think.
>> STEVE: Yes, so those are some of the challenges that we were presented with, and then it’s, you know, so what do we do? So we came up with what we internally call JavaScript scanning, which is kind of just a generic term. But for us, we understand what the difference between our HTML scanning and our JavaScript scanning is.
>> AMBER: Our HTML scanning, PHP is what powers that, right?
>> STEVE: Yes. but when I say HTML, I mean, we’re parsing HTML. We’re using PHP to parse HTML. The HTML is what’s being evaluated, not the PHP. But the engine behind it is PHP on the HTML side.
So you might be right. We should call it PHP scanning, right?
[laughter]
>> AMBER: PHP scanning, right? And that uses, like, Action Scheduler, which originally came from the WooCommerce team. I think it’s maintained by Automatic Now, to sort of cue things and that. But we realized all these false positives, especially around color contrast, which was the one that we started to hear the most.
So you decided to start there, so tell me about how scanning changed.
>> STEVE: Yes, so we’re presented with a very difficult challenge of something that several people have told us is not even possible, and we’ve told ourselves that it wasn’t possible. [chuckles] And we’ve had a lot of debate back and forth, and we decided that for color contrast, right? So we bring up color contrast because that’s the rule that we’re presented with the most false positives, right?
Now, if there’s false positives, I guess there’s a case for a false negative, right? It’s not catching everything, right?
>> AMBER: Yes.
>> STEVE: So we have to render the page. We need a rendered page so that we can properly evaluate it, so what we came up with is what we call JavaScript scanning, so when a post is updated or published, we listen for our initial PHP scan, right? So that’s still there. All the other rules still run that same scan, and once that’s finished, it then kicks up our JavaScript scan, and it loads the WordPress preview page in the background, renders the page, then we inject a bunch of code into that page to run the evaluation.
So we’re not just running our own custom color-contrast rule here. We’ve actually integrated the Axe-core library in to take…
>> AMBER: Which is open source, so people who aren’t familiar with that, it’s an open source rule set from Deque.
>> STEVE: Yes, so that we can take advantage of all the time and knowledge that has gone into generating that color contrast rule.
Axe-core, it has kind of become a bit of a standard with accessibility checks, so I think bringing our stuff in line with theirs is a net positive for the plugin, so we actually inject the Axe-core library, we run the color contrast checks. We post the results back through the REST API, and we store those results the same as we would store our PHP scan results.
So there’s a lot of challenges that went into that. There’s a lot of, you know, permissions and performance and memory issues that go into doing something like that. I think in the free plugin, it’s not as much of an issue. But in the pro plugin, we have a feature where you can do a full site scan and you can scan the whole…
>> AMBER: Yes, scan everything. Yes, that you selected.
>> STEVE: Yes, so that presents a lot of challenges, because with PHP, if you’re parsing the HTML on the page, that’s a fairly quick and not resource-intense process to do for most websites, right? I mean, I guess if you had, like, the world’s longest one page website, it could take a little bit of time. But there’s definitely a drawback, right? Or there’s a give and take, right?
So with this JavaScript scan, we went from having several false positives, and now we’ve rerun it, and there’s, like, none, or very little.
>> AMBER: Yes. I have a screenshot on the blog post that I published about this release. It’s from one of our Higher Ed client websites, and they previously had 341,194 color contrast issues, and then on their staging site, right before we were ready for this release, we ran the beta on the staging site, with their permission, [chuckles] and it took that down from 341,000 to 367 color contrast issues, and I looked at most of them, not all, and they were all real. They were, like, orange and white.
So we went from having this massive amount of false positives on color contrast to the point that before we were doing this, we debated, “Do we just turn that rule off for them?” Because it’s so much noise in the background.
I think that as we’re trying to build a tool that’s super helpful for people, we don’t want to create noise. That’s not helpful for people.
I know that it took a lot of work on multiple people’s parts to make this release happen, and it seemed like it made a big difference, though.
>> STEVE: Yes. I think it was probably a six-month undertaking from our development team, and we had some sharp developer working on it, and a lot of credit goes to him for achieving this and seeing it through.
A proof of concept is kind of easy to work up, and we made it to a proof of concept real quick, within a couple weeks. But something like this, seeing it from proof of concept to something that’s production-ready was quite the task, because like I said, there are a lot of challenges in what we’re doing and the way we’re doing it, and when you’re rendering a full page, there’s a lot of memory issues to be aware of and to look out for.
So the color contrast, in a way, was a little bit of a, “Let’s test one rule, get it out there, see how it works.” Right? And so far, it’s working fairly well, right?
>> AMBER: Yes, because I know we’ve had these conversations about Axe-core, and I did spend a bunch of time going through, I think I shared it with you, a spreadsheet where I was mapping our rules to Axe-core to try and figure out how many of the custom rules that you and I spent a whole bunch of time creating multiple years ago… But I think [inaudible] created some of these before that open source project was even really published and talked about.
>> STEVE: Yes.
>> AMBER: But I mapped. I don’t remember the number, but I feel like maybe about 20 of our rules have an Axe rule that goes with it. Or that’s basically checking for the same type of thing, but how they’re checking might be slightly different than how we’re checking, and then there’s a large number of Axe rules that we don’t have, some of which I’m not certain we should put in, because I feel like they’ll just confuse our content creators, like a lot of the ARIA stuff or that stuff.
Then we also have rules that Axe doesn’t have. Another, like, 20 or whatever of our rules, axe doesn’t… Like, you wrote one that warns people about carousels that specifically looks for all these different WordPress carousel skips, because we’re trying to create something that works well for WordPress, so Axe isn’t necessarily looking for WordPress-specific things like we are.
So I’m curious. We haven’t really figured out what this timeline might be, which rules to switch. Do you think eventually, we’ll have all of them running on a rendered page? And how do we decide that? Have you thought about that?
>> STEVE: Yes. We’ve had some talk about it. We got this feature out and then kind of we pivoted to some refactor work and stuff like that.
>> AMBER: [inaudible]. You mean you’re completely building almost, like, version 2.0 of this plugin? [laughs]
>> STEVE: Yes, yes. Yes, we’re completely rewriting the whole plugin over and over again.
>> AMBER: I mean, because we’re working with newer WordPress coding standards, improving some things that WordPress VIP asked for.
>> STEVE: Sure. I think..
[crosstalk ]
Not to go too far down the rabbit hole, but as a piece of software grows and you bring more people in, more eyes see it, more people are suggesting certain things, and really, the more your install count goes up, the more important end-to-end testing becomes.
There are a lot of things that happen in the background to make software releases and launches go smooth and to allow a larger team to work on a code base, right? So that’s kind of been our pivot as of late.
>> AMBER: I’m going to do a little toast to our investor, Yoast, because he was really pivotable in a lot of that feedback, and someone on his team has helped you with some of the refactor.
>> STEVE: Yes, totally.
>> AMBER: Because you were saying, bringing more people in, I feel like it’s really good, and I know not everyone has the greatness of being able to have Yoast look at their code and give them feedback like we do. We’re pretty lucky on that front. But I think anyone, like, any plugin developer, even if you’re just solo small, but you’re able to just have anyone else, whether they’re super experienced or just at the same path in their career journey as you are, getting feedback on your code is probably really helpful, because I know it’s helped us a lot.
>> STEVE: Yes, it’s a great practice in humility.
[laughter]
>> AMBER: Oh, like, taking their feedback when they’re like, “No, this sucks. Rewrite it”?
[laughter]
>> STEVE: Yes, yes, basically, and like you said, we’re fortunate to have the consultation of somebody like Yoast, right? And Yoast is not going to sugarcoat it. He’s going to set us on the right path for success, and it’s going to be a wild ride, and you just got to grab the reins and go.
I think developers and tech leads, and stuff, a lot of times, we could put doors up, you know, we don’t want our stuff questioned and all this, and we really got to put that aside and take the constructive feedback, and just channel it and use it to make the product better. I think if you fight things like that, it’s probably going to just hurt you more in the end.
>> AMBER: Yes.
>> STEVE: So that consultation has been great, and users of the Accessibility Checker plugin are going to feel that when they install the plugin and it works, and it’s performant, and all that good stuff.
>> AMBER: Yes, so once this refactor is done, do you feel like we’re going to make more rules into JavaScript rules?
>> STEVE: Yes, I think so. Part of this feature was not just converting the color contrast over, but it was creating a framework in which we could easily convert rules to JavaScript scanning, so in our code, we actually basically just have one parameter. We just change it from PHP, you know, just a parameter that’s defined as PHP or JS for JavaScript, and that converts that rule over to a JavaScript scan.
Now there’s a little more involved with utilizing the correct… Aligning… Like Amber said, she made that spreadsheet, aligning the Axe rules to our rules. Axe’s rules can be like… I’m not 100% sure on the terminology, but it’s like a rule, and then there’s checks within a rule? It might be the other way around.
>> AMBER: Yes.
>> STEVE: So aligning the right one up, and also, having an architecture for us to write our own JavaScript rules alongside these Axe rules.
>> AMBER: Yes. I’ll say that’s been the biggest thing that I’ve been nervous about, and this is kind of like a build in public, so I’m literally going to say, we’re still doing work for clients, and that’s how we make most of our money. We make money on the plugin, but not enough to support a whole giant team, right?
Currently, I’m the person who writes all the documentation, and so I know you were, like, oh, it’d be easy for me to convert all these rules. Now that I have the framework, I could just be, like, “Use this Axe rule, use this Axe rule, use this Axe rule.” But I’m, like, “But, wait a minute. I got to have a documentation post on our website that explains, or I even have to go back and update,” which I do have a to-do, and I did do one this week.
I noticed that all of our screenshots and our documentation that show examples of theirs, they don’t show that you can view it on the front of the page, because I haven’t updated the screen, so it’s this weird thing I’m trying to figure out, which is how do we roll stuff out that, tyone, we have time to do, knowing that there’s one person who does it who also has to do a whole bunch of other things, right?
>> STEVE: Yes, yes.
>> AMBER: And also any new Axe rules. I’m very cognizant of the fact that sometimes people find our plugin overwhelming as it is with the 40-plus checks we have, and I’ve seen other plugins be, like, “We have the most checks of every plugin.” And I’m, like, “But I don’t necessarily think that’s the best thing.” And we’ve even had some of those conversations with some of the bigger… Like, Stephen Walker from the VA. They have licenses of our plugin, which is super cool.
>> STEVE: Yes.
>> AMBER: But we’ve had those conversations with him about, you know, “What is this like for the average content creator?” And maybe at some point, we’re going to have to be, like, maybe you can set on each rule and say, “I want this user rule to see this rule.” And this other user rule won’t see it, and it just won’t even show up in their report, like, it’ll be hidden.
I’m nervous about suddenly just being, like, “Oh, the Axe rules.” [chuckles]
>> STEVE: Yes, it’d be a lot. It’d be a lot.
>> AMBER: Yes.
>> STEVE: So that’s definitely a challenge. From a technical standpoint, I think that the work that we’ve put into the performance and memory allocation for such a render inside of WordPress, I think we’re taking the hit, right? We’re taking the performance hit. The evaluations aren’t much of a hit. You know what I mean? We’re rendering the page, and then I think to run all of our rules as JavaScript rules are not really going to affect the performance all that much, and then that would allow us to remove the PHP checks altogether, so we’re just running everything through what we call JavaScript scanning. Yes.
>> AMBER: I won’t do the thing developers love where I’m, like, “How much time will that take you? Give me a deadline.” [laughs]
>> STEVE: Yes. Yes. It’ll take a lot of time.
>> AMBER: Yes, yes, yes. [laughs] I’m curious. This is not in our notes. You know, I love to surprise Steve. [laughs]
>> STEVE: Yes. Thanks. [laughs]
>> AMBER: We did a lot of testing in different environments and those sorts of things. But it gets released, and then you hear back from all the people that have random plugins or random themes, or things that we realistically couldn’t possibly test with all of these things.
>> STEVE: Yes.
>> AMBER: And one of the things that I’ve noticed, particularly more in the pro version when it’s doing a full site scan, is that when we render the page, if that page has a ton of JavaScript, like, console errors already – not from our thing, but some other plugin or their theme, or something is, like, breaking a bunch on the front-end – that sometimes, it can make it harder for Accessibility Checker to render that page.
Is there anything we can do about that? Or do we almost need to have a warning that notifies people, “When we rendered your page, we noticed all these errors. You might want to investigate.” [chuckles]
>> STEVE: Yes, yes.
>> AMBER: Like, I don’t know.
>> STEVE: I think that’s all part of WordPress and WordPress plugin development, right?
>> AMBER: Yes.
>> STEVE: Moving over to utilizing the REST API to move this data back and forth and to utilizing the Axe-core JavaScript library to evaluate these scans, right? You know, we were using Ajax before, so this kind of still mattered before, right? But if there are console errors and other errors from other plugins or from your theme that are causing errors, there’s a high potential that it could block it from working at all.
>> AMBER: So that’s, like, the biggest thing that we still get, right, is the notice?
>> STEVE: Authentication. Yes.
>> AMBER: Sometimes, it can’t scan at all, and there’s been weird things, like someone has their SSL certificate misconfigured, and so then the plugin will flag that?
>> STEVE: Yes. Or they don’t have the correct PHP library.
>> AMBER: Yes.
>> STEVE: That is a huge challenge of doing what we’re doing inside of WordPress. The unknown. The unknown of what server environment we’re running in, right? And what their PHP setup is, what PHP extensions are installed, even what version of WordPress they’re running, right?
The Accessibility Checker supports the last three major versions. But even in that, sometimes people are running four or five versions back, right? And if the support comes in, we’ll still try to do our best to help with that. But I don’t know that we’ve ever hid it where we’re, like, “No, we don’t support that.” We’ve never been that strict.
>> AMBER: No. We’ve tried really hard to try and make things work for people.
>> STEVE: So to that, if you have console errors, and if specifically, these errors are blocking Ajax, or they’re blocking the REST API from working, obviously, this is not going to work, right? The plugin is not going to work, and obviously, any other plugin that requires the REST API or Ajax is going to have a problem, too.
Where it gets a little weird is that if you’ve got a lot of warnings on the page, or you got some errors on the page that aren’t actually breaking errors, they’re not going to…
>> AMBER: Do you mean like console errors and warnings?
[crosstalk ]
>> STEVE: So if we’re going through and we’re rendering the page, there can be a build-up. There can be a memory build-up from all of those errors, because they’re being regenerated over and over and over and over.
>> AMBER: Because you render a page in the full-size scan. You render a page, scan it, save information. Well, I think there’s, like, a pause, right?
>> STEVE: Yes, yes.
>> AMBER: I remember you all built a pause in, and we’ve had a conversation [inaudible] that just got released that we might have a filter where people can change the pause?
>> STEVE: It’s not released.
>> AMBER: Oh, OK, so that is coming, though, because as we figured out on very low resource servers, people might need to make that pause longer, so it pauses, then it renders the page, and does it all over again in like a loop. But that won’t clear out the console errors [inaudible]
>> STEVE: Yes, so there’s a polling that’s going on, and I believe the default is three seconds that we’re polling, right? So we’re polling a page. We actually check, you know, there’s a lot. I mean, it’s pretty advanced. Like we’re checking that the last page is complete, and then when the polling runs, it’ll grab a new page if it’s ready to go.
>> AMBER: Because we don’t want to overload someone’s server. That’s the idea behind that. Yes.
>> STEVE: Yes, and that’s the key thing, where the PHP rules will run a lot faster, because we’re not rendering a page, and we’re doing one Git file to grab all the HTML, and once we have the HTML, we can just jam that through all the rules. We can jam that through all the rules. We don’t have to grab it every time. You know what I mean? We don’t have to parse the HTML every time.
With the JavaScript, we got to roll the page up every time so that we can see what it looks like and evaluate it, so what happens in a browser environment is, if you have a lot of errors or warnings or even deprecation warnings in your console, they can build up in your browser memory over time, so we’ve had to do a lot to be mindful of that, like, in our polling timing.
In Chromium browsers, we can actually get access to how much memory utilization there is, and if that gets too high, then we can enact a page refresh.
>> AMBER: You force a refresh?
>> STEVE: Yes, so these are big challenges and they require some out-of-the-box thinking and solutions.
>> AMBER: Yes. Well, I appreciate that you all were able to come up with the out-of-the-box thinking for that, because as someone who’s not on the code side but is on the idea side, it’s so easy to be, like, “Just do this thing.” [chuckles]
>> STEVE: Yes, yes. [chuckles].
>> AMBER: So I appreciate that you’re able to make it work, because I really do feel like, as much as we can, having some baseline of the plugin that does not require a SaaS connection is really important. But I do feel like there’s going to be a time when we’re going to have to revisit that SaaS, especially as we see these larger government, university, super enterprise businesses start to use the plugin.
We probably will, I think, end up needing to do some sort of offsite scanning and maybe even storage of data, so that it’s not in the WordPress database.
>> STEVE: Yes. Probably in the pro version of our plugin is where it’ll eventually mature too.
>> AMBER: Yes. I don’t want anyone who’s listening that has pro to think, “Oh, man, in the future, I’m going to be forced to pay for every scan.”
[laughter]
That’s not the intention at all, and I don’t think that’s what we’re trying to get at, and you can tell me if you see it differently, but the way I see it, there might end up being some sort of limit, like, “We can only store a million records,” or whatever that might be, right? Some number, and then you could either, in pro, go up to that limit, and at that point, be like, “OK, well I’ve hit my limit, but fine. However many accessibility problems on these many pages that I can fix, and then I can scan the rest or something.” Or you could then just say, “I want to toggle on the API,” like, do it optionally, right?
>> STEVE: Yes, yes.
>> AMBER: That’s what I’m hoping, that there’ll be some options, so there is still something for those people that are, like, “I really can only pay…” What, $144 a year, it’s slightly more than $10 a month? Right?
>> STEVE: Yes.
>> AMBER: Like, “That’s all my budget is.” Because I get worried about when we limit it. Those SaaS’s are cool, but a lot of them start at, like, $10,000, $25,000. I’ve seen university contracts where they’re paying about $100,000 a year for the software, and small businesses aren’t going to do that. They’re not.
>> STEVE: Yes, and when you talk about moving the needle when it comes to accessibility, I really think that the individual user has a huge responsibility, in that if we can make accessibility easy and presentable to them right there when they’re making their pages, that’s it’s going to go miles for accessibility as a whole, especially in a platform like WordPress that’s half the internet. It’s crazy, and like you said, access to accessibility tools is important for everybody.
>> AMBER: Yes. Not just people with big budgets.
>> STEVE: Yes.
>> AMBER: Yes, so we only have a few minutes left, but I’m curious, can we tease anything that might be coming in Accessibility Checker? Anything we’ve been talking about?
>> STEVE: I mean, that’s really putting me on the spot, [laughter] because we are heavily…
>> AMBER: Isn’t that my job? [laughs]
>> STEVE: Yes. We are heavily in, you know, a lot of refactor and stuff for better performance and security and all kinds of things like that. All the good software development stuff. We’ve been there for a few months now, right?
>> AMBER: Yes. Probably have a few more left.
>> STEVE: Though Amber’s itching to get back to the roadmap and get some features pushed through.
>> AMBER: Yes, some of them are waiting on me, I will totally admit. But we’ve talked about redoing our setting screens and…
>> STEVE: Onboarding wizard and setting screen and…
>> AMBER: So I need to do some wireframing for you.
>> STEVE: Yes. We would like to bring some fixes into Accessibility Checker. We would like to help, not just evaluate your code, but we would like to help you fix things in an automated way.
>> AMBER: Yes, where we can do it the right way.
>> STEVE: Where we can do it the right way, yes.
>> AMBER: So we’ll see.
>> STEVE: Yes, so we’ll get back to that roadmap and make Amber real happy with some nice, shiny new features coming to you soon.
>> AMBER: Yes. For everyone who’s listening, what I love to do is, I pick a date and I’m, like, “Hey, we’re sponsoring WordCamp EU,” which we are, by the way, if you’re listening and you’re going to be there, we will be there. Come say hi to us.
That’s your first international trip, Steve?
>> STEVE: Yes. Believe it or not, I haven’t really ventured too far out of the United States before, so.
>> AMBER: Yes, Chris also has never been to Europe. I have been to a tiny part of Italy just over the border from France. When I was in college and I was studying in France, I rode the train to Italy to get lunch one day. [chuckles]
>> STEVE: There you go. [laughs]
>> AMBER: Yes, so we will be there. But what I sometimes do is I’m all, like, “Can we have this feature before WordCamp EU, WordCamp US?” Like, that’s the timeline, because I’m, like, wouldn’t it be cool to be there and be, like, “Look at this new fancy things our plugin can do”?
>> STEVE: Yes. She likes to kill us before we go on a big trip where we got to speak and all kinds of stuff. [laughter] And quite frankly, we got to launch the feature while we’re there, right? Which is always lovely.
>> AMBER: Yes. Or it’ll be released. I know that was WordCamp US that got released. We were there before the event, and you released it, and I know that we were all a little bit nervous, because we’re, like, “What happens if a lot of support comes in?” But luckily, not all of our dev team was there, so we had our support devs who were still up.
>> STEVE: We had somebody back at home making bug fixes while we were…
[laughter]
>> AMBER: Yes. Hopefully, there’s not too many bugs, because we got a pretty solid process for testing and all that now.
>> STEVE: Totally.
>> AMBER: Yes. Well, this has been fun. I’m not totally sure. I might have to go have Chris try this and give me his verdict on the mango michelada.
>> STEVE: I can’t even pick it up. It’s so heavy.
>> AMBER: They are big cans. It’s fruit juice, though. Maybe it has vitamins in it. [chuckles]
>> STEVE: Maybe. [laughs]
>> AMBER: So are you on the you-would-never-buy-it-again camp?
>> STEVE: Oh, yes. I didn’t like it. I didn’t like it. [laughs] Or what would I normally say: “That’s gross.” Yes.
[laughter]
>> AMBER: Oh, that’s a T-shirt I got to add to our shop. “That’s nasty.”
>> STEVE: “That’s nasty.” That’s what it was. That’s nasty.
>> AMBER: So that’s what you say. [laughs]
>> STEVE: Yes. I mean, it’s not nasty, but it doesn’t taste like beer at all. I feel like I’m drinking a V8 with some chili powder in it or something. [laughs]
>> AMBER: And fizz?
>> STEVE: Fizz, yes. [inaudible]
>> AMBER: Carbonation? Yes.
>> STEVE: You know, we didn’t mention that.
>> AMBER: Yes, it doesn’t really have a beer flavor.
>> STEVE: Yes.
>> AMBER: But I think I’d like the fresh made ones better, but I’d be interested to try the non-mango. Like I’m kind of interested.
>> STEVE: Yes. Yes. Cool.
>> AMBER: All right.
>> STEVE: All right.
>> AMBER: Well, thanks for hanging out. We’ll be back in two weeks.
>> STEVE: All right. See you guys.
>> CHRIS: Thanks for listening to “Accessibility Craft.” If you enjoyed this episode, please subscribe in your podcast app to get notified when future episodes release. You can find “Accessibility Craft” on Apple Podcasts, Google Podcasts, Spotify, and more, and if building accessibility awareness is important to you, please consider rating “Accessibility Craft” five stars on Apple Podcasts
“Accessibility Craft” is produced by Equalize Digital, and hosted by Amber Hinds, Chris Hinds, and Steve Jones.
Steve Jones composed our theme music.
Learn how we help make thousands of WordPress websites more accessible at “EqualizeDigital.com.”