Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temporal Content Switches in Table Search and Filter #749

Closed
aphelionz opened this issue May 1, 2018 · 6 comments · Fixed by #1181
Closed

Temporal Content Switches in Table Search and Filter #749

aphelionz opened this issue May 1, 2018 · 6 comments · Fixed by #1181
Assignees
Labels
accessibility - WCAG A Level A WCAG Accessibility Criteria accessibility

Comments

@aphelionz
Copy link
Contributor

Steps to reproduce (assumes ChromeVox or similar)

image

Long story short: All of these items need to trigger screen reader events when they change the content of the table they are connected to with, at the very least, the number of rows returned as a result of user action.

  1. Open https://elastic.github.io/eui/#/display/tables in a new tab.
  2. Tab to the inputs under the "In-Memory Table - Selection" heading.
  3. Tab to the "Load Users" Button
  4. Press enter

Actual Result

silence

Expected Result

"Search|Filter complete. 8 rows returned"

Category: #688: Elastic UI Tables Accessibility
Relevant WCAG Criteria: 3.2.2 Predictable: On Input

@aphelionz aphelionz added accessibility accessibility - WCAG A Level A WCAG Accessibility Criteria labels May 1, 2018
@aphelionz aphelionz mentioned this issue May 1, 2018
5 tasks
@cjcenizal cjcenizal changed the title Temporal Contect Switches in Table Search and Filter Temporal Content Switches in Table Search and Filter Jun 5, 2018
@cjcenizal
Copy link
Contributor

This would address elastic/kibana#20200.

@snide snide mentioned this issue Sep 10, 2018
9 tasks
@PhilippBaranovskiy
Copy link
Contributor

PhilippBaranovskiy commented Apr 4, 2019

As I can see now, ScreenReader just says at the moment of focusing on search input that the future results will be filtered as the user types.
No announcement of how they have been filtered at the particular moment once the user finished typing.

I'm going to follow-up this issue as the filter button (see the screen below) needs to announce itself as well as changed results once the user toggled it.

Capture

I guess it also relates to #1184.
Initially, I started working on elastic/kibana#28385.

I would suggest that we/I should implement the on-live trigger for all that kind of cases where it needs to notify the user that something is changing on a page right now at the moment of they are typing.

Such case already exists:
Search on advanced settings: screenreader announces that results are getting filtered

@cjcenizal @snide @aphelionz @cchaos,
could you please share your thoughts, ideas, or suggestions what would be the best way to improve that accessibility occurrence?

@cjcenizal
Copy link
Contributor

@rockfield At first glance, the AdvancedSettingsVoiceAnnouncement component you shared looks fairly generic. It seems like you would be able to use this to address the accessibility problems you mentioned. What do you think? If so, then I suggest migrating it to EUI.

My only concern is that built-in delay within the component. It seems potentially very helpful, because then consumers won't need to worry about manually providing a delay each time they use the component. On the other hand, it's possible there may be scenarios where it's necessary to customize the delay, e.g. by reducing it to 0 or by increasing it. If you migrate this component to EUI, I'd suggest thinking about that aspect some more. If it seems like the built-in delay is the way to go, I would suggest at least exposing some ability for consumers to override it.

Thanks for tackling this stuff!

@PhilippBaranovskiy
Copy link
Contributor

PhilippBaranovskiy commented Apr 11, 2019

@cjcenizal, thanks for the response! and sorry for the delay from my side :)

What you typed seems very useful.
To continue your suggestion, I would propose the following functional separation:

  1. make a component-like API that is supposed to provide updated info (how many results are there now, filtered)
  2. by what it has been filtered ("search typing", "button-filters", "complex filter", and a react-referenced trigger whatever it is).
  3. presentational view, which is supposed only to render live-region and let screen reader announce the fact of changing

The 3rd option is what has been done for AdvancedSettingsVoiceAnnouncement .
The 1st option is needed to let, for instance, toggle buttons and search input at the same time trigger one unified point (component?) with updates. After that, this api component triggers presentative view to render live region.

The 2nd option is just I think maybe useful, might be skipped.

Looking at written above, I'm thinking that it seems as expanding search bar component's functionality by adding an additional tiny functional layer.

How does it sound for you?

@PhilippBaranovskiy
Copy link
Contributor

PhilippBaranovskiy commented Jun 3, 2019

To close this issue I need to update Table caption update with using component, which now is in Eui framework.

@PhilippBaranovskiy
Copy link
Contributor

PhilippBaranovskiy commented Jun 3, 2019

UPDATED: #1876 updates the table caption in file
src\components\basic_table\basic_table.js:464 so that now Screen Reader announce updates correctly by reading the whole line Below is a table of {itemCount} items., not only the updated number.

Capture

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility - WCAG A Level A WCAG Accessibility Criteria accessibility
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants