Some of the colours used on buttons do not meet Web Content Accessibility Guidelines (WCAG)

[joelamyman]

Issue

The contrast on the .btn-primary, .btn-danger and .btn-link button classes do not meet the required color contrast ratio of 4.5:1, (WCAG 1.4.3 Contrast).

To resolve this issue

Increasing the contrast would solve this issue, happy to recommend some colors or create a pull request with some ammendments.

[halfmoonui]

Hey, thank you for bringing this up. From my point of view, the buttons in Halfmoon are quite readable to the naked eye. Going with the strict rule of 4.5:1 here would make the aesthetics of the framework worse, and in return bring in negligible improvements in readability. Also, this is one of those rules that most websites fail at, including other frameworks:

Bootstrap primary button:

Bulma primary button:

Materialize primary button:

Not saying that its okay to follow a bad practice just because it is popular, but I think there is good reason for it. As I mentioned above, if it is readable to the naked eye, following the theoretical guideline often makes the aesthetics worse, which is of course very important in web design. And the trade-off is usually not worth it.

PS Bulma's button is not actually properly readable, and they should probably increase the contrast a little.

EDIT I tried Tailwind's blue-500 as the button background, the contrast ratio got worse. Seems like if you want to make a blue button on the web, you either go with dark blue or don't meet the WCAG guideline. I am willing to solve this issue but dark blue just doesn't look good with Halfmoon's default theme, especially dark mode.

[joelamyman]

Thanks for responding, I understand that you're hesitant to change the current colors because of the following:

• It may decrease the aesthetic appeal of the framework
• Other frameworks don't consider contrast requirements with default values

In regards to the first point, it is not the case that you can't have both aesthetic appeal and an accessible user interface.

However in terms of prioritisation, I think it's important that the design is as accessible to as many people as possible. While the current contrast may look fine to some people, given the different needs of individuals and different use cases, it may be problematic. Conforming to the web content accessibility guidelines means that it should be as accessible to as many people as possible, yet even then it may not be accessible to everyone! However, allowing as many people to use sites with halfmoon would be a great goal.

I think that even if the primary button color was changed to something like #0074E0, halfmoon would then be meeting the WCAG 2.1 AA requirements without a major change to aesthetics.

Moving onto the second point, I think that it's poor that other frameworks are not accessible by default. Your point about Bulma's primary button is spot on, the contrast for that item is poor and the font-weight: 400 rule does not help this. I see that these frameworks will then say something like, "We're not accessible by default, but you can easily make it accessible". But let's be honest, not many people are going to change those defaults.

Instead, it would be fantastic if there is a framework that says, "By default, with no extra work needed, our components meet WCAG 2.1 AA". I think that would really differentiate a framework from the rest, I think that would be a big selling point. It would then start to go some ways towards helping more sites to become more accessible to all users of the web.

[halfmoonui]

I set the following: --primary-color: #0074E0, and while this fixes the accessibility issues for the primary button, the contrast ratio for links and link buttons goes down in dark mode. I think the built in dark mode creates an extra challenge for making everything look good and also be accessible at the same time. On top of that, I think the darker blue #0074E0 buttons look worse overall (purely in terms of aesthetics).

However, I do agree that you bring up some great points, and striving for better accessibility out of the box is definitely a good goal to have. But perhaps a different approach is needed for a framework like Halfmoon. I have seen that Apple has two sets of colors for their system: light mode and dark mode. On top of that, they have an extra pair with better accessibility: https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/

Perhaps a similar approach would work well here too.

[CooperCorona]

I'd like to echo joelamyman's points and try to address some misconceptions.

• Apple's guidelines encourage 4.5 contrast ratios for normal text (3.0 for bold or large text). High contrast mode is "above and beyond", but contrast ratios should still reach those thresholds in default light and dark mode (though Apple's colors here do not meet these guidelines, some not even in high contrast mode!).
• You say #0074E0 increases contrast in light mode but decreases it in dark mode. Are you using the same link color in both modes? Using Apple's colors as an example again, they are different in light and dark mode. All colors are slightly lighter in dark mode to better contrast with dark backgrounds. Using a similar pattern would expand Halfmoon's options for accessibility and aesthetics. I see you have --blue-color and --blue-color-dark, but I don't know if the latter is "blue in dark mode" or just "dark blue for accents".
• Finally, I think "if it is readable to the naked eye, following the theoretical guideline often makes the aesthetics worse" illustrates a misunderstanding of the WCAG guidelines. A 4.5 contrast ratio IS "readable to the naked eye". Anything less is not. That's the minimum contrast ratio WCAG has defined as being broadly accessible. You say the colors are readable to you, but they may not be readable for some or even most others. People with visual impairments, with small devices poorly lit devices, people in environments with poor illumination or too much illumination all depend on sufficient contrast ratios. Accessibility is defined by if all people can access something, not just some or one.

I only recently discovered Halfmoon, but I'm excited to use it and see where it goes. But I'd be more excited if it had accessibility "baked in". This would be a huge advantage for Halfmoon, for developers using Halfmoon, and for users of sites developed with Halfmoon.