The customer (default settings) has a bug in the last version 6.3.0.
According the the docs the default color of the label is white.
$label-color Color || $white || Default text color for labels.
However, the default color right now is #0a0a0a after downloading the default custom build.
This is not only for the label, but also but accordion and probably more.
So there is some bug related to #0a0a0a
Hi @Vuurvlieg,
Since v6.3.0, Foundation is using a11y-compliant colors (see #9319). It means that when the background color is too light, we use $dark instead of $white for text color (see scss/components/_label.scss:60).
Maybe we should update the docs of all color variable $*-color. @andycochran what do you think ?
I do not like the ally-compliant colors because even when the background-color is dark enough the read the white text, Foundation think it is too light. So in example even the .button.success is not readable enough Foundation thinks, but it is actually when you use the default white color text.
Is there any way to revert back to the old way of coloring using v6.3.0?
There is no way to bypass the contrast check in v6.3.0. But you can always set the same alternative text color like the standard one ($button-color, $button-alt-color).
@andycochran Should we make a11y optional ?
I do not like the ally-compliant colors because even when the background-color is dark enough the read the white text, Foundation think it is too light.
But is it really dark enough? Some folks' vision isn't as good. This isn't a judgement call by Foundation; it's WCAG.
@ncoden, I don't know about making a11y optional altogether. But maybe we could use a settings variable to adjust the threshold?
@andycochran I think we should at least make the treshold customizable. I really want websites to care about accessibilities, but we have to recognize that _sometimes_ a11y-compliant colors can ruin a design for only a very small benefits for folks with a bad vision.
I'll try making tolerance configurable in the color-pick-contrast() function…Â
Maybe we should update the docs of all color variable $*-color.
– @ncoden
The docs do indicate the new $[component]-color and $[component]-color-alt variables. http://foundation.zurb.com/sites/docs/label.html#text-colors
Yeah - I've noticed after upgrading some projects to latest release that buttons, even really dark ones have text in black, which really isn't ideal - see attached.
Font family also differs now on input[type=submit].button vs a.button - cased by normalize-mixin.scss where button, input, optgroup, select, textarea has font-family set to sans-serif.
Input-group-button font size also goes larger than in the previous version.

@sebastiansulinski were you able to address with $button-color-alt?
@andycochran have you been able to look at making tolerance adjustable?
I simply made $button-color-alt: $white as all buttons I use are rather on the dark side.
Looks like this was fixed by @hikouki in #9747?
To be honest I really don't like a11y-compliant colors at the moment but https://github.com/zurb/foundation-sites/pull/9747 will help a lot, so thanks!
@Vuurvlieg Yeah, I wouldn't say I like the colors either; they're not the prettiest. We debated the default color palette for quite a while, trying to get it right. But we were determined to meet WCAG 2.0 level AA contrast requirements out of the box. What we landed on was changing the old palette as little as possible to meet AA. I'd love to see some prettier options, if you could suggest a better default palette.
Closing based on the above conversation, but would also love a PR with a better default palette that still meets WCAGT 2.0 level AA
If anyone wants to search for a better default palette, I made this tool that spits out variations of background colors and indicates which of those meet AA requirements and with which text color.
https://andycochran.github.io/foundation-a11y-palette-picker/
If you run it locally, you can give it a specific palette and text colors.