Accessibility Isn’t a “Thing”

You may have heard the phrase, “You can’t bake muffins and then stick the blueberries in afterwards.” Versions of this analogy have been floating around to explain the correct approach to digital accessibility, as documented by Lainey Feingold in an article she wrote about food analogies for digital inclusion. Perhaps the initial baking reference is owed to Billy Gregory who used chocolate chips to paint the same picture.

There was a time and place for the blueberry analogy: that you can’t add the blueberries (digital accessibility) into your muffins (digital property) after the muffins are done (property is built and live). You have to bake them in (plan for and embed accessibility) from the start (well before launch).

I think this analogy and ones like it have served the accessibility community well. They demonstrate that you have to account for accessibility as early as possible in the Product Development Life Cycle (PDLC), ideally accounting for accessibility from the very beginning. However, the problem with these analogies is that they imply accessibility is a discrete “thing”—that accessibility can be considered as one separate entity or a set of distinct elements to consider in the creation of your digital property. Run through your checklist and bam! You’ve added your blueberries.

But that’s exactly what accessibility is not.

Start your journey toward accessibility.

Contact us

Accessibility is the flour

To continue with the baking analogy, I’d say accessibility is more like flour. It gets woven into every aspect of the muffin, and it is core to the creation of that muffin. Fundamentally, you can’t create any muffin without flour. It’s embedded in every bite.

And, crucially, you don’t actually taste the flour—rather, the flour melds into all the other ingredients. It plays a supporting role in the experience of taste, allowing the blueberries and crumble topping to shine through.

This is just what accessibility should be to a digital property: the thing that underpins and augments each one of a digital property’s features, without taking center stage. Accessibility is vital to a useful experience, but it needs to be accounted for alongside all other functional and non-functional requirements, and seamlessly integrated into our natural processes.

Creating accessible “batter”

What does this approach to digital accessibility mean in practice? Here are just a few ideas:

Everyone is accountable for the accessibility of their output

Seamlessly integrating accessibility into the “batter” of a digital experience means each person involved in its creation should craft their portion with as much accessibility know-how as they can. That might mean that each team member:

• Commits to consistently learning something new about digital accessibility, prioritizing aspects given the current scope of work, and as time marches on, broadening their learning to other areas of accessibility.
• Takes the time to make that accessible work repeatable by using examples, code snippets, templates, pattern libraries, and other resources.
• Tests their own work early and often, especially work-in-progress deliverables, to catch potential bugs as early as possible.
• Ensures deliverables are measurably accessible, holding themselves accountable for demonstrating that their contributions are accessible through established reporting channels.

Collaborate early and often

Regardless of team makeup, what’s key to success is to reduce the separation between roles. This means that teams need to collaborate more and reduce silos. No one role can account for all accessibility considerations, and it is well documented that diverse perspectives yield the best results. Thus, having the perspectives of all primary roles throughout the PDLC can significantly increase overall productivity and reduce defects.

For example, developers should regularly attend design reviews. Not only will they be able to share their opinion, but it keeps them in the loop as to what they will be expected to work on in the coming weeks and months. They will be prepared to execute efficiently. Designers should also attend developer demos to ensure what’s being built adheres to all their design considerations (not all of which are always clearly communicated or documented). In the same vein, designers should conduct visual quality assurance. And whenever components have copy requirements, it’s best to ensure content designers are involved. This collaboration ensures that one team’s good work on accessibility doesn’t get lost in translation as an experience gets closer to launch.

The future is now

In the future of design and development, accessibility isn’t a “thing.” We don’t need to “put on an accessibility hat” when approaching our work or have a separate section for accessibility in our design systems. As a community, we’re not there yet. But we can get there faster if we each take responsibility for our own output. Work to embed accessibility considerations into everything that you do such that one day, it’s just what you do.

Get the recipe for success

Seamlessly integrating accessibility into your existing workflows can be simple, with the right tools and support. The Level Access solution is designed for full-team, day-to-day enablement: from Design Evaluations providing accessibility review of existing brand style guidelines to accessibility integrations with common test automation tools, like Cucumber and Mocha, helping developers incorporate accessibility checks into their existing test automation process, catching accessibility barriers as they code. With more than 20 years as a leader in the accessibility industry, we have the expertise to help you create a five-star accessibility program, ensuring sustainable compliance and a top-notch user experience.

To learn more, engage with our team today.