Shifting Left
Imagine baking a cake, pulling it out of the oven, and realising you forgot the sugar.
What’s in it
What is it for?
Imagine baking a cake, pulling it out of the oven, and realising you forgot the sugar. Trying to shove sugar into a fully baked cake is messy, stressful, and ruins the cake! It's much easier to just add the sugar at the beginning.
In technology, the timeline goes from left to right (Plan ➔ Design ➔ Build ➔ Production). Shifting left means moving accessibility checks to the very beginning of the project (the left side), instead of waiting until the end to test it. Finding an accessibility bug during the design phase is incredibly cheap and fast to fix. Finding it right before the website goes live is expensive and frustrating!
Shifting left is a team habit, built by teams talking to each other and asking questions early. No special software is needed.
How to support it
Everyone on the team plays a part right from the start! Here are some examples of how different roles can shift left:
- Designers can check colour contrast and plan out where keyboard focus will go before sending pictures to the developers.
- Developers can plan out which Semantic HTML tags to use before writing any complex code.
- Product Managers can make sure accessibility is listed as a requirement for the feature to be considered Done.
Shifting left can sometimes feel like it slows a project down at the very beginning because you are doing more planning and having more meetings. However, this early planning saves a massive amount of time and money at the end, because you never have to tear down and rebuild a 'baked cake'!