Accessibility

We are doing accessibility on the web wrong. Whenever I look into it, I get the feeling that everything is backwards. It’s an afterthought, and it is complicated when it really could be simple.

Have a brief glance at the Web Content Accessibility Guidelines 2.1. From the Operable section in the navigation:

• 2.1 Keyboard Accessible
  • 2.1.1 Keyboard
  • 2.1.2 No Keyboard Trap
  • 2.1.3 Keyboard (No Exception)
  • 2.1.4 Character Key Shortcuts
• 2.2 Enough Time
  • 2.2.1 Timing Adjustable
  • 2.2.2 Pause, Stop, Hide
  • 2.2.3 No Timing
  • 2.2.4 Interruptions
  • 2.2.5 Re-authenticating
  • 2.2.6 Timeouts
• 2.3 Seizures and Physical Reactions
  • 2.3.1 Three Flashes or Below Threshold
  • 2.3.2 Three Flashes
  • 2.3.3 Animation from Interactions
• 2.4 Navigable
  • 2.4.1 Bypass Blocks
  • 2.4.2 Page Titled
  • 2.4.3 Focus Order
  • 2.4.4 Link Purpose (In Context)
  • 2.4.5 Multiple Ways
  • 2.4.6 Headings and Labels
  • 2.4.7 Focus Visible
  • 2.4.8 Location
  • 2.4.9 Link Purpose (Link Only)
  • 2.4.10 Section Headings
• 2.5 Input Modalities
  • 2.5.1 Pointer Gestures
  • 2.5.2 Pointer Cancellation
  • 2.5.3 Label in Name
  • 2.5.4 Motion Actuation
  • 2.5.5 Target Size
  • 2.5.6 Concurrent Input Mechanisms

Managers and designers treat it as another item on the checklist. As a yes/no question: “Is it accessibile? No? How many story points to fix it?” I don’t blame them, but usually by the time they are asking these questions, it is an impossible task with no end.

How can we do better?

We can do better. We could make all this go away and have near perfect accessibility for everyone. How? It’s simple really. Don’t serve html. And especially don’t serve css and JavaScript.

What if the WCAG 3.0 just read

“Website must implement all its functionality using the XXX protocol.”

where XXX is some very simple protocol with a very simple implementation. One that describes intent, but not visual layout. In a sense, it doesn’t really matter which one it is, as long as it is restrictive, and simple. Let’s look at one.

Gemini Protocol

The Gemini protocol is roughly speaking a simpler http protocol. It’s for serving content, though a much simpler form of content. Instead of html it serves a sort of simplified markdown. Markdown has no css, and certainly no JavaScript. Neither does Gemini. It really doesn’t dictate much about the visuals, and that is important.

For example, you can’t put input fields in the middle of text. Instead it has its own status code (10) for those. This means you can only ever have one input field per page. This is incidentally also the recommended starting point by GOVUK when creating a new form.

There are many such restrictions, aiming at creating a simpler web that is focused on content. Gemini is not perfect for this, in fact there are some crucial features missing, but it is a start, and it is a protocol in active development that can be influenced.

Restrictions shall set you free

With a webstack as complicated as it currently is, it is impossible to build anything on top of it. There are a handful of browsers and they cost a fortune to develop. With something simple, like Gemini, creating a browser is suddenly a one person task. Add another person to the project and you get color and font selection as well.

Some other project could create a screen reader on top of that protocol. That is a larger task, but still much simpler than trying to do it for what we currently have.

What about from the website maintainers’ perspective? I can’t speak for everyone, but as a frontend developer who worked on building a netbank from scratch, I would have loved this protocol. I would have loved to ditch all of the css and all of the js, and just focused on implementing a “dumb” backend for accessing your accounts and transfering money. In fact, the last thing I did before leaving the company was to start work on a static html version of everything. I did it because we had started slowly rolling out the new version, and some blind person complained that he could no longer access the website using the Lynx browser. I wish more people would complain about this stuff. We need to hear them so we start taking it more seriously.

Restricting html

Could we instead restrict html? I think we could. Let’s make a version of html that we call valby (after the city I live in). We would tell the browser that this is a Valby page by annotating the html. We could then differentiate between different types of pages by giving the valby attribute a value. Let’s say we have three different types of pages: content, input, and data.

<html valby=content>
    ...
</html>

Then, because this is not a serious excercise, let’s make up some rules about what we want. First off, we don’t need a head tag, because Valby will always be utf-8, and we don’t really need a title. Without a head tag, we can also ditch a body tag. Great.

Next, let’s say we can have a nav, but it can only contain links. We generally don’t allow attributes on elements, but the a tag does need an href to work, so that’s allowed.

Next, for content. Let’s say, h1, h2, and h3. The p, the a, the two list tags (ul and ol), and maybe the pre tag. That’s it. So a full document may look like this.

<html valby=content>
    <nav>
        <a href=/>Home</a>
        <a href=/about>About</a>
        <a href=/contact>Contact</a>
    </nav>

    <h1>My simple website</h1>
    <p>Blah blah blah...</p>
</html>

Notice that the nav can be above or below. It does not really matter. It would be up to the browser to decide where and how to display it. It knows what it is (navigation that can contain only links), and so it should have its own rules (posibly defined by the user) about what to do with it.

The next one is valby=input. Let’s say it can only contain a mandatory <label>, any of the basic input elements (input, select, textarea, etc.), and an optional (new) <error> tag.

The input should be able to define its type attribute so the browser can help show the correct keyboard or in other ways assist the user. The type should not be radio though, as that is just a select in disguise. Speaking of select, the multiple attribute should be allowed as well.

<html valby=input method=POST action=/profile/update>
    <label>Your phone number</label>
    <input type=tel value=123>
    <error>Your phone number must be more than three characters</error>
</html>

There can only ever be one input element per document, so the for (and many other) attribute is not needed. Also, again, notice that the order does not matter.

I will not bore you with the valby=data, but let’s just say it can contain only a table. You get the idea.

This is far from optimal (optimal would be a dedicated protocol), but it could get the ball rolling. You could do this right now and not lose any readers. They might leave because your website is ugly, but at least they can access the content. Then it’s just a matter of, say, installing an add-on in the browser that knows how to apply some basic styling whenever it encounters the Valby attribute.

Conclusion

This is my dream internet. This would solve so many problems around accessibility and designing for different types of users. Not just users with disabilities, but even power users like myself. Given the choice I’d probably prefer valby over your typical website. Especially if that allowed me to customize things to my liking. Complete with keyboard shortcuts and everything.

But most importantly, it would be a simple, checklist kind of thing for managers to understand, and law makers to make laws around. Is it implemented or not? If it’s there, it is accessible—because the user, and not some designer, is making the decisions around their needs.