Accessibility on


I have some thoughts about improving the web accessibility of

Most of these relate to using the website on a desktop computer without a mouse. But they might be indicative of similar issues faced by users of screen readers / VoiceOver.

  • The “Levels / Radicals / Kanji / Vocabulary / Account” links at the top of the main page cannot be focused or opened with the keyboard (Tab doesn’t reach them). As navigation links, they should be <a> elements, not <h2> with an onclick listener attached.

  • Same for the expandable Review Forecast table. Rather than just <table> <tbody> <tr> with onclick listeners, they should use <a> or ideally the HTML5 <details> and <summary> tags.

  • Same for the “Wrap Up, Last 10…” button row on the lesson/review page. They are <li> with onclick listeners but should use <a>.

  • The little “Home” link has no outline when it’s focused. image

    I see that the page’s CSS has a:focus { outline: none; } in it. You should never do this!

  • The “cards” showing items by SRS level each show a breakdown into radical/kanji/vocab counts on hover.

    Hiding content until a mouse pointer hovers over it means users who don’t use a mouse can’t see it at all. It’s a common web accessibility pitfall! I think it’s worth avoiding this sort of thing unless you really need it, and I don’t think WaniKani needs it here.

    (Edit: I tried with VoiceOver on my iPhone and it’s impossible to get the breakdown to show up there too.)

    So, it might be better to just include this breakdown into the cards? Something like this (I know it looks cramped now — I’m no designer). Or maybe a different design entirely.


  • On the Level/Kanji/Radical pages, when an <a> gets focus, the radical/kanji is underlined, too. This is merely a little visually confusing.


  • This is neither here nor there, but I think the “wall of shame” items on WaniKani / Profile / lake should link to their pages (e.g. /kanji/捜 in my case).

Thank you for hearing me out!! Thank you for making this awesome application as accessible as it already is. Much love <3


I would honestly email them with these suggestions as well, because they should definitely address these issues and might not see this here.


That’s a good idea. I sent them an email, linking to this thread.


Shameless plug: I wrote a More Hotkeys plugin that adds some hotkeys to the review screen to improve keyboard accessibility. WaniKani team: feel free to add any of these that you like into the vanilla app.

  • Press W (after answering) to “wrap up”.
  • Press S to add a synonym.
  • Press M to edit the “meaning note” field.
  • Press R to edit the “reading note” field.
  • Press Shift+J to hear the other audio (Kyoko ↔️ Kenichi).
  • Press ? to show all hotkeys.

This is very interesting


This is also a problem for people with desktop touch screens or tablets.


Front page isn’t too bad. Besides the contrast issues, only one ‘error’


Also, 43? Come on @koichi, you’re obsession is slipping.


Yes, it looks like the “1 error” detected by WAVE is that the search box on the main page should get aria-label="Search" or something.

I noticed the input fields on WaniKani — Log in also need labels. They use the placeholder attribute as a label, which isn’t recommended.


WaniKani probably won’t ever be used by a screen reader user, since it is intended to train the visual recognition of kanji. But I agree that the accessibility could still be improved.

  • The “Levels / Radicals / Kanji / Vocabulary / Account” buttons at the top of the main page already have role="button" specified - they have just forgotten to add tabindex="0". I think this should satisfy accessibility requirements? EDIT: Oh, wait - I just realized that they don’t listen for Enter and Space on these. That should also be fixed.
  • The buttons on the review screen (Wrap Up…) are neither <button> elements nor have role="button" specified. I agree that this should be changed.
  • For the popup on mouse hover - the SRS stage “cards” currently don’t have any click functionality, so maybe they could turn them into buttons and make a click toggle the popup? But I also think that the breakdown in the popup is not essential and it wouldn’t be a loss not being able to access it.

WaniKani probably won’t ever be used by a screen reader user

Hmm, I know there are a lot of users who have some impaired vision who use a screen reader as a supplement. For them, accessibility could mean “not having to squint or zoom in a bunch to log in to the website.” I believe screen readers are also used by some people with dyslexia. Both of those groups might have more trouble learning kanji, but it’s not unthinkable.


Killer suggestions! Thanks a ton :raised_hands:


There’s one thing I want to add to this thread that I cannot see has been touched on yet.

Any accessibility issues you find on Wave or via other, similar tools whether free or commercial, will give you just a fraction of the errors you could have present on a website in relation to it being accessible. The rest of them must be manually identified by an expert - and all of this before the user experience of each of those disability categories are considered. Then there is the challenge of multiple disabilities to address, so certain user experience scenarios are avoided.

Just to give one example of an issue a machine cannot identify that is present on WaniKani:

Question; Where is the focus currently? Are you able to tell?

If you said “on the happiness radical” then congrats, you do not suffer from Usher Syndrome or another type of low vision disease.

Now imagine a user that sees as if “through a straw” knew to find the location via the link info at the bottom of the page (which, not all browsers supply btw - AND presuming they can read that small text), they now have to bob their head down each time they want to check. Probably not a very good experience.

On machine-readable errors, section 4.1.1. “Parsing” within WCAG 2.1. is the lowest hanging fruit you can attack first in regards to accessibility, but WK does come out with around 30 or so errors depending on the page and its state: [copy your source code and paste it here to see errors visible after login].

It’s sad that there are errors relating to ARIA attributes, as these are meant to aid screen-readers when non-semantic code is used that is not accessible (usually Javascript widgets).

If any WaniKani staff need a recommendation for an agency I’d be happy to help, I have worked with several from both America and the UK.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.