Danish Naseer: Hey everyone, I hope you liked the previous session by Sabrina Zeidan on the State of Web Performance, and I hope you have a lot of takeaways that you can implement in your business. The next session is on accessibility, so the session is how accessibility failures drive down your Core Web Vitals scores, by Amber Hinds. So Amber Hinds is CEO of Equalize Digital and the maker of the Accessibility Checker plugin, and also she is the organizer of the WordPress Accessibility Meetup and a co-lead organizer of the WordPress Accessibility Day conference. So we have Amber Hinds with us, she is giving a talk on accessibility, how it is important for Core Web Vitals. Hey Amber, how are you?

Amber Hinds: I’m doing great, thanks for having me.

Danish Naseer: It is such a pleasure for us to have you on this Cloud Bootcamp. So without further ado, the stage is yours, you can start your presentation, and the viewers are looking for your presentation.

Amber Hinds: All right, sounds great. I am so excited to be here for everyone. I am actually putting a link in the chat, so if you want to view my slides, there are some links on my slides, and you might want to even pull up the PageSpeed Insights report that we’re going to look at and look at it on your own separately. So you can grab that link out of the chat right now.

A quick primer. If you’re not familiar with website accessibility, I’m not going to talk deeply about everything related to accessibility today, we just don’t have time, but from a high level, what is website accessibility? An accessible website is one that can be used by everyone, people of all abilities and disabilities using a variety of devices and assistive technology. I have on the screen a grid of about 20 different people, many of whom have what are physically apparent disabilities, so they might have limb differences, or they might be wearing hearing aids, or appear to be holding a cane because they’re blind. But there’s also some people here that you might look at and not consider them to be disabled, and there are a lot of folks out there that have hidden disabilities that impact their ability to use the web.

And so when we’re talking about building websites and performant websites, of course we’re doing that because we want people to come to the website and be able to take a specific action, whether that is adding a product to the cart and checking out, learning about services and going and submitting an inquiry form, some sort of specific action is required or desired on most websites. And so what we’re talking about doing is building websites that work for as many people as possible, whether they’re accessing it on a computer, on a mobile phone, whether they are using a screen reader or an alternative input device or a refreshable braille display. So that’s high level what we’re talking about when we’re talking about website accessibility.

A question people always ask me is, does accessibility impact search ranking, is this something that will help me bring more people to my website? And there’s kind of some nuance to this discussion. So in 2022, March of 2022, John Mueller, who is a Google Search Advocate who does Google SEO office hours, I have a link to this on the slide if you want to go watch the video, someone asked him this question, I think they specifically asked, if I underline my links, does Google pay more attention to that and will that help my ranking? And he said, accessibility is something that is important for a website, because if you drive your users away with a website that they can’t use, then they’re not going to recommend it to other people, but it’s not something that we would pick up and use as a direct ranking factor when it comes to search, maybe that will change over time.

So if you look at PageSpeed Insights, you know, there’s an accessibility score that comes from Lighthouse. What he had said at that time in 2022, I can’t find anything more recent, so of course this was four years ago so it could have changed, is that they don’t directly use that Lighthouse score to impact their algorithm. But here is something that is important to know, is that as early as March 2008, this is a long time ago now, for some of us we think it’s not that long but it’s quite long ago, Google’s Search Central blog was posting a lot of articles about accessibility and how it can indirectly impact your ranking. So this quote is from T.V. Raman, who’s a research scientist at Google, and he says, in addition to the service you’ll be doing for the visually impaired community, accessible sites are more easily crawled, which is a first step in your site’s ability to appear in search results.

So accessibility, while it may not, who knows, right, directly impact the search algorithm, it does indirectly benefit ranking. Good accessibility aligns with things that Google’s ranking systems reward: semantic HTML, having alternative text on images, using meaningful link text, having proper page titles and heading structure. All of these things help accessibility, and they can benefit your website in a way that makes it easier for Google search bot to crawl, and at this point the AI chatbots to crawl, to understand, discover new content on the website, and then figure out who would be most interested in it and serve it on keywords that you want to serve it on.

If you want to read more about accessibility and SEO, then I have three links on these slides, which again, I shared the link to my slides in the chat, and these are articles that go back as far as 2008: web master tips for creating accessible crawlable sites, design patterns for accessible, crawlable, and indexable content, and creating helpful, reliable, people-first content. All of these talk specifically about or reference accessibility and some of the things I’ve mentioned here.

So of course there’s this whole other side of Google search ranking, which is Core Web Vitals scores, and there are actually a large number of accessibility failures that can drive down Core Web Vitals scores, and of course that is the meat of what we’re going to talk about here today. So I’m actually going to leave my slides for a minute and we’re going to go take a look at an example website. This is not a real website, what it actually is is the demo site for a free WordPress theme that is available on WordPress.org, and I’m a little bit picking on them, I know, but at the same time it is a really great example of a lot of accessibility failures that also can cause issues with PageSpeed Insights.

This is News Magazine X, is I think the theme name, but I have a link to this demo site in my slides, so if you want to go check it out. I’ll highlight a few things here that we’re going to circle back and talk about. But this is a news magazine layout, I can see right up at the top that I have a scrolling animation that’s scrolling probably post headlines across, they are, it does pause when I hover over it, but they are links, so that’s an animation which I can’t stop, which would be an accessibility problem. There’s a lot of different menus, we have a search that kind of opens an expandable, maybe like an accordion, there’s a dark mode toggle included where I can go from light to dark mode. We’ve got some like different sidebar menus that have a lot of content, and not only, for example in this sidebar I’ve expanded it and there’s editor’s pick and I can see four posts, but I can also see that there’s pagination here. Well, it didn’t load anything, but it could load more, so potentially there’s a lot more that they could be loading.

If we scroll down to some different sections, I can see there’s a lot of tabbed examples, so latest news, I can see five posts, all of which have images and some of them have icons as well. I can get gadget posts, health posts, so there’s like different sorts of filtering and queries that can happen on user interaction. We’ve got another popular and featured tab section, there’s some carousels here where we can slide through posts. In our trending now section, there’s embedded videos, maybe this is just a whole YouTube playlist, but again, right, there’s a lot happening on this website.

And so what does this look like when we do a PageSpeed Insights test? This particular test I do have linked as well, you could go run it, but this is from yesterday, and what it got on mobile was 54 for performance, 84 accessibility, 69 best practices, and 85 SEO. What are some of the issues that we see on this site that are causing, specifically we’re going to talk about performance and I’ll circle back on the accessibility, but there’s a lot of render blocking requests that are coming from both JavaScript and CSS, but you can see there’s quite a few different JavaScript, they’re also using jQuery Migrate, you know, because they’re using older versions of jQuery. They have issues related to image delivery, inefficient cache lifetimes, forced reflow, which is when JavaScript queries basically load things and force the DOM state to change, this can also sometimes cause issues for users on Zoom. There’s very large images that are causing LCP, or Largest Contentful Paint, breakdown. There’s request discovery issues. We have, it’s recommending, you know, let’s reduce all this unused JavaScript, so there’s different JavaScript that is happening, like JavaScript loading from those YouTube videos we saw, Swiper JavaScript which is probably coming from the carousel. So there’s a lot of issues coming into this 54 performance on mobile.

So I want to pop back over to my slides for a minute and talk about where this overlap between the issues that we see on performance and these negative Core Web Vitals scores can come in, in combination with accessibility. So these are some common components or patterns that can cause both accessibility and Core Web Vitals problems. So for example, having any sort of fade in or scroll triggered animations, from an accessibility standpoint these can cause motion that triggers vestibular disorders, the content may be hidden from screen readers if it’s implemented improperly, and on the same side they could also be hidden from just a straight-up keyboard user. Or, I know, the fade in animations, I just get so annoyed when I’m on my phone and I’m trying to reach something at the bottom of a website and I scroll, and then I have to pause, wait for the content to fade in so I can see it, and be like, oh, nope, I’m not there yet, scroll some more, right, like, I don’t know why, it’s, I feel like these can be frustrating for all users. And then on the Core Web Vitals front, if you have these kinds of animations, then this can result in delayed rendering and animation scripts that can hurt both your Interaction to Next Paint time and your Largest Contentful Paint.

Another component or pattern that commonly causes problems are carousels or sliders. These can frequently be hard to operate with keyboard, they might be auto-moving and unable to be stopped, which can cause an issue both for screen reader users, if every change causes an interruption on their screen reader of whatever else they’re reading lower down or somewhere else on the page, but they can also cause issues for those people with vestibular disorders or ADD that are like, I’m trying to focus on this and this scrolling thing across the top is very distracting to me. Frequently carousels and sliders have very poorly labeled controls, or maybe they don’t even function at all. And then the things that we see related to Core Web Vitals with these are large images, they often have very heavy JavaScript loads, so both of these can reduce both your LCP and your INP, and they could be render blocking as well.

Scrolling or animated content is very similar. We’ve talked a little bit about this already, but moving content can be distracting, if there’s no pause controls then that can be a significant issue. So the other thing you want to think about from a performance standpoint is that when you have something that is continuously scrolling, that means you have continuous JavaScript execution that is not stopping. Even if someone is sitting on a page and not doing anything with their mouse, they’re not scrolling, maybe they’re just trying to read something but they’re not actually interacting with it, the website is continuously running something. And so that again, when they go to interact with something else, could slow down their interaction on that next thing that they are trying to interact with, because the website was already executing something else somewhere else on the page.

Modals and popups are another thing to watch for. From an accessibility standpoint, these frequently have improper focus management, missing labels, they very frequently have keyboard navigation failures. I’ve seen a ton where the modal opens but the keyboard user is left behind the page, they can’t see where they are, they don’t know how to get into the modal because the modal is usually added in the footer below all the content, so they’d maybe have to tab through all of the things, right? The other thing that can happen, and I see this too with cookie banner modals, if you have late insertion of these modals or popups, then they can cause cumulative layout shifts, so CLS, or interaction delays, INP, so those can impact your Core Web Vitals scores as well. If you have a blocking modal, so for example an alcohol website in the US, we frequently see these where they say, are you 21, right, you have to do this to fill it out, those can actually make it difficult to be able to get a good page speed score at all, because it can maybe only test with that gate on there and it won’t test the whole page, and then you’re like, oh, I have to run Lighthouse myself if I want these scores, right? So those are things to think about.

Improperly coded tabs and accordions. What I see the most on these is they’re missing ARIA roles or keyboard support. If you go back to that example that I had pulled on that fake website, it has a bunch of different tabs in different areas, and if you use just your tab key and you try to move to them, you cannot trigger them, and you cannot change from where we saw like featured and popular featured or popular content, because it literally is not a functional button. So a lot of times those can be an issue, or they might seem like they work with the keyboard but they’re missing the necessary ARIA roles to be able to announce to your screen reader user to know how to use that. And then what we see most frequently on those, because someone is not using native HTML components, instead of using a button to be able to expand the accordion or to be able to switch the tab that’s currently selected, they’re sometimes using divs or spans. Well, now I’m not using native HTML, so what do I have to do, I have to write a bunch of JavaScript that will actually add in the functionality that a native button would have had on its own. So now I’m adding JavaScript implementations that of course can delay interaction, but they can also potentially, depending on how or where you’re loading your JavaScript, if you’re loading it in the header, it could also be render blocking. So it’s one of those things where, because I’m hacking functionality into a div, I am now probably making it less accessible unless I’ve worked very hard to ensure my div actually functions like a button, but I’m also adding all this extra code that I wouldn’t need to do if I had used the native element.

Infinite scroll is another one. Infinite scroll can be very difficult for keyboard and screen reader users, honestly me, to be able to reach the footer. I hate infinite scroll, I don’t know if you want to give like a reaction in the chat, I’m always curious like who else here really hates infinite scroll. When you’re like, I just want to go to the footer to find your contact information or to find your privacy policy, but every time I think I’m about to get to the footer, something jumps up and the footer goes down and I have to, right, like, so frustrating for everyone. Well, this is sort of a similar thing where I’m talking about, continuous loading increases JavaScript work, it delays interactions, it can cause frustration, but it will also impact your performance scores.

Hero or background images. This is so interesting, because a lot of us think like, oh, at the top we’re going to put like a photo that’s really big behind the section and then put some text in front of it in the page title, or maybe halfway down, right? But having those big images, if they are meaningful and they’re important, or heaven forbid, I didn’t list this, but background videos, right, if they’re conveying something important about the website or about the location or the restaurant, let’s say, it’s showing the kind of food you have there, well now that needs to have some sort of alternative for people who can’t see, so they can still access that information. So frequently though that is missing, it’s missing the alternative text that would describe the photo or the video. You can very often get color contrast issues when you’re putting images on the background if you don’t have a sufficient overlay to make sure that the text actually does contrast with lighter colors, for example, in an image, which can make it difficult for everyone to read, even people who don’t identify as disabled. And then of course this is where we see all those images that are not optimized, right, so it can slow loading if they’re very big, you might see that those hero images are what’s being flagged as, this is the largest element on the page, and that can result in negative LCP scores.

Any sort of heavy JavaScript frameworks or page builders, these can frequently result in complex DOM structures that will interfere with assistive technology and just general navigation if you’re not being thoughtful about heading structure as well. And really looking at any of those things and just saying, you know, are these adding a bunch of large scripts that slow rendering and responsiveness? I think some of the more popular page builders are getting a lot better at this, but there are still quite a few out there where regardless of whether you’ve put a carousel on the page, like maybe you didn’t use the carousel block or widget, they’re still loading all of their carousel scripts on every single page. And I’ve seen even worse where there are controls for something that’s in the footer that, as a sighted person, I don’t even know they’re there, but a keyboard user or a screen reader user might interact with them, even though they’re not really supposed to be interactive, they’re not supposed to be there, because the page builder or the JavaScript framework is loading that content anyway. So those are things that can cause concern.

And then of course third-party widgets, chats, ads, embeds. These can frequently have inaccessible controls or keyboard traps, if they’re injected late they can cause cumulative layout shift, or CLS, they can slow interactions. As we saw on that one page, there were YouTube videos that are all loading YouTube scripts, but if nobody hits play on that video, did we ever have to load the YouTube scripts at all, right? Like, perhaps it’s better, and we do see this now where people are putting an image of the video and then when you hit it, it actually loads all of the scripts, and those kinds of things. So that’s kind of a high-level overview of some of these components and patterns that we see that frequently cause both accessibility issues and Core Web Vitals problems.

So what can you do if you want to make sure that you are creating accessible, performant websites? The first thing I would say is, I would ask myself, do I need this JavaScript, do I really need the animation, do I really need this interactive component? I would experiment with clean, polished designs that don’t rely on old techniques. And what do I mean by old techniques? The background image with the parallax where you’ve got a giant photo that of course your client or you are like, I don’t want it to be blurry so it needs to be really big, right, like that is a pattern that’s been around for a very long time, there’s nothing new or special or interesting about it. Honestly, I think a photo background section with some text over it is probably one of the least daring and most boring design patterns I have seen, right? And it’s also something that can negatively impact accessibility and can super negatively impact performance, because you have to load this massive image or massive background video.

So why don’t you think about your pages in a way that, think like, maybe there can be some sort of creative challenge around, we’re not going to have giant images on this page, how can we still design it in a way that looks really nice? And it can be done, right? But this is forcing yourself to get out of that habit of, oh, we put a carousel at the top, we have a grid of three blog posts and then we need to break up the section with an image background, right? Like try and think out of the box, and what can you do that allows you to use more native components, more maybe CSS styles and images, right, or SVGs instead of photos, like those sorts of things.

Along the same lines, make pages more purposeful with straightforward layouts. I want to go back to this site we are looking at here. Like let’s say this was my news website, and it’s so easy to fall into this idea of, we have to get as much content as possible on the homepage, right? We have the scrolling ticker across the top, we have the tab sections under latest news where we can tab content, or we can click a control that fails color contrast and get different content in a query. You know, all of these, this carousel here that’s like trending now, and I don’t even know how many posts loaded here, maybe 10, I’ve seen things where someone’s like, no, we need 20, right, and it’s loading 20 posts, each of which has its own background image and a title and meta and a read more link, all of those things.

So if you have an existing website, probably the number one thing that I would recommend doing is run something like Hotjar or Microsoft Clarity or something where you can watch user interactions on the page. You will be surprised. Like I have seen things like this where everyone’s like, it has to be a carousel and we have to have more than four, and then you watch recordings and no users come and scroll either way. And think about how much you could cut off your DOM size, how much you could cut off your JavaScript by, a, removing the carousel, and b, instead of loading 20 things, now we’ve only loaded four, right? So all of that can dramatically impact your performance, and it can help drive users to a more targeted, curated experience that actually gets them to do more of what you want on the site. So that would be a thing that I would really recommend, is trying to make your pages more purposeful. If you’re afraid to remove something, go watch those user interactions and you might see nobody uses this entire section. I mean, I’ll say that on our website, we’re getting ready to rebuild our website, we have a video testimonial carousel at the bottom of our homepage that’s going away, because a, nobody plays the videos, and b, nobody switches to the second tab. So why do I have a carousel with four videos, right? It’s a win, like, more simple page, get people what they want. Don’t just think more interactive things is better, because it’s not always.

And then of course use proper semantic HTML and native components where possible. You want to get rid of JavaScript, use a button, not a div, you don’t have to make a div behave like a button, right? The more native components you use, then the better it is for accessibility, the better it is for performance. And test early and often, and I know the speaker before me was also talking about this, don’t treat it like the fire at the very end of the project. Both accessibility and performance should be part of your workflow, it’s not a final step before launch.

I have some screenshots up here on the slide of our Accessibility Checker plugin, which there’s a free version on WordPress.org, or you can get it off our website, the free version as well, and it puts reports right in your dashboard. This is actually a screenshot with this theme active, and it has 101 problems, 59 things that need review, only about 80% pass checks because there’s a lot of repeated problems. And then also the open issues show some of the things like empty links and ambiguous anchor text and a lot of those things that all come up on that PageSpeed Insights and impact that score that Google does see, and some of these things do impact your performance.

So I would really figure out how to start testing if you’re not. Test as you build, both with PageSpeed Insights, with whatever other performance tools you’re using, with Accessibility Checker if you have a WordPress website, and then on existing sites, start now. You can use automated tools like this to help you identify, prioritize and roll out fixes over time. Obviously if you’ve got lots of performance problems or lots of accessibility problems, it’s not an overnight fix, but there are pretty major changes that you can make to fix both very quickly. Like for example, if we determine we don’t need a carousel there, removing the carousel and replacing it with a nice four column section would probably significantly improve both accessibility and performance in, I don’t know, maybe 30 minutes of work, maybe an hour if you have to decide how to lay out that section instead of using the carousel, right? So thinking about simplifying, thinking about testing regularly as you go, and it can really make a big difference.

This is my information. I of course am the founder and CEO of Equalize Digital. If you have additional questions, I’m happy to answer them now, if you think of them later, I can be reached at [email protected], or I’m most active on X at heyamberhinds, or LinkedIn, and you can just find me, Amber Hinds, which is spelled h-i-n-d-s, on LinkedIn. What questions can I answer? I’m hoping I have a moderator who’s going to pop in here and be able to ask me some of the questions, because I’m looking. Let me see. Oh, I guess I’m going to do my own.

Danish Naseer: I am here.

Amber Hinds: Oh, perfect. All right, I was like, how do I do this?

Danish Naseer: Yeah. I must say thanks for the session, and it really highlights how improving the accessibility can also lead to better performance and better Core Web Vitals. Amber, I have a question for you, like, as you have experience in working with multiple teams, what is the most common accessibility issue that ends up hurting the performance more than expected, like people expecting this will not hurt the performance as we are expecting, but that issue raises a very big concern for the performance?

Amber Hinds: I mean, I would say the biggest thing is, like I mentioned, not using native components, because what ends up happening is that you have to write a ton of JavaScript to do the interactions that you wouldn’t otherwise have to do. And that is probably the number one thing that has the biggest impact on performance, especially if you’re not loading that JavaScript in the footer and you’re loading it as a render blocking element. You know, so like I mentioned, trying to turn a div into a button, you can do it, but I don’t know why you would, it’s a lot of extra work and it’s not super great for your website or for your users.

Danish Naseer: Making sense. So we have multiple questions on the Q&A session, I would like to bring some of the questions on the screen. There is a question from Ham, he’s asking, how can inclusive design practices reduce layout instability and improve the CLS?

Amber Hinds: Yeah, so I think one of the things that I really like to emphasize, and I talked about this a little bit, is thinking outside of the background image box. So a lot of times, I mean, it’s still so common that we see the hero section of the website at the top has to have a big giant image behind the text, and this can cause a number of problems, and depending on how the image is loaded, if it’s pre-loaded or not, if it has, if it’s as a background, then it might not be as big of a deal, but sometimes I’ve seen where it’s an actual image in the page and then it comes in and it makes other things shift down when it does load. But then that can cause like a lot of issues with regards to readability on the text and things, and so we’re frequently thinking, how can we make this as readable as possible? So we’ll say, okay, we’re not going to put images behind text ever, we’re going to come up with some sort of design that allows us to have the image to the side, or above or below, or maybe even on some websites, you don’t need to have 50 images. I don’t know how many images were on that page, right, that we just looked at, every single article has an image, but on a news site, do you, those images are usually just stock photos, they’re not always actually super beneficial. And maybe there are ways that you can design your news site without having a stock photo for every single article on the homepage, and it can still look very nice and clean and that sort of thing.

I think sometimes, again with the JavaScript, depending upon how things load in carousels in particular, so I always advise, if you cannot have a carousel on a website, it’s great. Carousels can be accessible, but it’s a lot of work to make a carousel accessible, and if you’re trying to keep budgets down or make it faster to build out a site, then maybe you don’t want to have to spend a bunch of time building an accessible carousel. And for users, it’s often a much better experience not to have to like click through things, and there are other ways to display multiple items without carousels. And so I think that’s another one where, depending upon how it loads in, it could definitely shift things around, especially if it’s below the fold and you have lazy loading. Lazy loading is awesome, but sometimes the lazy loading will make stuff jump.

Danish Naseer: Awesome. We have another question by Yeshu, and she’s asking, like, in your experience, what is the biggest challenge companies face when trying to implement accessibility standards on their websites, and how can developers overcome it effectively?

Amber Hinds: I think the biggest challenge that most companies face is that they just don’t know how to do accessibility. There’s a lot of boot camps out there that don’t talk about or teach accessibility, and even now with all of the AI code, a lot of the AI code is trained on existing code, and more than 90% of websites have accessibility failures. And there are tons and tons and tons of amazing tutorials which can teach you things but haven’t considered accessibility. So people who are using AI to code, or who are just reading tutorials, may not know how. So what I would say is probably most important for being able to overcome these accessibility challenges is training and education. I think companies need to make sure that they build time in for their developers to be doing, you know, being here at a conference like this, learning, or going to like the WordPress Accessibility Meetup that I run, or watching talks over time, attending those sorts of things are really helpful, I think. And then just get started. I think sometimes people feel a little bit overwhelmed by accessibility, or are worried, you know, it’s going to be this huge thing or a giant investment, and it can be, but it doesn’t have to be. You can, you know, use like our free plugin and find, it might show you a lot of problems, but like I said, it’s not overnight. So you pick one thing, do some research, learn how to fix it, fix it, and then moving forward you do it right, right, and then you can upskill yourself and your company in that way.

Danish Naseer: Awesome. Thank you so much, Amber. There are multiple questions already in the Q&A session, and I would request you to be active in the Q&A session to answer those questions. We are on time, and I hope the viewers learned a lot of things from you on the accessibility side. The upcoming session is an activity on unscramble the speed words. It is your chance to participate in the activities and win big prizes. We also activated the leaderboard, so feel free to chat in the chat section, visit the booth, visit the lobby and all the things so you can climb the leaderboard. Thank you so much Amber for your time, and we are moving towards the activity now. Stay tuned. Thank you.