Listen
In this episode, Amber, Steve, and new Equalize Digital team member and Senior Plugin Developer Matt, discuss Accessibility Checker’s new front-end highlighting feature, why we built it, and the future adjustments we’re working on.
Mentioned in This Episode
Transcript
>> CHRIS HINDS: Welcome to episode 28 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, Steve, and new Equalized Digital team member and senior plugin developer, Matt, discuss Accessibility Checker’s new Front End Highlighting feature, why we built it, and the future adjustments we’re working on.
For show notes and a full transcript, go to “AccessibilityCraft.com/028”
Now on to the show.
>> AMBER HINDS: Hey, everybody, it’s Amber, and today I am here with Steve.
>> STEVE JONES: Hello, everyone.
>> AMBER: And I’m also super excited that we have a new guest on the podcast, but not necessarily a new guest, newer member of the Equals Digital team.
>> MATT BOONE: Hey, guys.
>> AMBER: Welcome, Matt.
>> MATT: Absolute first podcast ever.
>> AMBER: Yes. Do you want to introduce yourself a little bit?
>> MATT: Sure. I’m Matt Boone. I am a developer. I write software, PHP, JavaScript, all kinds of good stuff. I’ve been doing this for 25 some odd years, and love getting to work with these guys.
>> AMBER: Yes, and you are our lead plugin dev, making all the magic happen with Steve.
So what are we drinking today, Steve?
>> STEVE: So we have a beer sour today by a company called Owl Farm. I’m reading the can here because the website doesn’t have a whole lot of information, but it’s a unique fermentation. It’s called Big Berry Imperial Fruit Sour. A lot of times they put funny things on these cans, but this one seems to be pretty straightforward to the point.
>> AMBER: I mean, I like the label. I think it’s cute. It’s like a basket of berries with legs and arms, and it’s carrying another basket of berries, and it’s like blueberries and raspberries.
>> STEVE: Yes.
>> AMBER: And it has feet and hands.
>> STEVE: But the basket is like its head/body. [laughs]
>> AMBER: Yes, so I don’t know. It’s cute, and it’s pink. I like pink.
>> STEVE: Yes. Is that pink?
>> AMBER: It says it’s got black currant, vanilla, blueberry, and raspberry. It’s kind of a reddish pink, I guess. I don’t know. I think it’s pink.
>> STEVE: Yes. It says, “An imperial fruited kettle sour ale brewed with raspberries black currants, blueberries, and vanilla beans.”
>> AMBER: Yes, and this is a 9%, so we’re going to have a fun podcast episode. [laughs]
>> MATT: No work done this afternoon.
>> STEVE: That’s right. Taking off early.
>> AMBER: It’s Friday afternoon. Pretty sure I hit 40 hours yesterday, so I deserve my beer. Thank you. [laughs]
>> STEVE: It does say on the can that these normally have around a 5%, and are soured for a day to achieve moderate acidity. “This release boasts a 9% ABV and has undergone an extended souring period for a bolder tart flavor.”
>> AMBER: All right, so should we open it and figure out how sour it is?
>> STEVE: Yes, let’s do it.
>> AMBER: All right. I like to do it right in front of the microphone just for fun.
[laughter]
>> MATT: Yes.
>> STEVE: Sip.
>> AMBER: Ooh, I like that.
>> STEVE: It’s definitely sour.
>> AMBER: What do you think?
>> MATT: I’m pouring into the glass.
>> AMBER: All right, Matt’s pouring it into a glass, so you’ll have to show it to us.
>> STEVE: Yes, we like that.
>> AMBER: You can describe it, too, for people, since we don’t share our, “Oh, it’s darker than I thought it would be.”
>> MATT: Yes. It’s gorgeous. That’s really pretty.
>> STEVE: So what color would you say it is, Matt?
>> MATT: It looks kind of like like cranberry juice.
>> STEVE: Is it purplish?
>> MATT: Yes.
>> AMBER: It is. It’s like a burgundy purple.
>> MATT: Yes.
>> AMBER: How cloudy does it look to you?
>> MATT: You know what? It doesn’t look that…
>> AMBER: Like the fruit?
>> MATT: It doesn’t look that cloudy. We’ve got some effervescent in there, but it’s not…
>> STEVE: It’s got a decent head on it?
>> MATT: Yes. It’s not very thick.
>> AMBER: Yes, and it doesn’t look foamy, right? Yes.
>> MATT: Yes. It smells great. All right, I’m going in.
>> STEVE: It’s pretty good. On first taste, it kind of hits you hard, but it finishes pretty smooth. Like, it doesn’t seem to stay too strong.
>> AMBER: I kind of think… Hold on.
>> MATT: A lot of cherry in there, right?
>> STEVE: Raspberry? Is it raspberry you’re tasting?
>> AMBER: I think that’s the currants.
>> MATT: OK, yes.
>> STEVE: So explain the BlackBerry currants. That’s a fruit?
>> AMBER: Currant is a fruit. Is it related to cranberries? I think they look the same.
>> MATT: They’re really small.
>> STEVE: They look like blueberries, kind of, or grapes.
>> AMBER: Yes, they’re small berries AGGRAND shrubs, and are more like gooseberries, says Google. Thank you, Google. [laughs] But I think they’re kind of bitter, and honestly, that’s what I’m getting, and part of me was, like, for me, on the finish, it leaves sort of a bitter, more than a tart, left in my mouth. I don’t know. Are you guys getting that?
>> MATT: This reminds me of, like, a homemade cranberry relish for Thanksgiving.
>> STEVE: Oh.
>> AMBER: Yes. It really does kind of have a cranberry flavor, even though it says there’s no.., but I think it’s coming from the currants.
>> MATT: Yes, the currant.
>> STEVE: Hmm. I normally stay away from the cranberries at Thanksgiving. Maybe I should try it.
>> AMBER: Really?
>> STEVE: Yes. [laughs]
>> AMBER: Oh, man. That’s one of my favorite parts of Thanksgiving. Why don’t you like cranberries, Steve?
>> STEVE: I don’t know. There’s turkey.
[laughter]
>> AMBER: Well, some people put their cranberries on top of their turkey.
>> MATT: Yes, Yes.
>> STEVE: Those are people that don’t like turkey. [laughs]
>> AMBER: You’re a gravy guy.
>> STEVE: I’m a turkey purist. That’s what I’m trying to say.
>> AMBER: No gravy, either, on your turkey?
>> STEVE: No. No.
>> MATT: Have you ever had, like, the next day sandwich? You slice your turkey, you put it on the sandwich, and then you take the cranberry relish and smear it all over the inside of that sandwich. It’s the best.
>> AMBER: I’m a vegetarian and I think that sounds disgusting.
[laughter]
However –
>> STEVE: Just minus the turkey.
>> AMBER: – My children… Yes. I would eat a cranberry sauce sandwich.
>> STEVE: With a piece of cauliflower on it or something, right?
[laughter]
>> AMBER: I mean, I don’t know. Here’s a question: Would green bee casserole be good the next day on a roll?
>> STEVE: A little mushy? I don’t know.
>> AMBER: Yes. Chris does that, and Nora, our oldest, does that. They put stuffing on it too, and I’m always, like, “Why are you putting bread on your bread?” [laughs]
>> MATT: Yes.
>> STEVE: This is definitely really good. I like it. I like the sours. We should do more sours.
>> AMBER: Yes. I like sours. I don’t think this sour is as fruity as some other sours that I’ve had.
>> STEVE: Like, sweet? Is that what you mean by… Yes.
>> AMBER: Yes. Well, I mean, it’s not that I expect them to be, like, sweet. I think it’s the finish for me. I think this has more of a bitter finish at the end.
>> STEVE: Yes, it does. It’s kind of dry, but I kind of like that. I don’t know.
>> AMBER: Yes.
>> MATT: I’m a fan.
>> AMBER: Would you get it again?
>> STEVE: Yes. I’ve got two of them in the fridge, so, like, we have to crack the other one.
>> AMBER: Yes. We can talk about how we were supposed to record this episode, like, three weeks ago [chuckles], and Craft City, by the way, that’s who we get the ships alcohol, I think they probably find us annoying because we order three cans, all going to separate places. [laughs] Well, they shipped them all to me, and then Chris messaged them and said, “Hey, they’re supposed to go here.” So it took forever, but I guess they made up for it. They said that they would send you guys extra. You got extra?
>> STEVE: Yes, I just got a couple.
>> AMBER: Well, that’s nice.
>> STEVE: But sometimes when we do pops and stuff, we get a whole case of them. [laughs]
>> AMBER: Yes, it’s because Chris can’t get one pop, so he ends up having to buy like twelve or six or something. I know.
>> STEVE: No, this is good.
>> AMBER: And then it’s like our kids are drinking them. [laughs] “You got to save them.”
>> STEVE: The pops, that is.
>> AMBER: Yes, the pops. Yes, yes, yes.
>> STEVE: So on the Owl Farm unique fermentations website, which is “OwlFarmBeer.com,” they’ve got other flavors, and they’ve got really cool art to go with each one of them. You Know, like Amber said, this one’s got like a basket of berries with legs and arms.
>> AMBER: Oh, man.
>> STEVE: Do you see them? They look pretty cool.
>> AMBER: Yes, I just went and looked, so there’s, like, a grape that looks like a…
>> STEVE: Cowgirl?
>> AMBER: A cowboy? Well, I thought cowgirl because of the way it’s standing [inaudible]…
>> STEVE: Oh, there’s a mustache.
>> AMBER: It has a mustache so I think it’s a cowboy with a pistol. The watermelon with the shaker, I got to find that. If that’s, like, a chili watermelon or something.
>> STEVE: And it’s shaking the chili or whatever that is on top of its head. [laughs]
>> MATT: Is that a cucumber there in the second one? Yes.
>> AMBER: A watermelon coriander and tajin. Do you guys do much tajin, or is that just a Texas thing?
>> STEVE: I don’t even know what that is, so this is the Midwestern guy talking here. North Midwestern. What is that?
>> AMBER: So tajin, T-A-J-I-N, and there’s, like, an accent that I don’t know what it’s called on the eye. It’s a Mexican, like, chili lime salt that really tastes like lime, so it looks like they have that both with the watermelon and the cucumber.
Our kids eat cucumbers with tajin on them.
>> STEVE: Really?
>> AMBER: I mean, they’ll put it on a lot of things, but they like to eat cucumbers with tajin because one of our kids’ friends, her family is all Mexican, and she went to their house and got introduced, and she’s, like, “You have to go buy this at the store.” And now it’s like they’re all addicted to it.
Do you have it where you live, Matt?
>> MATT: Yes, we do. We make Micheladas, which is basically, you use a Mexican beer and then maybe some tomato and ice and, like, a little bit of Worcestershire, and put tajin on the lip, and it’s incredibly refreshing.
>> AMBER: It’s like having a Bloody Mary, only with beer instead of…
>> MATT: Yes. Yes.
>> AMBER: Yes. That’s a neat idea. I kind of want to try that.
>> MATT: They’re great. Go cut the grass, and then have a Michelada. It’s great.
[laughter]
>> AMBER: Maybe we’ll see if we can find one of those for a future podcast, and we can talk about whether it’s as good as when you make it yourself or not.
>> STEVE: Yes, we’re definitely going to have to try some more of these. These look really good. Like, the watermelon tajin, cucumber tajin, mango tajin. Yes, these look good.
>> AMBER: All right. Yes, so I definitely think everyone should go check out Owl Farm. They’re neat. They’re in California, but you can find it on Craft City, in the US anyway. I don’t know if you can find it outside the US.
So today we invited Matt on because I wanted to chat about a feature that we released somewhat recently in our plugin, Equalize Digital Accessibility Checker, and we’ve kind of internally called it Front-end Highlighting. I know you started it, Steve, and then Matt finished it up when he came on board, and you guys work collaboratively, but do you want to describe what that feature does? And then we can talk about why we did it, and some challenges, and that kind of stuff.
>> STEVE: Yes, so if you’ve used the Accessibility Checker, you may know this. Before this release, you would scan your page and you would get your issues listed below your post in the post-edit screen, and then we would present them with a code snippet of the problem, and then Maybe six months or a year ago, we released an image field where if that code snippet included an image, we would show that image to you, and that was in an effort to simplify and demystify the problem. We understand that the plugin is not only made for developers, but it’s also made for content creators, and to present a content creator with a big chunk of code is kind of like just foreign to them. They don’t really know what to do or where to go to solve that problem, or even to identify what the actual problem is.
Now, as code nerds, like me and Matt and Amber, we can kind of deduce from that code snippet where the problem is and what it is, and we can view the source on the front-end and kind of get to it, right, we can find it.
>> AMBER: Sometimes that’s even hard.
>> STEVE: Yes.
>> AMBER: You know, what was always challenging for me was empty headings, because it’s just like, “Here’s an h2 with nothing in it.” So on the front, that’s just like a space, so usually what I would end up having to do is going to the front-end of the website, clicking “view source,” not even to, like, Inspect, so View Source, it would open all the HTML in a different tab, and then I would do a command F –
>> STEVE: Find and replace.
>> AMBER: – And search for an empty heading tag, and then I’d have to read what was around it to try…
In the block editor, it’s a little easier because you could look in the navigation and do it, but this would happen sometimes like on a Beaver Builder website and I’m, like, I’m not as familiar with a Beaver Builder Editor or that kind of stuff, so those were hard to find. I was, like, we really just need something to be, like, “Here’s this empty space,” and put a box around.
>> STEVE: So in an effort to advance the plugin and to help users identify issues on their site regardless of their technical ability, we decided to come up with this feature called Front End Highlighting, where on the back-end you have a new button now that says, “View on Page,” and you click that button and it jumps over to the front-end page, scrolls to the element, puts a highlight around it. I think we use like a pinkish magenta highlight around it. There’s a button, and then there’s a pop-up that has the error and describes the error, the same that you would have in the back-end.
If you want to look at the nerdy code, you can still do that from the front-end. You could hit the “show code” button, or you can click over to our full-fledged documentation on our website. From there, that gives you a visual reference to where the issue is. It highlights it, it shows it. It’s very easy to identify where the issue is.
Now, there are more tools built into this on the front-end. You could do that just one at a time, from the back-end to the front end to see where your issues are, but from the front-end, you can actually initiate the Front End Highlighting overlay, and you can then just page through your errors on the page, so all of them from the front-end without even having to go to the back-end, and you can get all the information you need to help identify those accessibility errors to help you better remedy them and fix them.
One thing with our plugin that may be a little more unique than some is the way that we parse the HTML of the page and we scan and we try to run our rules to intelligently identify the issues on the page. There are times where an element may be hard for us to find on the front-end, again, after we’ve identified the issue, and there can be many reasons for that. It could be that it’s dynamic and it changes, and that would actually, in the back end, probably keep reintroducing new issues, but it could also be that…
>> AMBER: Because we’re not currently looking at JavaScript.
>> STEVE: Right, and this would still be a challenge even if we were. Just based on the fact that elements on a website can be hidden. They can be off the page, they can be inside of a div with an overflow hidden on them, they could be in a navigation that’s currently closed, so there’s so many variables to consider when you’re looking at a website where an element can be on the page. It can be any number of things.
So we added a feature in there to disable styles. I don’t want to speak too out of term, but I haven’t seen a lot of WordPress accessibility scanning plugins that actually allow you to disable all the styles on your page, but this is a feature that is common in plugins like Wave, where you can initiate Wave from the Wave plugin in your browser and then you can turn styles off.
So I thought that bringing that feature to this would be great, so when you page through and you hit an element that is hidden, and a lot of times it’s, like, on elements that have an “Aria hidden” or a “display none” on them, the plugin will tell you that the element is not visible, try disabling styles, and a lot of times if you disable the styles, all your CSS on the page gets removed, and then we highlight that element.
A big use case for this is navigation, like mobile navigation, so a lot of times on a mobile, you size down the browser, and your navigation has a hamburger menu and it has, like, a “close” button, right? And a lot of times, those are hidden on the desktop, so you can’t see them, but once you disable styles, there they are, you can see them. You get the magenta highlight around it, you get the button with the description, and so we’re doing everything that we can to try to present these issues visually to the user so that they don’t have to have coding knowledge.
>> AMBER: Yes, so I know one thing that we worked on quite a bit, and we actually had one of our testers who does testing for our clients who blind also test the plugin because we thought it was really important that even though this is a “visual tool,” we want to make sure that all parts of it are as accessible as they can be.
Matt, you did some work on sort of managing focus on the front-end for screen-reader users, right?
>> MATT: Yes. Being able to tab into the focuses and then stay within that focus so that somebody that’s visually impaired doesn’t get lost in tabs in and out.
>> AMBER: Hold on for a second. Let me describe just for someone who hasn’t seen it. We have an button, and it is an actual button, which is actually first in the Dom, and I’ve had some thoughts about this. It’s first in the Dom, but it actually visually shows up in the bottom right corner when you’re on the front-end, so for a screen-reader user, if they’re going through the front, it’s only visible if you’re logged in. It’s not public on the website.
>> STEVE: And the post type is enabled.
>> AMBER: And the post type is enabled. They would get to that, and it’s a button that they can trigger, and then what that does is it opens a modal, basically. It would count as a modal, right? It would dialog.
>> STEVE: Yes, I think so.
>> AMBER: For accessibility checker, that says how many errors and warnings there are, and then it has “next” and “previous” buttons to allow you to go through them, and then as you’re going through them, it opens up a secondary modal for each individual issue that has information about it.
So this is what you were talking about, like, controlling the focus and stuff, Matt?
>> MATT: Yes. As a sighted user, we kind of worked to figure out what we thought would make the most sense with locking those focuses, so I worked with Steve. We put a set of rules in. You took a look at it and said, well, “Maybe it makes more sense to do it this way.” So we kind of set it up around that flow, but then we had a blind user take a look at it and he said, “We’ll, yes, this works, but here’s where it’s confusing.” So it’s really cool to be able to look at our tool through the eyes of someone that doesn’t look at it the same way that we look at it, so it was a really valuable experience for me to watch his process and to understand kind of regardless of how hard we tried to set up a flow that made the most sense to us, he was able to explain, “We’ll, here’s a way to improve it.” So it was fascinating. I’m really excited to go through that and re-implement some pieces to match what he identified.
>> AMBER: Yes. I think that just highlights, for all of our listeners, how important user testing is. I do accessibility testing almost every single day now as part of my job role. Whether it’s actually not always for a client, but I write content, I do other things. Sometimes I have plugin developers who ask me for that, or I’m looking at something that is part of the Core WordPress project, so I’m doing it all the time, but even I, the flow that I thought up, it worked, but it could be better, and so that’s where I think we always need to try and include people with disabilities, like, actual people who use the technology every day in our testing. It’s so important.
>> STEVE: Yes. I think this underlines being about what we’re about, right? It’s that we’re creating a plugin that tests websites for accessibility, but our plugin itself should be accessible, right?
I think in hindsight, the way we have it set up, like, Amber stated that we have, like, two modals, which I think just the initial way I designed it, and I’m sure after we got further into it, and Matt came on board, and he’s probably, like, “Steve, you should have made this one modal.”
[laughter]
>> AMBER: Well, let’s just all give a shout out to Steve, the developer at CTO, who is able to design things, [laughter] because you designed something. Probably at a lot of other companies, there’s someone else who’s, like, a UX person or a UI person that’s, like, “Here is your figma file. You go build it.” And we’re running very small. We’re a tiny team, and so we’re frequently, like, “Here’s an idea. Can you build it?”
>> STEVE: So it just doesn’t happen, right? Like, I’m a developer that actually has a college degree in graphic design, which is weird, right? I did things backwards, and I just want to kind of echo what Matt was saying about seeing a user that’s blind use the plugin and how that shifts a developer’s paradigm about what they’re doing.
Matt’s new to the team, and I think accessibility has definitely been part of his world, but now it is his world.
[laughter]
>> MATT: It’s a different world. Yes. Because it was an afterthought in most dev shops, and now it’s on the forefront, as it should be.
>> STEVE: Yes, totally. You know, I had the same. Years ago, we did a client for a large government entity, and I think it may have been the first time we used user testers, right, Amber?
>> AMBER: Yes, when we did for the Workforce. Solutions website, that was the first time, yes.
>> STEVE: And fortunately for me, we’re a remote team, so we’re all kind of scattered out throughout the United States and outside of the United States, too, but fortunately for me, Amber and Chris videotaped the user testing, and it wasn’t just a screen recording.
>> AMBER: Yes. Back then, we had an office here that we had a couple of employees in, because we weren’t all as distributed then as we were, and so they came into our office. Now when we do user testing, we just do it over Zoom. But, yes, they came into our office and we set up cameras so you could see, over their shoulder, what they were doing, so you could also see their hands, which was kind of cool, because you could see some of the keyboard interactions that they were using.
>> STEVE: Yes, totally. Just to see them, just to see it, it definitely changes your whole paradigm, your whole thinking around development, and it definitely shifts the importance of it a lot, so I just wanted to echo what Matt said.
I would advise any development team that they can to start integrating some kind of those actual real life user tests into their dev process.
>> AMBER: Yes, so let’s talk about some of the challenges that we encountered. I know you sort of started to get into it, Steve, with talking about items that are in a navigation menu, and what we haven’t said yet is that we actually were able to build this with some funding from NASA, because we are the accessibility team on the new NASA website, which recently they launched in public beta mode. You can go check it out at “Beta.NASA.gov.” Little pitch for NASA, I guess, and they’re using Accessibility Checker, and they gave us some feedback and they’re, like, “We really want it to be easier,” and so we built it for them, but I’ll say as far as stretching the limits of the plugin, the NASA website is the one that’s going to do it.
So you were talking about things buried in nav. They have a mega menu that has, like, I don’t even know, ten submenus and maybe even more within that, and so it’s, like, how do you surface that there’s an issue if you click the menu and then click two other things and then it will be visible.
>> STEVE: Yes.
>> AMBER: Right? So that was a challenge, for sure, and still is.
>> STEVE: It still is. Yes. I think the quick solution to that is, disable the styles, right? You disable the styles, and hopefully you’re going to find those issues that are in that nav menu.
I get that a nontechnical person is going to have a little bit of trouble reading a web page with no CSS on it, but the element will be there, it will be highlighted, and you’ll at least have some more context…
>> AMBER: Of what’s around it.
>> STEVE: Yes, of what’s around it or where it may be, but that’s definitely, you know, it may be a little bit of an edge case, like mega menu, you know, even a mega menu in and of itself for accessibility is a challenge, right? So getting that accessible is one thing, but then from our end, kind of aiding you in getting there, right?
Right now, the plugin will highlight those things, but if they’re hidden, we can’t see them until you fly that menu out or you disable the styles. There are things that we can do in the future, I think, to make that a little more intelligent. I mean, I think there’s a lot of things in regards to navigation menus that we’ve been thinking about, and Matt’s had some ideas about kind of formulating some more intelligent scanning of components. We’re not just scanning an Aria hidden inside of a navigation menu, right? We’re actually evaluating the whole navigation menu for accessibility.
>> AMBER: How would we do that, Matt?
>> MATT: [laughs] That’s a great question.
>> AMBER: What are your ideas?
[laughter]
>> STEVE: Yes. Don’t give away all of our secrets there.
>> MATT: That’s all secret sauce. Honestly, I think it’s taking the intelligence that we have on the team and translating into code. I mean, that’s the bottom line. It’s not just going and looking for, “Is this particular element missing from this particular piece?” It’s taking one step back and looking at a whole list of things.
>> STEVE: Yes.
>> AMBER: Yes. I know one thing that I’ve been thinking about. I haven’t logged GitHub issue yet for it, because I frequently have things floating around in my head, and it takes me a while to get them out there where people can see them, but I’ll tell you right now during the podcast.
You mentioned the Aria hidden. Right now, when we flag that warning on Aria hidden, for people that aren’t familiar, that is like saying, “This is hidden from screen readers.” And we flag a warning to be, like, should it be or not? We don’t know. It’s a warning. It requires a human to decide.
So let’s say it’s a social media icon, the only way you could really decide is if you would look and see if the link around it has an Aria label that describes that, “Hey, this goes to Facebook.” Or if there’s hidden screen reader text also in the link, right? One of those two things, then you’d say, “Oh, yes, it’s fine to hide this icon or this image because there’s something else that conveys the information.” But we just show you the icon or the image. We don’t actually show you the bigger apparent and everything that’s in there, and so part of me was, like, “Man, maybe we need to change the way we’re collecting the code snippet.” Or, of course, what would be really cool is if we could get smarter and evaluate the whole thing, and then not even have to ask you to check it because the plugin was able to check it for you.
>> STEVE: Yes, I think the future of this is definitely bridging the gap between the automated scan and then the human scan, right, the human evaluation. Because automated scans can only scan things that can be automated, right? And then to be fully accessible, it requires a human to evaluate certain things and to make those judgments.
Just like you said, you could look at that social icon and intelligently with your human brain decide if it’s compliant or not, and if the plugin is flagging something, one of those individual issues, you could go in and ignore it. In our plugin, we have an “ignore” feature, so you just go to the Accessibility Checker, you open the issue, you put in a message. Like you would say, like, “Amber Hinds evaluated.” Although we will log the user, I think, right?
>> AMBER: Yes. You could just say, “test it,” or have screen reader test or something.
>> STEVE: Then you can ignore, but I think the future is definitely being more intelligent in that regard, where we’re algorithmically, or we could call it like AI, of sorts, right?
>> AMBER: Yes, so let’s say that. Can we use OpenAI?
>> STEVE: Yes. I mean, maybe.
>> AMBER: Can we integrate it with that? Do you think that it would do a good job if you fed it sections of a website at checking for WCAG.
>> STEVE: It’s actually called EQD AI. Equalize Digital AI.
>> AMBER: We’re going to write our own.
>> STEVE: Yes. You heard it here first.
>> AMBER: I do not know how long that will take with two developers. Probably a long time. Everyone stay tuned. Five years from now, we will have.
>> STEVE: Well, I think it’s scanning back a little bit. Instead of evaluating each little individual issue, you start to intelligently decide, “What is this module on this website?” Or “What is this component on this website?” This looks like tabs to me. If this is tabs, then it should have ABC and D. It should meet ABC and D. It should have the Role tabs on it and describe or controls, all the area, the proper area labels on there, and we could decide that component as a whole, like, does it meet what tab should be, right?
>> AMBER: Yes. I know another one that I’ve been thinking about is, like, if there’s a div or a span that just has the word “next” or the word “previous” in it, that, to me, seems like a really easy thing for us to look for. Like if there is literally nothing else besides “next” or “previous” or “close” inside a div or a span, I think it’s pretty apparent that that’s supposed to be a button, but it’s not, right? So I do think maybe there’s just coming at what’s the logic and all of that, where’s that gap?
>> STEVE: Yes, totally.
>> AMBER: Yes. Do you have any thoughts, Matt?
>> MATT: No.
[laughter]
>> AMBER: I’m throwing you to the wolves here.
[laughter]
>> MATT: I’m a geek, guys. Come on.
>> AMBER: Yes. I know something that we have been working on, and you could talk a little bit about color contrast, some of the changes, because I think by the time this episode comes out, that will be live, and that’ll be pretty exciting.
>> MATT: Yes. Goodness gracious, I hope so.
>> AMBER: Color contrast is another thing that’s been a challenge for us outside of Front End Highlighting, even having an accurate color contrast check. I think right now it really has problems with CSS variables. I don’t think it evaluates them.
>> STEVE: It does, but at a basic level. I mean, if you think about CSS inheritance and how variables can be inherited as well to algorithmically compute what a value is just based off of a style sheet or all the style sheets on the page coming from all different places, it is a herculean task.
>> AMBER: Yes. Because the background could be defined like ten elements up from where the text color is set, right?
>> STEVE: Well, I mean, like a CSS variable can be, you know, you start with your root, right? If you’re writing CSS variable inside the root, you define your CSS variables, but then it can be changed at any point going down the page. Like it can be modified, it can be appended, all kinds of things.
>> MATT: If anybody ever wants to take a look at what a beast of a developer Steve is, they should go look at the code that he’s written for this. It’s incredible. It was a herculean lift. I do not envy what he put together there.
>> AMBER: For our PHP. It’s a PHP Powered, right?
>> STEVE: Yes.
>> MATT: Yes, but even with all that work, it’s just not possible to simulate what the browser is seeing. It doesn’t matter how smart you are, how hard you work. It’s just not possible, so we’ve decided that the way to solve this particular problem, and probably some problems going forward, is to render them through the browser, and actually let the browser do the hard work of processing all that CSS and those variables and then running our rules, running a rule set against it to determine if it’s valid or not.
Color contrast was the first run at this, and to this point, it’s working beautifully. I’m really excited about the work that it’s going to take off of us. A lot of our support requests are related to color contrast, so I’m excited about where we’re going with this.
>> STEVE: Yes.
>> AMBER: Yes. Well, and honestly, actually, if you think about it, color contrast is, if you look at the WebAim Million, that is one of the number one problems on the web, and I think that if we can build a tool that accurately communicates problems and doesn’t flag…
I like Axe. Axe is a cool tool, but I’ve been on websites where I’ve used Axe, and it’s, like, “Here’s 175 things you should check for color contrast,” because I think Axe can’t tell either.
>> STEVE: Yes.
>> AMBER: So I’m, like, maybe we’ll have a better bet on that, but I think if you can get something that makes it easier for people to see that, it could make a major difference for a lot of WordPress sites, and thus a lot of sites on the internet.
>> STEVE: Yes. When it comes to flagging accessibility issues, you’ve got to… Let me see if I can explain this correctly. Like, you describe Axe, right, where Axe is telling you to go check, right? They want a human to check, and it’s because they can’t, with 100% accuracy, determine the color contrast of that issue, probably based on the complexity of that markup and the CSS that’s attached to it, and maybe even some JavaScript, so I think their approach is “no false positives,” right? So by prompting you as a human to evaluate it, they’re…
>> AMBER: But I think that’s a false positive.
>> STEVE: To prompt you?
>> AMBER: Like, if it is something that definitively doesn’t have color contrast, like, it meets color contrast, let’s say that, maybe it’s five to one, or it’s something high, right? So it isn’t a problem, but we are telling someone you have to go check it. That, to me, is a false positive.
>> STEVE: Yes, but…
>> AMBER: Because it’s adding work for a user that theoretically could be done programmatically, maybe, or should be able to be done programmatically.
>> STEVE: I totally agree from a human standpoint, where you’re coming from. Maybe I’m in defense of the algorithm.
>> AMBER: As the developer who’s written one of them?
>> STEVE: Yes, as one of the nerds here. There’s two of us in this episode. [laughs]
>> AMBER: Hey, I’m nerdy too.
>> STEVE: Yes. Amber’s pretty nerdy. She was writing Macros earlier today, so we’ll give her the nerd title, but I think their methodology is to try not to have any false positives, and like you said, that element may meet color… You look at it and you’re, like, “Oh, yes, it’s like black text on white background. What’s the problem?” But based on that markup, that may be a very difficult thing for the algorithm to decide, even though it is simple people on your end, but it could be nested 50 layers deep inside some markup. It could be absolute positioned, like all kinds of things.
Think about it. You have a div right here. Up top there’s a div, and then below there’s another div that has some text in it, and then you absolute position that text outside of that bottom div, and it doesn’t have position absolute on that bottom div, so you put, like, top negative 50 or whatever, and it’s actually overlaid on top of the box on top it.
>> AMBER: Oh, the div above it.
>> STEVE: The div above it, right? So algorithmically, for code to figure that out, that this element is absolute positioned over top of a color, and the color contrast is wrong or could be wrong, or is right, those things get very difficult.
I think you even raised issue yesterday. I think it was on the NASA website, where there was a div with an image inside of it, and the image is absolute positioned inside of this div, and it looks like it’s positioned in a way that the image would be centered inside of that div, so there’s an overflow all around, and that div has overflow hidden on it, so I think the objective of whoever made that component was to get this image in here, probably expand it to a certain size, and make sure that it’s centered inside of this div.
>> AMBER: And that it always has the same aspect ratio, I think, right?
>> STEVE: Yes, and it always has the same…
>> AMBER: I think that’s why they did that. Yes, and I flagged that on Front End Highlighting because we did have our button that says, “Hey…” I can’t remember what specifically was wrong with that, like, it didn’t have alt text, maybe.
>> STEVE: Yes, yes.
>> AMBER: Right, and I was, like, I can see the button that it doesn’t have alt text, but it doesn’t have the little pink dash box around it. I was like, I don’t know why. Because normally in Front End Highlighting, the images, if they get flagged, they have a pink box around it, and then digging in, and it was, like, oh, that pink box is there, it’s just hidden below the other div.
>> STEVE: It’s inside the div, and the overflow is hidden, so we’re adding a button, a marker, that you can click on to see what the issue is, right? And then we’re putting an outline on that image, so we wrap the image in our own div, but it’s inside of another div that has overflow hidden that is actually bigger than that div. That’s complex. That’s a complex thing for us to even fix ourselves.
Now, we could traverse back up the Dom tree, check all the ancestry of that element, check to see if anybody within the ancestry tree of that element has an overflow hidden and has a width and a height that is greater than the parent div, and you have to do that all the way up the Dom tree. That is some serious work, and Matt’s over here…
>> AMBER: Is that possible to do with PHP?
>> STEVE: Matt, I’ll let you speak on that.
>> MATT: OK, I’m going to go with no. Just straight up no.
[laughter]
>> AMBER: So it would have to be a JavaScript-based test with something like puppeteer or some sort of way for the browser to render like a virtual browser or something. Is that the way? Or it’s not even possible with JavaScript?
>> STEVE: No. We’re doing it with JavaScript already. The Front End Highlighting gets added to the page, and it’s a little kind of app in and of itself. It’s all JavaScript driven.
>> MATT: Yes, and this is just getting off in the geek a little bit, but rather than wrapping that Dom element, we may need to do what we’re doing with the buttons, and absolute position based off of the position, and draw the border around that.
>> STEVE: Oh, yes. See, there you go. That’s why Matt is the man.
>> MATT: Just an old geek, guys.
>> AMBER: [laughs] Yes, so this is the interesting thing when you’re building a plugin, like any WordPress plugin, whether or not it’s accessibility or not, is that it could be used on so many different environments, different hosts, different themes, different plugin collections.
There’s only so much testing you can do before you’re just, like, “We have to be willing to let this go out into the wild and just respond if we get support because something doesn’t work,” right? And so we did it correctly so, rightly so. There’s a very tight process before plugins can get through the gate on NASA. Like a lot of coding standards, and there’s a lot of reviews, even when they’re updating our plugin to a new version.
So we did a lot of testing on non-NASA sites, and then we got it on NASA, and I know that was one thing we were talking about, which is we’re going to move the location of our button because where it was overlaying didn’t work as well for some of the themes we were testing it on. If there were tiny elements like social media icons right really next to each other, they all were flagged.
>> STEVE: Yes.
>> AMBER: But also, I think on the NASA website, there’s some where if we position it differently, it’ll be closer to the element.
>> STEVE: Yes, I think so. Yes. We were positioning it top left, and offset by, I don’t know, 50 pixels or whatever. The button itself was around, like, 46 pixels, and so we were offsetting it a bit to the left of the element, and I think the big issue that arise from that, like you said, where your social icons are in a list, and they’re all right close together, but even above that, any images that are, like, in a grid and don’t have a very large gutter on them, the icon would actually be laying over the image to the left, not over the actual image.
>> AMBER: So it’s harder to know what it applies to?
>> STEVE: Yes, so Matt worked on a pretty simple solution to move it into the top left corner of the element, just inset just a little bit.
You might be able to speak to it some, Matt. Like, you’re doing some intelligent with some logic around the size, right?
>> MATT: Yes. If we can go in and look at the size of the element that we’re trying to place the button on top of, should it go to the left, should it go above, should it go below? And right now, it’s, like you said, fairly simple. If it’s 80% of the width, then scoot it over. If it’s 80% of the height, bump it up, but what we really need is some real-world application. Take a look at it. Well, that works in most instances, but right here, this is weird, so that’s the joy of releasing these releases, and you just pray, but we’ll get back some feedback. We’ll be able to make some adjustments and make it smarter and smarter.
>> AMBER: Yes, so I think this is our call to action for all of our listeners. You can even try it in the free. Like, this feature exists in the free plugin, because we thought it was really important, and actually, NASA was super enthusiastic about paying for something that would give back to the world of WordPress, because NASA is very much about advancing knowledge for humanity and tools and all that kind of stuff, so it’s in the free plugin.
If you go try it, I think we would love to hear about button positioning, or if there’s things where it’s saying it can’t be found, but you’re, like, “But I see it. It’s right there on the page.” Especially if you’re using different page builders, because we don’t have licenses for all the various page builders, so we’re not able to test the plugin with all of them.
>> STEVE: Yes. Totally. Well, I think this big berry is kicking in here.
[laughter]
I’m feeling fuzzy, guys.
>> AMBER: There’s a little bit of time left in Friday.
>> STEVE: Yes.
>> AMBER: We’ll see how productive it is. You’ll be a very happy developer after this. You would not have to check your work again Monday.
[laughter]
Make sure you didn’t forget any semicolons.
>> STEVE: That’s right.
>> AMBER: I think it’s kind of fun. I want to try and do more of these episodes where we occasionally talk about the thought that’s going into the plugin, and some of the challenges that we’re experiencing, and what we’re continuing to work on, because I think it’s a little bit of that build in public kind of thing, but also, I hope that we can inspire people to be thoughtful about usability beyond their typical audience or who they typically think about with their own plugins, if we have other plugin developers who listen to this. Because, as we said earlier, right, we even learn.
>> STEVE: Yes, totally. Absolutely. I think that’s it, so we enjoyed having you all here for our Plugin Dev Notes episode. I don’t know what the title of the episode is.
[laughter]
>> AMBER: I don’t know, probably Front End Highlighting. Dev notes, or something. I don’t know.
>> STEVE: Give it a try. Kick the tires. Reach out to us if you have any issues, and in the words of NASA, I’d like to leave you all with this: Godspeed.
>> 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.”