Button Component WCAG Accessibility issues

[chris-gds]

Latest version

• [X] I have tested the latest version

Description

Button Component Accessibility issues

1) Issue: Uppercase text

WCAG 1.4.12 Uppercase text decreases readability for all users, but especially for those with dyslexia or other cognitive disabilities. All-uppercase text reduces the distinguishable shapes of letters (since uppercase letters have uniform heights), making it harder to recognise words by their shapes. [1] [2]

WCAG 1.4.8 emphasises that text should be presented in ways that improve readability, including limiting the use of fully uppercase text.

[1] https://accessibility.huit.harvard.edu/design-readability#:~:text=Avoid%20changing%20the%20typeface%20from,Don't%20underline%20text.

[2] https://www.gov.uk/guidance/publishing-accessible-documents

--salt-text-action-textTransform: uppercase; packages/theme/css/characteristics/text.css

2) Issue WCAG 2.5.5 Target Size (AAA)

Impact: Although this criterion is AAA, it’s worth noting that WCAG 2.5.5 recommends that touch targets (like buttons) be large enough (44 by 44 CSS pixels) to accommodate users who have motor impairments. A small button with uppercase text might be hard to tap or click accurately, especially on mobile devices.

3) Issue Disabled buttons

https://axesslab.com/disabled-buttons-suck/

4) Issue inconsistent focus styles

WCAG 2.4.7 Inconsistent focus styles (e.g., different elements having varying or missing focus indicators) can confuse users, especially keyboard and screen reader users who rely heavily on visual cues to navigate through content.

Steps to reproduce

https://www.saltdesignsystem.com/salt/components/button/examples

Expected behavior

1) Text to be Sentence case 2) All buttons to have a minimum size 3) More considerations for disabled buttons 4) Focus styles to be consistent

Package name(s)

Core (@salt-ds/core), Theme (@salt-ds/theme)

Package version(s)

No response

Browser

• [X] Chrome
• [X] Safari
• [X] Firefox
• [X] Microsoft Edge

Operating system

• [X] macOS
• [X] Windows
• [X] Linux
• [X] iOS
• [X] Android

Are you a JPMorgan Chase & Co. employee?

• [ ] I am an employee of JPMorgan Chase & Co.

[origami-z]

1) Issue: Uppercase text

We have received feedback around this. It's upper case to help distinguish transparent buttons with other elements (e.g. v.s. Text, v.s. Link). Do you have any alternative way to solve this?

Button as a component, is not the main content on the screen, so is "limited" in a way?

2) Issue WCAG 2.5.5 Target Size (AAA)

When using Touch density, Button meets 44px requirement

3) Issue Disabled buttons

What's your suggestion?

Focusable when disabled is one way for us to help the situation.

4) Issue inconsistent focus styles

All Salt components has consistent styling (dotted blue), it's a bug on the website itself which doesn't use Salt Link.

cc @jake-costa

[jake-costa]

@chris-gds First, I want to thank you for bringing this up and focusing on digital accessibility. It’s great to have users like you considering accessibility from the start, ensuring an inclusive and accessible experience for everyone. That said, I’d like to clarify that Salt currently follows WCAG 2.1 AA created by the W3C as the accessibility standard. Any other third-party guidelines not associated with the W3C would be out of scope.

1) Issue: Uppercase text

As mentioned "It's upper case to help distinguish transparent buttons with other elements (e.g. v.s. Text, v.s. Link)"

Regarding WCAG 1.4.12, it focuses on ensuring users can adjust text spacing properties—such as line height, letter spacing, and word spacing—but it doesn’t directly restrict the use of uppercase text.

As for WCAG 1.4.8, it falls under AAA standards, which are out of scope for us. Additionally, it doesn’t directly restrict the use of uppercase text either

The Harvard accessibility link you provided isn’t affiliated with the W3C. In addition, while it does recommend avoiding the use of all-uppercase text, this is not a strict requirement. Similarly, the gov.uk link is also not affiliated with the W3C and primarily provides guidance on digital documents rather than web applications with interactive components.

2) Issue WCAG 2.5.5 Target Size (AAA)

As you noted, WCAG 2.5.5 is a AAA criterion, therefore it is out of scope for our current standards and isn’t considered an accessibility violation.

3) Issue Disabled buttons

While this is certainly a hot topic within the accessibility community, there’s currently no restriction in WCAG 2.1 AA that prevents the use of disabled buttons in applications. Therefore, it isn’t considered an accessibility violation.

4) Issue inconsistent focus styles

Thanks for bringing this up! As mentioned, all Salt components are designed with consistent focus styling. This particular issue seems to be related to the site implementation rather than the component itself.

[jake-costa]

happy to reopen if more details are received

[chris-gds]

We have received feedback around this. It's upper case to help distinguish transparent buttons with other elements (e.g. v.s. Text, v.s. Link). Do you have any alternative way to solve this?

As mentioned "It's upper case to help distinguish transparent buttons with other elements (e.g. v.s. Text, v.s. Link)"

Should the button look like text due the Design, this probably needs a rethink so it looks like a button - as it is a button. This would impact information and relationships 1.3.1.

Regarding WCAG 1.4.12, it focuses on ensuring users can adjust text spacing properties—such as line height, letter spacing, and word spacing—but it doesn’t directly restrict the use of uppercase text.

As for WCAG 1.4.8, it falls under AAA standards, which are out of scope for us. Additionally, it doesn’t directly restrict the use of uppercase text either

The Harvard accessibility link you provided isn’t affiliated with the W3C. In addition, while it does recommend avoiding the use of all-uppercase text, this is not a strict requirement. Similarly, the gov.uk link is also not affiliated with the W3C and primarily provides guidance on digital documents rather than web applications with interactive components.

There are not any strong arguments to continue to use UPPERCASE text compared to Sentence text. Evidence demonstrates that's it's more readable, especially for readers with cognitive issues like dyslexia.

Bryan Gill, JPMorgan Chase's head of the Global Office of Disability Inclusion and the bank's head of Global Neurodiversity writes "...when we dismiss or minimize the neurodiverse, we also reinforce the notion that difference equals weakness—and that those who are different are somehow insufficient. "

Maybe this minor adjustment would not exclude, or minimise, the needs of these people?

What's your suggestion?

One solution is to remove buttons that are disabled entirely - why does it need to be there? It can be brought back once it's active.

Another solution by Hampus Sethfors writes "just don’t disable buttons! Have them enabled and then show an error message when the user clicks them."

All Salt components has consistent styling (dotted blue), it's a bug on the website itself which doesn't use Salt Link.

The styling seems to change depending on the colour of the button rather than be consistent regardless.

[jake-costa]

Bryan Gill, JPMorgan Chase's head of the Global Office of Disability Inclusion and the bank's head of Global Neurodiversity writes "...when we dismiss or minimize the neurodiverse, we also reinforce the notion that difference equals weakness—and that those who are different are somehow insufficient. "

I want to emphasize that our use of transparent buttons or uppercase text in certain UI elements, and our focus on WCAG 2.1 AA rather than AAA compliance, absolutely does not mean we are dismissing or minimizing the needs of neurodiverse users or those with cognitive disabilities.

There are not any strong arguments to continue to use UPPERCASE text compared to Sentence text. Evidence demonstrates that's it's more readable, especially for readers with cognitive issues like dyslexia.

Should the button look like text due the Design, this probably needs a rethink so it looks like a button - as it is a button. This would impact information and relationships 1.3.1.

I encourage you to look at W3C Non-Text Contrast "A button which has a distinguishing indicator such as position, text style, or context does not need a contrasting visual indicator to show that it is a button..."

To be clear:

1. Accessibility is a core priority for us. We strive to create inclusive designs for all users, including those with diverse cognitive needs.

2. WCAG 2.1 AA compliance, which we target, is a robust standard that addresses many accessibility needs. The W3C Conformance Requirements itself notes that AAA compliance is not always feasible or necessary for all content.

"It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content."

3. We continuously test and refine our components to ensure they work for as many people as possible.

One solution is to remove buttons that are disabled entirely - why does it need to be there? It can be brought back once it's active.

When to use disabled as a function depends on context, audience, expectations, and more. Often there are better ways to handle making a feature inactive, but a blanket ban for a design system is not ideal at this time. That said, we take all accessibility feedback very seriously and use it to improve our components. I want to assure you that we will review your feedback internally. Our team is committed to ongoing evaluation and improvement of our accessibility practices.

All Salt components has consistent styling (dotted blue), it's a bug on the website itself which doesn't use Salt Link.

Can you provide detailed examples and screenshots?

Lastly, being a design system, it's crucial to distinguish between design choices that may require thoughtful implementation and accessibility violations that actively dismiss or minimize the needs of any user group. Our approach aims to balance accessibility, usability, and design considerations for a wide range of users.

We appreciate you advocating for neurodiverse users. If you have specific examples where our design system is causing accessibility violations, we'd be very interested in hearing more to inform our ongoing improvements.

[chris-gds]

I want to emphasize that our use of transparent buttons or uppercase text in certain UI elements, and our focus on WCAG 2.1 AA

A transparent button that looks like text would be a fail of WCAG 2.1 A under 1.3.1 as it's not visually aligned to the underlying code.

W3C Non-Text Contrast relates to text, not information and relationships.

not mean we are dismissing or minimizing the needs of neurodiverse users or those with cognitive disabilities.

To confirm, there is a continued use of UPPERCASE text even when you're now aware users with cognitive disabilities face issues with this yet you're confident this is not "dismissing or minimizing the needs of neurodiverse users or those with cognitive disabilities."

Thanks for your time @jake-costa.

[joshwooding]

Thanks for the feedback, we are all passionate about accessibility and it sounds like some of that passion is boiling over. Due to the direction this conversation might go in, I'm going to lock this issue. Have a nice day.