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

Text and Non-text Contrast #29422

Open
lucalanca opened this issue Sep 19, 2019 · 17 comments
Open

Text and Non-text Contrast #29422

lucalanca opened this issue Sep 19, 2019 · 17 comments

Comments

@lucalanca
Copy link

lucalanca commented Sep 19, 2019

Operating system and version: All
Browser and version: All
Report: https://www.aditus.io/button-contrast-checker/getbootstrap-com-2019-09-12-at-15-02-11-139

Most buttons and links of the framework don't meet contrast criteria in all or some of their states.

Examples

Primary Button
Screenshot 2019-09-19 at 14 42 29

Success Button
Screenshot 2019-09-19 at 14 43 12

Happy to help you guys in this regard, but I think it's mostly a design decision that needs to be made on the default colors. I want to take some time to see if I can investigate a set of variables that pass AA and AAA when it comes to contrast without changing too much of the design.

@XhmikosR
Copy link
Member

Thanks for this, we have already many issues in the past about it, so we are definitely aware of this.

I have already landed a PR for the docs for master, and for core I have #29198 but I don't like the changes except for the blue color and maybe the pink one.

Also, note I have a WIP PR to automatically check for accessibility issues on #29315.

@lucalanca
Copy link
Author

lucalanca commented Sep 19, 2019

@XhmikosR your branch is a lot better. It still has a lot of issues but it's definetely better:

Screenshot 2019-09-19 at 15 23 59

For example, comparing to the buttons I shared above:

Primary Button
Screenshot 2019-09-19 at 15 24 17

Success Button
Screenshot 2019-09-19 at 15 24 23

I don't know where is the best place to focus on contrast of buttons alone. This issue or the one of your PR.

@XhmikosR
Copy link
Member

I don't think we'll land the other colors changes. I mean, there's a huge difference for green.

But for blue and maybe pink, we can move forward in my PR.

@XhmikosR
Copy link
Member

XhmikosR commented Oct 2, 2019

Blue and pink should be fine now on master. I'm not sure about the other colors because they change a lot.

@MartijnCuppens
Copy link
Member

That tool is checking for the contrast for shadows & outlines, we shouldn't worry about that. As mentioned by @XhmikosR, I wouldn't darken the green and teal colors more, because it looks like the buttons are hovered or focused with these darkened colors.

@lucalanca
Copy link
Author

@MartijnCuppens why shouldn't we worry about shadow/outline contrast?

@MartijnCuppens
Copy link
Member

If we want a higher contrast between the page background and the button focus shadows, we'll get less contrast between the button background and the shadows.

@patrickhlauke
Copy link
Member

we'll get less contrast between the button background and the shadows

but that is irrelevant, as the shadow visually changes the appearance of the button, making it bigger. so even if a user can't see the contrast between the shadow (acting as the focus indicator) and the actual button, they can still perceive that the button got "fatter" (i could have sworn there was an example of this on the WCAG 2.1 1.4.11 understanding doc https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html but it may have been in a separate document/discussion)

@lucalanca
Copy link
Author

@MartijnCuppens I see what you mean, but I think this is not an issue. One option could be to give a outline-offset so that the focusing and the button are disconnected.

@mdo
Copy link
Member

mdo commented Oct 9, 2019

No plans to adjust the focus styles. Also worth noting that we don't use outline styles, we use custom box-shadows.

@patrickhlauke
Copy link
Member

No plans to adjust the focus styles.

Then this will need to be noted as a known accessibility shortcoming.

@mdo
Copy link
Member

mdo commented Oct 9, 2019

Well I say that and this idea comes to mind, but does come with limitations that may be deemed too clever for the project. See https://codepen.io/emdeoh/pen/yLLNZRb. Uses background-clip: padding-box and a transparent border to recreate the offset an outline can have.

@MartijnCuppens
Copy link
Member

@mdo, we could also work with double outlines, see https://codepen.io/MartijnCuppens/pen/XWJzVBm. I think this technique will give the least issues with for example input groups since we don't fake our border:

@ffoodd
Copy link
Member

ffoodd commented Apr 1, 2020

@mdo @MartijnCuppens Just to mention that your graphic proposal is probably the best: Edge and Chromium adopted a similar approach and Firefox is considering to do the same.

Definetly worth it 👍

@ffoodd
Copy link
Member

ffoodd commented Dec 18, 2020

See also #31360 for @patrickhlauke 's inventory of what's wrong in v5.

@mdo
Copy link
Member

mdo commented Jan 12, 2021

Tagging with help wanted to see if we can get some love on this from others. I'm open to new solutions for focus styles, but not something that's overly clever and cumbersome to use. I know outline is gradually getting better, but it's still not 100%. So far I don't think anyone has found a better solution that our current one.

@patrickhlauke
Copy link
Member

I don't think anyone has found a better solution that our current one.

I think a bit of experimentation for v5 may be in order to see if we can future-proof stuff, pushing the default focus to be a bit stronger by default (perhaps all the way up to 3:1 ratio), plus future-proofing it with some additional :focus-visible tweaks.

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

No branches or pull requests

6 participants