Element in focus

In Pega table grids, you will find two input elements that are made aria-hidden (the screenshots are present below) .

Intent behind these input elements?

Keyboard navigation to table grids states that:

• Use TAB key to jump to table
• Use TAB key to jump out of the table
• Use directional arrow keys to navigate between cells of the table

Due to this navigation pattern:

• Table always has a single TAB stop.
• When navigated to table for first time, the first cell (first column of first row) takes focus.
• When moved within cells of the table and left the table keeping focus on any other cell besides the first one, then while navigating to the table again, cell having last focus retains focus back.

These two input elements are added within table to manage this focus,  improving the accessibility experience for the table. Through the focus Handler attached to these elements, the last focused element in the table is captured, before the focus goes out of the table. Then, the focus is brought back to the same element when navigated back to the table again.

Challenge identified

The input element is provided aria-hidden=”true” to make sure that it is not presented to screen reader users. In parallel, these input are given width, height and opacity as zero so that they do not take any visible space on UI.

During AXE automated test run, it is found that this functionality is getting flagged as an issue stating that input elements cannot be made aria-hidden. Basically aria-hidden=”true” cannot be provided to any interactive element. This becomes an accessibility compliance failure.

There are other CSS recommended approach to hide interactive elements, but that stops the inputs from managing the focus for which these are used.

What is WAI APG data grid pattern doing?

Similar functionality is available in the table present in WAI APG Data grid example.
In the table present in WAI website, this is achieved through manipulation of tabindex. When a cell is focused inside a table, while navigating using arrow keys, then the tabIndex of that cell is 0 and for rest all cells it is -1, preventing them from receiving focus. Now, when focus is moved out of the table using TAB key, then focus goes to the next focusable element while the last cell still has a tabIndex of 0, which helps to retain focus back while navigating to the table.

Can't the same logic be used?

This logic of tabIndex manipulation cannot be used in Pega tables, as here external cellRenderers are used and Pega tables have the capability of rendering any external component inside the cell. Table doesn’t hold any control over the markup of those components and even if the tabIndex is added from table side in the cell then in cases where external component re-renders, the tabIndex would get removed. Hence it is not feasible to go with the same approach.

Any adverse impact?

With current implementation of aria-hidden and CSS styling this functionality serves the purpose of focus management in table with having no adverse user impact.

• The presence of input is not identified by JAWS and NVDA in both arrow key navigation and TAB key navigation.
• Keyboard-only navigation is also not identifying any presence of such input.
• In Google chrome browser, with TAB key navigation a blinking cursor is observed when this input in table takes focus, but this is observed only when "Navigate pages with a text cursor" settings under accessibility settings for the browser is toggled on. Thus the setting can be turned off to avoid disturbance.
• No issue observed with other browsers.

Thus, to meet a critical product need, two input elements are used within table for focus management, made aria-hidden=”true”, which conceptually deviates from automation test check, but is implemented ensuring that it does not have any adverse user impact.