microsoft / fluentui

Fluent UI web represents a collection of utilities, React components, and web components for building web applications.

Home Page:https://react.fluentui.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Bug]: 2 Accessibility Issues in the TagPickers

NewFuture opened this issue · comments

Library

React / v8 (@fluentui/react)

System Info

System:
    OS: Windows 11 10.0.22631
    CPU: (16) x64 AMD EPYC 7763 64-Core Processor
    Memory: 36.67 GB / 63.95 GB
  Browsers:
    Edge: Chromium (126.0.2592.68)
    Internet Explorer: 11.0.22621.3527

Are you reporting Accessibility issue?

yes

Reproduction

https://codepen.io/newfuture/pen/QWRJyVG?editors=1010

Bug Description

Test with NVDA

Actual Behavior

There 2 issues:

  1. When the onEmptyResolveSuggestions return empty result. The screen reader where skip the place holder and announce the Not Found error. (So that the user can never listen the Place holder)
  2. When set the pickerSuggestionsProps.noResultsFoundText, it will announce Not Found list Not Found 1 of 1. The list ... seems a bug?

image

Expected Behavior

  1. we need a way to hide the layer for the empty state
  2. remove the list when empty data.

Logs

No response

Requested priority

Blocking

Products/sites affected

https://connectivity.office.com

Are you willing to submit a PR to fix?

no

Validations

  • Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
  • The provided reproduction is a minimal reproducible example of the bug.

This is actually intentional -- the way the "not found" text is exposed to screen readers is as an item in the listbox, via aria-activedescendant (which is how everything in the popup is exposed, since focus remains in the input). Since the "not found" text is technically a listbox option, that's where the "list" and "1 of 1" information is coming from.

The placeholder isn't read because it's not shown -- that's also on purpose, and build into NVDA's own internal logic. This isn't a bug because it's also not shown to sighted users, and technically the placeholder is still programmatically exposed, so a screen reader could decide to expose it to the user if they felt it was relevant.

Important information and labels should never be put in placeholder text because it's not consistently exposed. If you're getting bugs around the placeholder text not being read at a given point, that's probably an indication that you have information in the placeholder that should be taken out and exposed as text somewhere else, where it won't be conditionally unavailable.

Hope that helps! I'm resolving this issue as by design, but feel free to re-open or reach out on Teams if you have any other questions!