Accessibility Show with Joe Dolson, Episode 1: Mobile Menu Toggles

Transcript

Show and hide the transcript

[00:00:06] Nathan Wrigley: This episode of the WP Builds podcast is brought to you by 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% of new purchases. Find out more at go.me/wpuilds.

And by Bluehost. Redefine your web hosting experience with Bluehost Cloud. Managed WordPress hosting that comes with lightning fast websites, 100% network uptime, and 24 7 priority support. With Bluehost Cloud, the possibilities are out of this world. Experience it today at bluehost.com/cloud.

And by Omnisend. Do you sell your stuff online? Then meet Omnisend. Yes, that Omnisend. The email and SMS tool that helps you make 73 bucks for every dollar spent. The one that’s so good, it’s almost boring. Hate the excitement of rollercoaster sales? Prefer a steady line going up? Try Omnisend today at omnisend.com.

And by Memberful. . Building a membership website? Checkout Memberful. Memberful allows you to easily add gated content, private member spaces, payment collection, and more to your WordPress website. Get started for free at memberful.com/wpbuilds. That’s M E M B E R F U L dot com forward slash WP Builds.

Hello there. I am joined by Joe Dolson today. How are you doing, Joe?

[00:02:03] Joe Dolson: Oh, I’m doing great Yourself.

[00:02:05] Nathan Wrigley: Yeah, really good. This is brand new. Joe and I actually, quite a while ago, we were sitting together on a table at a restaurant outside of, it was in Word Camp Europe in Turino, right? It was not that far from the venue.

And, and we came up with the idea of this show. So this is an experiment. We’re gonna see how it goes. We know, I have no idea if the tech is gonna work. I’ve no idea, exactly what Joe’s gonna do, what Joe’s gonna say. The premise of this show is to, offer up an opportunity for Joe to demonstrate his expertise.

Joe, as you’re about to find out, is really into web accessibility, which kind of segues nicely for me to offer you an opportunity, Joe, just to tell us who you are. So do you mind giving us your, like elevator pitch, who you are and so on?

[00:02:51] Joe Dolson: Sure. my name is Joe Dolson. I am a website accessibility consultant, and I also do plugin development.

I’m a core committer to WordPress, so I’ve been working on accessibility in WordPress core for about, oh, let’s just call it 12 or 13 years. I don’t feel like actually looking it up right now. It’s too long to think about.

[00:03:17] Nathan Wrigley: Okay.

[00:03:17] Joe Dolson: But I have focused my entire business since I started it in 2004, around the topic of website accessibility.

And so I’ve just got a pretty significant depth of experience in that area. And so it’s always an interesting thing to look at, see what people have done, see what people are doing well, people are doing less well and just explore.

[00:03:40] Nathan Wrigley: Nice. so the, idea of this show in particular, and we don’t know if this format is going to be one that we stick with, but we thought for this opening show, we would go with the premise of finding some websites out there, and we’ll demonstrate how we found those in a moment, and then picking a thing.

On each of those websites, Joe is gonna poke around, ferret around in real time and you’ll get to see the tools that he’s using and so on. So that might be useful, but also you’ll be able to just focus on this one particular topic.

Now, a few caveats. The first thing to mention is that the websites that we have chosen. Have come from this place. Now, you may recognize this, is the WordPress Showcase, and if you’ve not been here before, an easy way to find it is to go to wordpress.org/showcase. And, it’s no, it’s not particularly new, but it’s had a bit of a refresh of late. And the intention of this website is to demonstrate websites which are using WordPress, which, I think it’s fair to say represent good design. Let’s go with that.

So they might not necessarily, be perfectly accessible, but I, just wanna point out at this opening juncture that the intention of this show is not to cherry pick things and, let’s say mock them or poke holes in them. The idea is really, we needed a repository where we could reliably find WordPress websites, and the idea would be for Joe to have an opportunity to pick some and then go through areas where they might need help. So this isn’t about naming and shaming, or at least I hope that’s the intention, Joe?

[00:05:21] Joe Dolson: Oh, absolutely.

[00:05:23] Nathan Wrigley: Yeah.

[00:05:23] Joe Dolson: I think a big thing of what I want to be able to express from this is how common accessibility problems are. Sometimes I worry that people have the general impression that most websites are basically accessible, and if somebody is out picking out accessibility problems, it’s something that they’ve really hunted down and searched out.

And the reality is, 97% of the top million websites have obvious automatically detectable accessibility issues. This is a great study by Web Aim at webaim.org. It is the million website study and they, do an enormous amount of automated testing to look at websites and say, yeah, most websites have lots and lots of problems.

So I just want to be able to look at a few things and say, yeah, this is common. These are not. This isn’t something that a developer should be embarrassed about. It’s something a developer should look at and say, I have a thing to learn. I could do this better.

[00:06:27] Nathan Wrigley: Yeah, that’s perfect. That’s a really nice way of framing it. And if you were watching, if you have the ability to watch what we’re doing, I have just been scrolling through the video and really you can see that the caliber of websites on this, on this showcase, it’s pretty high. There’s some fairly heavy hitting names out there, so they’ve definitely cherry picked some of the bigger players in the WordPress space. It feels like a lot of this is enterprise stuff.

But what’s interesting Joe, I think one of the things that we should probably say right at the outset is it definitely feels as if d it’s opinionated upon design. A lot of the things in here have really unique design, and maybe that’s, maybe that’s the criteria. I’m not entirely sure, but it’s certainly there’s something there. They all look fairly special, fairly unique. They’re not made from a cookie cutting template, I don’t think.

[00:07:19] Joe Dolson: Yeah, I do think a significant part of what the team that reviews showcase submissions is looking for is unique design ideas, something that’s a little out of the box. And, that’s definitely what they’ve got. They’re, you’re not going to find a lot of, you’re not gonna find very many WordPress core themes in here.

[00:07:42] Nathan Wrigley: Let me just have a little quick look here. We have things like category, and flavors and things like that. And then we can sort as of this moment, I could be wrong, but as of this moment, there doesn’t appear to be a way to filter based upon accessibility.

You never know. Maybe that’s something that’s gonna come in the future, but.

[00:08:03] Joe Dolson: It has been talked about.

[00:08:04] Nathan Wrigley: Okay.

[00:08:05] Joe Dolson: There is actually an open GitHub issue about adding that as a criteria and and flagging sites that are accessible. But there’s a pretty significant challenge in terms of the amount of time it takes to actually review that. And, the reality is, a full accessibility audit takes hours and hours, and we’re not going to do that. There’s simply no way it’s realistic to put that much time into assessing the accessibility of these submissions.

So that becomes a question of how much time is reasonable to decide that it meets some level accessibility, which is not going to be considered any, like, qualified acceptance criteria for claiming accessibility.

[00:08:50] Nathan Wrigley: Yeah.

[00:08:50] Joe Dolson: So you don’t wanna make a legal claim for a website. Hey, this website meets all criteria and they don’t. And that’s awkward.

[00:08:58] Nathan Wrigley: Yeah. So.

[00:08:59] Joe Dolson: A hard problem.

[00:09:00] Nathan Wrigley: Yeah. I’ll, move that website out of the way and just to say this is not therefore a sort of 101 in every single thing that you could possibly think about in terms of accessibility.

What Joe has decided to do is pick one thing. Then show on a few websites using the tools that he’s got available to him that one thing, over and over again in ways that it might be implemented on one site or a different site and so on. So without further ado, I’m gonna raise Joe’s screen there and we’ve got one here, on.

So your screen is divided into two parts. We’ve got the inspector from Chrome on the one side, and we’ve got the website, which is called noguchi. This is from noguchi.org, noguchi.org. You can find the website there. And what is under the microscope today, Joe? What is the thing that you’re gonna look at on everything we touch?

[00:09:55] Joe Dolson: The thing I decided to take a close look at here is mobile menu toggles., Because ultimately the mobile experience is an incredibly prominent thing. It’s huge for people with disabilities, because phones are cheaper than computers and the assistive technology and screen readers available on phones is just as good.

So it’s a great way to get around a website, but of course that also means that for almost all sites you’re dealing with a collapsed mobile menu. And so I picked this because, first of all, it’s a really significant issue for websites. Access to the menu is obviously a key thing to be able to get around the website. Even if every single page was perfectly accessible, if you cannot operate the menu, you’re basically done.

The other reason I picked it is because literally the first six websites I looked at all had different ways of implementing this button, and they all had some kind of a problem with it.

[00:10:55] Nathan Wrigley: Okay.

[00:10:55] Joe Dolson: So it gives a lot of different things that I can illustrate. They’re different, they’re not the same problem, and they’re interesting. So let’s just dive in.

[00:11:06] Nathan Wrigley: Yeah.

[00:11:06] Joe Dolson: So this first one on noguchi.org. First of all, this mobile menu, obviously it has no visible label. So my first question becomes what is in fact the label of this particular control? And so I’m gonna be looking at the inspector, and I usually leave the accessibility attributes open.

And so you can see down here on the bottom that it has an aria label that says open menu mobile. I, that’s reasonable. It’s a reasonable guess. It is an odd string of text. Really all this needs to say is menu, because what it does and how it behaves is a separate issue, but it is labeled so it has a name. That’s great.

However, what I also observe is that it’s a link, so it’s a link with, just a blank address. It’s using the hash for an address. Now what that potentially means is when it’s activated, it might move the focus, if they haven’t taken control over that, because that hash can, it can be a reference. It’s just a blank reference on the page. So it’s going to move the focus to somewhere on the page.

And that’s because of what links do. Links are fundamentally about moving you to a new location, whereas buttons are about creating actions. This should be a button that would be more expected, more predictable.

The other reason it should be a button is that buttons, have different controls than a link. Buttons open using space bar or enter, and links only work on the enter key. So if somebody is wanting to use a particular pattern, if that’s their habit, it might not work.

Now the next thing I would find here, I’m going to tab into this, and so I’m gonna turn on something that will show you what I’m doing. Whoops, that’s not the thing I wanted. This is basically just a tracker that keeps track of what key I’m pressing, so that you can tell what I’m doing, even if things aren’t visible. So I’m gonna tab in and try and find the button. Right now I’m on something that I can’t see, so I don’t know what that is.

But, I get to this menu button and it does have a focus and that’s useful. So let’s open it. So I just tried it with the space bar just to test whether they’d added an event that handled that space bar and it didn’t work. It just shifted the focus slightly, so that’s annoying. Not great, but it does work with the enter key. Now I can tab forward and see where I am.

Unfortunately now I’m not seeing anything, so I have absolutely no idea where I am on the page. I’m gonna try and escape this menu to see what I’m doing, but escape doesn’t close it.

[00:14:02] Nathan Wrigley: So just to be clear, these would be you, are using tab, space, escape these and in your case.

[00:14:10] Joe Dolson: Yeah. This is the experience that.

[00:14:11] Nathan Wrigley: This is the normal, right?

[00:14:12] Joe Dolson: Anybody who’s using a keyboard will have, if they’re not using a screen reader.

[00:14:16] Nathan Wrigley: Okay.

[00:14:17] Joe Dolson: Now a screen reader is gonna give you a bit more feedback. This is more the experience of somebody who’s sighted, and I’m doing that because in all honesty, trying to do an audio recorded event live with a screen reader is challenging.

[00:14:32] Nathan Wrigley: Yeah. Yeah.

[00:14:33] Joe Dolson: And I don’t want Nathan to have to spend the next month and a half in editing. So you’re gonna get the, keyboard. But this is a real experience when people do navigate using a keyboard from a mobile device. This is a very real thing that most people tend to ignore.

And one of the keys about accessibility is that when somebody says navigating with a keyboard on a mobile device, the people tend to seize on the idea that is a sole way of functioning. And what we’re talking about is the kind of mythical keyboard only user. But that’s not a real thing. What is real is that people use a wide variety of mixes of interactive methods, and the fact is whatever they are using at any given moment should work.

You shouldn’t be obligated to switch from your keyboard to a pointing device because this control only works from a pointing device. Because when you’re imagining a user, somebody who has very limited mobility, who’s using a breath controlled puff and sip device, the effort to switch between one type of controller and another is extremely high. That barrier is big. They should be able to stay on what they’re using as long as they possibly can.

[00:15:59] Nathan Wrigley: Okay.

[00:16:00] Joe Dolson: At any rate, what we’ve just seen here is that the biggest problem here is that once you’ve activated this menu, your location is lost. You don’t really know where you are, until you finally get to this close button.

But in the meantime, I don’t know what I’m doing, and I don’t know what will happen. And I just hit enter on something. I don’t know what it was and I don’t know what it did. So honestly, I have literally no idea what was going on with that menu. It would require a fair amount of effort to explore it and find the real details. Suffice it to say, it’s a challenge.

[00:16:41] Nathan Wrigley: Okay. Okay.

[00:16:42] Joe Dolson: So I’m gonna just go ahead and pop open another one.

[00:16:46] Nathan Wrigley: So, again, we’re gonna look at another website from the showcase, in this case. By the way, all of the links will be buried in the show notes, which you can find at wpbuild.com. This is quebec.ubisoft.com. That’s the URL and, okay, off we go again.

[00:17:04] Joe Dolson: Oh, this is much the same thing. We’ve got another mobile menu toggle. Again, it has no visible label, so I’m immediately curious whether it has an accessible name. And in this case it does not. In fact, what this is just, it’s a div. It has a couple of spans in it that are styled to look like lines. So it’s not even using character that could conceivably have some kind of unicode naming. This is, that’s pretty much a bad sign. The fact that it’s a div and doesn’t have any accessible name, it means it basically doesn’t exist for most screen reader users, or keyboard users. But let’s just see what happens.

I’m gonna go ahead and turn on the pressed key monitor so that my keyboard navigation isn’t completely an illusion. Okay. I’ve gotta focus on the business name and on jobs. And then I have jumped into discover our culture.

So this as, as pretty much I expected from the fact that it was a div without any kind of tab index attribute, I was unable to get to the menu. So in this case, this would be very difficult. I do know that a very experienced screen reader user by navigating, using arrow keys and arrowing through the text, might be able to get to that control and then activate it. But the average user is simply not going to find this.

[00:18:47] Nathan Wrigley: Okay?

[00:18:48] Joe Dolson: And in this case, whether this control loses your focus or not is somewhat irrelevant because you can’t get keyboard focused to it in the first place. Therefore, there’s no reasonable way you could worry about whether you’re going to lose focus. So this is always one of those issues in testing a website where I’m like, because you have this problem, I can’t realistically test this other problem. I’m going to warn you about it, but there is no situation in which I can actually trigger it.

Okay. And so I feel like that one, it’s pretty much a quick summary of exactly what that is doing. There’s not a lot to say. It doesn’t work.

[00:19:33] Nathan Wrigley: Okay. That was that was quebec.ubisoft.com. We’re now going to design museum, spelled as you’d Imagine, dot dk. Designmuseum.dk. Okay. And remove the inevitable cookie banner. Yeah. here we go. Okay.

[00:19:52] Joe Dolson: So this one, it’s the same presentation to start. I. Now we’ve got three lines. This one’s an SVG. Now an SVG is an element that can take a name. This one does not however have one. It would’ve required a title attribute, a title element that could receive that name in some aria.

So this is at least, it’s hypothetically more practical to name this one, with just the element you’ve got there. However, I see that it looks like they have not. And again, this is a div. So it’s going to have an event attached to it. It does not appear to have any keyboard focus, and it does not appear to have any name.

This is a great thing in the inspector. It can give you all of these accessibility properties. So like from the name, it’s going to be using the accessibility tree to calculate what the accessible name of it, the element is. It’ll even tell you where it’s from, but this has no title, no aria label, no aria labeled by, and no contained text.

So effectively it has no name.

[00:21:00] Nathan Wrigley: Okay.

[00:21:01] Joe Dolson: So that’s a little frustrating. I’ll also note, and I failed to mention this on the previous items, that what this also isn’t informing you about is whether or not it’s open or closed. So when I open this menu, in theory, the control that you get to should have an aria expanded attribute, that indicates whether or not it’s open or closed. Again, since this control can’t be reached using the keyboard, it’s a little bit irrelevant.

I will quickly test and see whether they’ve added any kind of handling to be able to get to it. On this case, I’m doubting it because I don’t see a tab index attribute, and so it’s fairly unlikely. And indeed I see nothing at all happening on this website.

[00:21:46] Nathan Wrigley: No.

[00:21:46] Joe Dolson: There is, I reached the skip to content link. That comes into focus, but unfortunately it does not appear that anything else has a focus state. On this page, though there are clearly things that I can tap to. So that’s going to be a pretty frustrating experience for anybody trying to navigate using a keyboard.

I do have two more sites to take a look at.

[00:22:13] Nathan Wrigley: Okie doke.

[00:22:13] Joe Dolson: So let’s go ahead and just take a look at those and see what we’ve got.

[00:22:18] Nathan Wrigley: I’ll quickly tell everybody what this one is. I don’t know how to pronounce it, but I’m just gonna say tetuhi.art. So it’s spelled T-E-T-U-H-I.art, A-R-T. And Oh, interesting.

[00:22:33] Joe Dolson: And that one started off with some fun animation.

[00:22:36] Nathan Wrigley: Yeah.

[00:22:37] Joe Dolson: Which, that might have been fine. I don’t at the moment have prefers reduced motion turned on my machine. I turn that off and on pretty regularly ’cause I’m in the process of testing. So I don’t know whether that was respecting it.

Animated text can be very strange for a screen reader. I did review a site yesterday that had an animated H1 heading nested in a slider.

[00:23:03] Nathan Wrigley: Okay.

[00:23:04] Joe Dolson: So the main heading of the page changed every few seconds, which I will tell you that the screen reader I was working with found that to be a bit confusing.

[00:23:14] Nathan Wrigley: Yeah, I’ll bet. Okay.

[00:23:17] Joe Dolson: But this menu, at least, I’m looking at it and it actually has a visible label, so that’s great. That means if you’re using like voice command, you’re going to activate this by saying something like, click menu. Which is great if it’s actually named that, which is something to check.

And in fact, it is not named menu.

[00:23:38] Nathan Wrigley: Oh, okay.

[00:23:39] Joe Dolson: So here’s where it gets a little bit interesting. The, so there’s a WCAG principle that’s called label in name. This does pass that, because the word that’s visible is menu and the actual label is coming from this aria label attribute that says, open the menu.

The problem here of course is label in name just means it’s present. The way voice command frequently works is it’s expecting the visible information to be at the beginning of the accessible name. This is highly variable. Some voice command tools, you have to speak the entire name, so even you may not be able to see it, but you need to use the entire thing. So that can be a little bit frustrating when those don’t match.

I would also argue that it’s unnecessary. there are other ways of indicating whether or not you’re gonna be opening or closing. That’s where that aria expanded attribute comes into play. Is that it tells you whether it’s open or closed.

So you don’t really need to use that in the name. It’s just part of the state of that control. What I’m also noticing here is that this is another link element. It’s an anchor. This one does not have an href attribute. So that does mean it’s not going to trigger a strange shift in the page.

[00:24:59] Nathan Wrigley: Okay.

[00:25:01] Joe Dolson: But it also means that you can’t focus it with the keyboard.

[00:25:04] Nathan Wrigley: Okay?

[00:25:04] Joe Dolson: Because the anchor element is not a link. The A element means this is an anchor. If it has an href attribute, that means it’s an anchor that points to somewhere and is there for a link. If it does not have an href attribute, it’s a target. It’s something that a link can point to.

[00:25:21] Nathan Wrigley: Toward. Yeah. Yeah.

[00:25:22] Joe Dolson: And that’s usually done using an ID attribute. However, since it doesn’t have an href, it actually is something that can’t receive keyboard focus. So let’s go ahead and turn on pressed keys again and just dive in and see what we can do.

I’m tabbing and I’m tabbing. I’m not seeing any focus. Now, a lack of visible focus doesn’t necessarily mean that it’s not there. So what I’m gonna do is I’m going to enable its focus state to see whether it has a focus state, and it does not. So in the inspector, what I just did is I selected the interactive element, the anchor, and I forced its focus state. But it didn’t change anything. So what I know from that is that in my tabbing, I really truly did not reach this item, which is what I expected. Since it doesn’t have a tab index or an attribute.

So you can see that they’ve clearly made some effort to try and do some accessibility. They have an aria label. They have visible text, and nonetheless, what you’ve ended up with is a menu toggle that cannot be accessed in any way.

So one more.

[00:26:40] Nathan Wrigley: Okay. Last but by no means, please.

[00:26:42] Joe Dolson: This is the last one.

[00:26:43] Nathan Wrigley: This is fabbricagroup.Fr. So fabbricagroup, group, all as one word dot fr. And we had a fair bit of animation going on there, didn’t we? At the the page load.

[00:26:57] Joe Dolson: Yeah. This one was a little bit simpler. It was pretty much all graphic animation and not text. I’d generally be less concerned. It’s probably, it’s essentially a loading screen. And it was fast enough that it probably doesn’t need to be expressed. Of course, I’m on a pretty fast connection.

[00:27:13] Nathan Wrigley: Okay.

[00:27:14] Joe Dolson: So here we go. Once again, no visible label. I will inspect that. Hey, this one’s actually a button.

[00:27:24] Nathan Wrigley: Okay.

[00:27:25] Joe Dolson: This one has an aria label that says menu. Great. So that’s a wonderful thing. So now I’m expecting this, I’m expecting this to work. I do not see an aria expanded state right now. That’s not necessarily evidence that it’s not gonna inform you of this. It could be added only when it’s active.

[00:27:47] Nathan Wrigley: Okay.

[00:27:48] Joe Dolson: That would be an error, because right now it does not communicate to you whether that it’s closed. So aria expanded equals false would tell you this is not currently expanded. So that’s, something I’m gambling is likely to end up being a problem. So let’s just tab through, see what we’re doing here.

That’s a little disconcerting. I tabbed to this Instagram link and to the title, and I have skipped, apparently the button. Now I know as a button, it pretty much has to be focusable. So what that probably means is it doesn’t have a visible focus state. So I think I’m on it right now. As the thing to the left of the title. I’m correct, I was.

Now the lack of a focus state is going to be a problem, obviously for cited people using a keyboard. It’s a little bit frustrating, it’s a little unnerving to jump past things and without knowing that you did it.

So let’s see what happens now that we’re in the menu. I’m still navigating the header stuff, so it’s visible though, so that’s okay.

[00:28:57] Nathan Wrigley: Yeah, okay.

[00:28:58] Joe Dolson: It’s honestly not a problem. But then the next thing, I can see from the monitor of the current link that’s down in the bottom left corner.

[00:29:06] Nathan Wrigley: Yeah.

[00:29:07] Joe Dolson: That I am on a link to Montmatre, so I think that I’m in the menu and where I’m supposed to be. And the next one is Ternes. Yeah.

[00:29:17] Nathan Wrigley: Yeah, looks like you are.

[00:29:18] Joe Dolson: So I’m in the menu, but continuing. I don’t have a focus state. So there’s nothing here to, that helps me easily see where I am. I’m having to use a reference that’s really fairly technical and down in the far left corner, particularly for somebody who’s low vision.

You usually can’t possibly see that piece of information. So this would still be a somewhat frustrating experience. However, it’s at least possible. You can get to these things and the information is there. This is going to be a much better experience for somebody who is using a screen reader, because those focus issues won’t be relevant. Though they will have a difficult time telling whether the menu’s open or closed.

Let’s see if it closes with the escape key. It does not. So in order to close out of this, you do have to go backwards and find that close button again. Which since it’s not, doesn’t have a focus state, it’s a little hard to say, Ooh, I just got lost. What I, I guess I just got lost and I’m not sure why that happened.

But Shift tab did not take me through what I expected it to. I’m now wondering whether I was not actually in the menu.

[00:30:31] Nathan Wrigley: Oh.

[00:30:31] Joe Dolson: Circumstantially also the same links that are on the page. It is. Ooh, God, that.

[00:30:37] Nathan Wrigley: Oh goodness. Wow. What happened there?

[00:30:41] Joe Dolson: I did not like that. Anyway, so yeah. In fact, I was not in the menu at all. It’s just coincidentally, the content on this page is the same as what would be in the menu. Let’s see.

[00:30:53] Nathan Wrigley: Oh, I see. Okay. So there’s, yeah. Okay. Okay.

[00:30:56] Joe Dolson: So it seemed like I was, but once I started to navigate around to try and leave the menu and discovered I was not in the right place, I now knew, I’m not actually here. I’m somewhere else on the page.

[00:31:08] Nathan Wrigley: Okay.

[00:31:08] Joe Dolson: So this is a menu that opened, concealed the whole page, but didn’t place your focus into the menu itself. What that probably means is that this menu is not in the DOM order, where it appears. The mobile menu is probably tucked at the very end of the document object, and then it just says, made visible.

Whereas the expectation when you toggle something and then tab, is that should be the next object in the document. So it should actually be located right after the control that triggers it, and then that focus happens automatically. There’s no concerns. Nothing has to be done.

So anyway, that was an example of just running through five sites. They all have beautiful designs, but they also all have mobile menu controls, and mobile menus that exhibit some fairly significant problems, that are, frankly, quite readily solvable.

[00:32:07] Nathan Wrigley: I think firstly, I’ve just removed the screen, so it’s just me and you again, Joe. That was really interesting.

So firstly, I will put all of the, the links to the Chrome extension that you used and the five websites plus the showcase itself. I’ll put those into the show notes so that they’re nice and easy to find. I think maybe, I’ve got an intuition about what we could do on the next one.

[00:32:34] Joe Dolson: Oh, great.

[00:32:34] Nathan Wrigley: Which might be to, might be to demonstrate a fine example of a mobile menu that might be a, a nice light and shade contrast between one and the other.

[00:32:45] Joe Dolson: Yeah. How would do it, right?

[00:32:46] Nathan Wrigley: Yeah, and demonstrate all of the different bits and pieces because we probably spent, what, three minutes unpacking each of those websites and I suspect we could probably spend round spend 20 minutes or so on finding a really nice example of something which captures exactly what we just were trying to see there.

[00:33:03] Joe Dolson: Indeed.

[00:33:04] Nathan Wrigley: And does it in a really nice way. I think that’s a wrap for our first one. Hopefully that was useful. Give you some intuition of ways that you can, how to describe it, muck up not correctly configure your mobile menu and some of the pitfalls that you might fall into.

Is there anything else you want to add before I click the stop button, Joe?

[00:33:29] Joe Dolson: I just want to thank people for watching, and I hope that they found that useful.

[00:33:34] Nathan Wrigley: Yeah.

[00:33:34] Joe Dolson: And if you’ve made those mistakes, it’s okay. People make mistakes and that’s how we learn.

[00:33:42] Nathan Wrigley: Where can we reach out to you, Joe, if people wanna actually communicate directly with you?

[00:33:46] Joe Dolson: You can find me on the WordPress Slack at, Joe Dolson. You can find me on Twitter slash X as Joe Dolson. You can find me on Mastodon. My handle is Joe Dolson.

[00:34:02] Nathan Wrigley: Yeah, but which ininstance?

[00:34:04] Joe Dolson: But in general, Joe Dolson, no spaces all lowercase is my username on pretty much everything and that’s where you can find me.

[00:34:14] Nathan Wrigley: My little trick when I’m using things like Google is to write the name of the person and then add a space and then just type WP and it always seems to then isolate it to the correct, in this case, Joe Dolson. So that would be my trick.

Honestly, that.

[00:34:27] Joe Dolson: There are not a lot of Joe Dawsons.

[00:34:28] Nathan Wrigley: No. Okay. Yeah, I’m, in that lucky band as well. There’s very few Nathan Wrigleys as well. Joe, thank you for sharing your insights today and, hopefully we’ll catch up with you on another episode in the near future where we’ll, where we’ll rectify it and discuss the ways that maybe it could be done, air quotes better. Thank you so much, Joe.

[00:34:47] Joe Dolson: Alrighty. Thank you.

Navigating the Complexities of Web Accessibility and Best Practices

In the first episode of the Accessibility Show, accessibility expert Joe Dolson tackles an essential yet often overlooked component of web design: mobile menus. Focusing on practical examples, he delves into the intricacies of making mobile menus accessible, shedding light on common pitfalls, and offering insights for creating inclusive digital experiences.

The Importance of Accessible Mobile Menus

Mobile menus play a pivotal role in website navigation on handheld devices. Unfortunately, they often come with accessibility challenges that hinder user experience for individuals with disabilities. Joe emphasizes that accessibility transcends mere compliance; it’s about ensuring inclusivity for all users, including those who rely on keyboards or screen readers.

Analyzing Noguchi.org

Joe points out several issues with the Noguchi.org mobile menu. Chiefly, the lack of a visible focus state makes it challenging for keyboard-only users to navigate, creating confusion. The menu toggle is inadequately labeled, making it difficult for screen reader users to understand its function. The improper placement of mobile menus within the DOM order further complicates navigation for those using assistive technologies.

Quebec.ubisoft.com: Key Accessibility Issues

Examining quebec.ubisoft.com, Joe and Nathan identify similar accessibility problems. The absence of keyboard focus states and proper labeling of mobile menu toggles makes navigation problematic for users with disabilities. Joe stresses the importance of the aria-expanded attribute, which indicates to screen readers whether a collapsible menu item is expanded or collapsed. Its absence here adds to the site’s challenges.

Enhancing DesignMuseum.dk

DesignMuseum.dk faces issues with missing aria attributes and keyboard focus states. These shortcomings highlight that visual design alone is insufficient for an inclusive user experience. Joe underscores the need for visible labels, making interactive elements comprehensible to all users, including those relying on screen readers.

Animation and Accessibility Concerns at Tetuhi.art

Though briefly discussed, Tetuhi.art’s animated, mobile menu poses its own set of accessibility challenges. While animations are visually captivating, they can hinder accessibility if not implemented thoughtfully. Joe identifies problems with the menu’s visible labels, stressing that functionality should not be sacrificed for aesthetics.

Lessons and Future Directions

Throughout the discussion, Joe emphasizes learning from mistakes and staying informed about best practices. Nathan suggests future episodes could highlight exemplary mobile menus, offering practical learning opportunities for their audience. Both advocate for ongoing education and integrating accessibility principles into everyday design and development processes.

Conclusion: Striving for Inclusive Web Design

The inaugural episode of the Accessibility Show illuminates the urgent need for accessible mobile menus. By examining real-world examples, Nathan and Joe illustrate the common challenges and provide actionable insights for improvement. Their dialogue highlights that prioritizing accessibility is not only about meeting standards but about fostering an fair web experience for everyone.

Joe Dolson aptly concludes that achieving web accessibility is a complex journey, but creating a universally usable web is a goal worth pursuing. This episode serves as both a resource and a reminder to designers and developers that slight improvements can make a significant impact on inclusivity.

By focusing on accessible design, we collectively work towards a more inclusive digital world, ensuring that everyone, regardless of their abilities, can navigate and enjoy the web.

Supported by:

GoDaddy Pro
Bluehost
Try Omnisend today at omnisend.com

Discover more from WP Builds

Subscribe to get the latest posts sent to your email.

The WP Builds podcast is brought to you this week by…

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! Find out more at go.me/wpbuilds.

The WP Builds Deals Page

It’s like Black Friday, but everyday of the year! Search and Filter WordPress Deals! Check out the deals now

Transcript (if available)

These transcripts are created using software, so apologies if there are errors in them.

Read Full Transcript

[00:00:06] Nathan Wrigley: This episode of the WP Builds podcast is brought to you by 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% of new purchases. Find out more at go.me/wpuilds.

And by Bluehost. Redefine your web hosting experience with Bluehost Cloud. Managed WordPress hosting that comes with lightning fast websites, 100% network uptime, and 24 7 priority support. With Bluehost Cloud, the possibilities are out of this world. Experience it today at bluehost.com/cloud.

And by Omnisend. Do you sell your stuff online? Then meet Omnisend. Yes, that Omnisend. The email and SMS tool that helps you make 73 bucks for every dollar spent. The one that's so good, it's almost boring. Hate the excitement of rollercoaster sales? Prefer a steady line going up? Try Omnisend today at omnisend.com.

And by Memberful. . Building a membership website? Checkout Memberful. Memberful allows you to easily add gated content, private member spaces, payment collection, and more to your WordPress website. Get started for free at memberful.com/wpbuilds. That's M E M B E R F U L dot com forward slash WP Builds.

Hello there. I am joined by Joe Dolson today. How are you doing, Joe?

[00:02:03] Joe Dolson: Oh, I'm doing great Yourself.

[00:02:05] Nathan Wrigley: Yeah, really good. This is brand new. Joe and I actually, quite a while ago, we were sitting together on a table at a restaurant outside of, it was in Word Camp Europe in Turino, right? It was not that far from the venue.

And, and we came up with the idea of this show. So this is an experiment. We're gonna see how it goes. We know, I have no idea if the tech is gonna work. I've no idea, exactly what Joe's gonna do, what Joe's gonna say. The premise of this show is to, offer up an opportunity for Joe to demonstrate his expertise.

Joe, as you're about to find out, is really into web accessibility, which kind of segues nicely for me to offer you an opportunity, Joe, just to tell us who you are. So do you mind giving us your, like elevator pitch, who you are and so on?

[00:02:51] Joe Dolson: Sure. my name is Joe Dolson. I am a website accessibility consultant, and I also do plugin development.

I'm a core committer to WordPress, so I've been working on accessibility in WordPress core for about, oh, let's just call it 12 or 13 years. I don't feel like actually looking it up right now. It's too long to think about.

[00:03:17] Nathan Wrigley: Okay.

[00:03:17] Joe Dolson: But I have focused my entire business since I started it in 2004, around the topic of website accessibility.

And so I've just got a pretty significant depth of experience in that area. And so it's always an interesting thing to look at, see what people have done, see what people are doing well, people are doing less well and just explore.

[00:03:40] Nathan Wrigley: Nice. so the, idea of this show in particular, and we don't know if this format is going to be one that we stick with, but we thought for this opening show, we would go with the premise of finding some websites out there, and we'll demonstrate how we found those in a moment, and then picking a thing.

On each of those websites, Joe is gonna poke around, ferret around in real time and you'll get to see the tools that he's using and so on. So that might be useful, but also you'll be able to just focus on this one particular topic.

Now, a few caveats. The first thing to mention is that the websites that we have chosen. Have come from this place. Now, you may recognize this, is the WordPress Showcase, and if you've not been here before, an easy way to find it is to go to wordpress.org/showcase. And, it's no, it's not particularly new, but it's had a bit of a refresh of late. And the intention of this website is to demonstrate websites which are using WordPress, which, I think it's fair to say represent good design. Let's go with that.

So they might not necessarily, be perfectly accessible, but I, just wanna point out at this opening juncture that the intention of this show is not to cherry pick things and, let's say mock them or poke holes in them. The idea is really, we needed a repository where we could reliably find WordPress websites, and the idea would be for Joe to have an opportunity to pick some and then go through areas where they might need help. So this isn't about naming and shaming, or at least I hope that's the intention, Joe?

[00:05:21] Joe Dolson: Oh, absolutely.

[00:05:23] Nathan Wrigley: Yeah.

[00:05:23] Joe Dolson: I think a big thing of what I want to be able to express from this is how common accessibility problems are. Sometimes I worry that people have the general impression that most websites are basically accessible, and if somebody is out picking out accessibility problems, it's something that they've really hunted down and searched out.

And the reality is, 97% of the top million websites have obvious automatically detectable accessibility issues. This is a great study by Web Aim at webaim.org. It is the million website study and they, do an enormous amount of automated testing to look at websites and say, yeah, most websites have lots and lots of problems.

So I just want to be able to look at a few things and say, yeah, this is common. These are not. This isn't something that a developer should be embarrassed about. It's something a developer should look at and say, I have a thing to learn. I could do this better.

[00:06:27] Nathan Wrigley: Yeah, that's perfect. That's a really nice way of framing it. And if you were watching, if you have the ability to watch what we're doing, I have just been scrolling through the video and really you can see that the caliber of websites on this, on this showcase, it's pretty high. There's some fairly heavy hitting names out there, so they've definitely cherry picked some of the bigger players in the WordPress space. It feels like a lot of this is enterprise stuff.

But what's interesting Joe, I think one of the things that we should probably say right at the outset is it definitely feels as if d it's opinionated upon design. A lot of the things in here have really unique design, and maybe that's, maybe that's the criteria. I'm not entirely sure, but it's certainly there's something there. They all look fairly special, fairly unique. They're not made from a cookie cutting template, I don't think.

[00:07:19] Joe Dolson: Yeah, I do think a significant part of what the team that reviews showcase submissions is looking for is unique design ideas, something that's a little out of the box. And, that's definitely what they've got. They're, you're not going to find a lot of, you're not gonna find very many WordPress core themes in here.

[00:07:42] Nathan Wrigley: Let me just have a little quick look here. We have things like category, and flavors and things like that. And then we can sort as of this moment, I could be wrong, but as of this moment, there doesn't appear to be a way to filter based upon accessibility.

You never know. Maybe that's something that's gonna come in the future, but.

[00:08:03] Joe Dolson: It has been talked about.

[00:08:04] Nathan Wrigley: Okay.

[00:08:05] Joe Dolson: There is actually an open GitHub issue about adding that as a criteria and and flagging sites that are accessible. But there's a pretty significant challenge in terms of the amount of time it takes to actually review that. And, the reality is, a full accessibility audit takes hours and hours, and we're not going to do that. There's simply no way it's realistic to put that much time into assessing the accessibility of these submissions.

So that becomes a question of how much time is reasonable to decide that it meets some level accessibility, which is not going to be considered any, like, qualified acceptance criteria for claiming accessibility.

[00:08:50] Nathan Wrigley: Yeah.

[00:08:50] Joe Dolson: So you don't wanna make a legal claim for a website. Hey, this website meets all criteria and they don't. And that's awkward.

[00:08:58] Nathan Wrigley: Yeah. So.

[00:08:59] Joe Dolson: A hard problem.

[00:09:00] Nathan Wrigley: Yeah. I'll, move that website out of the way and just to say this is not therefore a sort of 101 in every single thing that you could possibly think about in terms of accessibility.

What Joe has decided to do is pick one thing. Then show on a few websites using the tools that he's got available to him that one thing, over and over again in ways that it might be implemented on one site or a different site and so on. So without further ado, I'm gonna raise Joe's screen there and we've got one here, on.

So your screen is divided into two parts. We've got the inspector from Chrome on the one side, and we've got the website, which is called noguchi. This is from noguchi.org, noguchi.org. You can find the website there. And what is under the microscope today, Joe? What is the thing that you're gonna look at on everything we touch?

[00:09:55] Joe Dolson: The thing I decided to take a close look at here is mobile menu toggles., Because ultimately the mobile experience is an incredibly prominent thing. It's huge for people with disabilities, because phones are cheaper than computers and the assistive technology and screen readers available on phones is just as good.

So it's a great way to get around a website, but of course that also means that for almost all sites you're dealing with a collapsed mobile menu. And so I picked this because, first of all, it's a really significant issue for websites. Access to the menu is obviously a key thing to be able to get around the website. Even if every single page was perfectly accessible, if you cannot operate the menu, you're basically done.

The other reason I picked it is because literally the first six websites I looked at all had different ways of implementing this button, and they all had some kind of a problem with it.

[00:10:55] Nathan Wrigley: Okay.

[00:10:55] Joe Dolson: So it gives a lot of different things that I can illustrate. They're different, they're not the same problem, and they're interesting. So let's just dive in.

[00:11:06] Nathan Wrigley: Yeah.

[00:11:06] Joe Dolson: So this first one on noguchi.org. First of all, this mobile menu, obviously it has no visible label. So my first question becomes what is in fact the label of this particular control? And so I'm gonna be looking at the inspector, and I usually leave the accessibility attributes open.

And so you can see down here on the bottom that it has an aria label that says open menu mobile. I, that's reasonable. It's a reasonable guess. It is an odd string of text. Really all this needs to say is menu, because what it does and how it behaves is a separate issue, but it is labeled so it has a name. That's great.

However, what I also observe is that it's a link, so it's a link with, just a blank address. It's using the hash for an address. Now what that potentially means is when it's activated, it might move the focus, if they haven't taken control over that, because that hash can, it can be a reference. It's just a blank reference on the page. So it's going to move the focus to somewhere on the page.

And that's because of what links do. Links are fundamentally about moving you to a new location, whereas buttons are about creating actions. This should be a button that would be more expected, more predictable.

The other reason it should be a button is that buttons, have different controls than a link. Buttons open using space bar or enter, and links only work on the enter key. So if somebody is wanting to use a particular pattern, if that's their habit, it might not work.

Now the next thing I would find here, I'm going to tab into this, and so I'm gonna turn on something that will show you what I'm doing. Whoops, that's not the thing I wanted. This is basically just a tracker that keeps track of what key I'm pressing, so that you can tell what I'm doing, even if things aren't visible. So I'm gonna tab in and try and find the button. Right now I'm on something that I can't see, so I don't know what that is.

But, I get to this menu button and it does have a focus and that's useful. So let's open it. So I just tried it with the space bar just to test whether they'd added an event that handled that space bar and it didn't work. It just shifted the focus slightly, so that's annoying. Not great, but it does work with the enter key. Now I can tab forward and see where I am.

Unfortunately now I'm not seeing anything, so I have absolutely no idea where I am on the page. I'm gonna try and escape this menu to see what I'm doing, but escape doesn't close it.

[00:14:02] Nathan Wrigley: So just to be clear, these would be you, are using tab, space, escape these and in your case.

[00:14:10] Joe Dolson: Yeah. This is the experience that.

[00:14:11] Nathan Wrigley: This is the normal, right?

[00:14:12] Joe Dolson: Anybody who's using a keyboard will have, if they're not using a screen reader.

[00:14:16] Nathan Wrigley: Okay.

[00:14:17] Joe Dolson: Now a screen reader is gonna give you a bit more feedback. This is more the experience of somebody who's sighted, and I'm doing that because in all honesty, trying to do an audio recorded event live with a screen reader is challenging.

[00:14:32] Nathan Wrigley: Yeah. Yeah.

[00:14:33] Joe Dolson: And I don't want Nathan to have to spend the next month and a half in editing. So you're gonna get the, keyboard. But this is a real experience when people do navigate using a keyboard from a mobile device. This is a very real thing that most people tend to ignore.

And one of the keys about accessibility is that when somebody says navigating with a keyboard on a mobile device, the people tend to seize on the idea that is a sole way of functioning. And what we're talking about is the kind of mythical keyboard only user. But that's not a real thing. What is real is that people use a wide variety of mixes of interactive methods, and the fact is whatever they are using at any given moment should work.

You shouldn't be obligated to switch from your keyboard to a pointing device because this control only works from a pointing device. Because when you're imagining a user, somebody who has very limited mobility, who's using a breath controlled puff and sip device, the effort to switch between one type of controller and another is extremely high. That barrier is big. They should be able to stay on what they're using as long as they possibly can.

[00:15:59] Nathan Wrigley: Okay.

[00:16:00] Joe Dolson: At any rate, what we've just seen here is that the biggest problem here is that once you've activated this menu, your location is lost. You don't really know where you are, until you finally get to this close button.

But in the meantime, I don't know what I'm doing, and I don't know what will happen. And I just hit enter on something. I don't know what it was and I don't know what it did. So honestly, I have literally no idea what was going on with that menu. It would require a fair amount of effort to explore it and find the real details. Suffice it to say, it's a challenge.

[00:16:41] Nathan Wrigley: Okay. Okay.

[00:16:42] Joe Dolson: So I'm gonna just go ahead and pop open another one.

[00:16:46] Nathan Wrigley: So, again, we're gonna look at another website from the showcase, in this case. By the way, all of the links will be buried in the show notes, which you can find at wpbuild.com. This is quebec.ubisoft.com. That's the URL and, okay, off we go again.

[00:17:04] Joe Dolson: Oh, this is much the same thing. We've got another mobile menu toggle. Again, it has no visible label, so I'm immediately curious whether it has an accessible name. And in this case it does not. In fact, what this is just, it's a div. It has a couple of spans in it that are styled to look like lines. So it's not even using character that could conceivably have some kind of unicode naming. This is, that's pretty much a bad sign. The fact that it's a div and doesn't have any accessible name, it means it basically doesn't exist for most screen reader users, or keyboard users. But let's just see what happens.

I'm gonna go ahead and turn on the pressed key monitor so that my keyboard navigation isn't completely an illusion. Okay. I've gotta focus on the business name and on jobs. And then I have jumped into discover our culture.

So this as, as pretty much I expected from the fact that it was a div without any kind of tab index attribute, I was unable to get to the menu. So in this case, this would be very difficult. I do know that a very experienced screen reader user by navigating, using arrow keys and arrowing through the text, might be able to get to that control and then activate it. But the average user is simply not going to find this.

[00:18:47] Nathan Wrigley: Okay?

[00:18:48] Joe Dolson: And in this case, whether this control loses your focus or not is somewhat irrelevant because you can't get keyboard focused to it in the first place. Therefore, there's no reasonable way you could worry about whether you're going to lose focus. So this is always one of those issues in testing a website where I'm like, because you have this problem, I can't realistically test this other problem. I'm going to warn you about it, but there is no situation in which I can actually trigger it.

Okay. And so I feel like that one, it's pretty much a quick summary of exactly what that is doing. There's not a lot to say. It doesn't work.

[00:19:33] Nathan Wrigley: Okay. That was that was quebec.ubisoft.com. We're now going to design museum, spelled as you'd Imagine, dot dk. Designmuseum.dk. Okay. And remove the inevitable cookie banner. Yeah. here we go. Okay.

[00:19:52] Joe Dolson: So this one, it's the same presentation to start. I. Now we've got three lines. This one's an SVG. Now an SVG is an element that can take a name. This one does not however have one. It would've required a title attribute, a title element that could receive that name in some aria.

So this is at least, it's hypothetically more practical to name this one, with just the element you've got there. However, I see that it looks like they have not. And again, this is a div. So it's going to have an event attached to it. It does not appear to have any keyboard focus, and it does not appear to have any name.

This is a great thing in the inspector. It can give you all of these accessibility properties. So like from the name, it's going to be using the accessibility tree to calculate what the accessible name of it, the element is. It'll even tell you where it's from, but this has no title, no aria label, no aria labeled by, and no contained text.

So effectively it has no name.

[00:21:00] Nathan Wrigley: Okay.

[00:21:01] Joe Dolson: So that's a little frustrating. I'll also note, and I failed to mention this on the previous items, that what this also isn't informing you about is whether or not it's open or closed. So when I open this menu, in theory, the control that you get to should have an aria expanded attribute, that indicates whether or not it's open or closed. Again, since this control can't be reached using the keyboard, it's a little bit irrelevant.

I will quickly test and see whether they've added any kind of handling to be able to get to it. On this case, I'm doubting it because I don't see a tab index attribute, and so it's fairly unlikely. And indeed I see nothing at all happening on this website.

[00:21:46] Nathan Wrigley: No.

[00:21:46] Joe Dolson: There is, I reached the skip to content link. That comes into focus, but unfortunately it does not appear that anything else has a focus state. On this page, though there are clearly things that I can tap to. So that's going to be a pretty frustrating experience for anybody trying to navigate using a keyboard.

I do have two more sites to take a look at.

[00:22:13] Nathan Wrigley: Okie doke.

[00:22:13] Joe Dolson: So let's go ahead and just take a look at those and see what we've got.

[00:22:18] Nathan Wrigley: I'll quickly tell everybody what this one is. I don't know how to pronounce it, but I'm just gonna say tetuhi.art. So it's spelled T-E-T-U-H-I.art, A-R-T. And Oh, interesting.

[00:22:33] Joe Dolson: And that one started off with some fun animation.

[00:22:36] Nathan Wrigley: Yeah.

[00:22:37] Joe Dolson: Which, that might have been fine. I don't at the moment have prefers reduced motion turned on my machine. I turn that off and on pretty regularly 'cause I'm in the process of testing. So I don't know whether that was respecting it.

Animated text can be very strange for a screen reader. I did review a site yesterday that had an animated H1 heading nested in a slider.

[00:23:03] Nathan Wrigley: Okay.

[00:23:04] Joe Dolson: So the main heading of the page changed every few seconds, which I will tell you that the screen reader I was working with found that to be a bit confusing.

[00:23:14] Nathan Wrigley: Yeah, I'll bet. Okay.

[00:23:17] Joe Dolson: But this menu, at least, I'm looking at it and it actually has a visible label, so that's great. That means if you're using like voice command, you're going to activate this by saying something like, click menu. Which is great if it's actually named that, which is something to check.

And in fact, it is not named menu.

[00:23:38] Nathan Wrigley: Oh, okay.

[00:23:39] Joe Dolson: So here's where it gets a little bit interesting. The, so there's a WCAG principle that's called label in name. This does pass that, because the word that's visible is menu and the actual label is coming from this aria label attribute that says, open the menu.

The problem here of course is label in name just means it's present. The way voice command frequently works is it's expecting the visible information to be at the beginning of the accessible name. This is highly variable. Some voice command tools, you have to speak the entire name, so even you may not be able to see it, but you need to use the entire thing. So that can be a little bit frustrating when those don't match.

I would also argue that it's unnecessary. there are other ways of indicating whether or not you're gonna be opening or closing. That's where that aria expanded attribute comes into play. Is that it tells you whether it's open or closed.

So you don't really need to use that in the name. It's just part of the state of that control. What I'm also noticing here is that this is another link element. It's an anchor. This one does not have an href attribute. So that does mean it's not going to trigger a strange shift in the page.

[00:24:59] Nathan Wrigley: Okay.

[00:25:01] Joe Dolson: But it also means that you can't focus it with the keyboard.

[00:25:04] Nathan Wrigley: Okay?

[00:25:04] Joe Dolson: Because the anchor element is not a link. The A element means this is an anchor. If it has an href attribute, that means it's an anchor that points to somewhere and is there for a link. If it does not have an href attribute, it's a target. It's something that a link can point to.

[00:25:21] Nathan Wrigley: Toward. Yeah. Yeah.

[00:25:22] Joe Dolson: And that's usually done using an ID attribute. However, since it doesn't have an href, it actually is something that can't receive keyboard focus. So let's go ahead and turn on pressed keys again and just dive in and see what we can do.

I'm tabbing and I'm tabbing. I'm not seeing any focus. Now, a lack of visible focus doesn't necessarily mean that it's not there. So what I'm gonna do is I'm going to enable its focus state to see whether it has a focus state, and it does not. So in the inspector, what I just did is I selected the interactive element, the anchor, and I forced its focus state. But it didn't change anything. So what I know from that is that in my tabbing, I really truly did not reach this item, which is what I expected. Since it doesn't have a tab index or an attribute.

So you can see that they've clearly made some effort to try and do some accessibility. They have an aria label. They have visible text, and nonetheless, what you've ended up with is a menu toggle that cannot be accessed in any way.

So one more.

[00:26:40] Nathan Wrigley: Okay. Last but by no means, please.

[00:26:42] Joe Dolson: This is the last one.

[00:26:43] Nathan Wrigley: This is fabbricagroup.Fr. So fabbricagroup, group, all as one word dot fr. And we had a fair bit of animation going on there, didn't we? At the the page load.

[00:26:57] Joe Dolson: Yeah. This one was a little bit simpler. It was pretty much all graphic animation and not text. I'd generally be less concerned. It's probably, it's essentially a loading screen. And it was fast enough that it probably doesn't need to be expressed. Of course, I'm on a pretty fast connection.

[00:27:13] Nathan Wrigley: Okay.

[00:27:14] Joe Dolson: So here we go. Once again, no visible label. I will inspect that. Hey, this one's actually a button.

[00:27:24] Nathan Wrigley: Okay.

[00:27:25] Joe Dolson: This one has an aria label that says menu. Great. So that's a wonderful thing. So now I'm expecting this, I'm expecting this to work. I do not see an aria expanded state right now. That's not necessarily evidence that it's not gonna inform you of this. It could be added only when it's active.

[00:27:47] Nathan Wrigley: Okay.

[00:27:48] Joe Dolson: That would be an error, because right now it does not communicate to you whether that it's closed. So aria expanded equals false would tell you this is not currently expanded. So that's, something I'm gambling is likely to end up being a problem. So let's just tab through, see what we're doing here.

That's a little disconcerting. I tabbed to this Instagram link and to the title, and I have skipped, apparently the button. Now I know as a button, it pretty much has to be focusable. So what that probably means is it doesn't have a visible focus state. So I think I'm on it right now. As the thing to the left of the title. I'm correct, I was.

Now the lack of a focus state is going to be a problem, obviously for cited people using a keyboard. It's a little bit frustrating, it's a little unnerving to jump past things and without knowing that you did it.

So let's see what happens now that we're in the menu. I'm still navigating the header stuff, so it's visible though, so that's okay.

[00:28:57] Nathan Wrigley: Yeah, okay.

[00:28:58] Joe Dolson: It's honestly not a problem. But then the next thing, I can see from the monitor of the current link that's down in the bottom left corner.

[00:29:06] Nathan Wrigley: Yeah.

[00:29:07] Joe Dolson: That I am on a link to Montmatre, so I think that I'm in the menu and where I'm supposed to be. And the next one is Ternes. Yeah.

[00:29:17] Nathan Wrigley: Yeah, looks like you are.

[00:29:18] Joe Dolson: So I'm in the menu, but continuing. I don't have a focus state. So there's nothing here to, that helps me easily see where I am. I'm having to use a reference that's really fairly technical and down in the far left corner, particularly for somebody who's low vision.

You usually can't possibly see that piece of information. So this would still be a somewhat frustrating experience. However, it's at least possible. You can get to these things and the information is there. This is going to be a much better experience for somebody who is using a screen reader, because those focus issues won't be relevant. Though they will have a difficult time telling whether the menu's open or closed.

Let's see if it closes with the escape key. It does not. So in order to close out of this, you do have to go backwards and find that close button again. Which since it's not, doesn't have a focus state, it's a little hard to say, Ooh, I just got lost. What I, I guess I just got lost and I'm not sure why that happened.

But Shift tab did not take me through what I expected it to. I'm now wondering whether I was not actually in the menu.

[00:30:31] Nathan Wrigley: Oh.

[00:30:31] Joe Dolson: Circumstantially also the same links that are on the page. It is. Ooh, God, that.

[00:30:37] Nathan Wrigley: Oh goodness. Wow. What happened there?

[00:30:41] Joe Dolson: I did not like that. Anyway, so yeah. In fact, I was not in the menu at all. It's just coincidentally, the content on this page is the same as what would be in the menu. Let's see.

[00:30:53] Nathan Wrigley: Oh, I see. Okay. So there's, yeah. Okay. Okay.

[00:30:56] Joe Dolson: So it seemed like I was, but once I started to navigate around to try and leave the menu and discovered I was not in the right place, I now knew, I'm not actually here. I'm somewhere else on the page.

[00:31:08] Nathan Wrigley: Okay.

[00:31:08] Joe Dolson: So this is a menu that opened, concealed the whole page, but didn't place your focus into the menu itself. What that probably means is that this menu is not in the DOM order, where it appears. The mobile menu is probably tucked at the very end of the document object, and then it just says, made visible.

Whereas the expectation when you toggle something and then tab, is that should be the next object in the document. So it should actually be located right after the control that triggers it, and then that focus happens automatically. There's no concerns. Nothing has to be done.

So anyway, that was an example of just running through five sites. They all have beautiful designs, but they also all have mobile menu controls, and mobile menus that exhibit some fairly significant problems, that are, frankly, quite readily solvable.

[00:32:07] Nathan Wrigley: I think firstly, I've just removed the screen, so it's just me and you again, Joe. That was really interesting.

So firstly, I will put all of the, the links to the Chrome extension that you used and the five websites plus the showcase itself. I'll put those into the show notes so that they're nice and easy to find. I think maybe, I've got an intuition about what we could do on the next one.

[00:32:34] Joe Dolson: Oh, great.

[00:32:34] Nathan Wrigley: Which might be to, might be to demonstrate a fine example of a mobile menu that might be a, a nice light and shade contrast between one and the other.

[00:32:45] Joe Dolson: Yeah. How would do it, right?

[00:32:46] Nathan Wrigley: Yeah, and demonstrate all of the different bits and pieces because we probably spent, what, three minutes unpacking each of those websites and I suspect we could probably spend round spend 20 minutes or so on finding a really nice example of something which captures exactly what we just were trying to see there.

[00:33:03] Joe Dolson: Indeed.

[00:33:04] Nathan Wrigley: And does it in a really nice way. I think that's a wrap for our first one. Hopefully that was useful. Give you some intuition of ways that you can, how to describe it, muck up not correctly configure your mobile menu and some of the pitfalls that you might fall into.

Is there anything else you want to add before I click the stop button, Joe?

[00:33:29] Joe Dolson: I just want to thank people for watching, and I hope that they found that useful.

[00:33:34] Nathan Wrigley: Yeah.

[00:33:34] Joe Dolson: And if you've made those mistakes, it's okay. People make mistakes and that's how we learn.

[00:33:42] Nathan Wrigley: Where can we reach out to you, Joe, if people wanna actually communicate directly with you?

[00:33:46] Joe Dolson: You can find me on the WordPress Slack at, Joe Dolson. You can find me on Twitter slash X as Joe Dolson. You can find me on Mastodon. My handle is Joe Dolson.

[00:34:02] Nathan Wrigley: Yeah, but which ininstance?

[00:34:04] Joe Dolson: But in general, Joe Dolson, no spaces all lowercase is my username on pretty much everything and that's where you can find me.

[00:34:14] Nathan Wrigley: My little trick when I'm using things like Google is to write the name of the person and then add a space and then just type WP and it always seems to then isolate it to the correct, in this case, Joe Dolson. So that would be my trick.

Honestly, that.

[00:34:27] Joe Dolson: There are not a lot of Joe Dawsons.

[00:34:28] Nathan Wrigley: No. Okay. Yeah, I'm, in that lucky band as well. There's very few Nathan Wrigleys as well. Joe, thank you for sharing your insights today and, hopefully we'll catch up with you on another episode in the near future where we'll, where we'll rectify it and discuss the ways that maybe it could be done, air quotes better. Thank you so much, Joe.

[00:34:47] Joe Dolson: Alrighty. Thank you.

Support WP Builds

We put out this content as often as we can, and we hope that you like! If you do and feel like keeping the WP Builds podcast going then...

Donate to WP Builds

Thank you!

Share this...

Please leave a comment...

Filter Deals

Filter Deals

Category

Category
  • Plugin (13)
  • WordPress (12)
  • Lifetime Deal (10)
  • Admin (3)
  • SaaS (3)
  • eCommerce (2)
  • Maintenance (2)
  • Training (1)

% discounted

% discounted

Filter Deals

Filter Deals

Category

Category
  • WordPress (44)
  • Plugin (43)
  • Admin (30)
  • Content (20)
  • Design (12)
  • Blocks (6)
  • Maintenance (6)
  • Lifetime Deal (5)
  • Security (5)
  • Theme (5)
  • Hosting (4)
  • WooCommerce (4)
  • SaaS app (2)
  • Not WordPress (1)
  • Training (1)

% discounted

% discounted

SUBSCRIBE TO OUR

NEWSLETTER

WP Builds WordPress Podcast

THANKS.

PLEASE CHECK YOUR EMAIL TO CONFIRM YOUR SUBSCRIPTION.

WP Builds WordPress Podcast