It’s a good idea to have alternative colour schemes also, such as dark scheme or a colour scheme that is friendly to red/green colour blindness.
6 Likes
Nobody was threatening to sue anybody. I am in a position to know that there’s been a recent uptick in the number of ADA-based lawsuits against websites for failing to be compliant. The firm I work for is currently in the process of re-designing to be WCAG AA compliant. But ultimately, I wouldn’t have brought it up except that I’m literally having trouble reading the light-gray text on white backgrounds in the lessons.
Note: It’s actually easier to read the text in these screenshots because they are resized, which makes the contrast appear higher than it looks on my screen.
4 Likes
Another thing to consider is that color contrast doesn’t exclusively determine a text’s legibility.
You can have pure black on white text with a color contrast that’s WCAG AAA compliant, but if the text is presented in a script-style typeface (like cursive) or at a tiny size or with abnormal kerning, its sufficient color contrast is not going to guarantee that it’s readable, like @textheavy’s screenshots demonstrate.
The text on this interface might pass contrast checking but I also find the font sizes within the tabbed content on the Lessons pages to be too tiny to be read comfortably given the font’s lighter weight.
2 Likes
For the Supplemental Info sections beneath the header of the Lessons page, I would apply the following styles to increase legibility while maintaining the feel of the design:
#supplement-info {
font-size: 18px;
}
.pronunciation-variant {
font-size: 22px;
}
I think it reads a lot easier. I’d be curious if @textheavy agrees.
Note to the site maintainers: Avoid using IDs for styling. I would’ve used a class in my suggested code but there doesn’t appear to be one available on the pertinent element.
1 Like
In my Lessons, I only had vocabulary today so I’m only checking the contrast of the purple.
As noted before, there are visual elements contributing to the contrast besides foreground and background color, particularly an inset box-shadow, a background-gradient, and a text-shadow. I noted that the color of the text-shadow (#9300dd) is the same as one of the two colors in the background-gradient, which simplifies things somewhat. The box-shadow is just a black color that’s mostly transparent.
The text-shadow and box-shadow are essentially invisible to axe DevTools as far as I can tell. They don’t interfere with the automatic color contrast check. Also, because they have a darkening effect and the foreground color is white, they should theoretically help with increasing contrast. Since they don’t interfere with the automatic check, I let them be.
For my experiment, I disabled the background-gradient using the developer tools and set the background-color to only one of the colors in the background-gradient and performed the check. I then did the same with the other color in the background-gradient. This effectively checks the contrast of the colors in between the extremes of this gradient.
Both pass AAA for large text, but normal-sized text has only AA compliance.
Foreground Color: #ffffff
Background Color: #a0f
Link: WebAIM: Contrast Checker
Foreground Color: #ffffff
Background Color: #9300dd
Link: WebAIM: Contrast Checker
I even checked the fallback background-color and it’s effectively the same.
Foreground Color: #ffffff
Background Color: #a100f1
Link: WebAIM: Contrast Checker
So, there’s a little bit of room for improvement for color contrast on the Lessons page, if AAA compliance is sought by the site maintainers.
1 Like
Personally, I think you’d be better off replacing those reasons with the following:
If you want to style a class of things, use a class selector. If you want to style a specific thing, use an id selector. Compound selectors should generally be built from a combination of those same two rules.
The specificity rules were designed around that notion.
2 Likes
Just a question for you since you’re familiar with this sort of thing,
It doesn’t make much sense to me why you can sue a company for this, wouldn’t a simple force of change to be compliant be enough, with maybe a small fine at most? It’s not like WaniKani is providing something essential for someone to live to the point that someone who has trouble reading due to color is going to be effected or hurt in any way.
I’m not saying they shouldn’t change it, if it hinders people then I definitely support it, just a bit baffled that you can sue for this, it kind of feels like you can sue for just about anything.
1 Like
For people worried about lawsuits, no one has ever sued anyone over the color contrast rules in WCAG as far as I know. (Or if they have, they haven’t gotten very far.) Web accessibility lawsuits usually focus on support for screen readers: programs which read the contents of a website out loud so blind people can use it.
Screen readers seem like a whole other can of worms for WaniKani, given that the entire mnemonic system depends on visually recognizing parts of a kanji.
True, the design of CSS allows you to use IDs. However, in practice, using IDs for styling becomes a trap that many inexperienced front end web developers fall prey to because they don’t have the experience to understand the drawbacks of working with them long-term on large projects.
Watch this talk for a more comprehensive argument by a more experienced developer: Harry Roberts—Big CSS - YouTube
If you think about it, it’s not. If you are a user that relies on a screen reader to browse the web, you are not reading by sight. You rely on sound (and/or touch) to read. So what use would you have in the portion of a website designed for the very purpose of learning to read Japanese by sight? Screen readers negate the challenge of reading by sight.
With that said, there is certainly a need to ensure that the public-facing aspects of WaniKani (like the homepage) remain accessible to screen reading technology, and that the Lessons portion of WaniKani remain accessible for users who have a sight disability but are capable of reading by sight and do not rely on screen reader assistive technology (like me).
For anyone who’s still looking for a resolution, I’ll share mine. Rather than waiting for the site maintainers, I’ve decided I’m going to be the change I want to see in the world and I’ve begun taking advantage of my browser’s user stylesheet to implement custom CSS. I’ve been steadily developing a set of styles to make WaniKani dark mode, accessible, and WCAG AAA compliant.
Anyone can use this technique for themselves: https://www.lostsaloon.com/technology/using-a-custom-stylesheet-in-a-web-browser/
Dashboard
Vocabulary Page
Individual Kanji Page
Quiz Page
It’s still a work in progress. I just customized the parts I encounter the most but I’m far from finished. If anyone’s interested in seeing the CSS I’ve developed so far, let me know.
4 Likes
I just assumed that mods checked these categories, but @Mods maybe it got passed over? Seems like a somewhat important thing
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.