It is imperative that accessibility considerations are integrated at each stage of a project’s lifecycle, and are not treated as an arbitrary exercise.
But why is that, and what happens if they aren’t?
The definition of ‘web accessibility’ and the scope of what it refers to should encompass the complete combination of interfaces that sit between the application interface (which conveys semantics), and the user’s cognitive evaluation of those semantics.
They can be thought of as three distinct entities:
the application composition (colour contrast, design responsivity).
the device used to access the application (network connection, rendering capability).
the capabilities of the user (visual, cognitive, and physical).
It is important to recognise that each entity has the potential to affect the user experience to a similar degree.
For example, an unsupported browser used against a well-designed application may be as detrimental to the user journey as an assistive technology used against an application that is not using semantic HTML.
User capabilities are a project requirement
In the same way the application composition and supported browsers/devices are project requirements, so are user capabilities.
From the perspective of the project lifecycle, the capabilities of the user can be classed as external variables that cannot be analysed nor controlled.
For example, it is impossible to detect that a user may have a cognitive disability which could affect their user journey.
Don’t rely on the defaults
Throughout the project workflow, more often than not, a set of user capabilities with which our product must work against have already been subconsciously defined.
These are the personal capabilities of each team member (UX, design, development, testing) that has had input into the product.
Unless these team members take into consideration the varying capabilities of other users (who don’t have the same capabilities as themselves), it can lead to an inferior usability experience for those user groups.
a designer that doesn’t suffer from any visual disabilities may inadvertently choose a background/foreground colour combination or typography style that inhibits the readability of text.
a developer that relies solely on visual cues to deduce meaning may not pay enough attention to semantic HTML to describe the application to users who use screen readers.
Be aware of your surroundings
You need to acknowledge that a proportion of your users will have a disability (as demonstrated through consensus statistics) that leaves them exposed to potential usability issues with your site.
These disabilities can vary in severity, and the strategy you will need employ to ensure the quality of experience of these users will be proportionate.
For example, a visually impaired user may be using a screen reader to interact with your site, which relies on well-constructed, semantic HTML to deduce application composition.
Delivery of such an interface, will require early communication between UX designers, visual designers and developers to identify component patterns, so that their meaning can be described through the appropriate HTML structure.
In contrast, a user who has motor issues may require an intuitive keyboard routing to navigate through your application.
This will involve the same team members as the aforementioned, although the developer will have two roles – implementing the routing itself and advising designers by highlighting any additional routing requirements (sufficient focus highlighting, etc.) that weren’t originally perceived in the design phase.
Taking an holistic approach
Traditionally, conformance in this area has been a reactive task rather than a proactive one; indeed, the term ‘web accessibility’ is defined by Wikipedia as:
…the inclusive practice of removing barriers that prevent interaction with, or access to websites…
Rather, fundamentally there shouldn’t be any barriers in the first place that need removing.
A common example of such a retrospective task is an ‘accessibility audit’, where issues with the current product have been identified by team members or the business.
This approach is nearly impossible to get right because:
an audit is a static document; assuming the project is in active development, more often than not the audit becomes out-of-date as soon as it is written.
mitigating the risk of code conflicts during component ‘patching’ and ever-changing business requirements is tricky.
it can be a contentious subject getting buy-in from a business to remedy the issues identified; you are implying that you have delivered a product that not everyone can use.
The involvement of multi-disciplined teams throughout the entire project lifecycle demonstrates that accessibility is inherently a cross-cutting concern, which must be treated as such.
In order to correct previous bad habits, you’ll need to be prepared to change many aspects of your project lifecycle and overall workflow to ensure you stay on top of your responsibility towards accessibility – and become proactive rather than reactive.
In my next blog post, I’ll demonstrate how you can achieve this on your own project.