Throughout each week, I save articles I want to read in a list in my Raindrop account. And every Friday, I work through most of them. This Friday, this article caught my attention, even more so because it's directly related to this mini-series about shifting left.
In her article Shifting and shuffling, Beth DeConinck uses the metaphor of a deck of cards to explain how accessibility work fits into the software development lifecycle (SDLC).
She uses a deck‑of‑cards metaphor, where each card is a task in the product backlog and its position in the deck decides when accessibility is handled. If accessibility is just one more card, it becomes optional and easily pushed to the end of the deck, making it low priority.
DeConinck argues that accessibility cards should be modifiers, like cards in board games that change another card's properties. Accessibility should not be a separate add‑on, but a modifier applied to every feature card. It should shape how every item is designed, built and tested from the start.
This clicked for me immediately, because DeConinck put into words something I'd been circling around for a while without quite landing on it.
The last three emails focused on what you can do right now to shift accessibility left.
I wrote about how to add accessibility annotations to your design files to prevent miscommunication and rework. Then I wanted to show you how to easily write acceptance criteria for your user stories. The last focused on adding automated checks at various stages of the SDLC.
Looking back, I can see the thread clearly now.
Every single one of those things only makes sense as a modifier to something else. Annotations need design files to annotate. Acceptance criteria need user stories to attach to. Automated checks need an existing SDLC to live inside.
Accessibility doesn't stand on its own. It never did. It's a modifier. And DeConinck's framing is what finally made that obvious to me.
I highly recommend Beth's article.