When will keyboards work on the web?

The story of how to use a keyboard to run a web browser has been one of pretty steady decay. I recently read an early draft article that referred to some older work partially based on even older work, which pointed out that the accesskey attribute, introduced in HTML4 and slightly improved in HTML5 (although not without introducing new bugs), didn’t always help people.

I pointed out that while this is true, the response of developers all over the world has been to replicate the functionality with Javascript. Which is satisfying, because if you’re in the majority of people, who can use accesskeys successfully, the experience with javascript can be even better. Unfortunately, this approach actually has almost all the same problems, but it makes it impossible to fix most of them.

The first response I saw was a well-reasoned explanation of what was wrong with replacing accesskey with javascript, and a suggestion that maybe just giving up on keyboard support is the smart move.

In many cases that is the right answer, but not always.

Don’t try to outsmart a browser

In standardista circles (a term that seems to have lost its positive connotations) people still talk about “the user agent” – which mostly means “browser”. The difference is small, and you can call it what you like, but the idea that people are trying to bikeshed name is important in a few ways. One important point is that the user may have a collection of things working for them, including a browser, some extensions they think are critical, some kind of system extensions like a screen reader, a custom configuration to suit them better, etc.

People are not using “the browser” that a developer knows, but an unidentifiable toolset based on a browser, that meets their personal needs or goals. (Or someone else’s, if they work in a secured environment and are not allowed to change browser, or something like that).

The user’s relationship with their agent is that it helps them through the entire web. And they generally trust it, or at least know its foibles – the more so if they are relying on a customised set of things than a bare browser.

So it should be the browser’s role to tell the user how to move around a web app, how to “click” a button or follow a link or select a colour scheme or zoom level. Developers who try to override these choices for the user are often not doing people favours, and can be making their sites unusable.

Do try to help users

Developers cannot know everything that is happening on the user side. Some developers make a good-faith attempt to explain how things work, but e.g. the WikiPedia article on Access key isn’t perfect. It doesn’t cover even the browser I am using now (Yandex.browser – with real market share in Russia), let alone Vivaldi’s own browser. So explaining what is happening can be helpful – unless you say something wrong.

There are lots of things that a “user agent” could do for a user – enable them to skip between headings of a long-winded article like this, or remember a shortcut for the button that they use all the time while editing a blog post as I am now. I wrote a demonstration extension for Opera 12 to show how to do this for accesskey. (By “demonstration” I mean “it shows the idea, through badly-written buggy code without enough documentation”. When my.Opera closed, even the documentation went away 🙁 ).

The trick to helping users is to make sure that your solution isn’t so aggressive they cannot apply a better one if they have it.

Adding accesskey should help users. It should not force them into a situation where their user agent is overtaken without them knowing, it should offer them something that can be useful, and that they can easily adapt to make more useful. Mostly, it actually does this – but is only helpful for people who use custom setups, since standard browser implementations range from “not very good” to “far worse than that”.

The problem with Javascript

It turns out that interpreting how javascript works is hard. Theoretically, impossible, but in the real world it is only so difficult that people work really hard to avoid bringing different javascripts in contact with each other in case they clash.

Likewise, user agents are unlikely to be able to do much with your javascript beyond disabling bits. So if you are interfering with the way that a user agent works, it is very hard to do it “collaboratively” using javascript. Other helpful things like extensions or browser configurations are unlikely to know what you have done.

This is the big reason people (well, those unfashionable “standardistas”) promote “declarative markup” – like HTML attributes and elements. It’s available to all the tools in the toolkit. (Hmm. Except, apparently, in MS Edge – a big backward step I hope and trust they are working hard to fix). It is often much easier to work with than “imperative code” like javascript (although XSLT proves that isn’t a mathematically provable statement).

Is accesskey really broken? Can we fix it?

So what is the deal with poor old accesskey? Is it hopelessly broken, or can it be retrieved? I don’t know. We should do some work and find out, because it seems that it might be what we really want if only we treat it right.

Indeed, I’d be happy to find that browser makers had seen their mistakes and already fixed the problems, but I fear that will take a bit more work.

Discovery

The most obvious complaint people make is that it is hard to find out what the accesskey for anything is. That’s not hard to fix. But it shouldn’t be the task of every site developer, even if the HTML accessKeyLabel DOM property worked well. The Opera 12 implementation did a pretty decent job, although you had to check each page you were on manually – something a simple indication could fix.

The serious complaint that leads people to say “don’t use accesskey“, is the potential for conflicts with common user agent functionality. This is probably not as serious as often claimed. It is also easy to fix.

Clashing with the user agent

The common line is “it interferes with screen readers”. I haven’t done a lot of testing. In fact, tonight I checked a few browsers on my macbook against WikiPedia, which uses accesskey extensively (maybe they did some more testing?) while running VoiceOver (the Mac screenreader). All the browsers I tested (Yandex, Vivaldi, Opera, Firefox, Safari) use ctrl-alt and the defined key. This means there is a clash between important functions in WikiPedia, and in VoiceOver. And VoiceOver wins every time. So the user agent doesn’t let the user down, by suddenly surprising them when a key command (ha ha ha!) suddenly does something unexpected.

Historically, the situation has been worse on Windows – but how bad is it now? I don’t know. I’d love to have some recent test results that answer the critical question: Does web content unexpectedly “hijack” user agents with accesskey – the way Twitter does to me through javascript?

Making it more useful

Even if there is no real clash, denying people the functionality of one accessibility feature because they use another seems pretty stupid sub-optimal. But also unnecessary. Again, Opera 12’s implementation got that right. It let a user configure a single key to activate the accesskey menu. But that isn’t the only possible approach. 

Allowing people to use gestures, voice commands, or whatever keys happened to be handy (for example, when my keyboard is set to cyrillic, I’d like to have the option of shortcuts I can actually use easily) could all be done, with minimal changes to the specification, a few changes to browsers, and no change to any content that actually uses accesskey today.

Is there a reason to hope, or is this just a friday-night pipe dream?

This issue has been exercising my brain, and my keyboard, and various colleagues’ inboxes, for quite a while.

It continues to be seen as an accessibility issue. Apparently it is not generally considered a performance issue that millions of pages use masses of rubbish javascript to do a poor job of what browsers can do relatively efficiently. Nor is it often considered an architectural issue that developers are being asked to perform an impossible (and slightly creepy) task of knowing the user in order to fill in for basic functionality of a user agent.

But from time to time there are glimmers of hope. Today I am feeling positive that I will see things get better.

Please bring on those test results, even though I suspect they’ll make me feel a bit less positive in the short term…