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?
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.
For example, you can’t put input fields in the middle of
text. Instead it has its own status code (
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.
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
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
to work, so that’s allowed.
Next, for content. Let’s say,
a, the two list tags (
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 (
textarea, etc.), and an optional (new)
The input should be able to define its
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
disguise. Speaking of
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
let’s just say it can contain only a table. You get the
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.
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
your typical website. Especially if that allowed me to customize
things to my liking. Complete with keyboard shortcuts and
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.