The Web is Your A11y — Building Accessible Web Apps By Using the Platform

I want to talk about accessibility, and more specifically, I want to talk about web accessibility and how to build more accessible on the web by just using the platform. And what I mean by that is I want to show practical examples of how to use modern HTML and CSS to get a lot of those accessibility things out of the box by just using HTML right.

I want to start with the basics though to get everyone on the same page. I hope most people watching this already are in the mindset of that accessibility is important and why, but I also know a lot of people struggle convincing other members of their team or in their company or other stakeholders of that importance and why it needs to be considered as part of building your web application. Personally, I think it's quite surprising and sad to see how often conversations about accessibility quickly end up in like the corner of most of our users like don't really, are not affected by disability, so it's not a huge priority for us so we're not really looking at it.

This is frustrating on multiple levels. You might have seen this number before, it's often thrown around when talking about accessibility. It's from recent studies of the WHO which found that an estimated 1.3 billion people in the world experience significant disabilities, that's one in six of all people in the world. And basically saying like our users, if they don't experience that, it's saying you actively do not want any of those 16% to be part of your potential market which is crazy. But even ignoring that, it doesn't really show the full picture because this 16% number really just talks about what we would call permanent disabilities. So that's people with visual impairments or motion impairments, maybe cognitive impairments like dyslexia and ADHD.

But there's at least two more categories that we should talk about. One is temporary disabilities, so that's usually tied to some form of injury. So maybe you've broken your leg or you've broken your arm and your mobility is temporarily limited or you've had eye surgery and your vision is temporarily impaired. And then we have situational disabilities. Maybe you're holding something like a baby, which means you can't use your laptop or your phone in the same way you usually would or you're outside and the sun shines onto your device and the sun glare just makes it really hard to see contrast, these kind of things. All of them, all three categories affect you in similar ways.

The difference is really just how fast that effect wears off, if at all. But it shows like these last two categories definitely affect everyone to some shape or form in some parts of their life. So the whole discussion around the 16% becomes moving really quickly in my opinion if you look at that because it shows if you build for accessibility, you build for everyone, not just the 16%.

I also really like the definition of the Mozilla team that they've put on the developer docs on their website, which says accessibility is the practice of making your websites usable by as many people as possible. And I like it for multiple reasons. For one, it calls it a practice. So it points out that it's not a one off and done kind of thing. You actively have to think about it and do it.

And it shifts the language from accessibility to usability, which I found makes it a lot easier when talking to those other people in a team or stakeholders and make them understand why you care so much about these efforts. And I think it's sad that we have to do that. But as a takeaway from this, if you're in this situation where you're trying to advocate for more accessibility practices, maybe try to shift your language to help others understand what your motivation behind it is.

There's another one more principle that I want to explain as part of transitioning this into how does all of this apply to the web and that's affordances. So in his book design of everyday things, Don Norman defines a range of five different patterns that determine whether or not everyday objects are well designed. And two of those are relevant for us, which is affordances and signifiers. And it basically says affordances tell you just by looking at an object what actions are available.

And then signifiers tell you how to perform those actions correctly. And as an example, if you have a teapot, just the shape of the teapot kind of tells you that you're supposed to pour some form of liquid in it. And then the shape of the nozzle tells you the action of the device is to pour that liquid into other objects. And that's the idea behind it, that objects tell you what they're used for and how to use them just through their design.

And I think this translates into the web because we have these affordances and signifiers in the language in HTML for us. And for me, there's three layers to that. The first one is landmarks. So we have these landmarks elements like header and main site. They usually don't come with functionality, but they tell the browser where you are in your application. And this helps assistive technologies like screen readers or browser extensions, that kind of stuff, to navigate your website much more efficiently and much more quickly.

The second layer is what we would call semantic HTML elements. So that's the meat of it where we have HTML elements that actually have functionality, common UX patterns baked into them. And then there's a third layer of area attributes where we can apply attributes to any element to further describe what they are, how to use them, and what state they might be in and that kind of stuff. So this third layer is what people usually think of immediately when you start talking about accessibility. But I think it's important to think of all three layers as kind of like a priority list. When you're building something, start thinking about is this a landmark? If so, use one of the landmark elements to describe it appropriately.

If not, is the functionality that you're trying to implement already covered by semantic HTML elements? Even if it's not fully, but like if you can use it as a basis and then build on top of that, you already get a lot of functionality for free essentially. And only if that's not true, fall back to area attributes because area attributes usually don't come with any functionality at all. They just help you describe what the desired behavior is. And it's still on you to actually implement that behavior.

And to show that, let's go through a few examples. And actually, let's start with an example that hopefully shows how powerful semantic HTML elements can be. And for this, we have like a very basic button here. But it's a diff, but it has an unclick handler. So unclick, we want to increase the counter. And just on the first look, this seems okay, right? Like it does what I want it to do. But if you look a little bit deeper, it quickly falls apart. Like the first thing that I might want to try is to use keyboard controls and to tap into this button.

But I can't because the button is a diff and by default, diffs are not focusable. But I know my basic HTML, I know that's a role attribute that I can put on it to tell the browser that this is a button. But like I said, these attributes don't actually come with functionality. So I still can't focus the button. For that, I actually need to add a tap index. Because now it has a role to screen readers and other technologies know it's a button and announce it as a button. Now I can also focus it so that announcement actually happens. So if I now try to tap into the button, that works.

But I can't trigger it. Like I can't hit enter or space bar to trigger the onclick. So for that, I actually need to manually have a onkeydown handler that listens for all keydowns, checks if it's an enter or a space, and then executes the onclick. So now if I tap into this button, I can press enter and space and it just works.

Now, there's a lot more concerns that come with it. If I want to make the button disabled, I can't just use a disabled prop, I have to ARIA disable it. Again, ARIA doesn't come with functionality. So I have to add an actual like check in my click handler, only run the handler if it's not disabled. I also won't by spec, I don't want to be able to focus disabled buttons.

So then now I need to use that state to also check like, do I need to set the tap index to minus one or zero? I could go on and on with this. I hope this shows how much effort actually goes into trying to build any of these semantic HTML elements from scratch, where we could just use in this case, the button element and it gives all of that for free.

And it's been baseline widely available since 1997. Isn't that amazing? So yeah, again, this might look like a very extreme example at the same time. I'm sure a lot of us have actually seen this in the wild. And it just shows that it's worth relying on these spec elements that have gone through years of specification where very smart people have thought about concerns, including accessibility.

All right. Now I want to look at a couple of other elements that you might not know about because they're newer or you've known about them, but like you haven't used them a lot. The first one is the dialogue component. So again, a very common UX pattern where we have this dialogue thing that we want to open and close and dialogues that basically block the rest of the page from being interacted with. So we don't want to be able to interact with anything in the background while the dialogue is open.

And this used to be done with a lot of JavaScript, but for a while now we've had the dialogue elements. And with it comes two new attributes on the button element that helps us interact with the dialogue without any JavaScript at all. So on the dialogue, we give it an ID to identify it. And then on the button, we have a show more dialogue command. And in the command for, we just point to the dialogue that we want to open. And that's all that's needed to get that first interaction.

And that's all that's needed to get that first interaction. And in the dialogue, we have a command close button that helps us close the dialogue. And because it's all HTML, we can use CSS to target specific things to customize the look and the behavior of certain things. So we can style the backdrop. So if we wanted to make that green, for example, we can easily do that. But we can also do things like more advanced things like animations. Like we can animate the dialogue in and out, especially even if we dynamically add the DOM element to it, we can use discrete animations and starting styles to define where the transition should start in any given case. And in this case, we want to scale it in and from opacity zero to one, and we can easily do that for in and out, which is really powerful. And if you haven't looked at dialogues because of these restraints, this is all newly available since 2024, so quite a while. And all major browsers definitely check it out again and give it another try.

A very similar pattern is popovers, where the main difference is with popover elements, they still pop up, but they shouldn't block us from interacting with the rest of the page. For that, it's not a dedicated element. It's just a popover attribute that can put on any element, but the pattern is the same. We give it a unique identifier and then we have a popover target attribute on the button, tells the browser if I click on this button, that's what I want to open. But by default, it just opens it in the middle of the page, which isn't really what you want with popovers. Popovers, you want to position relative to their trigger. And we can do that with CSS anchors. So that's been finally newly available since earlier this year. So again, definitely check it out if you haven't. It basically allows us to on the trigger elements, in this case the button, we can give the button an anchor name. And then in the popover itself, we can say position absolute and position relative to that anchor. And then we can use the position area to say like where relative to the anchor we want to position it. So right now, bottom center, if we change that to top, it goes top center. And it deals with all of the collision magic for us. So calculating whether there's enough space, otherwise push it in a little bit or flip it to the other side. The browser does all of this for us, but we have full control via CSS, which is pretty cool.

When we talk about popovers, the next thing that you probably think of is tooltips. Because they're very similar behavior, just in different interactions. So usually tooltips you want to trigger when you hover over an element, and you can't do that with the popover API. So for that, this is very experimental.

This is Chrome playing around with stuff. We have a new attribute which is interest for. It still uses the popover as its target, but it's a new attribute on the button which tells it, hey, whenever this interest event happens, which by default is the hover event, open this popover. And then we have new CSS abilities to actually specify behaviors around these interest events. So have a delay of 300 milliseconds before you actually show it because usually with tooltips, you don't want to immediately show them so they don't like get really distracting. But when I keep hovering, it shows up and gives us that ability. So all this is to say, keep an eye on that space. Again, this is very experimental, but hopefully this space evolves into an API that other browsers are also happy to start adopting and build around.

The next thing is a personal favorite of mine. It's accordions. I think we've had the details and summary tag for ages now, but I don't think people use them enough. And for me, there's two primary reasons why you should use them, especially if you build like documentation and software, you use them a lot to hide more content until it's needed. So basically what this gives you is that accordion style, you can click on it and it expands the content that's hidden inside of it. Obviously, like it deals with a state management for you. So no JavaScript needed. You have the on and off state. You have all the accessibility with it as well. Again, you can focus into it, use keyboard, et cetera. But more than that, it deals with other concerns like discoverability. So I have it closed right now, but if I search and what I'm searching for is in the content of the accordion, it will automatically expand it and jump to that spot for me. And this is very hard to impossible to actually manually implement in CSS, in JavaScript. So again, using the power of built-in HTML and CSS, this is really cool here. If one of the concerns for you was, I actually want the behavior where only one of a group of accordions is open at a time, this is actually newly available since 2024 with a name attribute. So if I click on second first, I'm automatically closed, right?

Another element that's probably more exciting for the wider audience here is select. So selects have been a pain ever since I started as a developer. And this is really exciting for me to actually start being able to fully customize the look and feel of selects. So this is our standard select that we know and hate to the best parts. We can customize kind of like the trigger to certain extents, but the menu, we can't. We don't have any control over it. Even if you put like HTML in it, the browser will just ignore it because options really just take text.

So everything else gets stripped out. Now, again, this is experimental. This is Chromium only at the moment, but the idea is to build on the existing select element and just add a new appearance that we can apply to it. And when we set it to base select, the browser knows, hey, don't render it like a normal thing. Render this with a new customizable way. And what this allows us to do is actually do render HTML inside of our select menu options. This makes it really powerful while still getting a lot of browser behavior for free, keeping track of your selected state, et cetera.

It also comes with this selected content element, and we can render a button within the select component, which then is a fully customizable trigger element. So it replaces the built-in trigger. And we can do whatever we want with this, like I pick you. This selected content is just a helper that automatically grabs the HTML of the currently selected option. And then we can still target that with CSS and further style it and do whatever we want within the trigger. Again, very experimental. There's definitely going to be a lot of changes to it, but it feels a lot further than previous attempts to customizable selects have come. I'm really hopeful and looking forward to this becoming a standard across browsers.

Now, the last one that I want to talk about is carousels, because again, very similar. It's a very common UX pattern. We have this scrollable container, but we want to give more like affordances to the user to navigate around this container. So what we can already do like for a long time is having scroll behavior and scroll snap. This allows us to force the browser to snap to certain scroll positions. Our carousel elements always centered, which is nice. But I still want more like navigation elements to help the user navigate the carousel in the first place. Again, experimental. Only Chromium. Two proposals out there that will help with that. The first one is the scroll button pseudo selector, which is applied to the carousel itself and allows us to pass in which direction we want this scroll button to trigger the scroll. We can fully style it however we want, but the browser will automatically deal with triggering the scroll for us in combination with the snap. This is really nice in that accordion feel, but it will also deal with the disabled state. It will automatically disable these buttons when you scroll to one end or the other and enable them again. All fully accessible, keyboard accessible, out of the box, without you having to even think about that.

The second part is scroll markers. So if I want to show where in the carousel you are and how many carousel items there are, we can use the scroll marker group, which is applied to the carousel, which just defines this container. And then on each carousel item, we define the scroll marker that gets inserted into that group. And again, fully customizable, but not only can they allow me to show where you are, but they are also interactable. So I can click on the markers and it will scroll the container to that point for me. And again, it's keyboard accessible, so I can focus them and then use arrow keys to navigate around. Worth keeping an eye on, worth keeping generally an eye on, more and more of these common UX patterns are being adopted through specs into the core of HTML and CSS, which is pretty cool to see.

Now, I want to very quickly talk about AI, because a lot of people hopefully say like, with AI, accessibility will be solved in the future, because AI will just build accessible applications out of the box and everything around it. And one of the big hopes is that AI will help with accessibility testing, because one of the big problems with accessibility testing is that it's very manual, very high effort. And that's because most issues cannot be automatically tested for. So studies have shown that even at best estimates with really good automated tools, you're only detecting 30 to 40% of accessibility issues, which means up to 70% of issues will stay undetected and require manual testing. So this is one of the potentials that a lot of people say like that might help with improved automated testing, which I agree with. Especially the more we can give AI control over the browser and let it describe what the desired behavior is, I hope that there's going to be more capabilities. I don't think it will cover it fully, but at least more than those 30 to 40%. Other areas are like automated generation of accessible boutique content like alt text. We see it in more and more apps that if you upload images, there's going to be an alt text automatically generated in your social media stuff for you. I'm skeptical of that. Like yes, this is good if it works. If it's not correct, it can do more harm than good. So just be mindful of that. And then there's code gen tools. And the more we use code gen tools, the more those tools can actually apply accessibility to the code that we're generating. But this is where for me the risks are. So low quality content that models are trained on means that those code gen tools that we use today probably don't follow the best practices around accessibility on all ends. So garbage in, garbage out. If we don't make our models better, if we don't make the code that we use to train those models better, we won't get better code for free. This ties into biases whenever we train those models that generate our code. They're trained with biases, that's unavoidable. It just means we need to be aware of it. Like what biases are going into the training data and how does it affect accessibility.

And for me the big one is the first one here, and the risk, the checkbox phenomenon. So companies that see those AI tools that promise you accessibility for free will use that as an argument for like, okay, we've done our part around accessibility, so we're good even though those tools will not 100% fulfill what we need to. And then it makes those conversations around accessibility even harder than they are today.

So I want to leave with a final note based on all of this. I don't think the web is fine at the moment, and especially with AI and code gen more and more. I want you to think about where the next time you use the web application, take a piece of paper and make a note every time you run into an issue around accessibility. So if you try to focus an element but it can't be focused because it's not actually a button, it's just a diff, or it can be focused but you can't see the focus because the designer decided that the focus ring is ugly so they just removed it.

Or you try to open a link in a new tab by command click and it doesn't open in a new tab because it's not really an anchor attribute, it's just using JavaScript to navigate. All of these issues, make a note of it, and I think you will quickly realize how broken the web is at the moment and how much of it we've just started to accept. And I mention it because all of us, we're working on the web so I feel like there's a responsibility and a chance here, especially with AI, to actually change this to the better.