Accessibility for Web Writers – reply to a discussion

Note that this was written in reply to a post in the Chronicle of Higher Education by George Williams. Reading that and the first comment might provide more contextā€¦

 

WCAG is probably the best standard around for how to make your content “universally” accessible to more people with disabilities, but I would back up suggestions to look at tutorials – better to pick at least two. In particular there are things people do that experts would not says violates the requirements of WCAG, but that cause accessibility problems.

 

Besides, WCAG isn’t in the list of things I think of as easy to read. Even with knowledge and goodwill.  

 

Today’s example of problems that people recognise as causing accessibility issues, but can’t decide whether WCAG has been violated, are invisible buttons, which people who rely on keyboard or voice navigation can’t see or can’t understand. This example comes up a lot, but there are various others.

 

There is a common focus on accessibility for screenreader users. Which is of course important, but only a small subset of people likely to meet accessibility barriers. People with *low* vision are far more common – and WCAG 2.0 should be evolved (but W3C is currently suggesting otherwise šŸ™ ) because it doesn’t do a good job of explaining requirements for them.

 

There are a couple of good places to talk about this – WebAIM’s discussion list and the W3C WAI Interest Group are two mailing lists where a lot of people with serious expertise hang out. You’re not going to find someone there to check your work for free, but you will find people to be very generous with their knowledge if you’re trying to clear up doubts.

 

I have a lot of respect for the expertise and common sense of Dey Alexander, and the people at WebAIM, even though we occasionally disagree. I would also rate my friends at the Paciello Group and Deque as generally smart and on the right track – again although (or perhaps because) we don’t always agree on all details.

 

Following these communities a bit you’ll also learn where some of the interesting issues are – accessibility is by no means a completely solved problem, so there are things that are pretty clear, areas of very blue-sky research, and everything in between.

 

But it is a lot of fun. And done right, it’s pretty valuable to a lot of people.

Testingā€¦

For some reason the blog post I wrote last night doesn’t appear anywhere I can find except my timeline – everywhere that talks about me or my blog I read that I have only made one post.

So this is just checking if the problem is reproducible.

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ā€¦

 

Getting in the way

It’s kind of annoying when a blog platform disappears and takes a pile of the Web with it. Even if they let you extract stuff, they break links all over the place, and there is another hole in history.

Of course, history is like that. Quite a lot of paper that was written on has disappeared, parchments have been scrubbed and written over, and thermal paper is making archives a firetrap full of chemically treated records that can’t actually be read, and various magnetic tape formats may or may not have anything there when people figure out how to decode it again.

So in a triumph of hope against experience, here goes yet another blog.

On the plus side, one of the things I know about the people behind Vivaldi is that they are tenacious, and they don’t like it when things just disappear on people.