Font contrast and WCAG requirements

Not sure how best to get this info to someone who could act on it. I see it came up back in 2013, but it looks like it’s an ongoing issue…

I’m pretty sure that the text color for the content of the lessons is too low in contrast against the white background. I looked in the CSS but it’s too much of a slog for me to find the specific hex codes. I can only suggest that someone who can change the CSS check it against a recommended contrast tool that can clearly indicate whether it’s WCAG compliant (e.g. WebAIM: Contrast Checker)

I work on sites for law firms and I know that there are people out there bringing ADA lawsuits against sites that don’t meet WCAG requirements. My vision is generally pretty good, but even I’m having trouble with the text on the lesson pages. It really behooves the publishers of this site to act before they find themselves being served.


I’m honestly really confused by what you mean here. On my screen

the text shows up as a black or near black color and the main visibility issue is the size of the font. WK handles zoom well though, so it will move to fit the screen when further zoomed

The only gray text that I can see on vanilla WK is the accent selection.

Also tbh, I’m pretty sure the size of the text on my screen being small is part of an odd computer error since my screen is dual displays vertically arranged.

I’m using Google Chrome on a laptop. The font in the lessons is very light gray on a white background. The next time I do a lesson series I’ll grab some screen captures.

The text color is #333 which, when plugged into the contrast checker, gives a pass for all WCAG tests:


Interesting, over in POLL’s, @saibaneko’s showed up differently

The text is the description text in lessons…the scheduled lessons. Like I said, I’ll post it when I have my next lesson. Not sure when that will be.

1 Like

Yes, the lessons, which is what my screenshots are of. Unless you are talking about something else.

The lessons you get inside the app in wanikani? These are the kanji/vocab pages.

No, wait, you’re right, it just seemed that way.

I’m glad to see someone else concerned with web accessibility here.

Despite the site’s nice design and attention to detail, I’ve been suspecting this site has had a lot of issues with accessibility over the years. It’s definitely in need of an update. A high contrast mode update would be really nice.

Your post inspired me to finally get around to checking the contrast of the waiting states of the Lessons and Reviews buttons. The color contrast check there fails too. It’s surprisingly not even AA compliant.

Foreground Color: #ffffff
Background Color: #b1b1b1
Link: WebAIM: Contrast Checker


To dispel any potential future confusion :roll_eyes:

Apparently, the site’s accessibility issues elsewhere are as bad as I expected.

There’s 120 color contrast issues detected by axe DevTools on the radical page for Horns.

I’ll do another check on the Lessons interface tomorrow during my next lesson. :flushed:

1 Like


That looks like an issue with the tool being unable to check the contrast, not necessarily WK.

It might be more like 13 issues:


I haven’t used axe DevTools before, I’ll have to remember that next time I’m checking ADA


True. There are visual elements present that are interfering with the color contrast check. There are a lot of background gradients. There is also a white text shadow applied to a lot of the text on this page and I’ve seen automated tools fail before to recognize the effects of text shadow on a color contrast score. Purely knowing the foreground and background colors won’t tell the whole story if there are other elements like text shadows and background gradients applied. The contrast check I did previously on the Lessons and Reviews buttons still holds because the text is on a solid background with no other interfering visual elements.

The breakdown of those 13 unrelated issues is as follows:

Critical Issues

Moderate Issues

Serious Issues

Interestingly, the total amount of issues detected by this plugin has decreased by 5 since my last check, while the amount of Serious issues increased by 1.

110 of the now 124 issues require manual review because of the following reasons:

  • Element's background color could not be determined due to a pseudo element
  • Element's background color could not be determined due to a background gradient
  • Element content is too short to determine if it is actual text content
    • The plugin appears to be struggling with interpreting kanji characters as text.
  • Element's background color could not be determined due to a background image

For example, in the case of the navigational text, the background gradient that’s applied to the containing navigational header is interfering with the color contrast check. The plugin reports the same background gradient problem for this text that it does for its color contrast check on the page title.

When the background gradient from the navigational header is removed using the browser developer tools and the check is run again, the plugin detects no color contrast issues for any of the navigational links. The contrast check for the foreground color of the navigation text #333333 and the fallback background color of the navigational header #fafafa passes AAA compliance. The total detected issues is reduced to 118.


When you guys compile everything you think should be mentioned, I recommend @ the mods or emailing the site. Accessibility is a big thing and I do agree WK doesnt seem to conform properly


That’s probably a good step to consider before threatening to sue, methinks.

I mean, I’m not a lawyer, but…


I think the sue comment wasn’t the op threatening to sue, rather warning that there are people who will sue sites for not being compliant.

Also, since its breaking some law or regularment (please have mercy I’m not american), I think wk would always lose whether they were contacted first to change it or not? Who knows


Well, the cited law in the OP was the Americans with Disabilities Act of 1990 (though I really feel like there’s a big chasm between deliberately violating said act, versus just being careless with site design…)


I checked the Reviews button on the Dashboard and it fails to pass WCAG AA for color contrast.

The rounded element representing the number of pending Reviews doesn’t have sufficient contrast.

Foreground Color: #00aaff
Background Color: #ffffff
Link: WebAIM: Contrast Checker

axe DevTools struggles to check the contrast of the “Reviews” text on this button because there’s a background image. However, the human eye can verify the background image does not interfere with the text. The inverse usage of the aforementioned colors gets the same failing score of 2.56 to 1.

Foreground Color: #ffffff
Background Color: #00aaff
Link: WebAIM: Contrast Checker

1 Like

Hi there!

Thanks for bringing this up. We take accessibility very seriously and if we are failing in any way on our website we will do everything we can to change this.

I will bring this up with our design team and I will let you know what they say.

Don’t forget you can always reach out to us at and we will always be happy to help!



I checked the Lessons button on the Dashboard and it’s also failing to pass WCAG AA for color contrast.

Foreground Color: #ffffff
Background Color: #ff00aa
Link: WebAIM: Contrast Checker

Unfortunately, I completed my lesson before mustering the patience to run the check on the Lessons interface. (laughs) I’ll have to wait again. Something to consider is that the three different background colors used to represent radicals, kanji, and vocab (blue, pink, and purple, respectively) may have different contrast ratios. To do a thorough check, all three will have to be presented in a lesson. They’ll likely have to be manually verified because they contain interfering background gradients and/or text shadows, which can disrupt automatic checks. I’m optimistic about the contrast ratio passing for the vocabulary color but less so for the radical and kanji colors given the results detailed above.

1 Like