Examples should be accessible (a11y) out of the box

[tkrotoff]

Examples should be accessible (a11y) out of the box

Following this discussion in this PR: #4223 (comment)

Label and input association (id and for attributes)

The vast majority of UI toolkits and doc websites specify id and for attributes. They try to provide accessible examples out of the box.

• MDN: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input

• Tailwind Plus:

  • https://tailwindcss.com/plus/ui-blocks/application-ui/forms/form-layouts
  • https://tailwindcss.com/plus/ui-blocks/application-ui/forms/input-groups

• Flowbite: https://flowbite.com/docs/components/forms/

• Basecoat: https://basecoatui.com/components/form/

• Bootstrap:

  • https://getbootstrap.com/docs/5.3/forms/overview/
  • https://getbootstrap.com/docs/5.3/forms/form-control/

• Foundation: https://get.foundation/sites/docs/forms.html

• Pico CSS: https://picocss.com/docs/forms

• Pure CSS: https://pure-css.github.io/forms/

• Materialize: https://materializeweb.com/text-inputs.html

• Microsoft Fluent UI (React): https://storybooks.fluentui.dev/react/?path=/docs/components-input--docs

• W3Schools (bad source, but still): https://www.w3schools.com/tags/tag_input.asp

• ChatGPT: generates accessible forms without asking

• Gemini: generates accessible forms without asking

The sole UI toolkit I could find that doesn't set id and for attributes in examples is Bulma:

• https://bulma.io/documentation/form/general/
• Accessibility Issues jgthms/bulma#53

Based on this I believe devs expect code snippets to be accessible out of the box and are used to this: Principle of least astonishment.

Yes, some devs will blindly copy-paste code snippets and forget to adapt the code :-/
(This is where JS components shine: most a11y can be done automatically, for example you don't have to manually specify id and for attributes)

Promote a11y

At a broader level, I believe it's important to have a a11y dedicated section for each component and a general page about it:
explaining dos and donts, showing the UI toolkit is WCAG compliant and the efforts done, keyboard navigation, tested with VoiceOver/TalkBack...

I believe not having this is a handicap for a UI toolkit because it is something that nowadays devs and deciders expect.
I also believe making daisyui.com website to pass WAVE tool, Axe... would be a strong signal.

The legislation is getting stricter regarding accessibility: https://www.deque.com/blog/european-accessibility-act-eaa-intro/, https://en.wikipedia.org/wiki/Web_accessibility#Web_accessibility_legislation
In France, you now get financial sanctions if you don't comply (depends on your company's income and size)

So companies try to choose a UI toolkit as accessible as possible out of the box.

Examples of UI toolkits accessibility dedicated pages:

• https://react-spectrum.adobe.com/react-aria/accessibility.html
• https://getbootstrap.com/docs/5.3/getting-started/accessibility/
• https://help.mantine.dev/q/are-mantine-components-accessible
• https://primer.style/accessibility/

Examples of a11y section for components:

• https://getbootstrap.com/docs/5.3/forms/overview/#accessibility
• https://mui.com/material-ui/react-rating/#accessibility
• https://mantine.dev/core/input/#accessibility