Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[a11y] Button and Link high contrast outline issue fix #847

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

stamat
Copy link
Contributor

@stamat stamat commented Dec 2, 2024

Summary

Outline of the Button component was always visible in high contrast themes which was causing a11y issues.

Outline of the Link component was invisible in the high contrast themes which is also an a11y issue.

List of notable changes:

  • removed styles that were forcing the outline of the Button component to be always visible regardless of the focus in high contrast themes
  • updated outline of the Link component to use the native outline instead of box-shadow, since box shadow is invisible in high contrast themes
  • updated underline of the Link component to use border instead of background so the underline will be visible in high contrast themes

What should reviewers focus on?

  • Outline of the Button component should only be visible when the component is focused in high contrast themes
  • Outline of the Link component should be visible when the component is focused in high contrast themes
  • Underline of the Link component should be visible on hover in high contrast themes

Steps to test:

  1. npm run start
  2. Make the storybook port public
  3. Test in high contrast theme enabled Windows 11 by focusing on Button and Link with keyboard

Supporting resources (related issues, external links, etc):

Contributor checklist:

  • All new and existing CI checks pass
  • Tests prove that the feature works and covers both happy and unhappy paths
  • Any drop in coverage, breaking changes or regressions have been documented above
  • UI Changes contain new visual snapshots (generated by adding update snapshots label to the PR)
  • All developer debugging and non-functional logging has been removed
  • Related issues have been referenced in the PR description

Reviewer checklist:

  • Check that pull request and proposed changes adhere to our contribution guidelines and code of conduct
  • Check that tests prove the feature works and covers both happy and unhappy paths
  • Check that there aren't other open Pull Requests for the same update/change

Screenshots:

Please try to provide before and after screenshots or videos

Before After

Screenshot 2024-12-02 at 21 45 57

Screenshot 2024-12-02 at 22 00 02

Screenshot 2024-12-02 at 21 53 45

Screenshot 2024-12-02 at 21 58 36

Screenshot 2024-12-02 at 21 53 34

Screenshot 2024-12-02 at 21 58 44

Copy link

changeset-bot bot commented Dec 2, 2024

⚠️ No Changeset found

Latest commit: c889ba2

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Contributor

github-actions bot commented Dec 2, 2024

🟢 No design token changes found

Copy link
Contributor

github-actions bot commented Dec 2, 2024

⚠️ Visual differences found

Our visual comparison tests found UI differences.

Please review the differences by using the test artifacts to ensure that the changes were intentional.

Artifacts can be downloaded and reviewed locally.

Download links are available at the bottom of the workflow summary screen.

Example:

artifacts section of workflow run

If the changes are expected, please run npm run test:visual:update-snapshots to replace the previous fixtures.

Review visual differences

@stamat stamat self-assigned this Dec 2, 2024
@stamat stamat requested a review from rezrah December 2, 2024 20:17
@stamat stamat changed the title Stamat/high-contrast-outline-issues [a11y] Button and Link high contrast outline issue fix Dec 2, 2024
@stamat stamat marked this pull request as ready for review December 2, 2024 21:02
@joshfarrant
Copy link
Contributor

Looks great @stamat, thank you!

Thanks for raising this, I'd not actually tested with Windows high-contrast themes before. It looks like our icons could do with switching to a different colour in some scenarios. Are you seeing the same thing that I'm seeing here (dark grey arrow icon is barely visible)?

image

Could you also add the Update snapshots label to this PR to regenerate the snapshots please?

@stamat
Copy link
Contributor Author

stamat commented Dec 3, 2024

@joshfarrant I'll take a deeper look into this man in few moments! I didn't know there was an icon lol...

@joshfarrant
Copy link
Contributor

Sorry @stamat, I wasn't suggesting this was something you had to fix 😅

I just wanted to ask out of curiosity as I've not tested with Windows high-contrast themes before and I wanted to make sure I wasn't missing something obvious. I'm happy to take a look through all our components at some point in the future and make sure they're working as well as possible in high-contrast.

Comment on lines -200 to -206
.Button--primary,
.Button--secondary,
.Button--disabled:hover {
outline: var(--brand-borderWidth-thick) solid transparent;
outline-offset: 2px;
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI these styles were put in place by our accessibility engineering team to resolve similar issues in Windows HCM.

Before we undo that work (and for my own understanding), do the changes in this PR take precedence? cc. @TylerJDev who was involved in the original PR, if you have any thoughts too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rezrah I completely failed to understand how these button updates that I removed helped accessibility, seemed they had an opposite effect based on my understanding... Yeah it's a good call to ask @TylerJDev to shed some light on this. I'm all 👂 ! 🙏 ❤️

Copy link
Contributor Author

@stamat stamat Dec 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rezrah I think I know what happened... Our old(er) buttons probably didn't have a border but used an inset box-shadow... https://github.com/primer/brand/blob/d763e2fb6584489f1277370457b4c2ebded2fd82/packages/react/src/Button/Button.module.css (This is the state from the era the change was made)

So this "fix" used the outline to draw the border in high contrast themes since backgrounds and shadows are disabled - instead of just adding the border!?

The reason older buttons had the box-shadow borders was to animate them escaping the jitter of the border, thus sacrificing accessibility for aesthetics.

CSI Miami 😎

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello 👋

Looking at the change, and my own change, this was a time before borders were used for buttons, so we needed to add something to imitate the styles of box-shadow for HCM.

Since we've added borders to the button, we don't need to imitate the borders anymore, since those always show in HCM, so removing this is okay since it, and the focus styles. Right now it seems like the two are competing against each other, the outline provided in HCM and the border of the button.

As for the outline, this was more or less interchangeable with the border in HCM. I'm not too sure if there was another driving factor here, since it's been a minute 😅, but having there be some sort of presence of a border was the main goal to differentiate between what is/isn't a button.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TylerJDev thanks for the reply dude! 💖 Yeah I figured it was something like that! ☺️

Copy link
Collaborator

@rezrah rezrah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for helping to fix this @stamat 💖 ... I've left you some minor feedback. Would love your thoughts on this in particular.

A few other things before this lands:

  • We'll need a changeset added to this PR to describe what changed in this PR for our release change log. You can do it by clicking this link on this comment 👇

    Screenshot 2024-12-03 at 11 29 39

  • Updated snapshots would be useful to verify there aren't any visual regressions. You can add the 'update snapshots' label in this PR to run the tests.

@stamat
Copy link
Contributor Author

stamat commented Dec 3, 2024

Also a note, I believe aria-disabled="true" is assumed if the button has disabled attribute: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled

When needing to disable native HTML form controls, developers will need to specify the disabled attribute, as it provides all of the generally expected features of disabling a control by default. However, there can be instances where elements need to be exposed as disabled, but are still available for users to find when navigating via the Tab key. Doing so can improve their discoverability as they will not be removed from the focus order of the web page, as aria-disabled does not change the focusability of such elements, nor will the elements be dimmed by default browser styling, making them easier to read.

I don't think this applies to buttons, for the buttons to be disabled we need to use disabled attr...

@stamat
Copy link
Contributor Author

stamat commented Dec 3, 2024

@joshfarrant @rezrah one final ✅ from you 🙏 ! Also should I up a patch version? 😇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants