Accessibility issues in Radzen components

Radzen.Blazor Components
1

Hello Radzen Support Team,

during a WCAG 2.1 AA audit we found multiple accessibility issues caused by HTML/ARIA markup generated by Radzen components. These cannot be reliably fixed at application level because the roles/structure/IDs are generated by Radzen.

Below is a concise list with expected screen reader behavior.

  1. RadzenAutoComplete

Issue: role="combobox" is generated, but required ARIA relations are missing (e.g., aria-controls to connect the input with the popup listbox).

Expected by screen readers: A combobox must reference its suggestion list, so assistive tech can announce available options and navigation state.

Note: role="combobox" is generated by RadzenAutoComplete.

  1. RadzenCalendar (month navigation)

Issue: navigation is rendered as without href and behaves like a button.

Expected by screen readers: Calendar navigation should be exposed as buttons (proper role/semantics) so it is announced as actionable.

  1. RadzenTabs (tab headers)

Issue: tabs are rendered as and do not follow the ARIA tabs pattern (missing role="tablist" / role="tab" structure).

Expected by screen readers: Tabs must be announced as a tab interface with correct roles and selected state.

  1. RadzenPager (pagination)

Issues:

  • pagination items rendered as without href

  • disabled on anchors

  • pagination rendered without semantic navigation/list

    Expected by screen readers: Pagination should be announced as navigation with list items and correctly labeled buttons.

  1. RadzenFieldset / Expander (Duplicate IDs)

Issue: multiple Fieldset instances on the same page generate duplicate IDs, e.g. id="rz-fieldset-0-content" appears more than once.

Expected by screen readers: All id attributes must be unique; otherwise labels/relationships can point to the wrong element and assistive technologies may malfunction.

  1. Toggle / Switch (nested interactive elements)

Issue: interactive elements are nested inside other interactive controls (reported as “nested-interactive”).

Expected by screen readers: Each interactive control must be focusable and announced independently to avoid focus and announcement problems.

Could you please confirm:

  • whether fixes are planned,

  • and if there are recommended workarounds?

Thank you for your support.

Kind regards

2

Thanks for the report! Yes, we plan to address them and you can monitor this pull request:

3

Thank you very much for the quick response and the update! I will keep an eye on the pull request and let you know if I have any questions.