Would Heu-risk it? Part 6: Allies

Today our category is weapon, so we are looking at something we can use to stand out as professionals. Usually weapons are more centred around complex code, but today we are looking at an area a lot of developers don´t know enough about, thus making it a weak spot. This is one of my favourite topics but as always, we will start with the rhyme:

“Never assume everyone is like you
Make sure you welcome other people too
Consider how someone might stumble and fall
And make sure your camp is accessible to all”


So, what does it mean?

Ok, so today we are talking about accessibility. An area that has gained a lot of attention in the last years, but that is still a blind spot to a lot of us in the industry. And I can totally understand why!
For a long time we have talked about prioritization, analysing data and focusing on the big user groups. We have grown used to taking risks with smaller user groups for things like screen sizes, browser/device support, network speed and similar things, focusing a lot of our efforts on optimizing the experience for our core customer base.

And to be honest, the society in general is not different. How much of our environment is optimised for anything else than the generic, standard person (probably a white man) with a standard body and mind?
And then at some point, people started saying that we should make society accessible to everyone. This has come a long way from where we were, but is still not great. A natural progression from there is that our software needs to be inclusive as well.

So, we got things like the web content accessibility guidelines. And, as seems to be human nature: laws and regulations.

In more and more countries, it is expected of you to think of these things. In Sweden we have Web Accessibility Directive making it mandatory for the public sector to fulfil a certain level of accessibility. With increased exposure, a lot of the private sector is starting to acknowledge this as an important area.

But what IS it and how does it affect software development?
Well, some parts are easier than others to explain.

Visual

People with different levels of visual impairment is usually the first think people mention. This can include everything from considering colour blindness, allowing people to zoom in (a lot more than you think!) and making your system work with screen readers.

Hearing

Next up, we have hearing impairment.
These focus mostly around making sure you have alternatives for audio content. Pretty straight-forward, but remember that this includes the audio for video content as well.

Mobility

Then there is mobility impairment.
The range here is very large! I often hear teams talking about this being a very small subset of users, but you need to realize that we are talking everything from having trouble using a mouse to needing software like eye tracking or head pointer to interact with the software. It might be limited mobility due to old age. In the past, this group has been small. But, with the early generations of computer users aging, it is only going to increase.
To simplify, make sure your application is accessible with a keyboard. This affects way more than you might imagine, but I urge you to try it out. A lot of software out there is a nightmare to navigate with a keyboard.

Cognitive

Then we get to the part where my team mates usually look like they want to run away because it gets too much and too hard. Users with cognitive impairment.
This includes intellectual disabilities, but it also includes problems that might come with old age: problems with memory and/or slower thinking.
It also includes things like learning disabilities, mental illness, problems with memory and problems to understand content.

Think about that for a bit.

You need to produce software that is intuitive, does not require you to remember how they did something last time, does not force you to complete a task quickly, does not use complicated language and does not confuse your user.

A tall order.
An order that can cost many, many hours of rework of existing applications.

The good part: It benefits us all! We all gain something from having these amazing, inclusive applications.
Also: there is a lot of tools, instructions, guidelines and helpful things out there to help you out. From tools like pa11y, accessibility audits in chrome devtools to a bunch of initiatives around teaching people how to do this (see reading suggestions for a few of them).

To wrap this up: We should do this because caring for our users is the right thing to do.
It is not enough to be compliant; we need to be empathic and do right by people. We might have started the awareness with WCAG and regulations, but it does not stop there. Advocates for accessibility talk abut including the disabled community from start to end. From thinking about requirements and all the way through user testing and feedback. Because, of course, who better to judge if something is indeed accessible, than the actual users?
And also, experiencing your software first-hand with screen-readers or other tools tells you so much more than a checklist.

Story time

My story this time is about how I first came in contact with the WCAG. I knew about the importance of tab order, shortcut commands and building for different screen sizes but I had never considered it beyond “some people prefer to use a keyboard to a mouse” or possibly ergonomics.
Then one day we got an email. I was responsible for the overall testing at a company and we were, politely, informed that someone had decided that from a certain (totally unreasonable) date we were expected to comply with WCAG level AAA (highest available) in all of our web applications. And we needed to have 100% automated checks in place.

Oh. Ok.

Well, none of us knew much about it but we started investigating tools and requirements. That took a big chunk of our allotted time and the answer we sent after that was simply:
1. 100% automation is not possible
2. There are tools covering different parts but no tool that covers all
3. We did not believe the time frame would work.

But we chose a tool, set out to create some automation and handed it to the teams working on our web applications. We got very little attention from most of them, but we collaborated with one team and helped create a first set of tests to try the solution on. We also created a helper checklist for the tests that could not be automated and promised to help train people.

When the first automation report came back and the team had estimated the effort to fix the issues the result was that we needed twice the number of developers and the rest of that year to fix the problems found. And again: we had not even looked at the parts that the chosen tool lacked support for.

In the end, we agreed to lower the required grade to a more reasonable level and to not do this as a big fix but work it into new services and areas in need of other refactoring. But it did great work in raising the awareness and we learned a lot!


Quotes of the day (sorry, not sorry. Could not choose)

“The more you can feel what the user feels,
as far as pain points and frustrations,
the better testing you will do”

“Just because it is compliant to WCAG
does not mean it is usable”

Jenna Charlton

Reading suggestions

Web Content Accessibility Guidelines (WCAG)
WCAG Evaluation Methodology
Inclusive Design Principles
Microsoft Inclusive Design

WUHCAG – Start making accessible websites
WebAIM – Web accessibility in mind
The a11y project

Testers´ island discs ep28 – Jenna Charlton
Automating testing for accessibility – Viv Richards
Karl Groves

And there are so many other good links in this Dojo post!

Previous posts in the series

Title and linkCategory
Part 1: IntroductionNone
Part 2: Mischievous MisconceptionsTrap
Part 3: The RiftWeapon
Part 4: The FascadeTool
Part 5: The Temptress’ TrailsTrap

One Comment

Add a Comment