Bridging technology and empathy

I thought my first impactful work in accessibility was the keynote style presentations I delivered to product teams. They felt great, everyone laughed at the jokes, "hmm'd" at the insightful portions, and key decision makers told me what a great talk it was.

But then crickets. The day to day "on time and on budget" refrain blocked meaningful conversations about removing barriers from design and code. Features excluding anyone using assistive technology still shipped.

I was confused. I really thought we had something there. My lunch and learn keynotes, design critiques, dev trainings… all for naught.

What does it mean to make technology truly inclusive?

There are a lot of half-baked opinions on this. I have worked with people who literally said things like:

• All we need is for the Chief Digital Officer to tell people to "Make it accessible, or else!".
• You have to insist on rigorous training and pop-quizzes, and if they fail they get fired!
• Tell the vendors they work for us, so they have to do it.
• We'll review every design for accessibility, then it will be accessible.
• If we make sure the design system is accessible, then everything made with it will be accessible.

None of these were practical, none of them would have worked (even though I did make the design system accessible).

Little victories are inclusion's defeat

Sure, there would be little scores along the way — a team would remediate code (which they were rebuilding anyway) or one sole designer would ask about accessibility at the UX wireframe stage.

I recently gained some insight on the origin of these little victories from November Champion

Everyone wants to do the right thing… But they only want to do the right thing once.

None of those added up to a single accessible product. Nothing was working.

Building tools at the intersection of tech and empathy

Within the first year of my time as a dedicated accessibility expert, I began to see two important truths:

1. I was answering the same low level of questions repeatedly

Slack would ping throughout the day with engaged developers asking simple questions like, "How do I make the tab key go to every radio button?" or "What heading levels should get tabindex?" and "How do I get JAWS on my Mac?"

The questions weren't the same, but the level of sophistication was. People were googling accessibility, but gaining no understanding.

2. It wasn't enough to have the answers, you had to have the process

Our time doesn't scale. Answering a barrage of sub-basic questions about buttons and checkboxes was taking a huge portion of my time. I needed to scale my time in a way that freed me up to do longer lasting work. But how?

Most accessibility experts will send a link to WCAG 2.1.1 when asked keyboard focus questions… which just confuses people even more. I saw this a few times before I stopped trying.

What I thought I needed was a reference for component do's and don'ts. I was sure it existed. It didn't. There were great websites with example components, but none of them broke down the interactions of every component in a consistent manner. None of them described the roles and keyboard shortcuts by input.

So I made one… with this quote from Buckminster Fuller in my head:

You can't change the way people think, all you can do is give them a tool, the use of which will change their thinking.

The first version of this tool was not very interactive beyond an archive of links. It was just pages with tables of keyboard interactions combined with name, role and state per component.

It did allow me to scale my time. I went from walking across the corporate campus to cover what should and shouldn't get keyboard focus to typing, "You've asked a great question! Take a 3 minutes to read this [link to specific component in question] and let me know if that answered it.

I even had a keyboard macro to type this out for me.

But something was still missing.

This information was helpful to engaged testers and developers, but the majority of product teams were still pumping out barrier ridden features. What was happening, and why?

A hero comes along

I think the big breakthrough was something Erik Boisen said to me:

Jira stories are the currency on which the company operates.

Educating people about accessibility was always going to be a never-ending game of catch-up as turnover occurred or whole new teams of contractors were spun up overnight. We had to have a way to incorporate success criteria per component as it was being developed.

Thus, the first version of AtomicA11y.com was born. It only included the condensed version of criteria (which developers appreciated) but eventually I discovered less technical QA testers appreciated gherkin style criteria.

Beyond compliance: The bigger picture

When you give people tools they can reference on their own, you'll change the way engaged people work. When you give people tools for building the instructions for how everyone works, you change everything.

Product owners

When product owners use AtomicA11y.com to build acceptance criteria for Web, Android, and iOS features they are suddenly more interested in how their product works as they add acceptance criteria per component.

They learn the difference between a button and a link, a heading and a header. They learn there's no such thing as a checkbox in iOS, and asking for one means custom work. They can suddenly communicate more closely with developers.

Designers

Deciding how to annotate a Figma file shouldn't take days. AtomicA11y.com/design/ gives annotation notes per component and gives clear (and very opinionated) guidance on how to use components.

Developers

Developers spend no time wondering how much work meeting accessibility requirements is going to take because they build inclusion in from the beginning with acceptance criteria.

QA

QA testers produce fewer bogus defects because they understand the intention of the feature through the acceptance criteria.

The takeaway: Everyone can be a bridge

To be a bridge means you understand how to get people from point A to point B across an impassible gulf.

Think about what that means for a second: It means you don't just know where YOU are, you know where THEY are and what they need to cross.

Bridges don't provide benefit by existing and growing their maintenance budget, they are only useful if they allow people to cross the impassable gulf.

If your product teams are struggling to reduce barriers for people with disabilities, take the time to understand the actual reasons. It's almost never the case organizations don't want to care, it's simply that their current systems, workflows and patterns don't support the change you're asking them to make.

There's an impassible gulf.

It's our job as accessibility experts to build tools and processes for the teams we support.

What's keeping you from being a bridge?

I've observed accessibility professionals who were unable to really understand where product teams were. Some of this came from disinterest, but some just came from discomfort of learning a new system.

If you're unfamiliar or even uncomfortable with modern software production methodologies like Scrum, KanBan or SAFe — it's time to get comfortable. Have the sprint/release cycle taped to your wall so you know when new feature work is beginning. Be talking to people before quarterly planning sessions. Understand who actually manages releases from beginning to end.

If you're an inclusive design expert but code intimidates you, that's okay — but learn the semantics of different platforms. Did you know that Andoid and Web has native concepts of checkboxes and radio buttons, but iOS doesn't? Just knowing this will help you be part of conversations about interactions, acceptance criteria for testing and steering design teams toward platform specific solutions, rather than trying to cram iOS UI conventions into Web or Android, and not cramming Web or Android semantics into iOS.

If you're an accessibility program manager who didn't know what accessibility was til you were the manager of it, spend time with TheBookOnAccessibility.com which will give you the language you need to describe the commitments each individual contributor across your organization must make and how to track it.

Conclusion

I still do those fun/flashy keynotes for teams, and answer questions on Slack. But because of AtomicA11y.com the questions from the teams I support are a lot more interesting, and focus on the finer points of the user experience.

If you're using AtomicA11y.com, let me know in the comments what's working for you.