As part of our commitment to giving back and sharing knowledge, we recently began working with the WordPress Foundation’s community team to run an official WordPress Meetup centered around building more accessible websites with WordPress. This post has a recap of our Meetup that took place on Monday, August 16, 2021, and a video recording of the presentation.
About the Topic
In our Meetup on August 16th, Joe Dolson, a WordPress plugin developer, core contributor, and accessibility consultant, presented an in-depth look at his WP Accessibility plugin and answered questions about accessibility in WordPress core.
About the Meetup
The WordPress Accessibility Meetup is a global group of WordPress developers, designers, and users interested in building more accessible websites. The meetup meets twice per month for presentations on a variety of topics related to making WordPress websites that can be used by people of all abilities. Meetups are held on the 1st Thursday of the month at 10 AM Central/8 AM Pacific and on the 3rd Monday of the month at 7 PM Central/5 PM Pacific.
Learn more about the WordPress Accessibility Meetup Group.
Watch the Recording
If you missed the meetup or would like a recap, watch the video below or read the transcript. If you have questions about what was covered in this meetup please tweet us @EqualizeDigital on Twitter, or join our Facebook group for WordPress Accessibility.
Links Mentioned In This Video
The following resources were discussed or shared in the chat at this Meetup:
- WP Accessibility Plugin
- Accessibility Ready Themes In the WordPress Repository
- W3C Guidance on Text Zoom
- W3C Guidance on New Window Warnings
- W3C Guidance on Meaningful Links
Article continued below.
Stay on top of web accessibility news and best practices.
Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.
Read the Transcript
Amber Hinds 0:00
Alright, let me, so, hopefully everybody can see our intro slides. I’m gonna do a couple of quick announcements first. If you’re not in it, we have a Facebook group that you can join, in between Meetups we’re trying to be available, and there’s a lot of great accessibility people in there that can answer questions, or bounce ideas off of if you’re trying to figure out how to make your WordPress site more accessible. So that link is facebook.com/groups/WordPress.accessibility.
And then, as I mentioned previously, our next speaker is going to be another Joe, Joe Simpson, Jr. He’s going to be speaking on September 2nd, at 8am Pacific, or 10am Central, about “Four Ways to Learn Accessibility.” And then I’m going to speak again on Monday, September 20th at, at this time slot, so it’ll be 5pm Pacific, 7pm Central. I’m going to share what our process is for doing user testing with real-world users of assistive technology. So if you’re interested in adding that to your testing process, I’m going to talk about how we do that.
Amber Hinds 1:12
And then we are still working on trying to get a sponsor for live captioning. It’s super important, we’re working really hard to try and find it. Unfortunately, the WordPress Foundation doesn’t have funds to offer that on a regular basis, so we’re trying to reach out to sponsors, so I wanted to mention it. On that note, if your company is interested in sponsoring live captioning for us, please feel free to reach out. It is our goal to make this Meetup as accessible as possible. Obviously, we want to, you know, walk the walk and not just talk it. So we’re trying our best on that front. If you do need any assistance with attending the Meetup, or if you can think of something that we can do better, please feel free to reach out to me or Emma. Emma couldn’t come tonight, unfortunately, but she’s one of our other organizers on Meetup. You can contact us through that platform, or you can email either of us, just, I’m Amber@equalizedigital.com, and she’s Emma@equalizedigital.com.
So, getting right into it, I’m happy to introduce today’s speaker, Joe Dolson. He is a WordPress core committer. And he’s part of the accessibility team and the maker of the WP Accessibility plugin. I’m actually super excited about this, because we get people who ask us about this plugin all the time and I have not used it personally. And I just started, you know, recently, I was like, I really need to install that and play around with it. And then I thought, you know what would be really good, I should have Joe come and tell us all about it so we can you hear the best use cases and get all of our questions answered personally. So, we’re very excited to have Joe. And looking forward to -oh, apparently my slides are going to jump around- hearing what you have to say, so welcome. For this presentation, I know Joe is going to share his screen, I’m going to chime in. If you have questions, you want to throw them in the chat, I can sort of moderate that, otherwise, I think Joe has said he’s open to anyone asking questions along the way as well if you feel comfortable vocalizing your questions.
Joe Dolson 3:20
Absolutely. Alright. So, I’m just going to share my screen. And, I’m going to be just kind of bouncing through all of the various settings of the plugin, talk about what they do, how they do it. And, in principle, I’m going to talk a lot about the concept of the word- of the, uh, accessibility overlay. Because at its root, a lot of the pieces of what WP Accessibility do are, in fact, an overlay. And I have been a very public person in talking about what is bad about overlays. And so, this is an interesting opportunity to talk about this plugin, exactly what it does, and what makes it somewhat different from a lot of the other accessibility overlays out there.
I’m going to prefix this by saying that when I built this plugin, I conceptualized it as something to fix broken themes. To basically tackle the problem of themes that were not accessible, and try and fix bits and pieces of them that I could actually find and identify because I knew what might be going on. It was never intended to be something people would install permanently. But I have to say that at this point, with 40,000 active installs registered from the WordPress.org plugin directory, I rather feel that most people are installing it permanently. Hopefully they’re turning off all of the overlay features once they’ve actually fixed the problem, but we don’t really know. I, I have no way of telling that.
So let’s talk a little bit about what it does. What I’ve got here to demonstrate is I’ve created a broken version of 2021. I just took a bunch of things, and I, I broke the way this works, because 2021 is actually a perfectly reasonable plugin. I mean, sorry, perfectly reasonable theme. But I took away its skip link, I took away all of the ways that it worked, I added tab index so that the tab is now bouncing around the page inappropriately. Basically, I just went in and I hacked it apart, so that I can show what my plugin is actually doing. One of the things I did is I removed the labels on the comment form. So when- my plugin can fix all of these things, and there’s a reason it can do that. And the reason it can do that is because a lot of parts of WordPress are a known entity. And this is a lot of what overlays really depend on is you can fix anything with JavaScript, if you know what the problem is, and a way to definitely find it in the DOM, in the document object model.
The problem with a lot of “magic overlays,” things like AccessiBe, or UserWay, or a lot of those other plugins, that kind of just trump all over everything, they’re trying to use some kind of artificial intelligence, machine learning to study your website, and figure out what the problems are. And that is a considerably more fragile and biased way to go around, about doing it. That’s not to say that any overlay is the ideal fix. In the end, the ideal fix is actually to have it on the page, you know, have it rendered using software that’s intended to render it.
So, here’s the first thing. It’s turning on a set of skiplinks. This is a fairly simple process, ’cause essentially, since a skiplink has to be the very first thing in the DOM, I can simply attach this at the very top of the body. I don’t have to worry much about what is on your page. What I don’t have a way of knowing, is what it should target. And a lot of themes have very straightforward ID attributes. In 2021, it’s “content,” that’s the ID. So I can simply save that, and now it knows where to skip to. Not all themes are that easy. For example, I was recently working on a site that was built using Hello Elementor, and Elementor. And that was an interesting process.
Joe Dolson 7:48
Now you’ll see it didn’t come in the right order. Now that’s because I’ve also inserted a bunch of links down here at the bottom of the page that have tab index. Well, obviously, that’s a problem. The skip to content link needs to be first. I want to finish talking about that Hello Elementor problem, I distracted myself by jumping to this other tab index thing. Which of course is the essential characteristic of tab index is that it causes you to go out of sequence, just like I did in this talk. So, you know, great example.
Hello Elementor doesn’t have IDs, by default. Everything is just classes. This is actually a common thing, there was, there was a movement, probably, I would say it was, started seven or eight years ago, maybe, to just not have IDs in your CSS. It’s like, we should do everything with classes so that it can all be stackable, and we can match things to other characteristics. It creates a lot of problems, however, if you need to ever target anything, and it broke content and skiplinks. So, in that case, you know, my only, my job in that particular case with that Hello Elementor, was I needed to create a skip to content link. And I didn’t have access to the source code.
That was a much harder problem, because you’re kind of having to interpret the organization of the site to figure out where the content area actually is. Fortunately, in the average WordPress website, this is much more manageable. And with, with more recent WordPress.org themes, it’s actually become mandatory to have a skip to content link, so this is a rapidly decreasing problem in terms of frequency. So, let’s look at that tab index problem. That is also something that I can just strip out. It’s one of the-
Matt Wilson 9:43
-Hey, Joe?-
Joe Dolson 9:43
-miscellaneous options. Yes?
Matt Wilson 9:45
Hey, could I, could I ask you then, so if you do not put any ID in there, is there some sort of default that it looks for as far as the skip link?
Joe Dolson 9:54
There isn’t. So, there are a lot of problems, I mean in, so, there are things I can look for and try to find. Like, I can look for a main element because the main element should appear only on the page once. And then whether, if it has an ID, I can target that ID, if it doesn’t, I can insert an ID. I don’t currently do that. I try and keep this plugin fairly simple, because the fact is, I don’t really want people to just use it forever. You know, I just want them to fix the problem. The whole idea is to fix your problem.
Matt Wilson 10:30
Yeah, okay.
Joe Dolson 10:31
So, yes, there are things- but not all sites have a main element. You know, this is again, like this, Hello Elementor. There is no main element, right? It doesn’t have one. So, now it’s just a div, and you have to figure out which div, which with, with which element or content wrap class is the one that you actually want. That wasn’t fun. Ultimately, what I actually did was I wrote JavaScript, which found the section, the Elementor section header, which only appeared on the page once, and then found the next sibling to it, and defined that as the content. Because I knew that the navigation was in cell- okay, technically, I found the main navigation, then I found its parent section header, then I found its next sibling.
It’s a mess. It’s terrible. It’s fragile. It’s awful, you should never do that. But this site had problems. And I didn’t have any access to actually fix the core problems. Because rebuilding a site from the ground up is a pretty big project. And one of the things about, you know, a site that’s built with something like Elementor, is that it is complicated. There’s a lot going on in there. These are, there are tons, and tons of widgets, and just making the decision, “we’re just going to get rid of this,” was not something I could just drop on the client and say, “Hey, this is what you should do next week.”
Matt Wilson 11:58
Yeah.
Joe Dolson 11:59
They need a little more heads up on that.
Amber Hinds 12:01
Did you write, this is interesting to me, because we literally just audited website that’s built with Hello Elementor, and this is one of the things we flagged for them, right?
Joe Dolson 12:08
[Laughs]
Amber Hinds 12:09
Did you write a separate plugin that they installed that would activate the JavaScript that added the ID onto the element?
Joe Dolson 12:17
Yep, I did.
Amber Hinds 12:18
That’s how you did it?
Joe Dolson 12:19
Yep.
Amber Hinds 12:20
Rather than using like a child theme or something?
Joe Dolson 12:23
Uh, they were already using a child theme. But I didn’t, yeah, I couldn’t do that, because the child theme is in use by, like, it’s in a multi site environment. And the child theme is actually used by dozens of sites. And there’s a lot of fragile CSS going on, and they were averse to making changes. These things happen.
Amber Hinds 12:44
So it’s, so, to that question of you don’t have a default on there, if someone checks that box, but they don’t fill it in, does it still output the skip to content link, but it’s a broken link? Or will it not output it if they haven’t filled in what the ID is?
Joe Dolson 12:58
I haven’t tested that recently, if I remember correctly, it’s set up so that it will not output the skip to content link. That would be the logical thing. But, I can’t honestly say I remember. I just released a new update to this, because I wanted to, you know, take the time to actually look at it before this talk, but I didn’t review everything. And indeed, it does not output it if there is no target. So, that answers that question.
Alright, so anyway, back to the other question, which is removing this tab index. Tab index is a major problem on websites. You know, if any part of your site has decided that it needs to have tab index, that will reorder all focus orders throughout the entire site. Because anything with a defined tab indicee will come before anything without one. And there are a few plugins out there that have famously done this a lot, BuddyPress is one. And that can be really nasty. bbPress used to do that, but no longer does, ever since version 2.6. And so that can create all sorts of problems. So that’s an important one to remove.
Now, this, I have made the choice that I’m only removing it from, whoops, that’s the wrong tab, I’m only removing it from focusable objects. And that’s because if somebody has added tab index to something like a div, that’s probably because they already know they need that to be able to receive focus. So I’m only removing it from links, from buttons, from input fields, that sort of thing. And now the skip to content link comes up first, because the tab index has been stripped out.
All of these are things that ideally, the site doesn’t have this problem, and you’re auditing it separately and saying, “Okay, let’s get this out of the content.” But the reality with complex WordPress websites with dozens of plugins is, it’s really difficult to maintain a forked version of everything, it may not be something that’s filterable, so that you can pull out this characteristic. And that’s kind of what this plugin exists for, is dealing with some of those situations.
I also, so I inserted a bunch of links here that have target attributes, target equals blank. Now, the problem with target equals blank is really about disclosure. You should never have a link that has a target that’s blank, that doesn’t disclose the fact that it’s going to open in a new tab. And the reason for that is that users don’t have a choice. When a link is designated to open in a new tab. For any standard link, a user can make that decision, a user can choose to open it in a new tab or not, whatever they want. But if you’ve, if you’ve added target equals blank, they have no choice, and taking that choice away is their major accessibility problem. So you want to warn them.
Now, adding that warning is also something that WP Accessibility can do. But that’s why I have more than one option, because really, in many cases, just removing those links is the primary concern. There are cases where a link should open in a new tab. It’s not an absolute. For example, if you’re in the middle of a form, and there’s a link to a PDF that provides some kind of reading you have to do before you finish this quiz, for example. If that doesn’t open in a new tab, then you could conceivably lose all of the data you’ve entered in this form before the, before you submit it, and boy, that’s frustrating.
So, we can remove target attributes from links. I’m not going to demonstrate that because we all know what that does. Additional things I can do. So there’s the site language and text direction. Every site should declare what language it’s in. So if it doesn’t, oh, and I didn’t strip that out. So this one is, well, at any rate, in theory, if it doesn’t declare its language, then what a screen reader is going to do is it’s going to come to that page, and it’s going to read it in the user’s language. So if the user is a native French speaker, and they’re reading an English site, then everything is going to be pronounced as if it was French.
Joe Dolson 14:44
That’s not going to make for a great experience when the language actually is English. So what WordPress, what, what WP Accessibility does is it just adds your site’s declared language and text direction to the HTML element, so that those screen readers will know the correct language. And it is listening to translation plugins. So like if Polylang has changed on the fly, word, WP Accessibility should catch that. I’m not going to guarantee it works with every translation plugin. Because the practicality is I haven’t tested with every single one of them, because they’re all a lot of work to set up. But it’s attempting to catch those.
Forcing a search error on empty search submission. This is something that is a core WordPress problem. This isn’t something that’s an issue with a theme. This is something that WordPress just does. And it’s kind of obnoxious. If you submit a search that doesn’t have a query, it just goes and loads the homepage, except I turned on that feature, so now it doesn’t. But you get the idea. So natively, if you submit a search with no query, it just loads the homepage. That’s just confusing. It’s not actually like, per se, creating a major problem, it’s just giving you an a result that’s unexpected. So what word, WP Accessibility does is it forces that characteristic, it forces the search to instead return a no results page. I see what this did this actually did a search for a space.
Joe Dolson 19:48
No, it didn’t. I don’t know what this is doing, because that’s actually not the same thing that no, most WordPress sites do. Says returning results for nothing. I don’t know why it would return results for an empty query at all. But I’m not gonna debug that right now. Just kind of curious.
Amber Hinds 20:09
Do you think that’s core WordPress? Or do you think that’s what your plugin is doing?
Joe Dolson 20:13
No, no, that’s neither. That’s not either what core WordPress does or what my plugin does. So that must be something else. Yeah, well, it could be in the theme, it could be just something that I, I mean, so this is my trunk development site. And it might not be 100% clean. [Laughs] Because I might have trashed it on very, very many occasions and not reset it. Let’s be totally honest here. So one of the things I did in this demo site is I removed all of the underlines on the links. So that’s something I can also force.
Amber Hinds 20:48
Oh, I missed a question. I’m sorry. Um, someone was wondering how can a screen reader read English as if it is French?
Joe Dolson 20:58
Well, that, I think the, if I understand the question correctly, what it is, is that it will pronounce it using the French pronunciation rules, which don’t make any sense if what you’re actually reading is English words. And that’s because the screen reader has been informed, or it has not been informed what language this page is in. And so they’re going to fall back to whatever the operating system language configuration is. Did that answer the question?
Amber Hinds 21:35
I think so.
Joe Dolson 21:37
Okay. Hopefully.
Amber Hinds 21:39
Yes.
Joe Dolson 21:40
Alright. So, now, adding these underlines, that’s a very straightforward thing. That’s, that’s because on, if your site has no underlines on links, they may be very difficult to spot. Depending entirely on contrast to differentiate between link text and not, non-linked text is inherently difficult. There are almost no color combinations that make that actually possible to meet WCAG with. So this just adds the ability to add those links. Having those linked texts simply makes the site a lot easier to see and use. And so you can just kind of navigate through it.
A related feature is the ability to add an outline to keyboard focus. And this is something that’s just going to strengthen the way the site experience is for a user who’s using a keyboard. It’s just a little bit more obvious, a little bit more clear where your current location is. And that’s always an important thing to recognize is that keyboard focus really needs a stronger marker than the hover state does. And that’s because hover state is a directed action, the person who’s using hover is using a pointing device. So they had to move their mouse cursor around and ultimately land on a specific location, the cursor is changing, they have pointed at this thing with intent. So when it changes at all, they are looking at it, and they are observing it.
Whereas with keyboard focus, this is an undirected action. You’re tabbing, but you don’t actually know for sure where that next link is going to go. Sometimes it’s obvious, this is really quite obvious. But if I’m going backwards, I don’t know, where before that am I going to actually be shifting position to? Maybe it’s the image, maybe it’s some random other point on the page. And so having a very clear and obvious focus appearance, helps make that very, very obvious. And so this is always something I strongly recommend is that, if you’re, you know, you want your focus state to be at least as strong as your hover. And in preference, it should be much, much more obvious, because it’s really something that people depend on for locating their position on the page.
So this is one of the fun ones, it’s automatically labeling the WordPress search and comment forms. By default, WordPress, search and comment forms have perfectly good labels. All of the core themes are well labeled. The core code that is used to generate those has labels, that’s great. However, there are a lot of themes out there that prefer this look, which is with a placeholder and no label, or they like floating labels that are actually just a div that’s been overlaid, or something along those lines. So it’s important to be able to change that if your site is stuck with that problem. So WP Accessibility will find those fields, and insert a label. Now, there’s some limits to that.
First of all, rather than being able to inherit the language of your theme, let’s say maybe your theme has 50 translations into different languages, it’s dependent on whatever languages WP Accessibility is translated into, which I don’t actually know how many that is right now. But it’s less than 50. But it’s at least giving you some context, it’s giving some labeling, it’s going to work in most cases. And the reason this is possible is because no matter what is going on with these fields, the one thing I know for sure, is their name attribute. Because the name attribute is required for any of these fields to work with the PHP.
If you submit it with a different name attribute, that data is not going to be tracked by WordPress. And so I look for the name attribute, I check whether or not there’s a label associated with both implicitly by wrapping, or explicitly by association. And if not, I add it. It’s a, it’s a handy feature. But again, it’s fixing a problem that ultimately should just be fixed in the code.
Amber Hinds 26:22
So, someone asked on this note, will this work for third party modules or widgets? Or probably not, because it’s really only going to work with those specific-
Joe Dolson 26:35
-All I can say there is, it depends. If you’re talking about something like Disqus, then the answer is no, because Disqus uses a completely independent form and submits to their own system. But there could be third party modules that are using the WordPress core comment system, but then revamping the way it’s displayed, and the way it’s managed. So I can’t answer that in absolute, all I can say is, it depends. Anything that’s actually putting something on your website, you know, that can be manipulated. It gets a lot nastier if it’s something that’s actually being inserted by like an iFrame, because then it’s not on your website, and you don’t necessarily have any access to that. So that can be limiting. And those things certainly exist as well.
Amber Hinds 27:30
So the follow up question was, for example, do you know how it works with Beaver Builder?
Joe Dolson 27:36
I do not know how that works with Beaver Builder. I, I could check. I actually have a contract right now to audit a Beaver Builder based site. I don’t think they’re using comments. So I don’t know that there’s anything to check there. But I can ask.
Jean Roth (Rotem) 27:57
I was thinking of something like forms, or emails, subscribe forms, that sort of thing. And in general, using something like your plugin, how does it, ’cause you you’ve mentioned, you know, core WordPress.
Joe Dolson 28:14
Right.
Jean Roth (Rotem) 18:14
But so many of us are using, you know, different types. I mean, of course, there are widgets as well. But, you know, plugins and, and, you know, different types of page builders. So if we are still using page builders, and we haven’t switched from them to say, Gutenberg, how does a plugin like yours work with those, those types of builds?
Joe Dolson 28:34
So, if it, if it’s, there’s always a lot of questions there as to just how extreme the page builder is. So there is, there’s site content, which is, you know, things that are just inside, say, a post or a page. And those things, you know, WP Accessibility will treat just the same as they do anything else. It’s only really able to find things that are core WordPress functionality.
So for example, if the comment, if the comment form has been replaced by Beaver Builder, and they have completely revamped it, and they’re actually submitting everything via a JavaScript request, and they’ve actually renamed the, the form fields, so they’re submitting completely something else, then I won’t be able to find it. ‘Cause I just don’t know what it is. But if they’re using the core code to insert their data, then it will be found. Page builders are incredibly complex. Every single one of them is unique, they have different quirks, different characteristics, different limitations.
And that includes Gutenberg. Gutenberg is not a perfect solution by any stretch of the imagination. One of the biggest problems with all of the page builders is that you are restricted in working with them functionally, to the choices that they allow you to make. I was recently assessing another Elementor site that was using a series of just post documents, they were all, they were in a slider, which is ugly and horrible, but that’s where they were, and every single one of those posts had four links. They had an empty link, that was a, a touchable, a touch surface for using swiping, they had a link on the image, they had link on the title, and they had a “Read More” link. The link on the image was redundant, it was identical to the one on the title. And the link on the swipe surface was empty. And then the read more was meaningless, because it just said, “Read More.”
This is terrible interface. They also had 12 slides in this, so that’s 48 links to get through 12 posts. So one of the obvious things, like well, there’s an option to turn off the “Read More” link. Great. That’ll reduce it by a third, by a fourth at least. But you know what they actually did? They just took out the text of the Read More link, the link was still there. So from an accessibility standpoint, it had actually just gotten worse. Now there were two empty links, and the useless one, the useless duplicate, and the one that I actually wanted. So that’s a limitation of how that page builder is choosing to do things. And they’re all going to come with similar kinds of problems that just because it says that it’s disabling something doesn’t mean it’s actually removed it, it just means it’s hiding it in some way. And that might be gone, but you can’t really count on it. And that to me is one of the biggest frustrations of working with any of these page builders is that you don’t really know what’s going on behind the scenes.
And accessibility at a deep level depends on knowing what’s going on beside, behind the scenes. So I’ve mostly already talked about, at this point, the features that WP Accessibility has that are actually correcting problems with themes. There are additional things I have in mind to look at that would add things. But I’m actually more interested in exploring areas where I can improve core functionality, things that are actually permanently useful. One of those is going to be providing the ability to search the media library on alt texts. That’s uh, a thing that’s under debate to include in WordPress core, but there are some massive performance problems with it on large libraries, which makes it a problem to just include by default. But I’m going to talk about some of the additional things that are available in WP Accessibility that enrich the site. For example, there’s this support for long description. The longdesc attribute is one that’s never really been supported by browsers.
Joe Dolson 33:19
It’s a method for an image to get an expanded description, because an alt attribute is really quite limited. It’s, first of all, a screen reader really needs to read the alt attribute, so if there’s a lot to be put into it, it can get really overwhelming. A long description is intended to be a user choice, you can either view it or not. But there’s no actual browser interface for them, they’ve never really been properly supported. So this is adding a means to display a description in a relatively subtle way for an image.
And I do this by having just a little information link that is labeled for screen readers, as long description, read more, I don’t remember the actual text, and then it shows a more full description of that image. So that you can toggle that on and off and get the access to a more detailed version. This is particularly useful if you’re trying to describe, you know charts or graphs that have not actually been made into an accessible format. Because accessible data is really quite a challenge. And a lot of sites have tons of those sorts of things, and no budget or means to replace them all with a more accessible format. So this is just a way of being able to add some additional information to your site on a selective basis.
And then, my least favorite feature of all, which is the accessibility toolbar, which I, you should probably not use this in general. This is only intended to be useful if your website, by default, has a font size that’s just way too small, or way too difficult to read. The ideal is you should just have a website that has a good sized font, and has high contrast. But it does work. I’m leaning over to the side, because I’m, I’m reading off of a separate monitor. And this particular area of the screen is behind my other monitor. So I have to dive over here, so I can see what I’m doing. But it’s very simple. It just enables a high contrast mode. And it enables a large font size. And you can turn those off and on. And they are tracked with cookies, so they’ll be remembered for your next visit or for your next page. And all of that is stuff that can be customized, they’re just enqueued through style sheets, or you can override them with your own CSS because they’re just CSS driven.
And so you can get a perfectly good result with that. It’s just that most of that is in, is features that people already have through their browsers or through their assistive technology. Now, high contrast is a mode in most operating systems, and people who need high contrast, more often than not have it turned on. So this is only really useful if your website has very, very low contrast. So people who don’t normally need high contrast will be like, “Oh, I can’t read this, I need to turn on this high contrast mode.” Similarly, people who really need text to be zoomed in, will always have to need their text to be zoomed in. That’s just the way they operate on the web.
So again, that’s only useful if the font size on your website is so small, that people who don’t normally need that will want to enlarge it. So I try and discourage use of that as much as I can. And I have no intention of adding any additional features to it. Those two are as much as I ever intend to expand it to, though one of my most common requests is to add additional features to that toolbar, you know, “why can’t I use this? Why can’t I do that?” You know, “this other plugin has these features. Why don’t you add those?” It’s like, no, I’m not going to add those. [Laughs] That’s not what this plugin is about. There’s a part of me that regres- regrets ever adding that feature, but it’s very difficult to ever take features away from a plugin.
Amber Hinds 37:35
So someone has asked, why did you make the font size toolbar toggle between two sizes, rather than cycled between a larger number of sizes?
Joe Dolson 37:45
Mostly for simplicity. It gets quite complicated to track things when they are getting to be a whole bunch of different sizes. And I still believe strongly that really, the only reason this is useful is to just have one significant increase. You know, I’ve seen a lot of font resizing tools that have many, many steps. And you, you increase it to one step up, and it gets a tiny bit larger. And, you know, I’ll, if, if I need to see something better, I’m going to press Ctrl plus in my browser. And that’s going to be a more, even more reliable increase, I know exactly what it is, it’s predictable, I can adjust it on the fly for any given site to whatever I need, I don’t depend on somebody’s tool.
So, I don’t feel like there’s a lot of benefit to making that feature more complex. When, from a practical standpoint, there are existing tools that everybody already has that do the job better. The only thing that this really helps is extreme cases where your website is remarkably worse than the average, or the exception case where people have a need for this, but are not aware of how to do it on their, on their own browser or with their own operating system.
And it’s not that that’s an absolute zero case. Specific target markets, if you’re, if you’re working with a population that’s using a website that has a very low level of technological awareness and competence, then that might actually be really useful, because this is the only website they’re going to, they don’t use a computer normally, they aren’t comfortable with that, they just need to tweak it for themselves on the fly. That might well be the case. But, as, on term, in terms of kind of a global usage, it’s not something that really works that way.
Amber Hinds 39:53
Have you found, have you found that it’s reliable at catching, like both the contrast mode and the font size is reliable at not missing elements?
Joe Dolson 40:03
Contrast mode is pretty reliable. The biggest complaint I get about that is usually the fact that people have these giant images that take up most of their homepage that are background images. And one of the things that all high contrast modes do is wipe out background images. And so they get like, “Oh, my God, what happened to my big background image,” and I’m like, “it got wiped out, that’s what high contrast mode does.”
The font resizing, however, is not at all real reliable. It is incredibly unreliable. [Laughs] And that has to do with the fact that websites use such an incredible diversity of ways of sizing fonts, like any given website with, you know, a dozen plugins, the theme might size it in REMs. The, they’ll have a plugin that’s doing pixels, they’ll have another plugin that’s doing EMs, and something else that’s doing percentages. And, and in many cases, they’ll actually have different plugins that are using more than one unit across the plugin itself. And those all have different mechanisms for resizing.
So, in order to make that really reliable, what I would hypothetically need to do is parse over every single element on the page, figure out its unit, and then figure out an appropriate way of resizing it. And I have not chosen to do that, because I don’t consider this feature to be worth that kind of effort. Compared to the much, much lower amount of effort somebody would have to do to write a custom style sheet that just resizes the things they actually need resized in the way they need them resized. It’s one of those things where I could put in an enormous number of hours and make it reliable, or somebody else could put in a couple of hours and make their site reliable.
Amber Hinds 41:59
Yeah that makes sense. So there’s a couple more questions. So I’m going to skip one, because the second one is related. And then we’ll go back to this other one. So, question is, did you say if a user knows about control plus and control minus, the user can always use that instead of your font size toolbar? So, it might be worth demonstrating how that works. And if you’re on a Mac, it would be command Plus.
Joe Dolson 42:24
It would be, yes. So, this is, in fact, currently zoomed in. And let’s see, this is, I’m on Firefox right now. Yeah, okay, this is Chrome. Alright. So, I’m going to demonstrate it twice, because I have both Firefox and Chrome up and I have them configured differently. So this is Chrome. And in Chrome, this is a, what’s called a, just a browser zoom. And so it’s zooming everything. And it’ll initiate responsive modes as it gets to certain heights of size. So as you can see, like this, the menu just disappeared, because it got triggered by a responsive mode. And I’m just pressing Control plus. And here at 400%, we’re getting into the range where people with low vision are likely to actually be viewing their websites. This is a very, very realistic font size for a person with low vision. And then I can hit Ctrl, zero, and just drop it right back down to the original.
Amber Hinds 43:36
It’s worth mentioning that there’s a WCAG guideline, which states that everything on your website needs to be able to be resized up to 200% without losing content or functionality in order to meet the Web Content Accessibility Guidelines.
Joe Dolson 43:56
And that’s a very key thing that can be, can be a pretty major problem for some websites. And now, that’s specifically talking about, what that is mostly referring to is things like referring- uh, that sentence wasn’t going anywhere. I’m just gonna start over. So this is now Firefox, and in Firefox, I have it config, configured for text zoom. And text zoom is a mode where it only increases the size of the text. And this is going to more approximate what somebody might experience if the way they’ve tweaked their own experience is to modify their operating system’s core font size, or their browser’s core font size.
So this isn’t changing all of the spacing and it’s not going to trigger responsive mode, it’s just going to increase the size of the font. And so, it basically works the same way. This being 2021, it’s been pretty carefully laid out so that it doesn’t introduce problems with overflow. But there are lots of websites out there where if you’re using text zone, zoom, you will very quickly identify problems. And similarly, you can then control zero, it’s back to normal. And this, this, I find is just a very useful thing for anytime you come across a site that’s just a little bit too hard to read. And as I’m, you know, getting well into my 40s, that becomes more and more common of a thing for me to need to look at.
Amber Hinds 45:37
So, do you have any thoughts on, because I always think this is worth, you know, discussing, like, how prevalent, because you said, well, people can just zoom in on their browsers, wow commonplace it is to know that this is possible.
Joe Dolson 45:55
I would say it’s extremely common. And one of the things that makes it very common is the practical thing, that, people who need accommodation, who need any kind of assistive technology, are struggling, I mean, they, they are actually fighting with the technology to make it work for them, and so one of the things that comes out of that is exploration, and research, and trying to find a way that they can make things better for themselves. And that’s one of the things where having website tools is actually a real weakness. Because it’s a terrible user experience to be like, “Well, on this website, I can actually use, because I can increase it, but I can’t use any other website.” It’s actually going to be better, in the long run, for them to actually have to sit down and learn how to improve their experience on all websites by using the existing tools they have.
And I mean, it sounds, in some ways, unkind to say, “No, you just need to learn how to do this.” But it’s actually going to be better in the long run. You know, you can’t really insert a tool on every website in the entire world, and say, “This is the way it’s going to be best.” It’s like, well, we’ve already got those tools, those tools exist, you have them, we can teach you how to use them. So that’s a good thing to have in an accessibility statement on your website, is just some basic information about, “if you don’t know about this, this is a way you can increase the font size, this is a way you can adjust the contrast, these are options you have available to you in your existing environment, this is a, this is how you disable animations by tweaking this feature,” you know, all of these exist in the operating system or in the browser. And that’s definitely, in my opinion, a much, much better outcome for the users, is to just be able to know how to do this for themselves.
Amber Hinds 48:01
So the other question we had was, I think it’s going back to, you mentioned how to mark links that open in a new tab or window. “Could you show that again, and do you have documentation on how to do that,” it, was the question.
Joe Dolson 48:18
Um, documentation on how a link should be marked about the fact that it opens in a new tab?
Amber Hinds 48:27
Mhmm.
Joe Dolson 48:30
There’s definitely documentation for that, I don’t have a link handy, but, I mean, the, the essential characteristic is that it needs to be something that is clear. The ideal is literally to write into the link “opens in a new tab.” Because that is the thing that’s most accessible to everybody.
A common substitute is to inject an icon into the link that uses an external link type of indicator, and has an accessible alternative text behind it. That might be a span hidden, a screen reader text, or it might be an actual image with an alt attribute that says “opens in a new tab.” That way it’s available to screen readers. It’s visually available, but only if you can actually understand what that icon means. Which is learnable, but it’s not, it’s not the ideal choice. I personally am somebody who really struggles with icons, I do not remember what they mean. So, I really resonate with this idea that it’s frustrating having everything indicated just by icons.
Amber Hinds 49:47
So, we just submitted a plugin for review that’s new window warnings, that’s all it does. Like, you activate it, and it does it, and we have screen reader text, we have an icon, and on hover we also pop up a tooltip that says that. So, hopefully that’ll be on .org soon, but if you’re looking for some documentation, also this, I posted a link in the chat to w3.org, that has some examples of how you could code this. Also, if you’re a developer interested in that.
Joe Dolson 50:19
Yeah. And you know, tooltips, that certainly, that adds a little bit more availability. It’s still, you know, it’s going to be limiting unless you also added touch sensitivity for it. But, you know, there’s a lot of, there’s just a lot of things to catch, which is why in general, I recommend, A, use it as little as you possibly can, and B, just write it in text, if you can. And remember, the fact that a lot of people will open things in new tabs, because that’s what they actually want. They just want to be able to choose when something opens in a new tab rather than just be forced into it.
So, I think, you know, I’ve probably talked about this plugin enough at this point, I don’t know, I haven’t covered absolutely every characteristic of it. But you know, I covered the major things. This removing title attributes used to be one of the really major features of it. But the fact is, WordPress doesn’t have a lot of title attributes anymore. So there’s not much to remove, which is great. So I’m happy to answer any questions about WordPress core or about this plugin as, as they come in. And I can-
Amber Hinds 51:33
Well, while we’re waiting for other people, I might ask you, is there any big accessibility things coming up in core that would be interesting, or that you can give us a sneak peek on? I kind of occasionally lurk when the, on the Friday meetings, but [Laughs]. So I know that’s a way to get a preview, but I don’t know if you have any other thoughts for people on that.
Joe Dolson 51:55
Yes. So, well, right now, what we’re really kind of, this is very early, because it’s, right, post the 5.8 release. And so it’s, we’re in the kind of 5.9 scoping stage. The, the, probably the biggest change in 5.8, was the removal of infinite scroll in the media library. And that was really just stage one of a larger project to revise the management of images in the library. Because the reality is that infinite scroll was basically a kind of crappy substitute for having any real way of filtering images. And so, the goal is to try and iterate beyond that, to kind of solve pain points in finding images while also making it accessible. Because infinite scroll, while it was an efficient way, for people who could use a mouse to find images for, recite it and could use a mouse, to find images, it was crappy, it was absolutely terrible for absolutely anything else. So that’s one focus.
The other big thing is more or less, I have to say, just playing keep up with the block editor and what it’s doing. Because that’s kind of one of those, it’s an area where we don’t really have a depth of expertise in the code to really keep on top of it, it moves rapidly, it changes things on both the front end and on the backend. And, so, that just feels like it’s an ongoing challenge to keep up with. And, of course, I don’t know for sure exactly what features of it will end up in 5.9. So we don’t even know exactly what to work on. But that is definitely one of those ongoing things. Other than that, I think we’re really just trying to address as much as we can in terms of getting the backlog of general admin accessibility issues worked through. In the crush of the last few years, and the degree to which development has shifted over to the block editor, there’s a lot of tickets that have just kind of set, sat there and not gotten dealt with because there were bigger issues to mess around with. Getting the block editor to actually be functional was such a higher priority. So we’re trying to really catch up on those.
Amber Hinds 54:45
This might be a great time for you to pitch, if somebody wants to contribute or volunteer to help, what’s a good place to start if you’ve never contributed to core before?
Joe Dolson 54:58
Um, I mean, so, the accessibility team has an extremely broad purview. Because practically speaking, it’s documentation. So, anything that’s in help hub, anything that’s in training, anything on WordPress.org, in general is something we can conceivably be touching. Because we need to make it better. Um, it covers the user experience, so anything that’s an accessibility problem on the backend. And that can be just, that can be testing things. Like, one of the problems with some of these older tickets is, you know, it’s been four years, and like, tons of stuff has changed.
So we have to completely retest, and figure out whether this is even still a problem. Having more people who are going through tickets that are old, and you know, they might have hundreds of comments on them and have been discussed at length. And we have, we don’t even know whether it’s still an issue because of the number of other things that have changed.
Amber Hinds 56:01
Is that like screen reader testing? Or?
Joe Dolson 56:05
Frequently. Um, but a lot of it, it, frequently, it’s compatibility testing. Like we might have bugs that relate to a specific problem in a particular browser. And it’s like, well, that browser has now released 47 new versions, so, and, the screen reader that the problem was related to has released six new versions. So, is this still a problem? We have to find out. So people doing testing is always hugely valuable. People giving feedback on outstanding tickets, that’s always valuable.
We have weekly meetings on Friday mornings, mornings for me, at any rate. Uh, it’s 1300 UTC? Or is it 15000, 1500 UTC. I always struggle on that one. And so, the first hour is always just bug scrub. And there’s a need for people to be looking at these issues outside of the bug scrub, because a lot of that, we go through the bugs, we look at something, and we’re like, okay, yeah, this really needs to be handled. And then we need to find time to actually do that. And the more people who are involved in that process, the better. And everybody can give feedback. You know, it’s an op, it’s an open source environment. And a lot of the problems are really just in figuring out the scope, figuring out who is being impacted, how much they’re being impacted.
We are always, love to have people participating. It doesn’t have to be during a meeting. It can be, you know, ping somebody and say, “Hey, you want me to look at anything?” Sure. Here’s a list. We’ve got 500 tickets. But I know that that’s also overwhelming.
Amber Hinds 58:12
Uh, so someone asked, following up on the long description, do you think browsers will eventually support this, or is that feature permanently dead?
Joe Dolson 58:20
I suspect that it’s pretty permanently dead. I mean, it’s been in the “not fixed yet” pool for well over a decade. And it doesn’t really seem likely that it’s going to be fixed by the browsers. And that can change at any time, but I, I think there’s an element where, it’s not used enough. I mean, browsers, bas, base so much of their decision making on what is actually being used in the real world. And, you know, it’s kind of a chicken and egg situation. It’s very circular. Nobody uses long description because it’s not supported, and because it’s not being used, they’re not going to implement support for it.
So I’d like to see it used more because that actually might cause browsers to decide to fix it, or create an interface for it because I mean the fact is it’s not exactly accurate to say it’s broken. There is literally no interface for it. It is not exposed. But I was recently in a chat where the discussion was, what is the preferred way you’d like to see an alt attribute described for a particular type of image, and it was you know, for complex images and whatnot. And a lot of responses were, “well what I want is the alt attribute to be a short brief description, and then I would like an optional description where I can get all the rest of the information,” because it’s extremely inefficient to go through a page that has a lot of complex images and every single one, you have to read the entire description of it the whole way through every single time. Because that’s one of the things that we, as sighted users, speaking for myself, are privileged by. I can scan through that page really quickly, I don’t need to absorb everything on the image to get a sense of what it is I just skim right by it, go all the way through, alright, now I know what’s on the page.
But users with, on screen readers don’t have that privilege. They have to read whatever they’ve been given, whatever, whatever information has been chosen to be passed to them, is what they have to depend on. And what they would really like, is to have options to be able to skim better. So much of web accessibility, you know, having a good headings hierarchy, having navigation, navigational landmark regions on the page, having link texts that clearly define where they’re going, having lists of items, actually using unordered lists or ordered lists, is about making the reading process more efficient. The information can be gotten with none of that present, it just becomes really inefficient and difficult. And so, everything about the whole goal of how we try and structure everything is about saying, “Okay, how can you get the information you need, as quickly and efficiently as you can?”
Amber Hinds 1:01:39
How do you feel about, so, so we frequently advise, like, if it’s a graph, for example, that sighted people will also benefit from perhaps a data table, or, right? A, a sentence version description of what’s being shown in the graph. So, we’ll frequently advise to either include it, or potentially include it in, of course, an accessible, but an accordion, which would then allow someone to jump to it, because maybe there’s a heading or they can choose to expand it or not, below the image. How do you feel about doing that, versus what you’re doing with the overlay and the, the, you know, click on the image?
Joe Dolson 1:02:22
I mean, they both have reasonable benefits. In an accordion, it’s actually very similar, practically speaking, because, assuming it’s a traditional accordion, you can only see one space at a time anyway. So it is, it’s not covering the image, but it is changing the, the space that’s available and what you can actually see. I do think that, in an ideal case, you know, you have both items present, or frankly, like in the case of something like a data table, a chart or graph, if the data is reasonable to express without the image that is superior. It’s not always the case, because sometimes a graph can convey things that are more complicated, and should probably be realized in some kind of accessible data visualization.
But even then, they should be backed up by something that’s simpler and more straightforward. The reason in, in my plugin that I actually have it done via an overlay is purely because my goal has, was always to minimize disruption of existing websites, the idea that you could install this, and it wouldn’t be changing much about the way your site looked or operated, it would be adding an additional layer. So, you know, I could have made it so that it pushed information below or, you know, something like an accordion would actually be really pretty invasive, you know, it could change the way the site works pretty significantly.
That obviously also has some limitations. I mean, you know, sometimes the images are small, sometimes the button to expand it covers some key piece of information. That can all be tweaked by CSS, though I don’t know if people actually do that.
Amber Hinds 1:04:25
So, uh, someone posted in the chat “speaking of alt tags, most images I use, if any, tend to be illustrative. I’ve usually told to skip alt tags and I’ve noticed differences in this between themes. But do you have different advice? Is it counterproductive or not advisable to add something like “illustrative?” I’m guessing she means “illustrative” would be what you would put in the alt.
Joe Dolson 1:04:54
Um, I would definitely never put just the word “illustrated” in any image. Because it doesn’t actually tell me anything. I’m trying to imagine the scenario accurately. But my feeling is that either the image is explained in the associated text and doesn’t require anything, or that you actually need to describe the image in the alt attribute. You’re rarely going to go wrong by having a descriptive alt attribute. I mean, worst case scenario is it’s a little extra verbose, which is, can be annoying, but is, the information is there, and I will always bias towards have the information present.
But having text there that doesn’t actually convey information, because just saying to, to a screen reader user that this is an illustrative image doesn’t tell them what it is. Like, what, is this the illust- is this illustrating the stuff you just talked about? Is that illustrating something else? How is it illustrating this? Is this is like an example of what you’ve just talked about? It just it doesn’t tell the user enough information to be helpful, in my opinion. I hope that helped.
Amber Hinds 1:06:19
Yeah, we tend to say almost no image is decorative. Like, there’s a reason why you chose a man on a beach and not a girl on a mountain or something, right? Like, yeah.
Joe Dolson 1:06:29
Yeah, I mean, I think, I frequently tell people that it’s more important to me that you thought about what the alt attribute should be than it necessarily is what the alt attribute actually is. But, you know, a decorative image is probably more rare than anything else. I do think, you know, purely ornamental things like just, you know, a separator between two things that’s kind of filigree, that’s, that’s legitimately decorative. They’re also really uncommon, now. They used to be everywhere.
Amber Hinds 1:07:09
Oh, yeah. So there’s some extra context, she says, I was thinking, e.g., “decorative colon vegetable smoothie,” for related content on that page. So I think you would just said vegetable smoothie.
Joe Dolson 1:07:20
I would just say vegetable smoothie. Yeah, I would not, I don’t, unless the descriptive term conveys a unique sensibility about the image, I would exclude it. So you know, I don’t ever use the word image, graphic logo. And I wouldn’t, I wouldn’t choose a word like, descriptive or illustrative. However, I would use a word like-
Amber Hinds 1:07:51
-Like “hand drawn,” do you do that?
Joe Dolson 1:07:53
I might, I could conceivably do that, you know, something that has a very particular design characteristic that conveys a sense. I was, I was thinking of, and the word is, is not coming to my mind right now. The type of image which exaggerates people’s features for humorous effect.
Amber Hinds 1:08:13
Alicia said collage.
Joe Dolson 1:18:15
No, that’s not what I’m thinking of.
Matt Wilson 1:08:16
You’re thinking of a caricature.
Joe Dolson 1:08:19
That’s the word I was trying to come up with. Yep, thank you very much. I could define it, but I couldn’t quite bring it to mind. But caricature, like that really defines a very unique sensibility. Similarly, like, if it’s a, you know, a common layout process, for example, is image, name of person as a heading, bio of person, perhaps beginning with their name. In that case, like, also saying “image,” with an alt attribute with just their name, that’s terrible. Because then it’s just being repeated over and over again.
Describing the person, that can be useful. And if this is a person of the person in, you know, a clown nose and rainbow wig, that says a lot about the person on this banking website. ‘Cause it’s like, that’s, that conveys a huge amount of character about the person that is useful for people to know. Like, obviously, this is not your, not somebody who’s trying to give the image of being your staid, traditional banker, they’re trying to be whimsical. Whether they’re actually whimsical, totally different question.
Amber Hinds 1:09:23
Yeah, yeah, that brings up whole discussions about gendering people and descriptions and things like that. That is, that’s, you’re saying we could probably have a whole Meetup about how do we describe people in images.
Joe Dolson 1:09:38
Well, and that’s actually one of the reasons that like, I don’t generally consider, like, in my auditing, I don’t consider the content to be something I want to tell them what to do. I will tell them ideas and give them concepts of how it should be conveyed but ultimately like, this, this description of this image, you need to talk to the person it’s a description of. They need to okay that. I as a web designer, I as a developer, I as a consultant, no, that’s not my job. Graphic of chart? Fine. I’ll describe that.
Amber Hinds 1:10:19
Yeah. There is a follow up question about missing it if we addressed removing target attributes from links, and I think we did, but I don’t know.
Joe Dolson 1:10:34
I did. And that’s, that’s a fairly straightforward feature that literally just strips the target attribute out of all links. It, technically, there is a selector, you can add to a link to allow it to exclude it. I don’t remember what it is off the top of my head, but it isn’t, it, there is an option. And that’s kind of necessary because of that characteristic, where you might have a link that’s in the middle of a form and is necessary information to that form, but could disrupt the submission of the form. Ideally, now, you know, ideally, all of the information you need to read for the form should not be inside the form, it should actually be in some other container, because it’s not part of a form. And ideally, your form shouldn’t lose data just because you’ve left the form. But, we all know, the reality is that that might not be the case.
Amber Hinds 1:11:29
Oh, so I have a question about core. Looking ahead, and some of the newer guidelines with regards to passwords, and not asking people to re-enter information that we should already know, right? So for example, if somebody resets their password, we’ve already asked them for their email address, when they click to go to login, we should already have- or their username- we already have that filled in, right? Is that, are those features that are, because I think those kinds of things are being mandated by WCAG now, right?
Joe Dolson 1:12:07
They are, yeah. And that is certainly something to think about. There are some caveats there, of course, because one of the mechanisms for remembering that is actually allowing the browser to remember through, through auto completion. And username fields are fairly common auto completion fields, so that’s not necessarily something that WordPress has to resolve, as long as WordPress doesn’t prevent it from being enabled by the browser.
But there is actually a whole variety of things that WordPress, that we are actually looking at. One of them is remembering the user’s language, in the process of doing the whole forgotten password thing, because that’s something that’s easily lost. If a user, you know, their their language for the site is German, but the core language for the site is English. And they can easily get dumped into English when they do the Forgot Password process. So that’s one of the things that’s, that’s on on on the list for 5.9 that is still a little bit uncertain. Because there’s complexities in solving that.
Amber Hinds 1:12:33
As long as the autocomplete function works, that that would be considered a success?
Joe Dolson 1:13:27
I think it would be considered a success. That doesn’t necessarily mean it’s ideal. I mean, WCAG is really just a starting point. You can always go beyond it. That, but not, you’re not failing WCAG because you haven’t done absolutely everything you possibly could to ensure something is available. You’re failing it if you’ve actually blocked it from being possible in that particular case. And I’d have to, you know, I’d have to look at how that process currently works and exactly what the wording of the phrase is to really make, like, a definite call over it, because I haven’t I haven’t looked at that recently.
Amber Hinds 1:14:15
So Peter asked, what are your thoughts on the Accessibility Ready filter for themes in the repository? There are some excellent themes that have a high level accessibility but don’t have the accessibility ready tag, probably because the developer just hasn’t gone through the process. Right now the repository indicates only 116 themes as Accessibility Ready.
Joe Dolson 1:14:34
So, the accessibility ready tag was probably my first big core WordPress project. I wrote that. I set that up. And it is complicated. So the reason there are a lot of good themes that don’t have the Accessibility Ready tag is, there are two major reasons. One of them is a theme that was already pretty accessible before the guidelines were written, but for backwards compatibility reasons can’t easily make a change that is required in order to have the Accessibility Ready tag.
One example for that is, it is mandatory that your links in content regions, such as comments or post content, that sort of thing, must be underlined. If a theme didn’t already have that, there have been a number of authors who were hesitant about just making that change, as you know, as a fiat on all of their users, and that prevents them from having the tag. But that doesn’t mean that their site is terrible, or that their theme is terrible. The other reason is that the whole theme review process is extremely painful. And it’s very long. And going through the Accessibility Ready process makes it longer, because you have to go through an additional layer of review to be approved for that. And I mean, the theme review team is, like many of the themes, it’s all volunteer- of the teams, it’s all volunteers, they don’t really have that much time. And themes are very complicated. And there’s a lot to review.
So I think there are a lot of themes that probably have made the decision to fix a lot of accessibility problems, and then release that in an update, but not bother going through the whole process again. The Accessibility Ready requirements themselves are really just kind of a set of things that are targeted as ways that a theme can be as accessible as possible. You know, nothing about that process is intended to give the impression that this theme is automatically going to give you a website that’s WCAG compliant, it’s just going to give you the best possible opportunity to be WCAG compliant. So that’s always been a challenge with the accessibility ready program. I hope that answered your question somewhat. Did I miss a part?
Amber Hinds 1:17:10
I think that was a pretty good answer. So, you know, the follow up question which people always ask, if, aside from obviously custom, right, if you’re starting out, and I hate to put you on the spot, but are there themes that you recommend to people that are good, aside from those Accessibility Ready?
Joe Dolson 1:17:28
No, there aren’t. I don’t, I don’t usually make recommendations in that way. I personally start with Underscores. And that’s just because it offers a fairly reasonable framework that I can tear apart pretty easily if I don’t like something, because that’s, you know, actually building from scratch is more work than it’s worth, I mean, then you have to make a lot of decisions that are really extremely rote, and extremely well established in terms of patterns. And Underscores gives a good base for just getting started. And then you can start applying whatever accessibility styling and other criteria you need to it.
Amber Hinds 1:18:15
And for the non-developers in the room, it might be helpful to give a little context on Underscores.
Joe Dolson 1:18:19
Underscores, I don’t think Underscores is being maintained anymore, but it was a project that was basically, the idea was that it was a theme that was just a base. It’s intended to be forked and used to create custom themes. It’s very simple and has almost no CSS already in it. Because it’s, it’s basically just giving the barest bones of orientation organization. So it’s got a functional menu. It implements some things like, you know, uh, pretty sure, if I remember correctly, that it implements a responsive menu toggle, though, I can’t remember now whether I added that or not. So, it has a lot of the basic fundamental needs of a website, but it doesn’t impose a lot of styling on you. So you’re not like trying to figure out, “where did this extra three m of padding on this element come from? I can’t figure it out. There’s 12 layers of nesting here.” It’s simple.
Amber Hinds 1:19:33
So it’s good if, yeah, if you are, if you know how to, and enjoy, building custom themes. If you’re looking for a starter theme, then that would not be a good place to start. If you don’t know how to write CSS and things like that.
Joe Dolson 1:19:43
Yep, it definitely requires you to know CSS. It’s not going to work otherwise.
Amber Hinds 1:19:50
Uh, so, question, s underlining links a WCAG requirement, or only a WordPress Accessibility Ready requirement, or both?
Joe Dolson 1:19:58
It is, so the actual WCAG requirement does not specifically require underlining links, no. That is an Accessibility Ready requirement. And that’s one of the many reasons why, you know, we get pushback on it periodically. It’s because it’s not required by WCAG, and we’re like, yeah, that’s, this is not a WCAG requirement. There are requirements for being able to distinguish meaningful elements and controls. So you do need to be able to identify different elements on a page for WCAG That is, and that is something that can be fulfilled in a wide variety of ways. The accessibility ready theme decision was that, why would we allow people to do whatever random weird choice they want, when there’s actually an extremely well established, usable, consistent model for this?
I mean, the reality is, in all usability testing and expectations, underlined links are very readily understandable and extremely identifiable. So much so that if you in fact underline any other text on your page, people will tend to click on it. Like, you can do all sorts of heat map studies, where if you’ve got a bunch of underlined stuff that isn’t linked, you will find clear evidence that it’s being clicked on, on a regular basis. Um, but it is not technically a WCAG requirement.
Amber Hinds 1:21:39
Yeah, so I think the guideline, specifically on this one is that you can’t use color alone to denote links. And so, so you could maybe pass if it was like, all my links are bold and italicized, and I don’t bold and italicize anything else.
Joe Dolson 1:21:57
And one of our judgments on that is that we actually, you might not bold or italicize something, but this is a content issue. And you cannot prevent the people who are using your theme from bolding and italicizing everything. You also can’t prevent them from underlining things, but that is a, on the whole-
Amber Hinds 1:22:16
-Harder to do?-
Joe Dolson 1:22:17
-Harder well, and, and it’s, it’s more reasonable to require people to do the thing that is most common and expected, and accept the fact that that will still result in some problems for some sites, than allow them to do whatever random thing they want to do, which will also still result in problems on some sites.
Amber Hinds 1:22:39
This is, I just, ope, I might not have gotten it for everybody, hold on. I’ve got a link, that’s the WCAG guidelines on failing color alone as it relates to links, if you’re interested in the documentation on that.
Joe Dolson 1:22:56
Technically that’s the techniques document.
Amber Hinds 1:22:58
Oh, yeah. Well, yeah, so it’s, it’s, it’s not the guideline, it explains how the guideline, there’s links over, and this one might be did I link to 2.0? That might be a 2.0 technique not 2.1.
Joe Dolson 1:23:12
Well though, it actually doesn’t make any difference because it’s a 2.0 criteria. Um, and 2.1 just extends 2.0.
Amber Hinds 1:23:18
Yeah.
Joe Dolson 1:23:19
But actually, that’s, it is an interesting question, that, the distinction between normative and non-normative documents in the W3C model. The guidelines themselves are considered “normative,” in quotes, which simply means that that is the only thing that is actually the recommendation from W3C. Everything else is explanatory and non-binding.
So, there are, and there are plenty of examples in techniques documents that are actually somewhat questionable. They’re not necessarily techniques that would today be considered recommended, but the reality is that WCAG 2.0 was written in 2008. And from there, things change. You know, I recently had the the luxurious experience of going in to work on a website that I built in 2008 that I hadn’t actually had any maintenance to do on since 2013. And was kind of like, “oh, wow, oh, wow. What did I do?” You know, it’s, it’s just, it can be really striking. And I would not say that any of the decisions I made were unreasonable for the time. That doesn’t mean that I like them now.
Amber Hinds 1:24:36
I think we all might have websites like that.
Joe Dolson 1:24:38
Yeah, we don’t need to talk about our oldest websites.
Amber Hinds 1:24:43
Yeah. So we’re at an hour and a half. Does anybody have any final questions for Joe? I know for people on the East coast, it might be getting a little late, so.
Joe Dolson 1:24:55
I’m certainly getting ready for dinner.
Amber Hinds 1:24:57
Well, it seems like maybe not. So, thank you, everyone. Thank you, Joe so much. It’s been wonderful. Um, if you have not joined our Meetup group, that is the best way to get reminders about upcoming events. I will post that link in the chat. So I highly recommend joining our Meetup group. And also the Facebook group. And we will post the recording on the meetup event, um, well, a link to it because it will be on our website with transcripts and captions once that’s available. Thank you everyone. Thank you very much, everybody.
Matt Wilson 1:25:42
Yeah, thanks Joe. Good job, Joe.
Joe Dolson 1:25:45
Thanks a lot. Thanks, Amber.
Amber Hinds 1:25:48
Thanks.
