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][Violation][1.4.3 Contrast (Minimum)] File browser "New" button contrast does not meet WCAG 2.2 requirements #16888

Closed
nkn2022 opened this issue Oct 23, 2024 · 14 comments
Labels
bug status:Needs Triage Applied to new issues that need triage tag:Accessibility

Comments

@nkn2022
Copy link

nkn2022 commented Oct 23, 2024

Description

I am running an accessibility test suite with Jupyter using the IBM Equal Access Accessibility Checker tool on Chrome browser. The results look good overall, only a few things are missing to reach a first formal level of compliance. So kindly help look into these.

Issues reported were violating WCAG 2.2 requirements.
Ref: https://www.ibm.com/able/requirements/checker-rule-sets

Listing of violations categorized based on the checkpoints.
Full report (includes information on element locations where issue were found):
Accessibility_Report-Untitled.ipynb - JupyterLab.xlsx

Category: 1.4.3 Contrast (Minimum)

Ref: https://www.ibm.com/able/requirements/requirements/?version=v7_3#1_4_3

Violation of Rule: text_contrast_sufficient

List of issues with elements that violate this rule with a screenshots

Issue 1
Text contrast of 4.18 with its background is less than the WCAG AA minimum requirements for text of size 12px and weight of 400
Element location:
<jp-button minimal="" appearance="stealth" current-value="" tabindex="0" title="New Launcher (⇧ ⌘ L)" data-command="launcher:create" aria-label="New Launcher (⇧ ⌘ L)" aria-disabled="false" class="jp-ToolbarButtonComponent">
Screenshot:
image

Reproduce

Here is the screenshot of the UI scanned for the attached report:

image

Expected behavior

No violations are reported on the scanning to reach a first formal level of compliance.

Context

  • Operating System and version: MacOS Sonoma Version 14.5
  • Browser and version: Chrome Version 129+
  • JupyterLab version: Version 4.2.5
@nkn2022 nkn2022 added the bug label Oct 23, 2024
@jupyterlab-probot jupyterlab-probot bot added the status:Needs Triage Applied to new issues that need triage label Oct 23, 2024
@nkn2022 nkn2022 changed the title a11y][Violation][1.4.3 Contrast (Minimum)] Accessibility issues reported on JupyterLab UI using IBM Equal Access Accessibility Checker tool [a11y][Violation][1.4.3 Contrast (Minimum)] Accessibility issues reported on JupyterLab UI using IBM Equal Access Accessibility Checker tool Oct 23, 2024
@JasonWeill
Copy link
Contributor

Might be good to check the same elements using JupyterLab's high contrast theme, which is specifically intended for users who need higher contrast than the default theme offers. Do you still see the problems in that case?

Also, we might want to update the JupyterLab accessibility statement to mention contrast, because we've had questions like this come up before.

@krassowski
Copy link
Member

@JasonWeill
Copy link
Contributor

Code coloring is already covered by #14255.

Link styling is in #14166.

Adding tests for a11y as part of PR timelines is covered in #9742, which also mentions IBM's accessibility checker.

@JasonWeill JasonWeill changed the title [a11y][Violation][1.4.3 Contrast (Minimum)] Accessibility issues reported on JupyterLab UI using IBM Equal Access Accessibility Checker tool [a11y][Violation][1.4.3 Contrast (Minimum)] File browser "New" button contrast does not meet WCAG 2.2 requirements Oct 29, 2024
@JasonWeill
Copy link
Contributor

Retitled this to cover only sub-issue 1, about the "New" (+) button in the file browser.

@nkn2022
Copy link
Author

nkn2022 commented Oct 30, 2024

@krassowski I think you had the foreground and backgroud switched. Can you double check?
Also I see that the button is using hex #1976D2 for the color not #0078CE.

image

when I check with that I get a different value 4:6:1.

image

@krassowski
Copy link
Member

I used a color picker which might have been slightly off but my point is that 4.18 in your report does not agree with what I see:

Text contrast of 4.18 with its background is less than the WCAG AA minimum requirements for text of size 12px and weight of 400

Since 4.6 is greater than 4.5 which is the WCAG AA minimum requirements for text of size 12px and weight of 400.

@krassowski
Copy link
Member

krassowski commented Oct 30, 2024

I think you had the foreground and backgroud switched. Can you double check?

This does not matter because the contrast calculations in WCAG 2.x are not very clever and do not account for the difference between background and foreground at all (which bites Jupyter which uses a beautiful orange background but some folks came and changed perfectly readable white text to unreadable black to satisfy arbitrary rules of WCAG 2 contrast checkers, see jupyter/jupyter.github.io#587 - this is only getting fixed in WCAG 3 with APCA)

image

@krassowski krassowski added the status:Needs Triage Applied to new issues that need triage label Oct 30, 2024
@krassowski
Copy link
Member

Using another color picker I again arrive at #0078CE (which is why I think you cannot relay on automated checkers that match as they will look say at the background attribute but ignore opacity or CSS filters which modify the color), at least on https://jupyter.org/try-jupyter/lab/

image

@nkn2022
Copy link
Author

nkn2022 commented Oct 30, 2024

Thanks. Yes, that may be the reason here. I will confirm soon.

@krassowski
Copy link
Member

I see what happened with the contrast checker that you used. It indeed blindly extracted the background and color even though there is no text, but only white SVG. Understandably it gets lost with web components/svg and just attempts to use what it sees in the CSS:

image

image

Since 4.19 is very close to 4.18 that you reported I think this is what happened. I think this is not a real issue then.

@nkn2022
Copy link
Author

nkn2022 commented Oct 30, 2024

I agree with you. I will close this for now. Thank you for the investigation.

@nkn2022 nkn2022 closed this as completed Oct 30, 2024
@nkn2022
Copy link
Author

nkn2022 commented Oct 30, 2024

Adding the response from the tools team here for reference.

Phill Jenkins
:beequala11y: [16 minutes ago]
I'll might open an issue with the Checker to compare how it calculates the contrast vs how other tools do it, such as the CCA tool.point is sufficient, while the edges are not. So, in my opinion the Checker is correct in flagging this as a contrast violation.
image

NISHA NAIR
12 minutes ago
Okay. Thank you very much for checking. Should we chase the team to fix this gradation problem then? Not sure how critical this is from a user ’s perspective. (edited)

NISHA NAIR
[10 minutes ago]
I will put your comment in the external issue so they are aware of this issue.

Phill Jenkins
:beequala11y: [3 minutes ago]
Yes I would recommend that the SVG icon (it doesn't look like real text "+") get improved. At 100% zoom it fails, so the low-vision may miss that there is a "+" over that blue button. But since there is only one "blue button", seeing the "+" is not a critical.
When zooming out the SVG it looks a lot better, but it doesn't need to have that gradation in my opinion.
👍
1

Phill Jenkins
:beequala11y: [Just now]
They could also replace that SVG + icon with regular text + and it probably would not fail. The blue selected Name/Modified items in the list (white text on blue) do not fail contrast.

@tombrunet
Copy link

tombrunet commented Oct 30, 2024

The tool does in fact handle opacity, but that's not what's going on here. The reason this is flagging is that the foreground color of the button is specified as a slightly transparent black.
image
The SVG is overriding this color (which is why it's flagging the button and not the svg). We'll have to look to see if we can handle this better with the SVG defined colors, but if you have any buttons with the same CSS and there's text instead of SVG, it would have an issue.

@krassowski
Copy link
Member

Thanks @tombrunet, this confirms my guess from #16888 (comment) then. Indeed it could be an issue, but it's only this single button which has blue background (the rule targets it via command id) so it is guaranteed to have a white icon rather than any text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug status:Needs Triage Applied to new issues that need triage tag:Accessibility
Projects
None yet
Development

No branches or pull requests

4 participants