Adrian Roselli's Interop 2027 ballot ranks the places authors keep getting it wrong

Somewhere right now a screen reader user is on a page where an announcement never came, or came three times. Somewhere a keyboard user is pressing Tab through a toolbar one button at a time because nobody wired up the arrow keys. Most people in their position will never see an Interop ballot. They live with whatever ends up on it.

Adrian Roselli has published his. Interop 2027 is gathering votes until 19 November 2026, and for the second year Firefox has put up a page that lets anyone rank the proposals. Roselli narrowed his choices to fifteen and wrote a sentence or two of reasoning for each. Nearly every reason starts from a user who gets stranded. That makes his list a useful second opinion if you haven't voted yet.

The top of the list is about taking script away from us

Roselli says plainly that "the top three are really what matter." All three replace something authors currently build by hand and frequently break.

ariaNotify() is his first pick. His case rests on "years of watching developers get live regions wrong," which he argues is partly because companies aren't employing screen reader users in critical roles, combined with confusion about how live regions are exposed and supported. He notes that the ARIA Working Group put a lot of effort into specifying ariaNotify(), and he wants broad support to follow.

The HTML focusgroup attribute is second. Roselli expects it to simplify keyboard patterns for authors, "and hopefully less scripting," with better outcomes for users. He has written about his focusgroup testing before, so this is not a pick made on paper.

Shadow DOM referenceTarget is third. His reason is the one I'd underline for anyone shipping web components: he has seen "so many broken associations across shadow boundaries that have left screen reader and voice control users stranded." ARIA reflection and the proposed AOM continue to get some attention, he writes, but "they aren't here today."

Read those three together and the pattern is clear. Each is a job that today depends on every author, in every codebase, getting the details right. Each moves that job into the browser, where it gets done once. That is the use-the-platform argument at the scale of the whole web, and it is why I'd put these three at the top too.

Picks he makes while wary of them

The more honest part of the post is where Roselli ranks a feature and names the way it could go wrong in the same breath.

• He ranks the HTML headingoffset and headingreset attributes fourth, because headings in user-generated or third-party content are often the wrong level. He also says those wrong levels aren't typically blockers, and his fear is that authors will get more cavalier, even treating the attributes as an outline algorithm.
• He ranks line-clamp because card designs have been clipping text visually or moving interactive controls to the wrong place for years, which he says makes for confusing interfaces for keyboard and screen reader users. He is still wary of letting CSS generate content, citing localization risk.
• On random-item(), he writes that not needing script would be nice, but authors may use it for more than basic styling, which could interfere with what is exposed to accessibility APIs.

That is how I'd want anyone to vote. A feature can be worth ranking and still need watching once it ships. Ranking headingoffset does not change the fact that the heading level you write should match the structure of the page.

The rest of the fifteen

The lower half is a mix of user-facing fixes and things Roselli wants as an author:

• Device Posture API and Viewport Segments API, because new hardware is already causing problems for design systems that, in his view wrongly, rely on known and fixed screen sizes.
• CSS linked parameters, so he can pass colors into SVGs referenced by <img>.
• CSS AccentColor system color reflects accent-color, because some design systems that leaned on this user preference are, after fingerprinting concerns, stuck with low-contrast browser defaults.
• HTML <input type="week">, given how many poorly-coded, inaccessible date pickers he has seen. "I've yet to see an author get it right," he writes.
• CSS anchor positioning with transforms and animations, since the script needed to do it well makes his phone overheat.
• CSS flex-wrap: balance, to close what he calls a years-old gap in flex.
• Responsive iframes, which he treats as an accessibility issue once critical content is visually hidden, scrollbars or not.
• Interoperability of pointer events on touch devices, which made the list only because Apple is making a touch-screen Mac and he would rather the interoperability work arrive first.

He also says there are items he would down-vote if he could, and he links the rankings of nineteen other people who have published theirs.

Where I land

Roselli's ballot is the one I'd hand to someone who builds components for a living, because every entry is tied to a real failure rather than to novelty. The top three deserve the weight he gives them. Each turns a pattern that authors re-implement badly into something the platform owns.

If you are voting before 19 November:

• put features that replace scripted widgets and hand-wired ARIA near the top
• for anything that styles or generates content, ask what it could do to the accessibility tree before you rank it
• read one or two of the rankings he links that disagree with yours

His last line on those other lists is the right spirit for the whole exercise: "None of those rankings are wrong. Except where they are wrong, of course."