027: Key Considerations for Accessibility in WordPress with Amber Hinds

By /

This episode is a recording of a July 2023 WordPress Accessibility Meetup where Equalize Digital CEO Amber Hinds covers key considerations for building accessible WordPress websites, including recommendations for plugins and policies that your organization can enact to create more accessible outcomes. If you would like to watch a video recording from the meetup, you may do so on the Equalize Digital website here: Key Considerations for Accessibility in WordPress: Amber Hinds.

WordPress Accessibility Meetups take place via Zoom webinars twice a month, and anyone can attend. Learn more about WordPress Accessibility Meetup and see upcoming events.

Listen

Mentioned in This Episode

Transcript

Welcome to Episode 027 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.

This episode is a recording of a July 2023 WordPress Accessibility Meetup where Equalize Digital CEO Amber Hinds covers key considerations for building accessible WordPress websites, including recommendations for plugins and policies that your organization can enact to create more accessible outcomes. WordPress Accessibility Meetups take place via Zoom webinars twice a month, and anyone can attend. For show notes, a full transcript, and additional information about meetups, go to AccessibilityCraft.com/027.

And now, on to the show.

AMBER HINDS: I am excited. I kind of morphed a talk I gave at AccessU, which is Knowbility’s Accessibility Conference, and a little bit of what I’m going to be doing for HighEdWeb’s Accessibility Summit later this month. I thought I was just going to give that, and then I was, like, “No, I don’t want to just talk to university folks.” So I ended up making a talk this morning. [laughs] But we talked yesterday when Elvis was unfortunately not feeling well and we decided we didn’t want to cancel the meetup. We still want him to come. 

So I’m really excited that you all showed up anyway, and I’m excited to share with you. And we’re going to experiment with some zoom features later, so it should be sort of fun. 

Basically, the goal of this is I want to talk today about how we can minimize accessibility problems in WordPress. I’m going to be touching on four key things that really come into this. The first one is governance and policies, and then theme considerations, plugins and accessibility, and backend accessibility. 

I will mention that we have a link for the slides. So Paola, if you wanted to pop that into the chat, that might be helpful. I’m not usually very good at watching the chat and the Q and A. I will try my best to do that, but I think Paola will also be asking questions. So if there’s questions throughout, feel free. It’s most ideal if you can put them in the Q and A module and then we’ll definitely have time to answer them. 

So I’m going to start with governance and policies. I think it’s really important to start here and not start with, like, “What theme do you choose?” Or, “What plugins do you choose?” Because really having an accessible website, we’ve talked about this a lot and we’ve had a lot of speakers at this meetup, it starts before you even have a website. And so having good policies and oversight is a huge part of that. And even if you already have a website and you don’t have these, I’m not saying you failed, right? You can still go and create things. But this is where I really want to start, and this is something that we try to emphasize to our clients a lot as far as where to start. 

If we want to ensure that we have ongoing accessibility, it is important that we establish governance policies and practices. What does that mean? I basically mean oversight rules, literal rules. “This is how we approach XYZ at our organization and what the implications of failing to meet those things might be.” 

You also have to test at regular intervals, and you need to do combination of automated and manual testing, which we’ll talk about more later. But you really need to include users of assistive technology. It’s very important. Even if you don’t have someone who works full time for you that can do that, and you can only include users of assistive technology once a year, even that is a huge benefit to you. You’ll get a lot of feedback just from having a single user-testing session that you could then go and implement fixes, and then maybe you do it again the next year. 

Obviously, the more frequently you can include users of assistive technology, the better. But if it’s not something that you can do all the time, monthly, quarterly, do what you can, but try and include them. You also need to offer regular training opportunities to everyone on your team. This is really important, and I’ll circle back on that in just a minute. And then my favorite one is, not everyone should be an administrator. 

WordPress is really great. It can give us a lot of ability and flexibility to do many things. But if we start giving people who don’t understand about accessibility control or power… With great power comes great responsibility, but also can come great mistakes. We want to make sure that we are really thinking through who should be an administrator. 

So if you’re starting to ask some of these questions, “Who should be an administrator?” “Who should have different levels of control?” “Who’s responsible for ensuring ongoing accessibility of the website?” You really want to think about who this is. Is it an individual person? If it’s on a piece of content, is the content creator the person who wrote that blog post, for example? Are they responsible for the accessibility of that blog post or is it someone else? Do you have another person who is maybe the accessibility champion or the accessibility specialist that circles back and tests and reports on problems? On the occasion of that, if you’re not having the original content creator responsible for it, if you’re a larger organization, can it be a committee? 

When we work with colleges and universities; frequently, there are accessibility committees that are comprised of faculty and staff members from across campus, maybe even students that maybe have a say in the overall ongoing accessibility of the website, or they audit new websites that are being launched. The more you can spread it out and include more than one person at your organization, if possible, that is the most ideal. 

Then, of course, we talked a little bit about, are you including people with disabilities? And this is a really big thing to think about. Is website accessibility part of this person or these people’s everyday roles? Is it something that is just a side responsibility tacked onto their main job description? And if so, it’s less likely that it’s going to be done as opposed to if this is a key-performance metric on their job that they get evaluated on as part of their annual performance review. Or if you’re a website owner hiring a developer, if you say, “This is incredibly important to me,” and you’re saying, “I’m going to judge the success of my website on this,” then the developer is probably going to focus on it a lot more, than if you’re just, like, “Oh, yes, and it probably should be accessible too, but it’s not very important.” So really thinking about if this is central to what their job description is and what they’re supposed to be doing at the organization. 

Another really big one is, do they have authority to take action? So we have done a lot of consulting with organizations where they were, like, “Oh, this one person, Sam, is responsible for accessibility. They’re our accessibility lead.” But Sam has no power to go edit users’ content. The marketing team is the only one who can edit the content. Sam has no power to approve poll requests or to disapprove poll requests. Someone else is doing that. And so if you don’t give the person who’s responsible, or the people who are responsible for accessibility authority to take action, then what happens is, they log issues and they don’t get addressed, or they get deprioritized because someone else said, “Yes, but I really care about XYZ, SEO, or whatever the other bigger thing is. We really need this feature rolled out. That’s a higher priority than this accessibility bug that got logged.” So you really need to make sure that you are giving the power to take action to the person that is responsible for ensuring accessibility. And then really thinking about, with the user roles, how that comes in when using WordPress.

Another thing to think about in WordPress websites is, how restrictive of publishing will you be if there are accessibility issues on the sites? So we have worked with colleges and universities who they have faculty members creating sub sites or different departments. There’s hundreds of sites. Some will completely block new sites from being added. They’ll say you have to pass a basic accessibility test. “If you won’t pass a basic accessibility test, we won’t allow you to launch your new website.” That’s great. I think that is the way to go, but others won’t be. But either way, you have to discuss, “What is the implication of this?” “How do we want to handle this at our organization?” 

Beyond completely new websites, how about blocking publishing of new web pages? Or do you want to block uploading of PDFs or other file types? You could modify your WordPress media library to not accept PDF files or to not accept GIFs because you don’t want to have animated GIFs that auto-play for more than 5 seconds and can’t be paused on the website. So an easy way to do that is just make it impossible for a content creator to upload a GIF. It will reject it. 

Again, do you want to limit access to who can edit the headers, footers, and sidebars so that only people who are trained in accessibility can edit those areas? And then maybe the less-trained people or the people who are newer to accessibility are going to focus more on content areas because if they add a problem, they’re only going to be adding it on one page. They’re not going to be adding it on every single page of the website inadvertently. So you really have to start thinking about this as far as the different modules and areas of a WordPress website and all the different components that go into building it, and thinking about how much you want to restrict it, and who should get access.

On the flip side, what if you have a website that is already accessible, or already published and it’s not accessible? Or a page that has already been published and it’s not accessible either because you’re coming at it now and you’re working on remediating and improving your presence, or because something just slipped through the cracks? So if something goes past restrictions and go live, you need to start thinking about and writing a policy for how it’s going to be handled. Is there a warning process? Or does it get immediately taken down? What would the implications of an immediate takedown be? There could be SEO implications. There could be 404 errors. 

For example, if you had an event on your event calendar that was being shared and promoted, and it had an accessibility problem, and somebody from the accessibility team just converted it to draft until it got fixed, that could be a major problem, right? So it’s not to say that that’s not a possible solution, but you have to sort of think about, “What are the instances in which we’re going to say, this is already accessible. It needs to be removed until it can be fixed”? And what are the cases where we’re going to say, “It’s allowed to stay live for X number of days or X number of weeks,” at which point the expectation is it will be fixed. 

Another thing is thinking about, what would your policies need to be for “repeat offenders”? So if someone at your organization is very frequently failing to put alt text on images or failing to use meaningful links when they write posts, and they’ve been counseled on that, they’ve been provided training, how does this impact their job? If they’re a content writer for you and they can’t write accessible content, is that grounds to be fired? Or to no longer get new contract roles if you’re just working with a contractor? So really starting to think about this, like, how are we going to approach it so that we can ensure that we are going to have something that is accessible and that is delivering on an ongoing basis, and that we have policies in place if something goes up and is missed. 

I talked a little bit earlier about how part of governance and ongoing accessibility is creating training resources. As much as possible, try to create your own documentation library. There are some good resources out there where you can either record or find videos that demonstrate tool usage. I think it’s really important to have video training. Some people will like written training, so you should also have that. But frequently, especially if you’re trying to onboard someone who is new to the WordPress CMS, which might be a client or might just be a new hire who’s never worked in WordPress before, videos, five minutes or less, “Here is how you use the link block, and here’s the text that’s acceptable or not in a link,” those sorts of things. But you really want to ideally have some videos that include showing assistive technology, because until someone has seen a screen-reader user navigate a website, they frequently… They understand that a screen reader reads out the text on the website, but they don’t really understand what the reality of that it’s like for someone who uses assistive technology. So including some videos on that. You don’t have to create them yourself. 

Maybe you find some on YouTube or some other resources. And then it’s really important to have documentation that shows adding accessible content in your specific setup. So there are generic… Or you could even take some videos from WordPress Accessibility Meetup on our WordPress Accessibility Day. But those aren’t going to be very specific, showing your theme and your plugins and the way your website is built. So taking the time to create some documentation that actually visualizes the way your exact website looks or the website you’re handing off to a client looks is really helpful. And then if you’re an organization with employees, require training courses. Require that they do a certain amount of training. 

As much as I don’t like checklists or printed things, I think we have to recognize that there is a group of people who really benefit from checklists or “quick reference guides” that they can literally print out and set on their desk. I see this a lot with people who work in government agencies, not all. There are a lot of people that are very digital. 

We have a joke, actually. One of our clients also has a Chris, like my partner Chris, but they call her Analog Chris. That is what the client calls her because she’s not digital. She likes things printed. She would still use manila file folders and all that kind of stuff. So really recognizing that. And there might be cases with people where you need to create something that is printable that they can just have next to them that’s, like, “What are the top ten things you need to do every time you publish a blog post to make sure it’s accessible?” So having some printable resources can be helpful as well. 

Circling back on this user roles, making use of user roles, the top things that I would recommend really thinking about is limiting the ability to install new plugins, changing colors, editing header, footer, or other global areas we talked about a little bit. 

There’s a super-handy free plugin called the User Role Editor that allows you to create custom user roles or adjust the capabilities of existing user roles. But I really can’t emphasize enough that not everyone should be an administrator on a WordPress website. And the more content contributors that you have, probably the fewer the people who should be administrator. And setting up some sort of hierarchy there is really important. 

Before we transition, I’m going to experiment. We’ve never done a poll before, but I was, like, “I want to see how this goes.” So I’m going to attempt to do a poll. I think I’ve launched it. I’m going to read out what it is. If you can’t access the poll, it doesn’t work for your assistive technology, feel free to answer in the chat also. It’s possible I didn’t do this right, so we’ll see. 

So I’m curious how people who are attending today build WordPress websites. Or if you don’t build them, what is your website built in? That’s another way to answer this. So the options are a custom theme plus blocks, free theme plus blocks, a premium theme plus blocks, classic editor or a non-block editor. So that might mean, like, ACF pages. Not ACF blocks but ACF pages. Beaver Builder, Divi, Elementor, WP Bakery and other. And if you have other and you want to throw in the chat what your other is, I’m sort of curious about that. 

I’m not seeing any more coming in. So I’m going to end it and then see… OK, Annie said Bricks. I’m so afraid you guys are going to hit “end” and I’m going to lose the poll. 

>> STEVE JONES: This episode of Accessibility Craft is sponsored by Equalize Digital Accessibility Checker, the WordPress plugin that helps you find accessibility problems before you hit publish. 

A WordPress native tool, Accessibility Checker provides reports directly on the post edit screen. Reports are comprehensive enough for an accessibility professional or developer, but easy enough for a content creator to understand. 

Accessibility Checker is an ideal tool to audit existing WordPress websites find, accessibility problems during new builds, or monitor accessibility and remind content creators of accessibility best practices on an ongoing basis. Scans run on your server, so there are no per page fees or external API connections. GDPR and privacy compliant, real time accessibility scanning. 

Scan unlimited posts and pages with Accessibility Checker free. Upgrade to a paid version of Accessibility Checker to scan custom post types and password protected sites, view site wide open issue reports and more.

Download Accessibility Checker free today at equalizedigital.com/accessibility-checker. Use coupon code accessibilitycraft to save 10% on any paid plan.

>> AMBER: OK, I can see it. So hopefully you guys can. It looks like today, 18% are using a custom theme plus blocks. 2% use free theme plus blocks. Another 18% are a premium theme plus blocks. So we have right there that looks like almost half of the people are using blocks to build websites. And then Classic editor, 4%. Beaver builder, 7%. Divi, 16%. Elementor, 16%. And then we’ve got an other of 20. And I’m seeing in the chat, some Bricks builder, Avada theme builder. Someone mentioned Bricks and Oxygen, Themeify Builder. It’s interesting. I appreciate… Oh, wait. [inaudible] wasn’t sharing the results. 

>> PAOLA: No, I’m sharing the results. 

>> AMBER: So hopefully, you all can see that. And it’s interesting to see where people are. I wanted to do this poll because we’re about to move into themes, and this the section where I’m going to be brutally honest. I say this as a caveat, which is that I try really hard not to be negative. It’s something that I think is really important. But for this particular talk, I want to be honest. The honest reality is probably not what we want it to be.

I’m starting a chart from WebAim that shows the accessibility errors by “builder.” This is very weird. I actually contacted them to get information and figure out how they were doing it, because they have WordPress, and then they also have some things that are part of WordPress as separate line items, which is a little bit confusing. They told me that the WordPress line item in this chart… You can access an accessible version of this table on WebAim Million, 2023 report. There’s a link in the slides. But they said the WordPress here does not represent the Divi and the Elementor and the WPBakery that has been pulled out of that WordPress. So it doesn’t encompass it.

This chart shows different builders in the world they have scanned. So they have the quantity of home pages that they scanned, the average number of accessibility errors that they could identify with automated tools, and the percentage difference from the base on whether a particular builder had fewer or more accessibility errors that were automatically detectable. 

What I think is really interesting about this chart and why I think this chart is totally garbage [laughs]… Or it really just shows you something about automated checkers, and this goes for mine too. Automated checkers cannot find everything. And on this chart of the WordPress, I’ve put a little WordPress logo. That’s not on the table. I put WordPress logos next to the things that are actually technically WordPress websites. 

Divi, they scanned 4084 and they found 48.6% fewer accessibility problems, and that’s the only one that is better than the average. And then we have Elementor, they scanned over 51,000 sites, and it had point 6% more accessibility problems. Generic WordPress, they scanned 333,000 sites, and it had 1.8% more accessibility problems. WPBakery, over 32,000 sites for 23.6% more accessibility problems. 

Now, if you were to take this on face value and you look at this, you would say, “I should be building my websites in Divi because Divi has fewer detectable accessibility problems.” But if you’ve ever visited a Divi site on a screen reader, you know that there is literally no way to access the navigation menu on a Divi website, so it’s actually much worse. So charts like this, you have to be really careful about. [inaudible]

Don’t worry; it’s not just about Divi. But I’m prefacing this because I think that it’s important to just be aware that when you see things like this, it doesn’t always show the full picture, and that you still need to do testing. And this, again, is my brutal, honest truth. The title in this slide is, “Every Page Builder Sucks.” Because they all do. 

I also have subtext, which is that accessible websites can be built with page builders with an asterisk, because they can. We experimented with this. We used Elementor to build our podcast website, and it’s free of accessibility problems. But there are some caveats. All of the [inaudible] that I have tested have at least some accessibility problems. Some are much worse than others. Like I mentioned, with Divi, you can’t use the navigation menus at all. Almost all of them, if you were to try their carousel block or their tabs or their accordions, things that we might consider more fancy components, they are going to have problems. Some of them will be so bad that they’re not even keyboard functional for a sighted user. Some of them will work OK for a sighted user, but don’t have what they need as far as ARIA information for screen readers to actually help a screen reader user use that component. 

Can you build accessible website with page builders? Yes. If you are using one of these tools, you don’t necessarily have to make a change, but you need to be very cautious about which components in these tools you’re choosing to use. And if you’re launching a website with that, maybe you know, “OK, the tabs in this builder don’t work. So I didn’t build this website with any tabs, I built it with all the parts that do work.” Well, the next question is, can you unregister that inaccessible component? Do you have the ability to remove the tab widget or module or whatever the page builder calls it so that after you’ve launched the website and you’ve handed off to the client, or you’ve handed off to your marketing team, they can’t go add that thing that you know doesn’t work? So that’s the most ideal. If you can’t remove it, then maybe you try and document it. But the question is how well is that going to be maintained or followed? Or if a new hire comes on, are they going to know that they’re not supposed to use the tabs thing, or are they going to reference the documentation? 

OK, we talked about maybe don’t use a page builder. Where do we start for themes? There’s different options. Accessibility Ready is a tag on the “Wordpress.org” free theme directory. Those themes have gotten extra review. Opt in to get it. I think that these are starting points, but the requirements don’t cover everything. If you want to learn more about that, go watch The GoDaddy Audit, where Alex Stine and I talked a fair bit about what’s required. Or there’s a link in the slide where you can go over and read what’s required of an accessibility-ready theme. 

The other thing is, there are plenty of themes out there that don’t have an accessibility-ready tag either because they’re premium and there’s no free version available on “Wordpress.org,” so they wouldn’t be able to get one because they can’t get a review without being on “Wordpress.org,” or they just haven’t bothered. I know a theme developer who was, like, “I asked for one and they told me they had no one to review my theme, and it might take up to twelve months.” So they’re waiting. There are themes that don’t have the accessibility-ready tag that can still provide an accessible starting point. The biggest thing that I would say when choosing a theme or deciding where to go is, don’t just trust the theme author. 

I have seen themes where they say, “This is accessible.” I’ve even seen some where they say, “WCAG compliant,” and then it has literal WCAG violations in it. So it’s really important to test theme demos, use automated tools, whether that’s a browser extension, like Wave. I use Wave on theme demos and plugin demos all the time. It’s really handy and quick and easy, it gives me an oversight. But you can’t just use that; you also need to do keyboard navigation, use screen reader if you can. But when you’re testing things and trying to decide, you need to know what to ignore. Some problems are easy to fix. 

If you’re looking at a theme and it has bad color contrast, I wouldn’t worry about that. You’re probably going to change the colors anyway for your branding. So those are the kinds of things where I’m, like, “OK, whatever.” If I look at a theme demo and it has 58 color contrast errors on the home page, I wouldn’t rule the theme out because of that. So look at things that are outside of your skill set. 

For instance, if there are issues with the dropdown navigations not opening, and you don’t know how to change CSS, then that might be a problem. If you know how to change CSS, that might not be that big of a problem. If it has a component built into it that requires JavaScript, and you can’t add JavaScript, or if it doesn’t have skip links, and that requires you to edit PHP to add the skip link into the header.php file and you don’t know how to edit PHP, then that might be where you stop with the theme. So the answer on this is different for everyone, but I think it’s important to note that just because a theme, when you test it, has some accessibility problems, it doesn’t mean that it can’t be remediated or resolved. But I have my picture of Sebastian from “The little Mermaid” the animated picture, whispering in Prince Eric’s ear. Custom is the best choice. 

If you have the budget or the dev skills to create a custom theme, go custom. It will give you more control. You won’t have any reliance on a third-party developer, and this is better accessibility. It might also make it better in maintenance over the long run, because you don’t have to worry about someone else pushing an update that suddenly broke your styles because they changed the order of this when style sheets were being called, or something funky like that. So if you can do custom, go custom. 

Let’s talk a little bit about plugins. We’ve picked our theme, or we know what our theme is going to be, and now we have to choose plugins. I actually logged into a WordPress site for the first time for a client in their main site. We’re building a portal for them. They didn’t have a contact form on their contact page, and they wanted one so I logged in to add it. And I was, like, “They only had one plugin active.” I was shocked. I was, like, “I’ve never seen a website that only had one plugin active.” I was very impressed. And then I went and added a contact form and a SMTP plugin, which essentially tripled their plugin install count. Anyway, we’re almost always adding plugins. 

So what does this mean, and how do plugins impact accessibility? First of all, test plugins before adding them to your site, just like you would test a theme… I think in some ways you have to be harder on plugins, but in some ways, you have to be easier. So if you’re testing a demo, and I’m going to show you an example on Popup Maker’s website here in just a second, you need to know the difference between issues that were actually caused by the plugin and issues that were caused by the theme on the demo website. 

Let’s me jump over real quick to Popup Maker’s websites. I think they have a premium, but this is a free plugin that we frequently use on websites. And I think, unless it’s [inaudible]… Of course it does. I might have to stop my share. I was hoping it would give me a pop up, when I tried to exit. There we go. OK. All right. So it popped up. And if I were testing this as a demo, the first thing I might do, of course, I want to have a screen reader on. I’m not going to do that today. I could certainly maybe later if we have time, but I don’t know if it necessarily matters. I will tell you, in a screen reader, it does what it’s supposed to do. It shifts focus into the modal, and it would start reading it out to me right away as soon as it open, which is ideal. [inaudible] and I can’t get out. So a way to do that is to hit tab and sort of watch how it goes through the site. But when I hit tab… 

Now I’m on the first name. I don’t know where I was there, maybe the “close” button. Oh, now I’m on the email. Now I’m on the “submit.” Now I think I’m on the “close” again. So it is circling. I can’t leave the pop up. But there’s no focus outline. And I could inspect this and I could try and figure out why there’s no focus outline. If I go to this “close” for example, and I [inaudible] move my photos, I’m going to click on the hover and Chrome Dev Tools, and then I can turn on focus so it will show me what the styles are, as if it’s being focused. And if I scroll down, I’m going to find my focus styles. Oh, look, they have “outline none.” This right here: button, colon, focus, outline none, this is controlled by the theme. It’s not because Popup Maker doesn’t have focus on this. 

So if I see a problem like that… And this is what I’m saying; it gets harder with plugins versus themes, because you have to start to figure out if the plugin is actually causing this accessibility issue, or if it’s the theme causing the accessibility issue. This is a great example where if I were to go through and fix this, I could test it. Or if I were to put it on a different website where there is a focus indicator, then I wouldn’t need to worry about the fact that it does not exist on the demo. 

The last note I have on plugins that I think is worthwhile is that paid plugins or plugins with larger user bases may be more responsive on fixing accessibility issues. So if you come across a plugin with an accessibility issue, again, you sort of have to weigh your skill set, because if you’re really good at JavaScript maybe you can code a fix in your theme, your child theme for your site that resolves the issue in the plugin. Or if it’s a plugin with filters, you can write PHP that will solve that issue potentially. But regardless, some plugins, if you submit accessibility issues to them… And typically, I see this more commonly with paid plugins. Now, how quickly they’ll all prioritize them, I can’t say. But it doesn’t necessarily mean you can’t, it’s just something to consider. 

What I would love to do is, I’m going to actually go in and we’re all going to write my next slide together. Just trying to have fun today. So I’m curious, I would love to list out some plugins we all use that we know have decent accessibility. I’m not necessarily saying perfect, because I don’t think there is any such thing as perfect, but that might be good for other people to use. If anyone has any plugins that they like or they’ve tested and they think the accessibility is good on these plugins, I would love to add them to the slide. I listed Popup Maker, because we use that a lot. I listed Gravity Forms, which is a plugin. 

Everyone’s being nice and sucking up to me and saying, Accessibility Checker. Thank you. We can talk about that later. 

I want to know about not accessibility-testing tools, but plugins that you use. I think maybe people have said Formidable Forms before. So if you are a user of that and that’s correct, let me know. Plugins that can be used to add features. 

Gerson [phonetic] says WS Forms has pretty good accessibility, so that’s worth checking if you’re looking for a forms plugin.

Yoast is an interesting one, because Yoast doesn’t really impact the frontend. It impacts the code of the frontend. I don’t know if I’ve ever tested the Admin panel of Yoast, but I’ll put that on here with a question. Maybe the admin of Yoast is accessible, and so that’s good. And we’re going to talk about backend accessibility later

Stephanie Huntson [phonetic] says, “WS Forms is awesome, and the owner is very responsive.” So that’s good. Let’s see. 

Darren [phonetic] said, “We use an enterprise CMS cascade service so we can program some accessibility requirements into that.

So yes, if you are using your own things, then it’s definitely easier. 

Marcia [phonetic] wanted to know, “is there a good accessible plugin or theme for newsletter or events?” 

I have not personally tested any of the newsletter plugins. Paola mentioned the events calendar, which we use. Their accessibility on the frontend and the admin is pretty decent. And they have been responsive when we’ve flagged issues for them. I don’t know if anyone else knows a newsletter plugin. If so, please throw it in the chat. 

While I wait for a few more of those and then I’ll go on, I do want to answer the question that I see. Christopher asked, “If you do not have an assistive technology tech to audit, would you recommend reaching out to an access and disability department or enlisting students for testing or recommendations on tools, NVDA, zoom text or others?” 

I will say, even if you’re not an expert at using a screen reader, I think that NVDA on Windows and Voiceover on Mac can be picked up relatively easy. I would do a Google search for what the keyboard shortcuts are for those in advance, because that’s helpful for being able to make it stop talking the moment you turn it on; otherwise, it can feel overwhelming. But turning it on yourself, I recommend everyone do that. And the more you do it and sort of move around and listen to things… 

On my computer, I have my voiceover modifier set to Caps Lock. So if I just hit Caps Lock A at the top of the page and have it read me the entire page, which is not how an assistive-technology user would use a screen reader, but it allows me to literally hear every element on the page. Even doing something like that, not trying to move and just hearing that initially is a good step. 

Also, if you’re in Higher Ed and you have access to students, that is great. The Carroll Center for the Blind is a non-profit organization. They have given some talks for us, and they train people who are blind to be testers, and you could just hire them for one-off. We’ve partnered with tester school for the blind and visually impaired and have hired students from there. [inaudible] are a lot done tests. 

Craig also mentioned work-study programs. Peter said Fluent Forms. I’m going to put all these forms plugins together. Gravity Forms, Fluent Forms also has declared commitment to accessibility, which is awesome. 

DK [phonetic] mentioned… I’m clicking the link just to see what it is. OK. Pi calendar might be worth checking out. Let’s see. Did I miss anything else? Table Press. I’ll asterisk this one a little bit. I know then I had mentioned it. We had a conversation about this because I actually asked about this in our Facebook group. TablePress is OK. What TablePress did not do well is, if you need row headers and column headers, it fails to put the scope on there. I’m actually planning on opening an issue with them. There was one already on their support thread where someone attempted to fix it, but he doesn’t quite get it right. But that one might be worth looking at depending upon the kind of tables that you build. 

So I’m going to move on. I appreciate that you all were interested in helping to provide some other ideas, because that’s the question people always ask, like, “What are plugins I can use to build my website that won’t add accessibility problems?” So I’ll continue. If there are other ones, put them in, and then we can put them up with the recording in the notes. 

The next one is this group of plugins that I call Accessibility Helper Plugins. These are plugins that can extend the functionality of how you’re currently being built, and do things to improve the accessibility. WP Accessibility is my friend Joe Dolson’s plugin, and I’m going to circle back on that one in a minute. But it can do things like, if your theme doesn’t have skip links, it can add skip links for you. You can set it so that it removes target underscore blank from all links, so nothing will ever go open in a new window. So there’s a lot of helper things that it can resolve in many themes, and that’s worth exploring. 

We have our Accessibility New Window Warnings Plugin, which adds warnings for links that open in new windows. A plugin… And actually, yes, let me [inaudible]. I’ll pop these open, and if you have the slides, you can get links. So this is ours. We don’t have a fancy banner because it’s just free and we’re not ever planning to make a pro or anything. Maybe someday we’ll have a banner. 

Screen Reader Text Format. If you are in the Block Editor and you have not heard of this, this is one of my favorite plugins. It’s from Reactive. I think we had a talk a couple of years ago when they first came out with it, where Nick Croft shared about this. It allows you to add hidden screen-reader text in the Block Editor without having to edit code, which is really handy, and any content creator can use it. 

Along the same lines is this Lang Attribute for the Block Editor from Jb Audras and Guillaume Turpin. And what this does… Let me see if they have a screenshot. They have a GIF. It’s animated, everyone. It’s going to play. So you could say, “Oh, if this is French, I need to tag it.” Or if you have pages… We see this a lot in Texas, where there’s paragraphs in English and then there’s paragraphs in Spanish. Well, the main page, the language attribute, is English. And so if you don’t define that, “Hey, now we’re doing Spanish,” that can cause issues for screen readers. So this plugin allows you really quickly to say, “These paragraphs, or this part of a paragraph is all in a different language, and you can use it for any language you want.” I love that one. 

The Abbreviation Button is also Jb Audras’ and Guillaume’s plugins. It does the same thing where it allows you to put in an answer for an abbreviation, and it follows WCAG guidelines as far as how that would be. This is AAA-compliance tool. Some of the page builders support being able to add custom attributes on elements, which is important if you need to add ARIA. But in the Block Editor, WordPress Core doesn’t. So this plugin attributes for blocks, you can use it for a lot of different things. Some people use it for JavaScript or whatever, but this can be useful if you need to add ARIA for accessibility reasons. 

Contact Form 7. We listed a whole bunch of form plugins that I think are probably way better than Contact Form 7, but it still has millions of installs. But it is not accessible out of the box. So this plugin would give you accessible defaults if you’re using Contact Form 7. But maybe go check out some of the form plugins that everyone mentioned before. 

Search form. Improving search form accessibility. This comes from WebMan design. Oliver, he actually has some free and premium themes. The free ones have accessibility-ready tags and the premium ones don’t, because they’re not on dot org. But he’s done a lot with accessibility, and this fixes the WordPress Core, changes the label so it’s explicitly set rather than implicitly set. 

So I think when you’re thinking about building websites, trying to find some of these tools, there was one that we shared in the Facebook group, and I don’t have the link for it right now, that just recently came out. And I think they’re still working out their sales process. It has accessible components for Beaver Builder. So it has accessible tabs, accessible accordions, and things like that. So looking for plugins that can help you on that front can be really helpful. 

Then of course I have to have my, “Don’t fall for the toolbar,” with my favorite picture that I screenshotted off the AccessiB [phonetic] demo website, where they have a demo of their overlay open and it fails color contrast, because they have set it to light pink or salmon color with white text. And I’m just, like, “That right there just shows you something.” So accessibility overlays don’t work. And the JavaScript ones that come and try to fix things, they can add more accessibility issues if they’re not coded properly. They can hijack a screen reader user’s experience or make the website worse. They don’t protect against lawsuits. They may even add target. I think we’re seeing now in some of the [inaudible] that I’ve had from [inaudible] that there are some law firms now that are actually seeking out people who use overlays. And users don’t find the toolbar helpful. 

This is where I wanted to circle back a little bit to WP Accessibility, because it has a toolbar in it. Joe told me once that he wishes he had never added it to his plugin. So even just having the tools to make fonts bigger, well, people can do that in their browser. And if you think about this, someone who needs much larger fonts or high contrast, they don’t just need it on one website, they need it on all websites, or they need it on their entire operating system, and so they have their entire operating system set that way. 

So you don’t really need to add the toolbar. It’s an extra layer of complexity. Your client or your CEO or whomever it is that’s asking for them, try to talk them out of it. If you have to use those kinds of controls, I would lean towards choosing a WordPress plugin like Joe’s because at least it’s just the toolbar, and it’s not also trying to do a lot of weird JavaScript thing in the background, or attempting to use AI to write alt text, or things like that. 

The other group that comes into play with plugins is Accessibility-testing plugins. We’re not the only ones. There are some other free and paid options. There’s also SaaS services, most of which run on published pages rather than in the background of the WordPress Admin. But really, when you’re thinking about building sites and maintaining accessibility on the ongoing basis, you want to try and give content creators tools to identify problems in the CMS as they edit and add new content. It’s important that they don’t have to wait for scan. So if you’re paying for a SaaS that scans every Wednesday, it’s going to scan your entire website and give you a report. 

The downside on that is that; one, sometimes you have to go to a separate website to see reports; two, you will have had to have published the content. So if you publish the content on Thursday, that means you get the report the following Wednesday, and now you have to go back and fix it. That Increases time and costs. It’s better to try and find problems when you need to do it. 

I put a screenshot up here of our newer… We released Frontend Highlighting recently, which we were really excited about, to try and find issues on the frontend and put boxes around them. So we’re showing image, empty alternative text, and there’s a box around an image on my fake college website that I made for demoing the plugin. So really trying to think about what tools you can give content creators in the Admin for finding problems.

Of course, as I mentioned, don’t be reactive. Running a monthly or weekly scan, performing manual audits of live content, all of that is good. But if you’re fixing problems after they’re already live, that’s reactive remediation. So you want to always try to be as proactive as possible with selecting the right tools or testing before you publish. Training content creators on what to look for before content goes live. Training developers if you have developers on your team to test on their local or on their staging site before they push to production as much as possible, because remediation is always more costly than doing things right the first time.

A lot of what we were talking about seemed mostly frontend facing. We’re talking about plugins that build things for the Frontend. But backend accessibility is also really important. And why is this? People with disabilities edit WordPress websites too, and they might even edit your WordPress website too. 

I have heard a story. I don’t know if it’s my story to tell, so I’m not going to name the person, but it’s someone who was colorblind, and he said that he was in a meeting and his business partner didn’t realize he was colorblind. So they showed him something, and he’s, like, “I don’t know. I can’t see the difference in this.” Because it was red and green, and he couldn’t see it. So you might not even realize that you have people on your team who have certain challenges or disabilities or things that they identify with; ADHD or dyslexia, things like that. So thinking about the backend of the website is important just to ensure that everyone in the team can edit the site. 

Beyond that, employment laws in a lot of countries require accommodation for people with disabilities. So if you bring someone on to do a job and they are unable to do their job because the software that they are required to use to do their job is not accessible… Some of the web-accessibility lawsuits have been employees suing their employer because the employer didn’t make an accommodation or didn’t help them or didn’t change the software, and that person was effectively unable to perform their job duties. And then the implications of that is they don’t get to keep their job usually. So it’s really important to think about that, if you have employees with disabilities. 

Also, if you’re selling to clients, or if you are someone who works at a government website… Here in the United States, it’s section 508. But in other countries, there are other laws around the world that require the purchase of accessible technology. And this means not just that the frontend is accessible, but that the backend has to be accessible too. 

So is your WordPress Admin accessible? Core WordPress generally meets WCAG 2.1 AA, with some exceptions. So generally, Core WordPress starts at an OK point. When I am assessing the admin, you want to test just like you would on the frontend, I am particularly suspicious of plugins that have a fancy UI that doesn’t match Core WordPress. So maybe instead of checkboxes, they have little toggles. 

I have a screenshot from a plugin which we use on almost every site and we love and it’s great, but I really hate this, which is that they have a setting that’s lets you turn on accessibility mode in their plugin settings panel. And I would much rather that they just made it accessible and not have a buried setting somewhere in “options” where you have to go find it and turn it on. And if there are any plugin developers on this call or theme developers, please don’t do this. Please just make it accessible. 

So this sort of brings us circling back to full-site editing. I know there are a lot of people earlier who said they use blocks. What I didn’t really ask was whether people used full-site editing, where you’re actually using block-based headers, footers, and sidebars. I’m really cautious about that. We use a custom theme, but it’s what would be considered a hybrid theme. It supports blocks in content areas, but it is more classic when it comes to headers and footers. 

I think that if you are exploring full-site editing for your client websites or your organization’s internal website, if you’re using Coblocks, those have all been accessibility tested. If you go to the full-site editing theme… I think this is interesting you asked…They have this quote, “It might even be in easier to create an accessible block theme than a classic theme.” Why do they say this? They say this because the frontend output in block themes is more controlled. 

So for example, the navigation menu comes from the code that is in the nav block, whereas a random theme developer had to code their own navigation into their theme in the past in the classic themes. So in that instance, it could be right that the frontend output might be more accessible. But when you start getting into using third-party block libraries, then you sort of roll the dice a little bit there in the same way that you would have with a classic theme. 

What I think is really important to note… And I’ve had a lot of conversations with some of my friends who are blind or visually impaired. Alex Stine is one of them, and you may have heard him say this on other meetups. The Block Editor can be extremely difficult for screen-reader users to use. It’s not impossible. We’ve done extensive testing on client sites and on our own site with screen-reader users adding content in blocks. It can be done, but it is much more difficult than a more traditional editing experience. And so that may be a reason to not go full-site editing, or to limit how and where blocks are being used. Particularly, if the website needs to be section 508 compliant and the editor needs to be 508 compliant, full-site editing is probably not the best choice.

Joe Dolson was on our podcast with my partner Steve and I a couple of weeks ago and we were asking him about this. He has been a longtime contributor on the WordPress Accessibility team and does a lot for that. His opinion on this is that we’re really only getting back to where Core Accessibility was in 2018. So it was doing pretty well, and then in 2018, we introduced Gutenberg with a whole host of accessibility problems. So it’s taken that long, five years, to recover and get back to where we were. So I would be cautious about running the Gutenberg plugin, anything that is not fully launched or released yet in core WordPress. 

Feel free to disagree with me in the chat and I will read it out, but I personally don’t feel like full-site editing is where it needs to be for any sort of large enterprise or highly-professional website, and I would be very cautious about it, especially from an accessibility perspective.

So next steps, and then I’m happy to answer any questions. But when we leave this, I really hope that people will reflect on their organization’s practices. Maybe think about what could be improved in your own processes, or if you need to create policies. Think about how you can make accessibility problem identification easier for content contributors, whether that’s through training or other tools or things like that. 

We’ve talked about a bunch of different plugins today, both plugins that can help and have decent accessibility for just building features, and then other plugins that are helper plugins. So are there new tools maybe you can go add to your website? Maybe you also heard the opposite. Is there something that needs to be removed or something you need to restrict access to? So those are the kind of things I’m hoping you’ll leave with some thoughts about. 

I would be happy to answer any questions. This is my information if you want to follow up. But of course we’ll take questions now as well. 

>> PAOLA: A couple of questions came in when you were presenting. Danny [phonetic] asked, “Who do you recommend you get to test assistive technology? Or what is the best way to test those?”

>> AMBER: Users of assistive technology is probably the most ideal because they’re going to give you a more real world, “This is what this looks like” when someone comes. Most commonly, when we say that, we’re talking about hiring people who are blind or have low vision and who use a screen reader every day. That said, there are also certain cases, particularly if you serve specific populations as a nonprofit organization or a government entity, where you would also want to test with people who have mobility challenges and might be using just voice to control their computer, or potentially even eye tracking, or alternative keyboards like the Darci USB or switch input devices. Or you might also want to bring in people who have cognitive disabilities of one type or another. 

We did a website for Workforce Solutions, where people have to go through there and onboard, and we built a portal to allow them to get their benefits, like unemployment benefits or SNAP Benefits, which, if you’re not in the United States, that’s supplemental assistance to help you with buying food. So on a website like that, they could have people with a lot of different disabilities, and so it’s important to test for blindness, but also go beyond blindness. 

Craig mentioned you could talk to your local lines club. Blinded Veterans might be a good group to hire as well. And I know we mentioned earlier different students and things like that. 

>> PAOLA: And another question came in. It was John asking, “To what extent should the severity of an accessibility problem be considered a gating failing content? 

>> AMBER: I’ve seen some where people are, like, critical, high, medium, low, best practice, and they have this whole scale. But we do ours on just a three-point scale, because I think it’s easier to figure out how to prioritize if you don’t have all these different levels. And the way we will rank them is a high priority, which to us is the same as critical, is something that will literally stop someone from using the website or being able to achieve the specific task or get the information. For me, that’s navigation menus. If your dropdown menus don’t open or can’t be reached via a keyboard, that’s a high critical failure. 

If you happen to have a mostly decorative carousel on the home page where the “previous” and “next” buttons can’t be reached via a keyboard and so therefore they can’t slide through images, that’s not a high, critical thing because that’s not the most important thing. It’s still a WCAG failure. And if they need to have a WCAG-compliant website, it has to be remediated. But I would not put that over something that allows someone to add a product to a cart, navigate through the site, checkout, submit a form, doing the really important things. So that’s how I rank high. 

Medium, it’s a WCAG failure, but it’s not going to stop someone from doing what they need to do on a site. 

For us, low is not a WCAG failure, but it’s like a best practice or something that is recommended. 

You’ll notice in our plugin we have some warnings that are like that, like missing subheadings. So if you have a blog post that has more than 500 words, it will flag if you don’t have any H2s in it or any headings at all. That would be helpful to have subheadings once you get large amounts of paragraph text. But not having subheadings in a blog post that has 800 words is probably not… It might slow someone down, but it’s not critical to them being able to access your business. I mean, it might hurt your SEO, so maybe that’ll bring fewer people there, I don’t know. So that’s kind of how we look at it. 

It looks like Craig also said their scale is high, medium, and low as well. And Daniel said, “All sliders should be cast into the inferno, anyhow, so that screen-reader users aren’t subjected to a working one. That only works if the whole thing is hidden, but it’s really frustrating to watch a screen-reader user go through something and they just hear “clickable” because there’s a button there, but it’s not labeled. Although, that would be a button. “Clickable” usually is what happens when there’s a div that is supposed to be a button, but hasn’t been coded appropriately as a button. 

[crosstalk ] 

Craig says, “My favorite is ‘blank,’ ‘blank,’ ‘blank’.”

>> PAOLA: Even as a typically-abled person, I find carousels hard to move around with. I find them confusing. I don’t understand why people use carousels. But anyways, we do have another question. 

Carrie asked: What do you mean by the phrase “full-site editing?” 

>> AMBER: Full-site editing is the new way that WordPress Core is going, where you use… And I don’t know if you have used the blocks, but you can get information off of “Fullsiteediting.com.” But basically, the way we’ve been building content in the Block Editor. In a more recent version of WordPress, it came out where if you have a full-site enabled theme, that’s what they call it, then you can use those blocks to build your theme templates. So sort of like Elementor and Beaver Builder and Divi and some of those page builders, they allow you to go in and design what you would want your blog archive page look like. 

You can be, like, “I want my sidebar over here, and this is what’s going to be in it. And I want six blog posts before my pagination.” This is WordPress’ attempt to catch up to all those page builders. I did say page builders aren’t great for accessibility, but a lot of them are very useful tools for building websites quickly without having to do code, and WordPress Core is behind on that.

So as much as I was brutally honest about accessibility, like I mentioned, we built our podcast website with page builder, because I was, like, “I want to do this really fast.” Hopefully, that answers the question about full-site editing. If you go to “Fullsiteeditting.com,” you can get more information about it. 

>> PAOLA: I don’t see any more questions. Trying to see if we have anything else coming up. 

>> AMBER: Craig said, “If you want a really simple, easy-to-use podcatcher, Accessible Podcatcher is really good.” So that’s interesting theme. 

Oh, yes. That reminds me. I didn’t even think about this when we were talking about plugins. So we’re hosting our podcast on Castos, but their embed had some focus issues and caused some problems, which you could learn more about that if you’re interested, if you go back through our recordings and you watch the audit with Alex Stine of the Underrepresented in Tech website, because they also host their podcast on Castos. 

We’re using a free plugin from “Wordpress.org,” the Able Player, which is a library off of GitHub, and somebody made it into a plugin. So we’re using Able Player, and we just put in our podcast episode URL into it. We’re using that player instead of Castos. So sometimes there are things you can work around. 

I’ll try and grab the link for that one because I know there’s two on dot org, so I’d have to go back and look at our website to see which one, because we tested both of them, and one works better. I’m not sure, Paula. I’d have to look at the website. 

Dennis says, “Hasn’t been updated for years.” Yes. It still works. It’s still OK. We’re also using it on WordPress Accessibility Day website. If you go to the “2022.wordpress.wpaccessibility.day,” then you can see those. That version of it, though, has been modified. Joe Dolson made some modifications so that we could get the transcripts included in it in a specific way. But that loads YouTube videos in the Able Player instead of in the YouTube player. So there are some cool plugins out there; you just have to search for them. 

>> PAOLA: Yes. I think it’s about having that as a thought before getting into developing the website or working on the website. You just have to keep in mind accessibility, and knowing what you’re going to need and just look for them. 

>> AMBER: Yes. Especially if you’re building a lot of websites. So you’re not just doing it for one company, but if you’re doing it either because you’re in-house [inaudible] an organization with a lot of websites, or because you’re a web developer at an agency or a freelancer or something. 

The first couple of times when you get into it, it’s a lot more work. But once you figure out, “This is my setup, this is my starter theme, and these are the tools I use, these are the plugins I use,” I mean, it’s just like building any website, like, it gets faster. And if you just spend some time investing in that accessibility side of things, then once you build your second or third accessible website, it becomes easier because you’ve already figured out, “Well, what are the quirks in this one plugin?” There are plugins where you can use them as long as you have XYZ settings. So once you spend the time figuring that out, then that’s helpful. 

>> PAOLA: Yes, it’s about building the system. I don’t see any more questions, so I think we can just wrap up today’s meetup. 

Thank you, everyone, for attending. And thank you, Amber, for your awesome presentation today. 

>> AMBER: Yes, thank you.

>> 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 helped make 1000s of WordPress websites more accessible at equalizedigital.com.