Clarity: Keyboard Interaction for a datagrid component

Created on 13 Jun 2018  路  12Comments  路  Source: vmware/clarity

[X ] feature request
[X ] enhancement

Expected behavior

Keyboard Interaction for the datagrid component with arrow keys
https://www.w3.org/TR/wai-aria-practices/#grid

Hierarchical data grids is good to support collapsed and expanded row states and to have ability their rowes to be expanded/collapse through keyboard interaction

Environment details

Angular version: 4.x.x

Clarity version: 11.0.1

OS and version:**

Browser:all

tracked by a11y accessibility

Most helpful comment

I wanted to give at few quick examples of why this is a complex request. We have to consider all of the potential edge cases and scenarios before we can proceed.

Putting keyboard navigation into the datagrid raises a lot of questions about _how_ the keys should behave, _what_ should be in focus, and _who_ is responsible for orchestrating it (Clarity or the app). The best behavior for the datagrid and keyboard navigation is also likely dependent upon the content of the datagrid, which Clarity has no knowledge of.

1) Imagine a selection datagrid with whole-row selection, there is no reason to have right/left navigation because you can only click on the row itself. So in this case, we'd likely use only up/down keys for navigation and space for selection.

2) If a datagrid row has interactive elements, such as buttons, inputs, or signposts, focusing on the cells themselves doesn't make sense. You'd need to be able to navigate through the interactive elements, but those are controlled on the app side and not part of the datagrid. That makes it very challenging to understand how this would work, but it would most likely require the application to do some heavy lifting to manage navigation since Clarity cannot know ahead of time what a cell contains.

3) Filtering and sorting create additional questions, when you open the filtering box what should the behaviors be and do things close? We need some UX research to understand these behaviors and how they are truly accessible or not.

In short, I fear we'd have to either limit capabilities so we can better support known cases or expect apps to implement the keyboard navigation patterns that fit their use cases. More examples and clarification is needed though about use cases and examples to define the scope.

All 12 comments

We are indeed missing some ARIA attributes, but please note that basic keyboard interaction is already available through focus and activation. Every single one of the interactive pieces of the datagrid can be activated with the keyboard only. More advanced keyboard interactions are not on our plate right now, mostly because of potential conflicts between components (dropdowns will soon support up/down arrow navigation, and you can easily have a dropdown inside of a row).

Thank you for the info. I think it will be good if possible to be provided arrow key navigation for the grid.
It is good also the component to provide ARIA roles otherwise I think the screen readers will not read the data correctly. I know that these can be done by the users of the clarity library but it will be very helpful if this can be done by component at least for some of the ARIA roles.

I wanted to give at few quick examples of why this is a complex request. We have to consider all of the potential edge cases and scenarios before we can proceed.

Putting keyboard navigation into the datagrid raises a lot of questions about _how_ the keys should behave, _what_ should be in focus, and _who_ is responsible for orchestrating it (Clarity or the app). The best behavior for the datagrid and keyboard navigation is also likely dependent upon the content of the datagrid, which Clarity has no knowledge of.

1) Imagine a selection datagrid with whole-row selection, there is no reason to have right/left navigation because you can only click on the row itself. So in this case, we'd likely use only up/down keys for navigation and space for selection.

2) If a datagrid row has interactive elements, such as buttons, inputs, or signposts, focusing on the cells themselves doesn't make sense. You'd need to be able to navigate through the interactive elements, but those are controlled on the app side and not part of the datagrid. That makes it very challenging to understand how this would work, but it would most likely require the application to do some heavy lifting to manage navigation since Clarity cannot know ahead of time what a cell contains.

3) Filtering and sorting create additional questions, when you open the filtering box what should the behaviors be and do things close? We need some UX research to understand these behaviors and how they are truly accessible or not.

In short, I fear we'd have to either limit capabilities so we can better support known cases or expect apps to implement the keyboard navigation patterns that fit their use cases. More examples and clarification is needed though about use cases and examples to define the scope.

While keyboard interaction is only one of the ways to address accessibility concerns (among other like Theme Contrast, Screen Readers, ARIA attributes, Rows virtualization, etc.) i think the following features should be provided at least as a minimum (compared to some other popular component libraries' accessibility support) :

  1. Using arrow keys the focus should be moved between cells, if the selected cell is already on the boundary for that position the key press has no effect.
  2. Using some key combination (Ctrl + left/right) the focus should be moved to start and end of the line
  3. Using page up/down keys to scroll up/down the page
  4. Using Home and End keys to go to the first and last row.
  5. Pressing Space key on a cell should select the cell's row
  6. Pressing Enter key on a group element should expand/collapse the group.
  7. When the focus is on the column title, pressing Enter should sort the grid asc/desc consecutively (i see that this is already supported by the Clarity grid)

Hi @mibryamov
This is a good start. But the UX issues and edge cases @gnomeontherun has raised remain.

We can't dive into implementation until we have a reasonable path forward on these edge cases. Otherwise, we risk creating a mountain of rework and confusing our end users with shifting patterns and breaking changes.

@gnomeontherun @mathisscott @jaffoneh @mibryamov

Talked with @mathisscott about this ticket this morning and promised to get back to him with a reconciled list of requests

1) I really like @mibryamov list of suggestions above. A few thoughts:

a) We should look at supporting gestures in addition to just keystrokes - some people who are blind use a keyboard to page down, others prefer to do a three-finger vertical swipe up and down on iOS

b) We need to make sure the keystroke combinations we choose satisfy the new requirements in WCAG 2.1.4 https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts.html

c) We need to discuss how users would be made aware of this behavior

2) To answer one of @gnomeontherun questions

Imagine a selection datagrid with whole-row selection, there is no reason to have right/left
navigation because you can only click on the row itself. So in this case, we'd likely use only
up/down keys for navigation and space for selection.

Yes I think this is fine, optimally you could throw an error if a different key is pressed that "only up/down is supported for your current object" or something like that.

3) To address a second question regarding filtering, we should have a talk - if you can show me the existing filtering behavior and talk about future plans, I can give you guidance about the best way of handling it. I did guide implementation of a filtering system I kind of like in the shop.safeway.com search results. I know, it's food, not 10s of thousands of rows, but it's a starting point.

@sheribyrne
Here is a link to the new datagrid filtering proposal.

The existing filtering can be seen here.

Re: @mibryamov's suggestions, I have some thoughts as well

Using arrow keys the focus should be moved between cells, if the selected cell is already on the boundary for that position the key press has no effect.

How does this impact scrolling? Currently when focus is inside a datagrid up and down arrow keys enable users to scroll in the datagrid. It seems like we are overloading arrow keys here and introducing and unexpected (perhaps unwanted?) behavior with this suggestion.

Using some key combination (Ctrl + left/right) the focus should be moved to start and end of the line

This is fun. But how would people know about it?

Using page up/down keys to scroll up/down the page

Datagrids already do this when focused.

Using Home and End keys to go to the first and last row.

Datagrids scroll top-to-bottom now when Home/End keys are pressed. Is the recommendation here to move focus?

Pressing Space key on a cell should select the cell's row

Not sure what to do here. Presently, we tab through actionable elements and a single row may have multiple actionable elements.

Pressing Enter key on a group element should expand/collapse the group.

Wouldn't this conflict with the native execution of focused elements in a datagrid row?

When the focus is on the column title, pressing Enter should sort the grid asc/desc consecutively (i see that this is already supported by the Clarity grid)

Yes. We already do this.

Guys, are you planing any effort on this in some of the next releases ?

@bashibozuk
Not for 3.0. This effort would require non-trivial (and many breaking) changes to the datagrid and no one has answered my last response about these features. There are a lot of feature requests in this ticket and not all of them are clear and many of them conflict with existing accessibility guidelines that we are presently following.

Keyboard Interaction for a datagrid component is covered https://github.com/vmware/clarity/issues/3349

If we want to add hierarchy to grid I recommend to create a new component following the implementation at https://www.w3.org/TR/wai-aria-practices-1.1/#treegrid.

Hi there, this is an automated message.

In an effort to dedupe and track accessibility reports consistently, this issue is being closed and tracked internally with our Accessibility team. It will still be triaged and addressed as part of ongoing work.

Hi there 馃憢, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.

Was this page helpful?
0 / 5 - 0 ratings