322 – Why accessibility is so important and how you can do better with Nic Steenhout

[00:00:00] Nathan Wrigley: Welcome to the WP Builds podcast, bringing you the latest news from the WordPress community.

Now welcome your hosts, David Waumsley and Nathan Wrigley.

Hello there once again and welcome to the WP Builds podcast. You have reached episode number 322 entitled Why accessibility is So Important and How You Can Do Better with Nic Steenhout. It was published on Thursday, the 13th of April, 2023. My name's Nathan Wrigley, and I'll be joined in a few short minutes by Nic so that we can have our long and in-depth chat about accessibility.

But before that, just a couple of bits of housekeeping. Don't forget that we do quite a lot of shows. We do the podcast that you're listening to now, but also we do the this week in WordPress show that goes out live every Monday at the url, WP Builds.com/live. We love to have people in the chat. There's often quite a lot of commentary.

It's a jolly fun experience, like I said, 2:00 PM UK time every Monday, and then we repurpose that as a podcast episode the following day. If you want to keep in touch with all the things that we do, go to our subscribe page and get yourself on our email list, WP Builds.com/subscribe. There you'll also find all of the other ways that you can interface with WP.

Another popular page is our deals page. I say it's a bit like Black Friday, but every single day of the year, WP Builds.com/deals. Go there and check out to see if something that you are after in the WordPress space is available for a specific coupon code amount off.

The WP Builds podcast is brought to you today by GoDaddy Pro. GoDaddy Pro the home of managed WordPress hosting that includes free domain SSL and 24 7 support. Bundle that with The Hub by GoDaddy Pro to unlock more free benefits to manage multiple sites in one place, invoice clients, and get 30% off new purchases. You can find out more by going to go.me/WPBuilds. Once again, go.me/WPBuilds and sincere, honest thanks to GoDaddy Pro for their continuing support of the WP Builds podcast.

Okay. What have we got for you today? It's all about accessibility. Nic Steenhout is a certified expert in this area, and he's here to talk about all of it. There's a lot of gripes about the different things that are out there on the internet that make it very difficult for people to really make any use at all of the internet.

And Nic talks about all of the different pieces. We cover an awful lot of topics. It was quite a long conversation. We actually had to postpone the recording of it because about halfway through Nic's audio just collapse. So I've had to slice it all together. Hopefully it's nice and coherent.

I'm pretty confident that it is. But we cover the whole range of accessibility, and obviously this is increasingly a very important part of your WordPress website workflow. So I hope that you enjoy it. I'm joined on the podcast today by Nic Steenhout. How are you doing, Nic? Pretty good yourself, Nathan?

Yeah, thank you Nic and I have had a very brief little chat about the subject that we're gonna talk about today. And honestly, I think this is an important one. It's an important subject to get your head around. You may have been burying your head in the sand about this one, but it's time to get your head out the sand cuz Nic's here today to talk about all things accessibility.

Now this seems to be a hot topic at the moment and Nic has the credentials to talk about this subject. So Nic, first question really, it's a bit of a general one, but could you just introduce yourself, your background, how it is that you've come to be on a podcast about accessibility in this case?

[00:04:08] Nic Steenhout: Yeah I am Nic Steenhout and I've been doing web accessibility in one way or another for a very long time, nearly 25 years now. I used to build websites using notepad and handwriting my H T M L. And over the years I've done more and more work. In accessibility spec specifically. I started really thinking about accessibility when I had a deaf colleague who came in and she said, I got some video instructions on how to set up my new wireless printer, but I actually can't understand the instructions because there's no captions on the video.

The following week I had a blind colleague that came into my office and he says, Nic, I can't make sense of this website because my screen reader tells me that the website is image. And this was at a time where we didn't have CSS to make use of a variety of fonts. So designers would design images of text and then we would slice it up and we would load that up with on the page so it would look good, but it was totally not accessible.

So that, those were a really two big event that made me think. Huh. Accessibility is actually important for disabled people to be able to access access content. And since then I've done all kinds of things including being a core developer in the Jula cms. And at the time, Jula had just started.

So I was there to help make the platform accessible. These days I do a lot of public speaking around accessibility. I'm a professional speaker. I do consulting with companies, mostly large companies fortune 500 stock exchange listed kind of level of companies. And it's all about making their platform more accessible.

So we talk with designers, developers, QA, testers talk about strategic planning on how to make Websites accessible, but also about changing the culture of accessibility and perception of how do we include disabled people at all stages of what we do?

[00:06:40] Nathan Wrigley: What a laundry list of excellent things to have said.

That's just brilliant. So you've decided to essentially push your career down the path of accessibility. What sounds like really personal reasons and yeah I think this is gonna be interesting. So first of all, thank you for making the time to come and talk to us today. It strikes me that there'll be a real broad sway.

The people listening to this podcast, judging by the comments that we get, and I see profiles of Twitter and things like that, there's. Hardcore developers. And then there's people who just more or less recently strayed into WordPress and they're just building their first sight and trying to get a feel for the lay of the land and how they can do that.

And it may be that the word accessibility, whilst they understand what it means, they may have absolutely no conception about the broad nature of the ways that people consume the internet. Now, I'll put my hand on my heart for the whole of my life. When I've looked at the internet, it has been on a screen typically.

With a keyboard and a mouse. I'm sitting in a chair and it's all very straightforward. I move the mouse and things do exactly what I want them to do. The worst I have is a slow loading website that I have to sit there and, just wait for the page to load. Alternatively, I may look on a phone.

That's basically the other device. So it's phones, computers, and then a little bit more recently starting to talk to devices in my ha in my house, the little devices that sit in your kitchen and the Googles and the series and all of those kind of things. But that's really a tangential part, largely.

I'm just asking it, dumb facts and things like that. So it's screens and more screens. And so I consider myself to. Fairly privileged in that sense because like I said the worst it gets is slow internet connection. There's never anything on the page that I can't understand.

The images are straightforward to me. I can perceive what they're talking about. All of it works. But that's not the case for a proportion of people on the planet. And it may be interesting just to lay out the multitude of ways that people do consume the internet who are not like me.

[00:09:01] Nic Steenhout: Yeah.

There's a joke that I used to make that I guess I still make, but the word normal really it's a cycle on the washing machine because there's no norm. We are all different. We all have accessibility issues in one way or another. The most recent numbers out of the United States Center for Disease Control.

The C d C say that 26% of the adult US population has a significant disability in one way or another. That's more than one person in four has a disability, huh? Wow. Worldwide numbers vary a lot but typically it ranges. The official numbers range between 17% and 26%, and that comes down entirely to the kind of questions that are asked during surveys.

So if you ask someone, do you have a disability? Maybe they'll say no, even though they might have a disability. So basically, one in five, one in four is a good guesstimate. So we're starting to talk about a lot of people that have a lot of different disabilities, a and. If we break it down, we have four main kind of disabilities that mean that people may have an impact in how they use the web.

One is vision of impairment. Someone may be blind, someone may have low vision or any kind of thing around that range. The other one is hearing impairments. Someone might be deaf have no hearing at all, or someone might be hard of hearing. We have folks with mobility impairments, so someone might be paralyzed or they might have some tremors, or they might have had a stroke and have difficulty with fine motor control.

And the final one is cognitive disabilities. So someone might have played rugby once too many times and he hit on the head when they were a teenager and now they have difficulty concentrating or they have memory issues. Someone might have a ADHD or someone might have dyslexia. So we ha we have a whole range of conditions that are disabling that mean that we have people experiencing barriers when they go on the web.

The kind of barriers that can be experienced or fairly wide. It can be someone who is blind, who's using a, an application called a screen reader that reads what's on the screen. But because you have a whole bunch of images on your website, they can't actually access the content because you didn't plan for alternative text.

It could be someone who's deaf who wants to access your tutorial, but there's no captions on your video. So without text, they can't access it. It can be someone who has low vision, but. You decided to follow a trend where a gray text on gray background is really the fashion of the day, but there's no contrast.

You can't see it. So there's a whole range of ways people encounter barriers. Just there's a whole range of ways people experience web. Nathan, you mentioned smart devices. A lot of people will use Alexa to access the web and they talk to their devices and the device talks back. The same thing.

We can use smart assistance, we can use Siri, we can use if you have a phone, which I assume you do, it's likely to be either Android or iPhone. Both have built-in screen readers, so we, we can actually use that to, to interact with. With the web in different ways. Some people don't use screens at all because it's all done from audio feedback.

Then you have people who are deaf and blind where they use a keyboard for input and they use a braille display for output. We have people that can't use a keyboard and they're using a switch. So basically it's one button or two buttons, and depending on how they're tapping the button, they're able to control an onscreen mouse, an onscreen keyboard.

We could probably speak about how people use the web for two or three hours and still find new ways. I can tell you one thing though, is as a website owner, chances are that you will be surprised at how people get to your To your website. I was speaking with a client last year and we were doing some fine analysis on their their Google Analytics and they had 1% of traffic to their website coming from a LG smart fridge.

So you never know. That is extraordinary. Wow,

[00:14:40] Nathan Wrigley: that's amazing. What a great, what a great display though of information there. That was really helpful. What I'm picking up from that is we've got keyboards, we've got screen readers, we've got braille readers, we've got people, talking to things.

You, you imagine it, somebody somewhere will be using it. But I guess the thing the key part of all of this is that this is the way that they get on the internet. It, in the same way that I use my eyes, that's the way these people are using. Way, the keyboard or screen read or whatever it may be.

And this is what they need. Without that device, without the customization of websites to make it so that those types of devices can find their way around. Browse the internet, follow links, consume information, have an idea of what the pictures are saying. These people have a. Port culls in front of them.

There's a great big gateway to the internet. They're excluded from it. And so I, I don't know if you're prepared to do this. I'm gonna surprise you a little bit. We didn't really talk about this beforehand. I'm wondering, let's imagine the scenario where somebody, and we'll just pick one scenario where somebody is using a screen reader and they approach a page.

And let's say that this page is really dreadful. E everything that could be wrong is wrong. What kind of frustration is that experience? What is the person sitting there, wh what are they hearing back? What's coming back to them? Wh what does it feel like?

[00:16:22] Nic Steenhout: It's a very interesting question.

The first thing to realize is us cited people. When we look at website, we are able to catch the. The page at a glance, like I'm looking at the interface of what we're looking at right now. I'm have the typical browser page with the the tabs at the top. Then I have an address bar because I like to see the address bar.

And then it's a dark gray screen with, on the right of the the screen. I have the clean feed logo. Then I have my my settings, my name, and there's a microphone on the left. And then my, there's my headphone on the left, just below that. And then I see you, Nathan Wrigley. It says it's connected. I'm catching all that right at the blink of an eye because yeah, I can see it.

Now if I'm blind and I can't, I don't actually have vision, then I rely on the tools that I have built in my screen reader to, to build a mental map of what's on the page. Chances are the first thing I would do is I would use keyboard shortcuts to bring an interface that tells me all the headings on a page, all the links on a page, all the interactive elements on a page, the landmark area.

So I can build a mental map as to what's there. If the page hasn't been marked up properly, doesn't rely on the headings, or doesn't use proper markup for buttons or links and these kind of things, that mental map suddenly is not possible to be made. It's just nearly impossible to make it happen.

So the next thing you do is you start navigating. You can navigate by heading, but you just discovered there's no heading on this page, so I'm not gonna be able to navigate by heading. So I'm going to. Again, keyboard shortcuts to start navigating one line at a time. Trying to explore and understand what the content is, the amount of cognitive load that we've just added to the experience of even trying to figure out what's on the page, which are cited people can do in a fraction of a second.

We've just made life of the screen reader user so difficult. Most blind people I know come to a page where it's mostly unusable. If they have a choice, they will go buy the product somewhere else. They will go find the information somewhere else and they will just not stay on your page. You will get a bounce almost.

I.

[00:19:18] Nathan Wrigley: I am guessing that the experiences it would, I think you summed it up really well. We can take in the whole page at one time. I can zoom in with my eyes on the thing that I want most. I can scan across the whole menu, slide to the footer, go where I want to go and really it's all driven incredibly quickly.

I use my fingers to get the mouse to where it needs to be, the cursor to where it needs to be and so on. It's all happening really quickly. What you've described is an experience of tapping, and you're really looking at one thing at a time. So you can do one thing and then move on and try another thing and then move on.

And if that experience doesn't reveal to you what you need a year out of there, it's just a dead loss. Yeah, just the unfairness of that, just that alone. Hopefully people listening to this have got a gist that, wow, that just seems extraordinarily unfair in, in today's world, that's amazing. Okay, so given that there's. These multitude of problems, and we can talk about what they might be. In a moment. I'm wondering if we could lay out some of the sort of low hanging fruit, if so again, we'll imagine our website. It's in every way. It's wrong. There's things to be done in every regard.

What, from your point of view are the quick wins, the low hanging fruit. Now I'm not trying to emphasize here that this is where everybody must start, or indeed that this is where you must finish. I'm just thinking everybody likes to move the needle quickly for as little effort as possible.

So given that's part of human nature what are the good things to get your teeth into right away?

[00:20:58] Nic Steenhout: Yeah. So I'm gonna flip your question around a little bit. Okay. So instead of talking about the easy fixes, I'm going to talk about the critical items. And there's a lot of stuff we can work on. The, when we're thinking accessibility, the way we have to measure that is called the Web Content Accessibility Guidelines.

It's a standard put together by the W three C, and there are 78 different success criteria, and each success criteria can be quite complex to address. When I'm talking about the four more critical areas I'm really just chipping the surface and these four are keyboard images, forms and contrast.

You want to make sure that you can use your website with the keyboard, and that means being able to navigate through. Every single interactive element, and you want to be able to trigger them. So use the tab key to go forward shift tab to go backwards trigger element with the return key or the space bar.

Part of that, you also wanna make sure that there's visible focus when you're using the keyboard. And this is something that everybody can do because everybody has a keyboard. You can go on any website today and start using the tab key and the shift tab to move forwards or backwards on a page and see if you can trigger the interactive elements.

Yeah, that, that is probably a fairly straightforward things to fix in general, but it's most certainly one of the most important things that you can verify and. Everybody has the tool and everybody knows how to use a keyboard mostly. So keyboard, the other thing that we have to look at after keyboard are images.

Images are worth a thousand words, but if you can't see, then they're worth nothing. So in general, there's two types of images on the web. There's decorative images, and then there's informative images and decorative images. It's basically eye candy, right? It's things we're using to make the page look better.

Sometimes it's just to, to catch attention. These images generally don't need to be described. They don't need alt text. But when we're doing markup, we still need to add the alt attribute and we're using an empty or null alt value on that. And when I say that, I don't mean. Alt equals quote, N u l and quote, just nothing between the quotes.

I say this because I actually had a developer when I said, you need null alt text on an image decorative image. That's what they came back with. Okay. And I had to find all these images, but that's a, another story. The joys of accessibility auditing. So the other aspect is of course, informative images.

Any image that provides information that is not available elsewhere on the page, typically these can be action buttons. Like you have a button for your search form, and the button is actually the icon for a magnifying glass. That's an informative image. It actually tells you this is what it does.

But if you don't have alt text, it just will not be able to be. Perceived or understood by screen reader users. Sometimes it's graphs, sometimes it's things that are on the verge between being informative and decorative, because context is everything. You can't just take one image and decide, oh, this one is always going to be dec decorative, or This one's always gonna be informative.

You have to look at the context. So you have to do this evaluation where you look at what the image is, where it's at, and how it's used. And one great tool if you're not familiar with alt text and how to make the decisions as to whether or not you should use alt text is actually on the W three C's website.

It's called Alt Decision three. It's fairly easy to find and it's basically giving you scenarios and depending on your yes, no answers, it'll tell you what to do with your images. That is super important. I'll text for images is something I've been advocating for since 1994 and nearly 30 years.

It's still a problem on the web. So it's something that is both a low hanging fruit and very critical.

[00:26:27] Nathan Wrigley: Can I just ask you about that? Because I'm currently looking at a media library of a website that I maintain, and I clicked on one of the images, and so we're talking about WordPress now, and it offers me several options, which in a way is confusing because it's important to get the alt text right.

But also I've got I've got alternative text as it's written. I've got title, I've got caption, I've got description. And in a typical upload of a image file they all come across, they're entirely blank. And I'm, I confess that in many cases, I'm not sure which of those ones receives priority and which one describes the image.

Obviously it says description and it says alt text, but I'm often in a bit of confusion about which things go where.

[00:27:21] Nic Steenhout: That is a gripe I've had with the WordPress media library interface for a very long time. The one that, from an accessibility perspective is critical, is the alternative

[00:27:37] Nathan Wrigley: text.

There is, so in my scenario, that's the one that's at the top. So there is, yes. The very first,

[00:27:43] Nic Steenhout: the very first input, that's the critical one. The one that is called title is there, I believe, because in the olden days of WordPress, de Tatal attribute was used a lot to give the impression that accessibility was happening.

But the title attribute is actually ignored by a lot of the assistive technology. Or it'll be. Spoken as well as the alternative text, or it'll override the alternative text. So if I have a piece of advice around the title attribute is in 99% of cases, you don't want to rely on that. Okay. The caption is going to be something that is in addition of the alt text, and typically for cited users.

So for example, you would have a small graph or a, a small schema or something like that. You need alternate text to describe what the image is for people who can't see, but you may want to caption it, figure one or figure three. So in the text you can say figure one, yeah, we are talking about blah, blah, blah.

So that's what the. Caption is about, and to be honest, I don't know in the in the WordPress context what the description field is for at all.

[00:29:25] Nathan Wrigley: Yes. It's interesting. That's always baffled me. The alternative text comes with a hyperlink underneath it and it says, learn how to describe the purpose of an image, and it's linking over to the W three C website to I, yeah, the decision tree.

So yeah, there's that. So anybody who failed to find that link in the show notes, every time you go into the media library, that link is actually underneath the alternative text. So gi give us a scenario. Okay, let me give you a scenario and see if I meet the bill, really, if I'm uploading images and they're images that have information in them that would be missing to somebody who couldn't see them, it's important.

Primarily to go with the alternative text. So for example, I'm staring an image at the mi at the minute. It, there's a mountain in it, there's a cottage on that mountain and there look to be goats on the side of the mountain. So I would be writing something along the lines of image of mountain with a castle in the background at there are goats grazing in the field, something along those lines.

[00:30:34] Nic Steenhout: Yes. Something along those lines. A couple things to keep in mind when you're doing alt text is you don't say image of or photo of. Yes. Yes. Because the screen reader will come across the image element and will already say, this is an image, so we don't need to repeat that. Yes.

[00:30:55] Nathan Wrigley: That was clumsy.

[00:30:56] Nic Steenhout: Also, always finish your text with a period, because that will allow the screen reader to pause before it goes into the next bit of reading.

[00:31:08] Nathan Wrigley: I didn't, I've never heard that piece of advice. That's brilliant. Excellent. I,

[00:31:14] Nic Steenhout: yeah. Now, what do you put in the alt text? Your description was good, but it depends entirely on the context.

If you are advertising a holiday retreat high up in the mountain, is it necessary to talk about the goats? If you are advertising this location is a goat farm and you can pet the goats and all that, then maybe emphasizing the goats and the description becomes important, and this is where I'm talking about context is everything.

You really have to weigh the context in how you're using the image to decide what you put in it. Yeah. In the description, all text should be clear and concise. You can put. A lot of text in the alternative text input. You can put, I, I did six paragraphs of Laura Meso in a test I did.

You can put a lot, but remember that when a screen reader is reading the old text, you cannot control pausing or rewinding or anything. So you want to keep it fairly fairly concise. And this is where it becomes difficult in the WordPress context as if you upload one image. You cannot decide to have several different alt texts.

So if your image may be used in different contexts and may require different alternate text, you will need to upload more than one version of the image so you can keep track of the different alt text.

[00:32:59] Nathan Wrigley: Yeah, that's really interesting. The amount of. Text that you actually use is quite key, isn't it? Yep.

Because if you just get into paragraphs and paragraphs that are simply meaningless, you are in effect binding the person into that image, and they've got to endeavor to get out of that image. If they get bored halfway through. That's really interesting. Can I just ask on a with the screen readers, do they preface what the, they're about to be delivered information about an image?

Is there some description that says to them, I'm about to read the alt text. How does that work?

[00:33:41] Nic Steenhout: When you're navigating the page and you come across an image, you will be told there's an image and then it will speak the alt text. Okay. So there's no, Hey, heads up. You are about to receive alt text other than.

Here's an image and here's the alt text. And

[00:34:00] Nathan Wrigley: if the alt text is entirely null as in blank, does it just skip that entirely or does it say that's great? There's an, okay, so it doesn't say there's an image, we've got nothing to report essentially. Yeah.

[00:34:15] Nic Steenhout: Screen reader users, advanced screen reader users can actually toggle settings in their application where they can decide to have all the elements announced, whether or not there's all text.

But generally speaking, the default is if an image is got empty or null, alt it'll be ignored.

[00:34:37] Nathan Wrigley: I feel that Of all the bits that you are gonna talk about today, this is the bit that really resonates with me because when I browse the. I am absolutely captured by the images. It's almost like the web is images with text along for the ride, and it does seem that it's so important to get this bit right because so much information is conveyed in images.

So much context, so much of the gist of what we're trying to say. We offload two images and yet we just leave that box blank. We live in

[00:35:11] Nic Steenhout: a very visual world. And that's natural. We're cited we, we depend on our vision, but on the web it's the same thing. We are on a very visual web.

There's a been a push by a lot of people in the blind community for people to be a little bit more expressive in how they're describing images and to not be too strict on deciding. Hey, this is decorative and I'm not gonna bother because they rightly point out images, create a mood, images, help with understanding context in some ways.

And from that perspective, they want as much of the experience that cited folks get. So it's on us to go the extra mile and do that.

[00:36:09] Nathan Wrigley: Yeah. Yeah. Oh, thank you. That's been really helpful to me. Okay, so we've done keyboard, we've done images. I think next up was

[00:36:16] Nic Steenhout: forms. Forms, yes. Forms. We use forms a lot.

There are a few things to keep in mind with forms. The first thing is every form input needs to have a label. Because if we don't have a label, we don't know what the purpose of the input is. The best way to implement a label is to use the label element. And you do that by applying a unique ID on the input and then you use the label element, the four attribute, and you use the unique ID as the value of the four attribute.

It sounds a little bit complex. When you speak it and you don't see it, but when you start puzzling it out, actually fairly straightforward, this is critical because without labels, you don't know what the thing is. You cannot rely on placeholder to to label element. This is often seen in search forms where you have the search, the word search is the placeholder for the search input, and then people start typing in it and suddenly without a label, the word search has disappeared and we don't know what the purpose of this input is.

[00:37:35] Nathan Wrigley: So you go into the form and literally upon entering the form, you've. It erased the bit that they needed to see,

[00:37:42] Nic Steenhout: as it were. That's right. Ah, that's right. Yeah. So the placeholder is an element that you should not rely upon for labeling sometimes. Sometimes you can't actually use the label element and you're going to have to use a programmatic label.

And the way you do that is you use the attribute area, hyphen label, and then you use whatever it takes. There's a few more issues, but this is not a highly long-term podcast, so I'm not gonna go in the other ways. Just think about that. The label element or the area label attribute. Label your form inputs.

That's critical. Can

[00:38:28] Nathan Wrigley: I just ask, there, there's a whole industry of form plugins in the WordPress space and they do, they try to market themselves as, we can do this and we can do this fun way of interacting with the form. For example, we can split up the form into multiple pages. So you complete one section and you navigate to the next section and so on and so forth.

But also these conversational forms where you fill out one field and then click next, and the next field slides up into view and it looks beautiful. It's really engaging for me. How do all of those fun things, generally speaking inform the accessibility side of things? Are the, are, is it better to just have a plain form all of it on the page at once or is it okay to have those multi-page conversational type forms?

[00:39:23] Nic Steenhout: I'm gonna give you the answer that most of my clients find most frustrating. I'm gonna say it depends. Yep. It depends entirely on the implementation, right? You can make these things accessible and usable. You have to remember things like sliding things on a page. You have to be able to turn off the animation because we have users with A D H D, we have users with vest or motion disorders.

We have users with all kinds of conditions. That motion on a page will either make them nauseated, sick, or might even trigger migraines. In some rare cases, it can trigger full epileptic seizures. So these visuals of sliding in and out is need for a lot of people, but you have to be able to turn off the animations.

So that's one example of. This is good, but we have to look at how we implement it. Yeah. Now, in my experience there is not a single form plugin out there in the WordPress ecosystem that is actually producing accessible forms, not a single one. Some of them have labels and that's good. Some of them have different things that are okay.

I've had to use Joe Dawson's form plugins for the WP seven forms thing because it makes forms better. But one of the other issues that are so important in forms is error messages. So if there's something that is wrong with the form, when you go to submit it, for example, you have a. A required field that hasn't been filled.

Oh boy. Yeah. You got to submit and you say this field is required. It's not programmatically associated. So you have this error message that's in the form, but if you can't see, if you're relying on a screen reader and the error message is not associated with the with the airfield, then suddenly a, you don't know that the error is there and you don't know what's going on.

So you have to look at. Associating the error message with the input field. So typic,

[00:41:51] Nathan Wrigley: sorry just to interrupt, so I've seen so many implementations of this. So you click submit and obviously there's an error, but the errors might be all gathered at the top of the form above every input field, or they might be bound to each individual field, it, that something is highlighted in red or what have you.

Or they might be under the submit bond all gathered together. Or it might just say, there's errors, it doesn't highlight which errors. And you've gotta figure that out for yourself, largely based upon the fact that you've got empty fields. But, okay so first somebody using, for example, a screen reader, they've got to navigate to the error somehow before they can even consume the content of the error.

[00:42:34] Nic Steenhout: Oh, yep. So there's, in an ideal world, if you're going to have a lot of errors, you can do what is called an error bucket. A list of all the errors at the top of the form. Those are great, but you want to link each of these errors to their associated input. So people can just click on the error, it goes to the input, and they can fill that out rather than to have to tab to 1, 1, 1, 1, 1 until they read the right one. You also want to programmatically associate the error with the input. And typically the way you do that is you're using a little bit of area called, area described by where you're using that on the input. And you're basically, when a user gets to the input, they hear, for example input first name, and then because there's an area described by the error message is going to be described.

So it can be first name as a required field, so they will hear all that. The other approach that is really good is to to put the error message directly below the field that has an error. You still want to programmatically associate them because one thing most people don't know about screen readers is when a screen reader gets into a form, it will often automatically go into what's called forms mode, which gives the screen reader users different keyboard shortcuts, different ways to interact with the elements, but it also ignores anything that's not a form element.

So if you have a paragraph with an error message in it that will be ignored, right? Wow, man. When the screen reader is in forms mode, okay? So you have to programmatically associate that screen. Readers are incredibly powerful and complex bits of assistive technology. And there's, there's a lot to know about them.

So if you're listening to this show and you're going, oh my Lord, I never knew, and this sounds like too hard. It's okay to feel that way because it is really hard, but there's these little things we can do that are going to make it so much easier. Yeah. Boy the other last thing I wanna mention around forms and validation, and I actually had a a blind guy on my show recently talking about this is when we are doing inline validation, don't do the validation on each character.

So for example, you're checking for an email address is correct and you're doing it in line. You want it before the form is submitted and you've seen it, I'm sure you've seen it. You start typing, N I c and then. Because you don't have the completely formed, it's going to tell you this is incorrect.

Each character you type. So instead of doing it on a per character, do it on blur. Do it once the field is actually left, that's the time you do your validation. That's when you're saying, yeah, okay, it's okay. Or No, there's a problem with this. Okay, don't do your inline validation on a per character because it drives everybody nuts, but it makes it next to impossible to use four blind screen reader users.

[00:46:19] Nathan Wrigley: Yeah, it's really interesting because so much of this, which is completely common sense to somebody like me with sight, all of those things, I'm filling out the email field and the moment I put the Nathan at something and I hit dot and the arrow goes away, all of that seems. Brilliant to me, but I can 100% ascertain why that's infuriating for somebody who is not me who is using a screen.

Really? Yeah. That's really interest. So wait, validate after you've exited the field. Okay. Yeah.

[00:46:57] Nic Steenhout: Here's one of the things we see a lot is we see that the error message is important because it is, and we make it in a way that we wanna make sure that the screen rate of users knows, hey, this is an important error.

So we decide to put either a roll of alert or an area live assertive on the error message. So we know it's gonna be announced. But what you've just done is Arthur, you're using alert or area live assertive. You're going to get the screen reader to interrupt what it's announcing for the user. With every time you're pushing that error.

Yeah. Out. So basically you're starting to write Nathan, right? Yeah. Oh yeah. And hey, there's an error on this field. Hey, there's an error on this field. Oh t hey, there's an error on this field, and this is where it can really the amount of added cognitive load when that happens is unbelievable.

Yeah.

[00:48:03] Nathan Wrigley: It, that is utterly infuriating. That's about the most infuriating thing I can imagine having to go through. You're typing in an email address and every character is essentially screaming at you. You've done some that's, oh boy. pH forms seem like a real, I know we've only really touched on labels and then.

Diverted and went off in another direction. But yeah, this is an area which I feel is gonna be important. Okay. And then, so on keyboard images, forms

[00:48:37] Nic Steenhout: and contrast, there's been this thing about gray text on gray background looks fantastic. Yeah. And this fad just keeps on going.

And I gotta say, if you look at a page that's designed with poor contracts, you take your phone out on a sunny day and I challenge you to actually look at the page without squinting or having to figure out what's going on. You want good contrast. And there's really three things to keep in mind around contrast.

The first thing is regular text. Should have a contrast ratio of 4.521 against its background. And this number, the ratio of 4.521 is something you can find. Contrast analyzer tools anywhere on the web, there's dozens of these tools. It's even in your Chrome code inspector. So 4.521 for regular text.

3, 2, 1 contrast ratio for large texts. So if you have larger fonts headings, anything that's 18 points or bigger is 3, 2, 1. Then you have non-text contrast that needs to also have a three to one ratio and non-text contrast. It's your images, it's your icons in the clean feed interface that we have.

We have the microphone that is white against green green background. We have the headphones that's white against blue background. I haven't done the test, but if I eyeball it, I know for sure that the headphone will pass the three twenty one. The microphone would probably pass three to one, but probably not 4.5 to one.

Okay? So those are three contrast levels to remember and it is just so important. You also, when you're talking about contrast, you also want to think about your links. We often say underline your links, and designers say, but underlines are ugly. And I say, okay, if you don't want to underline your link, you have to be very careful with your contrast because the link color itself needs to have 4.5.

One contrast against the background, but to be able to be identified as being different from the surrounding text, it also have to have three to one contrast against surrounding text. Okay. So that becomes really difficult to find the right color. So just underline your links. It's been the thing for 30 plus years.

Just do it. Can I ask,

[00:51:51] Nathan Wrigley: in terms of, let's say you mentioned icons and the ratio that you need there, w what is the, so there's a boundary between the background and the icon, and we're trying to make the boundary. Really clear. So that's the icon, that's the boundary. What are, what is the person perceiving there?

If the boundary isn't as clear as that. If the contrast ratio is not high enough, is it that it just fades into the background and is more or less invisible? Is it the background is blurry, so it's almost like you're squinting at it.

[00:52:30] Nic Steenhout: It really depends on the person's vision condition.

Okay. For some people it's just going to fade out. Yeah. It's if you reduce the opacity of an element, at some point you go from a hundred percent capacity to 80 to 50 to 30, and at some point it's going to become so faint that you can't see it. For some people, their vision means that if there's not enough contrast, What is clearly visible to us at maybe 50% will not be visible at all.

So that's where we have to have that good

[00:53:07] Nathan Wrigley: level of contrast. Yeah. So the background, so essentially the icon could be indistinguishable from the background a k that's correct. The icon doesn't exist. It's just not even there. Oh, wow. Yeah. Okay. So do you feel that you've done contrast to the level that you wanted there?

[00:53:25] Nic Steenhout: I think so. Okay. I could, I always talk more about these things? Yes. Yeah. As an intro, as

[00:53:30] Nathan Wrigley: a, I feel there's a good 12 hours in you about all of these things, but Yeah. Yeah. Okay. Okay. So the next thing I wanted to ask is you've mentioned along the way you've mentioned that, there's tools to do this and there's tools to do that.

Could you give us a bunch of tools, just a few that you think would get us off in the right direction? And when I say tools, I don't literally mean, browser extensions or tools that you could download. It could be a resource, it could be a website, just something which can push us in the right direction.

[00:54:05] Nic Steenhout: Yes. Before talking about specific tools, I'd like to talk about the, a general workflow that people can implement to make their accessibility testing a little bit easier. Oh, okay. And there's really several levels of testing and the first thing you should do is you should do automated testing and there's a lot of free tools that you can use.

The two. Come to mind are DQ X tool A X E has browser plugin. And what that is going to do is it's going to look at your code and it's going to identify the things that are easy to identify. It's gonna calculate your contrast issues. So it'll tell you, Hey, you have got contrast problems. It's gonna look at your form elements and see if you have labels that are missing and it's going to look at your images and see if you have all text missing.

So automated tests are a really good way to get started, to identify the low hanging fruit like you were mentioning earlier. So you were asking me about the hanging fruits. I told you about the critical things to look at. And then we're coming back to this low hanging fruit concept, which can be caught by automated testing.

Now, You cannot rely entirely on automated tests because they will catch, on average about 40% of what's there on a page. So there's still a lot of things to look at. For example, the automated test can tell you whether or not you have the alt attribute on an image, but it cannot yet analyze is this image decorative?

Is this image informative? If it's informative, is the quality of the alt text appropriate for this image, right? So it can tell you, you forgot the alt text. Silly, but it cannot tell you, Hey, you've got alt text. Is it good? So the first pass everybody in accessibility does is automated test.

It'll catch if you have duplicate IDs, it'll catch these kind of things that are really. Brain numbing kind of code review that can be difficult. The second pass is what we call manual testing. And that involves, for example, using your keyboard to navigate through and find whether or not everything is usable with keyboard.

It can also involve doing some code review. You look at a form, you test to see if there's error messages. You look at the code to see if the error messages are programmatically associated. So that becomes really where most of the work is. And then the third thing you can do if you have a little bit of money is get usability testing done by disabled people.

So you identify people with disabilities that can do tests, or you hire an outfit that does that for a living. There's couple fable, make it. Fable is one that does that. They're great because they have a large database of disabled users that will be able to tell you whether or not you've done a good job at actually making it accessible.

So those are the three main phases of testing. If we're looking at tools themselves. Automated tools I mentioned ax. There's also one called arc a r c, either or pretty good. One thing that I think is perhaps the best option out there, if you aren't familiar with how you do accessibility testing is a tool called Accessibility Insights.

And it uses the AX automated engine to do a first pass of automated tests. And then it gives you a step by step check of how you test all the things that you need to look for, keyboard, all the things you need to look for headings, all the things you need for one at a time. So it becomes basically your checklist that you can start using and relying on to really build that muscle memory as to what you need to do.

So accessibility insights, it's plug in or I think it's also standalone on Windows, but I'm on a Mac ecosystem, so I use the plugin.

[00:59:09] Nathan Wrigley: Thank you very much. Yeah, that's really, they're really helpful. Okay, so three phases to the testing that you ought to be doing and then a couple of good tools that you've mentioned.

Now just before we wind it up, there's there's been this recent trend in the past to we know what humans are like. We like a quick, easy fix. We like to we like to press a button, click a button, and everything's done for us. And it would appear that these tools have come around, I'm gonna broadly call them overlays, which endeavor to big ILOs with this notion that you can press a button and your accessibility woes will disappear.

I'm sure you've got something to say about this and I don't suppose it's going to be entirely.

[00:59:59] Nic Steenhout: Let's just say that I could speak for 12 hours about this and I could be very rude about how I'm thinking. There is no magic bullet. It just doesn't happen. Before I go into any level of details, I would invite people that want to learn more go to the overlay fact sheet and they can read the details about why it's bad, and they can see the over 700 accessibility practitioner, disabled users and other people in the accessibility and disability community that support this fact sheet.

One of the problems is that just like automated tests can't identify all the issues, the overlay cannot. Identify all of the issues. It also cannot fix all of the issues. And you've seen it, I'm sure you've seen it, this little logo of a man typically at the bottom right or bottom left of the screen, and you click on it and it's accessibility tools and it lets you change, contrast or make it keyboard friendly or it will narrate the screen or whatever option are there.

The concept of that is very appealing, but the reality of it is that it often conflicts with the person's own tool. For example, imagine this, you're blind. You require a screen reader to be able to interact with not only the browser but your computer. You're not blind. Only when you go to a specific webpage that is so very kind to tell you, Hey, we have this screen reader so you can interact with our page.

No, because you need a screen reader on the computer at any all times. So suddenly you have this overlay that is trying to push something that is already in use with a much better, stronger system keyboard to be able to get to the overlay trigger button to open that up to make the side keyboard friendly.

How do you get there if you don't have a mouse and the site is not keyboard friendly in the first place. So there, there's all these little problems that actually are actually, it doesn't work. Maybe in the future. We're going to be able to rely on automation like that to make it easier for everyone.

But right now it doesn't work. If you look at the at the terms of use of some of these overlay companies, and I'm not naming thems because they are very very quick at swing people that are talking bad about them. But if you're looking at the terms of use and the conditions and the warranties, you will see that a lot of them are telling you that they can't actually guarantees to do the things that they promise to do.

And then the last bit to consider is that more and more there are accessibility lawsuits out there. So if your website is not accessible, it is possible you will get sued. There were. An average of between five and 6,000 lawsuits in the United States for non-accessible website every year since 2016.

And more and more of those lawsuits actually named the overlay companies as defendant in the suit because the overlay is not doing what it needs to do. Correct. So maybe you think it's neat and easy and quick and whatnot to use one of these tools, but ultimately you are not achieving what you want to achieve with it, and you're spending your money for nothing.

[01:04:28] Nathan Wrigley: Yeah. Okay. That's fairly categorical advice. Yeah. Okay. Thank you. Just before we wind it up, I'd like to give you an opportunity to talk about the podcast that you do and also to mention some other resources that you feel are of interest. So let's begin with your podcast and then move on to other people or websites that you might like to recommend.

So tell us about the Accessibility Rules podcast.

[01:04:56] Nic Steenhout: Yes, the Accessibility Rules podcast, a one one y r u l e s.com is I have two series and the one that is really most interesting and most active right now is called a Sound Bite. It's a series of short conversations I'm having with disabled people.

And by short generally less than 10 minutes where we talk about where the disability is. What barriers they experience on the web and what message they have for designers and developers. And I think this is really powerful because we can talk, like we've been talking about accessibility, but until we really understand the impact lack of accessibility has it's just completely different. And to hear it in the words of disabled people is really powerful. And once you've heard it, you can't un unhear it. I, obviously I'm preaching for the choir here. I'm biased. I think it's a wonderful show, but I'm also hearing from a lot of people that it is a wonderful show and it's a very powerful thing.

So check it out. One episode of week, every week on Monday is coming out. So that's my show resources, the. Web accessibility initiatives section of the W three C website is absolutely filled with great information. That's w three.org/w ai. There's so much stuff there to look at. So I think those are probably your two starting points.

My web, my podcast, and the Y website. And then I look at DQ universities, that's D E Q U E. They do the AX tool. And in the AX tool, when they're running their automated test and they're returning an error, they will link to they will link to. Their explanation as to why these things are wrong.

And it refers to the standards. So it's actually quite well done. There's the there's the Mozilla web developer tools that are giving really good explanation about different elements and how to use them. And that becomes really important around using area all the names the roles, the values you can use that becomes quite important.

And I think that's probably enough for people to get their, yeah, their toes wet and get

[01:08:00] Nathan Wrigley: started. That's really helpful. And very last question, if people would like to connect with you personally because they feel you might be very helpful toward them, what's the best way to do that, Nic?

[01:08:14] Nic Steenhout: Several different ways.

There's my. Website, I N c l.ca. So that's my website where I have a blog with tens and dozens of blogs around accessibility. And there's my speaker profile there. I'm on Twitter still and my handle there is a V R O m I am on LinkedIn. Nicola Asha is good to find me on LinkedIn. And then obviously my podcast has contact info, so a one one y r u l s.com.

[01:08:56] Nathan Wrigley: Nic, I really appreciate you chatting to us today. I've realized we're trying to squeeze probably days and days worth of content into a very short space of time, but hopefully for many people it's been a bit of an eye opener, a bit of a beginning of the journey towards their website accessibility.

Really appreciate you coming on today. Thank you. Nathan,

[01:09:14] Nic Steenhout: thank you for having me. It's been a pleasure to talk with you.

[01:09:18] Nathan Wrigley: I hope that you enjoyed my chat with Nic talking all about accessibility. There certainly was a lot to cover and really I think Nic did an admirable job explaining all of the different bits and pieces.

If you've got any comments about that, head to WP Builds.com. Search for episode number 322 and leave us a comment there. It would be most appreciated. We do have a Facebook group as well. WP Builds.com/facebook. If you wanna search for the post in there, you can do as well.

The WP Builds podcast was brought to you today by GoDaddy Pro. GoDaddy Pro the home of manage WordPress hosting that includes free domain SSL, and 24 7 support. Bundle that with The Hub by GoDaddy Pro to unlock more free benefits to manage multiple sites in one place, invoice clients and get 30% off new purchases. You can find out more by going to go.me/WPBuilds.

Okay, we'll be back next week. We'll have a this week in WordPress episode on Monday, and then we'll have another podcast episode. It'll be David Worsley and I having a chat in our Thinking the Unthinkable series. I hope that you join us for some of that. Don't forget to subscribe. WP Builds.com/subscribe. Have a good week. Stay safe. Bye-bye.