Accessibility issue: Focusable grid body element missing consistent ARIA role (tabindex="0" without role)

[mehmetardin]

I have a question regarding an accessibility issue in the Grid component, identified using the ARC Toolkit.

Description:
A focusable

element within the grid body uses tabindex="0" but does not consistently define a semantic role. When dataView.length > 0, the current binding:

[attr.role]="dataView.length ? null : 'row'"

removes the role attribute, leaving a focusable element without a defined purpose for assistive technologies.

Accessibility Warning (ARC Toolkit):

The element has been placed in the tab order using tabindex="0", but it lacks a specific role="..." attribute.

Reference:
grid.component.html – line 34

Could you please confirm whether this is the intended behavior or if the grid body should consistently include a semantic role (e.g., role="rowgroup") to comply with ARIA grid accessibility guidelines?

Thank you!

[ddaribo]

Hi @mehmetardin,

I have been looking into your question, and I can see the mentioned error, as well as the same for the “igx-grid-header-row” and some elements of the footer. You are observing those as well, aren’t you?

What I can say is that these could generally be qualified as a false positives by the automated tool in the context of a complex widget as the grid. Both the grid body and header row elements receive focus, which is programmatically delegated to a cell or column header. So, these semantic elements to which the focus is delegated are what is communicated to a screen reader user, also what is observed as the currently interactive/focused element by regular (or keyboard) users.

For your particular question, the related elements are currently rendered like:

1. For an empty grid, the element with class "igx-grid__tbody" has a role “rowgroup” and its direct child with class "igx-grid__tbody-content" (also having tabIndex=0) has the role=”row”. This is valid according to the automated a11y tools. However, in that case for example, a tool would also produce:
   Table headers are missing associated cells
   Description: Some table or grid header elements are not associated with a corresponding cell in the same table or grid.

This would definitely qualify as a false positive, since this is the design of the grid, where the structure of the data is displayed, while there are no records. No need to render any empty cells here.

2. For a grid with data, obviously the "igx-grid__tbody-content" does not have the “row” role as it now contains many rows, hence the error.

In conclusion, while it is possible that the team addresses some of these a11y errors by altering the roles to fit in these scenarios, I wouldn’t be convinced this is absolutely necessary and would contribute to anything other than resolving these errors. Still, if you have any further considerations on the matter, please do share them and in that case we could proceed with logging this to be addressed in the library.

[mehmetardin]

Hi,

Thank you for the detailed explanation. Please see the additional errors identified by the ARC Toolkit below.

[ddaribo]

@mehmetardin, Thank you for following up!

Indeed, the tool would error with this in case the header row or the grid body have an active (focused) cell. This is inherent to the grid implementation, where as mentioned in my previous reply, both the grid body and header row elements receive focus, which is programmatically delegated to a cell or column header. The aria-activedescendant points to the actual active element. It is the one announced by screen readers and properly communicated to the user.
The benefit of this approach in the IgxGrid is that the header and the body are single tab stops. By not using tabIndex on each column header and cell, users can easily navigate out of and back into the grid with a few tab stops. Moreover, there is logic in the grid that keeps the last active node among those two regions, so the user would land on it on navigating back and forth. In a high-performant and virtualized grid as this, ensuring quick navigation is one of the considerations behind this design.

Having said this, I have tested applying some alternative roles, however, trying to appease those automated accessibility validators seems to inflict a cause-effect chain, where yet another error would be thrown each time.
I was personally not able to identify a role in the ARIA-spec accommodating this scenario and such a “focus-wrapper” element of a composite widget so far.
Still, as the aria properties ultimate purpose, in addition to semantics, is usability for visually impaired people, I encourage you to test this particular flow in the grid with a screen reader and verify the announced active elements.
Let me know what you think.

[mehmetardin]

As shown in the screenshot, although the table contains data, the selected

element is assigned a tabindex="0" attribute but lacks a corresponding role attribute. This issue is flagged by the ARC Toolkit as a violation of WCAG 2.1 Success Criterion 4.1.2 – Name, Role, Value.
For reference: WCAG 4.1.2 – Name, Role, Value

[ddaribo]

Hi @mehmetardin,
Yes, this is in line with the explained above - this wrapper receives focus and programmatically delegates it to an active cell through custom logic and the aria-activedescendant attribute.
I am wondering if you've had the chance to test the grid navigation and screen reader announcements, as suggested?
Are there any other considerations regarding these errors?
As mentioned, some of the scenarios could be targeted, however not all, since the ARIA spec currently lacks a dedicated role for such wrapper elements, hence the tools consider it as error. Assigning other roles would either generate different errors, or lead to misannouncement of the structure.

[mehmetardin]

Hi @ddaribo,

You can find the screen reader announcement in the attached video. When the table receives focus, the screen reader is able to read it. However, when the focus moves to the header using the Tab key, the screen reader does not announce anything. When the focus then moves to the rows, the screen reader reads the cell values correctly, but announces the wrong row number. For example, it says “row two” when the focus is actually on row one.

Screen Reader: JAWS

Jaws-screen-reader-video-record.mp4

[ddaribo]

Hi @mehmetardin,
Thank you for the recording.

Could you please specify which version of Ignite UI for Angular is your app targeting in this case?
I am asking this, as there has recently been an effort to improve just this area of the grid. Please, check out this issue for more information. It was addressed in versions 19.2.x, 20.x. and upwards.
Testing the documentation samples, i.e. here, with JAWS, column headers are properly announced:

Recording.2025-11-04.173720.mp4

[mehmetardin]

Current version: 19.1.6

I also tested with version 19.2.31, but the behavior remains the same. I’ll try again with version 20.x and update you on the situation afterward.