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

smhigley

Content variations & semantic structure in selectmenu

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.

1. Secondary actions on options

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

smhigley

Secondary Actions Proposal

This is a both an explainer for why a secondary actions proposal is needed, and a draft of the proposed change to the ARIA spec.

Original issue: w3c/aria#1440

Jump straight to the Proposal

What are secondary actions?

smhigley

Manual Accessibility Review Steps for Fluent Components

Accessibility review checklist, with detailed steps below. Skip any tests or sub-tests that you do not feel comfortable evaluating, and either pair with or hand off the issue to an accessibility SME for any remaining items.

Note: these checks are geared towards catching component-level accessibility issues. They are not comprehensive, and this is not the correct checklist for evaluating page- or app-level accessibility.

• Color contrast: the text meets required contrast, and all states (e.g. selected, focus, etc) meet 3:1 contrast
• High contrast mode: the control is understandable in high contrast mode in all states
• Zoom and reflow: the control is still visible and functional when zoomed in
• Pointer access: hover states are not required to understand or operate the control