[igx-grid] Sort Buttons are not keyboard accessible, the state is not announced to screen reader

[jamesuhl]

Description

When using keyboard only, the HTML node used for sorting the columns is not keyboard accessible and there is no accessibility code to convey to a screen reader the current state (ascending or descending) of that button

Solution

The [div class=”sort-icon”] should be a button (with a descriptive aria-label) to make it accessible. Some kind of method needs to indicate to the screen reader of its state and the direction of the column ordering (ascending or descending). I assume this can be added to the same function that adds/updates the classname of 'desc'

Alternatives

At a minimum, the aria-sort attribute could be used for the first (primary) column of the data grid that is being sorted. For multi-sorting grids, add/update the buttons aria-label to indicate “sorted ascending 1” or “sorted descending 2” (for example)

Reference

https://www.w3.org/WAI/ARIA/apg/patterns/table/examples/sortable-table/

[damyanpetev]

Thanks for the feedback, @jamesuhl !

Doing some digging around:
The keyboard accessible sort - the header itself should be accessible, since the entire header row is a single tab stop with arrow navigation across headers... except I don't see aria-activedescendant bound on the host even though the internal activeDescendant property is being updated constantly, just not reflected in the DOM. Definitely an issue there.
The other part to that would be Ctrl + Arrow Up/Down from the shortcuts https://www.infragistics.com/products/ignite-ui-angular/angular/components/grid/keyboard-navigation#header-navigation, except I fully understand there's no established KB combo for that and what we picked is not something users can just intuit. There's a whole lot more that's very custom and potentially begging for some guidance section - technically doable on app level, but might be something we can provide out-of-the-box or in the extras package.

The aria patterns so far all work by making the button the active tab stop/descendant for the header, so it's obvious Enter would trigger an action and we could consider that as well. My concern with that is those examples all feature a single interaction, we need to worry about others we have like the excel-style filter and moving menu and the expand/collapse that can be on a header. Might be missing some and perhaps the collapsible headers don't overlap with other types and we could default the action to sort, just something to consider.

As for aria-sort - indeed, though we might've chosen to avoid it beck in the day specifically due to the explicit limitation that goes like

The aria-sort attribute should only be added to a single table or grid header at a time

Since we do support multiple column sorting that doesn't quite convey what's going on to the screen reader.
Interestingly, there's just been a development on that front - w3c/aria#283 (comment)
Might need some clarification & testing if the "ARIA does not forbid sorting on multiple columns" bit is usable now, because that would technically allow us to add those attributes to all the columns and still be compliant. It might not include order, but it's better than no sort state announcement at all.

We'll have our internal discussion on all of this and update.

[jamesuhl]

damyanpetev:

Note: I'll be repeating some of the same information (word for word almost) from ticket 15847 (assigned to teodosiah)

The Infragistics 'Key Combinations' page is extremely useful. The igx-grid is more keyboard accessible than I was originally aware of. These key commands resolve the issue with the Sort buttons not being keyboard accessible. They're not intuitive, so I think I'll add an instructional guide on our website to resolve that. You might consider hosting a strip-down/bare-bones webpage on your site for developers to link to as an instructional guide for users (unless you already have one). (just a thought)

I am experiencing difficulty using the arrow navigation across headers while a screen reader is active. Below is a description of my experience, and you can let me know if this is a defect, 'out-of-our-control' problem, or a PEBKAC issue.

Here are my observations:

JAWS reads out the entire table in document mode. 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 cell's data is announced and properly associated with its column title (so this 'might' pass for 508 compliant (U.S. Law)). I am not able to access the filter button (or the sorting buttons) while JAWS is currently active.

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 out of the entire table). In order to move from one column header to the one next to it (using 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 using NVDA).

Are your screen reader testers able to navigate the table headers 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?

And, I might take this opportunity to suggest improving what is announced by the screen reader, regarding the sorting buttons.

Since the aria-sort falls short of multi-column sorting, I would like to suggest the following:

1. use aria-hidden to hide the text within the <igx-icon> for the up/down arrow graphics, and replace it with: "sort column" and append: "sorted descending", "sorted ascending" when appropriate. (a blind person could figure out what an up arrow means, but this seems more specific)
2. The superscript numbers next to the arrows are announced, I can hear them in NVDA, but they're not explained, maybe a prefix like "Priority order: 1", "Priority order: 2", etc. (I don't think there is conventional language for this)

Finally, one thing to consider regarding U.S. Law Section 508, (I'm no lawyer but) my understanding is that if a data table is not accessible, (or any component for that matter) but there is an alternative page/component that offers the same information that is accessible, then it passes the compliance test. This means that if any of your (i.e. data grids) becomes too complex for it to work in a screen reader, if you offered an accessibility 'toggle' button on the component that could re-render the table/component in basic HTML, that can resolve any compliance issue (your "get out of jail free card"). As long as any of the bell and whistles (filtering, sorting, etc.) is not a requirement to accomplish a task in a web app, then that 'toggle' feature is an acceptable fallback. Obviously, developers could build this on their own site, but if it were an optional feature of the igx-grid, it might appease your government contractor customers, or give Infragistics an "out" if you've painted yourself into a corner with complex features that screen readers cannot interpret.

If you already have this feature, then just call me an idiot and send me a link.