Accessibility – the earlier the better

Imagine the scenario…

you enter a multi-storey building and find there’s no elevator to take you between floors. Sound familiar? This may be a minor inconvenience for you but for a number of people this can be a major problem.

In this example, attempting to fix this by adding an elevator post-development will likely be far more costly compared to including one in the original designs.

This type of scenario is, unfortunately, all-too-common in software development, with many systems st

Things you will learn

Why is accessibility important?

Accessibility is defined as “the practice of making a system usable by as many people as possible.”

Often, accessibility in this context is restricted to only cover users who have some form of disability. This is not a small figure – over 14 million people in the UK alone, or around 1 in 5 according to Scope. However, accessibility should be extended to include all users, such as those non-technical (which could include elderly users, for example). As a result of this, accessibility and user experience (UX) have extensive cross-over.

Once we consider accessibility and user experience together then it becomes clear that a large number of potential users may have issues when using your system. This could range from annoyances through to entire blockages of functionality. In today’s world for online systems, a user frustrated is often a user lost.

In addition, accessibility within software systems is also becoming more and more present within legislation.  In the UK, both the Equality Act (2010) and the Public Sector Bodies (Websites and Mobile Applications) (No.2) Accessibility Regulations (2018) refer to accessibility compliance. In the United States, lawsuits around accessibility violations are becoming increasingly common with over 2300 lawsuits filed in 2021 alone, according to a report from accessibility.com.

Beyond legal obligations, user behaviours and the way we interact with computer systems continues to rapidly evolve. So, it’s vital that we design and develop systems with a focus on accessibility. Otherwise, there is a risk that a proportion of your customer base either has difficulties using your system, or is excluded entirely.

During my career as a software tester, I’ve seen many different ways of approaching accessibility. Ultimately, I’ve found that baking accessibility in from the start as a core goal, leads to a number of positive effects on the project. In addition to a more inclusive experience for all your users, the general user journeys often become more intuitive. Furthermore, development of the system is often smoother and less costly.

The problem

When starting a project, it’s quite common to consider accessibility all too briefly and as a separate entity alongside other cornerstones, such as functionality, performance and the user interface.

From a stakeholder perspective, accessibility requirements may simply reference general compliance with the Web Content Accessibility Guidelines (WCAG). In addition, there may be a commitment to have the final system audited by a 3rd party for accessibility compliance.

As a brief aside, the Web Content Accessibility Guidelines (or WCAG for short) aim to provide a single shared standard for web content accessibility. These guidelines are well adopted now, due in part to the way they categorise accessibility into tiers of compliance. The most basic level is ‘A’ level, with a mid ‘AA’ level and the most accessible ‘AAA’ level. AA level compliance is most often used for general accessibility requirements, with AAA reserved for specific accessibility-related scenarios.

‍

WCAG separate their accessibility guidelines into 4 separate areas:

• Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
• Operable – User interface components and navigation must be operable.
• Understandable – Information and the operation of the user interface must be understandable.
• Robust – Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

‍

So, whilst referencing the WCAG guidelines and having the system audited for compliance is a start, it often leads to confusion and conflict between requirements around the design of the system. A common example here is around branding guidelines, which may contain non-accessible colour palettes when used together. In addition, using web controls from a common template, may also have built-in accessibility issues.

Going beyond visual design and layout, fundamental functionality decisions and user experience journeys may not work well with the very tools that users with different abilities rely on to use the system.

One such example is infinite scroll, which is a particularly common feature seen on social media systems. For users who rely on assistive tools, these can often struggle here mainly in terms of how users are able to reliably access items on lower ‘pages’ and additional content beneath the infinite scroll area.

Ultimately, if accessibility is missed, poorly covered, or we end up with unresolved disagreements between requirements, then we introduce risk. If an accessibility audit is done late-on (often against the complete system) then the project exposes itself to, potentially, a large number of critical bugs. These may jeopardise release dates and even the success of the project itself.

For more information on WCAG, including an overview of the current guidelines, you can read on here.

So how can we approach accessibility better?

For a viable approach to bake accessibility into a project, accessibility cannot exist as its own tier of requirements. In addition, we can’t cover accessibility with a simple over-arching requirement as it can often be forgotten about or, dangerously, assumed that development will include it along the way.

Instead, consider accessibility as the bedrock upon which the corner stones of your requirements are built on. Functionality? Performance? Security? User interface and experience? All still remain vital – but let’s talk about them in the context of accessibility.

When we do this, accessibility becomes the foundations upon which the system is designed and built. An attractive user interface can be designed with an intuitive, yet accessible user experience. Powerful branding guidelines can be created to support the system and communicate your organisation’s message yet not hinder anyone trying to use the system. Effective web controls can be created for your users to interact with that allow anyone to engage with them.

Earlier, infinite scroll was mentioned as not being the friendliest for accessibility. One option here is to provide the more standard pagination navigation as an option. This helps not only users who rely on assistive technology navigating your system, but also provides an additional option for those who may find it easier using traditional pagination. This shows how standard design patterns and user controls are still acceptable, so long as we remember accessibility and build in contingency for all users. This brings us round to our original elevator example – we have 2 methods to scale the building (stairs and elevator) with all users able to benefit.

Conclusion

In order to bake accessibility into our projects, we simply need to keep asking questions around the topic as early as we can. As the conversations develop around functionality, performance and security for example, we must keep referring back to accessibility. How can we achieve our goals in an accessible manner? Whether this is alternative text on images, tab outlines on elements, or messages explaining progress to users, we can build these ideas in from the very start. These can then become part of the acceptance criteria against specific user stories and features being developed for the system. This has the added benefit of making the overall development process much smoother as the conflict between tiers of requirements is eliminated.

The upshot here is that developers and QAs are able to produce a system with accessibility baked in as they go. Bugs relating to accessibility, that could be costly to fix late-on are minimised. The result is a system that is able to satisfy the client’s needs functionally, in a secure, performant and visually attractive manner whilst also being able to be used by any user of any ability. A system designed for accessibility will likely be more intuitive to use and provide a more inclusive user experience. Ultimately, these factors can be the difference over your competition.

Whilst changing the development culture around accessibility is important, it’s even more powerful if the culture shift is at the level of your entire business. If accessibility becomes the bedrock of all of your business activities then including it in software development properly is something that happens very naturally. And by properly considering accessibility, we turn the very concept of accessibility into everyone’s responsibility – and in so doing, everyone benefits.

In a future blog post, we’ll take a look at the changes upcoming in the WCAG 2.2 guidelines, due to be released in September 2022.

‍

‍