Update on component accessibility guidelines?

[jramke]

Hey,

im starting this disscussion, because i saw this point on the roadmap and would love to hear some other thoughts or insights.

Currently, im evaluating to use daisyUI for future projects as it seems to be the best way to use tailwind in non-component-based js frameworks.
The components look pretty great and straightforward with css only, huge props for that.

But as i look more and more into accessibility there seem various things to consider as devs implementing daisyUI. I understand that these things require js and or are related to the context the component is used at the end, but i would really love to have some suggestions, best practices and or code snippets stated out in the docs.

I noticed, @saadeghi already gave some suggestions in various issues and discussions on how you would handle some cases.
There is also this PR where @gjvalenz already addressed some issues.

For example a small script to close the details/summary dropdown on focus out, or aria-expanded and similar attributes as needed for the css option would be great.

Looking forward to hear some thoughts
Joost

PS: I also wonder why there is a tabindex="0"on the <ul> element, because you have to hit tab two times to focus the first dropdown element?

[saadeghi]

daisyUI is CSS only and the goal is to provide UI parts which are possible without relying on JS and at the same time we want them to be accessible.
And of course, accessibility is crucial and we're constantly improving methods and syntaxes to be more accessible.

I understand that these things require js and or are related to the context the component is used at the end, but i would really love to have some suggestions, best practices and or code snippets stated out in the docs.

Yes, as a component library we can provide examples of using a component but at the end "accessibility" can not be a built-in feature of component library and should be considered by the developers of each project, based on the context of each UI part.

For example daisyUI provides examples to use icons in buttons, but it a button only has an icon without any text, it needs ARIA label to describe the function of that specific button. This is not something a component library can provide by default because that ARIA label should be written manually by the developer based on the context of that button or icon, depending on what that button is supposed to be labeled for screen readers.

As you mentioned, sometimes additional JS code might be needed for some parts. This is not related to accessibility tho. It's functionality.
For example, we use details/summary for dropdown. It's a standard HTML tag. It's accessible and it works as intended but unfortunately there's no way to close it using CSS when clicked outside. That functionality simply was not in the spec for details HTML tag so we can't do anything about it. So if someone needs it to get closed by clicking outside, they need to do it manually in JS.

For example a small script to close the details/summary dropdown on focus out, or aria-expanded and similar attributes as needed for the css option would be great.

If the JS ecosystem was not this divided, I could add a line of JS for how to do it, but there are many methods to do it in each framework. there's DOM/Virtual DOM, there's SSR/CSR, there are hooks runes and various methods of DOM manipulation on each version of each framework and even users of a single JS framework cannot agree on one method. So it's not easy to provide a small script to work everywhere. And it's important for daisyUI to work everywhere as it is framework agnostic.
On top of that, there are non-JS solutions as well, some people handle DOM manipulation with other languages on the server.

accessibility guidelines

The goal is to add some descriptions and guidelines to each component page about:

• ✅ Dos and ❌ Don'ts
• how/where to use each component
• When ARIA attributes are needed
• etc

And of course these depend on the context of the final project, so we give these guidelines as suggestions to make their project more accessible.

Currently I'm working on optimizing the translation functionality of daisyUI docs and also compatibility of daisyUI 5 for the next version of Tailwind CSS

So I can promise accessibility guidelines after daisyUI 5 release but in the meanwhile, if you already know how to check your project for possible accessibility issue and fix them, you would be fine already.

PS: I also wonder why there is a tabindex="0" on the <ul> element, because you have to hit tab two times to focus the first dropdown element?

It's explained here: https://daisyui.com/components/dropdown/#method-2-using-css-focus

Method 2: Using CSS focus
We can't use <button> here because Safari has a bug that prevents the button >from being focused.
<div role="button" tabindex="0"> is a workaround for this bug.
It is accessible and works in all browsers.

Let me know if you have a question.

[SpasiboKojima]

I'm also looking for the reasoning, the explanation is for the button/<div> element, but what about the list/<ul>?

[saadeghi]

@SpasiboKojima Because of a bug in Safari iOS 15 If the dropdown itself is not focusable, clicking outside won't close it in Safari iOS 15. The bug is fixed in newer iOS Safari versions so if you don't care about iOS 15, you can remove the tabindex from the dropdown menu.

[SpasiboKojima]

Thank you for the explanation!

[jramke]

Thanks for the fast reply.
Yeah, absolutely understand the issue with the js.

✅ Dos and ❌ Don'ts
how/where to use each component
When ARIA attributes are needed
etc

These sounds great, looking forward to it.

And thanks for the clarification when we can expect them.
Im definitely pumped for tailwind 4 and daisyUI 5 now.

Yeah i also had some issues with buttons in safari. I now got the opportunity to view it in safari and i cant focus on either of the items in the two dropdown options with tab. Am I missing something, or is this a bug?

Thanks again!