Accessibility

[fabd]

Purpose

This issue is to collect accessibility related feedback. If any concrete item comes up I will create separate, actionable issues that can be closed.

Lighthouse

@magnonellie brought to my attention contrast issues that are detected by the Google Lighthouse tool.

As of writing, I am going to label this "nice-to-have" because some of the suggestions seem silly or fairly inconsequential. We also have to account that the audience is learning Japanese... so I assume if they can read kanji they can easily see the following items:

• the news date is a dark brown on a light cream color, pretty visible, it's bold text too
• the twitter button text is white against a saturated blue, pretty visible
• the green "push buttons" on the Home screen have white against a saturated green. This is a contrast of colour hue, but also brightness

/* "Elements must have sufficient color contrast (Failed on 13 elements)" */
#home-qs > div:nth-of-type(1) > .box.padded-box-inset.mb-p50 > .hd > .failed
#home-qs > div:nth-of-type(1) > .box.padded-box-inset.mb-p50 > .bd > .btn.btn-lg.btn-go
#home-qs > div:nth-of-type(2) > .box.padded-box-inset.mb-p50 > .hd > .expired
#home-qs > div:nth-of-type(2) > .box.padded-box-inset.mb-p50 > .bd > .btn.btn-lg.btn-go
#home-qs > div:nth-of-type(3) > .box.padded-box-inset.mb-p50 > .bd > .btn.btn-lg.btn-go
#sitenews > dl > dt:nth-of-type(1) > .newsdate
#sitenews > dl > dt:nth-of-type(2) > .newsdate
#sitenews > dl > dt:nth-of-type(3) > .newsdate
#sitenews > dl > dt:nth-of-type(4) > .newsdate
#sitenews > dl > dt:nth-of-type(5) > .newsdate
#footer > .k_bg_free > .container > section > p:nth-of-type(2) > a:nth-of-type(1)
#footer > .k_bg_free > .container > section > p:nth-of-type(2) > a:nth-of-type(2)
#ft-tweet_btn > a > span

[fabd]

These are things Lighthouse found:

Maybe it is looking for color-based contrast for color blind people?

We can address any of these issues but as a solo developer I'm going to focus on real uses cases, and address real user problems. I genuinely have never received any feedback on Koohii about things that are difficult to read. So this isn't something I need to focus on right now.

I should note here that I am well aware of the accessibility topic in general, though I'm not well versed in the "aria" stuff. Light text on light background color is also a pet peeve of mine. I don't think the website is guilty of that.

I think less contrast is acceptable for small, less important information. For example the redesigned Stories list have the "last edit" time in light gray. It is purposely made to be out of the way, and less important visually. If it is slightly difficult to read, it's not something that impairs the usability and functionality of the website. These are considerations I am well aware of.

[dotellie]

Yeah, it is for colorblind people (at least I think so). But what is preventing colorblind people from learning kanji? 😛

I get your point about focusing on more common usability problems, but also consider the following: you're colorblind, you want to learn kanji, you find RTK, you find koohii but notice it's difficult to read the website. Would you actually try to get in contact to have it fixed or would you label it as "just another of those websites that don't care about accessibilty" and just give up on it? Food for thought.

Considering how trivial most of these are to fix though, I really don't see the point of just leaving it when there is an issue with it.

[fabd]

What do you change? Make the twitter background darker?

As a developer I need clear steps; Is there some way of getting "whys" from this tool? ie. make it more saturated, make it darker, make the text larger, etc.

Since I am not color blind or visually impaired, I don't want to do guess work as to what a color blind person experiences. So either I get feedback from a color blind person, which I can act on. Or the tool gives clear explanations as to what is the issue to fix.

[dotellie]

I don't think it's fair to expect a tool to be able to give you exact steps on what to change, especially not when it comes to design.

At any rate, first off, a disclaimer: I am not a super expert on this subject. As far as I understand it, W3 has a standard for how to calculate the contrast and how to check what level it passes. Since that is incredibly annoying to do, you can just use this tool: http://leaverou.github.io/contrast-ratio/

[faneca]

An usability problem (well, more like a not-very-annoying-inconvenience-I-can-totally-live-with) is keyboard navigation throughout the menus. I don't remember when it happened exactly, it's been quite a while, but since the last menu revamp I no longer could logout by using just my keyboard. I only noticed because I tend to use keyboard shortcuts/commands/navigation for everything I use regularly, not for impairment reasons, so it never was a real annoyance to reach for the mouse or touchpad. I have to do that anyway for other actions in the site for which using just the keyboard is impractical.

That said, the SRS reviews work wonders in this respect (though I wish there was a keyboard shortcut to open the card's statistics -- the one you open with the hamburger icon), and I don't think implementing keyboard navigation thoroughly across the site will be worth it (unless an impaired user states otherwise). But I think it'd be nice-to-have both general menu and study pages' navigation with the keyboard. For the former, just being able to reach all items by pressing tab would do. For the latter, I don't really know: a "too obvious" keypress would likely be triggered most of the time by mistake (inadvertent users), while a too complex combination would be hard to trigger for impaired people, precisely the ones who should benefit more from it; also, it shouldn't interfere with history editing, which can be hard to pinpoint right.

[fabd]

We can definitely add a few keyboard navigation for frequently used actions.

Can you create a "Keyboard Navigation" issue? I will create actionables out of it after some discussion.

I don't think Keyboard navigation on desktop is strictly an accessibility, more of a usability thing for desktop users.