How We Made Inclusivity and Accessibility A Key Design Principle

To ensure equal digital access, designers must prioritize accessibility from the earliest stages of design and development, going beyond traditional demographics to consider the diverse needs of users with disabilities, including those with neurodiversity.

User experience designers have always known they need to understand the demographics and archetypal persona they are designing for. These might be the core target groups, but what about the differences within, or on the edges of those groups? Making products and services accessible means ensuring they can be used by as many people as possible, including those with life-long or temporary challenges; impaired vision, motor and coordination difficulties, cognitive impairments or learning disabilities, deafness, impaired hearing, and a whole range of hidden neurodiversity. This is true for digital products, digital services, and hardware.

Many inclusive design challenges are tangible or can be simulated. But neurodiversity is where we must think beyond visual or auditory perception. Peoples’ brains function in different ways, so to increase inclusion of neurological differences, we need more design strategies and technologies to grant fair access to all.

Future Provenance (FP) created a ‘global slider-panel’ to house different accessibility functionality for an embedded airline application (IFE-C GUI). Accessibility functionality can be turned on and off from the universal accessibility icon.

With existing and new disability regulations supporting access for all, it’s clear that designing and building digital products with accessibility and neurodiversity in mind should take place at the earliest planning stages. We have encountered many considerations and developed various tools and approaches to help in the design and build process. There is so much to consider! Right now, we’d just like to share how to overcome two key types of challenge — one more visual in nature, and the other where the user experience and build must function seamlessly with assistive technologies. But first up, let’s review why this is important and where to look for the standards that guide the process.

In the USA, the ADA (Americans with Disabilities Act) has been designed to protect individuals with disabilities from discrimination in various settings; public access to businesses and services, and in the digital space (e.g. websites, apps, digital products and experiences). It could be said that The European Accessibility Act (EAA) is the European parallel to the ADA. And in the European geographical region many countries have their own, and additional disability legislation to deal with discrimination to make the physical and digital world more accessible.

How long will it be before we hear of a high-profile digital discrimination, or lack-of-access case? Many stories in physical spaces have emerged in recent years. Perhaps the most recent was the experience of BBC journalist Frank Gardener. His article ‘I had to crawl to plane toilet’ highlights the lack of fair access for all. Read it here (opens in a new window).

All organisations will need to ensure their digital estates meet requirements. This is particularly true of Airlines, travel companies, car manufacturers, international eCommerce or any other organisation operating across borders where regulations, customers and users will extend beyond their ‘home country’. Legal experts and courts will likely reference the Web Content Accessibility Guidelines (WCAG) to consider compliance with disability regulation. And it is the version 2.1 AA standard that should be achieved.

Ok, so let’s look at some ‘low hanging fruit’: These issues are easier for all to relate to, and to appreciate the need to address in design and coding. However, they need a well-thought through approach within the UX/UI design process and coding strategy.

When designing for embedded apps (for example In Flight Entertainment GUIs and In Car Applications) we want to ensure that touch interactions work for all — not all users immediately recognise, or have the ability to use swipe, pinch and zoom, or flick gestures. We therefore need to design a range of touch interactions within the same interface. We also need to ensure that impaired sight or other users using screen reader technologies can perceive and navigate the experience.

Accessibility is not merely a compliance exercise; it should be a fundamental principle of good design. By ensuring that our digital products are usable by everyone, regardless of their abilities, we create a more inclusive and equitable user experience.

A baseline embedded App User Experience should consider navigation and interactivity via multiple interaction models and control devices (for example a keyboard or screen reader). Even touch interaction requires several options for it to accommodate a range of users with varying levels of ability. In this example, (1) is a swipe, but not all users have the dexterity or physical ability to swipe. But they may be comfortable with a single tap, hence the additional interaction point using arrow icons (2) as an alternative method to move the carousel of objects.

A Universal Baseline

One of the core tenets of accessible design is to establish a universal baseline. This means designing for the broadest possible range of users, anticipating their potential needs and challenges. This universality in design should consider the aging process as well as people with longer-standing vision impairments or health conditions. As people without visible disabilities age, their vision may deteriorate, making it more difficult to read small text or interact with tiny buttons. This doesn’t necessarily mean that all screen elements should be large, and large only, but a range of user-configurable size options should be available without breaking layout. By providing larger type sizes, buttons, and icons from the outset, we can accommodate a wider range of users without compromising the overall design.

Designing for Enlargement

Accessibility tools, such as screen readers and magnifiers, are essential for many users. But not all users have these software tools installed. When designing for accessibility, it's crucial to consider how changes in text size within the digital product itself will affect the wider performance and user experience of that product. For example, if the text is enlarged, will the layout still be readable and usable? To avoid retrofitting the design, it's essential to design for enlargement from the start. This ensures that the user experience remains as positive as possible, with or without accessibility tools.

In this series of layouts (baseline default size, large, larger), the text size and icons are increasing or decreasing in size, but other elements such as images remain the same. The layout does not break as the size of text and icons increases, but instead, the length of the page or screen grows.

Starting as early as possible in the design process is key. Yes, we could use the Chrome developer tools, Chrome extensions, or a range of software services to test webpages once the site is designed, built and deployed, but accessibility requirements are better met in the process of creating the initial design and UX system. We could also use a screen reader after deployment, for example the built in ‘Voice Over’ for MAC OS and other Apple operating systems, TalkBack for Android, or JAWS and NVDA for MS Windows. But again, it’s better to use these tools during the design and prototyping process.

A wireframe schematic defining the reading order of screen readers. For web development, the order of elements in the DOM can be modified.
Good and accessible colour contrast to meet accessibility standards can be defined during brand identity design. This matrix took the colour palette defined in brand development work and determined which pairing of brand colours could be used to combine text colour with background colour.

So, testing accessibility with an iterative design process or with tech prototypes rather than retrofitting final built software is best. First, fully review the WCAG guidelines and be aware of key test cases to ensure that you are as compliant as possible. Then do manual and automated testing. Document the process so that it is repeatable and analyse the results with any accessibility violations highlighted. Repeat the process at regular schedules to ensure proactive measures are taken to comply with regulations and the WCAG guidelines.

Designing and developing to be inclusive and to meet accessibility standards is not enough … also test with users!

This is so important! Test with a wide range of people. Ensure that in your test group you have those with cognitive, motor, vision and hearing impairments. Test with and without assistive technologies.

The Future Provenance accessibility icon set.