smhigley

Colors

HEX values in the theme

Name	Hex
white	#ffffff
light-grey	#f4f6f7
grey	#d6dde2
dark-grey	#5c6c7c

smhigley

import { Component, Event, EventEmitter, Prop, State } from '@stencil/core';
import { getActionFromKey, getUpdatedIndex, MenuActions, uniqueId } from '../../shared/utils';

interface SelectOption {
  name: string;
  value: string;
}

@Component({
  tag: 'combo-readonly',

smhigley

APG Coding standards

Standards for developing contributing HTML, CSS, and JavaScript to W3 WAI-ARIA APG.

smhigley

function observeElement(element) {
  const config = { attributes: true, childList: true, subtree: true };
  const callback = function(mutationsList, observer) {
    for(let mutation of mutationsList) {
        if (mutation.type === 'childList') {
          const additions = mutation.addedNodes;
          const removals = mutation.removedNodes;
          if (removals.length) {
            console.log('Child nodes were removed:', ...removals);
          }

smhigley

Uses of "descendant" in the ARIA spec

Summary

• unclear use/used on its own: 51
• descendant element: 12
• active descendant: 8
• DOM descendant: 6
• descendant node: 2

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

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

Testing Guidance for new WCAG 2.1 guidelines

1.3.4: Orientation

Quick test: resize your browser or application window between a rough estimate of portrait and landscape aspect ratios, and verify that everything looks OK and works correctly in both.

Full test: open the website or app in a tablet, and rotate the tablet.

1.3.5: Identify Input Purpose

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

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