Minor Menu Updates

Hey all!

We’ve made some tweaks to the menu, and they’re up on the preview site for everyone to see. We replaced the ‘account’ item with your avatar; we hid the search bar by default and added a search icon that triggers/focuses it to the menu; and we made some accessibility improvements to the menu while we were in there.

The avatar change is super simple: we replaced the word ‘account’ with your avatar, at least for larger screen sizes. We tried some stuff for mobile, but the avatar didn’t add much to the larger menu items, so we left that as-is.

The search change cleans up the top part of, well, all the pages that have a search bar, especially the dashboard. Once expanded, the search behaves as it did before. We’ve got plans to make search even nicer — putting it in a dropdown like the rest of the menu items, making it work as a Chrome search tool, and a few other refinements — but those are still in the works.

There have been a couple suggestions about accessibility improvements for WaniKani, and we’re listening to those concerns. We can’t address them all at once, but we’re going to include accessibility updates to any work we do. So, we made sure that there’s decent keyboard access to all the menu items and that the focused state is super clear. We think those were the missing accessibility pieces for the menu — if we’ve missed anything else, let us know.

That’s it. We’ll push this up to the main site on April 6, unless we’ve missed the boat on something large. As always, let us know what you think, and thanks for the feedback!


Minor unrelated issue, but on the dashboard when I dismissed the pink box explaining the changes it also dismissed the box saying that I’m on vacation mode.


Wish list: advanced search option to include context sentences.


Noted and added to the bug list. It’s probably a too-generous selector on the JS.



:star_struck: :star_struck: :star_struck:

Actually, while I’m here - I have always found it super confusing that you can access ‘account’ under ‘settings’, but also that going to ‘subscription’ takes you to a page nested under an ‘account’ parent. From which you can also access a ‘billing’ tab not directly accessible from the menu, and there’s a ‘settings’ tab which takes you to the top-level settings page, not a page nested under ‘account’, and doesn’t even focus the ‘account’ tab of ‘settings’… Which I think demonstrates my confusion :sweat_smile:

‘Also’ #2 - dang the forum logo got big


On the confusion for the account/subscription section and navigation: yes, yes, we know. The “account > settings > account” nomenclature is … unclear. And the subscription/billing pages are high on our “need a lot of love” sections, like, the highest. So, we know, and we feel your confusion.

For #2, hit reload a couple times. Discourse updated their CSS a few days ago, and I was fixing some minor sizing issues, but missed some of the different states (scrolled, mobile, scrolled-mobile).


That’s cool then :blush:



The icon instead of the word Account, looking back and forth between the live and the preview, it’s the little change that makes a big difference I didn’t know I was missing until I saw it! Looks pretty! =D


As it is in the preview, it ALREADY requires an extra click to search now (could you make clicking the search button automatically put a cursor in the search box in order to avoid this?); having to click into a dropdown to access such a fundamental feature as search seems like a mistake. (In addition to the extra click, it essentially hides the search feature’s existence. Search is not usually a dropdown feature on webpages, so I couldn’t imagine looking for it there, only finding it by accident.) Binding it to CTRL+F would be cool, but not all users know that shortcut, so I’d still say that a visible search icon (as is currently in the preview) is near-necessity.

Also, I still think the FAQ should be somewhere more obvious, such as in the dropdown, if at all possible. Where it is now we still have so many early users coming to the forums confused on system basics. (I’ve heard rumors an on-boarding tutorial of some sort is in the works, but at least until it exists…)

Avatar in place of the account button definitely has a nice aesthetic, though :slight_smile:


Can you get the preview site to share cookies with the main site so we don’t have to log in again?


Overriding browser shortcuts goes against a user’s expectation and can often cause confusion.


Hmmm, it should autofocus on the search field when you click the icon — I just tried it out on Safari, Chrome, and Firefox, and all three show that behavior. What browser are you on?

WRT the future plans: the search icon will stay in the menu, no matter how we roll. The idea for the dropdown wouldn’t be nesting search inside of it, but making the field and results live in a dropdown/modal — so kind of how it works now (click icon -> focus field -> search -> see results), except the field and results would live in the dropdown/modal thing, not interrupting the flow of the page. It’s a loose plan, and we’ll play with it to see how it feels.

Ah, my mistake - I thought that was what was meant by “working as a Chrome search tool”, but I see now that I should’ve double-checked. (There are webpages that grab CTRL+F and use it slightly differently, and many of these are Google pages, so my brain ran with it…) I agree with you!

I’m on Firefox. Sometimes my Firefox doesn’t quite play nice, though, (no idea why) so if it works for everyone else, I’m okay!

Ah, okay, that sounds cool! Apparently I’m failing to understand basic things this morning; carry on! ^^;;;

1 Like

Ha! I’m still working on some coffee to get my brain going, so no worries. Using words for interfaces is tricky business, too. We’ll put something up on preview for everyone to play with, whenever the project happens. :slight_smile:

1 Like

The account element is not a button, but an H2. Please may you change this? as it opens a menu.
The same goes for the new search.

Why is it popular to use role="button" instead of <button>? :thinking:

1 Like

As you noted, we’ve got role="button" on that element, and we support a few different listeners on there to support both mouse and keyboard interactions.

For us, it’s to make a clearer document outline — since the items in the menu don’t go anywhere, it seems better to show them as headers to those nested lists. My guess about the popularity of the role attribute is the flexibility and semantic meaning other markup can lend.

But! Reading through that MDN article, we need to add a couple more aria tags to the elements to show that they’re pressed and that the menu is expanded. We’ll add that to our list for next week.


Why is it popular to use role="button" instead of <button> ?

I don’t know, and it’s really bad for accessibility.

Also, to cut off any holy wars, we’re open to feedback on the button thing — but we want to make the decision on good info, so help us out with why it’s bad for accessibility.


That would mean you could type wanikani.com in the URL bar, press tab, and then type your search criteria. When you hit enter all it would do is load something like wanikani.com/dashboard?q=somesearchterm, and it’s up to WaniKani to handle that gracefully on page load. That’s why it doesn’t work “for free”.