Shift left in inoculating Accessibility

It’s an interesting thought to start with — Accessibility is a vaccine for pervasive web. The sooner your web get a jab of it, the better :-)

Elaborating here my mind on the above lines a little more here — this debate is running through my inner-self as to what’s the right time for it. It’s almost always that everyone’s focus is tending towards taking up features first and keeping accessibility for the later. however, just like a vaccine, the sooner the thought process initiated and injected into the project, the better the results are and the safer the product would be. That’s where a shift left helps!

A few examples when accessibility is an afterthought

For a person with cerebral palsy.

• Problem:I can’t rotate my tablet — it’s attached to my wheelchair.
• Works well:The application works whether I attach my tablet horizontally or vertically.

A user with dyslexia:

• Problem:My address is so complicated. There’s lots of numbers and long words. It’s hard to type it all without making mistakes.
• Works well:I love websites that can automatically fill it all in for me. Then I don’t have to work so hard to get the numbers and spelling right.

Traditional vs Shift left approach

A traditional approach to validate accessibility is at the very end of software development. Often after the product is released where accessibility deficiencies have been found by user feedback. So the cost is huge in this approach and there are risks related to brand reputation.

A shift left approach helps it by making incremental investments at every stage. How does this helps ?? — It can make accessibility baked in as a DNA into the product. This helps in better usability and also developing a culture to give equal importance to accessibility as a feature.

Misconceptions associated with accessibility

Accessibility is optional: Until required by law, many clients and product developers think that it as an optional requirement. That’s one of the reasons, it did not get the due importance that’s needed. As a result, the need of it is keep shifting to the end and sometimes ignored as well.

Accessibility is expensive: Somehow there is this strange thinking prevailed that implementing accessibility is complicated, time consuming and expensive to built. The truth is that the technologies to build web has accessibility baked in. It’s the same HTML, CSS and JS that has the capability to build accessible websites and no additional complex tech etc. is needed.

Accessibility is useful for a few: This is yet another prime reason for not making accessibility as a first class citizen. However it’s not a correct assumption. An accessible app is always prove to have much better usability and better reach universally. Accessibility is not about making special features for impaired people but to make the user journey inclusive for all alike.

How shift left helps in each of the software development lifecycle ??

As I mentioned in the diagram above, putting small incremental efforts in each phase of project development helps a lot cumulatively. Let’s look at it in more details in individual phases.

Requirement: The first step in the shift left strategy is to make a mindset to capture feature requirements keeping inclusivity in mind. Identifying and capturing persona for desired actors/users of your application will dramatically help. It helps shifting the focus to the user’s problems and pain points. If we are able to be inclusive here and capture most personas, the requirement itself will be able to trickle down accessibility as a non negotiating aspect to subsequent cycles.

UX Design: UX designs are the first step towards conceptualising how the user is going to interact with the software. Therefore, it is really important to keep the varying degree of user persona in mind while designing the UX.

Take an example of a retail website selling shirts online. If the designer choose to depict different colors of the shirt by a thumbnail image, one can imagine how tough it would be for a color blind user to select his desired option. A better choice would be to incorporate this persona as well while designing and provide options like name of the color along with the thumbnail.

There are tools and techniques like color pallet checkers to take care of appropriate contrast ratio and DSLs (Design system language) that helps standardizing the experience across the board. Once these small yet important inclusivity elements are inculcated into the design, It becomes difficult to miss it in the later parts of implementation.

Implementation: As part of the shift left strategy, the team should be sensitised towards keeping accessibility and inclusivity principles in mind. A good ecosystem of tools is evolved to make this happen. Web technologies has been developed keeping the accessibility features in mind, however it didn’t get the due importance.

It’s exciting to see that the current ecosystem of tools has made it easier to validate the accessibility aspect. Google lighthouse score and axe toolkit is quite easy to bake in into the build pipelines to keep a check on it. however it is important to understand that accessibility is quite subjective in nature and not everything can be covered by automated checks and controls. We must put ourself into the shoes of different user persona to validate the usability during the implementation cycle and must do our due diligence to avoid making it someone else’s responsibility.

Testing: With a shift left strategy, testing should play a role of safety net so that the issues related to compliance to WCAG rules should not be escaped. Testing strategy should include writing and executing test cases keeping in mind multiple persona as well as validating if the content and features are usable with assistive technologies (like screen reader, keyboard etc.).

Just to summarise:

The most important objective here is to be more proactive than reactive for the accessibility adoption. The shift left helps in activating the right mindset at all stages and keep the accountability at every level instead of dealing with it at more costlier stages.

Our processes should be tuned to make this shift by incorporating the right tools and techniques at each increment. Fret not, you will be astonished by the realized gains!