Description

This task describes the Storybook implementation for the sd-button component as part of the A11y improvements outlined in Epic #1465.

A11y improvements for sd-button can be found here: sd-button Notes.

Comment

Problem: The accessible name of the loading buttons is “Loading Loading.” It’s coming from the slotted “Loading” and the accessible name of the progress bar.
Solution: The progressbar role needs an accessible name, so you can’t remove that. You can’t and probably shouldn’t remove the slotted content. I guess putting aria-labelledby (or aria-label) on the button to overwrite the accessible name coming for the content within is the best solution.

Problem: The icon-only buttons have no accessible name.
Solution: Provide an accessible name via slotted content, coming from the icon (needs a role=img for that), or aria-label.

Notes

I’m not the biggest fan of disabled buttons because they cause more problems for users than benefits.

• Missing Feedback - When you click a disabled button, nothing happens. The button doesn’t explain what’s wrong or help you fix the problem.

• Missing focus - Disabled buttons are not focusable, so screen-reader users who use the Tab key to navigate might not know that there even is a button.

• Low contrast - WCAG’s minimum contrast rule doesn’t apply to disabled controls, but they’re often hard to read, especially for people with low vision

• Deception - It’s not always apparent that buttons are disabled. Some users will try to click them; if nothing happens, they can feel irritated, confused, or disappointed.

• The pattern description says, "Buttons perform various functions (e.g., download, link)." While a button can do that, aren't those examples something a link typically does?

• please check out https://shoelace.style/components/button#link-buttons

• we will create a new Ticket for the disabled topic to discuss the usage of that (design wise)

Best Practices

The button element has two main use cases: submitting a form, and running Java‐Script when a user interacts with it. Don’t use button to link to other pages.

Always provide an label even if it’s an icon-only button.

Try to avoid the use of disabled buttons. Instead of disabling buttons, there are several measures you can take to avoid errors up front:

• Use clear labels for your input fields.
• Add hints and descriptions when the label alone isn’t clear enough.
• Split complex forms into multiple steps or pages to reduce cognitive load.
• Always enable buttons and validate input on submit.
• Give clear error messages.

Related WCAG criteria

https://www.w3.org/WAI/WCAG22/quickref/#name-role-value

Open Questions

• Question1
• Question2

DoR

• Item has been estimated by the team
• Item dependencies have been identified and documented

DoD

• Documentation has been created/updated (if applicable)
• Migration Guide has been created/updated (if applicable)
• Relevant E2E tests (Features, A11y, Bug fixes) are created/updated
• Relevant stories (Features, A11y) are created/updated
• Implementation works successfully on feature branch