Improving road lane detections with data augmentations
25 May 2022
How to explain AI to non-technical users – a GOV.UK example
16 June 2022Putting accessibility first early in the alpha stage
While design practitioners follow a ‘mobile first’ paradigm, we as a community should change our mindset to ‘accessible-first’ because it’s the right thing to do.
No UX/UI prototyping tools fully create accessible prototypes that support and assist individuals with disabilities, restricted mobility or other impairments. However, accessibility shouldn't be overlooked at the early prototyping stages. On the contrary, Assistive Technologies like screen readers, magnifiers, keyboard navigation should be considered early on.
We worked with the The Accessibility Capability Team at the Central Digital & Data Office (CDDO) in the prototyping of a digital service to access government digital records. In this post, we share our experience in creating accessible digital service.
Developing а digital service for GOV.UK requires that everyone can use the service. Government’s agile delivery Alpha phase is all about trying out solutions to the problems found in the initial Discovery research. Trying out solutions means ‘build, test, learn, repeat’ which is often faster through no-code prototypes. These prototypes come with limitations: Although you can manually set up accessible commands for objects in your prototype to ‘fake it’ (e.g. voice, keyboard), the mock is not really accessible and you cannot test the full range of Web Content Accessibility Guidelines (WCAG).
Here is how we test the usability of a prototype by covering perceivability and understandability elements, and anticipating potential behaviour/technical constraints for operability and robustness.
Designing for screen readers
Usability and accessibility have some overlaps, yet, an usable website is not necessarily accessible. See for instance the screens below. It’s safe to assume most users would figure out how to navigate Screen 1; but for a user with accessibility needs, Screen 2 would improve the screen-reading experience.
Design Choices: We aligned everything to the left, shortened the search bar and replaced the icon for a call-to-action (CTA) button instead.
Why: Screen readers make sense of information top to bottom, left to right. Aligning content to the leftmost part makes for an improved focus when consuming content from assistive technology. Text CTAs are clearer than icons and the search bar should not be wider than necessary to help with magnifiers.
Keep in mind: Try to incorporate ‘staged’ tools on your prototype. Adobe XD has voice narration and speech playback functionalities. Test users with visual impairment, learning disabilities, ADHD and always follow a linear logical sequence of the elements.
Here is a good example of the importance of placing elements logically:
Imagine a screen reader going through Snapshot 1 (below). For a visually impaired user it would be difficult to make sense of the applied filters in the second row, even worse when two different date filters could be applied.
Design Choices: The criteria applied to a filter is displayed in the same filter selection box.
Why: Assistive technology would read the filter type followed by the applied criteria (if any), providing a clearer content description
Keep in mind: The number of filters and the possible character length of the applied criteria to work with the screen size and responsive resizing.
Colour contrast
I know, as designers we may feel tempted to use minimalistic, low opacity and subtle monochrome palettes, often overlooking whether contrast is accessible by users with low vision or colour blindness. Legibility is non-negotiable; when visual elements require different shades to denote hierarchy, actions or information, they must maintain an accessible contrast.
An example of an early design WCAG checked for contrast which did not even meet AA level.
After applying changes to the colour contrast and testing we obtained:
Obviously increasing contrast in grayscale is easy, but when colour comes to the equation you must pay attention to your design choices. We used GOV.UK’s Design System tags to highlight “Closed” records within search results as shown below:
Running some tests we obtained that the selection’s contrast is AAA.
And users with colour vision deficiency would be able to consume the content based on the colour blind simulator test:
Writing for web accessibility
Writing clearly and concisely is fundamental to make a site more accessible. When we first tested some product features we found confusion with some features lacking descriptions and clearer content. For example, when testing the AI Assistant, a novel feature hardly comparable to another application, we learned that landing directly into the page’s workspace would make it difficult for users to consume the content, thus, we incorporated a description page with link text, to help users complete the desired transaction. We wrote a full entry about the AI Assistant, go check it.
From mobile-first to accessible-first
Many design practitioners have ‘mobile first’ as top-of-mind when starting new projects. We, as a community should change the mindset to ‘accessible-first’, simply because it’s the right thing to do. The previous examples show simple, yet, essential aspects to consider when designing an accessible website or application. After validating your prototype, there are still a myriad of standards to implement and test to comply with at least WCAG AA level. At Viapontica AI we build accessible solutions and are constantly aiming to improve on this practice. Get in touch if you have any challenge for use or would like to know more.