Accessibility clinic 3 — notes

Every two weeks co-run an accessibility clinic with Craig Abbott and Nicki Berry. It is a safe space for people to come and get feedback and talk about something they are working on.

From performing regular audits and speaking to teams we need more space to talk about early work. As part of the clinic we make it clear this isn’t an audit or a governance board.

The BBC has a more in-depth Accessibility design review process (and Accessibility swarms) which I’ve used a couple of times to help structure conversations about design components, this is usually at a more developed stage.

One thing that does happen when you spent time with multiple services is you start to see patterns — which to me is a big part of providing better documentation of use. A good example of this is the multiple layers of navigation we are starting to see and where they might not work in certain contexts.

This clinic was reviewing an internal service aimed at showing citizen information.

Input or Action

The first page of the service had a text input or a button to autoload data — this could be confusing as you have additional actions within the page, the assumption was a pre-filter question would give a more navigable experience

Relational Context matter

The service used Primary navigation after a key details bar this navigation allows you to browse related elements to the citizen details which in Ministry of Justice’s context is sub navigation when we have navigation we need to make sure it is in the right location

Horizontal Navigation

We also talked about how the navigation might break — what if we have more items than space? What happens if we zoom, or have reduced screen width?

The assumption was left hand navigation as used on the GOV.UK design system may be more robust and extensible.

Accessible but not accessible in context

We often see the composition of components that can cause accessibility issues for example the secondary button was composed on a blue background which meant the bottom border didn’t have a good focus style, this may not strictly be a fail against WCAG 2.1 but based on look it seems like it may need more contrast and a stronger indicator of focus.

Same same but different

One of issues highlighted was the use of the secondary button within the keybar details looking similar to the ‘Claim status’ when viewed together both look like buttons, this could cause confusion.

Navigation within pages

With some pages, the content was quite long — so consideration needs to be made on how users would get back to the top of the page something like ‘back to top’ at the bottom of the page could help.

Also if left-hand navigation we could look at testing sticky navigation persisting as you scroll. We also talk about multiple skip navigation links.

The next action

The final point we talked about was the where is the best location to have the ‘complete action’ we talked about the context and the natural end point — potentially the bottom of the page because the user needs to engage with multiple pages of content before performing the last action there isn’t a natural place but it needs to be consistently identifiable across the pages.

One of the things that is clear whenever we look at these types of interaction — there is always space for additional accessibility guidance built into components for the context of use, and much wider accessible interaction at a page level.