A presentation at Mobile UX London in in London, UK by Joshua Marshall
These are five good things, or rules, statements that I’ve learned during my time working in accessibility.
We don’t have long so I’m going to get through these as quickly as possible.
Hello. I’m Joshua.
My name is Joshua. Thanks for having me.
I’ve been playing with technology since the early 80’s. My first job as a developer was in 1990. I was a contractor with IBM in the early 2000’s. For the past decade I’ve been mostly working as a freelance digital accessibility consultant.
There’s a good chance that most if not all of the people in this room have used the thing I’m most known for:
GOV.UK is the online home of her majesty’s government in the United Kingdom.
I helped to create the initial prototype of what became GOV.UK. Then I became a founder member of the Government Digital Service and ended up Head of Accessibility across all of the work GDS was delivering.
I’m not going to bang on about that too much. The GDS story has been told to death by now.
But before we start with the do’s and don’ts, let’s clarify.
I’m a digital accessibility specialist, so I mostly work on web applications or websites.
Sometimes I do document accessibility projects or native mobile app accessibility, but mostly it’s web-based, so that’s the context for this talk.
These are pretty generic “rules” though. If you do any kind of UX or design or development, they should still apply.
When I mention accessibility or a11y what I mean is this:
There’s no mention of disability here, no mention of accessibility laws or legislation, no specific tools or platforms or or assistive technologies.
Can a person use the thing that we’re working on.
Is there a barrier to them doing that independently?
I’m excited about a future which includes things like VR and AR and voice-based computing, but we have to make sure as many people as possible can come on that ride with us, not just a privileged few.
So, the rules…
Do these things:
It doesn’t have to be massive thing, doesn’t have to be super complex problem, it just needs to move things forwards.
Everything needs to remove barriers to people being able to use your stuff.
Great teams share what they are doing. They release design systems, they open source code, they contribute to the wider web. They fix issues. They educate others. They push things forwards.
You may not be able to do all of those things, but just talking through your approach in blog posts can be helpful to others trying to find their way.
It’s great having vision statements and telling everyone how inclusive your culture is. It’s lovely if you run a yearly awards ceremony to slap yourselves on the back. But if you don’t back that up and do the work, you haven’t finished yet.
It’s great getting an external subject matter expert to come in and help you out.
It’s even better if someone like me comes in and there’s some knowledge transference so that when I leave all that knowledge doesn’t walk out of the door with me.
But I’d rather have ten accessibility champions than one accessibility expert.
I am not the only accessibility professional who thinks that.
If you have people willing to step up and learn this stuff and share that knowledge across the team, give them all the resources and the encouragement you can.
At the very least, get out of their way and let them do it.
But celebrate them so that their passion is rewarded visibly and everyone else can see that it’s valued.
It will build momentum to keep them doing it. To get more people doing it. To make it part of your culture, not just a talking point.
A lot of accessibility work is invisible. It’s necessary for the people who need it to be there, but it’s very often hidden.
Don’t keep it hidden, get it out there for people to notice. To comment on. To try and compete with. To improve.
I hate the word gamification but I haven’t worked with a team yet who doesn’t enjoy beating their colleagues in some sort of contest. Use that to move things forward.
Put it on the walls, put it on a screen as a dashboard.
There are plenty of existing tools to show charts for a11y issues over time. Make the progress of these things know.
Automated testing only solves around 30% of actual issues, but it’s a start, and if it develops more empathy within your teams and gets them on the journey to thinking more inclusively, I’ll take it. If nothing else it’ll be 30% better than it was before.
And you’ll have a nice graph on the wall to prove it.
Accessibility is a team sport.
It isn’t just for developers to implement. It’s a design issue, a content issue, a development and delivery issue. Every single member of a team can and should contribute.
Make it everyone’s responsibility.
It’s helpful to have a single owner for accessibility in your organisation. I was that for GDS so people knew who to ask, but I just helped everyone else make it happen. I gave them all the help they needed, but then I got out of the way so the teams responsible for delivering the work got the credit for delivering the work.
This may come as a shock, but your users aren’t spending time worrying about your choice of dev tools or your chosen tech stack.
They care whether they can use the thing you’ve built.
That it’s understandable.
That the navigation is clear.
That it loads quickly.
That they can complete their tasks from end to end without having to ask someone for help.
The big picture stuff is way more important than whichever framework your dev team is excited about using this week.
Use whichever framework or methodology works for your team and makes you productive, but the output is what’s important.
Don’t forget semantics.
HTML is full of useful elements. Use the right element for the job so your browser and the users assistive tech has less work to do to interpret what you’re trying to communicate.
Do this 👍
Every feature story, every sprint, every wireframe, every design iteration, every component is an opportunity to revise something and improve it.
Even if it’s only 1% better that’s still a measurable improvement.
You don’t have to sacrifice beauty or elegance to make something accessible, but there’s a massive difference between a good looking veneer over a shitty product and one that’s designed to work well from the start.
Right.
We’ve covered some good. Now for some bad…
This could also be rule #1, really.
The only way to make a product truly accessible is to start from the beginning.
Every wireframe, every design, every user story, every template and component: everything that gets you from idea to finished release, it all has to have an element of accessibility included.
You cannot leave it until the very end to start your accessibility testing:
you’re going to waste SO MUCH money, time, energy and effort trying to retrofit accessibility into a “finished” project.
Save yourself the hassle and do it right.
Regardless of whether its permanent or situational, your audience is going to include people with various disabilities. It just is. So you need to be testing your work with a variety of differently abled users.
Find yourself an expert (or a team of experts) and make testing with differently abled people a part of your release cycles.
At GDS I mandated that a service wouldn’t go live unless it had been tested by an external agency at beta stage, and gone through at least one successful round of testing with disabled users. If it didn’t pass, it didn’t go live. End of.
Try and get your projects to a similar place, it’s the best thing to prove that your products work.
If you haven’t started building inclusively yet that’s okay, but the time to get started is now. Not when you’ve already been sued.
Don’t wait until you’re already getting hammered by the press.
Don’t wait for lawyers to be involved.
All that will happen is you’ll be under even more pressure to get it fixed and done right, ASAP. That means less time, higher stakes, and likely even angrier customers who can’t understand why you didn’t bother in the first place.
Domino’s are currently taking a case through to the Supreme Court over whether they should make their website work for their blind customers. The cost to do that, they worked out, would be $38k.
They probably spent more than that to quantify how much the change would cost. They are most definitely spending much more than that on lawyers to take it all the way through the courts.
They brought in close to $3.5 BILLION last year but thinks that it’s more important to fight it than spend $38k to accommodate customers who want to give them more money for their terrible pizza.
I don’t care about your politics, or what drives your decision making, but if you’re making this kind of call you’re a dick, and you deserve to go out of business.
Software is politics. Don’t be like Domino’s.
ARIA, or the Accessible Rich Internet Applications web standard, allows you to describe complex user interface components in a way that makes it clearer to users of assistive tech like screen readers.
It can be amazing when used well. But it can be a nightmare when it’s used badly.
It does not get you off the hook for writing terrible HTML.
Don’t think you can just throw every ARIA attribute at something and it’ll be magically accessible. I’ve tested so many things where the dev team has thought that the best way to fix an issue was to use every ARIA attribute going. All at once. Or they’ve made up a bunch of their own.
Don’t redefine HTML elements to fake them using ARIA where you possibly can avoid it. Treat it like progressive enhancement - the base product still has to be functional HTML.
Which leads us to the last rule…
Things like design systems, pattern libraries, SPA’s, web components and frameworks like React or Angular can be great but they all come with some serious potential problems if you don’t think about underlying semantics.
Don’t write shitty HTML!
You avoid so many issues that make sites inaccessible if you write semantic code.
The web standards crowd worked really, really hard to give us a world where we can do this stuff more easily.
If you’re building components, don’t forget that they need to be exposed in a way that consumers understand and recognise.
If it’s a list item, use the correct list element. If it’s supposed to be a heading, use a correctly ordered heading, not a div or span.
People will tolerate some rough edges along the way if they need what you’re saying or selling, so long as you communicate clearly and in ways that they can consume on their own terms.
For full disclosure, Billy is a former colleague of mine. I love this tweet of his.
Accessibility really isn’t much more than great design brought to life with solid code.
It’s not something to be afraid of.
It’s not impossible.
It doesn’t have to be super expensive.
It’s not something only wizards or 10x ninja rock stars can deliver.
Stop overthinking it!
Do this 👍
Don’t do this 👎
I’ve seen these do’s and don’ts many times over my career and blows my mind how much simpler our lives would be if we focused more on doing the basics just a little better.
Browsers do an amazing job of communicating when we use the standards available appropriately.
Platform level accessibility API’s do an amazing job of communicating between the operating system and assistive technologies.
I am not a computer scientist or even a proper developer, so I try and get out of the way of the folks who have done the hard work already.
And I’m not trying to give certain people preferential treatment with the work I do, I just try to give people equivalent access to the same information I have.
“Who the fuck are you to throw a log in the road of somebody who has a different set of different set of difficulties?” –Dave Letterman. Broadcaster, good human
The web was designed to be responsive and accessible. We already have the tools and the platforms and the technologies to deliver on the original promise of the web.
Universality.
Access for everyone, including for people who are disabled in some way. Or that need to access our products in a slightly different way than we do.
Our job should be to remove obstacles, not to introduce more of them. It’s up to us to design and build things in a way that lets that happen.
(Photo © Christoper Anderson for Vulture)
Every feature story, every sprint, every wireframe, every design iteration, every component and feature we build is an opportunity to remove obstacles and make things better, for everyone.
So let’s push things forwards.
A quick look a the rules I put in place or look for when working with teams to create the most accessible work possible, plus a few things I’ve gotten wrong that you will want to avoid on your own projects.
for free. You
can too.