Skip to content

Instantly share code, notes, and snippets.

@smhigley

smhigley/tpac2025-aria-openui.md

Last active November 7, 2025 00:00
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save smhigley/d370d79e52015cb011685f2cf8b80eca to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save smhigley/d370d79e52015cb011685f2cf8b80eca to your computer and use it in GitHub Desktop.
Download ZIP
TPAC + ARIA 2025 – Open UI updates
Raw
tpac2025-aria-openui.md

TPAC + ARIA 2025 – Open UI updates

Table of Contents

Please note: this document contains discussion points about areas that I personally thought were most relevant to bring to the ARIA WG, curated for time and relevance. There is a lot of active work and development outside of the topics in this doc that are worth paying attention to.

Anchor positioning

Relevant reading:

Summary:

Creating an anchor positioning relationship between two elements implies some sort of semantic association, which also implies there should be a default ARIA relationship if one is not explicitly declared by the author.

Right now, the current proposals in the linked issue center around using aria-details, but only when the author has not created an explicit relationship between the two elements (e.g. with aria-labelledby, aria-describedby, etc.).

There are two implementations of this, but some details to iron out.

Interest invokers

Relevant reading:

Summary:

The basic idea of interest invokers is to provide a platform-level way to manage tooltips, hovercards, and submenus. The current landscape forces developers to use hover (and focus if they think about keyboard) to trigger UI like this. This clearly has fundamental accessibility issues – touch, eye gaze, and voice control all lack the ability to trigger hover and focus separately from activating the control, and even if screen reader users can trigger focus, there is no consistent way to directly access the popup UI.

Interest invokers make this possible by adding a platform-level interest event, as well as a declarative way to associate a button or link with a popup via interestfor. This makes it possible for platforms and assistive tech to create custom UX to indicate interest, where before it was functionally impossible.

The main difficulty is that a lot of the work involved in making this accessible falls directly on assistive tech developers. The current very tentiative set of proposed access methods are as follows:

  • Desktop screen readers: the same keyboard shortcut as for aria-details, which is the proposed semantic association.
  • Touch screen readers: via the actions rotor
  • Voice control: unknown
  • Touch: longpress, with the current objection of Apple. Alternatively, have an optional ::interest-hint CSS pseudo-element that indicates interest on tap, but is not in the accessibility tree.

Open questions:

  • Does the aria-details access method for desktop screen readers sound like a good approach? How does that compare to a platform-level aria-actions mapping as an alternative?
  • If there is a proposed ::interest-hint pseudo element that is intended primarily for use on touchscreens as an affordance for pointer users without AT; is there consensus around this being excluded from the accessibility tree?
  • If anyone who has contacts with voice control software developers is present, is there an avenue to discuss potential voice activation?
  • [Optional]: this is outside the scope of ARIA, but if anyone has thoughts or opinions on touch access, let’s discuss outside of this session.

Select updates

Relevant reading:

Summary:

There have been quite a few updates to the customizable select in the last year, so this is only a small and curated subset of issues that seem most relevant to ARIA.

  1. Value computation: there is both the question of how to allow authors to declaratively set what they wish to be the user-exposed value string, and the question of how to define the default browser computation. The latter would benefit from coordination with creatinga value computation algorithm in ARIA.
  2. Customizable arrow key direction: the original proposal asked for authors to be able to customize both vertical vs. horizontal arrow directions, as well as potentially having grid-like arrowing. Specific considerations include:
    • Is including aria-orientation on the listbox adequate to notify the user of different arrowing behavior?
    • Is a 2D arrowing option possible or desirable?
  3. Filterable / editable combobox: right now, there are two directions that are both being pursued. One is to repurpose input + datalist to be more customizable and function better out of the box. The other is to allow a search input within the options popup. Topics for the group include:
    • Currently, editable comboboxes (and by extention input + datalist) do not function well outside of Windows. Is there anything we can do to push for better cross-platform support? Are there any considerations that should go into working on an update input + datalist, especially from Apple?
    • Are there any concerns with updating select to support a dialog popup with an input + listbox with an activedescendant relationship?

CSS Carousels / scroll-markers updates

Relevant reading:

Summary:

This is currently shipped in Chrome, which means that any pushback needs to either be incremental attempts to mitigate harm, or on the level of formal objections.

There are roughly two areas that are problematic:

  1. Interactivity: inert, which grants the ability to set sections of content to inert with CSS
  2. Focusable CSS pseudo-elements, which create focus targets that are not DOM Elements, and do not support custom semantics or accessible name customization outside CSS.

The issues I have raised are all linked here: openui/open-ui#1265. The subject of discussion for the ARIA WG is largely around how strong our objections are or are not, and what paths forward we have.

Focusgroup

Relevant reading:

Summary:

Focusgroup is a proposal to allow authors to declaratively create a single-tab-stop arrow navigation region, and is now scoped to a set of specific behaviors:

  • toolbar
  • tablist
  • radiogroup
  • listbox
  • menu
  • menubar
  • grid (future)

This greatly improves the ability of browser to correctly add semantics, essentially by forcing authors to intentionally choose between a limited set of available semantic patterns.

Other behaviors authors can specify include:

  • orientation (horizontal or vertical)
  • wrapping
  • memory (i.e. whether tabbing will go to the last-focused item, or the default)
  • Descendants of the focusgroup may declaratively opt out of being part of the arrow behavior with focusgroup=”none”.

The explainer is well worth reading, since it lays out the reasons behind the accessibility-impacting choices, as well as some of the options that were rejected.

Topics to discuss include:

  • Are there any red flags with any of the combinations of direction/wrapping/memory with the allowed semantic types of focusgroup?
  • Ordering: should arrow direction follow DOM order, visual order, be affected by tabindex or reading-order, or anything else?
  • Managing the initial focus entry point: the current proposal is with a new attribute (currently named focusgroup-initial-focus): openui/open-ui#1314

Other element initiatives

If there is extra time, here’s a heads’ up on several other proposals being worked on:

Range

This isn’t just the range input, but a two-handled version that lets you set the min and max on the same visual track. This is done by having a range group, with two child inputs – one for min, and one for max.

Explainer: https://open-ui.org/components/enhanced-range-input.explainer/

Toolbar

Somewhat self-explanatory, a proposal for a toolbar element that would be similar to a focusgroup with the toolbar behavior. This is in early stages and has a number of open questions.

Explainer: https://open-ui.org/components/toolbar.explainer/

Menubar / Menulist

Chris either will talk about or has already talked about this in ARIA. Included for completeness.

Explainer: https://open-ui.org/components/menu.explainer/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment