docs: Inaccessible components / wrong advice on docs.
horsemankukka opened this issue · 5 comments
On which page do you see this issue?
No response
Describe the issue
Multiple daisyUI components or their example uses are problematic concerning accessibility. You asked me on Twitter to write about them here, so here goes.
Countdown
Because the countdown component is essentially just a pseudo-element containing numbers from 00 to 99, screen readers will read it as such.
Timeline
The first example gets read as "1984. First Macintosh computer. Divider. Disabled. Divider. Disabled. 1998. iMac. Divider. Disabled. Divider. Disabled."
Using those two <hr>s without hiding either one of those from the screen reader makes reading the timeline tedious.
Radial progress
The docs claim that adding role=progressbar makes the element accessible again. In fact it does the opposite: just declaring the role but not aria-valuenow (even though ARIA requires it) makes all of the examples read "50%" on VoiceOver, for example.
Tabs
This one misuses the tablist role as it doesn't implement all roles it needs. The input + div + input + div order also makes navigating the tabs weird and unexpected.
Rating
The examples show just unlabeled radio buttons without any indication to screen reader used about what they do.
Drawer
The drawer's content isn't hidden for screen reader users ever. Additionally, even though it's redundant as the drawer isn't actually hidden for screen reader users, the <label for aria-label> pattern doesn't seem to work in VoiceOver (it doesn't get announced and cannot be selected). MDN docs for aria-label states that in practice it's supported for limited number of elements only, might be about this.
Using checkboxes for non-checkbox stuff
This is just confusing overall, no matter what.
Not sure if this covered everything, feel free to mention if there was something I said on Twitter but forgot to include here. Marked as an issue on docs even though it's not purely just that and didn't want to open different issues for every single component.
What browsers are you seeing the problem on?
No response
Thank you @horsemankukka
for reporting issues. It helps daisyUI a lot 💚
I'll be working on issues one by one. I will help with this one as soon as a I
find a solution.
In the meantime providing more details and reproduction links would be
helpful.
Hey, I'd like to work on this. I'm using NVDA to test which does show some discrepancies from VoiceOver (it has no problems reading Drawer aria-labels, etc).
I have a few fixes going on at the moment, including some minor changes to the Drawer component. Setting visibility to hidden if it's not open makes the screen reader ignore it on my end. Once it is open, a transition to visible takes place allowing screen readers to parse it without altering previous transition functionality. This may need further testing so no functionality is broken!
Rating, Timeline, and Radial Progress can all be fixed by updating the docs to reflect accessibility practices.
As far as Counter and Tab go, I'm afraid Counter should potentially be marked as inaccessible. Since it is just CSS, it cannot truly update its content in a way that meets accessibility standards. Also digging into the code for Tab, its input + div ordering is so that DaisyUI's CSS can choose to hide content properly. It is a built in limitation for Tab that cannot be circumvented without using JS, which DaisyUI does not do.
Another point on Tab, can you further elaborate on misusing the tablist role? I have been looking at the documentation for it, and I'd like further elaboration on the misuse of the role if possible!
Thanks. that's great!
As far as Counter and Tab go, I'm afraid Counter should potentially be marked as inaccessible. Since it is just CSS, it cannot truly update its content in a way that meets accessibility standards.
For countdown, I believe adding a aria-label in the docs would fix that (aria-label value must also change along with --value variable)
Hey, just to keep you updated. I managed to get countdown to be accessible. Unfortunately, the aria-label doesn't work since span can't take on a label unless it has specific roles.
In the proposed changes, a countdown class would apply the content changes only to children with the countdown-content class. This way we can safely label that child with aria-hidden="true" and give it a sibling span that just displays the current countdown content to screenreaders only.
Any thoughts or concerns? I'll be looking over previous aria-labels as well to ensure consistent and correct usage.
A new update that makes it so countdown works the same as normal, just adding a countdown-accessible class that lets users easily integrate accessibility without breaking previous uses. Updated docs to reflect the new accessibility standards, tested with NVDA screen reader which makes countdown accessible for me!
Anyone mind looking these changes over?