Acessibility

[cdpestitschek]

Ahoy team, I would like to ask a question about accessibility.

I wanted to share with you a feedback from an accessibility specialist gave us about our solution and understand how we can improve it together with Paste.

"From what I can test from the video, some of the text fails color contrast. Text should meet a minimal of 4.5 contrast. Dark mode would have to be tested too."

Considering that we apply the existing component (disable button) of Paste in our solution. Can we discuss and re-evaluate these applied colors and font sizes to the point of meeting accessibility criteria?

I wanted to understand if there is someone I should talk to and work with on this solution or what would be the recommended next steps here.

All the best,
Carol

[kate-porter]

Hi Carol, thanks so much for reaching out about this! Great to see that you're investing in accessibility.

Re: the disabled button contrast, disabled UI controls do not need to meet the 4.5:1 contrast requirement for text, because they can't be interacted with. You can read more about it here. Here's the line outlining that the contrast requirement does not apply here:

Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

With that said, we often recommend against using disabled UI elements whenever possible. Instead, it can often be a better experience to keep the button enabled and provide actionable error text if needed after the button is pressed. This can be more clear than a disabled button, where it might be difficult for the user to understand why the button is disabled.

For the timestamp text, can you share what text color tokens and background color tokens are being used there?

[stumcrew]

Hi @katieporter. Thanks for the feedback. Is your recommended solution appropriate for users who use screen readers? They will be told an action is available when really it is not. Working out how to move forward could be complex. (I don't have any expertise here but based on previous feedback from customers this could be an issue).

[kate-porter]

Hey @stumcrew - great question! 🙌

Having the Button enabled, marking required fields as required, and providing clear error messaging when needed is generally more usable for all users—including screen reader users—because the enabled Button gives you a trigger to provide feedback to the user. If they select that enabled Button and an error message is thrown, it would be announced to them, making troubleshooting easier than having to guess what they need to do to get a disabled Button to activate.

That said, context always matters, which is why we do have a disabled Button available in Paste. We'd be interested to hear what feedback you've heard from customers related to this!

[stumcrew]

Thanks, I don’t disagree. Just hoping to find a great solution for all users.

As we’ve started to speak with customers about screen readers we’ve learned how important it is for the UI to be clear to navigate and without unnecessary complexity. We had feedback about the new logout menu in Flex where the user has to navigate to their profile icon in order to open a modal, and then navigate again to the only button in that modal to logout. The feedback was that this is needlessly complex and impossible to discover if you didn’t know that action lives in the modal. I wonder if we risk creating a similar situation with an ‘enabled but disabled’ button.

We’re still doing research into how we best support screen readers and I don’t have an answer. If I learn more or find a good example of this I’ll share it.

[kate-porter]

Please do, we'd love to hear what you learn!

[cdpestitschek]

Hi Katie, thanks for getting us back.

After the considerations you mentioned, I prepared this [material].(https://docs.google.com/document/d/1sqejovHJKyZGDfa_zQD9RZvw7K9v9QZnxLbv3Mg1zi4/edit).

1. Scenario - Selected task
   

Current: (4.16:1)
Background color: E1E3EA
Font color: 606B85

Proposed to improvement: (13.22:1)

Background color: E1E3EA
Font color: 121C2D

1. Scenario - unSelected task (4.85:1)
   

Current:
Background color: F4F4F6
Font color: 606B85

Proposed to improvement (13.32:1)

Background color: F4F4F6
Font color: 121C2D

3. Scenario - Form filling
   Currently the button is disabled because the fields are not filled, although none of the fields are mandatory.
   Proposed to improvement:
   At least inform in a visual way the user that the fields are mandatory. So when there is a screen reader reading the user will be aware.
   We could create something friendly to contextualize the user, instead of forcing an error. Adding an ALT text before the form, "All fields in the form (or channel, recipient address and queue) are mandatory, and necessary to enable the "start task" button".

Reasons not to start with the button in the normal and error state.
The user would not have performed any interaction, and the reader reading the screen would already be faced with the reading of an error present.

What are your thoughts on this proposal @katieporter?

[kate-porter]

The text color updates on the tasks look great!

Regarding the "start task" button, I do want to clarify: the suggestion was not to show the button in an enabled state AND show error messaging from the start. The suggestion was to show the button in an enabled state, and then if the users selects it before completing required fields, show an error. This provides a nice trigger for all users to help them troubleshoot if they try to create a task before filling out required fields. Does that make sense? Curious to hear your thoughts on that!

[cdpestitschek]

Yeah. Definitely I agree a 100% percent on this suggestion.

The suggestion was to show the button in an enabled state, and then if the users selects it before completing required fields, show an error.

Perfect, we will update the text colors 🫡