12 Principles Of Web Accessibility

[APPLAUSE]

[LARISSA] Well, then we go to our next speaker, and before I ask him on the podium or they, I said it wrong. Our next speaker published the 12 principles of web accessibility in the beginning of the year and calls it more like a survival guide itself, which sounds very thrilling. I really want to introduce you to Heydon Pickering. Please come on stage.

[APPLAUSE]

[HEYDON] Hello. I need to get my laptop actually started.

[LARISSA] Good morning, Heydon. Well, I just have an introduction to do, but I need my iPad to peak a bit because you do quite a lot. You are a technical writer and author, a designer, programmer, illustrator, video producer, and sound artist. How the heck do you fit that in one day or even a week?

[HEYDON] I don't have children.

[LARISSA] Okay, makes sense. Yeah, makes sense. All right, I'll let it to you. Please take over the mic.

[HEYDON] Thank you, Larissa. Hello, everybody, and thanks ever so much for that opening keynote, Erik. That's brilliant.

I should probably first describe me. I'm a short person with an unbranded baseball cap. I have a T-shirt which looks like it's for a black metal band, but it actually says Crab Museum. It's a souvenir from a crab museum in Margate. That's me.

I have written early in the year, at the beginning of the year, I wrote out some principles of web accessibility. Some like high-level ways of approaching web accessibility specifically. I don't know anything about native accessibility.

Because it's in this official-looking font that you might see on a road sign, that's a bit misleading. These are just my principles of accessibility. There's nothing official. I don't do standards work. That's why I've scrawled Heydon's at the top above them like that.

These are up on GitHub, and they've been sat there for a little while. They've got somewhere in the region of 800 stars. That's a meaningless metric, but there you go.

I just put them up there because I thought I might as well share them, make them public, even though they really were just for me. But it had a really surprising and really humbling response where a lot of folks were really interested in them. They resonated.

Since then, they've actually been translated into multiple languages. I translated them from English back into English and then they were translated into French by some of my French friends and then later into Spanish, and the NCDT team themselves actually translated them into Dutch ahead of the conference. Thank you ever so much for Jaap and everyone who was involved in doing that.

Also, very recently, and I'm very excited to say they've been translated into Japanese by my friend Makoto, in fact. What you can see on screen now is the tweet that Makoto put out. I didn't see this because I'm no longer on Twitter, but there was a whole team that Makoto pulled together to do the best translation they could in Japanese, which is just fantastic. Domo arigato, Mr Makoto.

What do they say? Well, I'll dig into that, and I'm going to step through them and just add some additional context, basically.

The first one is perfection is the enemy. I'm going to read this out verbatim for those who can't read this on the screen.

Nothing is nor can be 100% accessible. Anyone who claims their offering is completely accessible is a liar. Or they don't understand accessibility. Or both. Usually both.

It's okay to deliver inaccessible work so long as it's more accessible. Do what you can within the constraints given, and if the constraints are unreasonable, challenge those first.

You may not feel confident you are always the best person available to work on accessibility, but you are available. This speaks back to some of the stuff that Erik was saying. Don't leave the work to absent and non-existent accessibility superheroes.

You get this all the time. Among all of the other hype that product owners say. They say this product will take moments to set up, it will make you rich, it will make you sexually irresistible, and it will be 100% accessible. Never trust that, of course.

But there's two sides to this coin, and the other side is this.

That actually, in my experience, as someone who has consulted organisations about their accessibility and usually about the accessibility of their design systems, I very rarely meet people who are actively against working on accessibility, don't think it matters, or just shun the idea of doing that work.

Most people are really interested in doing it, but this idea that accessibility is an on or off, like you either do it right or you do it wrong, puts people off because they think if they do get it wrong, they're going to let down a lot of people, and a lot of vulnerable people.

The principle's in there just to say just have a go, basically.

Second principle, this is the fuck accessibility overlays principle, basically. By default or death.

Accessibility fundamentally does not work as a plugin, add-on, or opt-in state. If an interface offers the option to enable accessibility, it is inaccessible. A low contrast switch that turns on high contrast? Game over.

Categorically, accessibility overlay software does not and cannot work. Adding accessibility stuff on top of inaccessible stuff does not address what needs to be addressed. The specific features offered by such third-party interlopers, not sure why I used the word interlopers there, are immaterial.

Resist the ideology of post hoc accessibility at all costs. A minimum viable product, MVP without accessibility is not even minimally viable. We…

[APPLAUSE]

Thank you. I feel like I'm preaching to the converted in a way here, so hopefully I'll give this talk at a non-specifically accessibility conference as well.

Just recently, Figma had this disastrous product launch, where they created a tool which magically converted your flat graphical designs, which is what Figma is for, into coded websites and the source code looked a little bit like this.

If you can't see this, it's like a psychedelic, phantasmagoric world of just divs. There's some incredible stuff in there as well. There were divs with hrefs.

Like they weren't aware that hrefs had to be on links to work, so they put hrefs on divs, and then used JavaScript to make the hrefs work, which is unbelievable. Also loads and loads of superfluous ARIA labels.

You probably see this all the time, where someone has a text node, and then they have an ARIA label which is identical. Just bizarre behaviour really. I did a video which parodies this.

I introduced my own product called Webbed Sites, and the conceit is that I invented an artificial intelligence which was trained on Hitler's Mein Kampf and uncensored Hentai and Microsoft FrontPage 98. That's the code that came out the other end.

Have a look at that if you haven't seen it. Next principle, moving swiftly on from the Hitler references. Parity is paramount. The point is not to create a better experience or even a good experience. It's to ensure a comparable experience between different people.

Interfaces should not be challenging to some and not to others. But some interfaces are necessarily complex and some content is inherently esoteric. You do not get to choose who is interested in or can cope with what.

If an image serves as a joke, the alternative text should not give the joke away or explain why it's funny. It should tell the same joke by alternative means. The joke may be offensive to some or inexplicable to others. These are shortcomings of inclusivity, not accessibility.

I think it's really important to have a distinction there. They're both really important things. But accessibility is literally being able to gain access to actually be able to get at something, whereas inclusion is really about, "Are you going to regret being anywhere near this thing?"

I try and divide them in that way and I use this example sometimes of the accessible Rickroll. Generally speaking, the link text for a link shouldn't be misleading. It shouldn't be guiding you somewhere that it's not saying it's going to take you.

But if it's doing that to everyone, if the prank is on everyone, then it's accessible actually, because there's parity. Weirdly, you could make that an inaccessible Rickroll by adding a descriptive ARIA label there.

If you to screen reader users or people operating screen readers, it says it's actually Rick Astley singing. Weirdly, you've helped them in a way, but you've not. Because actually, the point is that it was a prank. In any case, that's an example that I use sometimes.

The next one is design for implementation. Bear Figma in mind here because that's partly where they went wrong there. They say form should follow function, but most organisations design first and develop second. The design phase consists of purely graphical ideation and leaves too many implementation questions unanswered.

Consequently, developers are encouraged to prioritise visual approximation over usability. Drag-and-drop interfaces need to be operable by keyboard. This means buttons need to be provided. Those buttons will need to appear in the so-called design.

As an accessibility practitioner, you must contribute early and at a conceptual level, because form must follow function and the function must be accessible.

This is really addressing this problem we've had in our industry since time immemorial, when we borrowed all of our design ideas from print design, which is an entirely different medium. We still have this thing where we… It's a waterfall thing.

It doesn't matter how many Kanban boards we have, we're still going to design first and then that's set in stone, and then you pass it off to the developer and the developer looks at it and goes, "Fuck me.

How does that supposed to be made in any way that anyone can use it?" It all comes from this idea that we have left and right brains. You're either a technical person who codes or you're a non-technical person who makes pretty pictures. I do both.

This whole right-left brain thing dichotomy is a complete myth. It's pseudoscience, and it's worth remembering. I did another video about this actually, and I compare the idea of binary gender to like a CIS education, the idea that we divide education in this way, stem or non-stem, et cetera.

All nonsense. I've just put this in the biggest text possible because I think this is an important point. Code needs to be designed. How we write code. We need to employ design thinking, especially for our interfaces. That's the underlying point here.

You get 10 points if you include people versed with code and reviewing or annotating the visual design. I've worked in organisations where it is Figma-driven, but at least they actually annotate and say, "Well, this should be an H1 and this should be an H2 and that thing."

That's great. But actually starting out with code, starting out as you mean to go on, actually I think is much more worth it because that's the material you're actually dealing with and there are designers out there who can do that. Structure first is the next principle.

A poorly structured interface can technically pass WCAG or W-C-A-G, if you prefer. A well-structured and intuitive interface can have multiple discrete WCAG errors. Chances are the latter is the more accessible interface to most. Automated accessibility tools are only really good at locating discrete errors.

While these may be helpful diagnostically, you will need to take a holistic view. What will confuse or overwhelm people? Where will people get tripped up? Don't waste time ticking off individual success criteria when the underlying structure needs rethinking.

I'm not saying that compliance doesn't matter, but as Erik addressed it, it's not just about compliance. You need to really think about the user experience or sometimes what's called the accessible UX. The thing is, you won't fail WCAG for not using headings. That's not a thing.

Likewise, actually, and I only really learned this recently because I hate it when this is done. You don't even fail WCAG for skipping heading levels. But this is where two of these principles interact.

Under parity is paramount it's saying, "If you can't see headings, you shouldn't be able to hear them either." If it really is a stream of consciousness, you shouldn't be putting headings in there invisibly, say for screen reader users, to help them, because that's what it is.

Ontologically, it is a stream of consciousness and it should be to everyone. But at the same time, under structure first I'm saying, "But actually, you probably do want to have headings in there and lists and everything which helps you pass 1.3.1. Use your words is the next principle.

A considerable proportion of web accessibility is about providing text labels. Buttons, links, and inputs must all have labels. Page titles and headings are also important types of label. Status messages are critical for labelling state.

Including a label may placate an automated accessibility testing rig, but the label's wording makes the real difference. Good writing cannot be automated. Artificial intelligence cannot anticipate your intent, develop your writing and editing skills, or include writers and editors in your process.

It's just the web is for words and this is the key phrase here. Artificial intelligence cannot anticipate your intent. While sometimes artificial intelligence or things which automate your alt text can just be plain wrong, they can just get it wrong. They can see things which aren't there.

Actually, a bigger problem is that they don't really know themselves why you put that photo there. What was your editorial decision that was going on there? The idea is that if you can choose a photo, if you can actually go and say, "I want this photo on my website."

Or "Management wants this photo on my website." Then you should be able to describe it as well. If you're doing that, and you're actually placing it there, you should be describing why it's there. I mean, that's ultimately what the alt text is for.

Next one is tools are not identities. Disability is no more uniform than ability. Different screen reader users use different screen reader software in different ways, for different reasons, in different circumstances, to meet different needs and preferences. That is if they are using screen reader software at all.

Too many people think about accessibility as just screen reader compliant. There is no persona that can adequately exemplify a screen reader user or their behaviour. There is no screen reader user who speaks for all screen reader users. Don't design for screen reader users or any other fictionalised homogenous group.

Designed to support the capabilities of screen reader software. People cannot and should not be quantified, but inputs and outputs can and are. I think about interface design really purely in terms of inputs and outputs. That's been very like a useful approach to me.

I did a talk all about this called the Folly of Chasing Demographics a while ago, and that's me, talking about it at the Converge Design System Conference in Brighton.

Just word for word, this is what I said in that talk, which is, you tested with a disabled user. Great. You met a new person, but you only met that person. Your job is not just to give them whatever they ask for. They don't speak for everyone.

The more testing you do and the more users you meet, the more you'll realise how unrepresentative your early encounters were of the non-existent uniform disability demographic that existed exclusively in your head.

Ultimately, you'll learn the only things any of your users really have in common are brains, sphincters and access to an array of tools and technologies. The predicament here is that people use tools in different ways and designing for just one way fails a lot of people.

You're basing that on presuppositions, but adapting to every single person, there's a privacy issue there. You'd have to assess, analyse, and store data about their behaviours, which is problematic on a different level. You don't design inclusively, is the idea. You design non exclusively.

You are permissive with your inputs and your outputs. Next one is less is less. The mantra less is more is incorrect. Less is less. That's a good thing. Too much of interface engineering is done because others have done it or just to prove it can be done.

That's like everyday life, really, working with developers. Stop. The more we do and the more complex the output becomes, the more likely it will fail. Not just by producing discrete errors and breakdowns. More importantly, by resisting comprehension. Most components, in most cases, should just be content.

Content should rarely be hidden behind a button. Turning headings, paragraphs, and lists into an accessible tab interface is not an enhancement. It's a degradation with bragging rights. I hate tab interfaces basically. That's the I-hate-tab-interfaces principle. We should stop hiding content behind buttons and things.

We should stop thinking about our interfaces as cluttered when they have words that are there necessary for understanding. It makes me go a bit loopy that people do that all the time, putting the labels instead of above text inputs inside the text inputs so they look like placeholders because we need space.

No, you don't need space. People can scroll. Anyway. I'm going to get into a rant, so I can feel it coming. To make these things actually compliant and actually usable and accessible, is really complex.

You have to have combination of esoteric CSS for positioning pop-ups and then you have to worry about your roles and your states and what the keyboard behaviour is, and everything. Just put the text on the page.

Get paid. I added this one late, but I think it's a really Important one. It was an afterthought in a way, but I think it's a key one. Don't let your enthusiasm for accessibility work be exploited. Like any work, the more people do it for free, the less it is valued.

Accessibility work is not an optional extra, a hobby, or a kindness. It is a foundational part of sound interface design. If you're paid to work, and you work on accessibility, it should be defined as part of your role.

Accessibility work must be compensated and rewarded like any other work, where accessibility is everyone's job, it's often nobody's. Beware of that rhetoric. I've worked in organisations like that. I think everyone should be mindful of accessibility.

But at the same time, this idea of, "Oh yeah, no, we should just all magically have that as part of our role." You're just being asked to do extra work with no extra compensation. This is like the situation usually.

You get lots of overpaid, the JavaScript engineer people, they make an uninclusive, inaccessible, poorly performing application, and they get paid loads of money to do it.

Then people within that organisation who happen to give a shit about doing an interface well get exploited into fixing and actually making it into something which is useful and usable for sometimes nothing at all, or no rewards, no extra, nothing extra in their compensation package.

It's really just an analogue of this. We have all of the very rich, incompetent people at the top, stock traders, oligarchs, demagogues, and capitalists, and the people who are actually running society. Nurses, teachers, social workers, childminders, firefighters, et cetera, going to food banks.

The next one is fishing, not fish. Designing accessible products and interfaces starts with designing the organisations and communities that deliver them. Erik had a master class up just before me about this. You can deliver accessible work today, but who will do it tomorrow?

Who or what might undo it tomorrow? Accessible design might mean building a front-end team consisting of developers well-versed in the front end. Who would have thought? It might mean replacing a CMS that prohibits accessible output. It might mean briefing editorial staff in how to structure their content.

If you're fixing inaccessibility yourself, by yourself, your impact will quickly fade. I just want to pick up this phrase here. "It might mean briefing editorial staff in how to structure their content." It's often not thinking like a developer.

I contracted at a large international publisher not so long ago, and they had a really good design system already before I arrived and this design system had accessible components.

The header and the navigation and most of the technical, interactive things that were part of the page as a whole were already really good in terms of accessibility. They were responsive and everything else. But actually, most of the content came from a WYSIWYG and that was lawless.

It was completely outside of the design system, and it was editorial staff that were adding that stuff in. It wasn't a case. This was not something that we could technically fix.

It was very much about, "Well, I need to step out of this role as a developer here and think", "Well, I need to brief the editorial staff."

It was actually more just about writing guidance about how you structure your content, how you should use this WYSIWYG editor, hoping to encourage them to use their heading levels in the right places and that thing. The next one, there's only two more to go.

The next one is no points for performance. Companies tend to prioritise looking like they are addressing accessibility over actually doing it. They hire accessibility professionals and don't give them the necessary resources. We've already talked about that today. They commission research with disabled participants and refuse to interpret the feedback.

They pay for audits and don't implement the recommendations. They tell you colour contrast needs to be assessed, but won't budge on any colour relating to their sacred brand. If you want to make a real difference, demand praxis in place of performance.

This term praxis, is often associated with political activism and especially left-wing political activism. It's basically just actually fucking doing things, actually getting stuff done, even if it's small things, it doesn't matter. Like I said, it's about just making things a bit better, but actually doing things.

Inside the organisation that you're working in or you're consulting, the first sign that they're not really good at their practise is the accessibility Slack channel.

What it should be is a place for guilds or people who are like-minded and interested in getting the work at that company to a more accessible state.

But what it ends up being often is a place where people just generally talk about accessibility and accessible resources, and stuff, which is all well and good, but actually doesn't get the job at hand done. It's a focus issue.

This is the last principle, and it's a slightly controversial one, and I'm just going to read it out first, and I'll give you some context. It's let evil rot.

You will have opportunities to work on products that are inherently exploitative and addictive, trade in hatred or misinformation, or just make the world worse. These kinds of products and the psychopathic enterprises that beget them are extremely resistant to reform, no matter what they might tell you.

Don't martyr yourself trying to redeem the irredeemable. Don't make their failure your own. Protect your reputation and mental health. There's a lot of inaccessibility out there. Prioritise working with receptive people on the kinds of products that deserve to exist in the first place.

[APPLAUSE]

Thank you.

It's a tricky one because some stuff out there is you'd rather it didn't exist, but governmental institutions and things like that sometimes, or any quasi-evil part of the state, and people do have to interact with it, whether they should or not.

In those cases, I understand, you're going to want to make them as accessible as possible, but ultimately, if you can, instead, burn them to the ground is basically what I'm saying. Bad people making bad products badly is the situation I'm talking about.

To break that down, bad people, as in people who don't care about others, who are happy to throw people under the bus, especially disabled people making bad things so unethical, hateful, or addictive products and doing it badly.

I really think that accessibility is really just a question of quality in a product. Because if it's an interface, if it's not accessible, it's just broken. It's about quality, and you can measure that similarly to performance. Like if it's a laggy, janky application, then that's poor quality as well.

It's in the same area. Now a lot of what we do a lot of the time is this. We fix this bit at the end. Now, we're in a fucked up situation here. Because now, these bad people making these bad products are doing it more effectively.

We don't want that. We want, as I said, to burn this stuff to the ground. The principle here really is, and I've just got a diagram up here which is… Basically, there's a lot of… Most of the web is inaccessible.

But only some of the web is inaccessible, but also fascist. As much as possible, you should try and fix the non-fascist stuff and not the fascist stuff. That's all there is to it, aside from saying that it is about putting yourself first.

I've burnt out multiple times doing accessibility work because you are up against people who don't necessarily believe in things being inclusive and accessible. You're really fighting hard for something where you're not getting the support you need. To fight another day, you need to give yourself a break.

That might mean looking for clients and looking for organisations that really are receptive to doing this thing, or it might mean taking a break. It mostly means not working with Nazis. That is the final principle. Thank you ever so much for listening and domo arigato.

[APPLAUSE]