User ‘wants’ versus accessibility

In organisations that are getting to grips with accessibility, there’s often a tension between what their users ask for and doing things in an accessible way.

The organisations in question often have that problem where:

• historically, they have not designed and built with accessibility in mind
• their existing user base, therefore, does not include many/any people with disabilities since they have been unable to use the product

When we introduce a change that improves accessibility, there’s often a barrage of negative user feedback that product stakeholders find difficult to ignore. That feedback usually gets to them through unfiltered Customer Satisfaction channels like online surveys, help centre enquiries, and social media, rather than via user testing sessions where a user researcher can separate user wants from user needs.

Problems to overcome

The way I see it, there are two problems to overcome:

1. Users’ natural discomfort with change
2. A homogenous user-base

Users dislike change

Any change you make, regardless of the reason, is going to be met with hostility from users. Much as I hate to link to something by Jakob Nielsen after his irresponsible and damaging comments on AI and accessibility, his video on Users Hate Change hits the nail on the head:

Any time you release a new user interface design, you’ll get complaints. This doesn’t mean that the new design is worse than the old design; it simply means that it’s new, and users don’t like to learn different ways of doing things

A new, accessible design isn’t just likely to be objectively better, it’s often necessary, but the feedback in user testing and via customer service is unlikely to be positive. Users don’t want change, even if they and many others would benefit from it.

All your users look the same

Your user-base is representative of who you’ve been designing for, and if, historically, your digital product team hasn’t considered accessibility you’ve defined ‘done’ as ‘it works for me’. This is because:

• the majority of the working population is non-disabled, so the majority of people who design and build digital products are non-disabled
• Disabled people are less likely to be employed, so product teams employ fewer disabled people than they should
• Disabled people in employment often hide their disabilities, so product teams may unknowingly include disabled people who feel they don’t have a voice

Potential disabled users have been overlooked.

So as you begin to introduce changes that unlock your interface for people that were previously excluded, the feedback from existing users is not only going to be negative, it’s also likely to be unanimous.

Not only is there the natural discomfort with change, they’re also unlikely to see why the changes have been made, as it doesn’t benefit them.

The good news here is that this will change with time as a your user-base becomes more diverse, so the big issue is managing all of this unhappy users in the meantime.

Change management

The aim is to introduce changes with the minimal upset to users, and this can usually be achieved with steady, planned, incremental updates to the user interface (UI). Where this isn’t possible it may be necessary to manage the change with careful, succinct, and dismissible explanation in the UI itself, or an email or social media campaign to inform users of your drive towards accessibility and inclusion.

As our user-base starts to reflect the proportion of disabled people in the general population we can start to really understand what will make our product better; making it easy to distinguish what our users think they want versus what they actually need.