Developers Unite: Navigating Accessibility in WordPress

Transcript

…

Nick Goodrum: Thanks, Nick Goodrum. Been working here at American Eagle for about ten years and, really, the goal of this presentation is about the two hats that I wear, right? So, accessibility and front-end development. And so, developers, you know, there’s all kinds of issues that we can do–that we create that impact end users.

Really, at the company we used to be more reactive and kind of, “Oh, if you wanna take care of accessibility, we’ll do it.” We switched to being much more proactive ’cause, really, every website is important. Every website has potential of creating barriers for people with disabilities that just wanna enjoy everyday life.

Amanda Bailey: Nick, I’m sorry, I don’t think your screen is shared. Yeah, if you double check that.

Nick: Oh, I’m sorry about that.
Well, using up–slides anyway, so.

Amanda: There we go, there we go.

Nick: Always preferred technology, right? Fun with all the Zoom calls that we’re doing.

So, yes, this is more aimed towards developers but it’s actually, really, everyone as a whole. So, site owners, site managers. What it is, is I’ve been assessing, looking at code for a long time and I kept going, you know, “Why are there issues? Why are there still problems? You know, why are we still having difficulties creating good end-user experiences?” And so a lot of times it’s probably, you know, not with bad intentions. It’s usually with good intentions but, as developers, we don’t really know any better.

So, where to start? So, we got a nice image of kind of that golden compass pointing North on a nice wooden table there, a nice sparkling table. So we can grab our compasses and let’s dive in. Let’s actually kind of take a look into the WordPress space and how we can navigate accessibility in it.

So, the WordPress starting lineup. That’s really where you wanna start. This is really aimed towards more beginners. People that have been doing this for a long time, you’re probably well aware of this, but really, there’s two areas you wanna be aware of when you start working inside of WordPress. So, one, you’ve got WordPress alone in the Themes area, you’ve got oh, about, close to 4000 themes.

But really, you wanna take a look for the ones that are accessibility-ready, ’cause really, we only have 107. And then, of course, the accessibility handbook. So let’s take a look. Accessibility-ready themes. Multiple people have probably brought it up so far and so, if you’ve been a marathon runner through this whole entire, you know, almost now, 24 hours of presentations, you’ve probably heard this. But it’s important to be aware that these take time to audit and review. Joe and the team have been working through these, trying to get as many as possible, but it takes time because we wanna do due diligence.

And it should also be noted that, of course, it’s kind of almost, you know, themes are in a sense almost kind of like hanging clothes, right? You won’t know if it’s actually truly the right fit and the right kind of accessibility until after you actually put in yourself–right?–and put in the content. And if you’re aiming to make a theme, these slides are available so there’s links throughout the whole entire area.

Feel free to go and you can reference them and jump to them. Is, you know, there’s also patterns, right? You know, helpful tools if you’re starting to actually make these things. So the handbook. So, picture here, of course, is going over all the chapters that’s inside of it, right? You’ve got best practices, development best practices, content best practices, tools, all kinds of items.

So you have to ask yourself, you know, as a developer, as a site owner, do I understand what WCAG is? Do I understand what the POUR methods, the things you’re looking for, perceivable aspects like that. Hey, there’s a quick little reference guide for that. Unsure about what–why ARIA guidelines are or what the HTML semantics for roles?

Well, hey, starting point right here too. You know, do you need to be able to send announcements? How do you do that, you know? And it covers even code of WP, you know, a11y.speak, code bases that can help guide you on how to fill these things out. And then, of course, just tools, right? Build tools, how do I put this into my CLI?

You know, how do I do it and to build tools? All kinds of aspects. So when we’re talking about WordPress and navigating it, we should also be able to know a map of where the current state is and so we’re gonna look into, you know, what aspects of WordPress are needing to be talked about. So we, of course, are gonna navigate it kind of like navigating this person with their finger going over, I think, it’s the downtown Los Angeles.

So I’m gonna talk, of course, about page editors. And so, some of you might be groaning. Some of you might know what we’re gonna talk about. I know it’s created a little bit of divisiveness but. Gutenberg. So, Gutenberg is moving forward. Automatic and the accessibility team have been working for, actually, multiple years now trying to improve and better create a usable experience.

The end goals, I can see the benefits, right? Trying to create an ecosystem where you can create blocks, move things around, have a page editor kind of like Wix and aspects like that. That, you know, if you think about it, WordPress from the beginning was just kind of a blogging platform but now it’s used to create all kinds of websites. But execution is key, right? So, of course, needed to have an audit, needed to have part of the practices, so Tenon.io did the review on WP campus. I’m not gonna rehash the whole entire history but it’s a good sign that, you know, we’ve gotten through two-thirds of the issues.

Now, of course, UI’s changed. There’s gonna be regression issues. It’s an ongoing aspect. But Joe Dolson, everyone, has been trying to really resolve this. Now, there’s still problems, right? So that’s why Classic Editor’s probably one of the most popular plugins and it’s because, yeah, things like video captions, you still need it.

Now, the Classic Editor plugin should be noted that right now, it’s supported only, really, through the 2021, through the end of 2021. Now, that might change, right? Because this is really about Gutenberg should be in a stable state, should be accessible, should be accounting for all these things by that time. So it gets a lot of flack but, you know, actually what about other page builders, right? Well, why don’t we use the others ones instead of Gutenberg? Well, unfortunately, the alternatives have pain points as well.

This is no means trying to bash on these particular ones. I’m not–Beaver Builder, Divi, Elementor, they’re, you know, they have some good aspects to it, but really, they’re most commonly used. They’re high up there. And they also have similar issues, so ATAG, you know, really about being able to easily traverse so people with disabilities can create content. They have problems with this as well.

Beaver Builder is trying to improve, you know, but it takes time and it’s been years. And so, you know, it’s nice that there’s a change of pace and really focusing on it but they still have problems.

Then of course, Divi and other people have even built plugins to fix some of the front-end issues of what’s being created. But CampusPress built that and it still has problems too, right? ‘Cause there’s a lot of work involved if you start with,
you know, sometimes not the right basis. And then Elementor, you know, they’re also advocating about accessibility but it
also has some work to do. So you can even take a look. You’ve got GitHub aspects that are pointing out multiple issues and it’s because, yeah, it’s not one and done, and there’s always room for improvement.

Okay, so, Nick, you’re not really making it sound amazing. Maybe there’s plugins, maybe there’s something to fix that. But really, all page builder tools, all plugins, they all still need work. So we’ve got a nice background here of a road in Japan pretty much in front of a Family Mart.

I miss convenience food from Japan. And pretty much people digging up and doing maintenance, right? ‘Cause it still needs work. So I mentioned plugins. Okay, this is probably better state, right? So if we’ve got page builders creating front-end code that’s having issues, maybe there’s some–one magic button that fixes everything? And so, really, I see people submitting, people talking about it, accessibility overlays. This has kind of become a popular theme more recently.

And so, I ask just, you know, ask yourselves what are your expectations for this overlay? What are your expectations in putting these plugins on your site? Because really, accessibility should not be an afterthought. So if it’s, “Hey, as developers, we’re just going to just plow ahead, keep making code, and then, okay, well, I’ll just throw in a tool at the end that’s supposed to fix everything.”

Well, they kind of don’t really fix everything.

If you really look at it, there’s so much inside the spec that an automated tool fixing everything is not really possible. Then you might say, “Okay, well, it’s also progressive and has been helping out people that might need to grayscale or high contrast or, you know, some negative contrast, some options– right?–underlines.

Now, again, if you’re making a good website, the link should already be recognizable so why I had the link underline aspect. Increase font, decrease font, if you’ve actually done a pretty decent job, it should also already be quite large in fonts. The design era of, like, 2000s with 9-point font aren’t really there anymore.

But think about it this way. So if someone with a disability needs to have high contrast or needs to have a certain font size, those kinds of things, they’re probably already going to have some tool, some plugin, some software, installed on their machine so that they can do this for every website, not just your website. So, some of these tools end up being a little bit redundant. Now, it’s not that you really shouldn’t use it at all and there’s no value. There could be some people that still somehow get benefit from it. So that’s where I kind of go, “What are your expectations?”

And there’s also some within the, you know, WordPress space that might kind of– accessibility one from Joe Dolson, yeah, that has a little bit of overlays but it’s also got snuck in some good aspects, right? Plugin making sure title tags or attributes are kind of removed if they’re not really needed, making sure skip navigation is inserted for you, so they’re putting stuff inside the P-H, P space, to actually make it a little bit better.

So the idea, though, is, you know, what is the goal? If it’s for a quick fix, there’s many voices out there. The community really expressing that that’s really not the best approach. You’ve got– Steve Faulkner. You’ve got even–let’s, this article here from Lainey Feingold, really going into how all of the issues are still around and there are still some legal battles for sites that have these kinds of overlay tools.

So, are there good ones? Yes, there are good plugins out there. Now, is this a huge list? No, and is it exhaustive? No as well. But yes, like I said, the WP Accessibility plugin, that’s, you know, a good starting point. Contact Form 7, it’s actually not that bad of a starting point for accessibility, but some of the defaults may sometimes need some help and so that’s why there’s a tool for that. Gravity Forms has some issues.

So, hey, we’re gonna patch that and fix that. Of course, there’s Accessible Twitter Feeds. This is also a lot of stuff that’s also in the handbook as well, so if you wanna know some good starting points, here it is. Video players, there’s also Able Player as a plugin. Able Player’s a really nice one that really gives a lot of options for different kinds of disabilities.

Now, of course, you have to make sure your content is also available that way. So I didn’t list a lot of options here and I’ve so far kind of pointed out everything has some problems. So, really, that’s why it’s all on us as developers, site owners, site managers, it’s on us to make sure we do our due diligence. We can’t wait until QC comes in.

We can’t wait until the end user has to complain or try and access the content. So we’ve got nice cartography tools on a workbench going over maps, and really, we’re gonna use those cartography tools. Just the tools for ourselves, so how are we going to test our sites? So test, test, test, and vet. Now you might be thinking, “I don’t know how to test or vet.” Well, at the very least, you can still do your part and look into the history. Okay, what–let’s go into the GitHub. As devs, we probably don’t feel too concerned of just jumping in and looking at the issue trackers.

They’ve been kind of showed here, right? We have Elementor’s. Making no dig at them but there’s, you know, still 21 issues still open. Still issues with maybe some keyboard accessibility. Now, there’s 64 closed, which is great. Now, for some plugins, some tools, that might not get enough traction to have a lot of people diving into the accessibility, so it’s also important to check is there even any statement at all?

So if it’s silence about accessibility, that’s probably a bad sign that they probably aren’t thinking about it. So, you know, even Beaver Builder, for example, has statements about it, trying to work towards it, right? And then, of course, search for reviews. Maybe you’re still kind of unsure, there’s a lot of specialists, there’s a lot of people, I mean, all the presenters today, I mean, there’s plenty of people that are trying to help educate and grow knowledge on maybe some pain points or in some growth areas.

Well, you know, you even have– oh, I think I shared that one. But you have, like, A Bright Clear Web. You’ve got multiple– that are actually testing out, sometimes even end users are saying, “Hey, I can’t actually use this.” But at the end of the day, it’s about actually, really, testing the demos, testing the code, testing it on a sandbox, testing it yourself. You know, even Graham earlier, watching all these streams, says, “You know, you need to know how to tab, use a keyboard. Don’t just assume it’s a mouse.” So we need to test, right?

We need to test with different kinds of tools. So a lot of people go to automated tools, right? So we’ve got Tota11y, Wave, aXe, ARC Toolkit. These are extensions you can install into your browser to be able to say, “Okay, well, quick assessment.” Then you’ve got Pa11y. That’s if you wanna create dashboards for yourself and do it through–against the A11y build tools. Then you’ve got Tenon.io, Siteimprove, these types of–hey, they’ve already created a dashboard, they’ve already created a system, that’s crawling your site and looking through everything.

And there’s plenty more tools available and out there. But these are all great starting points. Now, everyone’s throwing out different amounts, but in general, automated tools can only catch so much, maybe 25% to 50% of even the–text space. So really, manual testing is key because how would you know if a multi-step checkout process with multiple tabs, with an automated tool, needs to fill out all the form fields, fill it out, some of them incorrectly, hit submit, find where the errors are, and make sure that they’re properly tied?

That’s not that easy to achieve without a lot of customization with automated tools. Same thing, is there an automated tool to run through to confirm all your captions are well set up inside of your videos?

No, it takes humans. That’s why we even have humans writing closed captions. So I think one of the main things that I find with devs, you know, why there are so many gaps?

Why do I see ARIA hidden on a whole bunch of things that need to be read? Why are there these mistakes that are coming through? And it’s because as humans we have a hard time stepping out of our own shoes. We’re used to our normal, everyday life.

Some people are, you know, have sight and do cater everything to site users and so, really, it’s about picking up these tools. The ones that I’ve kind of listed here, NVDA, LipSurf, VoiceOver, TalkBack, all of them are actually, to a degree, free to use. NVDA, of course, would love donations, but–so if you’re on Windows and you need a screen reader, install it.

Don’t be afraid to just close your eyes and try and experience what it’s like going through your website or just regular websites and you’ll see the extreme pain points that many sites provide. I mentioned LipSurf, so Dragon is another, you know, voice dictation software.

Generally hasn’t been that great for web traversal, and so LipSurf is kind of another alternative that’s also free. It’s an extension that’s available for Chrome that also has some commands to be able to reverse everything. If you have a mobile device, and pretty much almost, I think, everyone to a degree has, now you can use VoiceOver, Voice Control, through MacOS and iOS.

You’ve got TalkBack and Voice Access on Android for the accessibility sweep, so they’re already built in so you already have options. So go into your settings, turn ’em on, see what that experience is like. ‘Cause not everyone’s going to
be–your end users are not going to be pro-screen-reader users.

It’s gonna be people that just, “I needed to, you know, get through the day.” So I think that’s one of the key things is if I were to say, stress anything about today or anything, is pick up one of these software tools and there’s other assisted technology, of course, as well, and try it out. And that will kind of show you the pain points of what you’re building. So, ’cause what I’m getting at is, you know, as you saw, there’s many plugins that–and page tools that all have issues.

There’s even ones that are promoting accessibility that have problems. So us as developers, as site owners, as site managers, we’re gonna need to patch things. We’re gonna need to fix things. So you’re–and you know, you’ve got here a nice kind of beaten-up road with potholes and definitely needs a paving, right?

So, DIY repairs are needed. So let’s actually go into some of these, right? Well, what could we do to improve this experience? So this is where we’re gonna get more devi side. So, situations that I feel I often see in reviewing people’s code and everything, is that are missed. So we’ve got sticky headers, right? Everyone loves sticky headers. It’s still kind of a focused interface, really, for sighted mouse users or touch users.

But it’s not that it’s a bad practice, per se. The problem is, is that there are people and we are getting older, right? And eyesight, unfortunately, doesn’t really last forever. And so, people need to zoom, increase the screen size so that they can actually–or magnify it so they can actually read content. So let’s take a look at an example, right? So, let’s actually change our zoom. So we’re at 100%, and let’s get out to 200%, and let’s get up to 400%.

And what is this experience for someone that needs to zoom in order to read content? Now, again, this is with Navigation Open, but the amount of space on a 1280 by 1024 screen, this is what’s simulating here, when you zoom in at 400%, that’s really not ending up that tall. You don’t really have enough real estate space. It’s actually shorter than most phones. So sticky here, where it’s following you around and then you have navigation and that’s open, how easily can I read–“Contact,” okay.

The experience is tough ’cause now we have also a sticky “Pricing” area. And again, this is not to–I see this on many, many sites, so this is not just something with Divi. So how do we counter that? So you can actually use media queries with min heights. Many people are aware of min widths, right? But you can actually do min heights. So you can do something along the lines of min height is 30 EM, right? So ems versus pixels to account for a little bit with different font choices and font sizes people might use within their browser.

And so, maybe if you’re tall enough, then let’s have a sticky, and otherwise, just have it be normal. Modal dialogs, it’s very, very, very, very common to do it wrong ’cause it is very easy to do it wrong. It requires a lot about focus management, being able to say, “As soon as I toggle something I need to move into that area, then I need to be contained within that area,” because the idea of a modal dialog is that you need to complete this task before you move on to something else.

That’s why you often have, you know, the grayed-out areas of a page. But okay, let’s–try me. Okay, something popped up on the screen. Are you under 18? Okay, this is just a demo. And so I’ll tab through and you can see that at least we know that tabbing through this, the content is actually– the user’s focus is nowhere inside this area. So, as a screen reader user, they may never even know that something even popped up.

As a keyboard user, how do I even get to this information? So then, okay, well, I need to move focus inside and then I need to be contained within side because a screen reader user might not know that they’ve left a dialog and now they’ve ended up in–there’s hot keys to jump all over the page. And so if they’re outside of it, they don’t know how to complete the task before coming back in. And then, of course, when you escape it, it shifts that focus back to where you were.

So, some promising aspects is there’s a new attribute, a newer attribute, inert, which doesn’t have perfect support yet. So if you mix that with aria-hidden equals true and you apply that to pretty much everything behind your content modal, that pretty much contains everyone inside, because screen reader users have, really, no other content to really interact with. Same thing with keyboards.

And something of note in Safari for VoiceOver, there’s bugs across all of these operating systems and browsers, right? So they actually have an issue where focus doesn’t actually move inside if you actually have–the modal display none and then you show it. If it just pops in, that’s a little bit different, so use visibility hidden if you were to actually hide this. And something, you know, I’m talking about Safari as well, in iOS, is that actually accessible names, you should have had an accessible name to your button in the first place, but I see so many times hamburger menus that pretty much have no name and just visuals, right? The three bars.

And those pretty much are always skipped by VoiceOver because they would never even know exist. You try and flick, you try and tab, anything and nothing really happens. There’s no way of interacting with it. Now, there’s plenty of other issues but at least the screen readers and desktop might actually land on it, at least let you know that’s clickable or if it’s a link, they might actually just at least read the URL. So what are some more situations often missed? So we’ve got what I call “div-itis.”

Concerns for, you know, anything interactive, you see it all the time: pagination for carousels, you see buttons that look like a button but, really, it’s just a div. And I see developers all the time that go, “Okay, well, I’ll throw in a div and then I’m gonna put a–okay, well,” screen readers don’t know it’s a button, a–button. All right, the keyboard users can’t access it ’cause there’s no tab index set. Okay, tab index equals zero.

And then, on top of that, they go, “Okay, well, that should fix everything because I have a click binding.” But the click binding doesn’t get called because the keyboards aren’t tied to it anymore. So now you have to add in on enter, on space bar, to actually trigger your click events. Or is that even really worth it? You could have just created button type equals button. The same concerns happen with anchors with no H reference. They end up being kind of just like a div.

So, same concerns happen. So, as developers, as site owners, if you’re creating a button or, sorry, a link, and you have no real H reference, you’re gonna like, “I don’t know where that would point to,” you’re probably wanting to create an actual button. And I do note type equals button because, it’s a little thing but forms actually, if you hit “enter” inside of an input field, will actually trigger the first submit option, and that submit, the default state of a button is type equals submit. So it’ll actually trigger that.

So that’s why most of the buttons that I see if they’re toggle open, do something, type equals button is something you’d wanna throw on there. And then carousels, slideshows, I see all the time, you know, it’s automatic rotation, rotating through items and there’s even tools where it’s, “Okay, well,” and you set focus. When you set focus, pause it, or when you hover over it, pause it. And yeah, for digesting content, great.

But about someone with maybe ADHD or someone that has–gets sick from motion, they have no way of turning it off or I guess they just have to stare down a carousel for the rest of the time of being on that page. And that’s not really enjoyable at all. So a pause button is absolutely necessary in order for it to be really accessible. Or really, don’t even have automatic rotation. That would be great.

So I’ll also get into some maybe ARIA overlooked items. Aria-expanded is really the base of any toggle when you wanna open and close it because–so the screen reader, to kind of give you an idea of what that experience is like, so sighted users, sites cater to you all the time. Let’s say I click on a features or hover over a feature, and it shows something, right?

Sites have been designed to account for sighted users for a long, long time.

So I get immediate feedback provided to me that, oh okay, for editor, design, all these things have been shown. But as a screen reader user, none of that’s actually happening for you because the software itself, think of it as a pinhole view.

You’re only seeing a little–one piece at a time. So when you’re on a button, when you’re on an area, all that’s being announced is just that area. Now, there are tools within aria to help with that, so Focus Management helps, ARIA Live helps, and some of these attributes like aria-expanded. And what will happen is, when you first land on that button and you, you know, click. You land on it, it’ll say, “Expanded, collapsed.”

One of those two options. Okay, I get immediate feedback on the area around me, even though I’m just only on one button. When you actually press it, you get immediate feedback because here’s the trick about buttons and, yeah, generally buttons for screen readers, is that, as a sighted user, if you pressed on a link and nothing happened, how long would you wait?

How long before you go, “Did it work? Is it thinking? Is there something wrong?” That’s pretty much what you actually have to deal with as a screen reader user on every single button because you press it and nothing’s announced so if you don’t use aria live, if you don’t do focus management, if you don’t do these attributes like aria-expanded, how long do I wait?

Did it work? I don’t know. So aria-expanded gives that opportunity to immediately say, “Expanded,” and let users know, “Oh, okay, this worked and I can continue along in my traversal.”

Aria labels. Aria labels are great and in the presentation so far, there’s even been references to them, how to do it. Just understand it’s a double-edged sword. If you overwrite all of your links with, let’s say, “Oh, I’m gonna benefit people, and I’m gonna say, ‘Open to a new window,’ on every single link and I’m gonna do it as an aria label,” well, the danger of aria label is that it actually, all of its children inside that anchor, inside that button, are actually removed and not really accessible anymore. And only the label itself is going to be announced to screen reader users. So you pretty much negated any visual text, any information, and only supplied what’s in that label.

So if all you had was “Opens in a new window,” you’ve just ended up in a site with a whole bunch of links that just say, “Open in a new window.” Just not helpful. So you have to front load and actually include all of that visual text for it to make sense. This also impacts voice dictation users so, like I talked about LipSurf, you know. Now, the technology’s changing, VoiceOver actually even puts in grid-view option so they can say, like, “Tap 10,” and a lot of opportunities to not have to rely on the actual phrase of the button that you’re interacting with, but there’s plenty that do, and so if you overwrite the accessible name there’s a large potential for voice users to not even be able to access those buttons.

Another one, you know, is aria-current equals page, true. I kind of point those out so if we take a look at even W3C, to understand the reference, we always create sighted aspects to say, “Okay, there’s some visual indication of what page you’re on,” right? In navigation, sidebars, all these things, there’s usually some class equals active, and some background color. Screen readers just don’t get provided that information. There’s nothing visual for them.

So, that’s where aria-current equals page now will announce something for them. And pagination, maybe sometimes they’re not always going to different pages so then you also have aria-current equals true to actually announce kind of, hey, this is the current one of this set. And something that I don’t think a lot of devs realize is that CSS display properties actually impact the accessibility and the semantics of anything, really. I mean, it’s kind of, if you think about it, display none makes it so screen readers and assisted technology keyboard users, no one can access it.

It’s already showing that display properties impact the semantics and the accessibility of HTML. And so, if even, you know, Adrian also went over a nice little explanation and it’s a good example of, okay, well, responsive tables, right? So if you do display block, display flex, on a table, that loses all of its semantic value. So these are the common things that I started to see as I analyze sites, look through sites and it’s not exhaustive. There’s plenty more out there. There’s a lot of new ones here.

So you kind of go, “Wait a second. He’s pretty much spent the whole entire time saying there’s lots of problems, there’s lots of issues, and it’s all on me and I’m, you know, scared and frightened about all this.” But I’m actually not that pessimistic about this. I’m actually quite optimistic ’cause when I look at over the years that there were plenty of people announcing– making a voice.

But probably in the past five years I’ve only seen a huge increase in the number of voices, the number of devs, the number of companies, that are waking up and realizing the accessibility needs. There’s–if any time to jump into accessibility, now’s a great time. And so that’s why I kind of say, the future still looks– it’s very promising. We have so many voices out there, so many opportunities. Joe Dolson and the team putting together information. Gutenberg, all of these areas, are still improving and you can as well. And you can be part of that.

So that’s why I kind of say, you know, devs unite. Let’s work together and create a better future. Let’s get out of this, you know, image of the dark tunnel and into the brighter future that we can help so many people with disabilities and improve life for everyone. All right, questions.

Amanda: All right, thanks so much, Nick. I can really tell how passionate and, you know, how much this is important to you. We do have some questions from the viewers out here, so we have, yeah, we have about 15 minutes for the Q&A session.

First question was: “Do you recommend a starter or accessibility-ready theme?”

Nick: All of them have really good points. I don’t wanna say, like, “Oh, this has to be the one.” It’s still just, I would say, go through them. Find ones that really align with you, because they have been vetted, they have been reviewed.

Of course, there’s always room for improvement for any of them but, you know, the main pain point is, you know, we’ve worked on many projects ourselves in WordPress and a lot of times there is that page builder aspect where, you know, there’s even Genesis Frameworks, aspects like that where they still don’t have the page builder that many clients, at the end of the day, wanna say, “I just wanna drag and drop. I just wanna put something in.” And that’s usually where the pain point starts to come out.

So if you are just creating more of a simple site and you can just build it off of the basic WordPress set up, any of those accessibility themes are going to be beneficial to you and I would say, “Take a look through these themes. Find one that aligns with you and that’s probably a good starting point.”

Amanda: Awesome. Okay, thank you. Next question is: “Why don’t developers lock in required accessibility items within repository themes and plugins? For example, requiring all text on all image or video content added or color contrast, et cetera.”

Nick: So, this is where it gets tricky ’cause it’s a two-way street, right? It’s not just devs, it’s also really site ownership so content has all. You could say, “Everything needs an alt text.” But actually, it’s not that simple because there are times, so let’s say it’s all inside of an anchor, right? So you have images and text and a whole bunch of information, all inside of an anchor tag.

Well, if the image is–let’s say it’s a product, right? And you’re buying men’s gloves, let’s say. And men’s gloves, the picture is of men’s gloves. Maybe you could get into some poetic way to describe them but, to a degree, most people end up just going, “Men’s gloves.” So in that anchor, now you’ve got alt text that says, “Men’s gloves, men’s gloves.” Well, it’s men’s gloves and then the title of men’s gloves that would be inside that same anchor. So in that case, you actually want to say “alt equals blank,” or nul;, in a sense.

And you would actually still want that attribute but you don’t actually want it to be explained. Videos enforcing captions for everything is not that simple and a lot of times, like, let’s say Netflix, for example, when–having audio descriptions and captions. They went through some suits themselves and, you know, I think initially they were, like, “Okay, we have audio descriptions for 2000 videos.”

And you go, “Yeah, great.” How many videos does Netflix have?

Amanda: Brilliant.

Nick: So, enforcing is tough because content creators, would you wanna say you can’t launch because you don’t have it done yet? Okay, well, how long will it take? Now, it should be built in, it should be best practices, but it’s hard to enforce that. ‘Cause it’s really on the content side.

And there’s sometimes no answer.

So devs, still it would be great to enforce but it still probably would be, you know, you have to flag to say it’s allowed because even the WCAG spec says if this is gonna prevent a launch, that you don’t have one video with closed captions, that’s not a reason to stop. It’s about a due diligence plan, and working towards it. Now, I request it. Yes, it would be great to make sure everything has that. But we also have to be realists and I know that’s not great but if you think about buildings, accessibility of a building, how often does it get renovated versus a website. When’s the last time you updated a page? Probably maybe even since 8 a.m. today.

Hopefully, that helps answer.

Amanda: Yeah, no, I think that was a great answer and a really great question, so thank you. Let’s see. If there are additional questions, you can continue to put them in the chat. The next question for Nick is: “Can you suggest automated workflow tools for preflight accessibility checks and are there any that you would recommend?”

Nick: Okay, so you wanna kind of have build tools to kind of run through and run against it so that you could actually catch these issues before you actually even go live or go up into a production environment. And there’s a lot out there– aXe and these other tools, you can actually build it in. There’s a lot out there.

It’s–they’ll have–the main thing I would say, you know, I mentioned Pa11y as well if you wanted to kind of create dashboards and run through it and run ’em against builds. Again, it’ll only help you catch so much so the main thing I would stress is that it’ll help you a little bit but there’s always gonna be false positives, there’s going to be aspects that are going to be missed, so it at least steps you in the right direction.

But it doesn’t actually really solve everything. So that’s where it’s really important you look at your own code, review it, and make sure you, you know, just even run through it with a keyboard. Run through it with a screen reader. Run through it with these things, and help catch it before it even–it bypasses a build tool to then go to a live site.

Amanda: Okay, great, I think, yes, diligence is key, testing is key, as you mentioned. Okay, so we’ve got two more questions here. The next one is: “How would you rank the page builders in relation to accessibility? Page builders always seem to be adding new features but is one working faster or more diligently to make their product better in this area?”

Nick: Yeah, I would say, you know, we’ve switched through a couple ourselves. Again, Beaver Builder still had some issues and we kind of switched over and we’ve been working a bit with Elementor. But we still have to hack around it, to be honest.

It’s really–if you know a system and you know the structure and you know the tools that are available, at the end of the day it kind of comes down to, okay, well, if you’re getting used to those, it’s about making sure you have the job script workarounds or the PHP workarounds or the customizations to fix it.

So that’s why I kind of say it’s a lot of patchwork and a lot of fixing potholes and it’s hard to say ’cause I see times where they make improvements and then they regress. I see, you know, advocacy and then I see things sitting for a couple of years.

Because it–all the people making it, right? How many people are involved? How much time does it take? I mean, if you look at it, Gutenberg ran into the same situation, right? They had to now go back through and start to fix and resolve items, and there are still gonna be issues that come up once in a while. It’s never one and done, unfortunately. So I don’t wanna be, “Oh, absolutely, this one,” because I haven’t vetted every single one of them ’cause that’d be a lot of time on myself as well. So there could be, actually, a really good one that caters to you because you know it so well.

Amanda: Okay, great. Okay, we did get another question so there’s still two more questions. “Where do you feel developers could make the most positive impact on accessibility,” and then, in parentheses, it says, “type of contribute, feature area, et cetera.”

Nick: That’s a good one. Like I said, I think in one way it is, as developers, how can we contribute?

The first thing is getting into another person’s shoes, is to break outside of ourselves. The more–all developers–if all developers and all, you know, site owners pretty much said, “I’m not gonna just think about me,” a lot of our design concepts and a lot of our development concepts, a lot of the things that we create, infinite scroll items, all of the concepts that we create that go, “Wow,” probably would have had some more thought into them on the impact that it is.

So that’s why I kind of say, you know, the thing that I would stress is, you know, if you haven’t picked up any of these tools, any accessor technology, dive into it for a day. Close your eyes and just try and even use a normal site that you
do every single day, and could you actually understand what it is? But if you were to contribute–right?– really, if you’ve gotten really good at accessibility and you know a fair amount and you wanna be able to contribute, be another voice by all means.

If you’ve found something, blog it, post it. For these, you know, open-source tools, contribute, right? They’ve got problems and you’ve been having to hack around it over and over and over again, here’s the hack or here’s an approach to do it and try and, you know, fork and try and actually do poll requests.

Amanda: Okay, great. I think that’s very much in the spirit of WordPress Accessibility Day, you know, having so many experts together, so.

And the last question is, I guess, more of a personal one. They said–the comment is, “I love your approach on testing. So what drew you to accessibility and who has influenced you?”

Nick: Yeah, no, it’s a lot of people have. Close family, you know, they themselves have issues that they’re dealing with. Mine’s not as fanciful, like, but it’s really just, I think, maybe being abroad, maybe living abroad teaches you, it’s just like, again, break outside of your mold and break outside of yourself and start to empathize with others. And so, yeah, did I make mistakes early on?

Oh, absolutely, I made some bad code decisions. I thought, “Oh, this is cool.” But when I started to realize the impact, it really started to get to me, kind of go, like, “Well, a lot of these principles are just basics.

We’ve lost sight of the basics. You know, accessibility principles for the web have been around for 20-plus years and somewhere along the line we wanted to get cooler and cooler and cooler, and it’s not that you can’t be cool. You can create really interesting interfaces, but you just have to remember the basics.

The amount of times that I don’t see a button, you know, again, all these job script frameworks, it’s not that the javascript framework is bad as a whole, you know, React, Angular, all of them. It’s that the people doing it don’t remember the basics. And so, I guess that just deeply influenced me where it was like, “Oh, I can actually make a difference.” And then, the benefits, right? The–plenty of presenters so far have gone over SEO, user experience as a whole.\

There’s a lot of alignment. So when I first started on, really diving in, I started, you know, people would always ask, it’s like, you know, devil’s advocate: “Why focus on accessibility?” And I can hear people presenting and they’re, like, “I–’cause you should.” Like, yeah, but I think, you know, that’s not always so realistic. It’s kind of sad in some ways that, you know, you would think it should be that easy.

So it got me really passionate and kind of going, like, “How can I express this to people so organizations, clients, can finally realize the benefits?” And so, generally, if you need to express something, you know, get buy-in within your companies or a client or something, is I always go with the selfish method. You know, it’s if you just scare them with legal, they’ll do just enough ounces of flair to get along, get by.

It’s, “Hey, did you know that you’d get benefits of SEO,” and they’d be, like, “Ooh, ooh, ooh, SEO, that’s much more important.” If you kind of point out, you know, “Oh, okay, well, you know, the amount of people with disabilities that you could increase,” right? An e-comm site. “You could increase up to 20% the amount of users.”

Banks, “Hey, stop thinking of it as–you know, you always talk about wanting to be individuals, wanting to be, you know, about the people. Well, you can create marketing campaigns about how you’re about the people and you’ve worked hard to make the accessibility.” So that usually then gets the buy-in to then finally do the thing that I wanted to do all along, which is make sure the sites are accessible.

Amanda: All right, perfect. Thank you so much, and for everyone that asked questions, thank you, those were great questions. Nick, it’s been a pleasure having you and, again, thanks, everyone, for attending this session, “Developers Unite: Navigating Accessibility in WordPress.” …