DataTable search bar not recognized by screen reader

[snrubnomis]

Environment

Operating system

Windows 10

Browser

Firefox

Automated testing tool and ruleset

Assistive technology used to verify

JAWS 2020

Detailed description

What version of the Carbon Design System are you using?

"carbon-components": "10.11.2",
"carbon-components-react": "7.11.3",

What did you expect to happen?

When using the down arrow to read through the page with JAWS, the search bar should not be skipped and the screen reader should read something out to indicate its existence.

What happened instead?

When reading through the page using the down arrow the search bar is skipped.

What WCAG 2.1 checkpoint does the issue violate?

2.4

Steps to reproduce the issue

1. Go to the DataTable with search in the carbon storybook: https://react.carbondesignsystem.com/?path=/docs/datatable-filtering--usage
2. Try to navigate the page with the screen reader
3. Notice that the search bar is skipped when reading the content using the down arrow to navigate

Please create a reduced test case in CodeSandbox

• Style and vanilla JS:
  https://codesandbox.io/s/github/carbon-design-system/carbon/tree/master/packages/components/examples/codesandbox
• React:
  https://codesandbox.io/s/github/carbon-design-system/carbon/tree/master/packages/react/examples/codesandbox

Issue can be seen in react storybook: https://react.carbondesignsystem.com/?path=/docs/datatable-filtering--usage

[carmacleod]

@emyarod
Try moving the role="search" aria-labelledby="1-search" up from the div.bx--search to the div with tabindex="0".
This may or may not fix the virtual cursor issue, but there are 2 reasons to do this anyhow:

• a div with a tabindex should have a role (and depending on the role, possibly also a name)
• currently, the search role is on a div that is inside an expandable area, and since search is a landmark role that the user may want to jump to, it would be better if it was on the parent that is always visible.

[emyarod]

@carmacleod I will try that out. From what I understand we would essentially also be reverting #5330 then, is that right?

[carmacleod]

I think probably the best way to fix this issue is to make the searchbox always visible. :)
The way it currently is (with the appearing and disappearing searchbox) causes multiple problems:

• smaller click target than just searchbox alone
• cognitive disconnect (I click "over here" and focus goes "over there")
• harder to notice that there's a search there in the first place
• uncomfortable feeling of not knowing what will happen when I click on that magnifying glass - will a search open "in place"? will a dialog open? will I get a drop-down?
• screen reader markup problems - I honestly don't know how to tell a screen reader that "there's a focusable div here, that when focused, will disappear, and a search input will appear in it's place, and your focus will be moved to the new input". :)

https://www.nngroup.com/articles/magnifying-glass-icon/

I guess it seems to be an Apple thing. They have some odd markup for this:

• 2 search landmarks (one containing the magnifying glass button and one containing the combobox) for 1 search feature
• the button has aria-haspopup="true" which says it's a "menu button", but it actually pops up a combobox (not a menu)
• when the button is pressed, the whole nav is hidden (including the button), the rest of the page is aria-hidden, and tabs are trapped so that the user stays in the search combobox, so this is basically a dialog (without actually being marked up as one)

An always-visible search input would be easier to understand (particularly as it is more of a filter for the table than a search), and it wouldn't have this virtual cursor issue, and it would fix the "hidden search landmark" problem as well. :)

[carmacleod]

From what I understand we would essentially also be reverting #5330 then, is that right?

Not all searches need to be landmarks. Really, all landmark design should be up to the author of the particular page, and ideally not a part of a component library.
Typically, there would be just 1 or 2 search landmarks on a page (usually one for the whole site, but if there's another one, it might be for some particular aspect of a page).
If there were 16 Carbon data tables with searches on a page, then there would be 16 search landmarks, which would be sub-optimal.
If, however, there were only 1 or 2 Carbon data tables, it would still be best if the author could decide whether or not the data table searches were important enough in the context of that page to be marked up as search landmarks.
Can Carbon consumers (aka page authors) decide whether or not they want a particular search to be a landmark?

[emyarod]

Can Carbon consumers (aka page authors) decide whether or not they want a particular search to be a landmark?

currently the landmark role is applied automatically by Carbon, so it sounds like it may be best to make that user-configurable

regarding the topic of making the data table search bar always visible, cc @carbon-design-system/design regarding this proposal. in the meantime I can explore different methods for keeping the same visual style with more accessible markup

[mashenka123]

@emyarod Could you please confirm when this bug could be fixed?

[emyarod]

you can refer to the ongoing discussion in this thread to track its progress at the moment