# Popover, Anchor Positioning, Dialog: Are They Accessible Enough to Use Yet?

> A green support table doesn't mean everyone can use it. Here's a 2026 accessibility check on popover, anchor positioning, dialog, and view transitions — and what you still have to do yourself for each.

**Published:** 2026-08-05 | **Updated:** 2026-08-05

---


When we're deciding whether to adopt a new feature, we usually look at a support table. We check caniuse, see what percentage of cells are green, and once it clears 90%, we think "okay, we can use this now."

But there's a question the support table never answers: **Can you use it with a keyboard? Does a screen reader read it correctly?**

Those are two different questions. There's a bigger gap than you'd expect between a browser implementing a feature and that feature actually handling accessibility. Some features quietly replace accessibility code we used to hand-write; others open up brand-new traps.

This post checks four features that people are calling "ready to use" against that exact question. As of August 2026.

All four come with a **demo page you can actually poke at**. Whenever a claim below makes you think "really?", open the [live demo](https://isaaceryn.github.io/demo_codes/browser-features-accessibility/?lang=en) and check it with the Tab key — reading that focus escapes and watching it escape are two different experiences.

{{< img src="images/contents/browser-features-matrix-en.png" alt="A table splitting what the browser handles for you from what you still have to do yourself, across four browser features - popover automatically handles the top layer, closing on outside click and Esc, and even aria-expanded, but you still have to set the role and move focus yourself, and since it isn't a modal, focus doesn't get trapped; anchor positioning handles placement in Chrome 125, Safari 26, and Firefox 147, but it doesn't change DOM order, so if the visual position and the reading/tab order don't match, it becomes a WCAG violation; dialog handles focus trapping, Esc, and disabling the background, plus restoring focus on close, but you still have to supply an accessible name and a fallback for when the element that opened it has disappeared; and view transitions are supported by all browsers for same-document transitions while Firefox doesn't yet support cross-document transitions, so you need to respect prefers-reduced-motion and check focus during the transition" >}}

## What this post covers

- Features where the support table is green but accessibility is still on you — `popover`, anchor positioning
- A feature that now does what we used to hand-code — `<dialog>`
- A feature that still needs caution — view transitions
- For each one: "so what do I actually have to do myself?"
- How to read Baseline tiers, and where to check other features yourself

---

## popover — the key point is that it isn't a modal

> 🔬 [Open the live demo](https://isaaceryn.github.io/demo_codes/browser-features-accessibility/?lang=en#popover) — open the popover, press Tab, and this section takes three seconds to confirm.

The `popover` attribute was built for things that need to float above the page — tooltips, dropdowns, menus. We used to fight `z-index` wars and wire up outside-click detection by hand; now one attribute does the job.

```html
<button popovertarget="menu">Menu</button>
<div id="menu" popover>
  <a href="/settings">Settings</a>
  <a href="/logout">Log out</a>
</div>
```

There's not a single line of JavaScript. Click the button and it opens; click outside or press Esc and it closes. It always renders in the top layer, so you don't have to think about `z-index` either. Support is solid too — Chrome, Edge, Safari, and Firefox all support it, and once iOS Safari — the last holdout — landed it in 18.3, the feature reached Baseline "newly available" **in January 2025**. It hasn't reached the tier above that, "widely available," though — that label only gets attached 30 months after "newly available."

{{< img src="images/contents/demo-popover.png" alt="The popover demo - a popover is open below its button, but the focus ring is still on the button, and the status line reports that focus remains on the menu button because the browser does not move it" caption="<a href='https://isaaceryn.github.io/demo_codes/browser-features-accessibility/?lang=en#popover' target='_blank' title='Opens in new window'>Try it yourself</a> — the popover opens, but focus stays on the button" >}}

So far it sounds like a silver bullet, but here's the most important fact: **popover is not a modal.**

What that means is: even while a popover is open, the content behind it stays fully alive. Focus isn't trapped, so keep pressing Tab and you'll walk right out of the popover, and the background is still clickable. That's not a bug — it's exactly the right behavior for something that should "float without getting in the way," like a tooltip or a notification. The problem shows up when you use it for UI the user **must** deal with before moving on, like a login modal.

### auto vs. manual, and what's still on you

`popover`'s behavior splits depending on its value.

| Value | Closes on outside click / Esc | Used for |
|---|---|---|
| `popover` (= `auto`) | Closes automatically | Menus, dropdowns, tooltips |
| `popover="manual"` | You close it yourself | Toasts, panels that need to stay open |

And there are things the browser **doesn't** do for you. This is the core of the post.

- **It doesn't add a role.** `popover` is an attribute, not an element, so it has no role of its own. Chrome, Edge, and Firefox do fall back to a `group` role when a popover has none (Safari doesn't even do that), but you still need to set `role` yourself — as a menu if it's a menu, as a dialog if it's a dialog — for a screen reader to understand what it is.
- **It doesn't move focus.** Even after the popover opens, focus stays on the button. What the browser does do is splice the popover's contents into the tab order right after the button, and return focus to the button when you close it with Esc. If you want focus to land inside as soon as it opens, add `autofocus` to an element inside the popover. The spec defines a procedure called the "popover focusing steps," and the browser follows it to move focus for you.

```html
<button popovertarget="menu">Menu</button>
<div id="menu" popover role="menu">
  <a href="/settings" autofocus>Settings</a>
  <a href="/logout">Log out</a>
</div>
```

On the flip side, **the browser now sets `aria-expanded` for you.** Once you link a button and a popover with `popovertarget`, Chrome, Edge, Firefox, and Safari all report the button's expanded/collapsed state automatically. So hand-writing `aria-expanded="false"` actually hurts you — the value never updates, so it keeps reading as "collapsed" even after the popover opens.

There's also an implicit `aria-details` relationship the browser wires up when the two elements aren't siblings. But this one's only in Chrome, Edge, and Firefox — **Safari doesn't do it.** And whether a screen reader actually announces that relationship is a separate question again; even JAWS and NVDA announce it or don't depending on the mode. Bottom line: trust `aria-expanded`, but don't expect any relationship beyond it to happen automatically.

---

## Anchor positioning — when the eye and the hand disagree

> 🔬 [Open the live demo](https://isaaceryn.github.io/demo_codes/browser-features-accessibility/?lang=en#anchor-positioning) — compare where Tab lands in two menus that look identical on screen.

CSS anchor positioning lets you say "pin this element next to that one" in pure CSS. It's popover's natural pairing.

```css
.trigger { anchor-name: --menu-btn; }
.menu {
  position: absolute;
  position-anchor: --menu-btn;
  top: anchor(bottom);   /* pin it below the button */
  left: anchor(left);
}
```

Support has shifted quite a bit lately. For a while it had a reputation as Chrome-only, but **Firefox and Safari now support the core feature too.** Chrome joined first with 125 (May 2024), then Safari with 26 (September 2025), then Firefox with 147 (January 2026).

One thing worth correcting: there's a rumor going around that `@position-try` — which flips the position when the element would overflow the screen — needs a newer version than the core feature. In Safari and Firefox, it actually **shipped in the same version as the core feature.** The only engine with an early gap was Chrome (`position-try-fallbacks` landed at 128). If a browser supports anchor positioning, it generally supports this fallback too.

So is it safe to use without worry? Not quite yet. Firefox support is only about half a year old, so plenty of older versions are still out in the field, and there are still spots where engines disagree — things like `position-anchor`'s default value or some `position-visibility` values — which is why webstatus.dev still rates its Baseline status as **"limited."** Relying on anchor positioning alone for layout, with no fallback, is a bit premature.

From an accessibility standpoint, there's a separate point worth flagging: **anchor positioning doesn't change DOM order.**

That sounds obvious, but the consequences are anything but small. Say you've visually pinned an element right below a button, while in the markup it actually sits at the very end of the document. To a sighted user, the button and the menu look like one unit. But **for someone tabbing through with a keyboard, the entire rest of the page sits between them.** Someone reading in document order with a screen reader hits the same thing.

{{< img src="images/contents/demo-anchor.png" alt="The anchor positioning demo - two stages both show a menu pinned under an account button so they look identical on screen, but in the top one the menu sits at the end of the DOM and in the bottom one right after the button, so Tab goes somewhere different" caption="<a href='https://isaaceryn.github.io/demo_codes/browser-features-accessibility/?lang=en#anchor-positioning' target='_blank' title='Opens in new window'>Try it yourself</a> — same picture, different Tab destination" >}}

This is something WCAG addresses explicitly. It runs straight into the criterion that reading order must preserve meaning (1.3.2 Meaningful Sequence) and the criterion that focus order must be logical (2.4.3 Focus Order).

For now, the safe line is this: **keep your visual order matched to your DOM order.** Just because CSS now lets you move things around freely doesn't mean you should scatter the order too — for someone who isn't looking at the screen, that turns the page into a jumble. There's a standard in discussion for reordering reading order via CSS, but it's still at the waiting stage.

This problem repeats every time layout gets more freedom. Flexbox's `order` and grid's placement properties carried the same trap. The more powerful the tool, the easier it becomes for "what you see" and "what gets read" to drift apart.

---

## dialog — this one genuinely lightens the load

> 🔬 [Open the live demo](https://isaaceryn.github.io/demo_codes/browser-features-accessibility/?lang=en#dialog) — open it, close it, and the page tells you where focus went.

If the previous two were about things you have to handle yourself, `<dialog>` is the opposite. The browser now does what we used to hand-code.

```html
<dialog id="confirm">
  <h2 id="confirm-title">Delete this?</h2>
  <p>This action can't be undone.</p>
  <button id="cancel">Cancel</button>
  <button id="ok">Delete</button>
</dialog>
```

```js
document.getElementById('confirm').showModal()
```

Open it with `showModal()`, and here's what the browser handles for you automatically.

- **Focus trapping** — everything outside the dialog goes inert, so Tab only cycles within the dialog. The code we used to write ourselves — grabbing the first and last focusable elements and looping between them — is no longer needed.
- **Closing on Esc** — no need to wire up a key event yourself.
- **Background deactivation and `::backdrop`** — the content behind it becomes inert, and you can style the dimmed backdrop with a single line of CSS.

One thing worth spelling out: keep pressing Tab with the dialog open and focus will eventually move into the **browser's own UI** — the address bar, the tab strip. The trap isn't broken; its scope simply ends at the edge of **the document**. The browser's chrome sits outside the document, where no web page can reach. Cycle past it and focus comes right back into the dialog.

And to be clear: **a modal confining focus is deliberate, and it's the right behaviour.** It's the only way to tell a keyboard user the same thing the dimmed backdrop tells everyone else — you have to deal with this before moving on. WCAG's no-keyboard-trap criterion (2.1.2) doesn't say "never confine focus"; it says **you must be able to get back out**. A dialog satisfies it because Esc and the close button are the exits. The real failure is confinement with no way out — focus lands in a custom widget and neither Tab nor Esc will free it.

If you've ever built one by hand, you know a proper focus trap alone runs to dozens of lines of code. Being able to rip all of that out is a pretty big deal.

### Two things are still on you

Still, opening the dialog isn't the end of the story. Two things remain your responsibility.

**First, you have to give it a name.** Without an accessible name, a screen reader just announces "dialog" — the user is essentially trapped inside without knowing what it's for. Link it to the heading inside.

```html
<dialog aria-labelledby="confirm-title">
  <h2 id="confirm-title">Delete this?</h2>
```

**Second, focus restoration needs verifying** — but not doing yourself. It used to be conventional wisdom that you had to manually return focus when closing a dialog; that's no longer true. The HTML spec now has browsers remember the element that had focus right before the dialog opened, and return focus to it on close, and **Firefox has implemented this since version 90.** Chrome and Safari do too. Just open and close it, and focus finds its own way back to the button.

Does that mean nothing to watch for? Not quite. The problem is when the element it's supposed to return to has **disappeared in the meantime.** Say you click a "Delete" button in a list to bring up a confirmation dialog, and running the delete removes that button entirely. In that case, the browser has nowhere to send focus back to, so it falls to `<body>`, and screen reader users get bounced to the top of the page. You only need a safety net wherever this kind of flow exists.

```js
// The browser remembers the focus from right before opening and restores it automatically on close.
// But if that element has disappeared, focus falls to <body> — only handle that case yourself.
dialog.addEventListener('close', () => {
  if (document.activeElement === document.body) {
    // main needs tabindex="-1" to be focusable
    document.querySelector('main')?.focus()
  }
})
```

{{< img src="images/contents/demo-dialog.png" alt="The dialog demo - an open-the-confirm-dialog button and a delete-item button that reproduces the case where the invoking button disappears, each paired with its own status line" caption="<a href='https://isaaceryn.github.io/demo_codes/browser-features-accessibility/?lang=en#dialog' target='_blank' title='Opens in new window'>Try it yourself</a> — close it and the page tells you where focus landed" >}}

And don't put `tabindex` on the `<dialog>` element itself — it breaks the focus model.

There's a remaining bug too. On Safari with VoiceOver, plain static text inside a modal dialog sometimes doesn't get announced — it's tracked as **WebKit bug 174667**, filed as P1/Critical, and it's **still open.** That means multi-line descriptions or an error message next to an input field can go entirely unheard, so if your service has a lot of Safari users, it's worth listening through it yourself at least once.

On the other hand, `aria-haspopup="dialog"` isn't as bad as it used to be. There's a well-known story about the `dialog` value going unsupported for ages, but ever since **NVDA accepted it in 2023.2**, JAWS, NVDA, VoiceOver, and Orca are all reported to announce it (per a11ysupport.io — only Windows Narrator is partial). That said, the underlying test data is a few years old, so don't take it as gospel.

Still, it's clearly better than the days of hand-coding all of this.

---

## View transitions — the prettier it gets, the more care it needs

> 🔬 [Open the live demo](https://isaaceryn.github.io/demo_codes/browser-features-accessibility/?lang=en#view-transitions) — see whether your browser supports it and whether reduced motion is on.

This is the effect where elements smoothly morph as the page changes. **Same-document transitions** now have support across every major browser, with Firefox joining last at **144 (October 2025).** **Cross-document transitions** are supported by Chrome 126 and Safari 18.2, but **Firefox doesn't support them yet.** Cross-document transitions aren't at the everyone-supports-it stage yet.

The first accessibility snag is the motion itself. Screens sliding and zooming can trigger dizziness or nausea for users with vestibular disorders. So if a user has turned on "reduce motion" at the OS level, **you have to respect it.** This isn't optional — it's closer to a default requirement.

```css
@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*),
  ::view-transition-old(*),
  ::view-transition-new(*) {
    animation: none !important;   /* instant switch instead of animated motion */
  }
}
```

{{< img src="images/contents/demo-vt.png" alt="The view transitions demo - a Screen A panel with a transition button, and a status line reporting whether this browser supports view transitions and whether reduced motion is switched on" caption="<a href='https://isaaceryn.github.io/demo_codes/browser-features-accessibility/?lang=en#view-transitions' target='_blank' title='Opens in new window'>Try it yourself</a> — turn on reduced motion in your OS and press it again" >}}

There's a less-known problem too. During the transition, **snapshots of the old screen and the new screen exist at the same time.** That can mean losing your reading position, losing track of where focus went, or an announcement parked in an `aria-live` region (the spot you mark so screen readers read out changes automatically) getting read at an odd moment. This is an area without a clean, settled solution yet, so before you add a flashy transition, the best move is to walk through it with a keyboard yourself.

---

## Even a green light has tiers — how to read Baseline

We've been saying things like "Baseline newly available" and "still limited" throughout this post — it's worth pausing to explain what that tier actually means, since it's the yardstick you'll use to check other features yourself.

**Baseline** started with the Chrome team and is now defined by the W3C's WebDX Community Group. The idea is to answer "has this feature landed in all the major browsers?" in a single word. The core set is **seven browsers**, counting mobile separately: Safari (iOS, macOS), Chrome (Android, desktop), Edge (desktop), and Firefox (Android, desktop). Samsung Internet and in-app WebViews aren't included.

There are three tiers.

| Tier | What it means | Among this post's features |
|---|---|---|
| **Limited** | At least one core browser doesn't support it yet | Anchor positioning, cross-document view transitions |
| **Newly available** | Counted from the day the last browser added support | `popover` (2025-01), same-document view transitions (2025-10) |
| **Widely available** | **30 months** after it went newly available | `<dialog>` (2024-09) |

{{< img src="images/contents/baseline-tiers-en.png" alt="An illustration listing the three Baseline tiers from left to right - limited means at least one core browser still doesn't support it, newly available starts from the day the last browser added support, and widely available, 30 months later, covers roughly 95% of users including those who haven't updated. The table below places this post's features into those tiers: dialog reached widely available in September 2024, popover reached newly available in January 2025 with iOS Safari 18.3, same-document view transitions reached newly available in October 2025 with Firefox 144, and anchor positioning and cross-document view transitions are both limited. At the bottom, a note states that none of the tiers tell you whether a feature is actually read correctly by a screen reader" >}}

The 30-month number might look arbitrary, but it isn't. It's based on the observation that roughly 95% of users worldwide tend to be on that version by then. In plain terms, **"newly available" means "it works in current browsers," and "widely available" means "it works even for people who haven't updated."** At that rate, same-document view transitions won't hit widely available until roughly spring 2028.

### What a single tier label hides

Read the label too literally, though, and you miss something — and this post happens to have two good examples of it.

**Why did `popover` land in January 2025?** Safari on macOS already supported it in September 2023, and Firefox joined in April 2024 — but the tier waited another nine months after that. The holdup was iOS Safari, and the reason is worth a laugh: it wasn't missing the feature at all. **A bug where tapping outside the popover didn't close it** was recorded as a "partial implementation." That's exactly the kind of problem this post keeps circling back to — it works, just not properly.

**Anchor positioning gives you a different answer depending on where you look.** Look up the whole feature on webstatus.dev and it says "limited." Open the `anchor-name` page on MDN and it says "Baseline 2026." But on that same MDN, the `position-anchor` page still says "limited." None of these are wrong — it's just that **status varies piece by piece within the bundle.** So instead of asking "is this feature ready?", ask **"is the specific property I'm about to use ready?"** — that's the question that gets you an accurate answer.

## Where to check other features

Four features aren't the whole story, so here's a rundown of where to check the rest yourself.

| Where | What it shows | When to use it |
|---|---|---|
| [webstatus.dev](https://webstatus.dev) | Baseline tier and its date, first-supported version per browser | "When did it cross the line, and who was last?" |
| [MDN](https://developer.mozilla.org) | A Baseline banner at the top of the page, plus a browser compatibility table below | "Is the specific property I'm using ready — and are there any caveats?" |
| [caniuse.com](https://caniuse.com) | A version table plus a **usage-share-based support percentage** | "What percentage of our users are covered?" |
| Vendor pages | Chrome Platform Status, Firefox release notes | The primary source for "when did this land in which version?" |

There's one trick to reading MDN. If the banner at the top carries **an asterisk alongside a note that "some features may have varying levels of support,"** that's a signal the page is bundling several pieces together. When you see that, scroll down to the compatibility table and read the footnotes. Something like iOS's popover "doesn't close on outside tap" bug we mentioned earlier isn't in the banner — it's in that footnote.

It's also worth knowing that caniuse and Baseline can give you different answers. **caniuse asks "what percentage of measured traffic is covered?" (market share), while Baseline asks "is it in all seven core browsers?" (a browser set).** That's why a feature like cross-document view transitions — supported across Chromium and Safari — shows a fairly high caniuse percentage while Baseline still calls it "limited": Firefox is missing entirely. Neither answer is wrong; they're just answering different questions.

One more note on Safari: the WebKit Feature Status page we used to rely on has been retired. These days, the per-release WebKit blog posts are the accurate source.

### What none of these show

That covers how to check whether a feature works. But the question this post started with — **"does a screen reader read it correctly?" — isn't in any of those tables.**

This isn't my opinion — MDN says so directly in its own Baseline explainer. Baseline is not a substitute for accessibility, usability, performance, or security testing, and **it doesn't tell you whether a feature works with assistive technology.** The documentation from the people behind Baseline explicitly scopes out screen reader, screen magnification, and voice control support. It's an honest disclosure — but that exact sentence doesn't show up on the promotional landing page, so most people never see it.

So where do you check assistive technology support instead? Honestly, **there isn't anywhere as well-maintained as Baseline yet.**

- **[a11ysupport.io](https://a11ysupport.io)** — the broadest matrix around, but some entries are testing from 4-5 years ago. Always check the test date listed on each entry.
- **[ARIA-AT](https://aria-at.w3.org/)** — a currently active W3C project that runs standardized tests against real assistive technology. It only covers patterns that have a test plan written, though.
- **[The ARIA APG's assistive technology support tables](https://www.w3.org/WAI/ARIA/apg/about/at-support-tables/)** — where ARIA-AT results get compiled and published.

In the end, what's left is checking it yourself. It doesn't have to be elaborate. If you've just wired up a new feature, try these three things.

1. **Put the mouse aside and go through it with Tab alone** — spots you can't reach, focus that disappears, and jumps in order all turn up here.
2. **Check the accessibility tree in dev tools** — see what role and name your elements are exposed with. An empty name means that's the spot to fix.
3. **Listen with a screen reader once** — NVDA is free on Windows, and VoiceOver comes built in on Mac. Five minutes is enough.

---

## One-page summary

- **`popover`**: Reached Baseline "newly available" in January 2025. But it **isn't a modal** — focus isn't trapped and the background stays live. Set `role` and move focus yourself (use `autofocus` on the inner element for focus), though **the browser sets `aria-expanded` for you.** For UI the user must deal with, use `<dialog>` instead
- **Anchor positioning**: All three engines support it now — Chrome 125, Safari 26, Firefox 147. `@position-try` shipped in the same version as the core feature in Safari and Firefox too. Still, its Baseline status is "limited" for now. And since it **doesn't change DOM order**, a mismatch between visual position and reading/tab order becomes a WCAG 1.3.2 / 2.4.3 violation. Keep the order matched
- **`<dialog>` + `showModal()`**: Beyond focus trapping, Esc, and background deactivation, **the browser even restores focus on close.** What's left: an accessible name (`aria-labelledby`), and a safety net for when the element that opened it has disappeared. Never put `tabindex` on `<dialog>`
- **View transitions**: Same-document transitions reached full browser support with Firefox 144; cross-document transitions still lack Firefox. Respecting `prefers-reduced-motion` is mandatory; focus and reading-position issues during the transition remain unsolved
- **How to read Baseline**: limited → newly available → (30 months) → widely available. A tier applies to a bundle, so status can vary piece by piece — check **the specific property's page** you plan to use. Check status on webstatus.dev and MDN; check usage share on caniuse
- Common lesson: **a green cell in the support table means "it works" — not "everyone can use it"** — even Baseline's own documentation says it doesn't cover assistive technology support

---

## When you get a new toy

When a new feature ships, it's tempting to bolt it on right away out of sheer excitement. The first time I saw `popover`, I thought, "guess I don't need a dropdown library anymore." And honestly, that's often true.

But it turns out knowing exactly how far the browser's help extends really matters. Some features, like `<dialog>`, genuinely lighten the load. Others, like `popover`, look convenient but leave accessibility squarely in your hands. Miss that boundary, and you end up assuming "I used the latest feature, so it must be fine" — while, quietly, a keyboard user is stuck.

The three steps above — one pass with Tab, a look at the accessibility tree, a listen with a screen reader — take under ten minutes all together. About as long as checking a support table. And those ten minutes close most of the distance between "we shipped the new feature" and "everyone can use it."