smhigley

Listview

This doc is intended as a summary of the reasons for adding a listview role, the proposed spec changes, and open questions.

What is an interactive list? (the problem to solve)

I wrote about this in more detail in a recent blog post, but the general issue is that there is a common pattern on the web that is not currently well supported by any existing semantics.

This pattern also already exists on all native platforms (Windows, macOS, iOS, and Android), which indicates both that there is a genuine UX design need for it, and that users are able to understand and operate it.

smhigley

Notification Best Practices

Using DOM-based live regions

There are functionally three ways to create a live region in the DOM:

1. Use aria-live="assertive" or aria-live="polite" Using aria-live to designate an element as a live region is the most common way to do so. In theory, the difference between assertive and polite affects how where notification text is inserted in the screen reader's speech queue. However, in practice this is not consistent between operating systems and screen readers. Generally use aria-live="assertive" when the notification is likely more important than a user's current interaction, and use aria-live="polite" when the notification is less important than what the user is currently doing.
2. Use role="alert" The alert approach is best used for error messages such as form errors or high-importance toasts. Some screen readers say "alert" or a similar word before the text of the live region element. It is the only live region that consistently gets

smhigley

TPAC + ARIA 2025 – Open UI updates

Table of Contents

• Anchor positioning
• Interest invokers
• Select updates
• CSS Carousels / scroll-markers updates
• Focusgroup
• Other element initiatives

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.

smhigley

Slides: https://smhigley.github.io/slides/have-a-notification/workshop/

Code examples: https://github.com/smhigley/notification-workshop

MutationObserver debug function: https://gist.github.com/smhigley/75fa44df8218d62714ea6df5bab353b5

smhigley

Draft guidance for aria-actions behavior in screen readers

This document is intended to provide a set of rough guidelines for aria-actions implementation in screen reading software. There are no plans for this guidance to go into the ARIA spec or any other normative guidelines; it is only inteded to help clarify how the new aria-actions attribute is intended to be used as a reference for implementors creating new UI for actions.

Intro: browser and authoring requirements

The ARIA PR includes the actual proposed spec wording, but here's the gist of how authors and browsers should create actions, including examples:

Browser accName changes and API mappings

smhigley

Interactive list proposal

This gist is intended to pull in all the various ideas around creating an interactive list ARIA pattern, and document a cohesive proposal for moving forward.

Summary of need

The need for an interactive list pattern has been documented in multiple previous issues, including the following:

• Interactive Lists #2036
• New roles listview and listviewitem needed #1325

smhigley

aria-maxlength discussion

This is a short overview of the background and decisions that need to be made to map the maxlength HTML attribute and create an aria-maxlength ARIA attribute.

Background

Although the HTML maxlength prop can be used to limit characters in native inputs, it has no accessibility mappings and is not communicated to screen reader users (either up front or when the character limit is reached).

This becomes a pain point when authoring text inputs that have character limits in several ways:

• It necessitates a custom live region announcement when the character limit is approaching and exceeded, despite there often being no visual text equivalent.

smhigley

Testing Expandable Group behavior

A list of results from testing accordions, but with tabbable, clickable container elements with a group role in addition to the expand/collapse button. The semantics are as follows:

<div role="group" tabindex="0" aria-expanded={expandedState} aria-labelledby="citationId titleId">
  <a href="#" id="citationId">1</a> <!-- This is conditionally a in-page citation link, depending on authoring -->
  <a href="#" id="titleId">Title of accordion</a> <!-- This is conditionally an external link, depending on authoring -->
  <button aria-expanded={expandedState} aria-label="show details">+</button>
 

smhigley

Fluent v9 Component accessibility docs structure

Fluent component a11y information is split across three sections, depending on relevance to the user:

1. Component Best Practices section on overview page
2. Component Accessibility section on overview page
3. Component Accessibility details page

The reason for splitting the information into different areas is to present the most concise and relevant information possible in each area of our docs. The component overview page should contain only information that authors need to know in order to implement an accessible version of our components (e.g. "provide a label), while the full accessibility details page provides a thorough description of all accessibility behaviors and choices made on the component.

Detailed breakdown of information

smhigley

Component features and behavior

This section documents out-of-the box accessibility-related behavoirs of the component.

Keyboarding

Link to the APG for standard keyboard patterns for this component pattern. Document any additions or non-standard interactions.

Key	State	Behavior