Transcript
Show and hide the transcript
The Accessibility Show #5 – Can A.I. create an accessible site?
[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.
Hello there and welcome to The Accessibility Show with Joe Dolson who’s just there. Hello, Joe. How are you doing?
[00:01:38] Joe Dolson: Well, I’m doing really well. I’m really glad to be here again.
[00:01:41] Nathan Wrigley: I really appreciate it. We’ve done four shows in the past, and today we’re having a bit of a departure on our fifth show because today we’re gonna be looking at something entirely different.
In the past, we have looked at websites that have been, around on the internet for a variety of reasons, and Joe has had a good look at those and decided what he’s, what he’s able to decide in terms of accessibility. But today we’ve we’ve decided to look at an AI generated site, which is curious and, so I’m really excited to see what this delivers for us.
I’ll just do a bit of context first, if you don’t mind Joe, do you mind?
[00:02:16] Joe Dolson: Absolutely. Go ahead.
[00:02:17] Nathan Wrigley: Lay the groundwork. Yeah, that’s perfect. So a little while ago, a friend of ours, somebody in the WordPress space who’s been making lots and lots of video content. His name is Jamie Marsland, and he is in fact the head of WordPress YouTube.
He’s an Automattician, and he has been experimenting a lot with AI, and building websites with AI and trying to, trying to do different things just by, I think they call it vibe coding these days. I think that’s the way it’s described.
And on the 8th of March, he released a blog post entitled, How I Built a Freaking Awesome Website with WordPress and Lovable.dev. So Lovable is a third party SaaS platform. And in that post he describes in words, but also in video format, how he built a website. So maybe we’ll provide the links to that in the show notes. So you can just click on that and get to that blog post. But you’ll also be able to find the website itself, which is currently online.
It’s at jamiemarsland.com. I won’t spell that, but it’s how you’d imagine it would be spelled. And that is the location of the website in question. So I reached out to Jamie and said, I do this show with Joe, and Joe likes to look at websites from an accessibility point of view. Can we, can we poke around and have a look in there?
And he said, yeah, go for it. That’s absolutely fine. And so that’s the enterprise today. Sorry that was very wordy, but that’s the idea.
[00:03:44] Joe Dolson: Alright. I had to give some background.
[00:03:46] Nathan Wrigley: Yeah, indeed. Joe as always is gonna have a little bit of a poke around, and we will share the screen right away and so Joe can show you what it all looks like. So there we are. There’s Jamie’s website.
[00:04:01] Joe Dolson: So to start off, one of the most intriguing things to me about this was, in reading that post, he specifically called out that he instructed the AI to make an accessible site, which is, great. It’s nice to think about that and make that request. I would be very intrigued to see what ended up happening if he didn’t make that request.
Obviously as a developer of accessible websites, I have this expectation that, of course they should all be accessible, that’s the default. But I know AI follows your instructions and what, how do they interpret a lack of instruction? I have some thoughts about that, but first, I’m gonna actually take a look at this.
Now this is different from what we’ve usually been doing because this is a, a whole website, rather than just looking at one particular feature. So I just decided to do a very base level auditing process.
And the first thing I’m doing is just a little bit of tabbing through the page. So I’m gonna start, start using the tab key and see where I go.
Now it’s interesting. You can see a very clear focus as it navigates from item to item, and it changes the image as well, which is interesting. But what you, if you watch closely, what you’ll also notice is that I have to hit tab twice to get to that next item. That was a little bit suspicious to me.
That was oh, what’s going on there? So I took a look and if we go into our inspector and take a look at this. Here’s the link, which has been styled to be a full height, and it’s huge and very easily clicked. But suspiciously, it is inside an article that has a tab index of zero, which makes it keyboard focusable, and the role of a button, and an aria label that gives it the name photos, my favorites. Which is a duplicate of the text of that link, which contains the text, photos, my favorites.
Now from a screen reader standpoint, this is potentially very confusing. First of all, it’s not an article anymore. An article has a very specific semantic meaning. It probably should never have been an article, because this is just a link. It doesn’t make any sense to consider it as an article, which represents usually a substantial block of content. It’s now a button, however, so it’s not gonna report that semantics to anybody. It is not an article. It will show up. It’ll say I’m a button, and that I’m labeled photos, my favorites.
Now, unfortunately, there are no events attached to this. So if you tab to it.
I’m now on the button, I hit enter, it doesn’t do anything. I hit space, it doesn’t do anything. That’s because it’s a button in terms of its semantics, but it is in no way a button in terms of behavior, function. It has no keyboard events attached to it. It does nothing. Of course you can still get to the link ’cause you hit tab again and now you’ve gotten to the link, which behaves normally.
There is some kind of interesting edge cases that can occur, if you’ve got an interactive element nested inside another interactive element. I don’t think they would apply in this case because it’s not a real button, but if you had link nested inside a button, some older A.T. Assistive Technology, will occasionally create an infinite loop, where basically you tab into the link inside the button, and then you tab back outside to the link to the button, then back inside to the link, then back outside to the button. Which can be a bit gnarly. And also depending on if there’s event bubbling going on, you can get weird things that happen because the link triggers the event on the button.
But none of that’s gonna happen here because A, there are no events on the button, and B, it is not a button, it is an article that’s claiming to be a button. It’s wearing a very nice halloween costume, but doing nothing.
[00:08:39] Nathan Wrigley: Nicely put.
[00:08:43] Joe Dolson: But it’s still claiming that it’s a button, and it has a label. So this is gonna be duplicate. It’s gonna be an extra tab stop. It’s gonna claim it does something but not do it. It’s going to be duplicate text of the next text and the link. Honestly, that navigation is going to be a real pain. It’s gonna be confusing, and just not really ideal.
It’s an interesting example of something where there’s a lot that’s been put into accessibility, ’cause it’s using semantic elements, an article but wrong. It’s using semantic roles by declaring that it’s a role equals a button. Which is also not a very good idea, you should just use a button. If you wanna button. It’s got the aria label, which is an accessibility feature, but it’s a duplicate text. So altogether, it’s done a lot of stuff. It’s not benefiting anybody by doing that. So that was less than great.
Now, also in that keyboard focus, you note like there’s some, there’s a decent amount of focus. You can clearly see the focus position. On the main title logo text it’s, I don’t know what’s going on there. That looks pretty weird. There’s gonna be some kind of funny CSS that’s making it look that strange. I didn’t investigate it further, but it’s weird.
So I just wanted to, look at the menu, see how that works. If it actually opens properly. It opens. Focus stays where you are, so you can close it again right away if you want. That’s dandy. Hitting tab, that’s a little bit weird. It goes to the dark mode switcher, rather than going directly into the menu. So it’s basically, you’re still in the thing that you’re in. It’s not a big deal. It would work. So you can do that.
And if you just keep going, you just navigate right out of it. That’s not a problem because this has not actually covered any content. It’s just pushed the content over. Which looks a little bit strange here on a wider monitor, it would probably be better.
What I don’t like is that you can’t close this by using the escape key. I would really like to be able to hit escape and then just close the menu, and be able to continue on with the menu out of the way, ’cause as it is, I have to navigate to something and then now I can actually move forward. Which is just normal page navigation, but I’d like to be able to close the menu with the escape key, I think that would be helpful.
So now I’m just gonna go to an example page. We’ll just go to the journal, pretty routine thing. I’m just gonna try to navigate through this. It looks like it’s just a link, a list of links. They might be posts. They might just be images, I don’t know. I do know I looked in advance. So I just navigate through it. But, here we’re seeing, I get to the dark mode. I get to previous month. I hit tab again. And if you note, I’m now in the browser chrome.
[00:11:53] Nathan Wrigley: You are.
[00:11:55] Joe Dolson: I did not get to any of these. They’re clearly clickable according to what the cursor does. And I can click on them, and it looks like they are in fact an image, they’re opening a light box. But they were not keyboard navigable at all. And so we look at what these are, and what we’ve got is, it’s an H3 heading. It’s text. It’s a div. There’s another div. It contains an image. There’s nothing interactive here. So as far as that’s concerned, this is just an image. The event is as it happens attached to, I think it’s actually attached to the wrapping div. I don’t remember, and I’m not gonna inspect that right now, but.
That’s now, there’s no content to this light box other than what we see on the page. Just, it’s just the same thing. It’s the same text. The same date. The same image. It’s just bigger. So for a screen reader, there isn’t really anything that needs to be interacted with here, and their impression of this is going to be roughly equal. Except their screen reader will probably notify them that this is clickable. They just won’t. It won’t be of any use to them.
[00:13:12] Nathan Wrigley: Got it.
[00:13:13] Joe Dolson: However, for a sighted person using a keyboard to navigate around this, particularly if you say they’re low vision, and would really like to see the whole image and see it better, that’s not usable. A keyboard navigator who is sighted will not be able to get any more information, will not be able to see this image better, will not be able to click on anything. So that’s a bit dissatisfying.
The light box itself, obviously the way of triggering it isn’t accessible. But it’s also an irony is that it is actually fairly accessible to close it. So if you could get into it, you would then potentially be able to close it.
[00:13:58] Nathan Wrigley: Oh, gosh yeah.
[00:13:58] Joe Dolson: It does have an actual button to close it. So that’s just an inconsistency that I think the AI needed some QA to push back and say, hey, we need more consistency here.
I will note that this is, there’s no real benefit to this text here. It’s the same text. There’s no alt attribute on these images. There’s no description. There’s nothing extra there. I don’t actually think that’s the AI, because from what I read in Jamie’s post, this data is being pulled from custom post types.
I didn’t watch the video, I’ll confess. So I don’t know whether he used AI to auto generate that data, or whether this is just data he loaded in, and then used the AI to format it. So I don’t want to make any attributions to the AI about those image descriptions. But most of the content of this website is images. They would really benefit from some descriptive information. Right now there’s nothing here for somebody who’s blind, because it’s just a bunch of images with no additional information.
[00:15:20] Nathan Wrigley: Okay.
[00:15:21] Joe Dolson: So that’s not great. Additionally, these images, this looks a lot like a kind of a standard semantic layout, a fig caption with a caption, so that this information is semantically associated with the image that you’re seeing.
It’s not. It’s just, it’s an h3 heading, which is somewhat nice. You can navigate through the headings and see what’s on the page, but since there’s no additional information to find, I’m not sure how useful that is. But really this layout should be a figure. It should be using an image inside the figure, and then a fig caption so that information is all semantically associated with each other. And that would just make it more useful.
Now after having looked at some of this content, trying to navigate through things, I decided I’d take a look at the HTML structure of the page. So we need to look at some kinda larger things here. Oops. I keep trying to click on the video feed. I’m like watching the video feed, and then I try and click on it and ugh, apparently I’m an idiot.
Alright, so we have landmarks here. I’m gonna shrink this down a bit so that we don’t, we have a little more space. Now, they’re a little weird. Now, I look at this left area, for example, this is labeled as complimentary. That means it’s an aside. I’m not really clear why we have an aside for the menu. That really should be a navigation. It could conceivably be a header. A header that contains navigation. But it shouldn’t be an aside. That’s just a misunderstanding of what aside means, because it’s basically, I think it’s assigned it to an aside because it’s on the side.
[00:17:22] Nathan Wrigley: Interesting.
[00:17:23] Joe Dolson: And say, oh, and a side is a sidebar. So sidebar is locational. But this is structural. It’s functional, so it actually needs to serve a purpose.
And then up here we’ve got, what is that? It’s partially hidden. It’s a, oh, it’s a role of region that says it contains notifications. Presumably that’s being used as a feeder location. It’s intended as a feeder location for aria live notifications. I don’t know what there would be in this website. I didn’t observe anything that I would expect an aria live notification from, so.
[00:18:12] Nathan Wrigley: Maybe Jamie has plans.
[00:18:14] Joe Dolson: Yeah, big plans. We’ll go with that. Then there’s this main. What I do note is I do not see a header region. Now a header is normally that would be the place where your logo goes, and then your navigation might get tucked inside it.
I would expect something like this dark mode toggle to be maybe in the header. It could be in the navigation though it’s not technically navigation, so it makes sense for it to be in the header. But there is no header. So where exactly is thai. Because I see a header there. Yeah, there’s one in the code.
[00:18:58] Nathan Wrigley: Yeah.
[00:18:59] Joe Dolson: It’s marked as hidden here, so it’s got display none.
[00:19:06] Nathan Wrigley: Yeah.
[00:19:06] Joe Dolson: If I show it, you can see it’s got very similar information. What’s in the sidebar? It’s got another menu trigger. It’s got another copy of the logo text. I’m betting that’s for mobile purposes. Yeah, but the thing is, it should be the same content. It should be the same structure for both mobile and live. That header should be the same thing, just being moved around visually. So that to me is a pretty significant misunderstanding of how things should go together.
And then we pop open this navigation here, and I will run the landmarks again. And now we see that the navigation is in a navigation landmark.
[00:19:50] Nathan Wrigley: Nice.
[00:19:51] Joe Dolson: That sounds great.
[00:19:52] Nathan Wrigley: It does. Yeah.
[00:19:54] Joe Dolson: It’s not.
[00:19:54] Nathan Wrigley: Oh.
[00:19:55] Joe Dolson: So the reason it’s not is because this navigation region, when you hide the menu is marked as aria hidden. So you can see that here. It says right here, aria hidden equals true.
[00:20:14] Nathan Wrigley: Yep.
[00:20:15] Joe Dolson: What that means is when the navigation region is not visible, it doesn’t exist to a screen reader.
[00:20:25] Nathan Wrigley: Got it.
[00:20:25] Joe Dolson: If you’re trying to navigate your landmark regions, you won’t find a navigation region because it is not in fact available. It’s hidden. And when you do find it, by opening the menu, well you already know it’s there, it is the next thing you’re going to find. You don’t really need landmarks to navigate to find something that you’ve just opened.
[00:20:49] Nathan Wrigley: I understand, yeah.
[00:20:50] Joe Dolson: That toggle has informed you. So that essentially it’s a useful structural thing, but the point of a landmark region is to help you locate a section of a page. If you can only locate that page once you’ve already manually opened it and gone inside it, what’s the point? It doesn’t help anything. And of course, the menu toggle itself should be inside that navigation region.
And then the other thing on the, structural navigation of this is just that, on most pages, if not all pages, the heading structure, jumps from h1 to H h3.
[00:21:31] Nathan Wrigley: Okay?
[00:21:32] Joe Dolson: That’s not like the worst problem ever. It just. But it’s also something that is something I feel like AI should be able to figure out is just, an h1 should then be followed by an h2.
[00:21:47] Nathan Wrigley: Right.
[00:21:48] Joe Dolson: So got an h1 and then add another heading, it should be an h2. That’s just the way it works. So that’s just a more of an annoyance than anything else.
And then I took a look at the images and I guess I got out of order when I talked about that. But as I said, the images here are clearly the primary content. There’s just no question about that. They are on pretty much every page the information that’s being shared. They have an alt text. It contains exactly the same information as in the heading. It doesn’t serve any purpose. And just to illustrate, ’cause of the, I’ve only looked at this one page so far. If you go to this page, it’s also images. If we go to photos, surprisingly enough, yeah. Paintings are images, travels. This one actually is a little bit unique.
This is a map. This is somewhat accessible. It does actually get keyboard focus, and you can open things, like a popup tool tip kind of thing. It doesn’t however read that information right away, and it’s not in the DOM in a super obvious location. So it’s gonna be a little bit unpredictable. But it should work. You can see that the button and it imports this to be right underneath the button. I would expect that users will be able to get that information reasonably well.
[00:23:33] Nathan Wrigley: Okay.
[00:23:35] Joe Dolson: It’s okay. And then also we’ve got these navigation elements. We’ve got this nav region here, as we already talked about, its label is main navigation. That’s a really common thing.
[00:23:52] Nathan Wrigley: Yeah. Yeah.
[00:23:55] Joe Dolson: It really should just be main, because it is a navigation region and will be announced as such. So when.
[00:24:01] Nathan Wrigley: So what would it come out as? Main navigation navigation?
[00:24:04] Joe Dolson: Yeah, pretty much.
[00:24:05] Nathan Wrigley: Okay.
[00:24:06] Joe Dolson: Okay, that’s just unhelpful. And then we’ve got this toggle for opening and closing. That this has a minor annoyance to me, is that it’s got this aria label which changes. So it’s open menu when it’s closed, and it’s closed menu when it’s opened. Now this yields confusion for one thing, because when it’s open, you get to a button that says aria expanded equals true. So it reports as expanded, and clsed menu. And then when it’s closed, it reports as closed, open menu.
[00:24:53] Nathan Wrigley: Got it. Okay.
[00:24:53] Joe Dolson: It’s clear enough, you can figure it out. It’s not unpredictable. The thing that gets difficult is that there are some significant unpredictabilities about whether or not a change in accessible name will be reported to the accessibility APIs that communicate this information to a screen reader if they’re changed dynamically. It’s always better to just have it be labeled menu, and allow aria expanded to control reporting its current state, because that’s just gonna be more reliable.
Additionally, if somebody is trying to use voice command with this control, it’s clearly visibly labeled as menu, which is great. I love that. However, the actual text to trigger it will either be open menu or close menu, and that will change depending on state. It’s not visibly obvious what that might be. It’s gonna get a little bit fussy trying to get that to be triggered.
And then the last thing I wanted to just call out is if you just look at the pages that have text, that text is really, really obviously below color contrast guidelines. It is the kind of classic mid gray text on a black background, which is largely unreadable.
[00:26:30] Nathan Wrigley: Right.
[00:26:32] Joe Dolson: So that’s just something that should be a fairly obvious thing. If you go into light mode, then that contrast is fine.
[00:26:39] Nathan Wrigley: Yeah, it’s the same text color I’m imagining on a different background.
[00:26:43] Joe Dolson: Very possibly, yeah. Yeah. It’s just not a fully consistent switch between dark and light mode.
[00:26:47] Nathan Wrigley: Yep.
[00:26:49] Joe Dolson: And so that’s the stuff that I noticed in looking over it. And I don’t know. It was interesting.
[00:26:57] Nathan Wrigley: Yeah, it’s interesting from the perspective of somebody that obviously doesn’t have the depth of knowledge that you have. It’s interesting how the AI has definitely got cues into these kind of things. It clearly has an interpretation that these things, like the, closed and open menu buttons, and the aria labels being identified as such. But it hasn’t quite got the background there. And I guess why would it, the corpus of information out there on the internet is, as we’ve seen in the other videos that you and I have made, there’s a heck of a lot going on which doesn’t adhere to the standards that you would expect.
[00:27:35] Joe Dolson: I think that’s what’s really interesting about this. Using AI to do this kind of stuff and telling it to be accessible, is it is basically doing it the same way a human does. If anything my biggest criticism of a lot of AI stuff is it is, it is too human. It’s just a really, really fast human. It’s not however really, really skilled human. Or a human who’s really good at discerning good information from bad information.
So like tons of these mistakes are mistakes I have absolutely seen on other sites. The misuse of semantics. The link nested inside a button. The duplicate aria label to link text. Like these are all, nothing’s new about that. It’s just.
[00:28:30] Nathan Wrigley: The AI did it quicker.
[00:28:33] Joe Dolson: Yep.
[00:28:34] Nathan Wrigley: Yeah. And it, I guess that’s one of the things that Jamie touts in the videos is the speed at which things can be done. And maybe that’s the beguiling thing about AI at present, is that. It’s just it speeds up things.
I think Jamie also leans into how it comes up with layouts that we’ve seen, that he likes the look of, and the design aspects he likes the look of.
[00:28:59] Joe Dolson: Yeah.
[00:28:59] Nathan Wrigley: But as you’ve said it’s got certain faults that from an accessibility point of view need looking at. But it does it in a heartbeat.
[00:29:06] Joe Dolson: Interesting thing. But yeah, and I would actually say that this isn’t horrific. This isn’t unsolvable. I feel like I have absolutely seen worse accessibility than this. And not having looked at the backend code, or I guess this is largely built in front end, this is headless, but I haven’t looked at the code, so I don’t know how easy it would be to fix or replace anything. I don’t know how clean the code is or how nice it is. But none of these are like unfixable.
[00:29:47] Nathan Wrigley: I’m curious. I’m gonna send this video to Jamie, and. I am curious to see if he thinks that he can rectify the problems. Let’s say given the transcript of this, this show that we’re doing now, if I give him the show plus the transcript, I’d be curious if that can in any way be leveraged. Or if him merely taking more prompts into the AI and saying, okay, on this portion of the website, we would now like it to go like this. And obviously you’ve supplied that information.
[00:30:22] Joe Dolson: Interesting. Yeah.
[00:30:23] Nathan Wrigley: It’d be interesting to see if it can overcome the problems that it has itself created. That would be fascinating.
[00:30:28] Joe Dolson: Yeah, that would be interesting. Yeah, and I don’t know.
[00:30:31] Nathan Wrigley: I will get in touch and.
[00:30:32] Joe Dolson: But I do think just in general, it’s intriguing to see that when told to make something accessible, it makes a lot of the same mistakes that I’ve seen early, people early in the accessibility stage of their career make, in terms of not fully understanding how aria works, and not fully embracing the details of semantics.
[00:31:04] Nathan Wrigley: Yeah.
[00:31:04] Joe Dolson: But it has done a lot of the super structure is okay. It’s got structure, which is something. It’s got keyboard focus. It’s got interactivity most of the time. It’s just not totally complete.
[00:31:20] Nathan Wrigley: Yeah, it’s interesting. Okay, I guess we’re gonna pin this one and say, Jamie, over to you. Let’s see.
[00:31:27] Joe Dolson: Let’s see what, happens next.
[00:31:28] Nathan Wrigley: That’s right. Yeah, this could be A series which never ends. It’s just a ping pong between Jamie and us. But let’s see if anything.
[00:31:36] Joe Dolson: That sounds boring to be honest.
[00:31:37] Nathan Wrigley: Yeah. Yeah.
[00:31:38] Joe Dolson: Really too much.
[00:31:39] Nathan Wrigley: Let’s not do that. So we’ll return to normal service on the next one, and probably looking at a website and taking it apart on one feature at a time, which is what we usually do. Yeah, but.
[00:31:50] Joe Dolson: Like usual.
[00:31:50] Nathan Wrigley: Joe, thank you so much for that.
[00:31:52] Joe Dolson: Absolutely.
Let’s, let’s see where we go here. I appreciate it. Alright, thanks very much.
Episode description
Welcome back to another episode of The Accessibility Show, where we dig into the world of web accessibility.
I’m joined, as always, by accessibility expert Joe Dolson, to tackle a thought-provoking question: Can AI create an accessible website?
In this episode we explore a website crafted by Jamie Marsland, a key figure in the WordPress community. Jamie has been experimenting with AI to rapidly build websites, and in his latest project, he tasked the AI with creating an accessible site. Nathan and Joe take a detailed look at this AI-generated site, evaluating its accessibility features, identifying strengths, and pointing out areas needing improvement.
Throughout the episode, Joe shares his expert insights, examining how AI handled tasks like semantic structuring, keyboard navigation, and proper use of ARIA labels. He uncovers some of the nuances and common pitfalls AI encounters in accessibility, offering some lessons for developers and designers alike.
Whether you’re deeply embedded in the world of web development or simply curious about how AI is reshaping traditional practices, today’s episode offers a wealth of knowledge.
Key topics and bullets
Welcome and Overview
- Nathan Wrigley welcomes Joe Dolson to the show.
- Discussion about this episode being a departure from previous ones.
AI-Generated Websites Overview
- Explanation of the episode’s focus on an AI-generated site.
- Introduction of Jamie Marsland’s work with AI in web development.
AI and Accessibility Introduction
- Joe Dolson discusses the implications of creating an AI-generated accessible site.
- Questions raised about the default accessibility of AI-generated content.
Website Inspection and Initial Findings
- Joe begins by inspecting the AI-generated website starting with the tab navigation.
- Observations on the keyboard focus and functionality, or lack thereof, on certain site elements.
Detailed Analysis of Website Structure
- Joe dives into the specifics of the site’s HTML and CSS.
- Discussion on semantic misuse and the implications for accessibility.
- Interactive Elements:
- Issues with nested interactive elements like links inside articles falsely labeled as buttons.
- Navigation Functionality:
- Problems with the navigation menu in relation to keyboard accessibility and aria standards.
- Interactive Elements:
Examination of Site’s Content
- Joe examines image use and associated challenges for screen readers.
- Remarks on image descriptions and their importance for accessibility.
Structural and Semantic Observations
- Joe notes inconsistencies in the site’s use of semantic elements like headers and asides.
- Highlights issues with landmark regions when handling mobile vs. desktop versions.
Specific Accessibility Concerns
- Joe identifies specific concerns related to text contrast and readability.
- Discussion around how AI might improve these elements with better data or instructions.
Final Thoughts and Suggestions
- Reflections on the AI’s performance and suggestions for improvements.
- Proposal for Jamie to address and possibly rectify identified issues using AI prompts or manual adjustments.
Notes from Joe about the site
- Jamie specifically instructed the AI tool to make an accessible site.
- Let’s see how it did!
- Keyboard navigation
- Observe two tab stops on each main link.
- Each link is an article element that’s been given the role of button, a tabindex of 0, and an aria-label with the contained text, then also has a link nested inside it.
- The button doesn’t do anything; navigating with the keyboard, only the second tab stop is active.
- Main navigation seems to work pretty well from the keyboard, although the menu can’t be closed with esc
- Navigate to Journal; attempt to tab through items. Photo Journal items are not accessible via tab.
- Each image has an event attached directly to the image that opens the lightbox. (no link or button)
- Captions are not semantically associated with images.
- Observe two tab stops on each main link.
- HTML Structure
- The left sidebar navigation is in an aside element.
- The header is hidden; I wasn’t able to find a way to make it visible.
- The navigation menu itself is inside a nav element.
- The entire navigation region is hidden using aria-hidden when concealed; this means that the landmark regions on the page aren’t consistent. The purpose of a landmark region is to locate a section of a page more easily; if it’s only made present when you’re already inside it, that’s pointless.
- Heading structures skip h2. A relatively minor issue, but should be easily resolved automatically.
- Accessible naming
- Images are the primary content; none of them have sufficient alt text. (That may not be the AI’s fault.)
- Navigation regions are labeled as “Sidebar navigation” and “Main navigation” (redundancy.)
- Menu toggle is named “Open Menu” and changes to “Close Menu” when expanded. This will work, but will cause problems for voice command users.
- Color Contrast
- Body text is at 3.48:1, which clearly fails. https://jamiemarsland.com/iphone-sketches
Timestamped overview
[00:00] AI-Generated Website Review Debut
[04:01] AI and Website Accessibility Concerns
[07:32] “Interactive Elements Accessibility Issues”
[10:38] Menu Navigation Improvements Needed
[15:21] Improve Semantic Layout
[18:14] Missing Header Observations
[20:50] “Navigation and Structure Issues”
[24:53] Dynamic Accessibility: Managing Menu Labels
[27:35] AI: Human-like but Not Expert
[31:39] Back to Normal Service
Discover more from WP Builds
Subscribe to get the latest posts sent to your email.



