One of the premises of the new popover attribute is that it comes with general accessibility considerations “built in”. What does “built in accessibility” actually mean for browsers that support popover?
See also: Scott's post Popping preconceived popover ponderings and Hidde's talk on popovers, and other posts about popover semantics, positioning popovers and the difference with dialogs and other components.
About this post
NOTE: except for this note, this whole post was co-written with Scott O’Hara (thanks Scott!). See also Scott's post, popover accessibility and his post Popping preconceived popover ponderings. Whether you're a developer, designer or accessibility specialist, hearing “accessibility is built in” probably makes you want to know what exactly is built-in. For popover, this actually changed quite a bit over time, after discussions at Open UI and with WHATWG. At first, the plan was to introduce a popup element with built-in roles. Later, an attribute ended up making more sense (more on that in the post). For that attribute, and thanks to the great effort of Scott and others, some “accessibility guardrails” have now emerged. And they shipped in most browsers. I hope this post helps you understand better what accessibility is “built-in” when you use popover, and what is not.
In this post
- Accessibility semantics
- What browsers do (aria-expanded, aria-details, group, keyboard accessibility)
- What browsers don't do
- Conclusion
Accessibility semantics
The “built-in” accessibility of popover is in the addition of guardrails: browsers try to improve accessibility where they can. These guardrails exist mostly in the form of browsers augmenting accessibility semantics. Before we get into what those guardrails are, let's clarify what that term means.
Many features of HTML have some amount of accessibility semantics associated with them - e.g., roles, states and properties. This is information that a web page exposes, which browsers then pass on to platform accessibility APIs. They do this, so that assistive technologies can build UIs around them (see: How accessibility trees inform assistive tech). These semantics are sometimes baked into native HTML elements. For instance, headings and lists have implicit roles (heading and list, respectively). Other elements, like the checkbox input type, have an implicit role as well as additional states and properties. Developers can use HTML elements with such “built-in” semantics. But they can also set, overwrite and augment accessibility semantics more directly in their HTML structure, using WAI-ARIA.
The thing with the popover attribute is that it doesn’t have a built-in role. After all, it’s not an element. Its purpose is to only add “popover behaviour”, as discussed in Popover semantics. In that sense, popover is a bit like tabindex or contenteditable. These attributes also add behaviour: tabability and editability behaviours, respectively.
A major reason for this choice is that there are a number of components that exhibit popover behaviours. Examples include menus, “toast” messages, sub-navigation lists of links and tooltips. You can use popover on a specific element, then it will get that element's role. Or you can use it with a generic element, and add a role that best matches what you are building.
So, while the default role is ‘generally’ not handled by the attribute (more on that later), there are other semantics (properties and states) that the attribute will expose. Browsers can take care of those with some degree of confidence.
What browsers do
There are two semantics that the browser should take care of when you use popover, and its associated popovertarget attribute. Additionally, there is some keyboard focus behaviour that may also be handled automatically, depending on the type of popover you are using.
The aria-expanded state
First, aria-expanded. This state is exposed on the element that invokes the popover, currently limited to buttons (for a variety of reasons that would require a whole other article to talk about - so this is all you get right now). When a popover is invoked by / associated with a button with the popovertarget attribute, the browser will automatically convey whether the popover is in the expanded (rendered) state, or if it is in the collapsed (hidden) state. This is implemented in Edge, Chrome, Firefox and Safari.
For the following example, the ‘heyo’ button will automatically convey whether its associated popover list is in the expanded or collapsed state, based on whether the popover list is invoked as a popover.
<button popovertarget=p>
Heyo
</button>
…
<ul
aria-label="Heyo subpages"
id=p
popover
></ul>Note: the state won’t be applied if script, rather than the declarative attribute, does the opening on click of any button (or any other element). Needless to say: it also doesn’t work if there isn’t an invoking button, for instance, and script invokes this popover (because in that case, there isn’t any expanding going on). Additionally, if you force open your popover using CSS display block, then it will not be rendered as a popover - and thus the button will still communicate that the “popover” is in the collapsed state. Also, if you’re doing that - forcing your popover open with CSS - maybe you have some things you need to reconsider with your UI.
The aria-details relationship
When the popover doesn’t immediately follow its invoking button in the accessibility tree, browsers are supposed to create an aria-details relationship on the popover’s invoking button with its associated popover. At the time of writing, this is implemented in Chrome, Edge and Firefox.
For instance, in the following markup snippet an implicit aria-details relationship will be made with the button that invokes the popover, because the button and the popover are not immediate siblings in the accessibility tree.
<button popovertarget=foo>something</button>
<p>...</p>
<div role=whatever popover id=foo>...</div>
Similarly, an aria-details relationship will be made with the next markup snippet too, because even though the popover and its invoking button are siblings, the popover is a previous sibling to the invoking element, and it might not be understood which element is the popover, because it doesn’t immediately follow the element that invoked it.
<div role=whatever popover id=foo>...</div>
<button popovertarget=foo>something</button>In contrast, the next two examples have no aria-details association because that would be unnecessary. For the first, the popover is the immediate next sibling in the accessibility tree (note divs are generic and often ignored when they do not provide information important to accessibility). For the second, the button is a descendant of the popover, so browsers do not need to tell users that the button they are interacting with is about the context they are within. That’d be silly.
<!--
example 1:
popover immediate sibling in acc tree
-->
<button popovertarget=m>something</button>
<div class=presentational-styles-only>
…
<div role=menu popover id=m>...</div>
</div>
<!--
example 2:
button descendant of popoover
-->
<dialog popover id=d>
<button popovertarget=d>close</button>
…
</dialog>
For more information on how aria-details works, check out the details in the ARIA spec.
Note: aria-details is often confused with aria-describedby. That makes sense, “details” and “descriptions” are very similar. However, these two properties expose different information. aria-describedby takes the associated element’s content, flattens it into a single text string, and exposes that as the ‘description’ or ‘hint’ of the element which the attribute is specified. In contrast, aria-details only informs a user that there is additional information about the current element. That might not seem useful, until you know that screen readers largely provide quick-keys to navigate to and from that associated element which provides the details.
At the time of writing, navigating into the referenced content using quick-keys is supported by JAWS and NVDA (release notes), but not VoiceOver.
Here’s a quick demo of that with JAWS 2023 in Edge 124. JAWS lets us jump to the details content if we press Alt + Ins + D:
In NVDA (2023.3.4), tested with Edge 124, it works slightly differently: when you press the shortcut (NVDA + D), we don't jump to the details content, but it is read out after the shortcut is pressed:
(see demo on CodePen; note: announcements and shortcuts depend on the user's settings, versions, etc)
In the following demo, you can see how the aria-details relationship works between popovers and their invokers (in JAWS 2023 with Edge 124):
(video contains screenshot of code, see demo on CodePen)
In summary: the aria-details association is not announced by JAWS when we focus the invoking button for the first time. This is because the corresponding popover is hidden, so the association isn't made yet. After we open the popover, JAWS announces the button's “has details” association while it is open, to hear it we navigate away and back. This is also how it works in NVDA, which, in addition, also requires you to switch to forms mode to actually hear the relationship announced.
Warning: even if the aria-details association is implemented, it may not be completely ironed out in how the UX behaves for people. For instance, there isn't currently a way for users to find out about the details relationship once it is established, like when the popover opened. It requires for the user to move away from the button and return to it, at which point the relationship is announced. Maybe it would be helpful if the browser would fire some kind of event, to let AT like JAWS know that an element representing details has appeared.
We mention this not to deter you from using popover or to indicate that anyone is doing something “wrong” here. Rather, this is a relatively new feature that people still need to figure out some of the UX kinks around. Feedback is welcome, and to help ensure the best UX is provided, please reach out to the necessary browsers / AT with your thoughts.
The group role
As mentioned above, popover can be used on any element, including elements that don’t have a built-in role, like div. But even without a role, it’s likely that the contents of a popover form some kind of meaningful whole. This is why in Chrome, Edge and Firefox, a role of group is automatically added to popovers if they would otherwise have no role, or a role of generic (for instance, divs and spans).
The group role is added, so that assistive technology can have the option to expose the boundaries of the popover that is being displayed. This can be important to users, because a popover is a behavior and visual treatment of its content. How is one to know where such content begins or ends if it doesn’t have boundaries to expose?
It’s important to know that an unnamed group is often ignored by screen readers. This is because otherwise the Internet would be riddled with unhelpful “group” announcements. (See also why Webkit made the decision to remove list semantics from lists that have been styled to not look like lists. These topics are related). Here though, it again comes down to what assistive technology wants to do. By exposing the group role for the popover, now the element can be named by authors, which will force the group role to be exposed in most cases. Then, if AT decided they want to do something special for popover groups, they now have the opportunity to do so.
Keyboard accessibility
One more aspect of “built-in accessibility” that browsers do for your popover, is take care of some keyboard behaviors.
Moving focus back to invoking element
Edge/Chrome, Firefox and Safari will all return focus to the invoking element when you close the popover (only if you are inside of it). This is useful, because if focus was on an element inside the popover, the default would be to return focus to the start of the document. Various groups of users would get lost, increasingly so on pages with a lot of content. Moving focus back to the invoking element helps ensure people can quickly return to what they were doing, rather than spending time having to re-navigate to where they think they were last.
Popover content in tab order
Desktop browsers also do something else: they add the popover content into the tab order just after the invoking button. Even if that’s not where the popover is in the DOM.
Imagine this DOM structure:
<button popovertarget=p>Open popover</button>
<p>content… content… <a href="#">link 1</a></p>
<p>content… content… <a href="#">link 2</a></p>
<div popover id="p"><a href="#">link 3</a></div>When the popover opens, and you press Tab, you might think you’d jump to “link 1”, the next interactive element in the DOM. Except, in desktop browsers, you will jump to “link 3” instead. The browser basically moves the popover content’s position in tab order to just after its invoking button. This takes it out of its expected position in the tab order. That improves the user experience, because it is likely that upon opening the popover, users will want to interact with its contents.
Keep in mind: browsers adjust the Tab order for instances like this, but they don't adjust the placement of the content in the accessibility tree. This is why the aria-details association was implemented. This special Tab order behavior helps ensure logical focus order for keyboard accessibility. However, we should still strive to make sure our popovers come after the invoking element in the DOM.
But since there will be times where the exact location of the popover in the DOM may be out of one’s control, this behavior is still quite welcome. For instance, if the popover happens to be far away in the DOM, having to go through the rest of the document before reaching the popover would be a nuisance. It would be highly unexpected and unwanted to have to navigate through all other focusable elements in the DOM, prior to the popover one just opened. WCAG 2.4.3 Focus Order requires focusable elements to receive focus in an order that “preserves meaning and operability”. This special browser Tab restructuring helps ensure that requirement can be met.
What browsers don’t do
We can keep this one short: the browser will not do anything apart from the behaviours listed above. Browsers will not add behaviors based on which elements you use or which role you add to them. The popover attribute is merely a first step for us to build new components.
Conclusion
The popover attribute provides a starting point for building popover-like interactions on the web. Browsers don't magically make your components accessible, that's not a thing. But there are some specific keyboard behaviours included with popover, as well as these semantics:
- In specific cases, browsers set the
aria-expandedstate and/or set thearia-detailsrelationship on the invoker. - Browsers apply the
grouprole to thepopovercontent if it doesn’t have a role of its own, so that assistive technologies can expose their boundaries.
Browser support note: at the time of writing, Safari only sets aria-expanded, not aria-details. It also doesn't add a group role fallback.
List of updates
- 15 March 2025: Added link to Scott's latest post and to my talk and posts for easier findability.
Comments, likes & shares (186)
Michelle Barker, Sara Joy :happy_pepper:, Sheldon Chang ????????, Baldur Bjarnason, Daniel Göransson, NekoOverflow, Florian Schroiff, Dr. Angus Andrea Grieve-Smith, Apple Annie :prami:, Joe Lanman, weilawei, CSS Café, Dave Rupert, Stephanie Eckles, Ville V. Vanninen, Curtis Wilcox, Scott Orchard, Brett Ritter, Heather Migliorisi, kolya, katherine, Roma Komarov, Sophie, Vincent Valentin, Bernhard :firefish:, Sarah T, Andrew Sutherland, Patrick Grey, bkardell, Luke, Simon St.Laurent, Samir Saeedi :firedoge:, Konnor Rogers, Tamas G, Megan Lynch (she/her), Bonaventure Software, Jason Neel, {sydney:webdev}, mj12albert, Pratik Patel, Seth A. Roby, Steve Bogart ????, Erik Pavletic, Manuel Matuzović, Krzysztof Jeziorny, Sha Razeek, Quentin Delance, .js, Stan Chang ????, Taiyo Totsuka :sabakan:, Eric Jonathan Martin, mkelandis, Philipp Tootloff, Fynn Becker, Zach Leatherman :verify:, Jeff Caldwell, Oskar im Keller, cincylee@mastodon.social, Anton ????????????????, Aaron In Iowa, Hamish Mackenzie, Frank // Mottokrosh, Mckensie parker, Adam, roycifer, Timo Tijhof, Callie ????️⚧️, Royce Williams, Cathal, Wubbels, Melanie, Ryan Trimble, Ana Rodrigues, Daniel Göransson, Robb, Luke, Curtis Wilcox, steve.rss, Dennis Frank, John P. Green, Vadim Makeev, Bart van de Biezen, Daniel Göransson, Jon, W3C Developers, Adam Argyle, Matthias Ott, Tyler Sticka and Punnamaraju Vinayaka Tejas liked this
Michelle Barker, Sara Joy :happy_pepper:, TheJen - Jen Wojcik, Sheldon Chang ????????, Baldur Bjarnason, keithamus, Ben Myers ????, Apple Annie :prami:, Joe Lanman, weilawei, Ayo Ayco, Dave Rupert, Patrick H. Lauke, Laura Langdon, Stephanie Eckles, Curtis Wilcox, hypebot, Thomas Broyer, Christian Puffer, Jeroen Zwartepoorte, Lachlan Ridley, Sophie, Bhupesh Singh, Sarah T, John Kemp-Cruz, Patrick Grey, Gustav Hansen, bkardell, Luke, Konnor Rogers, Drew Mochak, Thomas Rigby, Adrian Roselli, Tamas G, kazuhito, Krishna Jariwala, Jason Neel, {sydney:webdev}, Nolan, Pratik Patel, RT bot :verified:, Sylvain G., Eyal Eshet, just adrienne, Seirdy, Paul Kinlan, Manuel Matuzović, Svenja, Katja ｢Amethyst｣, Daniel, Pierre Spring, Stan Chang ????, Taiyo Totsuka :sabakan:, Devin Prater :blind:, Fynn Becker, Jeff Caldwell, Zach Leatherman :verify:, Ryan Mulligan, Hamish Mackenzie, Jake Gross, Kaveinthran, Åke Järvklo, Rob Whittaker :thoughtbot:, Timo Tijhof, Ana Rodrigues, Patrick Grey, Apple Annie :prami:, W3C Developers, Matthias Ott, Kaveinthran and Bhupesh Singh reposted this
Popovers are commonly positioned relative to their invoker (if they have one). When we use the popover attribute, anchoring is tricky, as these popovers are in the top layer, away from the context of their invoker. What options do we have?
See also: Hidde's talk on popovers, and other posts about popover accessibility, positioning popovers and the difference with dialogs and other components.
Basically, there are two ways to position popovers: one you can use today and one that will be available in the future. I'll detail them below, but first, let's look at why we can't use absolute positioning relative to a container shared by the invoker and the popover.
Not all popovers are anchored, but I expect anchored popovers to be among the most common ones. For popovers that are not anchored, such as toast-like elements, “bottom sheets” or keyboard-triggered command palettes, these positioning constraints do not apply.
See also my other posts on popovers:
Top layer elements lose their positioning context
One of the unique characteristics of popovers (again, the ones made with the popover attribute, not just any popover from a design system), is that they get upgraded to the top layer. The top layer is a feature drafted in CSS Positioning, Level 4. The top layer is a layer adjacent to the main document, basically like a bit like a sibling of
<html>.Some specifics on the top layer:
z-indexes in your document, top layer elements can't usez-index. Instead, elements are stacked in the order they are added to the top layer.<dialog>s withshowModal()andpopover'ed elements, currently.When I positioned my first popover, I tried (and failed): I put both the popover and its invoking element in one element with
position: relative. Then I appliedposition: absoluteto the popover, which I hoped would let me position relative to the container. It didn't, and I think the last item above explains why.In summary, elements lose their position context when they are upgraded to the top layer. And that's okay, we have other options.
Option 1: position yourself (manually or with a library)
The first option is to position the popover yourself, with script. Because the fact that the top layer element doesn't know about the non-top layer element's position in CSS, doesn't mean you can't store the invoker's position and calculate a position for the popover itself.
There are some specifics to keep in mind, just like with popovers that are built without the
popoverattribute: what happens when there's no space or when the popover is near the window? Numerous libraries can help with this, such as Floating UI, an evolution of the infamous Popper library.Let's look at a minimal example using Floating UI. It assumes you have a popover in your HTML that is connected to a button using
popovertarget:By default, browsers show the open popover in the center of the viewport:
The reason that this happens is that the UA stylesheet applies
margin: autoto popovers. This will reassign any whitespace around the popover equally to all sides as margins. That checks out: if there's the same amount of whitespace left and right, it element will effectively be in the center horizontally (same for top and bottom, but vertically).For anchored popovers, we want the popover to be near the button that invoked it, not in the center. Let's look at a minimal code example.
In your JavaScript, first import the
computePositionfunction from@floating-ui:Then, find the popover:
Popovers have a
toggleevent, just like the<details>element, which we'll listen to:In our
positionPopoverfunction, we'll find the invoker, and then, if thenewStateproperty of the event isopen, we'll run thecomputePositionfunction and set the results of its computation as inline styles.To make this work, I also applied these two style declarations to the popover:
margin: 0, because the UA's auto margin's whitespace gets included in the calculation, with0we remove that whitespaceposition: absolute, because popovers getposition: fixedfrom the user agent stylesheet and I don't want that on popovers that are anchored to a buttonIt then looks something like this:
See it in action: Codepen: Positioning a popover with Floating UI.
In the Codepen, I also use some Floating UI config to position the popover from the left. In reality, you probably want to use more of Floating UI's features, to deal with things like resizing (see their tutorial).
Option 2: with Anchor Positioning
To make all of this a whole lot easier (and leave the maths to the browser), a new CSS specification is on the way: Anchor Positioning, Level 1. It exists so that:
This, as they say, is rad, because it will let the browser do your sizing and positioning maths (even automatically- update 4 May 2024: looks like automatic anchoring was removed). It is also exciting, because it doesn't care where your elements are. They can be anywhere in your DOM. And, important for popovers, it also works across the top layer and root element.
Though popovers would get implicit anchoring, you can connect a popover with its invoker via CSS. To find out how all of this works in practice, I recommend Jhey Tompkins's great explainer on Chrome Developers (but note it's currently somewhat outdated, the editor's draft spec changed since that post, and has new editors). Roman Komarov covers his experiments and some interesting use cases in Future CSS: Anchor Positioning, and also wrote Anchor Positioning on 12 days of web.
The Anchor Positioning spec was recently updated, and is currently in the process of being implemented in browsers, hence the Option 1 in this article. But, excitingly, it is in the works. Chromium has already issued an intent to ship anchor positioning, and so did Mozilla/Gecko. The recent updates are still pending TAG review.
Wrapping up
So, in summary: if your popover needs to be anchored to something, like a button or a form field, you can't “just” use absolute positioning. Instead, you can use JavaScript (today), or, excitingly, anchor positioning (in the near-ish future, an Editor's Draft in CSS was published last year and a new version of that with new editors was released in April 2024.
List of updates- 6 May 2024: Added that Gecko intents to ship anchor positioning.
- 4 May 2024: Reworded to reflect that the editor's draft of the anchor positioning spec was updated (as editor's drafts are), is now different and not yet passed TAG review.
Thanks to Jhey Tompkins, Mason Freed and Keith Cirkel for explaining and clarifying some of this to me.@hdv @scottohara Daaaaang, I had no idea about any of this. Kudos to the two of you for such an excellent, helpful post!
Note when the post says ‘browsers’, not all guardrails are currently implemented in @webkit, I hope that this may still happen in a future update (cc @jensimmons @annevk)
@scottohara TLDR: browsers sometimes set`aria-expanded` state and/or the `aria-details` relationship on the invoker, sometimes add a `group` role to the popover, and add some keyboard behaviours.
You'll still need to take care of all other accessibility considerations for components you build with popover (eg literally anything but these specific things).
@hdv @scottohara thanks for these details! side note: the design of your blog makes it always such a nice experience for reading :)
@baldur thanks Baldur!
@hdv @scottohara
> Desktop browsers also do something else: they add the popover content into the tab order just after the invoking button.
I didn't know about this and wonder why only desktop browsers, mobile ones can have keyboards too (I confirmed it doesn't happen with mobile Safari and a Bluetooth keyboard).
@hdv @scottohara much thanks!
So for example for a menu button, is the popover attribute preferred over the ARIA APG pattern? Especially given its "built in accessibility".
@eyalito @scottohara if you'd like the menu to be definitely above other elements (by bringing it to the top layer) and/or want it to light dismiss, popover is the way to do it! (see https://hidde.blog/dialog-modal-popover-differences/ for intro)
you can use the attribute in addition to what you're already doing
Dialogs and popovers seem similar. How are they different?If you're not sure what popover is for, I've written this post about how popover is different https://hidde.blog/dialog-modal-popover-differences/
Dialogs and popovers seem similar. How are they different?Guten Tag! Guten Tag! ????
When will
align-contentwork in divs? Does the brand newpopoverattribute enhance accessibility? And why doesmargin: autowork on completely positioned components?Activate the Net Weekly tune and discover all of the solutions beneath. Get pleasure from!
However earlier than, the Net Weekly music queue is nearly empty. When you take pleasure in discovering and sharing new music, send me your favorite tracks to keep the Web Weekly jukebox playing.
Ellen listens to “Slut — If I had a heart” and says:
What number of Git instructions do you utilize commonly? I am the
add -p,commit,push‘n’pullkinda man. I’d even be capable to carry out a flowery rebase every now and then. However do I do know what I am doing? Not likely.How will you stage up your Git abilities?
The next speak collection is a trick rapid-fire. The movies have bounce marks so you may decide your matters. Extremely advisable.
Moreover, Julia Evans started digging into Git. As at all times, her articles are approachable but tremendous informative.
What are your favourite Git assets?
One thing that made me smile this week
How good are your eyes (or monitor) when differentiating colours? Discover out with
colormatch.Match colors
Two methods to compose elements
How do you lengthen your Frontend elements and make them configurable? Straightforward — slap an
is-activeorh-fullclass onto it and name it a day, proper?However the extra class modifiers you add to your elements, the trickier it will get. It is one in all these issues that turns into more durable with each change. Element and design system design is hard.
Kyle Shevlin’s put up on part compositions triggered some ideas, and I believe I modified my strategy to part creation now.
Think about composition
TIL — auto-margin works on
absolutepositioned componentsIt will possibly’t simply be me who hasn’t utilized
margin: autoto absolute positioned components earlier than, can it? I discovered this week that you may middle components (X and Y axis) with a wise mixture ofinset,widthandmargin.Center like a pro
disabledvsaria-disabledQuick’n’candy: Kitty Giraudel printed a simple advice on when to make use of
readonly,disabledandaria-disabeld.Use the best attribute
You are midway by way of!
Wowza! Would you take pleasure in getting Web Weekly straight to your inbox?
The fantastic bizarre net –
grumpy.web siteThe Grumpy web site complains about what’s fallacious with the net as we speak. We’re speaking bizarre dialogs, cluttered UIs, unlogical consumer flows, unreachable footers, [PLACE YOUR WEB ANNOYANCE HERE]…
Let’s get up and yell “YES! This annoys me, too!” collectively!
Be grumpy
What are your favourite web corners? Send them my way, and I am going to embody them in Net Weekly!
What is the fuzz about this new React compiler?
Whereas it will not be launched anytime quickly, React will finally rework right into a compiled Framework. When you suppose this feels like a drastic change, it’s. Nadia Makarevich does a terrific job summarizing what’s on the horizon.
What could change with the React compiler?
Issues to count on when advocating for net accessibility
Heather Buchel displays and shares classes discovered when advocating for an accessible net. It is a incredible learn!
Understand why it’s tough to advocate for accessibility
Grid, subgrid and breaking consumer agent types
What occurs in case your HTML content material contains an ordered checklist with over a thousand entries? Right! The use agent types begin to break, and the checklist markers will overflow.
It is wild how rigid the default types are on this space, however Noah Liebman shared the way to resolve this challenge with a flowery subgrid!
Avoid list overflow
The totally different font dimension downside
Have you ever ever found how troublesome mixing and matching totally different fonts in a paragraph is? It is shocking how difficult it’s to align totally different fonts and make them equal in dimension.
Theoretically,
font-size-adjustsolves this downside, however browser support is still lacking. Com’on Chromium!Rasmus Fløe shared how one can nonetheless align all these totally different fonts with some font evaluation.
Align fonts
Somebody ought to construct a fast device to align fonts robotically. If that’s you, let me know!
On the brilliant facet, popover cross-browser help is simply across the nook. Chromium has shipped the brand new attributes since 114, Safari has supported them since 17, and Firefox contains the brand new UI options within the nightly channel.
However what do the
popoverandpopovertargetattributes imply for accessibility? Hidde de Vries and Scott O’Hara went deep into this matter.tl;dr
aria-expandedstate is dealt with robotically.aria-detailsis typically utilized.function="group"is typically utilized.Learn about popover internals
From the limitless MDN data archive…
Have you ever used the
dfnHTML component? Perhaps it’s best to give it a strive.Define terms
TIL recap –
Intl.SegmenterIntl.Segmenterreaches cross-browser help with Firefox 125 (transport on April 16). Then, we’ll have a local technique to cut up strings into phrases, sentences, and even graphemes.Split the strings
With Safari 17.4, vertical form controls are available on the web. How will you flip the controls? A
writing-mode: vertical-rl;does the trick! Neat.Sadly, I can not learn a top-to-bottom language, so I do not see myself utilizing vertical textareas, inputs or selects quickly. However a vertical vary slider or progress indicator — I am sport!
The help data for vertical kind components is not prepared on MDN, however I checked
<enter sort=vary>and<progress>within the present Chrome, Firefox and Safari Tech Preview. The 2 labored effective.However in different information, in the case of centering components in block layouts by way of
align-content, MDN compat has all the data.????And as you see above, we’re nearly there. Centering components in a div turns into a flowery CSS one-liner quickly!
Three invaluable initiatives to take a look at
For the TS nerds: the TS AST viewer helps you perceive how the TypeScript compiler parses your stunning code.
Understand TS a bit better
Reminder: do not use underlines when designing paperwork, websites, slides, or something that may be consumed with a digital gadget. ????
Anil Sprint has some extra strong recommendation in “Make better documents”.
If you wish to help this text, advocate it to your pals, book a sponsorship package or ensure that I’m not running low on coffee with a small donation.
Thanks! ????
And with that, handle your self – mentally, bodily, and emotionally.
I am going to see you subsequent week! ????
@hdv thank you for the feedback! I will add the aria-details information, I think that is useful.
(and just updated the positioning post with the info that for the recent major changes to anchor positioning, Chromium issued an intent to ship, TAG review and Gecko, Webkit positions still pending).
@hdv @jensimmons What is WebKit missing in this case? Off the top of my head aria-details isn't done but iirc the aam says not to do anything with it for AX API?
It would be nice to get the light dismiss bug on iOS fixed though!
@Lukew @jensimmons last time I checked it doesn't set aria-details (under specific conditions) and doesn't set the group role as a fallback.
the HTML AAM PR is still open (https://github.com/w3c/html-aam/pull/481) and no WPT exist for it yet, but Chromium and Firefox already have this behaviour
add/revise popover related attribute mappings by scottaohara · Pull Request #481 · w3c/html-aam@hdv @jensimmons group fallback role is possibly an issue, the aria-details is per spec.
@hdv @jensimmons Fwiw I don't think WPT can even test this stuff, except the role, (yet*). Even the latest additions only cover role and label, which is a tiny subset of the accesibility API surface area. Not to say they're not a big win but we need more. One of my colleagues presented on work they've been doing to try and get testing of the actual accesibility APIs into WPT. That way we're not reliant on the browser to tell us the truth, and we can cover all the specifics of each API mapping.
@Lukew @jensimmons yep that's my understanding too, just roles at the moment! didn't know about labels (names?) that's nice
It's only a few days until 2025. That means one thing: it is time for my yearly tradition of reviewing… some of my year. I'll cover work, conferences, reading, writing and music.
This will inevitably sound cheesy, but I am once again genuinely grateful for the opportunities I got… there were fun projects at work, I got to see some of my dearest artists live and I got to share knowledge and opinions at events among some of my favourite peers. At the same time, the last few months have, honestly, been intense, and I am looking forward to take a few breaks in January.
I also can't not mention politics. I saw a number of sad elections results. I saw people chose to vote, basically, against other people. It was heartbreaking to see people vote against women, against trans people, against people who crossed borders, and also against the odds for humans to inhabit this planet… and some major tech leaders chose to embrace, encourage or cheerlead that. Booh.
Some say one should focus on things one can impact. I'm not always good at that, but I'll do it now, by sharing a bit more about my year in terms of projects, conferences, reading and listening.
Projects
I spent most of my time on two projects for the Dutch government: NL Design System and the digital accessibility (standards) team at Logius.
At NL Design System, I got to organise another Design Systems Week, and worked on accessibility testing, guidance for forms and WCAG (both in Dutch), communication strategy, events and our website. At Logius, I worked on growing our participation in international standards discussions, specifically accessibility standards like WCAG and EN 301 539, at W3C and ETSI. It's been really cool to get back into familiar groups and join new ones (like the TC and JTB; yes I learned new abbreviations why).
Next year I'm increasing my time for standards at Logius, which, sadly, also means I'm leaving the NL Design System team.
From February, I'll have some availability for new projects, too: ~2 days/week to work on accessibility, frontend and/or design systems, do get in touch if you can use help.
Conferences
It's been a very busy and very fun year in conferences (I recommend going to conferences, for all reasons Sophie outlines in her post You should go to conferences).
Some talks I liked:
I loved speaking at a number of them, too. I got to meet new people in the industry and hang out with friends. Even if it is nerve wracking at times, it gives me a lot of energy.
Creativity, art and AI
In October, I presented a new talk called Creativity cannot be computed at Beyond Tellerrand in Berlin. I talked about what's great about arts and creativity, in the context of our industry's tendency to leave stuff to computers. I love computers and art both, but we've got to prioritise. Some of this has been in my head for the last decade, and I loved to hear how it resonated with people in conversations after (maybe partially because I can't seem to shut up about it, sorry to all affected). I plan to write more about art and AI on my blog, but you can already read along with the slides or watch the video.
Acccessibility
Another new talk was Built-in accessibility: blessing or curse, which combined some of my earlier talks on tooling, browsers and CMSes with what I learned about design systems at NL Design System, all to uncover a general theme: that building in accessibility is not a one size fits all solution, but when done right, can be a sound part of your accessibility strategy. I gave this talk at A11y Club Amsterdam and at Accessibility Toronto.
Popovers
Earlier in the year, I did the most northern iteration of my popover talk (video) at All Day Hey in Leeds. I was very happy how it turned out and it was great to visit this city and this event that I had heard so many good things about.
My shortest talks were at Joy of Coding in my home town of Rotterdam, where I spent 5 minutes rambling about software and accessibility, and Mozilla's performance.sync() meetup in Amsterdam, where I talked about Open UI and reducing bundle size.
In the next year, I'd like to talk about web sustainability more, and continue to cover accessibility, design systems and AI/art.
Reading
I read some books this year, two of my favourites were:
These blog posts from others are among favourites this year:
Music
Three albums that came out in 2024 that I liked:
In live music, it was a good year… I stayed on top of who's touring and ticket acquisition, and managed to see many faves. Most liked: IJSLAND, Massive Attack and Robert Glasper. I also made a point of going to see stuff when traveling, a tradition I hope to keep, though it gets expensive when traveling outside of Europe and its subsidised cultural venues.
In music making: I am picking up playing piano again and have joined a choir, which has been on of my best decisions, it is so much fun. As usual, I should have listened to a friend's advice earlier.
Writing
With 10 posts in total, I didn't write as much on this blog in 2024. I don't know which were most read, but these got some good feedback:
Cities
Outside The Netherlands, I spent time in Duisburg, Berlin, Taipei, Tainan, Kaohsiung, Brighton, Antwerp, Paris, Leeds, London, Bad Schandau, Brussels, Los Angeles, Toronto, Liverpool, Vienna.
Self study
I did a bunch of self-study:
Wrapping up
I wanted to write up some resolutions for the next year, but I ran out of time. I guess I'll leave it, as a resolution itself, for the next year. If you're reading this, I wish you all the best for the new year!