[V2] live region implementation #2581

gwyneplaine · 2018-05-02T04:08:45Z

This PR includes work to substitute the existing minimal aria-label based accessibility implementation with an aria-live-region.

We remove the following labels:

Group

aria-labelledby
aria-label
aria-expanded
role

Option

aria-selected
role

aria live region Implementation

Added an A11yText element with two children
- a string representing value events (select-option, deselect-option etc)
- a string representing context
  - focused-value
  - focused-option
  - results
  - instructions for what to do depending on where the user is focused in the select.
See inline code comments for details

gwyneplaine · 2018-06-19T01:10:23Z

src/Select.js

@@ -4,6 +4,15 @@ import React, { Component, type ElementRef, type Node } from 'react';

 import { createFilter } from './filters';
 import { DummyInput, ScrollBlock, ScrollCaptor } from './internal/index';
+import {


We import in helpers for constructing the relevant aria live messages. These can eventually be exposed as a command api like so

export const a11yCommands = { valueFocus, optionFocus, resultContext instructions valueEvent }

gwyneplaine · 2018-06-19T01:11:12Z

src/Select.js

@@ -224,7 +232,7 @@ export const defaultProps = {
  pageSize: 5,
  placeholder: 'Select...',
  screenReaderStatus: ({ count }: { count: number }) =>


Keeping screenReaderStatus for now to not break the existing accessibility API, but i think we should do away with this in favor of the more verbose pattern specified above.

gwyneplaine · 2018-06-19T01:12:42Z

src/Select.js

@@ -236,12 +244,22 @@ type MenuOptions = {
 };

 type State = {


Internally we now have two new pieces of state information.

ariaLiveContext: (a string value holding instructions for assistive tech based on the context of the user (in menu, focused on value, in input)

ariaLiveSelection: a string value holding instructions for assistive tech based on value events that occur (select-option, deselect-option, pop-value etc.)

gwyneplaine · 2018-06-19T01:24:19Z

src/Select.js

+    let focusedIndex = selectValue.indexOf(focusedValue);
+    if (!focusedValue) {
+      focusedIndex = -1;
+      this.announceAriaLiveContext({ event: 'value' });


if there is no currently focusedValue we can infer that the user is moving from the input to a focused value. We want to inform the user of the shift in context and what to do from this point onwards, hence the ariaLiveContext invocation here.

gwyneplaine · 2018-06-19T01:25:22Z

src/Select.js

@@ -536,9 +571,11 @@ export default class Select extends Component<Props, State> {
  popValue = () => {
    const { onChange } = this.props;
    const { selectValue } = this.state;
+    const lastSelectedValue = selectValue[selectValue.length - 1];
+    this.announceAriaLiveSelection({ event: 'pop-value', context: { value: this.getOptionLabel(lastSelectedValue) } });


we invoke announceAriaLiveSelection for any events to do with setting or unsetting values from the control.

gwyneplaine · 2018-06-19T01:26:19Z

src/Select.js

@@ -536,9 +571,11 @@ export default class Select extends Component<Props, State> {
  popValue = () => {
    const { onChange } = this.props;
    const { selectValue } = this.state;
+    const lastSelectedValue = selectValue[selectValue.length - 1];


just boyscouting, so we don't attempt to retrieve the same value from the array twice.

gwyneplaine · 2018-06-19T01:31:24Z

src/Select.js

@@ -635,6 +672,16 @@ export default class Select extends Component<Props, State> {
  // ==============================
  // Helpers
  // ==============================
+  announceAriaLiveSelection = ({ event, context }: { event: string, context: ValueEventContext }) => {
+    this.setState({
+      ariaLiveSelection: valueEventAriaMessage(event, context),


this calls the valueEventAriaMessage helper with the passed in event and context to resolve to the next value of ariaLiveSelection in state.

gwyneplaine · 2018-06-19T01:31:38Z

src/Select.js

+  }
+  announceAriaLiveContext = ({ event, context }: { event: string, context?: InstructionsContext }) => {
+    this.setState({
+      ariaLiveContext: instructionsAriaMessage(event, { ...context, label: this.props['aria-label'] }),


this calls the instructionsAriaMessage helper with the passed in event and context to resolve to the next value of ariaLiveContext in state.

gwyneplaine · 2018-06-19T01:35:25Z

src/Select.js

-        {screenReaderStatus({ count: this.countOptions() })}
-      </A11yText>
-    );
+  constructAriaLiveMessage () {


each invocation of constructAriaLiveMessage creates an aria live message to represent the following:

focusedValue

focusedOption

results (amount of options available) and inputvalue

ariaLiveContext

We construct this every time on render, in order for us to not have to imperatively infer value focus or option focus change in event calls or within componentWillReceiveProps. valueFocus and optionFocus can change due to any number of user interactions and non user interaction based side-effects from async loading to controlled prop changes outside of our intended scope. Likewise with results.

gwyneplaine · 2018-06-19T01:36:14Z

src/Select.js

@@ -1481,6 +1506,16 @@ export default class Select extends Component<Props, State> {
    }
  }

+  renderLiveRegion () {


if the input (and hence the select) is not focused, don't render the A11yText elements.

gwyneplaine · 2018-06-19T01:39:32Z

src/accessibility/index.js

@@ -0,0 +1,30 @@
+export type InstructionsContext = { isSearchable?: boolean, isMulti?: boolean, label?: string };
+export type ValueEventContext = { value: string };


I think it's actually better here to pass in value as an object and the function getOptionLabel as a function argument here.

This solves for Creatable select, where we need to be able to either fire an announcementEvent from the wrapping Creatable HoC, or infer whether or not a value isNew to change the returned event string. However this also requires that the user apply getOptionLabel manually, which doesn't seem great, given that it's a prop that they've passed in with the implicit understanding that we'd be handling application for them.

gwyneplaine · 2018-06-19T01:40:37Z

src/accessibility/index.js

+  }
+};
+
+export const valueFocusAriaMessage = ({ focusedValue, getOptionLabel, selectValue }) => `value ${getOptionLabel(focusedValue)} focused, ${selectValue.indexOf(focusedValue) + 1} of ${selectValue.length}.`;


see above for argument against this way of doing things. Of course, passing in the focusedValue as a string here, means that instead of getOptionLabel and selectValue, we'll probably have to pass through selectValueSize (number) and focusedValueIndex (number).

gwyneplaine · 2018-06-19T01:40:44Z

src/accessibility/index.js

+};
+
+export const valueFocusAriaMessage = ({ focusedValue, getOptionLabel, selectValue }) => `value ${getOptionLabel(focusedValue)} focused, ${selectValue.indexOf(focusedValue) + 1} of ${selectValue.length}.`;
+export const optionFocusAriaMessage = ({ focusedOption, getOptionLabel, options }) => `option ${getOptionLabel(focusedOption)} focused, ${options.indexOf(focusedOption) + 1} of ${options.length}.`;


same as above

gwyneplaine · 2018-06-19T01:41:19Z

src/accessibility/index.js

+
+export const valueFocusAriaMessage = ({ focusedValue, getOptionLabel, selectValue }) => `value ${getOptionLabel(focusedValue)} focused, ${selectValue.indexOf(focusedValue) + 1} of ${selectValue.length}.`;
+export const optionFocusAriaMessage = ({ focusedOption, getOptionLabel, options }) => `option ${getOptionLabel(focusedOption)} focused, ${options.indexOf(focusedOption) + 1} of ${options.length}.`;
+export const resultsAriaMessage = ({ inputValue, screenReaderMessage }) => `${screenReaderMessage} for search term ${inputValue}.`;


we ingest a screenReaderMessage which is the returned value of calling the screenReaderStatus prop.

…d in innerProps

…cements

…lection and deselection

…usValue

…ion and ariaLiveContext messages, added ariaLiveSelection and ariaLiveContext messages

…for focusedValue, focusedOption and results context

gwyneplaine added v2 labels May 2, 2018

gwyneplaine force-pushed the v2-live-region-implementation branch from a140d2b to 03c33e3 Compare June 5, 2018 03:54

gwyneplaine force-pushed the v2-live-region-implementation branch 2 times, most recently from a2e58fd to 9525702 Compare June 19, 2018 00:53

gwyneplaine changed the title ~~WIP V2 live region implementation~~ [V2] live region implementation Jun 19, 2018

gwyneplaine commented Jun 19, 2018

View reviewed changes

gwyneplaine force-pushed the v2-live-region-implementation branch 4 times, most recently from 9993071 to b3697d1 Compare June 19, 2018 01:22

gwyneplaine commented Jun 19, 2018

View reviewed changes

gwyneplaine force-pushed the v2-live-region-implementation branch 2 times, most recently from 2fc8985 to 695120a Compare June 19, 2018 01:29

gwyneplaine commented Jun 19, 2018

View reviewed changes

gwyneplaine requested a review from JedWatson June 20, 2018 02:32

gwyneplaine removed the WIP label Jun 20, 2018

gwyneplaine force-pushed the v2-live-region-implementation branch from 3721f93 to c6dd5d7 Compare June 22, 2018 04:39

gwyneplaine mentioned this pull request Jun 25, 2018

(v2) React-Select -No Accessibility Support when using option groups with searchable=false #2740

Closed

gwyneplaine added the needs review label Jun 26, 2018

gwyneplaine mentioned this pull request Jun 29, 2018

Fix for #2740 aria-options for option groups #2741

Closed

gwyneplaine added 16 commits July 3, 2018 12:09

remove unnecessary aria props from Input and Group components

ab42d2d

removed unnecessary aria attributes from Menu and Option

9455736

remove allytext from loadingIndicator

b7a3534

aria hidden true on indicators and svgs

8bba325

clean up flow types LoadingIndicator class, add aria-hidden to passe…

774e979

…d in innerProps

initial live-region implementation

27a7d66

accessibility wip, added focused options and inputvalue change announ…

612dd62

…cements

add utility methods for aria live region updates for option focus, se…

363d635

…lection and deselection

removed instructions from menuIsOpen and moved to focusOption and foc…

7b5089d

…usValue

react-aria-live implementation w aria-live-regions

5ccccc3

add instructions and valueEvent functions for defining ariaLiveSelect…

053edd7

…ion and ariaLiveContext messages, added ariaLiveSelection and ariaLiveContext messages

added accessibility folder, added helper fucntions for aria messages …

2b17ed4

…for focusedValue, focusedOption and results context

update cypress tests

b064304

added null checks for values passed into announceStatus

8b169af

update snapshots

8f5cb3a

updated tests to reflect changes to accessibility implementation

b8fc4c3

gwyneplaine force-pushed the v2-live-region-implementation branch from a53f33c to b8fc4c3 Compare July 3, 2018 02:18

gwyneplaine added 2 commits July 3, 2018 12:18

revert menuList innerProps removal for more consistent api

4f799ca

optimise constructAriaLiveMssage function for readability

3e066cb

gwyneplaine removed the needs review label Jul 3, 2018

gwyneplaine merged commit b3fb7d7 into v2 Jul 3, 2018

gwyneplaine deleted the v2-live-region-implementation branch July 3, 2018 03:12

gwyneplaine mentioned this pull request Jul 23, 2018

Update Select.js to meet accessibility requiremenets #2670

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[V2] live region implementation #2581

[V2] live region implementation #2581

gwyneplaine commented May 2, 2018 •

edited

Loading

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

gwyneplaine Jun 19, 2018

		@@ -0,0 +1,30 @@
		export type InstructionsContext = { isSearchable?: boolean, isMulti?: boolean, label?: string };
		export type ValueEventContext = { value: string };

[V2] live region implementation #2581

[V2] live region implementation #2581

Conversation

gwyneplaine commented May 2, 2018 • edited Loading

Group

Menu

Option

aria live region Implementation

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gwyneplaine commented May 2, 2018 •

edited

Loading