Keyboard Accessible Reviews

It’s been bothering me for a while that I couldn’t use the keyboard to get everywhere doing a review, so I went ahead and made a Firefox / Chrome Add on to allow it.

Check it out and let me know if it’s helpful. I added a little focus circle to make it more obvious what is currently focused. You should be able to treat anything with focus like a button now (use space bar or enter key to activate them).

https://addons.mozilla.org/en-US/firefox/addon/kenban

I haven’t added this into lessons yet (I don’t have any to test with at the moment, but I will once I do).

Any reason you made a Chrome/Firefox extension instead of a userscript that anyone can easily run with a script manager?

Correct me if I’m wrong, but isn’t the only vanilla button that’s not reachable via keyboard the “wrap up” one?

Also, I second this:

1 Like

I wanted it to be signed and verified by Firefox so people know it isn’t malicious. Also to make it easier to install / update.

I’m kind of surprised at how many extensions are scripts, is there a historical reason for it?

For me at least I couldn’t access most of the “buttons” by tabbing during reviews.

mfw when I think I’m being helpful by not doing a script but realize that might be what people prefer
krabs

2 Likes

They’re easier to write. You don’t need to pay Google to publish them to their app store. They’re easier to tweak for when people want to customize other people’s scripts. And so on.

3 Likes

It’s easier to develop a community around a userscript. Since the code is open source by nature, curious people tend to look inside if they want to modify things… and pretty soon you have people venturing into writing their own scripts based on what they see and learn. An extension, on the other hand, is closed source and essentially immutable from the user’s perspective.

As a security-minded developer, I actually put more trust in an open-source userscript than a “verified” extension. I personally review the code of every userscript I use before I install it… though of course there are very few people who do that. Most people just trust that “someone else” will let them know if a script is unsafe. And to an extent, that’s true. I know a lot of people browse through scripts for self-learning purposes, so any bad things are likely to be revealed. It’s sort of a community trust thing, and Wanikani has a surprisingly good community.

As for updates, the popular script managers (TamperMonkey, etc) handle installs and updates well. It’s easy to control script load order, which is sometimes helpful. And it’s easier to enable/disable scripts dynamically if needed, such as for troubleshooting.

You can set automatic update, or manual. And TamperMonkey even shows you a diff of the old and new code before updating, which is great for people like me who want to do security checks incrementally.

5 Likes

The code is open source for this one, at least that’s what Firefox told me (not sure how they expose it). But I also publish it on Github so people are free to contribute / fork it etc.

I agree about the community here, it blows my mind the number of crazy scripts people have.

I haven’t checked it out but I wonder how easy it would be to publish to all three (Chrome, Firefox, scripts). Chrome has been the largest pain so far, while Firefox is a joy.

1 Like

I haven’t written extensions for Chrome. What makes it a pain?

For userscripts, Chrome seems the easiest since it’s the most standards-compliant. Lately, Firefox is the new IE in that regard… :-/

1 Like

They’re super picky about everything being exactly X size for icons and screenshots, where Firefox will take care of everything automagically for you. And to be honest, the UI for Firefox extension publishing is 2018 looking while Chromes is 2000 looking.

When I get home tonight I’ll look into how to publish a Tampermonkey script.

2 Likes

Just as a quick-starter:

You’re basically just writing JS as if it was loaded with the page.
Other than that, there’s a short [metadata header] that instructs the script manager which URLs to run the script on, when (timing) to run it, and a few other things.

Here’s a short example, which is literally everything you’d need:

// @name        Sample Script
// @namespace   rfindley
// @description Change some CSS
// @version     1.0.0
// @include     https://www.wanikani.com/*
// @run-at      document-end
// @grant       none

var style = document.createElement('style');
style.innerHTML = 'body {background-color: #dddddd}';
document.getElementsByTagName('head')[0].append(style);

That’s it!

It’s good practice, though, to wrap everything in an anonymous enclosure so you won’t overlap any functions/variables on the page it’s running on.

Example
// @name        Sample Script
// @namespace   rfindley
// @description Change some CSS
// @version     1.0.0
// @include     https://www.wanikani.com/*
// @run-at      document-end
// @grant       none

(function() {
    var style = document.createElement('style');
    style.innerHTML = 'body {background-color: #dddddd}';
    document.getElementsByTagName('head')[0].append(style);
})();

You can publish by posting the code above as-is on GreasyFork or OpenUserJS… [Example], and post the link wherever (e.g. here in the forum). When users go to that link, they’ll have an Install button (assuming they have a script manager like TamperMonkey installed already).

And while you’re developing, you can edit directly in Tampermonkey. Or just @require a source file from your local filesystem and edit in your favorite editor.

1 Like

So I do this for all my scripts of course… But Tampermonkey has to do this on their side too, right? Otherwise there’d be too much risk of bad development causing cross-contamination.

I don’t think so. I’ve used named functions in in-line onclick attributes.

You can check it out in the Element Inspector. TamperMonkey injects scripts directly into the DOM.
In the screen-shot below, the only wrappers are the ones in the scripts.

[EDIT: This is true when @grant none. I think if you have some granted permissions, there is a wrapper.

image

2 Likes

That’s kind of sad. Oh well. :man_shrugging:

@seanblue,
Possible correction. I realized that the stuff I was looking at above is what *I* injected via Open Framework. I’ll check again later to confirm TamperMonkey’s behavior.

True, but there are shortcuts for them (like F for item info, , for previous items), which is even easier than tabbing.

image

1 Like

:joy: I’m honestly terrible at remembering shortcuts, but I could probably get around that by just showing the shortcuts on the screen all the time.

1 Like

Okay, I finally had some time (yay Friday!). I’ve republished this to the extension stores, but I also went and made userscripts. Thanks for the tutorials @jfindley . I’m lazy so I ended up writing a script to run postbuild that puts together the script version based on the webextension version. The only downside is since I’m using webpack the code ends up not being developer friendly to read, I made sure to include a link to the source that people can check out in case they’re extra security conscious.

Thanks for the idea @Chikuhitsu, I actually decided to simply add shortcut hints to the buttons instead of adding tabbing functionality. It’s a lot safer and ensures I’m not mucking with how Wanikani wants people to use it (they try to keep focus in the input, which is why they use the keyboard shortcuts).

1

Take a look if you’re like me and utterly forgetful. (;・∀・) I’ve included a bunch of flavors for installing, do what you prefer.

https://greasyfork.org/en/scripts/371536-kenban

https://addons.mozilla.org/en-US/firefox/addon/kenban/

As always, the source is available here: GitHub - andrewkfiedler/kenban: wanikani keyboard accesibility
I have build steps there. Contributions and feedback always welcome!

2 Likes