[igx-grid] [igx-chips] Filter button in table is not keyboard accessible

[jamesuhl]

Description

The "filter" buttons in the Table Grid component can not be accessed using only the keyboard.

Solution

Make the Filter button keyboard accessible by using an HTML button tag

Describe alternatives you've considered

the Filter chip element should be a <button> or at least have a role="button" and a tabindex. The current role attribute is "listbox" which is not correct. (a list box* is the equivalent of the <select> tag.)
Also: each filter button should be unique, appending the name of the table column header is ideal such that the aria-label reads "Filter {{col_Name}}"

*Info about listbox role: https://www.w3.org/WAI/ARIA/apg/patterns/listbox/

[teodosiah]

After looking into this, what I could say is that the tabulations in the IgxGrid are reduced by design and the currently introduced tab stops are the following:

• GroupBy or Toolbar area (if enabled)
• IgxGrid header
• IgxGrid body
• Column summaries (if enabled)
• IgxGrid paginator (if enabled)

When the IgxGrid header container is focused, the column headers can be traversed with the arrow keys (which would activate the column header but this is not the actual focus) and the column actions like filtering, sorting, grouping and etc. can be triggered by different key combinations described in the Grid Keyboard Navigation topic - here.
Regarding the filtering, I could say that by design the chip is focusable element, however, having in mind the behavior described above, we are setting its tab index to -1 in our code and the filtering UI could be opened when a column header is activated and the Ctrl + Shift + L is pressed.

[jamesuhl]

teodosiah:

Thank you for providing me the link to the Infragistics 'Key Combinations' page. I was not aware of these key combinations. These key commands resolve the issue with the Filter button not being keyboard accessible.
Reducing the tabulations does make the table navigation less intuitive, as it requires the user to know what the key combinations are, but I'm not sure how that can be avoided. We can provide the key combination instructions on our own web site to resolve that.

There's a couple of observations I noticed, this may be suitable for a feature request--outside the scope of this ticket (?).

The key combinations work without a screen reader, but once I turn on the screen reader I get a few anomalies. Here are my observations:

JAWS reads out the entire table in document mode (awesome). But as I manually navigate the table header with the left/right arrow keys, the focus indicator (magenta border) moves but JAWS does not announce the column headers (nothing is announced). However, once I move into the body of the table the table cell's data IS announced and properly associated with its column title. I am not able to access the filter button (or the sorting buttons) while JAWS is in use.

NVDA however, does allow me to access the functionality within the column header (sorting, filtering) using the up/down arrow keys. So that's better than JAWS! But I am having trouble moving across the table header (The left/right arrow keys seem to move me out of the entire table). In order to move from one column header to the one next to it (in NVDA), I have to move down into the table's first row, travel to the right, then move back up into the header. (In other words, I can't move left to right or right to left across the table header).

Are your testers able to navigate left-to-right and right-to-left while a screen reader is on? If so, what am I doing wrong? If not, does this constitute a defect?

Finally, I might take this opportunity to suggest improving what is announced by the screen reader, regarding the sorting and filtering buttons. The igx-chips-area component has an aria-label="chip area". Which doesn't really mean anything, it's just "noise". The igx-icon component announces "filter list" which is somewhat useful. At a minimum, the aria-label could be removed. The sorting arrows are also announced as "up arrow" and "down arrow" because that's the description text in the DOM. It would be nice if these said "Sort column, sorted ascending", "Sort column, sorted descending", etc. Something to better improve it's purpose/function.