Hello,
I was wondering if we could have more accessibility classes to control our CSS appearance, such as color contrast. Right now, it seems there’s no way to toggle settings that enables us to use CSS rules like prefers-contrast
or prefers-reduced-motion
. An alternative solution that would be easy to implement, and wouldn’t require dealing with QT-specific issues, could be adding classes like accessible-contrast
and accessible-motion
— similar to how .nightMode
works for dark mode.
For me, this would help make better color contrast decisions when working with the APCA guidelines, as higher contrast doesn’t always equate to better legibility for everyone.
Thank you for reading!
Note: a toggle for “Enabling accessbility mode” may be misleading if it doesn’t actually modify the UI to be accessible-- so a card reviewer specific toggle like this might be the way to go:
Card Reviewer: Accessibility
- Enable support for Color Contrast
- This allows cards to use color contrast rules (if any)
- Enable support for Reduced Motion
- This allows cards to use reduced motion rules (if any)
2 Likes
Please correct me if I’m misunderstanding your post, but aren’t the CSS media features prefers-contrast
prefers-reduced-motion
prefers-color-scheme
(and so on) managed entirely by the web browser?
That is, is not needed to make any changes to the app’s source code to take advantage of them as long as your browser offers Media Queries level 5 support; which are widely available at the time of this post.
For example, I’m currently using something like this to bring support to my flashcards in both light and dark mode (through an OS setting) with no issues so far:
.card {
background-color: #fbfbfb;
color: #333;
}
@media (prefers-color-scheme: dark) {
.card {
background-color: #3c3c3c;
color: #e8eaed;
}
}
Or as an accessibility example more tailored to your question, you can remove all animations in your content and increase contrast if needed with the following styles:
@keyframes pulse {
0% {
transform: scale(1);
}
25% {
transform: scale(0.85);
}
50% {
transform: scale(1);
}
75% {
transform: scale(1.15);
}
100% {
transform: scale(1);
}
}
.card {
animation: pulse 1s linear infinite both;
}
@media (prefers-reduced-motion: reduce) {
.card {
animation: none;
}
}
@media screen and (prefers-contrast: more) {
.card {
background-color: #fff;
color: #000;
}
}
Of course, you can expand the above rules to better suit the specific needs of your notes’ content or intended audience.
Sort of. It’s a combination of the web browser and the OS. The OS passes the preferences through its accessibility settings. The OS can often be the problematic part; for example, Microsoft doesn’t differentiate between prefers-contrast: more
and prefers-contrast: less
(see this post by Microsoft and this article).
Since Anki should work in any browser (via AnkiWeb) and on *nix systems, this fix should cover most cases. It’s also easy to reverse as WCAG guidelines evolve (to 3.0).