[terra-data-grid] Flowsheet keyboard navigation

[cm9361]

Summary

What was changed:
The Terra Table and Flowsheet components were updated to facilitate proper keyboard navigation within the Flowsheet data grid component.

Why it was changed:
The ability to use keyboard navigation is a core accessibility requirement of a grid control.

Testing

This change was tested using:

• WDIO
• Jest
• Visual testing (please attach a screenshot or recording)
• Other (please describe below)
• No tests are needed

Reviews

In addition to engineering reviews, this PR needs:

• UX review
• Accessibility review
• Functional review

Additional Details

N/A

This PR resolves:

UXPLATFORM-9403
UXPLATFORM-9911

---

Thank you for contributing to Terra.
@cerner/terra

[adoroshk]

I observed that if SPACE button was pressed on focused section, it does both - first opens the section, then closes it. Per discussion with @cm9361 it become clear that the second toggle is happening due to section header button being triggered as well.

I guess it can be fixed with onKeyDown event handler added to intercept a SPACE key press only:

Suggested change

	onClick={hasSectionButton ? handleClick : undefined}
	onClick={hasSectionButton ? handleClick : undefined}
	onKeyDown={handleKeyDown}

where

  const handleKeyDown = (event) => {
    const key = event.keyCode;

    // Intercept the SPACE key only
    if (key === KeyCode.KEY_SPACE) {
      onSectionSelect(id);
      event.preventDefault();
    }
  };

[cm9361]

I will have to make an update in terra-core to fix this behavior. I don't think the update should be part of this PR.

[adoroshk]

I tested the flowsheet sections keyboard navigation. Observed results:

1. The Arrow Up/Down keys navigation works as expected. If the section header is met, it gets focus. After focus leaves the section header, the next cell that gets focus keeps the original column order, which is expected behavior.
2. The Arrow Left/Down keys navigation preserved within regular cells, including when ctrl + cmd + left arrow moves focus to the section header (as it's the first cell). However, once the focus is on the first cell which is the section header, ctrl + cmd + right arrow won't move focus to the last cell, as it would for any other cell, which probably is not the expected behavior?

[kenk2]

💪 Nice use of JS to track the grid active state!

[kenk2]

Question: Will we have to account for scenarios where a cell/column header can be selected without having been reached from a mousedown or keyboard navigation? I would not think so but removing these could affect that scenario if it is a concern. I know that JAWS has a quick navigation ability so I was wondering about this.

[cm9361]

This event only triggered for the mouse down and spacebar being pressed. I think this new implementation is equivalent.

[kenk2]

Question: Why is this being commented out? We should be testing that the last available column is selected if the last focused column index doesn't exist?

[cm9361]

We should not be removing the column during the click event. We are mutating the object in the middle of an event. There should be another way to remove the column such as a button.

[kenk2]

In that case, I believe we should make a comment that this test ought to be changed. We clearly should be testing this behavior but if this was implemented incorrectly, then we should take a note of that to be addressed?

[cm9361]

I tested the flowsheet sections keyboard navigation. Observed results:

1. The Arrow Up/Down keys navigation works as expected. If the section header is met, it gets focus. After focus leaves the section header, the next cell that gets focus keeps the original column order, which is expected behavior.
2. The Arrow Left/Down keys navigation preserved within regular cells, including when ctrl + cmd + left arrow moves focus to the section header (as it's the first cell). However, once the focus is on the first cell which is the section header, ctrl + cmd + right arrow won't move focus to the last cell, as it would for any other cell, which probably is not the expected behavior?

Hi, @adoroshk - The command is Ctrl+Fn+(Right/Left) Arrow

[mjpalazzo]

Validated several examples with Edge and Chrome. Keyboard interactions are working as expected. I also tested several examples with JAWS. I was able to navigate with the screen reader and hear announcements as expected.
Great work!

[eawww]

High level check looks good. Approving to unblock Kenny but will dive deeper and log any issues found.