Need Work Arounds for Accessibility Shortcomings

[Mike]

I'm developing an application where accessibility is very high priority, and I'm finding that every time I try to use one of your controls within the application, there is some sort of issue with its usability, mostly with screen readers.  While I know that you are working on trying to make the controls more accessible, this appears to be slow going. 

Further, I'm not seeing any options for workarounds.  For example, most of the controls are missing certain aria labels that would make them viable to use with screen readers, but because you have deciding not to implement allowing arbitrary attributes / attribute splatting within your controls I can't do anything to get these controls working for screen reader users. As a result, I keep having to roll my own controls instead of using yours, even though in most cases your control is 90% there.

Take the Multi-select control.  It has keyboard support, which is great, and it does read the options when navigating through the dropdown, but once you have selected an option, there is no way to get a screen reader to read any of the selected tags.

Another example is with your checkbox control. I need a way to set an aria-invalid attribute on the control, but I can't do so because your controls don't support attribute splatting: http://https://feedback.telerik.com/blazor/1416978-support-arbitrary-attributes?_ga=2.192430378.1005614243.1645625246-1187442152.1626202564

Other examples include:

https://www.telerik.com/forums/how-to-alter-aria-attributes-on-menu-and-panelbar

https://www.telerik.com/forums/how-to-add-html-aria-attributes-to-telerik-components

https://www.telerik.com/forums/ignore-forward-slash-allow-various-formats-when-using-date-input

I know that you are working on some of these things, but this is not something that I can wait months for to be released.  So I'm asking are there any work arounds for some of these issues?  If you had chosen to support arbitrary attributes, it would ease the frustration of waiting for a fix because we could have used that method as a workaround.  Is there anything that I can do now to mitigate my issues short of writing the controls from scratch?  

[Hristian Stefanov]

Hi Mike,

I fully understand the importance for you of fixing the accessibility bugs.

Currently, accessibility in the components has a very high priority in our plans. It is so important for us as well. We are doing everything possible to faster significantly the process.

Still, as a workaround in the meantime, you can modify our source code with the needed aria attributes. The Source code is available as of 2.29.0 version.

Now let's cover the mentioned specific issues below.

Pager accessibility issues

The referred Pager accessibility issues are already fixed (in 2.30.0 version):

Pager navigation buttons accessibility issues

MultiSelect accessibility issues

The MultiSelect accessibility issues are confirmed as well with the last testing in one of the public posts. This will be fixed shortly (in the next 1-2 releases).

PanelBar accessibility issues

The PanelBar issues will also be fixed shortly.

DatePicker accessibility issues

The DatePicker issue is still under review from one of my colleagues.

Overall, I encourage following the public items of all issues for the next status updates. Thank you for your cooperation here.

Regards,
Hristian Stefanov
Progress Telerik

[Mike]

Hi Hristian,

Thanks for your response.  I appreciate that accessibility is being made a priority within the component suite.  I eagerly await for some of these items to be fixed.

And I appreciate that you guys are making the source code available, but I don't see customizing the source code as a sustainable work-around.  It means that every time you come out with new release, I would need to compare it against my changes and re-apply them.  That may be fine for some issues that would be fixed within a single development cycle, but if you guys aren't able to fix it for 3 releases, let's say, that means that I need to make my changes 3 times. 

I'd ask that you guys revisit Arbitrary Attributes and Attribute Splatting again, as that becomes a more viable option to fill in the deficiencies with stop gaps until your fixes are complete.  This feedback thread just declined the request without really giving an explanation, and there are a number of upvotes for the feature:

https://feedback.telerik.com/blazor/1416978-support-arbitrary-attributes?_ga=2.192430378.1005614243.1645625246-1187442152.1626202564

I know that in the past for your Kendo controls you guys provided javascript work-arounds. Is that something that may be viable here that you guys can provide.  I'm not sure of the feasibility of this, I'm just trying to think out of the box. That would be much more sustainable than customizing and branching off of your source code.

[Joana]

Hi Mike,

First, I would like to genuinely thank you for your detailed reports and testing the accessibility of our components. Such objective evaluation helps a lot when revising our internal accessibility practices.

I absolutely agree with you that changing the source code is not ideal due to the manual merge when new version is released. However, it is an alternative for our customers who have strict deadlines for their projects.

To the question what we can do more - we can provide is a custom nuget packages once we push accessibility fixes, so that you do not have to wait until next release. In addition, we continue to prioritize our accessibility backlog.

Even though the feature request for attribute splatting is declined we still hear our customers voice and evaluate all requests that mention the topic. Let me give you more information about the reasons that led to the decision.

1.  Performance

The performance is already hot topic for Blazor, and we constantly run tests and track any features that might increase or decrease it. The attributes splatting causes a huge decline in the performance that becomes more serious when a composite component need to pass them to inner ones. It is also partially explained in Microsoft documentation.

2. Conflict with existing feature

Attributes passed by customer might conflict with already added and used attributes by the components. We do our best to keep our API and documentation clean and easy to use. So, imagine how would look like our documentation and intelisense if we need to explain "if you use this parameter, it is not supported to use x, y, z attributes". 

I hope that the above summary clarifies the situation. Our goal and mission is to make the development process of our customers easirer not the other way around. We want to protect our customers from choosing attributes over perfomance, or from thinking what feature with what attributes can be used or not. 

I understand that if we supported the attribute splatting, it would help you achieve the desired accessibility. However, that might not be entirely true because the attributes would be added to the root element of the components. There would be still cases when you cannot access an inner element.

It is our job to assure the accessibility and we will adapt our strategy for assuring compliance to provide fixes soon.