Accessible by default

🖖 hands up if...

Let's do a classic show of hands! Hands up if you...

have heard of web accessibility
think you have implemented an accessible feature
have tried using only a keyboard to navigate and use a feature you’ve built
have any kind of experience, making or consuming an accessibility audit report
have tried using a desktop screen reader like JAWs, NVDA, or OS X VoiceOver
have watched an assistive tech user, be it
- screen reader user
- 400% zoom user
- braille display user
- Windows high contrast mode user
- or others, use your feature

If your answer to any of the last 3 questions was ‘no’... let me ask you again,

Who thinks they have truly implemented an accessible feature?

Not even the whole product, just a feature?

It's ok... I get you

🛠️ Lets fix it

⚠️ Disclaimer

These are my personal views and I’m still learning

😑 😱 🤩

Common reactions to
accessibility project

What is
web accessibility?

Inclusion and access to
information and services

How is
web = accessible?

Hyper Text Markup Language
🤍 HTML

Who is web accessibility for?

🤍 Everyone

“Disabled”
communities

Permanent, temporary, situational

When I started learning about disability, I was so scared of referring to someone as “disabled”.

Is that an offensive way to refer to a group?

But after talking to advocates, reading user stories, and watching demos, I realised no, “disabled people” is exactly what we should be using.

It’s social model of disability, which is especially relevant when us creators create things for people to use.

A blind person can be disabled from using a site that isn’t well designed for screen readers.
A wheel chair rider post hip surgery can be disabled by narrow groceries self checkout.
A person cooking with dirty hands could be disabled from using recipe software if it doesn’t allow for voice dictation.
A person with severe ADHD was disabled from finding product information, because of heavy use of distracting looping animations in the marketing site.

In all of these usage of the term “disabled”, you’ll notice that it’s how the technologies have been designed that disabled and barred users with different access needs from helping themselves.

By not considering, or designing with these users, design stops these communities from becoming independent.

It is the creators saying: The problem is with you, not the tool.

Wow, what a way to create an inclusive world.

It’s especially scary to think about, when anyone can become ‘disabled’ at any point in their lives.

🪄 Assistive tech

Assistive tech

🤍 HTML

						import React from 'react';
import { Button } from '@a-ui-library;

function App() {
	return <Button color="primary">Shop now</Button>;
}

Did you just disable someone?
Check your HTML output

Are you accessible?

Ask users 🤑
Web Content Accessibility Guidelines (WCAG)

WCAG
POUR principles

Perceivable, Operable, Understandable, and Robust

Web Content Accessibility Guidelines (WCAG)

The guideline is true to its 4 core principles. POUR

Perceivable information and user interface, text and text alternative content, etc.
Operable user interface and navigation, can be easily navigated using multiple types of input device. Mouse, Keyboard, voice, etc.
Understandable information and user interface, clear and predictable
Robust content and reliable interpretation by assistive tech and future tools

These principles translate into almost 50 individual success criteria - checklists by W3C that measure how accessible your content is.

The guidelines also come in different versions, like WCAG 2.0, 2.1, 2.2 and the upcoming 3.0. You can also meet different levels of conformance in the guide, like A (minimal), AA (acceptable), and AAA (Optimal experience).

Alright, so now that we kinda know what web accessibility, and how to test if we’re accessible...

How to make an accessible web product?

Focus areas

Buy-in, audit, requirements gathering, screen reader training, design and content, test and development, usability testing

1. Buy-in

Accessibility 101s
User stories
Empathy workshop

If you’ve tried to get buy-in for anything, you know it’s hard to rely on one talk,

or one presentation to change hearts and minds. Especially with foriegn concepts like accessibility.

If you were in that hypothetical 12 months scenario, people might buy into the timeline; by force of course. But that’s a stick, where’s the carrot?

We all know that for persistent behavioural change, incentives work much better than a stick.

How do we make people want to make an accessible product?

I’ve found that you’ll need different types of presentations or workshops with the same underlying message, at a consistent interval over a period of time.

Expect this to take at least 2 months.

Here are a few suggestions...

Accessibility 101s

Similar to what I’ve done in the first part of this talk.

You need to explain who, what, why, how of accessibility and testing to give them a general idea of the concept.

But beware!

These won’t be the session that gets the conversation going. It’s the bare minimum why groundwork.

And no, try not to do what I’m doing, and force people to sit for 45mins to listen to an intro to accessibility.

I can do that because you’ve willingly signed up to watch this talk.

If you’re presenting it at your team’s ceremonies like a show n tell, which is usually short, split up the content.

Drip feed it… be patient my friends.

People will come out of these sessions with a similar reaction to a presentation on why inequality exists.

They may feel curious, or even sad, but still don’t feel like they can or would do anything about it.

That’s fine, you’re building awareness.

1. Buy-in

Accessibility 101s
User stories
Empathy workshop

User stories

These are a little bit more interesting.

The goal is to move from the why behind accessibility, to who are the access needs users.

Our goal for these sessions is to highlight their web content consumption strategies.

When the makers know how consumers consume their stuff, they start to design with those users in mind.

There are a lot of videos online which show different access needs for users like

a deaf person watching a video transcript,

a low vision user using high contrast mode to read an article,

or a dislexic user encountering a huge wall of text and switching to a screen reader instead.

After watching each of these videos, open the floor up to discussions.

Based on different types of users, match it with your current users profile, and discuss what they may use to access your product?

Someone in your team is bound to know someone who’s disabled by inconsiderate designs.

Hopefully, your team’s culture is safe enough for people to share these experiences. If they do, it can be quite powerful.

At these sessions, you would have created empathy for more clearly defined types of users.

So at this point, hopefully you can steer the conversation around the ‘how’ to designing, coding and testing with these needs in mind.

1. Buy-in

Accessibility 101s
User stories
Empathy workshop

Empathy workshop and/or usability testing

I personally love these.

Fork out the money.

Pay advocates and different types of access need users to come into the office with their personal devices, and talk to your team about how they use them to consume the web, or better, your product.

Nothing spur action like seeing customers struggle with your feature.

My UX friends are nodding. It’s something most of them have probably advocated for a long time.

All the theoretical ground works you’ve done up until this point will become much more meaningful. Because after this workshop, your teammates will finally ‘get it’.

You will most likely gain a few more strong advocates in your team, hopefully with different roles.

Form a pack and work with them closely over the next few stages.

It takes more than 2 people to create momentum.

2. Audit

internal vs external

Next focus, let’s look at exploratory audit.

Like when you’re creating a pattern library or clearing out your closet,

you need to take stock of the current situation.

For accessibility, you do that via an audit. There are 2 options:

Internal audit and External audit

So, which one? Ask

“Why did we embark upon the accessibility journey?”

Was it from internal drive,

such as someone passionate from the team,

or upper management mandate?

Then Internal audit.

It’s also a good way to train people to read those legal like WCAG requirements.

That’s when you’d go with an internal audit/

Or was it external pressure to meet NZ’s legal requirement for Government agencies,

and would like to be certified?

Then definitely needs an external/3rd party to provide the report.

Also, if your team or company lacks in-house capability and time, this would be a way to go.

Regardless of your reason, external audits are always useful.

They provide an impartial insight into your product.

And usually, those 3rd parties are experts or real users.

So try to get that if you have the budget.

Expect this to take anywhere between 2 weeks to 1 month.

Can be done at the same time as buy-in

2. Audit - What?

Highest traffic templates
Core user journeys
Critical components

2. Audit - Automated

Wave (free)
Google Lighthouse (free)
Accessibility Insights (free)
Axe Dev Tools (freemium)

For some of you devs, rejoice.

Yes! You can do automated tests!

The beauty of these, is that it’s an accessible entry point into errors for any role. Design, QA, BA, and etc.

But unfortunately, there’s no one tool to rule them all. They’re all good at different things. But a generally good starting tools would be:

Wave (free) - Browser extension.
See page structure at a quick glance. Switch off styles to see DOM order
Google Lighthouse (free) - Accessibility tab is available with Chrome
Accessibility Insights (free) - Browser extension
Axe Dev Tool (free) - Browser extension.

Pro gives you more detailed and guided testing

Beware:

Only 30%-40% of the accessibility issues can be picked up by those automated tests.

2. Audit - Manual

Keyboard testing
Color contrast testing
Screen reader testing
Cognitive testing
Mobile testing

2. Audit - Report

Blameless debrief session
Get stakeholders involved
What pass? What fail? How critical?
Why? Access needs impacted?

So, using the combination of tools to do your audit, you’ll generate a report.

It is easy to throw the final stats of

x number of pages failing
x number of criterias,

at the team and just leave it there for them to fix.

But what kind of reaction do you think the product team and management will have,

if you send them a huge list of failures in an email or a work messaging app?

Panic and dread is all you’re going to get.

Those are negative emotions which cause people to become less open to learning new things.

Exactly what you don’t want for the team,

who are about to embark upon a steep accessibility learning curve.

The key to managing that very human reaction,

is organising a debrief session with the team and stakeholders. Team, because they’re doing the work. Stakeholders, so they get a sense of how much work it’s going to be.

Like all good debriefs, it needs to be blameless. Stating only facts.

Summarise what are the critical fails, why they fail, and perhaps what kind of access needs those failures will disable.

Open the floor up to Q&A from team members.

There’s no better time for those not involved in the audit process to find out about WCAG criterias. Especially ones that failed, hence relevant to their work.

Alright, so we know what’s broken.

How do we manage all the fixes?

🤯
1.3.1 info and relationships

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

It is extremely tempting to look at the report,

See this 1.3.1 Info and Relationships failure,

and write that as a task or a ticket,

then assign it straight to design or dev to fix.

The problem with this approach of creating requirements, is this becomes a task to fix a specific error.

Take a look at what this criteria says...

Took me a whole week of rereading over and over to understand that "Things should be properly related in code"

There are 100s of ways to convey relationships between information, that could be mean:

Ensuring that content under heading 2 actually belongs to that section of content
Ensure label for=”” and input id are the same, so that screen readers know which label describes which input field
Ensure that decorative image doesn’t get read out by screen readers

Related list items just looks visually like a list, but is not marked up as ol or ul

Which means that the failure may have come from 10 problems on the same page,

or that one problem failed multiple other criterias.

WCAG success criteria and the fix is not a 1-1 relationship.

That’s a lot of redundant and duplicate admin work to create these types of error based tasks.

Some, only to be closed as soon as the first one went live, since it did fix 5 criterias.

Or some, taking so long to fix due to multiple problems causing that one criteria to fail.

Not Agile at all.

3. Requirements -
User story

User goal
Impacted user (their access needs)
What does best UX look like?

My personal recommendation is to write them as user stories.

When writing a story, look at the failed criteria, and visualise how these criteria help users with different types of access needs. Useful questions to ask:

What task is a user supposed to be able to accomplish in this page/component?
Which type of user are we disabling, if this failed WCAG/issue is not fixed?
What kind of strategy/tools would these users use to consume content?
What do we need to do to serve those users the best possible user experience?
- What could go wrong?
- Who could we be excluding?
- How could this be misused?

Based on those answers, write tasks up as user stories.

This will give the team more information and guidance when looking for an appropriate solution and narrow down testing methods.

This makes it much easier for the team to deal with issues, and chip away at the errors.

3. Requirements - Which tech?

WebAIM’s annual survey
Local advocates
List ‘Tested with’ devices

Now, we can’t officially support every type of assistive tech under the sun.

We can’t own all possible types of devices, and train everyone to use them all proficiently.

Remember when responsive design was this new thing,

and we had to start making our product works in all sorts of devices and viewport sizes?

How did we decide what to give 10% support?

Most sold devices on the market, and top 95% of your product’s Google Analytics viewport stats.

Though we can’t rely on Google Analytics for assistive tech usage stats yet,

we can look at WebAIM’s annual surveys in conjunction with stats from your local accessibility advocates. What is your local charity for different types of disabilities training their patrons to use?

Support those.

And if you’re feeling brave, list out device support or ‘tested with’ section for your product!

This could be a very helpful way to set expectations for people.

They definitely know if their chosen device should work with your content.

4. Screen reader training

Everyone in the team
Divide and conquer
Share and celebrate learnings

Next is screen reader training

My friends, welcome, to a whole new world.

We’re going to have to start learning how to use only the keyboard to navigate, and how to use screen readers. It’s actually quite fun. Keep an open mind.

Why do we need to learn this? Wouldn’t clear headings and well designed content be enough?

Using a screen reader is a different experience.

A content first one.

So knowing how screen readers work will help you test your product as you develop.

Rather than waiting until the end stage usability testing to reveal where you went wrong.

Helps you be Agile!

My tip here is, that have every role in the team learn it.

BA, design, devs, and QAs.

Including other stakeholders might be a stretch.

But if you have the influence, do try.

4. Screen reader training

Everyone in the team
Divide and conquer
Share and celebrate learnings

Divide and conquer.

Remember when I said that you should be gaining some accessibility champions after user stories or empathy workshop sessions?

This is when you get together, and split up the learning.

Not all screen readers work the same way.

Think iPhone vs Android. Or Mac vs PC. They’re all computers. But they’re slightly different.

Even the OS X and iOS version of VoiceOver by apple is different.

I’m on a Mac, so the natural screen reader to pick up is OS X VoiceOver (comes pre installed).

If you’re on a PC, NVDA is free, pick that up.

If your core user base is phones, iOS VoiceOver and Android Talkback will be what you should learn.

Learning these are especially interesting, because your smartphone is a flat piece of glass with almost no buttons.

So you use either gestures or voice to navigate.

4. Screen reader training

Everyone in the team
Divide and conquer
Share and celebrate learnings

5. Design & content

What can I do?
Isn’t it all technical?
Will this restrict my creativity?
Do we need to cover all access needs?

So, like all product journeys, it start with design.

For a lot of designers, their questions around accessibility could be any, or all of these:

Do I need to do anything if people are not navigating the product by sight?
Isn’t it all in technical implementation?
Will this restrict my creativity?
Do we need to design for all possible use cases? There’s so many!

These are questions borne out of lack of experience with designing accessibility first products.

It’s fear of the unknown.

They might even be going through a design existential crisis. It’s ok.

Give them a hug, a hot beverage and some food. Tell them that you’re all in this new journey together.

On a serious note, first, I’d like to ask: What is your designer’s job title?

UX or Product designer
design experiences

Experiences ≠ visuals only

Design content & mobile first

Focused & linear experience is inclusive

6. Testing & development

Isn’t the design system already accessible?
I don’t get HTML & CSS!
Who tests what?

Now, let’s have a look at concerns around testing and development

If your product is using a pattern library or a design system,

check if it’s accessible out of the box

If no, talk to the creators. It might be the kind of feedback they’re looking for.

If it is accessible, check your implementation. Have you added in all the attributes they recommended?

Design systems are just a base for you to build experiences.

It’s your team and designer who put together the experience.

Try navigating through with only keyboard, then with screen readers.

If you haven’t already from the audit phase, integrate those automated tests to help monitor implementation.

While you’re doing all this, be mindful that

Not all developers are UI focused front end developers.

HTML & CSS isn’t usually taught in comp sci degrees. And it’s hardly a focus in bootcamps.

These days, pattern libraries make it easier than ever for devs to make a designed looking page without ever touching HTML and CSS.

So by needing to really look under the hood of these UI tools, they might be learning a whole new language, and could be experiencing imposter syndrome.

Please don’t go saying that HTML and CSS is basic. Hold their hands, and connect them with a kind front end dev.

And think back to testing early days of responsive design.

Both you and QAs were probably trying to test as many devices as you can in the beginning. Cause nothing was responsive

And later on, you know and have fixed enough to get a sense of what you need to specifically test in each phase.

As you and your QA gain more experience, it’s likely that devs will test on their preferred assistive tool, and QA run regression on the rest when it’s a new feature.

So it’s ok. It’s only a lot of work in the beginning.

7. Verify the fixes

Focused usability testing!
Audit round 2+

Team needs

Empathy, curiosity, patience, consistency, perseverance, inclusion

I’ve spent 40+ minutes arming you with what a systematic cultural shift would look like, and what you’d expect to happen in each stage.

The last 2 phases will probably take at least 4-5 months fo teams to adjust.

That was a lot of content which you won’t remember.

But really, it all boils down to making the team think more deeply about different user needs,

Empathise and be curious about their experiences.

It’ll help inform what you need to do

Be patient with your team’s learning progress,

don’t beat yourself up when you hit another constraint or criteria,

but celebrate new learnings when you do.

Be consistent with your accessibility practice.

And keep at it until it become your team’s habit.

The last step though, is to include disabled people in your team, to truly be able to design inclusive experiences.

That’s how you’ll become accessible by default

Thanks

Questions? Feedback?!

Tweet me @praesongprasit