My first task as a content designer at the University of Southampton was to design our new accessibility statement. The challenge was to design something helpful and easy to follow for anybody having difficulties using our site.
This would mean being upfront about where access issues existed and how users could access content. In short, it would be far more than something to comply with the law. It would be a practical guide and a useful insight into our work, to build trust in our site.
Being clear about what access issues users will encounter
Ideally our accessibility statement, like all our site content, would help people to do what they’re trying to do.
So, if somebody uses assistive tech or software, or changes settings but still struggles to access our content, they need to know there is an issue. Or if somebody wants to check if they can use a section of the site before they make the effort, they can find out at a glance.
Our old statement told them that ‘on some pages’ you cannot change the line height and ‘some tables’ cannot be tabbed through, for instance. If users only have vague information on what to expect on your pages, they may not wish to try their luck visiting them.
To fix this, I worked closely with content design, UX design and developer colleagues to work out where the biggest outstanding issues for those moving through the site were.
Experiencing issues to describe what users themselves face
Discovering the issues our users face led me into the thicket of impenetrable terminology that’s often used to talk about accessibility.
In the list of accessibility issues, I encountered reams of obscure language. The ‘functionality’ of a ‘hamburger menu’ button ‘is not conveyed’. ‘Radio buttons’ in the ‘filter section’ are not ‘programmatically exposed’.
I asked colleagues to show me some issues and I tried them out myself where I could. I was then able to turn the consultants’ technical language into content that was more task-orientated and relevant for users.
Take the consultants’ “no indication of current focus for keyboard-only users” on “list items inside the hamburger menu (observed when the browser is zoomed to 200%)”. This became “if you use a tab key, it may not be clear which menu item you can select”.
Helping users find what they need, without making them think
Deciding how to structure the content was not easy. We’d put issues in accessibility guideline ‘priority level’ order, which would not mean anything to most people.
An alternative I talked about with experienced content designer colleagues was to group the content for different types of users. With this design, visual impairments would be under one heading, keyboard users under another, and so on. We discussed how useful these categories would be.
There are different types of visual impairment, so do we try to break them down into ever-smaller categories? And if you need to both magnify content and use the tab key, which section on the page do you go to?
This is why I designed the statement to focus on tasks people are trying to carry out, such as ‘accessing our study pages’ or ‘using our navigation menu’. We could still put the biggest issues with access higher up.
People have in their mind what they are trying to do. Our job is to help them to do it, not get them to think about who they are.
Working in the open so we can be held to account and build trust
Making the statement useful (concrete and about what users need to know) and usable (easy to navigate and scan through) would help us to build trust.
Being clear about what users can expect next would help even more.
What are we working on next? What do we hope to fix soon? I asked colleagues these questions for the user. So that we could let them know what might have changed if they return to carry out other tasks important to them.
You can look at the accessibility statement and follow Lee Baker’s content design journey.