#44 – Joe Dolson on How To Fix the Six Most Common Accessibility Errors on Your Websites

On the podcast today we have Joe Dolson.

Joe is a WordPress plugin developer, a core committer, and a web accessibility consultant. He’s part of the Make WordPress Accessible team, the team dedicated to improving accessibility in the WordPress ecosystem.

His recent presentation at WordCamp US entitled ‘Finding and Fixing the Six Most Common WCAG 2 Failures’, highlights some of the key areas where websites are not as accessible as they should be. The areas we discuss are:

  • low contrast text
  • missing alternative text
  • empty links
  • missing form labels
  • empty buttons
  • missing document language

Joe explains what each of these problems are, both in terms of how they can be fixed, as well as what people with accessibility requirements might experience when they visit your site.

We talk about how you can equip yourself with the tools that you need to diagnose these issues, and online resources you can use to discover more about website accessibility.

It’s Joe’s opinion that you’re better off making a start right now, carrying out incremental changes rather than attempting to solve every single problem that your website might have. Begin the journey and take it one problem at a time.

We also chat about the fact that there’s an ever growing legal compulsion to make websites follow accessibility guidelines. Lawsuits are going through the courts with greater regularity, so now might be the time to look into this topic.

That being said, Joe cautions against the use of tools which purport to solve your accessibility issues with minimal effort. A variety of pop-up solutions have emerged onto the market which claim that they can make your site compliant with almost no effort. Joe is adamant that these promises are almost always false and that there’s real work to be done on each website as they’re all unique and have unique problems to solve.

Typically, when we record the podcast, there’s not a lot of background noise, but that’s not always the case. Over the coming weeks, I’ll be bringing you recordings from a recent trip to WordCamp US 2022, and you might notice that the recordings have a little echo or other strange audio artefacts. Whilst the podcasts are more than listenable, I hope you understand that the vagaries of the real world were at play.

Useful links.

Joe Dolson’s website

Joe Dolson’s Twitter account

Adrian Roselli’s website

Leonie Watson’s website

Heydon Pickering’s website

Scott O’Hara’s website

The a11y Project

a11y Slack channel

axe accessibility testing tool

W3C Web Accessibility Initiative (WAI)

WAVE Web Accessibility Evaluation Tool

Tenon.io

popetech web accessibility testing & reporting

webAIM website

The WebAIM Million report

International Association of Accessibility Professionals: IAAP

Accessibility for Ontarians with Disabilities Act (AODA)

Transcript

[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Juke box is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, how to improve the accessibility of your WordPress website.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast, player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m very keen to hear from you, and hopefully get you all your idea featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox, and use the contact form there.

So on the podcast today, we have Joe Dolson. Joe is a WordPress plugin developer, a core committer and a web accessibility consultant. He’s part of the Make WordPress accessibility team, the team dedicated to improving accessibility in the WordPress ecosystem.

His recent presentation at WordCamp US entitled, finding and fixing the six most common WCAG 2 failures, highlight some of the key areas where websites are not as accessible as they should be. The areas we discuss are, low contrast text, missing alternative text, empty links, missing form labels, empty buttons and missing document language.

Joe explains what each of these problems are, both in terms of how they can be fixed as well as what people with accessibility requirements might experience when they visit your site. We talk about how you can equip yourself with the tools that you need to diagnose these issues and online resources you can use to discover more about website accessibility.

It’s Joe’s opinion that you’re better off making a start right now, carrying out incremental changes rather than attempting to solve every single problem that your website might have. Begin the journey and take it one problem at a time.

We also chat about the fact that there’s an ever-growing legal compulsion to make websites follow accessibility guidelines. Lawsuits are going through the courts with greater regularity. So now might be the time for you to look into this topic.

That being said, Joe cautions against the use of tools, which purport to solve your accessibility issues with minimal effort. A variety of pop-up solutions have emerged onto the market, which claimed that they can make your site compliant with almost no effort. Joe is adamant that these promises are almost always false and that there’s real work to be done on each website, as they’re all unique and have unique problems to solve.

Typically when we record the podcast. There’s not a lot of background noise. But that’s not always the case. Over the coming weeks, I’ll be bringing you recordings from a recent trip to WordCamp US 2022, and you might notice that the recordings have a little echo or other strange audio artifacts. Whilst the podcasts are more than listable, I do hope that you understand that the vagaries of the real world we’re at play.

If you’re interested in finding out more, you can find all the links in the show notes by heading to WPTavern.com forward slash podcast, and you’ll find all of the other episodes there as well. And so without further delay, I bring you Joe Dolson.

I am joined on the podcast today by Joe Dolson. Hello Joe.

[00:04:23] Joe Dolson: Hello.

We are at WordCamp, I nearly said WordCamp Europe. We are at WordCamp US 2022. We’ve got Joe on the podcast today because he is doing a talk at WordCamp US. Do you just wanna tell us a little bit about yourself? Why you’re on this podcast, but then stray into what your talk is about.

[00:04:40] Joe Dolson: Certainly So I’m Joe Dolson. I’m a WordPress core committer. I’ve been a contributor to the accessibility of WordPress for quite a long time. I think I first started contributing in WordPress 3.4. I’d have to look at my history to actually know that for sure, but it was somewhere around there. So today I’m talking about a study from the nonprofit organization, WebAIM, out of Utah, in which they looked at the top million homepages around the web. The most widely visited, heavily known webpages, and did a bulk analysis of the accessibility issues on those pages.

And, I’m going to talk about six specific types of errors that they found constituted 96.5% of all detectable errors using automation. And the things that that exposes and how you can work with consultants. How you should use your time and how you should use automation to solve problems.

[00:05:39] Nathan Wrigley: Can I ask how it is that you became interested in accessibility problems, given all the myriad things that you could have become interested in web? How did accessibility fall into your lap and create so much interest for you?

[00:05:51] Joe Dolson: So when I started my business in 2004, I started right from the beginning with the idea that I wanted to pursue accessibility in websites. And that was because when I decided to become a web designer, I wanted something that was unique about what I did. I wanted to do something that wasn’t just marketing. I wasn’t really interested in marketing. I’d seen a lot of that around and I’m like, boy, that, that just doesn’t seem like it’s socially motivating.

[00:06:21] Nathan Wrigley: Mmm.

[00:06:21] Joe Dolson: It doesn’t seem like it’s interesting. It doesn’t feel like I’m doing something worthwhile. So I had to think to myself about, well, what do I know already? What do I have a unique access to that can make my business be a little bit different? And my mother was the executive director of a nonprofit that provided arts access for people with disabilities.

And so for years, I’d had conversations at home with family when visiting my mother in her workplace about what people with disabilities needed and how the ADA worked, and how all of this sort of world needed to be constructed. So what I already had was a reasonably strong sensibility for why people with disabilities need access and the very fact of the modality of different experiences and different perceptions. And so with some study about the actual technical side behind that, I was able to pick that up relatively quickly. Which is not to say I didn’t make absolutely horrible mistakes in 2004 and five.

[00:07:29] Nathan Wrigley: It’s almost, it’s something that came from your, your background,. Your family enabled you to have some sort of prior wisdom. Most of the rest of us, I would imagine are coming at it pretty cold, and if we were to go back, I don’t know, 5, 6, 7, 8 years, I feel like nobody was really talking about this. I could be wrong. Obviously you were interested in it, but as a proportion of the people that were designing websites, I feel that accessibility was not on everybody’s radar. I would imagine that many, many of the websites out there were not accessible in any way, shape or form.

But it’s become a real talking point in the last few years and people are making much more of an effort. Obviously you’ve got your conversation, your presentation at the event in the next couple of days. I’m just wondering if you could outline for those people who, maybe they’re new to WordPress, maybe they’re new to web design and they hear the word accessibility and they just think, well, I don’t know what that means. Just, in the broadest possible brush strokes. Just let us know what the 10,000 foot high version of accessibility on the web is.

[00:08:31] Joe Dolson: So yeah, the 10,000 foot view. Accessibility, web accessibility, and the access to information for people with disabilities is about making sure that the content you’ve put on your website is interpretable to the most, the widest variety of senses. So for people who are visually impaired, that means making sure everything can be understood by what’s called a screen reader. That will look at the text content of your site, look at the code of your site and interpret that in voice production.

For people with hearing impairments, that’s about having captions for your video. It’s about having transcriptions of your audio files. So it’s really about recognizing that people have different ways of perceiving the world, whether that’s because of dyslexia, and they have difficulty with the way text is structured. Or it’s visually impaired, so that they literally cannot see your images and have no idea what that is. Your responsibility in sharing that information is making sure it’s available to multiple senses.

[00:09:40] Nathan Wrigley: Thank you.

Your talk is called finding and fixing the six most common WCAG, W C A G, two failures. First of all, what’s WCAG 2? And then if you wouldn’t mind elucidating what are those six most common failures? Maybe we just go through them one at a time, and if we, if we stray off into a conversation about each one of them, that’d be good, and if not, we’ll carry on from there.

[00:10:02] Joe Dolson: Sounds great. So the web content accessibility guidelines is a document coming out of the W3C, the worldwide web consortium, and it’s kind of the international standard for what is considered to be accessibility. Version two is the version that was published in, I wanna say 2008. So it’s not new. But it’s been then updated periodically since then. The current version is 2.1. 2.2 is currently a candidate. It is likely to become a recommendation sometime at the beginning of 2023.

And that just keeps incrementing different ways of looking at things and what is considered to be a standard internationally for what makes content accessible. It’s a very useful document. It is enshrined in law in a number of contexts. The US government’s section 5 0 8 is based on WCAG 2. A lot of international laws such as what the EU uses for their guidelines are based on WCAG 2. So being aware of these guidelines is pretty key.

[00:11:07] Nathan Wrigley: Just before we go into the six areas that your presentation is about. When you say that the things are enshrined in law, and you mentioned the US and the EU in particular, I guess there’s going to be a whole swathe of different responsibilities and things that you are compelled to do. You are in the US, so just give us an idea, just paint the picture in the US specifically, and we’ll just ignore the rest of the world for now, about what the absolute requirements are. So, in other words, if you don’t satisfy this, you are in breach of the law. So are you able to speak to that?

[00:11:40] Joe Dolson: I can definitely speak to that. And it’s definitely good that we’re narrowing that just to the US, because otherwise this would go on for hours.

[00:11:47] Nathan Wrigley: One country time. Yeah.

[00:11:49] Joe Dolson: So in the US, what we’ve got is section 5 0 8, which is part of the federal regulations governing the acquisition of software for government institutions. And that only applies when you’re getting funding from the federal government. So you’re only in violation of that if, for example, you’re a university and your website is funded by federal grants. And that is, 100% it’s based on WCAG 2.

There are a few tweaks that are not exactly identical, but basically if you’re violating WCAG 2 at what’s called level AA, there are three levels of severity within WCAG. There’s level A, AA and triple A. Triple A is usually very specific types of errors that apply to relatively small populations and mostly need to be handled if you’re specifically serving that population. The guidelines, the laws are around AA, which is gonna be very broad, but it’s still, there’s got a fair amount of meat to it.

The other law is the ADA, which is a 1991 law, and this may shock you, but at the time it was written, they did not directly address websites. And that does not mean that website accessibility isn’t covered by the ADA, and case law has repeatedly demonstrated through precedent, that yes, the ADA does require websites that are publicly accessible and commercial need to be accessible.

What is lacking in the US is any regulations that stipulate what that means, and that is a case where WCAG has not been brought into the legal bounds on these websites. And that is why you hear so much about so many lawsuits against companies for web accessibility. It’s because we don’t have regulations that allow anybody to easily look at their website and determine whether or not they’ve met those requirements. Really. the ADA stipulates your website needs to be accessible, it needs to provide this equal access. Figure out what that means.

[00:13:50] Nathan Wrigley: You just mentioned lawyers and that’s kind of an interesting place to go just for a moment. It feels like there’s two premises here. We could have the carrot approach, or we could have the stick approach and the stick approach, by that, I mean is the threat of somebody contacts a lawyer and threatens to sue you because your website is not up to scratch.

On the other hand, there’s the, uh, carrot approach, which is the kind of thing that I’m imagining you are doing. You’re involved in educating the community and, and making this stuff happen with a little bit of education. Do we need to fear the lawyers, the stick approach? Is that an increasing thing that’s happening? I mean, you see it in all other walks of life. People are sued for things that they haven’t done because people think they might be able to make a little bit of money out of it. Is that kind of on the horizon? Are people doing that? Do we need to be worried about the legal aspect?

[00:14:36] Joe Dolson: Yes, 100%. As recently as six or seven years ago, I would’ve said no, you don’t really seriously to worry about that unless you’re an international scale company. And that’s just not true anymore. And that’s directly because we don’t have those regulations. They’ve been slated to be added on many, many occasions, and keep getting canceled. They are currently on the docket to be created again, hopefully in 2023. But until that happens, we don’t really have anything that gives us a goal. And one of the things that regulations could come with is a schedule. A schedule of enforcement. That’s what certainly a lot of other places have done.

The province of Ontario created a document, the AODA, which is a set of laws within Ontario for what is needed to accessible, and that came with a schedule of enforcement. Instead we have a free for all. Anything could happen. And there are thousands of accessibility lawsuits every year. And a lot of them are just accident chasers effectively. They’re not people with a very serious concern. They’re just looking for a quick payoff. And that is a horrible, horrible scenario to be in because you might receive one of these demand letters, and there’s a very good chance you are in fact in violation of it, and it is legitimate, even though they probably wouldn’t pursue it in court, but you can’t count on that. So it’s, it’s a very unpleasant situation.

[00:16:09] Nathan Wrigley: That, is curious. But also, conversations like this and podcast episodes like this, at least we’re alerting people to the fact that this is something to be taken seriously. I wonder at what level, like you mentioned six or seven years ago, if you are a, a major corporation, you probably needed to worry about this. And then as though six or seven years have passed, presumably that barrier has gone lower and lower and lower. But at some point it doesn’t matter who you are, you are going to be liable unless you take this sort of stuff seriously. Sorry, you were gonna say.

[00:16:35] Joe Dolson: Right, right, right. I was say that there usually is a point when you get down into non-commercial websites, when things do get a lot fuzzier as to whether or not you’re likely to be liable, but that’s really a question that the law should be settling and the regulations should be settling.

What we should probably do is actually get to these six error types. All right. Let’s do it. So the number one is low contrast text, and that literally means where you have gray text on a slightly darker gray background, and it’s just hard to read. And there are a lot of very very specific calculations that determine in WCAG what is considered to be low contrast or not. It’s an extremely easy thing to test for, and it’s just a matter of trying to meet those guidelines.

Nobody is trying to claim that these color perception tests are perfect. It’s a number. It’s intended to be there so that you have to meet this basic minimum. An important thing to remember about contrast is that this is not a scenario where higher contrast is automatically better. If you’ve met the guideline, you’re in perfectly good shape. You do not need to then go, oh, but I should probably just go black on white. That’s not necessarily better. There’s a whole population of people who will actually find that to be a completely separate struggle.

After contrast, it’s all about, images and that’s images that are either missing alternative text, have generic alternative text, like just image or file or something useless, or are repetitive. And that’s going to be cases where maybe you’ve got a linked image next to a link where the text of that alt text is exactly the same as the text of the link, it’s just duplicate. It’s not helping anybody. These are also really easy to find because you can easily identify that your images have this really common recurring pattern. In a lot of cases in the world of WordPress.

You know, you might have a block pattern that’s producing an image with a heading and some text. And if that block pattern is just presetting an alternative text to something that’s not good, that’s where you might have a problem, it just needs to be dealt with and fixed.

[00:18:50] Nathan Wrigley: Can I just interrupt there a moment, because a default install of WordPress will give you more than alternative text. You’ve got descriptions and captions and so on. You only mentioned alternative text. Is that the case? It’s just that one field that we need to be mindful of.

And you’re describing what is in the image. So, for example, if there’s a red car with a, I don’t know, a dog in the backseat or something you would write, this is an image of a red car with a dog in the backseat.

[00:19:15] Joe Dolson: That’s a great question. I’m gonna answer two parts of that. First of all, you don’t describe the image. You describe the purpose of the image, which may or may not be a description of the image. It really depends on the context. For example, if that image is a link to a post, then what that image is actually conveying to the user is, what is this link for? Which is not necessarily going to be what is the image of. Which is also a question for, is this the right image for this? If that alt text doesn’t make any sense with that image, then maybe this isn’t the right image. But ultimately what you’re actually describing is the purpose of the image. It might be that it’s an image of a dog in the backseat of a red car.

The other thing I wanna mention about that is you would not say, image of. Because that is already going to be predicted and produced by the screen reader. They know it’s an image. You got that covered. And that is an extremely common problem actually, is people stating that it is an image? Totally unnecessary.

[00:20:15] Nathan Wrigley: Okay. So we went through number one and number two.

[00:20:18] Joe Dolson: Well, there was another part of that, which is the WordPress fields. So the WordPress media library has four fields that can be filled in. Title, alternative text, caption and description. Those four things all serve completely different purposes. The title is really only for administrative use. In very old versions of WordPress, it was used to add a title attribute, but that has not been the case for many years.

The alternative text is the thing that basically represents the image. It’s the alternative to the image. When that image is not available, whether it’s because somebody can’t perceive it or because it doesn’t load. That’s the thing that should take the place of that image. And that’s the generic version of it because the things stored in the media library is just one alternative text. So usually that is going to be a description of the image. In actual use, you may or may not want to use that text depending on the context. Again, with that linked image, it’s not necessarily a description of it. It might be a description of the target.

And then the caption, the caption is a thing that should be universally available. So both people who are sighted and people who are visually impaired will be able to see that. So really it’s something that should be complimentary to the image. It gives additional context, but doesn’t necessarily explicitly describe it. An example there would be, it might be used to say who is in the image. For example, you know, the description is a man with glasses and a beard, stroking a cat. And then the caption actually says, this is a picture of our founder, Joe Dolson and his cat Bubbles. I don’t have a cat named bubbles. just to be clear.

[00:22:00] Nathan Wrigley: There was more in that than I, I imagined.

[00:22:02] Joe Dolson: The description field is actually not used by default unless your theme has decided that there’s some context in which that’s used.

[00:22:09] Nathan Wrigley: So, okay, we’ve done one and two.

[00:22:10] Joe Dolson: Moving on to number three. That’s form fields without labels. And that is an incredibly big deal. I mean, if you have a contact form or a search form or a sales form, any kind of query, and those form fields don’t have labels, then basically a user with a screen reader, they don’t know what they’re trying to do. They have no idea what this is. Frequently, you have form fields that have text nearby that is visually a label, it looks like it has a label. But if there’s no explicit association between that information, because a label is a specific HTML field and it’s connected to an input using a for attribute and an ID, attribute. And that makes it really straightforward, really explicit.

And that tells somebody what this field is for. And those being missing are just, that’s just wrong. It should not be missing. Next one after that, and I’m just gonna collapse the next two into one because they’re effectively the same problem. Empty links and empty buttons. That is literally a link that does not have any text contained inside it, or a button that doesn’t have any text. As often as not that’s because they’re either an image that doesn’t have an alt attribute.

So there’s nothing meaningful there. It’s like a font icon or an SVG image that is supposed to represent your hamburger menu, or it’s a close icon, or it’s a help icon or any of those many possibilities, but doesn’t have any kind of accessible name. It doesn’t have any attributes that give that a text context. So the screen reader knows what this is supposed to do. Those are also extremely common.

The last of the six, and this is quite rare to be a problem on a WordPress site because WordPress pretty much takes care of this, is a missing document language. Every HTML element should have a lang attribute that declares what language the document is in. English, German, French, Spanish, whatever. And the purpose of that for a screen reader is to tell them how to pronounce it.

Not having that means it will be pronounced according to whatever that person’s local settings are. So if they’re a French browser on an English site, the English is gonna have a very strong accent. And in fact, it’s not really an accent because it’s following a completely different set of pronunciation rules and that’s going to make it incomprehensible.

So making sure that that attribute is present is really important. I haven’t seen that as a problem on a WordPress site with a theme that’s reasonably recent for a long time. There were definitely a lot of older themes where, big problem.

[00:24:49] Nathan Wrigley: I’m guessing that the six things that you brought to the table could easily be 15, 20 things, but six was the number that was chosen there. I guess the problem is you could have gone on all day and we could have talked for hours about all the other things, but these are the things that have risen to the surface.

So anybody who’s not encountered this is now going to be presented with additional things to do. Work to be undertaken. Things to be learned and so on and so forth. I’m just wondering if there’s any, any useful things, tools for want of a better word that you have found over the years that have enabled you to short circuit things, make things as easy as possible. So it might be a browser extension, or I don’t know, some app that you can install on your computer or something like that.

[00:25:32] Joe Dolson: Yes, there are an incredible number of these types of tools, and they all have slightly different ways of working, slightly different sets of tests. But these particular six items, all of the automated tests are going to find these and help you solve them. They’ll give you guidance about what you have and what you need to do.

So I think some of the ones I use the most are going to be, there’s an automated tester from tenon.io, and that’s an application that you can run remotely. It’s got an API, you can run it just automatically. And it’ll just scan a page and give you a list of everything it’s found on it..

Another one is wave.webaim.org. That’s from the same group of people who produced this report that found these errors. And that’s available as a toolbar for, I think it’s Chrome. Firefox or Edge, so pretty broadly available. It’s also testing one page at a time, but they do have a tool through a company called Pope Tech, that can give you generated reports of larger sets of pages. So you can get a much larger body of data.

There are browser extensions from an organization called Deque called Axe. Those also do a wide variety of automated tests.

One of the things that’s important in development with accessibility is that it’s always something that needs to be based on the rendered site. There’s a reason they’re called the web content accessibility guidelines. It’s because it’s all about the user experience and what they’re actually getting. So there aren’t a lot of tools for doing like pre-production linting as part of your development. You know, you can do some of that in an end to end test, but it’s going to be very limited because it’s, there’s so many assumptions you have to make.

And the real world is where people have put in content that, the content is what’s really causing problems. Anything with these images, almost all of that is problems coming from content.

[00:27:28] Nathan Wrigley: So it strikes me from what you’ve just said, that there might be a better place to put this work. This work that needs to be done in the workflow of a typical website. And from what you’ve just said, it sounds like it would be better done toward, the end of the development cycle?

[00:27:43] Joe Dolson: Different parts of it fall in different locations. So low contrast text, for example, is frequently a design issue. So that as often as not should go at the very, very beginning. That’s when you’re deciding what kind of color palette you’re going to use and what your base design looks like.

The images, it’s a mix, because it depends on whether you’re using a plugin that generates a body of images, or you’re using images embedded into content. In the latter case, it’s a content production issue. So it’s something that you should be checking on the fly and should be done on a constantly recurring basis.

For the application environment, for, you know, a plugin that’s producing these lists. That needs to be fixed in the development side, on that plugin of whatever it’s doing.

Form fields are another one where most of that needs to come from the plugin that’s generating your form. Gravity Forms has done a huge amount of work on improving the accessibility of their product. They’ve got more to do. It’s always, these things are a constant battle of, oh, we screwed this up now we’ve gotta fix it. Oh, we fix this, but now we screwed that up. But Gravity Forms has done a really great job, and one of the advantages to that is that they don’t give you a lot of room to screw it up. Just make sure that legacy markup is not turned on.

[00:28:58] Nathan Wrigley: There’s a whole other conversation I think to be had there as well, but…

[00:29:01] Joe Dolson: There’s a lot.

[00:28:03] Nathan Wrigley: In terms of a typical agency, let’s say who’s done none of this work before. They’ve got a legacy of websites. Let’s say, I don’t know, 50 websites, which they’re maintaining and they’ve built. So suddenly we are presenting the agency with work that they need to go back, and if you like retro fit the websites that they’ve already built and bring them up to standard.

And then of course, there’s gonna be the new work which comes through the door and that’s gonna be a little bit more straightforward. This brings to mind the question, how much do we need to be doing of this now? How imperative is it for us to go back to our clients and say, look, we need to begin this work yesterday?

Or is it more a case going back to the clients and saying, maybe it’s time to begin again. And I know that’s not gonna be a comfortable conversation to have. Essentially what I’m trying to say, is it easy to retrofit or is it sometimes easy just to begin again almost?

[00:29:55] Joe Dolson: It is absolutely frequently easier to begin again. But it’s it is very much a case by case scenario. One of the things about the WordPress environment and this ecosystem, is that there’s a huge number of themes and plugins that you’re building your sites based on.

If those themes and plugins are issuing updates and they’re fixing problems, then a lot of the problems that are coming out of those tools can be fixed for you. And I mean that’s why I think the people who should be looking at this first and foremost are the tool creators. WordPress Core, plugin authors, theme authors, because that is going to solve the biggest, most global problems. And when I say global, I mean, these are things that are infecting, that are affecting entire sites.

I said, infecting. It’s kind of an interesting perspective, I like that in some ways, I don’t know. They’re infected with inaccessibility. But anyway, if these plugins can fix something then they can have an impact on thousands, millions of sites. I mean this is one of the reasons I contributed to WordPress at all is if I can make one little change, it can potentially impact millions of sites.

[00:31:06] Nathan Wrigley: Just the answer to this may simply be a no, and it goes nowhere else. But is there any sort of an accreditation system that things like plugins can get certified against. So that, for example, you mentioned Gravity Forms as a good example of a company that have done some work in that area. So that you could visit their website, see the accreditation stamp somewhere and say, okay, I’m assured that at least some of the work has been done. I don’t know if that’s even a thing.

[00:31:31] Joe Dolson: There’s nothing that I’m aware of really for plugins. There’s an organization. It’s the IAAP, the international association of accessibility professionals. Uh, and they certify people as specialists. In the theme world the WordPress theme repository does have the accessibility ready tag that does require some manual testing.

Plugins are a really difficult case because it’s hard to set a specific set of tests and guidelines that they have to meet because they do so many different things. For some plugins, there are no settings, there’s no user interface, it just does some automation. And you’re like, well, is that accessible? It literally has no interface. How do we judge that?

[00:32:14] Nathan Wrigley: Okay, so, we talked about retrofitting. We talked about beginning and potentially that the beginning is the easiest way to go forward. That therefore raises the question of how much of this do you need to be mindful of before you can say, that site is ready to ship. And bluntly let’s say, is it okay to have a site where 10% of the tick list that you want to achieve has been completed?

Is that okay to launch, or do we need to be higher into the fifties, or indeed the nineties, or the 100%? In other words, is it better to do something and launch it, rather than wait until it’s perfect? We know how this works. If we build websites, we’ve had this problem time and again. You know, things creep in that we need to do, and we never end up launching the product because we’re constantly, constantly making it perfect. So just some guidance on where we need to be there.

[00:33:05] Joe Dolson: So it’s a slightly different answer depending on whether we’re building a new product or making changes and retrofitting something old. When you’re retrofitting, in my opinion, it’s just, the goal is make it better every day. If you can ship an update that fixes one problem, then fix that one problem.

It’s better. It doesn’t have to go from zero to a hundred in an instant. There’s no reason to wait. To shift an improvement. When it’s a new product I would say 10% is awfully low, because we all know how priorities work And as soon as that product gets in front of users. Now you’ve got user demands. You’ve got clients who just are like, oh, I don’t, I don’t know that I want to pay anything more right now.

And so that additional percentage may just never happen. So going over 10% is definitely worthwhile. But you should always recognize that there is no a hundred percent. Like you’re not going to achieve a hundred percent accessibility. The range of human experience and human perception is far too great. All you can reach for is try and think of everything you can, and everything that seems reachable and that you understand and recognize that you’re going to make mistakes.

[00:34:20] Nathan Wrigley: You were mentioning earlier about the lawyering and how that has become a thing. And I’m wondering who is the person who’s responsible. So in other words, if you are the web designer and you’ve taken on that work and you’ve handed over to your client, but then they’ve taken over for example, and they’re maintaining and updating from this moment forward. Is there any guidance around that?

In other words, can you insulate yourself from the problems which may occur? And again, there’s a myriad set of different ways that we could build and hand over and all of those kind of things, but, I’m sure a lot of people listening to this will be thinking, okay, how can I protect myself, having done some of it, but not all of it?

[00:34:58] Joe Dolson: This is definitely one of the areas where that gap in regulation is a real problem. In terms of responsibility that ultimately falls on the business owner, the website owner, or the product owner. But of course, the terms of your contract will vary and your specific liability to the outcome of your product might vary.

And even in the most solidly constructed contract where you protect yourself, that doesn’t mean you couldn’t be sued for negligence. You know these things all revolve around. If a company ends up having to pay damages of $7 million because of an inaccessible website, it’s very reasonable to think they’re gonna go back to the people who they hired to work on that website and be like, we are not happy. I think that’s an extremely justified position to be in. So I think everybody needs to take a piece of this responsibility.

I know for a fact that, in the Ontario law, the AODA, they do explicitly specify that everything on the website has to be accessible, including third party products that you are using. So a common problem in a lot of websites that I’ve audited, you know, it’s a nonprofit, they’ve got a great accessible website, but they’re using this client relationships, module, a CRM to take their donations, and it’s a mess.

And you’re like, okay, this is an absolutely key part of keeping your organization operating, is getting these donations working and that’s not accessible. So you really do have a problem there. And that’s a third party application. You don’t have any direct control over it. You can’t directly fix it, and I think that’s a marketplace problem. Where all of these elements within the overall picture have to be thinking about what their responsibility is.

[00:36:50] Nathan Wrigley: You’re obviously very keen on this. And I’m just wondering if this is becoming an industry. In other words, a few years ago, we didn’t have SEO experts. Well, quite a long time ago now, but let’s say 20 years ago, there was no such thing as an SEO expert. It just, wasn’t a thing. Now there is. There’s people who you would hire in because you want to take over the SEO and give it to somebody else. And that’s now their responsibility.

Is there a growing collection of people like yourself, who you can hire in to examine and look, so you’re not relying on the tools, the automated tools. You’re really getting a, a human being in to do the real work, and yeah, is there a career there?

[00:37:30] Joe Dolson: Oh, absolutely. It is actually a huge growing market. I think the growth of the accessibility consulting and testing market is pretty high. I don’t know what it is right now off the top of my head, but it’s a growth market with no question.

And as somebody who’s been in accessibility for almost 20 years, there’s always been an industrial market for accessibility. 20 years ago, it was almost exclusively in government, universities, higher ed, that sort of area. And it has been growing very rapidly. There are a lot of large companies now that they exclusively provide accessibility consulting. There’s actually been a lot of consolidation and acquisition within the accessibility space. So there’s no question that this is absolutely a major career. It’s a market where if you engage in some training and accessibility, there are jobs to be had. They are all hiring, and this is because it has grown enormously in the last four or five years,

[00:38:31] Nathan Wrigley: Which brings me to nearly my last question, and that is, imagine that we’re working for a large agency and we are employed by a boss who, how to put this, does not care about the last half an hour’s conversation that we’ve had. And just simply wants to ship things as quickly as possible, and obviously what you are proposing is not as quickly as possible. There’s other work that needs to be done on top of that. So we could hire out, we could find somebody such as yourself, who’s able to guide us with our, your expertise. But, what do we say to those bosses? How do we persuade them that, not only does this matter, but it’s essential?

[00:39:08] Joe Dolson: So I think, you know, some people are unpersuadable. There are always going to be a group of people for whom this is simply not, not something they are going to choose to care about. And those people will ultimately only be persuaded by legal action. And so when their company gets sued, they will have no choice but to deal with that. But operating on the assumption that we’re working with somebody who at least is willing to listen to reason and to, justifications about why this needs to be done.

There are a lot of arguments in favor of it, in terms of the fact that it makes websites easier to use. It makes processes easier for customers. So there’s a, there’s an acquisition aspect. There’s a sales benefit. Just making things easier to use, making things possible to use by more people.

It’s an estimate of around 15% of the world population has some form of disability that could impact their experience on the web. And a lot of that is in cognitive impairments, where they might have problems with distraction, or lack of focus, short term memory loss, and all of those people are going to benefit enormously from the same kinds of principles that go into web accessibility.

And so on a, on a marketing argument, the very fact that by implementing accessibility, you can increase your potential market by 15% is something that should be relevant. I think there is a perception sometimes that people with disabilities aren’t a market with money to spend. That’s a bias that’s coming through things like, the social security programs for supporting people with disabilities.

But the fact is, in this era the percentage of people with disabilities who are able to be gainfully employed is rapidly increasing because the digital marketplace takes away a lot of the barriers. You don’t have to necessarily travel to your job, which might be very difficult if you are visually impaired. Or if you have problems with distraction in an environment, or you just need to be able to get away from over stimulation. So

that market is increasing. I think, I think it’s the US number right around now. I happen to do a presentation on Thursday morning about accessible advertising. So a lot of these numbers are things that I’m remembering from my presentation two days ago, that the estimated buying power of the US disability, people with disabilities, is around 350 billion. But an awfully high number of products cannot be purchased by those people, because they’re not accessible. There’s an awful lot of people with disabilities where I buy from this company. Why? Because it’s the only one I can.

[00:41:58] Nathan Wrigley: That is absolutely fascinating. And it really speaks to the question that I asked. If you have a boss who doesn’t care, potentially this is the quickest route to somebody caring. There is a market, it’s a growing market. You can be more profitable by making these tweaks.

Final question if that’s okay? We’ve talked about a lot. There’s probably gonna be a lot of confusion about where do I go, how do I find out more about these things? And you’ve sent me, we had a little shared show notes, and you’ve sent me a bunch of links. It’s gonna be difficult for us to spell them all out. I will put every link in the show notes and hopefully get them done correctly. Do you just wanna say something about the best places, the most reliable, the quickest wins, if you like that you have come across where people could? I don’t know, two or three or four of them that you’re happy to share.

[00:42:41] Joe Dolson: So yeah, I mean the list of people I’ve mentioned, they all have unique perspectives and great information. I always recommend when you’re trying to get the current best practices on how things really work and what is, what support is available for a particular interaction interface. I like to go to Adrian Roselli. He’s very, very thorough researcher on accessibility issues. And one of the best things about what he publishes is that he routinely updates things. So his website does not have stale content.

I shouldn’t say that absolutely. I haven’t read everything on his site. It might have stale content, but I’m not aware of it. So that’s a great place because you can trust that it’s going to be current and maintained and is very thorough.

I also like Haydon Pickering and Scott O’Hara. That might be O’Hara. I honestly don’t know. They both do a lot of nitty gritty experimental of, this is how you use these various accessible interactions. They’re great resources. And then there’s a general website, it’s the A11Y project, the accessibility project. And that publishes articles by a lot of very experienced accessibility practitioners who’ve been around for a long time, who are new to the industry, but writing really solid information about how things work.

And then of course there’s the actual WCAG documentation. There’s a lot of information from the web accessibility initiative, the WAI working group, and they have an enormous amount of information about just general, what it means to be accessible and what an accessible interface looks like.

[00:44:25] Nathan Wrigley: Overlays.

[00:44:26] Joe Dolson: Ha, yes.

[00:44:27] Nathan Wrigley: Overlays have cropped up. Essentially what we’re dealing with here is a, click a button, I will solve all of your website accessibility needs. That sounds too good to be true. It sounds too simple to be able to install something, let’s say it’s a plugin or a piece of JavaScript or whatever it may be, and to say to yourself, I’m done. I am compliant. I’ve done all of the things by installing some small bit of code. Tell me your thoughts about this.

[00:44:54] Joe Dolson: Well, you know, if things seem too good to be true, it might be because they’re false. And that is absolutely the case with overlays. If an overlay is claiming, I’m going to solve your problems, you don’t need to think about anything else, you are now compliant, that’s because they’re lying to you. Flat out lying to you. Because what overlays are is they’re kind of a side effect of the accident chasing, legal thing. They’re a reaction of, oh, we have all this AI. We can solve things. We can find all these problems. It’s amazing. This is fabulous. But they can’t, because the problems are vastly more complex than they actually think they are.

So many things simply, you can’t even test to identify the problem, let alone fix it. So overlays are basically just a disaster.

[00:45:44] Nathan Wrigley: Is there any scenario in which they represent a decent bridge? In other words if, if you just click that button, get that overlay on there, and then begin the good work that you’ve described during the podcast, all the other things that you can do. Is there any scenario where that could be recommended? Knowing that it was the temporary kludge.

[00:46:02] Joe Dolson: Mostly, no. Now I will say that’s a no in terms of any of the really major overlay vendors, because for the most part, they are actually going to make your website worse. There are certain of those vendors who will absolutely, definitely make it worse. And there are browser extensions that have been marketed directly to the disability community for the sole reason of disabling these overlays because of the problems they cause for people with disabilities.

There are some extremely narrow categories where an overlay can bridge that, and a lot of the major accessibility corporations as part of their work, they will build an overlay, a custom overlay, which specifically deals with specific problems on your website. And that’s going to be in cases where the process to actually get the backend code updated is too burdensome, and they need something fast. But it’s only gonna solve a tiny fraction of those problems.

That should be something that’s custom, that’s targeted. I have a plugin, WP Accessibility. It includes some overlay aspects within it, but they are very targeted because they are targeted at specific things that are known to happen with WordPress or with WordPress themes, and they have known answers.

And even then, I wouldn’t say that’s something that guaranteed to fix everything. It could still cause problems. And you shouldn’t keep it installed and operating in that manner any longer than you absolutely have to, because fundamentally what you need to do is get the fix in place But these big commercial overlays are just horrendous. They make things worse, period.

[00:47:44] Nathan Wrigley: There was one further question. Sorry, I was sneaking this one in right at the end. I also asked you to recommend a community that you thought was worth hanging out in, because that’s often a way to just sort of speed up the process. You find some friends in there and they help you and they point you in the right direction. So, you’ve mentioned one here. Do you just wanna tell us about that?

[00:48:01] Joe Dolson: So there’s a Slack community for web accessibility professionals. It’s web-a11y.slack.com, and there’s about 10,000 members of that Slack organization. And it’s a great place to ask questions, look for advice, read what other people have done, search for past conversations on various topics. It’s a pretty large Slack. It’s very active. It’s kind of the place where the community mostly hangs out I would say.

[00:48:32] Nathan Wrigley: And should anybody wish to find you Joe, off the back of this. If you’re willing to share, what are the best places to get in touch with you?

[00:48:39] Joe Dolson: I’d say the best places for me, you can find me on Twitter @joedolson, J O E D O L S O N. You can find me in the WordPress Slack, also Joe Dolson. Pretty much anywhere I am, you’ll find me as Joe Dolson.

[00:48:54] Nathan Wrigley: Thank you very much for joining us on the show.

[00:48:56] Joe Dolson: Thank you. Thanks for having me.

Leave a Reply

Your email address will not be published. Required fields are marked *