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

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.

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

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.

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

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.

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

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.

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.

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>
 

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.

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

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

The purpose of this gist is not to directly recommend a specific implementation of a selectmenu element, but instead to lay out how different variations in content will affect the semantics and keyboard handling needed to make it accessible.

Secondary actions refers to when individual options have actions that may be taken in addition to the primary selection action: