Background

While we've been putting years of learning from components in production (OOUI), user feedback on large scale and newest best-practices (ARIA Authoring Practices Guide, short APG) into place for Codex components development, there are a small number of vague corners that would benefit from real-user testing on our newer component suite.

Goal

Evaluate these areas with help of American Foundation for the Blind (AFB).
We are not only interested in technical implementation details, but also in user flow for people with different assistive technology (e.g. keyboard flow, verbosity in screenreaders…) to optimize their experience.

Components in question

Must-haves for a consultation:

• ButtonGroup: keyboard handling satisfying – should arrow keys be considered? T314446
• Dialog: Are our approaches and assumptions for keyboard/AT flows correct? Originally captured in T344178
  • Add aria-modal="true" to the role="dialog" element.
  • Focus on initial dialog open should work in a predictable way.
  • Putting dialogs at end of body on above behalf
  • Users should not be able to interact with content behind the dialog when open.
  • Remain with aria-hidden="true" for its wider support than only aria-modal on background elements incl script
  • Add inert as future-facing attribute for non-interactable background elements as well
  • The user always has a way to exit the dialog using keyboard navigation.
• Combobox, Lookup, Select and TypeaheadSearch: keyboard handling satisfying? ARIA exposure clear?
• Field: Questions on the component and its various features with a variety of inputs and input groups.
  • A Field with a label, description, and help text, a single input, and error handling/error message. Does the focus handling, the keyboard handling and the markup and ARIA markup, specifically around error interaction work sufficiently?
  • A Field that's a fieldset with a radio group
  • A Field that's a fieldset with two inputs (see the examples on the Field page)
• Menu: Verify our approaches T343275 & T344538 and also T324794: Consider changing handling of space key for menu components
• Tabs:
  • Followed ⇥ (Tab) + Arrow key best practices in APG. Does this meet expectations?

Consider:

• T140812: ToggleSwitch: Consider adding 'on'/'1' and 'off'/'0' like in iOS accessibility
• T314446: ButtonGroup: Implement arrow key behavior for button groups
• T341357: Disabled elements: evaluate if we want to increase the contrast ratio

Visual design questions:

• Several components: Disabled components are not strictly applying the contrast ratio requirements for ambiguous guidance in the WCAG. What is the best practice here?
  • Disabled buttons
  • Disabled Chip
  • Disabled selected Checkbox
  • Disabled selected Radio

• TextInput/TextArea
  • For controls without text (if there is no placeholder within the input) the border contrast needs to be 3:1. Since the color used, border-color-base (#a2a9b1), contrast is less than 3:1, what are the recommendations to fix here?
• ButtonGroup
  • Border and the background of each button inside ButtonGroup have a contrast ratio of 2.25:1. Might this be a concern with determining the bounds of what is interactive for each individual button?

Acceptance criteria

• DST members provide feedback on this task with accessibility questions
• Prepare a document with the context of questions to AFB – https://docs.google.com/document/d/1IPo1E3Waph9a6OtdDKWFf3blYKmEZdUnhXNeZ8PjNtA/
• Submit a request to AFB for review, see also T353179