Show Notes

This episode is made possible thanks to my sponsors, help me continue to make contributions to the web by sponsoring my work.

Socials

You can follow Hidde on Bluesky: @hidde.blog or Mastodon: @hdv@front-end.social

You can follow Lola on Bluesky: lolaodelola.bsky .social and Mastodon: mastodon.social/@lolaodelola

Episode Links

• Accessibility Compat Data
• On popover accessibility: what the browser does and doesn’t do
• Popping preconceived popover ponderings

Transcript

[00:00:14] Lola: Hello, good people and welcome to What The Spec, a podcast where I Lola unpack browsers and web standards with the people who create them. First up, I wanna say a massive thank you to everyone who listened and shared the first episode with Keith last month. I had such a warm and positive response. If you haven't heard it yet, go back and listen to how Keith went from web engineer to browser engineer.

[00:00:42] If this is your first time listening, thank you. I'm a former web developer and current independent standards technologist, a member of various open source and standards groups, and an appointee to the W3C technical architecture group. I care about bridging the gap between web developers and web standards, which is why I created this podcast.

[00:01:04] In this month's episode, we're going to be talking about accessibility. Last week was Global Accessibility Awareness Day, and I launched the Accessibility Compact Data project. It's definitely a project that is starting, so there's not much to show for it yet, however. It aims to collate assistive tech and browser data to make tools like baseline accessible and also provide web developers with data on how web features are spoken in various screen readers.

[00:01:36] You can read more about this on my blog at lolaslab.co, and the link will be in the show notes. If you enjoyed the podcast or care about this work or want to support me, you can sponsor me at give.lolaslab.co. Sponsoring independent technologists like myself helps us contribute to the web platform.

[00:01:59] Now, let's get into the episode. As I said, this month we're talking accessibility. Hidde De Vries breaks down the new Popover web feature and which accessibility considerations are included and excluded.

[00:02:17] Okay. I am here with Hidde De Vries, and today we are gonna be talking about Popover accesibility. What's possible, what's not possible, what do we get with using Popover? Hidde, thank you so much for joining me today.

[00:02:33] Hidde: I'm so excited  to talk about this.

[00:02:35] Lola: So Hidde is a freelance front-end accesibility and design spec design systems specialist, excuse me, and has previously worked for the Dutch government, the W3C, Mozilla, sanity.io, Is there anything I'm missing in that intro of you?

[00:02:54] Hidde: No, they're all correct.

[00:02:55] Lola: Nice. So before we get into the main accesibility side of popover, let's give our audience just a brief overview of some of the like key phrases and keywords we're gonna be using in this discussion. Can you give a very brief overview of popover? What is popover? It's something that's quite new to the web, so what is it?

[00:03:19] Hidde: Yeah, popover is a new attribute in HTML that you can chuck onto elements and that turns them into a popover, so you add the popover, attribute it becomes a popover. And then you get some stuff in the browser that you can do with the popover. And the goal of it is sort of like the main features that you get are that the browser can take care of dismissing them and also can put your popover in the top layer.

[00:03:46] So Pop popover is something that lays on top of other content. It's content that lays on top of other content and to make that easier for you, it puts it actually in its own layer. So the layer is separate from your main HTML document, meaning that if you make something a popover you can be very sure that when it's shown it's on top of everything else that's on the page.

[00:04:07] Lola: Right.

[00:04:08] Hidde: And that's cool. Like it's a new feature that that has been worked on in the Open UI Community Group and it currently shipped in all the major browsers.

[00:04:17] Lola: Nice. So when you describe that though, that sounds like a dialogue or a modal to me, what's the difference between popover and a modal or dialogue or the dialogue element in HMTL?

[00:04:30] Hidde: Yeah, that's a, that's a fun question that I struggled with myself for a while because at some point we were thinking of making it its own element and it kind of had some different variations. And these, these words are also really closely related. So the, the main difference I think between a popover and a modal is that the modal is a characteristic of an element.

[00:04:52] So an element can be modal. So you could have dialogues that are modal and you could have dialogues that are non

[00:04:57] Lola: Non-modal. Yeah.

[00:04:59] Hidde: So yeah, they're that, that's kind of a characteristic and I'm the difference really, like a dialogue and a popover. Popover is anything that lays on top of other content that could be a dialogue, but it could also be another type of, of content that's on top of our content, like a tooltip or a menu or like a listbox. So popover is a wider group of things, and, and dialogue is a specific type of popover.

[00:05:21] Lola: Right. And from my understanding, when we talk about popover, we are talking about an attribute specifically. We're not talking about an element in the way that dialogue may be an element, and we're not talking about the state of something like modal. Or, you know, a characteristic or like modal is a characteristic.

[00:05:42] It's an attribute that you can use with JavaScript to say, this is a popover, this is the popover target and this is what I want you to do with those things.

[00:05:52] Hidde: Right

[00:05:53] Yeah. exactly.

[00:05:55] Lola: Cool. Okay, so there's two other things that I want us to define. Just so that our audience is all on the same page, what is the accesibility tree?

[00:06:07] Hidde: I like to explain it as like, it's like the DOM tree, but then it's like it's derived from the DOM tree. But it's a tree of all the information that's relevant for accesibility for assistive technologies to understand what's going on your page. So it, like, DOM tree has everything that's on your page, but accesibility tree, just accesibility, relevant information like the stuff that gets exposed to assistive technologies, basically.

[00:06:32] Lola: So I guess that would be things like, things that have aria roles on them. It would say the actual aria role itself, things that have names on them or if name is derived from content, the names of those elements, things like that, w hich the assistive technology can interpret and understand how the page is laid out in a similar way that the browser understands how the page is laid out based on the DOM

[00:06:57] Hidde: Yeah. Yeah. I like the do it's kind of the computer stuff, right? So if you maybe change the name through JavaScript or something, it will have like the latest information on what everything is on the page.

[00:07:07] Lola: Cool. And then finally, what's the screen reader?

[00:07:11] Hidde: Yeah, that's a piece of software that will read out stuff that's, that's on your page. It will read out everything on your screen and you can use it like to browse webpage. So go to like specific parts of, of a webpage. Like you can go like, I wanna see all the headings, or here are all the headings, or I wanna go between different sections of the page.

[00:07:29] And the screen reader will kind of read out for you and, and let you browse if you can't see the webpage.

[00:07:36] Lola: Yeah.

[00:07:36] it's mainly for people who are either fully blind or have low vision or other visual issues. And it's it's one of the main ways that visually impaired people use computers, but also the web. And so this is why accesibility is really important because we wanna make sure that we are including users of not just screen readers, but also other assistive technologies.

[00:08:02] Even keyboards, right? Keyboard access is a really big deal. And it's something important to think about when we're creating websites and web experiences. Cool. Thank you for those descriptions and explanations or rather definitions. When we are talking about popover, as I mentioned, the popover is an attribute, but it doesn't have a built in role such as like, you know, other elements because it's an attribute.

[00:08:30] And so its purpose is to augment the behavior of the element it's applied to. How does this impact the accesibility of the popover or the popover target?

[00:08:42] Hidde: Yeah, just, just that behavior. And, and that means that there are certain things that you'll need to do yourself, like, like the role when we kind of first talked about popover. We still called them popup at the time thought of making it a popup element and be like, oh, cool, we'll just grab the role in aria that is for popups.

[00:09:00] But it turns out there's a bunch of different roles with different behaviors associated that, that could be popups or, or popover, like, like list boxes and menus and, and dialogues. So we kind of learned that there is not one role that would work for all the things that need popover behavior. So yeah, the fact that it's like its own attribute means it's just gonna do behavior like the tabbing next or content editable attributes.

[00:09:27] And that means that you'll still need to add a role to the element yourself if there is a relevant one. So if you're building a menu, it makes sense to add that menu role. It's not gonna be added for you automatically.

[00:09:40] Lola: But there are accesibility things that are in kind of included in popover right So like what accesibility semantics does popover expose

[00:09:50] Hidde: Yeah, the major one is, aria-expanded So like when there's a button that opens a popover. When the popover is open, that's the state of that button. So the, the button is expanded, like when there's little popover that floats on top of the, of the button. That button needs to expose that it is expanded or not expanded.

[00:10:09] So that's information that, that will be set by the browser. So it's basically like the aria-expanded attribute, but then it's managed inside of the browser. You can like find it in the accesibility tree. You won't actually see the attribute in the, in the DOM. But that information is, is in the accesibility tree for popovers that are associated with a button.

[00:10:29] That's one of the, the major ones. Another thing that gets exposed is aria-details. And that is a relationship that I actually learned about in a lot more detail. No pun intended, when I kind got this article written about aria-details like how, how this thing works because the.

[00:10:47] I knew about aria-described-by and like aria-labeled-by, where you kind of give a label a name to an element or a description. aria-details is a bit different. And the way I like to think about it compared to the aria-described-by, a description is like a long string of text that you could like read out at once.

[00:11:05] Lola: Yeah

[00:11:06] Hidde: So like that's, you can point an element and say, that describes my other element.

[00:11:11] Lola: Yeah

[00:11:12] Hidde: Details, you're basically like, here is another structure like a a bit of DOM that is relevant for this element that has more details and you can go there and explore it because it's more complicated than just a string of text.

[00:11:24] Like that could have headings or links or buttons inside of it. It doesn't make sense to read the whole thing out. It makes sense to go there, have a look and come back. So like there's structure involved in the, the details that come with

[00:11:37] Lola: Interesting

[00:11:38] Hidde: the button basically.

[00:11:40] Lola: So okay let me just like make sure I'm understanding this You've got aria-details which in and of itself is another piece of structured I guess data Would that be fair to say where you would have h HTML elements with them within them as well

[00:12:00] Hidde: Yeah. So where with aria-described-by you say like that element is a description, with aria-details like this is more details and it can be any kind of structure. It could be one or two words, but it could be like more complex stuff with interactive elements. And usually popovers are like that, right? They'll have a close or they'll have like a form inside of them if you wanna go real complex.

[00:12:23] But they can have like anything inside of them.

[00:12:27] Lola: And so how is aria-details populated

[00:12:29] Hidde: So it's basically the, there's a relationship between the button and the popover that is opened. And you could think of it as like inside of your DOM, the button could have an aria-details attribute that points to the ID of the, of the popover. but what happens when you use popover like that, that will actually happen automatically.

[00:12:52] So that aria-details relationship is set between the popover content and and the button just like the aria-expanded state

[00:13:00] Lola: Yeah

[00:13:01] Hidde: well.

[00:13:01] Lola: Does that mean then that the popover and its target have to be siblings or children like what's the proximity they have to be in together on the DOM If aria-details is gonna be populated by I guess the target

[00:13:17] Hidde: Yeah, that's a, that's a great question. 'because usually when you have a button that opens a, a popover, you want 'them to be close by, or ideally siblings, so that when you open the popover and you press the tab key, the next thing you end up in is the, the popover, right? You don't want somewhere sitting at the end of your DOM, which is where they often are for reasons like layering and, and stuff like that.

[00:13:41] The cool thing with aria-details is that it doesn't matter where your details are because that relationship is set. So when you press the tab key after opening an aria-details associated popover, the next step that would actually be inside of that popover And the way it works in screen readers is that a screen reader would have a, a shortcut to go into the details content.

[00:14:05] So it would be there are details about this button, do you want to go there? And it doesn't matter where they are, if aria-details is supported, and that's. Tricky. not supported everywhere.

[00:14:16] The recommendation still is to make sure they are they have proximity that they are siblings or close enough so that people can get to the, the content easily.

[00:14:28] Lola: Right And so because they're not supported everywhere that I think aria-details isn't supported in Safari but it is supported in Chrome Edge and Firefox Do screen readers interpret aria-details the same way then like what happens in voiceover in safari when you've got popover

[00:14:51] Hidde: Well, the aria-details stuff isn't exposed. So where in Chrome and Firefox you would get information about, Hey, there's, you're on a button, there are some details. Do you wanna open them? There's some information. They click a different per browser, right? They are per screen-reader, like they, they expose 'em in different ways and they might have different shortcuts as well.

[00:15:12] In Safari, you just wouldn't get that information. So you don't know that there is details available. You might get other information 'cause it's still a button, so you could press the button and then maybe go to the popover. But it wouldn't announce it as like, Hey, I've got I've got details here.

[00:15:28] So yeah, my hope is that they will implement it.

[00:15:32] Lola: Same and I guess my I guess the responsibylity then is on the web developer to make sure that they're considering screen reader users when it comes to popover especially in Safari especially because of Safari not supporting like the accessibility freebies that you get

[00:15:53] Hidde: Yeah, as I understand it, it's got to do with like, already there's not being supported anywhere in, in voiceover, so they just don't have that, that concept

[00:16:02] Lola: yet Yeah

[00:16:03] Hidde: it. And I guess when they do add it to voiceover, it would be trivial to also add it to, to popover. And we, we might hear about this probably when it happens. The Apple engineers are not super open about when they edit, but it might, might happen at some point. Right. So I'm, I'm looking forward to that. 'cause it would, it is nice to have like a shortcut to go to to details and to be able to have your details anywhere in in the page, but have some cool, like, design features, like footnote that's related to, something or like it's at the bottom of your page, but you can go there and kind of go back and stuff like that.

[00:16:41] Yeah,

[00:16:43] Lola: Cool So there are different ways then that popover manages auto closing and like dismissing the popover And I think that's one of the main highlights of popover of the popover attribute Can you tell me what the difference is between like popover equals manual Popover equals auto and I think there's a popover equals hint as well

[00:17:06] Hidde: Yeah true. So the. You can do a popover on its own and then it will become auto. So it's kind of the basic one. What that will do is it will light dismiss so when you click outside of it, it goes away and it will close other popovers. If you don't want any of that, you can send it to manual to do popover equals manual.

[00:17:25] And then you can decide whatever you wanna kind of do and you do that manually. That's currently used by github.com when they show Tooltips on hover. Because there is no hover trigger yet that's being worked on, but doesn't exist yet. So they use regular popovers that they trigger themselves on hover.

[00:17:45] So they get the benefit of the top layer behavior. So the element goes to top layer. That's the thing they want for their their tool tips. But then the hover behavior, they, they edit themselves. So manual is perfect for. If you know very well what you want to happen and how the dismissing should work and, and stuff like that, maybe you want it to go away on scroll or something like that.

[00:18:04] And yeah, can implement that with manual.

[00:18:08] Lola: And then what about popover Hint

[00:18:11] Hidde: Yeah, so that's a new one that's being worked on. And it's supposed to be for tooltips.

[00:18:16] Lola: So basically in the way that GitHub is using Popover manual this is kind of like the evolution of that

[00:18:23] Hidde: Yeah, it would be the standard way to, to do that kind of thing. It's a little tricky because if it's something that shows on hover. Well, with both work and accesibility, we know that not everyone has a mouse, right? So how do you expose it in a way that's not annoying? Like do you do it on like a press?

[00:18:42] But then when you press a link, usually we show a context menu as well. So you end up in kind of weird territory where it's really hard decide like what's ideal. How do we also know users

[00:18:52] keep the functionality that they're used to.

[00:18:55] Lola: And you mentioned there about not everybody has a mouse So how does Popover manage keyboard focus

[00:19:02] Hidde: Yeah, it's really cool. You get free keyboard behavior with it. So one of the basic things that it will do is you open the popover and then when you press escape, it will close. It will also return the focus if it was inside of the popover, to the element that invokes it, if the browser knows about it, right?

[00:19:21] So these are all heuristics that will happen, if possible, if relevant et cetera, et cetera. But yeah, it will return the focus, which is nice. Like I've written a lot of popover implementations before the popover attribute existed, where I had to like, oh, where's my element? I need to find it.

[00:19:37] Lola: Right Yeah

[00:19:38] Hidde: You can forget about it. Or someone can break it. So it's nice that that happens. Another thing that happens is that the next tab press will take you into the popover when you open it which is kind of cool. And that would, that's kind of related to what we were talking about before, that your popover content could be in a sibling, but it could be somewhere quite far away. Wherever it is, tab will kind of go into popover first on the browser.

[00:20:04] Lola: Oh

[00:20:04] Hidde: Fix it into the tab order for you while it's open. So

[00:20:08] So

[00:20:08] Lola: So I have a question about that because as someone who doesn't use keyboard to navigate often I mean I use tab now and again but I definitely am mainly a mouse user or a track pad user Would that not be disorienting If I think I'm tabbing somewhere visually and then I when I hit tab I go to somewhere else in the page

[00:20:33] Hidde: Yeah, I think the assumption is that visually, 'cause you've just opened the popover, you've clicked on it, that popover shows near the place you've clicked like near the button.

[00:20:45] Lola: I Yeah

[00:20:45] Hidde: That it would kind of make sense that it goes in there. But yeah, it really depends on how it was designed, right? How, what, it visually looks like if, if that actually makes sense. Usually yeah, your content would be close by to your button or something.

[00:21:01] Lola: And so that's kind of like another thing that's like it's on the web developers and the designers to kind of take those things into consideration when they are designing right So that it makes Visual sense when yeah

[00:21:16] Hidde: Yeah, it's actually something I found about Popovers is that. Where's like a modal dialogue. If you open it, it makes sense put it full screen or like in the middle

[00:21:24] Lola: of the

[00:21:24] Hidde: page because it's the one thing that people can interact with. Whereas like popovers, I almost always want 'em to be where the popover opener was.

[00:21:34] So where like the, the button that opened it, not all popovers have buttons. Right? You could have a, dare I say a toast message that goes like in the right bottom corner. They might be focused 'cause they are on top of other content and could be the top layer, could be nice. But they usually don't have buttons that open them, so yeah.

[00:21:54] But if they do then you'll get that, that focus behavior for free. So this is one of those things that depends on their being an associated button basically.

[00:22:04] Lola: Right Yeah And it's I'm happy that you kind of made that distinction between popover and modal again like this is another way they differ even in terms of implementation. When we are thinking about popovers then it kind of seems like we're more thinking about things like tooltips things like toasts things like I don't know maybe even menus I guess to a certain extent depending on how you wanna implement. We're not necessarily thinking about you know those big ad banners that you get when you go on you know every single I guess news website nowadays you know we're we're not talking about like things like that

[00:22:41] Hidde: I think we should agree here that we should never tell the marketing and add people about popover.

[00:22:47] This is our secret as

[00:22:49] Lola: This our thing Yeah this is our thing Cool And so what doesn't popover do then What is it not for I guess we touched on that a little bit

[00:22:59] Hidde: I think one of the things I always try to explain when I talk about popover accesibility is that like, yeah, you do get a bunch of things that are built in. so people would market it as, oh, it's good. It's got accesibility built in.

[00:23:11] Lola: Mm

[00:23:11] Hidde: But you know this, right? accesibility is really wide. There's a lot of things need to do for accesibility.

[00:23:17] Like it's not gonna work with forced colors mode automatically. Or like you zoom in, do stuff for that or like make your colors have enough contrast. Or like, there's some things that we always do for accesibility that. Would be weird if Popover would take care of them. But important to kind of realize that Popover just does those things.

[00:23:39] It does the aria-expanded, it does aria-details where that's relevant. So where there is no sibling situation, but where the, the content is further away it does a bunch of those kind of things and then it doesn't do anything else. So everything else that you need to do to make your thing accessible is still something that you'll need to do manually.

[00:23:59] Lola: Yeah And that you need to like consider

[00:24:02] Hidde: Yeah.

[00:24:04] Lola: And just to come back a bit because I did wanna talk about this but I just didn't know how to phrase this question So I'm just gonna give you free rein here Talk to me about popover groups

[00:24:14] Hidde: Oh yeah. So there if you don't add a role to your popover, then it still makes sense to have the content contained by something. So what the browser will do is it will add a, a role of group to your pop for content for you if there is no role. So it's kind of like a fallback role so that there are boundaries and I'm not, I don't know enough about screen-readers to know exactly like what that helps.

[00:24:41] But as I understand it the screen-reader, it's nice, like if your content is kind of contained as it is visually, right, it's, that one thing is a popover, so it makes sense for it to sit in in one group and be one zone within the page. And it would have that if it was a menu or it was a list box or it was a dialogue.

[00:25:02] But if it's none of those things or it just don't add all, then yeah, that's the full act. We'll make it a group for you.

[00:25:07] Lola: And what's the benefit of that then for accesibility

[00:25:12] Hidde: Yeah, that it provides boundaries like that the content is contained in something. This is what I've been told, but I, I don't know exactly how that helps if you're using a screen reader, but maybe it's gotta do with like, but I'm kind of guessing here, like if you're, that it knows when you're tabbing in and out of it and, and things like that, that

[00:25:32] Lola: Right Yeah

[00:25:33] Hidde: can make that happen more easily.

[00:25:35] But I'm, I'm not entirely sure, but it's like an another kind of thing where we can automatically add that to kind of make your accesibility to you slightly better based on, on heuristics and kind of what, what Yeah.

[00:25:51] Lola: Yeah Okay That makes sense to me we're gonna go into the next part of our episode which is patch notes from the future But before that a quick break

[00:26:03] This is just a quick break to say if you are enjoying this episode, don't forget to share with your friends and communities or leave a review where you listen to podcasts. Thank you. Now back to the episode.

[00:26:18] Right We are back and now we are gonna go into patch notes from the future. This is a game that we play where you need to tell me one browser feature or web API that you'd bring back from the past one current feature that you wish never existed or that you would change and an invented feature which can be real or absurd that you'd create if you could So let's start with one browser feature or web API that you'd bring back from the past

[00:26:49] Hidde: Yeah. In the past, websites used to be so much more whimsical. I was watching my friend Sophie Kunin talk about. Websites, what they used to be like and the kind of things that people would do on their websites and made fan sites and just people went all overboard with like different kinds of features.

[00:27:06] And in that realm, I think I love to have marquee back was a feature I used a lot on my earlier work where I just had like a Harry Potter fan side and it would just like have a marquee with like random things in there and it could change the speed of it. And the browser would automatically do that for you.

[00:27:23] Lola: Did you have a piczo growing up We had so this is 2000 and between 2004 and 2006 I wanna say there was this kind of like website generator kind of thing where I it's not like a website generator and like how Squarespace or those things are It was just a place where you could put HTML and make it sparkle make it glitter make it shiny everything would blink Everything was like You know moving It was very chaotic but it was so fun It was so fun to build your website and have like all the colors of the rainbow do It was overwhelming if I'm honest like but fun you know

[00:28:06] Hidde: You make very like, stress inducing websites and like

[00:28:09] Lola: Yeah

[00:28:10] Hidde: followed around by random text and stuff.

[00:28:13] Lola: yeah

[00:28:14] Hidde: It was a wild time, but maybe a lot of the new browser features are very like business oriented. you know, we can, we can use some whimsical ones.

[00:28:22] Lola: We should bring whimsy back We definitely should Cool And so what's one current feature that you wish never existed or that you would change

[00:28:31] Hidde: yeah.

[00:28:32] So you, you told me what that question would be before and I was like, Hmm. I find it right now. The longer I work in web standards, the more I realized, like, how. How carefully everything is thought out. Like, I don't know if there's things in the web platform that really shouldn't be there. like the CSS working group has this list of, of mistakes that they admit having made and that they would do differently if they

[00:28:56] Lola: Yeah

[00:28:57] Hidde: So yeah, that they exist, but, but for me, I feel like a lot of the, the web features are. are just great and I want more, more features maybe,

[00:29:06] Lola: But I don't

[00:29:07] Hidde: know if I would get rid of any. Also 'cause I like backwards compatibility and kind of making sure that none of the old web breaks. So, I wouldn't change any.

[00:29:19] Lola: It's really cool that the CSS working group has that list I didn't know that I think like more working groups should

[00:29:26] Hidde: Yeah. Yeah, I think we could do one for aria.

[00:29:31] It would really interesting. But maybe CSS has it also 'cause they, like when it, the first version of CSS was written like in a few weeks time. In the south of France. many people were like, let's just see if this works.

[00:29:45] And I think some of the things are from that time where, yeah, they were like, oh, this would probably be great. Yeah

[00:29:52] Lola: And then ended up not being so.

[00:29:54] Hidde: I guess aria-labelled-by could go on that list 'cause of the spelling. Like it uses the British spelling instead of the US

[00:29:59] Lola: The, yeah, it is. Even though I am biased and I am definitely in favor of the British spelling of things, I do understand the rest of the web is spelled in the American way. You know, so it just for consistency sake, I understand the, you know. The kind of like, aim to get rid of that. I think that's been discussed about actually in the aria working group about de deprecating one of those, the, well I say one of, but the British spelling.

[00:30:29] Hidde: The British one will be.

[00:30:30] Lola: Yeah. that's the one that's going

[00:30:33] Hidde: Yeah, same In the CSS, like they have both British and US spelling of gray if you wanna do colors. Yeah,

[00:30:40] Lola: Well that's funny because color is still spelled the American way.

[00:30:43] Hidde: yeah,

[00:30:45] Lola: Color is still spelled without the U. So, and then one invented feature, real or absurd that you create if you could.

[00:30:56] Hidde: yeah. I have a whole list I guess,

[00:30:58] Lola: of like different

[00:31:00] Hidde: things that would be cool to add, but they're also kind of around this idea of, it would be cool to have more elements in HTML that resemble kind of things that exist in aria and then manage the aria automatically. Or like as far as that's possible, right?

[00:31:15] Because. As I learned with popover there's a lot of heuristics and you don't really know what people want and can't just guess what the role is. If you just have an element that someone used, you can't just know what role they intended to have. So there's some, some caveats, but I feel like there were a lot of opportunities for bringing elements to HML that are not HML elements yet, and that are kind of often used.

[00:31:40] So that it's easier to do them accessibly so that a lot of the accesibility might be abstracted the way or like focus might be managed, that kind of thing. So I'd love to have more of that. I'm thinking things like tabs, but they are really hard. We tried at Open UI It's really hard to kind of find one set of tabs that would work in all cases and on all screen sizes and it's really messy.

[00:32:03] But I think there are, there are a number of other elements where it be cool. Actually, the open ui, we're looking at menu at the moment

[00:32:08] Lola: Oh okay

[00:32:09] Hidde: make a thing. It's already a thing in HTML, but it's not the correct thing, if that makes sense but yeah, lots of those kinds of things I feel like.

[00:32:18] Having components that exist in design systems today have them available in HTML so that if we had accesibility bugs, they would be on the list of browser engineers. And I know browser engineers are really busy, but there's only like a couple hundred of them. If I, I don't dunno if I'm estimates correctly, say there's a couple of thousands, very few compared to the millions of web developers who could make.

[00:32:41] More mistakes. So I love like the bug to only exist in the code base of the, the, of the browser. 'cause there's only like three or four engines maybe a couple more, if we count different versions. That's so, so much less than the amount of websites that there are. So I feel like it could be really big for accesibility to have,

[00:32:59] Lola: Yeah.

[00:32:59] and I mean there's, there's like three or four engines and then those engines all use the same test suite, which is web platform tests anyway. So, you know, fixing a bug in one engine really means fixing a bug in all the engines when 'cause of the way you have to fix bugs, which is you have to write the web platform tests for it.

[00:33:22] Which all the engines, you know, implement.

[00:33:25] Hidde: That's brilliant. Yeah, so we could fix it in platform tests and be done

[00:33:29] Lola: yeah '

[00:33:30] Hidde: cause it's hard like to do accessibility of those kind of components. Like we might disagree a lot, but then once we agree, we only need to agree in that one place and that, that feels really attractive to me.

[00:33:40] Lola: Yeah. That's interesting. Well, thank you Hidde. Is there anything else you wanna tell the people? Where can they find you on social media? Your blog? Are you talking anywhere soon?

[00:33:53] Hidde: Yeah, I'm on hidde.blog where I kind of do longer writtings and I'm like, on Mastodon and bluesky. And I am going to be talking soon about sustainable web development at a Dutch government design, international Design in government conference in the Netherlands, and pioneers in Bristol later in the year.

[00:34:14] Yeah, look forward to meet anyone who listens to this.

[00:34:18] Lola: Yeah, I will be adding all your socials in the description. I will also be adding Hidde's blog posts on popover accesibility, which is a very thorough, in depth view on things in the description as well, as well as Scott O'Hara's blog post about popover accesibility, which I think acts as a companion piece.

[00:34:38] Scott also co-wrote Hidde's blog post as well, so. You know, we're bringing the forces together basically. Thank you so much for joining me Hidde. I really appreciate you giving up your time.

[00:34:48] Hidde: Thanks for having me.