fix(a11y): update orange values to make pagination and navigation compliant to WCAG non-text contrast SC

giamir commented 1 year ago

This PR addresses STACKS-440.

Problem

Pagination and Navigation components selected state don't comply with the WCAG2.2 non-text contrast Success Criterion (3:1).

Solution

Tweak slightly the default orange palette to reach the 3:1 WCAG Contrast Ratio Requirement.

Extending Test Utils

This PR also extends our testing utils to run additionalAssertions for dedicated components. This allows us to add targeted a11y tests checking that the we are compliant with the WCAG2.2 non-text contrast Success Criterion. @dancormier I would appreciate if you could review how I have extended the test utils. I do think this extension could help us also to test for the Focus Appereance SC in targeted components answering the open question in this WIP PR.

Open Questions

Our highcontrast-light mode still fails the WCAG2.2 non-text contrast Success Criterion. See failing tests (WCAG Contrast Ratio 2.6:1) in this PR. @CGuindon I guess this should be fixed before we merge this in?
We are currently testing for this SC only against the Pagination and Navigation component because they were mentioned in the original ticket. I do believe more components need to actually be checked/tested though. What about buttons and button groups?
[Tangent] I was wondering if we can assume that any element containing text need to have a WCAG Color Contrast Ratio of at least 3:1 (regardless of APCA). I am asking because if that is the case we might want to create an axe-core rule that check against that.

netlify[bot] commented 1 year ago

Deploy Preview for stacks ready!

Name	Link
Latest commit	8e4fa2dc2b7350c45028fe6c640ad4f814ea1f93
Latest deploy log	https://app.netlify.com/sites/stacks/deploys/654522615b76550008f941db
Deploy Preview	https://deploy-preview-1550--stacks.netlify.app
Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

CGuindon commented 1 year ago

I'll look into HC today to see if we can change something to fix this (at least on pagination and navigation)

What about buttons and button groups?

Our buttons don't use the orange color, just the blues and blacks so we don't have to worry about those components. The only other component I can think of that uses orange might be the voting arrows but it's a different UI (has borders and different fill as well) so it ends up passing for different reasons. Nothing else I can think of uses a straight orange background only to signal an interactive change to users.

I was wondering if we can assume that any element containing text need to have a WCAG Color Contrast Ratio of at least 3:1 (regardless of APCA). I am asking because if that is the case we might want to create an axe-core rule that check against that.

I don't think that would work... I believe there are a few color combos that hit our APAC 60 or 70 rule but don't meet AA 3:1 ratio. I could be wrong but I recall coming across that scenario while exploring certain color alterations.

giamir commented 1 year ago

@CGuindon

The best path forward I can see is to make change the orange color stops in Light HC mode to hit the AAA standards we need.

Honestly I am a bit confused around what we are after. I really would like us to start being very specific and detailed about the WCAG rules we are targeting (for example by including links to Success Criteria from the WCAG docs). I thought that this fix was related to failures related to Success Criterion 1.4.11 Non-text Contrast.

From what you are writing we are now referring also to 2 other success criteria:

Success Criterion 1.4.3 Contrast (Minimum). This is the one necessary to reach AA level for text and images of text (4.5:1 for body text)
Success Criterion 1.4.6 Contrast (Enhanced). This is the one necessary to reach AAA level for text and images of text (7:1 for body text)

So for me we either categorize the pagination and navigation components as non-text content (see definition) or as regular text.

If we categorize them as non-text content then this criterion apply:

Success Criterion 1.4.11 Non-text Contrast

This means we need to have a 3:1 contrast ratio (AA). There are no other criterion to satisfy for AAA.

If we categorize them as text content than this 2 criteria apply:

This means we need to have a 4.5:1 contrast ratio for our regular modes (light and dark) and a 7:1 for our highcontrast modes.

I see how all of this might sound pedantic but I think it is really important to be precise about this stuff to:

Avoid communication misunderstanding on implementation
Be confident on our claims (e.g. our pagination component is WCAG2.2 AA compliant)
Be able to test the changes so that we can prevent regressions

So in a nutshell my question is: what are we fixing?

A. a non-text contrast issue (which would require 3:1 contrast ratio)
B. a text contrast issue (which would require 4.5:1 contrast ratio for regular modes and 7:1 for highcontrast modes)

giamir commented 1 year ago

Thanks for implementing these changes @giamir! I have a few questions about the WCAGNonTextContrast function you added. (Ignoring a11y failures for now), the changes seem solid.

@dancormier Somehow I cannot see the questions you have (in case you have written them down somewhere). Or maybe you want ask them sync in person?

giamir commented 1 year ago

Open conversations have been addressed in a sync way. You can find the outcomes in this commit.

StackExchange / Stacks