How Popovers Are About to Become a Whole Lot Easier to Build

Rate this content

You've probably build one of these before: tooltips, date pickers, menus, teaching UI… they're all examples of “popover” content. Good news: it's going to get a whole lot easier to build these, with some proposed web platform features. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, when to use modality and access to the top layer.

28 min
20 Oct, 2023

Video Summary and Transcription

This talk explores the challenges and guidance for building well-designed popovers and dialogues in HTML. It discusses the differences between dialogues and popovers, their use cases, and the importance of semantics in differentiating them. The talk also covers UI considerations, implementation, and positioning of popovers. Additionally, it highlights the use of modals for blocking access to the rest of the page and the role of semantics in making accessible dialogues and popovers.

Available in Español

1. Introduction to Popovers and Dialogues

Short description:

In this talk, we will focus on content overlaps in design systems, particularly popovers and dialogues. We will explore the challenges and provide guidance on how to build them well. HTML offers two exciting features, dialogue and popover, with wide browser support. While dialogue is more established and accessible, popover is newer but gaining support across major browsers. It is recommended to experiment with these features while considering accessibility.

So who has got popovers in their design system? Show of hands. Cool. The majority of this audience.

I only found out recently that in the US, Yorkshire Puddings are called popovers. I even found this video on America's text kitchen, where they say popovers can be real tricky as we're about to find out in this talk. They've got a custody inside. I can't promise that for today's talk.

Yeah, we'll be focusing on content overlaps other content. Super common, it wasn't always like that on the web, right? We had long blobs of linear content, and now we like to put stuff on top of other stuff. On some websites, they really go overboard with this, where you get like banners for, do you want to go send to cookies? Do you want to sign up for our thing? There's ads that are quite bad and invasive. And then sometimes, you even get more stuff on top of that. Like in this case, why? It's no good. It's no good, and you see a problem here in this example is that their modal to ask you to sign up for the newsletter is actually underneath the cookie consent thingy. Not good.

And yeah, you're probably aware of this website called It's modal with a z. It explains, in quite a lot of detail, why you should not be using modals, and that's something I won't be covering today. I'm not going to talk about why you should use them. I'm going to talk about if you are using them or if someone in your team decided were using them, how to build them well.

And the reason I got interested in this is that as of recently in HTML, we've got two exciting features that allow you to build popovers and dialogues quite well. A little bit of a spoil here, I'm not only going to talk about popovers but also about dialogues because they are quite similar, and I to leave this room with knowledge about how they're actually different.

So dialogue is an HTML element that has wide browser support that, as of recently, works really well accessibly as well. Like it's safe to use. There's still some stuff to iron out. There used to be a lot more accessibility issues with it, and it's quite safe to use now. And then there's popover, which is fairly new. But also, it's supported in Chrome and Edge, Safari, and it is in Firefox behind the flag. So very soon, we'll be able to use this. And I recommend actually experimenting with it today. There are still also some accessibility considerations to take into account.

2. UI Considerations and Examples of Popovers

Short description:

Today, we'll talk about UI considerations for dialogues and popovers, and the importance of semantics in differentiating them. I'm Hedda, a developer and accessibility person at NL Design System. I'm also part of the Open UI Community Group at W3C. Let's explore some examples of popovers, including their use in Slack and Microsoft Teams.

I do have a blog post coming out about that soon because there is some stuff to look at there. Today, we'll talk about UI considerations for these things, and also semantics, which are really important, especially when you're thinking about both dialogues and popovers, how are these actually different? It's quite a challenge to find out.

Now, as mentioned, I'm Hedda. I work at NL Design System for the Dutch government. I'm a freelance developer-related accessibility person. And I'm also a participant in Open UI Community Group, which is a group at the W3C that makes things like popovers. So we're working on it there. I now have my own blog on You can like and subscribe. The other day, someone thought you could actually like and subscribe. You need to get the RSS feed. So that's something you can use.

So let's look at some examples of popovers. They are everywhere. I don't know if anyone's got the new Slack yet, but they do use a popover to explain to you how to use it. Teaching UI is what that's called. It's not always used in very good ways either. We've seen previous examples. When I was using Teams to chat to my colleague, I got this feedback popover that just popped over my content, my conversation that I was having. And the other day, when I was in a very serious business meeting, I got Microsoft to promote their other products in Microsoft Teams. They went, do you want to use Excel, because we also make that. I'm not sure, like, it was kind of in a way, because I was getting ready to have some very serious conversations there. And it goes even weirder sometimes. They also encouraged me to be my expressive self. Create some avatars. No, thanks. I'm in a serious meeting. There's better things like Slack that give you this popover that says, you look nice today. And they don't even check your camera footage for it. They actually tell you you look nice every single day, which I appreciate.

3. Differences between Dialogues and Popovers

Short description:

In banking, popovers are used for combo boxes, date pickers, and more. Let's explore the differences between dialogues and popovers. A dialogue is an additional window that contains crucial information or asks for user feedback. To build dialogues, you can use the dialogue element in HTML and call show modal or show in JavaScript. Using the dialogue element provides browser support and built-in behaviors. Dialogues are supported well across major browsers with improved accessibility.

There are more serious things too. Like, in banking, you'll find popovers to do, like, combo boxes, date pickers, all these sorts of things. So lots of popovers exist across the web. And I want to look now at how these patterns are different, because some of these are dialogues and some of them are popovers. And many of them are both.

So let's look at what the differences are, starting with dialogue. So a dialogue is an additional window to your main window or a sub-window. One of the things I found out working on this is that there isn't one central definition. So I'll be giving you a couple to helpfully guide you there. Another definition is something that contains an action or a task or crucial information or critical information. It's often a conversation between you and the system. It will be things like do you want to continue, yes or no? Or if you're starting a new file, what do you want to do with the current one? All these kinds of things where you actually need to talk to the user and need to get their feedback immediately. So it is warranted to kind of interrupt them and go and ask those questions.

Now, to build dialogues, there is the dialogue element in HTML. And you can use it with scripts. I don't have any React examples in here, but you can port these to React, because it's all vanilla JavaScript. So when you find the element or you have a ref to the element, you can call show modal on a dialogue or you can call show. So show modal is going to show it as a modal, and show is going to show it as a non-modal. We'll get into the differences in a bit. So this one is important to talk about the word dialogue. So if you use the dialogue element, you get lots of stuff for free from the browser. So it will make it modal for you. It will do the keyboard stuff for you, and it will do a bunch of other things. That is different from using a role of dialogue on a div, because the role of dialogue is going to give you that semantic, but it's not going to give you any of the behaviors. And then that is also different from using just the word dialogue, which you might do in conversations with your colleagues. That is a different thing altogether. So you might be using a role of dialogue or even a dialogue element, but those are kind of different levels of using dialogue at work. Now dialogue is supported quite well across all the major browsers. And there used to be quite a big amount of accessibility issues, and there are a lot less now. And for more detail about that, I recommend Scott O'Hara's blog posts about them.

4. Popover Implementation and Use Cases

Short description:

A popover is a floating, non-modal dialogue used for transient content. It is implemented as an attribute in HTML and provides built-in behaviors. Popovers are being used by Chrome and websites like They are triggered with scripts and used for tooltips, menus, and more. Popovers have various use cases, including content figures, form element suggestions, action menus, list boxes, and teaching UI.

This most recent one used the dialogue element reasonably. Moving on from dialogues to popover, a popover is a floating piece of UI that's supplemental, contextual, and importantly, a non-modal dialogue. So with dialogue, you can make modal dialogues, with popover you can make non-modal dialogues. And they are also for transient content.

In HTML, they come in the form of an attribute, so not an element. And when you add that attribute to an element, it's going to add a bunch of behaviors, which could include like dismiss, keyboard, top layer presence, also closure of other popovers. It's going to deal with all of these kind of things for you. Now this is for elements that are on top of other page content that are not always visible and that are usually displayed one at a time. That's kind of how it was meant to be.

And it is actually being used by some people. This is from Chrome, a stat that is clearly going up. It's 0.3% of page loads in the Chromium-based browsers. And I don't know if you know this website called, but they are using it in production at the moment. Experimenting with it, I believe, but they are using it now. So they have a manual popover. That means that they are triggering it with scripts because they make it work on Hover. So when you hover over icons and you get a little tool tip, that's a popover. In this screenshot, you see a menu right underneath. That's also a popover. And you can see that it appears in the top layer as well when you inspect it in the browser. It's also coming to Photoshop on the web. I don't know if you've seen, but they build all of Photoshop on the web. Pretty exciting. And they are also looking at using popover there. So popover is for content figures. It's for form element suggestions, for action menus, for list boxes, and as mentioned for teaching UI. So lots of different and very variety use cases there. This is how it works. Basically, if you have a button and a div and the div is your popover, what you can do is add the popover attribute. And in React, in JSX, you'll have to give it some value so you can give it the empty string as a value.

5. Working Popovers and Understanding Differences

Short description:

When you add an ID to the button and give popover target equals that ID, the popover will work without JavaScript. This reduces bundle sizes and allows the browser to handle it. There are different types of popovers, such as auto and manual, with various behaviors. Popovers are supported in all browsers, with Firefox being the only exception. It's time to experiment with popovers and understand the differences between popovers and dialogues, particularly in terms of modal versus non-modal content.

Then when you add an ID to it and you give popover target equals that ID on the button, this is now working popover. The button is going to toggle the popover for you. That's pretty cool. It works without JavaScript. I know I'm at the React Conference and we are all about JavaScript here, but it's a really cool opportunity to reduce your bundle sizes because where before maybe you would need to run some scripts, now the browser will take care of it for you and will take care of lots of other stuff while it's at it. And that's pretty cool.

In fact, it's so cool that they're now also working on getting this in dialogues and other types of elements. So with something called the invoke attributes, they will make more buttons do stuff without JavaScript. It's just kind of cool. There are other attributes you can use like popover target action, where you can say this button can only show something or it can only hide something. And there are different types of popovers. The auto one will close other popovers and it's going to like dismiss, meaning when you click outside of it, it will disappear. And the manual one, which will not like dismiss and will not close others, and usually will open that when it's correct. You can also open them in JavaScript. So you can do element.showPopover. Again, you'll need the reference to the actual element in the dom for that.

Now popover is supported as mentioned in all the browsers. In Firefox, it's behind the flag. In other browsers, it's available. Your users might not be using the latest version of Safari, for instance, but it's coming. And I think that's cool. It's time to experiment with it. Now when I was working on popover and joining these open UI meetings, we kept talking about popovers and dialogues. And I realized that I didn't actually understand it as well as I thought I did, because I kept hearing all these phrases like, this is modal, this is not modal, this is this, this is that. So I started to think about how are these things actually different? And I want to share what I found. There are a couple of different axes on which they are different. So the first one being modal versus non-modal. So modal is a bit of content that is the only thing you can interact with. So if you are tracking your users according to EU law, you need to get permission. And if you don't have the permission, they can't interact with the site.

6. Modal Dialog Use Cases

Short description:

Modal dialogs are useful in scenarios where access to the rest of the page needs to be blocked, such as session timeouts on government websites or game over screens. They interrupt the user's flow and limit interaction to the modal content.

So it's a good use case. It's a bit annoying thing to have, but it's a good use case for like blocking access from the rest of the page. Another example is when you're on a Dutch government website and your session time's out, that's after 50 minutes, you usually show a modal to ask people to extend their session. Because if they are midway their text return, that takes two hours and they press submit, they might not be able to submit it if they're no longer authenticated. So these kinds of things are typical kind of modal examples. You need to interrupt the user. It's a bit like an alarm clock in the morning. You need to interrupt the person even if they might not like it, because reasons. Another example is a game over screen. You're playing a game. You can no longer play the game because you're dead. You can't go back to the game, you can only kind of interact with this game over screen. It's the only thing available to you.

7. Modal and Non-modal Elements

Short description:

Non-modal elements allow interaction with the rest of the page, while modal elements block access to other content. Light dismiss automatically hides UI elements, while explicit dismiss requires a button press. Z-index and top layer control element ordering, with the top layer being above all other elements. Backdrops and keyboard focus traps are often used in modal elements for styling and user experience purposes.

Now, non-modal is the opposite of that. So it's a thing that opens on top of other contents, but also you can still interact with everything else on the page. So it's more of a part of the rest of the content. So it's things like toggle tips and menus and chatbots as well. Imagine a chatbot where you could only chat and not look at the rest of the site. So making something modal is a drastic measure. You probably don't want to do it with many things, but sometimes you kind of have to.

Now, another axis is light dismiss versus explicit dismiss. Basically, the difference is that with explicit dismiss, you will press a button to dismiss the dialogue, whereas with light dismiss, it kind of disappears automatically. So when you're choosing a font in Google Docs and you scroll or like click outside, that's just going to disappear. And that's fine. Like you don't expect it to stay there forever, it will just go away. So it's that kind of UI that needs a light dismiss.

Then Z-index versus top layer. With Z-index in CSS, you can change the order of things. Like sometimes you have multiple things in the same place. And with Z-index you can kind of change the ordering and say, this is going to be on top and that's not. Top layer is quite different because it's a layer that's on top of everything. So even your highest Z-index, if you have like a 9,999, top layer's still going to be on top of that. It's a separate thing. And that's also how it renders in like Chromium browsers, and will show us a thing that's kind of next to the HTML element. So it's really like its own world. And the way layering works there is not through Z-index, but through the order in which things are added to the top layer. So to get this second thing to be on top of the first thing, you need to edit seconds, basically, or take everything out if you want to re-order stuff.

Then backdrops. Some of these patterns also have backdrops. They can be in modal and non-modal things, but usually they are part of modal dialogues. So sometimes they have backdrops, and if they're in the top layer, they have a built-in styleable backdrop. So with colon colon backdrop you can style through CSS, power of CSS, awesome, style your backdrop to be any color you like, have a blurry effect, all these kinds of things. And then there's keyboard focus traps that sometimes need to happen in modal elements, it's usually used and sometimes in non-modal things as well, like calendars, where you really don't want users to escape the thing, because it might be annoying for them to lose track of where they were.

8. Focus Traps, Modals, and Semantics

Short description:

So focus traps are sometimes useful, but always temporarily. Modal is what you get when you use dialogue with show modal method. Non-modal is what you get with anything else. Light dismiss is what you get with popover equals auto. Explicit dismiss is what you get with popover equals manual or any kind of dialogue you're building. ZnX is what you get when you use dialogues with show or any kind of content you're building. Backdrops are built into any top layer element. A keyboard focus trap is what you get when you use dialogue with show modal. Semantics are important for making accessible dialogues on popover.

So focus traps are sometimes useful, but always temporarily. So these are the things, kind of how they are different, and I wanna show you kind of how to interact with popover and the dialogue.

So modal is what you get when you use dialogue with that show modal method, that's the only way to get the browser to do something modal for you. Then non-modal is what you get with anything else. So modal, a dialogue with show method, or popovers, they will be non-modal. Then light dismiss, you can only get when you popover equals auto. And explicit dismiss is what you get with popover equals manual, or with any kind of dialogue that you're building. Then ZnX, you always get ZnX, you get top layer access when you use popover or dialogue with show modal. There is no other way to get into the top layer. Well, full screen API is one if you're using that. But popover and dialogue with show modal are the only ways to get this. So no library is going to provide this for you without using these primitives. Because this is the only way that browsers are gonna let you into that special top layer. Now, ZnX is what you get when you use dialogues with show, or any kind of content that you're building. Backdrops then, they are built into any top layer element. So, same as before, it's popover and it's dialogue with show modal. And then, a keyboard focus trap is what you get when you use dialogue with show modal. So the browser is going to take care of it for you. Seems kind of exciting. Now I wanna quickly dive into semantics for this. Because that's a really important part of making accessible dialogues on popover. You need to know what stuff is. Now, I studied philosophy, so for me, semantics would be like, what is this thing? But if you talk about web developers, it's probably what is this thing in this page or app? That's kind of what the science of semantics is all about. And you'll have semantics in your site, like when you use headings, you get heading semantics. And they are very helpful because a screen reader user can pull up a list of headings and then browse by headings. Actually, one of the most common ways that people with screen readers navigate across websites. So they'll look at your headings. So provides an API, basically, of headings. An anchor tag comes with the link, a list item comes with list item, dialogue comes with dialogue. Divs come with nothing, which is fine in some cases, if there's nothing to convey.

9. Popovers and Semantics

Short description:

Popover attributes do not add semantics, only behavior. You can add roles to divs with popover attributes to determine their role on the page. The most common role is dialogue, used for smaller windows with interactive elements. Listbox is used when users need to choose from options. Menu is used for actions, not navigation. Tooltips are plain text, while toggle tips with headings and dismiss buttons are more like dialogues.

You can also add roles to divs and you can add as mentioned that popover attributes. And the thing to note here is that popover attribute is not gonna add any semantics for you. So like a heading tag will give you a heading semantics, popover will give you nothing. It's going to add behavior and not semantics.

And so in the next few slides, I'll show you a couple of different semantics that you can add yourself. So if you have a div with popover element on their attributes, you can then add a role attribute to decide what role this is going to be within the page. The most common one is dialogue. So you can have popovers that are dialogues. They're very common. Like I said before, they are smaller windows, sub windows, and it's basically the case when you have like multiple things in there, interactive elements, maybe some buttons, some links, that's usually a dialogue that people can interact with. Teaching UI is often a dialogue, mega navigations could be because they have lots of stuff in there. And then the next one is listbox. That's basically what you use when your popover is something that people need to choose from. So an emoji ficker or like something to check a currency, all these kinds of different things. So listboxes are also part of combo boxes, but then you're nesting stuff, right? So the listbox is the kind of thing that people pick from, and you might have other things in there as well.

Then the menu role is quite common as well. So that's what you use when you have a bunch of actions that users can do. So a menu is not for navigation. If you have a navigation thing at the top of your page, that's the navigation. A menu is really with actions in it. So it will have buttons, stuff that people can do. It executes functions basically. So in this case, there is a function to remove an item, to duplicate, it's basically like an application type of thing. It's also what is used for a menu like in Google Docs, the file menu that you open, that's typical menu as well. Then tooltips, they're quite common popover use cases. The thing to note about tooltips is that they are plain text. So when you have a string of text that goes into a tooltip, when you have anything more, it's usually a toggle tip that is more like a dialog. So if you have text in there, but also a heading and also a button to dismiss it, that's probably a dialog, even though it feels a bit like a tooltip. I don't know if we lost the connection there. That's cool.

10. Semantics and Positioning

Short description:

In terms of semantics, the dialog element has dialog semantics, while the popover has no semantics. Positioning is important to consider for both dialogs and popovers. Two solutions for popover positioning are using a library like floating UI or anchor positioning in CSS. The dialogue and popover APIs can reduce your JavaScript bundle, eliminating the need for libraries.

Might come back. So in terms of semantics, the dialog element has dialog semantics, it's built in. The popover has no semantics and you need to pick it yourself.

Now, moving from semantics, I want to talk a little bit about positioning and I don't have a lot of time to cover a lot about that. But the thing to note about positioning is that both dialogs and popovers are centered by default because they are in the top layer, the browser doesn't know where to put them. So they are not going to be relative to other content on your page. They're actually going to sit in the center. So that's something to keep in mind.

If you want to anchor your popover to the thing that invoked it, then you need to think about how you can do that because only one of them is in the top layer. So your popover is in the top layer but the button that opened it is not in the top layer. They don't know about each other because they are very separate layers. So that's important to keep in mind because often you want to acquisition a popover relative to the thing that opened it because they are visually close to each other.

So, two solutions basically for popover positioning. So one is you use a library like floating UI and you calculate where the thing needs to be and you put something like cells and like put it where it can go. Or you can use anchor positioning, which is a new proposal. It isn't out yet, although it is in Chrome, but it's still kind of in development. And that is going to solve it in CSS. So rather than importing a library for positioning, this will allow you in CSS to say, make this thing anchored to that thing and kind of give you a way to automatically do that. Again, without libraries. As I don't have a lot of time to go into it, I'll refer you to my blog post called Positioning Popovers. It tells you more details about how that would work.

For now, I wanna wrap up. So we've talked about UI considerations and semantics. A couple of things that I hope you've taken away from this talk. One is that dialogue and popover APIs, they can reduce your JavaScript bundle. And that's very exciting, I think. You no longer need the library to do dialogues. A lot of stuff can be taken care of by the browser. The popover attribute also just adds behavior. It doesn't add semantics.


Popovers and Modals in Mobile Apps

Short description:

There are attributes like TEF index and content editable that add behavior but don't do much else. Popovers and dialogues with showModal provide top layer access. Popovers and modals should not be used for cross-promotion. Popovers and modals in mobile apps are implemented more gracefully. Accessibility is crucial, and the browser can help with accessibility aspects. Browsers are trying to handle relationships and improve accessibility. Introducing a visual attribute-like popover is an interesting question.

That's the case for a lot of things, right? There is also the TEF index attribute and the content editable attribute. They also add behavior. They don't really do anything else. It's very common for attributes, but important to note.

Then, top layer access is an important facet of this. So popovers and dialogues with showModal, they get top layer access, nothing else will. So you can't get top layer access with any other things than these APIs. And last thing to mention is, don't use popovers to cross-promote your products. That's not what it's for. And with that in mind, I want to thank you very much and refer you to my slides that are on that QR code. Thanks.

So I think there's one that was getting the most excitement from people, which is what's your opinion on popovers or modals in mobile and the mobile app space? From the points you've mentioned here, it seems like mobile apps implement them more gracefully in general. Would you tend to agree with that? Yeah, yeah, I think that's fair. Yeah, yeah, I agree with the point. Yes, great! Excellent! This next person's brought up the difficulty that popovers and modals can present for, from an accessibility perspective. What's your kind of thoughts there? Yes, it's true. But, yeah, accessibility is a very wide subject. There are a lot of different users of the web, and they also bring benefits to lots of other users. Like, there is a benefit in that they help you make your content such that some stuff is hidden and some is visible, which makes your interface more concise and will make it more usable. Now, it's super important to make sure that you do it in an accessible way. Today, people are building a lot of these components in an inaccessible way, and I hope that both popover and dialogue can actually help make it more accessible overall because the browser will take care of more of the accessibility aspects of it. So, it can build in accessibility, so to say. And that is really hard because there's a lot of nuance to it, but this is what browsers are trying to do today. So, they'll take care of relationships like, is this thing expanded or is it not expanded? Does this thing say something about that other thing? That's kind of relationships that people who use screenreaders need to know about and that often aren't put into the system. So, with these new APIs, they could be done by the browser, and I think that's really exciting because it allows us to build more stuff and the browser to do more accessibility. So, I think that's cool. Nice, and to keep that in the forefront of our minds when we're developing in place. So, after decades of deprecating visual stuff in HTML, oh, here we go. Just looking at the questions moving around. What's your opinion on introducing a visual attribute-like popover? Interesting question.

Popover's Semantic Evolution

Short description:

Popovers are not just a visual element, but also introduce keyboard behavior and focus management. While popovers have different semantics, you still need to design your own layout for them. The decision to make popover an attribute instead of its own element was driven by the lack of a single semantic that could cover all use cases. It was initially proposed as an HTML element called popup, but the realization that different popovers have different semantics led to the decision of having no semantics and treating it as behavior. Looking ahead, it's challenging to anticipate how the web could have been used now. Turning off all modals without disabling JavaScript is a possibility with browser-based features like popovers, but ad people will always find ways to work around it.

It's not just a visual. So, it introduces keyboard behavior and introduces focus management and all these kinds of things. So, yeah, I don't agree that it's a visual thing, but it's also not a semantic thing as mentioned. Like, yeah, it's just behavior basically. I guess this kind of highlights the point that you brought up at the start around there being these disparities around the importance of semantics.

Yeah, yeah, there's a lot of different semantics that this can work with, but you still need to do your own layout for popovers. So, by default, it's a div or whatever you use, and you still need to design them yourself.

Well, staying on that theme, there's a question here from Alexandra. Why did popover become an attribute instead of its own element? Which elements would it potentially be used other than? That's a really good question. It's related to these different semantics that I highlighted. So before we thought, and at that time we also thought it would be called popup, but decided not to. That was a proposal for an HTML element that would do it. But we realized that there was no one semantic that would actually cover that because there are different things. Like, some things are menus, some things are list boxes. So if you're going to give a menu default then what if it is a list box? So we decided like it should have no semantics, it's just behavior. But yeah, that was a process, because it was first imagined as maybe there should be an element. There was even talk about multiple elements. So you'd have like a list box element and a menu element. Menu already exists but deprecated, so yeah. Long story, short. It's difficult to look ahead and anticipate how we could have been using the web now.

Yeah, for sure. So I think we've got time for maybe one last question. So we've got the most updated one here by a couple of late entries, but Biomar seems to be, since it's a browser-based feature, does this mean that one day we can turn off all modals without disabling JavaScript? Yeah, that's a cool prospect, yeah. It will make that a whole lot easier, but I guess like the ad people will still work around it and annoy you. It will happen, yeah. Well, I was gonna say they... Ads will find a way not to go full Jurassic Park on it. Get a good ad-blocker, like this is very important. Excellent, on that note, thank you so much for your talk today. Thank you. Now, you...

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Top Content
Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.
JSNation 2022JSNation 2022
24 min
a11y and TDD: A Perfect Match
Accessibility has been web development's ugly duckling for quite some time now. I often get asked, "when should you test for a11y in your apps?" My answer is simple, "right from the start!". Regardless of the framework considered - React, Svelte, Vue, YourOwn™️ - as developers we are in a privileged position to help the ugly duckling grow into a beautiful swan. How? By diving deep into the pond and harnessing the power of Javascript APIs to build the right components for your web apps. And how can do you know you are building them right? By pairing Test Driven Development with the Testing Library family. Ready to grow your web apps into swans?
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
Our design systems commonly feature components that show on top of other content: tooltips, date pickers, menus and teaching UI, to name just a few. Proposed updates to the web platform are about to make building these a whole lot easier. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, modality and the top layer.
React Advanced Conference 2021React Advanced Conference 2021
32 min
How to do Good Without Doing Anything
There’s no arguing that building accessible websites is a force for good. But ensuring that our React websites and apps work for everyone can be time-consuming and isn’t always easy to get right. Luckily, investing a little bit of time on your accessibility workflow and setting up a series of automated tools will end up saving you tons of time and energy in the long run.In this talk I will demonstrate how you can leverage automated tools, clearly documented code standards and a well-defined development process in order to make building and testing accessible React apps a breeze. I will discuss the ways that I automate certain aspects of my development workflows to catch accessibility errors, define and set up tests and go through the entire lifecycle of accessibility feature development using a real-world example.
JSNation 2023JSNation 2023
30 min
Accessible Component System Through Customization
Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization, and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance.
How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much accessible we can provide out of the box to our users? How much customization freedom is enough?
That's what my talk's about.

Workshops on related topic

React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)
React Summit Remote Edition 2021React Summit Remote Edition 2021
91 min
Creating Accessible React Native Apps
React Native is a framework used to create native iOS and Android apps in a way web developers may already be familiar with. But how do you ensure your React Native apps are inclusive and usable everyone? Scott will share tips on how to test and build React Native apps with accessibility baked-in!