Accessibility via Screen Reader issue in jQuery KendoUI PanelBar

Progress® Kendo UI® for jQuery Feedback Portal

Create an account Log In

Back to Feed

Request a Feature Report a Bug

Declined

Last Updated: 26 May 2021 11:24 by ADMIN

Chirag

Created on: 08 Apr 2019 13:26

Category: PanelBar

Type: Bug Report

Accessibility via Screen Reader issue in jQuery KendoUI PanelBar

We are working on enterprise product, which uses Progress Telerik jQuery KendoUI components extensively purchased by our Company. In which Kendo PanelBar is used in many modules of our product.

Now a days we are working on Accessibility (i.e. keyboard and screen reader) as part of out-of-box feature of our product.

The Kendo Panel Bar has been made accessible so that it can be navigated using the keyboard arrow keys, once it receives focus via Tab Key.

We have created small example on dojo.telerik.com (i.e. which can be referred on https://dojo.telerik.com/@chiragvidani/EBEPUnoY/3) to explain issue faced by us, when accessing via Screen Reader. Please find issues below:

When the panel bar is initialized in expanded state and on receiving focus by Kendo PanelBar widget, screen reader reads Header as well as Content. Now because of this, content is read twice (i.e. second time when we navigate to content using down arrow keys one at a time). Whereas behavior in collapsed state is as expected.
Also, to read out the expand/collapse event of PanelBar we need to programmatically remove role attribute from <ul> and <li> tags after initialization of widget.

Secondly when referring WAI-ARIA practices on www.w3.org website (i.e. https://www.w3.org/TR/wai-aria-practices/examples/accordion/accordion.html), we found some differences as explained below:

Header of PanelBar or Accordion is surrounded by <button> inside <h3> (i.e. reference link is https://www.w3.org/TR/wai-aria-practices/#accordion)
Content of PanelBar or Accordion has an aria-labelledby attribute with value containing ID of respective Header.
In WAI-ARIA website PanelBar or Accordion is generated using combination of relevant <div> markup, whereas in Kendo, its generated using <ul> and <li> markup.
In current implementation of Kendo PanelBar, focus is set to <ul>, whereas in demo of w3.org website its being set to <button> placed as a header in order to restrict reading of list keyword.

Kindly help us with your assistance.

Thanks,

Chirag Vidani

6 comments

ADMIN

Veselin Tsvetanov

Posted on: 26 May 2021 11:24

Hi,

So far we have not received an example where the PanelBar generates invalid HTML. As there is not enough information that would allow us to replicate any bug in the PanelBar we are closing the current item.

As per the other topics discussed in the thread:

- Using <h> tags in the widget could be achieved by setting the item text to an HTML (text: "<h1>Item 2</h1>") and setting its encoded option to false. Here is a Dojo sample demonstrating that approach:

https://dojo.telerik.com/ElOhodey/2

- We have also reviewed the possible use of the aria-controls attribute. So far we could not see any benefit from using it to point to a nested element.

Regards,
Veselin Tsvetanov
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

ADMIN

Veselin Tsvetanov

Posted on: 25 Apr 2019 06:56

Hi Siddhant,

Here are the remarks on your notes:

Concerning the Menu like behavior of the Kendo PanelBar, what you have observed and what is reported by the screen reader is intended by design. The PanelBar is intended to be one of the Navigation widgets available in the Kendo suite. That could be seen from how its articles are placed within our documentation (they are in the "Navigation" widgets section). That is a design-time decision, which makes the PanelBar widget a component, that is different from the WAI-ARIA Accordion.

As per the headings configuration, that may be an appropriate option for the widget. We will review the viability of such approach and will consider its introduction.

May I ask you to share with us an example of PanelBar widget, which has generated an invalid HTML? In the referred Dojo, the structure of the widget is the following:

<ul data-role="panelbar">

<li>

<span>

<span>Details</span>

<span></span>

</span>

<ul>

<li><span>Q1 Forecast</span></li>

<li><span>Q2 Forecast</span></li>

<li><span>Q3 Forecast</span></li>

<li><span>Q4 Forecast</span></li>

</ul>

</li>

<li>

<span>

<span>History</span>

<span></span>

</span>

<ul>

<li><span>Q1 Forecast</span></li>

<li><span>Q2 Forecast</span></li>

<li><span>Q3 Forecast</span></li>

<li><span>Q4 Forecast</span></li>

</ul>

</li>

</ul>

As per the focusing logic, what you have described is exactly what we are doing internally in the PanelBar. The wrapper <ul> element is the focused one, while it uses the aria-activedescendant attribute to point to the currently active item. What issue have you observed with such an approach?

Let me explain a bit in detail why the aria-controls attribute is not used with the current rendering of the PanelBar. As you can see the above structure, the PanelBar widget represents an unordered list. Each item in that list (<li> element) can be the currently active element. In its content, each active element (item) can have a header section (<span>) and content (can be <div> or another <ul> element). When the first level item in the PanelBar is active, that means that the entire <li> element is active (containing both the header and the content). If we are going to use the aria-controls attribute, we would have to set it on the <li> element (the active one) and we should point to its inner content element (either a <div> or a <ul>). This way the <li> element will point inside itself. By now, we have considered such an approach as redundant. Nevertheless, we will review the possible use of the aria-controls attribute. As you have said, that may lead to improvement of the screen readers performance of the elements inside the widget.

Regards,
Veselin Tsvetanov
Progress Telerik

Get quickly onboarded and successful with your Telerik and/or Kendo UI products with the Virtual Classroom free technical training, available to all active customers. Learn More.

Siddhant

Posted on: 18 Apr 2019 10:43

Kendo comments:

"You will also notice that I am keeping the properly assigned role attributes in the widget. I have tested that demo in Firefox with NVDA reader. It properly announces the state and the currently focused item within the widget "

My comments:

On verifying the example at https://runner.telerik.io/fullscreen/eBosicOH, each item is announced as menu. One should understand that role menu, menubar, menuitem comes in picture only to provide a choice of "actions" that user can perform. Take for example Windows OS>Notepad>Menubar>File Menu > Open menu item - user wants to perform "Open file" action. You will observe that menus will get used likewise in Google Drive> Spreadsheets>File Menu as well. Other use case for these menu related roles is Site Navigation menus where user wants to perform of visiting some section of website. These could have easily been simple set of links within ul/li but nested lists of links again carry problem of multiple tabs within navigation bar itself to get passed it.
In fact, putting menu related roles creates confusion about kind of widget and its expected behavior for SR user. It is the role attribute which will provide the correct semantic information to Screen Reader which will help user to identify the way widget will behave.

Kendo comments:

"As the PanelBar widget could be placed at any place on the page, it avoids the use of <h> elements that may break the semantic logic of the HTML."

My comments:

I certainly understand your concern. I would like to know the feasibility of providing some initial configuration where one could instantiate the widget with custom heading levels. It is assumed you might provide default role="heading" and developer would have the choice to specify custom value for aria-level which you might set internally.

Kendo comments:

"c. The <ul> and <li> elements in the Kendo PanelBar are used to semantically structure its hierarchical structure."

My comments:

It is absolutely fine to have ul/li elements unless you aren't making it like ul>div/span/anything>li kind of structure as that breaks the HTML semantics and would flag up in HTML validators. WCAG 2.1 Success Criteria 4.1.1 (level A compliance) needs parsable markup.

Kendo comments:

"d. The focus is set on the PanelBar widget element (the <ul>), so that the Tab and Shift + Tab element will properly navigate to and away from the PanelBar widget, instead of navigating among the PanelBar inner items."

My comments:

In your example, why doesn't this happen? Because you are using a composit role of "menu" on the ul element which in turn exposes aria-activedescendent child. This makes the child as the semantically focused element and not the parent ul as the focused element. The roles have influenced the naming. The focused element (indicated by aria-activedescendent) is the li having "details" as its name. This is determined by Inner HTML of that li element.

Kendo comments:

"At the moment, the use of the aria-controls attribute would be redundant, as the content of each item belongs to the same element that contains its header."

My comments:

This isn't the correct justification to avoid aria-controls. The aria-controls allows Screen Readers like JAWS for instance to have their own custom implementation to allow SR user to jump from header to content easily. What you are specifying sounds closer to aria-owns although not exactly. The aria-owns property needn't be specified on parent node if the child node is contained within the parent node. If child node isn't inside parent node and such parent>child relationship needs to be established, aria-owns serves the purpose. In our case, even from aria-owns standpoint, parent and child happen to be siblings.

ADMIN

Veselin Tsvetanov

Posted on: 18 Apr 2019 09:14

Hello Chirag,

We have carefully examined the suggested practices and how they fit in the DOM structure of the Kendo PanelBar. At the moment, the use of the aria-controls attribute would be redundant, as the content of each item belongs to the same element that contains its header. We use the aria-hidden attribute instead to determine which sections of the respective pane should be announced by the readers and which should not.

Similarly, in the current rendering the PanelBar widget, the elements in it are configured to be items rather than a combination of buttons and panes. Each item contains a header and a content element, which is announced only when it is visible. Such approach has some benefits over the suggested in the practices. For example, the number of items is known for the readers and they can announces that to the used (e.g. "item one of four").

That is why we do not have current plans to alter the PanelBar rendering. Nevertheless, if you face any specific screen-reader related issues with the PanelBar, please share them. This way, we will be able to address those in a proper way.

Regards,
Veselin Tsvetanov
Progress Telerik

Get quickly onboarded and successful with your Telerik and/or Kendo UI products with the Virtual Classroom free technical training, available to all active customers. Learn More.

ADMIN

Veselin Tsvetanov

Posted on: 15 Apr 2019 09:22

Hi Chirag,

Concerning the first question, I have slightly modified the sample in question, so it properly implements a nested hierarchy in the PanelBar widget. Here you will find the modified version. You will also notice that I am keeping the properly assigned role attributes in the widget. I have tested that demo in Firefox with NVDA reader. It properly announces the state and the currently focused item within the widget ("Details, expanded, one of two."). It does not read all nested items when an expanded item has been focused. May I ask you to test this sample and let us know what you have observed? Also, which is the browser and the reader you are testing with?

As per the second case:

a. The example in question " ... uses heading level 3 so it fits correctly within the outline of the page; the example is contained in a section titled with a level 2 heading.". As the PanelBar widget could be placed at any place on the page, it avoids the use of <h> elements that may break the semantic logic of the HTML. The Kendo PanelBar, however, does not use role heading and role button for the elements that control the content opening/closing. As far as I can see, that is a violation of the practices described here. Also, the use of a button input element may be needed. That is why we will further review this case.

b. The use of the aria-labeledby attribute is not mandatory. The practices say that "Optionally, each element that serves as a container for panel content has role region and aria-labelledby with a value that refers to the button that controls display of the panel."

c. The <ul> and <li> elements in the Kendo PanelBar are used to semantically structure its hierarchical structure.

d. The focus is set on the PanelBar widget element (the <ul>), so that the Tab and Shift + Tab element will properly navigate to and away from the PanelBar widget, instead of navigating among the PanelBar inner items.

We will also review the aria-controls attribute and how it should fit within the PanelBar scenario.

Regards,
Veselin Tsvetanov
Progress Telerik

Get quickly onboarded and successful with your Telerik and/or Kendo UI products with the Virtual Classroom free technical training, available to all active customers. Learn More.

Siddhant

Posted on: 09 Apr 2019 10:23

Agree with this issue. In case of accordions, it is very much needed that the accordions be buttons wrapped inside either of h1-h6 elements. The panel that opens can be containing any type of elements. But the container of the panel which hides/shows content should have an id as well. The header button must aria-controls="panel-container-id". Here is a snippet:

<div role="region" aria-labelledby="btn-id">

<h2><button aria-controls="panel" id="btn-id">Details</button></h2>

<div id="panel"></div>

</div>