!Accessibility Blocker: Kendo Grid is reading table twice.

[Akash]

Hello Team,

We are currently facing challenges with the Kendo grid, which is a widely used widget or component at o9Solutions. Although we have been using Kendo for a long time, the widget is failing to meet accessibility standards for some components, which are crucial in today's world.

Regarding the Kendo grid, there is an issue where SR is reading the table twice, once for the header and once for the cells. This can cause confusion for assistive technologies like SR.

Consider the cases of horizontal scroll or fixed column cases also.

Having a single <table> is the standard. We can't create multiple tables, which will violate the good coding practices + accessibility standards.

---

I saw some posts regarding this... where it was mentioned we can remove this Scrollable() . But what are the cons of this if we remove this?
--

 

We want this functionality like a horizontal or vertical scroll or fixed column cases.But it needs to recognize as a single table.

Case: Frozen [Name and hometown ..enabled locked flag]. It's considered as 4 table.

https://dojo.telerik.com/oXoroDav

 

Case 2: normal one. It's considered as  2 table.

Dojo: https://dojo.telerik.com/@naseer743/eyeVuCep

 

[Peter Milchev]

Hello Akash,

Please enable the keyboard navigation of the Grid via the navigatable: true property. That would improve the keyboard accessibility and also apply additional aria attributes. 

• https://docs.telerik.com/kendo-ui/api/javascript/ui/grid/configuration/navigatable 

In general, the physical tables are negated with role=none and all the screen reader should know about is the non-locked content table. It contains all the needed aria-owns attributes to represent properly the rows in the locked table and the header tables.

Regards,
Peter Milchev
Progress Telerik

[Akash]

Will u please tell me where i need to put role = none? Or will u share the dojo?

If I put role = none in all the tables, then it'll recognize as a table.

I see there is no outer role = grid or table.

[Peter Milchev]

The roles will be added internally from the grid itself, you just need to set the navigatable: true property in the grid configuration:

• https://dojo.telerik.com/@pmilchev/OnoPacic 

• $("#grid").kendoGrid({
    navigatable:true,
    columns: [
      { field: "name", width: 200, locked: true },
      { field: "age",width:200},
      { field: "hometown",width:200 },
      { field: "siblings",width:200 }
    ],
    dataSource: [
      { name: "Jane Doe", age: 30, hometown: "Sofia, Bulgaria", siblings: 3 },
      { name: "John Doe", age: 33, hometown: "Boston, MA, USA", siblings: 1 }, { name: "John Clark", age: 33, hometown: "Boston, MA, USA", siblings: 2 }
    ]
  });
  var grid = $("#grid").data("kendoGrid");
  grid.lockColumn("hometown");

[Akash]

navigatable true is for keyboard right? We don't have any issues with keyboard support.. that's working correctly. Issue is present with semantics 

As you've mentioned we need to add role = none to nested grid. Because currently screen reading is identifying as 4 different table for one table.

so, we're asking if we put role=none where <table> is present then it'll not recognise as a table.

 

[Peter Milchev]

To make the Grid fully accessible, an improved keyboard navigation(especially for the more complex configurations) is required along the semantic attributes of the various tables. 

That is why you need to have navigatable: true to get the Kendo Grid to be fully accessible, both for keyboard navigation and aria attributes.

[Akash]

But after doing this also, <table> tag is repeating and it's creating confusion for Screen reader or DOM Accessibility tree which read by the assistive tech

 

[Peter Milchev]

Hello Akash, as you can see, although there are a few table elements rendered, only the important one has the role=grid, while the others have the role=none, which hides them completely from the assistive technologies.

According to the ARIA standard, using attributes is the correct way to handle complex scenarios where the accessibility cannot be achieved with an HTML structure only. 

[Akash]

yes got it.

So even when we fix the left side, there is still no issue in that case. Right?

[Peter Milchev]

Yes, there should be no issues. You can inspect the rendereded rows and see the cells for the row are listed in the aria-owns attribute so the assistive technologies consider these elements as direct children of the row, despite the cell elements actually belonging to a completely different table element:

<tr class="k-alt k-table-row k-table-alt-row k-master-row" data-uid="df84cfc6-38e5-4995-823b-ed9907c1b265" role="row" aria-owns="dd56f052-e41b-4250-8f11-115c10a8670b_locked_datacell_1_0 dd56f052-e41b-4250-8f11-115c10a8670b_datacell_1_0 dd56f052-e41b-4250-8f11-115c10a8670b_datacell_1_1 dd56f052-e41b-4250-8f11-115c10a8670b_datacell_1_2">
<td class="k-table-td" role="gridcell" id="dd56f052-e41b-4250-8f11-115c10a8670b_datacell_1_0">33</td>
<td class="k-table-td" role="gridcell" id="dd56f052-e41b-4250-8f11-115c10a8670b_datacell_1_2">1</td>
</tr>