Shift left on accessibility

• Atomica11y
• Practical Accessibility
• A Designer’s Guide to Documenting Accessibility & User Interactions

Hey, everyone. I'm Geri, lead accessibility specialist at Just Eat. As a visual description

of me, if you're listening to this, I am a white woman with shoulder length brown hair

and nerdy black glasses. Today, like all days, I'm wearing what I term as corporate goth.

It's a black dress with as many skulls or dead things as I can get away with in a corporate

environment. So, as Dave said, I attended State of the Browser back in March. Can you

put your hand up if you're also there? Woo! Beautifully curated set of talks available

online if you missed out. Here is a photo of the stage in the gorgeous Barbican Theatre.

Now, picture this. It's the end of a long day and you're sitting in the back row of

the conference mentally processing all the incredible talks you've watched. Your mind

is here with an ice cold post conference beverage of your choice. Through the mists of your

thoughts, you vaguely hear Dave mention he's running an event for accessibility week. Then

he invites you to speak in front of the whole conference, which is the first time you've

heard of this. So, a big thank you today for inviting me to speak. Despite being publicly

thrown under the bus, I'm delighted to be here. Jokes aside, I'm always keen to talk

about accessibility at tech events where it's not always on the agenda. And this week is

accessibility week, so a lovely opportunity. So, let's get started. Everyone likes a story,

so sit back and make yourself comfortable. Auntie Geri is going to start this talk with

a tale of something that happens to her regularly in her life as an accessibility consultant.

The story starts late in the afternoon when I get a message from a team who are just about

to release a new feature. It's likely the first time I've seen this feature, which has

already been designed and built. The product manager asks, Geri, is it accessible? I run

through the usual accessibility checks and feedback. Oh, there's a problem. The new feature

isn't announcing as expected on a screen reader. The beleaguered senior engineer who incidentally

is working across five different agile teams says, they'll have to troubleshoot why this

is happening. It's potentially a complex rework and they estimate it will take a couple of

sprints to fix. Ah! This news completely blindsides the PM and rightly so. They have a deadline

to meet and they haven't factored into additional sprints. Where do they go from here? Do they

release something knowing it's not accessible? Oh, that seems wrong and unethical. Or do

they tell the business that their shiny new feature is delayed? That makes their team

look bad and everyone's worked hard on this. How does the story end? It ends with everyone

hating the accessibility person for ruining their day. The same thing happens with accessibility

audits. I call this the accessibility cycle of sadness. We plan, design, build and QA

a new feature. It is released with some fanfare, a Slack announcement and maybe even a celebratory

pizza. The feature gets accessibility tested often by an external agency. Hundreds, sometimes

thousands of accessibility issues get reported. Someone like me with some accessibility knowledge

has to pick through all the fails, ticket them and rank them in priority. Tickets get

assigned back to the original feature team, but the team that worked on this feature may

no longer exist. And if the team does still exist, they haven't accounted in their planning

for all this extra work they have to do. How does this story end? You guessed it. Everyone

hates the accessibility person for ruining their life and we all metaphorically die of

dysentery. If we're talking numbers, Deque estimates it costs $350 to mitigate an accessibility

issue in design and development, $450 in QA, but more than $800 per bug that gets through

post release. Ultimately, if someone can't interact successfully online, they're likely

to call customer services, which becomes even more expensive long term. The way to avoid

falling into this never ending cycle of sadness is to embrace everyone's favorite LinkedIn

keywords. Shift left. If we shift left and sprinkle some accessibility good practices

into each stage of our Agile workflow, we're less likely to get slapped around the chops

with some time sink at the end that we haven't accounted for. So tonight I'm going to cover

some simple ideas on how to integrate accessibility into your Agile product design process as

you plan, design and build stuff. My loose definition of Agile in this talk is you're

working on a website app or software that is being continuously released and your team

is committed to continuous improvement, be that in increased efficiency or customer experience.

I appreciate I've just shat all over 25 years of product management methodology with this

two bullet point generalization. Fight me in the pub later. Starting with planning.

When you're scoping a project, ask questions like what do we know up front and what are

the unknowns that we need to go away and research? If you're fortunate to have some accessibility

support like me, pull them into this planning stage to troubleshoot any potential problems.

And in time for accessibility spikes and investigations when pointing a ticket, these accessibility

investigations take time. Have a think through how this might affect people with access needs

who use different accessibility settings, assistive tools and devices. And consider

what product and design can front load in the sprints before so engineering can hit

the ground running. The teams I've worked in that have done accessibility successfully

is where it's been baked into the team culture and this is reflected in planning. If the

PM sets the expectation that this team produces accessible design and code, we build time

for accessibility in our pointing and we have accessibility acceptance criteria, then after

a while it becomes the default and no one questions it. If it's perceived as extra work

or something that's done at the end of the sprint, if there's time, then it never happens.

If you need help writing accessibility acceptance criteria, there's a brilliant website from

Charlie Triplett called atomica11y. The site's got sections for design, HTML, iOS and Android.

If you select what you're working on, it might be like a component or part of a web page,

it spits out accessibility acceptance criteria either as a user story or as a condensed checklist

that you can cut and paste and adapt to your requirements. This all sounds peachy, Geri,

but won't it slow us down? Yes, it might temporarily slow you down while your team adjusts to some

new ways of working, but discovering a critical blocker the day before release or retrospectively

fielding 750 accessibility bug tickets post release will probably slow you down a lot

more in the long term. I always say it's not accessibility that slows you down, it's surprise

me. So, let's move from planning to design. Deque suggests 67% of accessibility issues

start in design. I hate made up statistics like this, but I kind of reluctantly agree

with this one. I'm going to talk through three aspects of design to consider in a shift left.

Design foundations, design tooling and annotating designs for engineering discussion and handover.

Starting with foundations. If your foundations nudge you towards accessible choices, then

you're more likely to end in accessible outcomes. Most companies or most tech companies now

have design systems where as a designer these foundational choices are already made for

you, but if you're making these decisions yourself, put a system into the choices. As

an example of creating a system to ensure colour contrast, use a tool like Leonardo

colour here to generate your colour ramps where you can specify a minimum contrast ratio

for each step in your ramp. By specifying ramps with contrast stops, you can create

rules around colour. In this example, I made for a company called BPP. I know I can use

white text on background colours 060 and above and I'll always hit a 4.5 to 1 contrast

ratio in any of my colour ramps. The same goes for type and spacing. Get a system into

it that will scale. If you need some inspiration, have a look at how some of the big design

systems and component libraries do this and adapt it for your organisation. From Craig's

talk description, it looks like he's going to go into detail about putting some systems

into your thinking. Maybe. Maybe not on a design level. Maybe on a code level. So, yeah,

it's good to build on solid foundations. So, moving beyond the foundations to starting

to design to tooling. Design tools shape our outcomes. 80% of the market uses Figma, so

my focus is here. Figma's annual conference was last week and there's some great news.

Figma now makes websites! As a designer, you no longer need a pesky engineer or boring

stuff like semantic HTML. We're partying like Macromedia in 1999. All you need is divs.

If you inspect the code on Figma's new magical website making tool, there's no headings,

no roles. I'm being cheeky. I appreciate this is primarily pitched as a tool for quick prototyping,

but this lack of care under the hood just makes me despair. We need to be exposing designers

to good practices so they can learn and improve rather than marinating them in this sort of

div inception of slop. As far as I can see, there are still no fields in the Figma interface

to specify semantic structure, roles, alt text and labels, focus management and states.

This is such a missed opportunity for designers to learn. So, don't assume designers know

about accessibility. They need training and training designers is a key part of your shift

left. I guarantee educating your designers will head off at least 67% of your accessibility

problems. All your money back. Along with training, little nudges in the right moments

are useful. At Just Eat, we have a UX and accessibility review checklist component which

kind of nudges you to consider the basics. Things like check color contrast, add screen

reader announcements, check zoom and increase type size. If you add this to your design

systems library as a component or into your design templates, this is a little nudge that

will make designers remember they need to include this detail. This leads to design

annotations. Design teams usually have an existing way to annotate designs for engineering.

You can use this for accessibility annotations. What can designers annotate? The stuff that's

missing from Figma. Heading levels, if it's not obvious from the design. I've got a grab

of our Just Eat homepage here with H1 down to H4 annotated with stickers. Reading order,

what comes next if I'm swiping through on a screen reader, what order is the content

announced? Focus order, when I tab, what's the next interactive thing that takes focus?

And finally, any non visual stuff like alt text and labels. As a designer, running sessions

where I collaboratively marked up files like this with an engineer was how I learned about

accessibility. I would highly recommend doing this. If you're looking for some training

for designers in a shift left, I highly recommend checking out Stephanie Walter's website. It's

at StephanieWalter.design. She has loads of useful resources. Ultimately, I have mixed

feelings about design tooling and, you know, the effort that goes into this engineering

handover by reducing web pages to flat pictures made at fixed resolutions with no interactivity.

We're abstracting away all of the good stuff that the web ultimately represents. You know,

it's easy to get caught up in these beautiful design artifacts, the complexity of design

libraries and these perfectly crafted prototypes. But it's really all just a means to an end

and the end is code. And with that, onwards to shifting left in development. Scott O'Hara

recently shared this on Blue Sky and it made me chuckle. He says, I don't feel joy in having

someone realize they need to add alt text. That's like congratulating someone for knowing

it's inappropriate to not wear pants in public. Wear pants without a pat on the back, please.

While I agree that alt tags, much like pants, are nonnegotiable in public, it's easy to

assume that everyone knows about accessibility and that includes engineers. In my experience,

the coverage of engineers' accessibility pants varies wildly. I have worked with some senior

React engineers which are firmly in the hot pants zone when it comes to HTML. And conversely,

I've had junior engineers sat in wearing a pair of palazzo pants and throw accessibility

shade over their older cargo panted peers. Accessibility training for engineers is essential

for a shift left to make sure everyone knows the basics. Don't just assume accessibility

knowledge because an engineer is senior. If you've got budget, I highly recommend Sara

Soueidan's practical accessibility course. I revisit this constantly. It's a really comprehensive

resource and it gives you a lovely toolkit and some freebies. As an engineer, if you're

looking for an objective towards your annual review, completing training like this can

be an excellent measurable. I think the key for a shift left to building

accessible products in an agile team is to make sure product and design are frontloading

everything you need to set you up for success. The ticket and the designs you're working

from need to meet a definition of ready for engineering. To shift left, here are five

things you need to be supplied as an engineer up front to start work on a ticket. You need

to know what happens when you zoom in or increase font size. Does the container grow in height

or does the text truncate? You need to know how this will work with no mouse. Keyboard

accessibility is fundamental to so many users. And if you constantly test with keyboard as

you build stuff, you will cover off most accessibility requirements. You need design to either supply

or work with you to step through how a keyboard user will navigate. You need to know what

happens when you interact. What takes focus and in what order? You need to be supplied

the treatment for all interactive states. What if the user prefers reduced motion? If

there's motion in the design you're building from, you need to be supplied a reduced motion

version. Finally, how would a screen reader announce this? If you don't know what should

announce, you'll either have to guess or you'll have to loop back around to design who are

likely to have to go back to the content team which blocks your ticket. If you're not being

supplied the accessibility information you need to build stuff, speak to your PM and

work with them to spec out a definition of ready for engineering. PMs hate a blocked

ticket because it makes those scary looking charts they turn up to retros with look bad.

It's ultimately in their charting interest for the sprint to run smoothly. In terms of

engineering process, I'm a designer, so I'm not here to tell you how to write your code.

We've learned a lot of stuff from Matt. Common sense says you should automate as much as

you can to catch the check box fails. Integrate accessibility into your development environment,

run automated testing tools to scan for WCAG violations. Once you're through all the check

box stuff, the most important bit is to manually test. Here is my quick and dirty checklist

when someone asks me, "Geri, is it accessible?" I make sure all the content makes sense, that

I can zoom to 200%, that I can navigate and perform all actions using keyboard alone and

there's a clear visual focus indicator. I check text has good contrast against the background.

And finally I open it on a screen reader. You all have one on your phone and computer.

If you don't know how to use it, just Google it. You only need to learn four or five commands

to cover basic testing. So that was a few simple ideas to help your team shift left

and incorporate accessibility best practices earlier in the process. You'll notice all

the things I've talked about are straightforward checks that anyone can do. You don't need

to be an accessibility specialist who eats the web content accessibility guidelines for

breakfast. To truly shift left, we need to make accessibility accessible so it becomes

less of a specialist skill and more of a shared responsibility across a whole agile team.

As Matt said, terms and tools that you already know. Before I go, I have two challenges for

you to take away. First is don't hate your friendly neighborhood accessibility person.

They might come at you citing WCAG criteria or loom large in your Figma file judging your

choices but at the end of the day, we're in it to make the web a more equitable place

for everyone. Involve us early. We will be so delighted to hear from you that we might

have biscuits. Second challenge is to take one of the ideas I've talked about today and

apply it to your own process. This could be a teeny tiny thing like speaking to your PM

about including accessibility acceptance criteria on tickets or building time into planning

for an accessibility investigation. It might be including some screen reader annotations

on your designs or upgrading your accessibility pants with some training. Let me know how

you get on. You can find me enthusiastically on Blue Sky or reluctantly on LinkedIn. If

you want to update me on your progress or just fancy a nerdy chat, I am @gerireid.

Thank you.