Access All Areas: Visual Accessibility in Web Design

In many ways, the design decisions made around visual accessibility have the widest impact on the broadest audiences. While all of the aspects of accessibility we’ve covered affect all users to varying degrees – such as content organisation for screen readers or functionality adjustments for keyboard navigation – visual accessibility has the most immediately noticeable effect. It directly influences how all users perceive and interact with your site, making it crucial to ensure that your visual design is inclusive and accessible for everyone. Let’s hear from the team.

Design

Clearly, designers play a huge role in ensuring visual accessibility. Once again, we turn to our in-house designer extraordinaire, Emma, to give us the rundown on how she addresses visual accessibility requirements in her work here at Tilt.

Contrast

When it comes to ensuring adequate contrast, we follow a specific process to guarantee that all users can comfortably read and interact with our sites.

I always start with the brand’s colour palette because maintaining consistency and brand identity is crucial. Recently, we have been working on a project with a client whose brand colours were vibrant and visually appealing but didn’t provide sufficient contrast. Using tools like the TPGi Color Contrast Analyzer, I tested various combinations. When the primary colours fell short, I created secondary and tertiary palettes that adhered to the guidelines. For instance, if a brand’s primary colour was a shade of light blue that didn’t contrast well with white text, I might use a darker blue or a different background colour for text elements. This ensures every piece of text is readable while still feeling cohesive with the brand’s identity.

However, if no brand colours meet accessibility contrast guidelines, we will need to make adjustments.

There are two ways we can go about this, depending on the brands’ flexibility:
We would use tools such as ‘Use Contrast’ in Figma, which enables you to find similar tints and shades which pass accessibility. These kinds of changes usually need client approval.

Instead of using a brand colour, we could use a neutral colour, like black, for primary buttons and other navigational elements and keep the use of brand colours for background elements. This ensures that there is enough contrast between elements while keeping the design consistent with the brand identity.

Typography & Scaling

Choosing the right typography involves balancing aesthetics with readability and accessibility. I start by selecting clear and legible fonts. Sans-serif fonts like Helvetica or Verdana are often good choices because they’re clean and easy to read at various sizes. However, we are often tied to using brand fonts. In these cases, readability can be improved by adjusting spacing to give generous line heights and by limiting line lengths to avoid them becoming too wide.

When I design layouts, I ensure that text resizing is accommodated up to 200%. This is crucial for users with low vision who rely on larger text sizes.

To ensure that the type scales nicely, I use relative percentages for font sizes and spacing. This allows the content to scale smoothly without overlapping or causing layout issues.

One key rule we follow at Tilt is to avoid using text within images. Text in images can’t be resized or recognised by screen readers and other assistive technologies, which is a red flag for accessibility. If we must use text in images, we will always provide a suitable alternative text description. Generally, though, it’s best to keep text and images separate for maximum flexibility.

Transitions & Animation

Designing animations and transitions involves careful consideration to ensure they enhance the user experience without causing issues. I always keep several key considerations in mind. Animations should be smooth and not too rapid—fast transitions can be disorienting for some users, especially those with vestibular disorders.

I prefer subtle animations that guide users’ attention without overwhelming them. For instance, I often use gentle fade-ins or slide-ins to draw focus to new content or to provide feedback after an interaction. These animations should also be brief. I aim for a duration between 200ms and 500ms, as longer animations can frustrate users who are looking for quick interactions.

Lastly, testing is a vital part of the process. We always test our designs with our in-house QA Engineer to ensure that our animations and transitions are accessible.

Development

While developers have less responsibility for the decisions made around visual accessibility, they play a crucial role in bringing those designs to life. Our lead developer, Colette, shares how she sets about implementing designs to enhance and maintain the accessibility considerations given in the design phase.

Contrast

There are several checks in place before a signed-off design gets to me. So, by the time it comes to implementation, I can be pretty confident that contrast has been checked and meets the requirements. However, we’re all human, and sometimes things slip through. That’s why I occasionally check things that I think may be on the line.

There are plenty of tools available for this. My personal favourite is https://colourcontrast.cc/. I also have the WCAG Contrast Checker Chrome extension installed, which is handy for checking the whole page in one go.

Typography & Scaling

As with contrast, typography choices are primarily set during the design phase, and my role is simply to implement the system. It can be so easy to overlook features like letter-spacing and line-height during development, I’ve definitely been guilty of this myself! But these details are crucial to the readability of content.

Even more important is the ability to zoom text. WCAG guidelines require that users be able to zoom text to 200%. This can be achieved either by using browser zoom features (CMD + on Mac or CTRL + on Windows) or by adjusting the baseline font size in the browser settings.

To support this functionality, developers need to use the right units to define text sizes. Relative units like rems (short for ‘root-em’) are ideal because they allow font sizes to scale relative to the baseline font size. This means that if a user has set a baseline size in their browser settings, all font sizes will adjust accordingly, or they’ll default to the browser standard – typically 16px. I highly recommend reading Josh Comeau’s article, The Surprising Truth About Pixels and Accessibility covering this very subject.

Transitions & Animation

Micro interactions, transitions, and animations can all really help bring a site to life. Subtle visual flourishes, like feedback when you roll over a button to show it’s interactive—what we call “polish” in the industry—can help make otherwise dry content more engaging. For most users, these tools aid in communication. Using transitions and animations to deliver content at a natural pace can reduce cognitive load.

However, while animations enhance the user experience for many, they can be distracting or even harmful for others. For instance, certain animations may cause headaches, dizziness, or nausea in individuals with inner ear disorders. That’s why offering a reduced motion option is included as part of the WCAG success criteria for achieving AAA standard accessibility.

Luckily, there’s a pretty straightforward solution. Since around 2019, the prefers-reduced-motion CSS media query has been widely supported by browsers. This feature allows developers to detect when users have set a preference for reduced motion and automatically deliver simplified transitions, ensuring a comfortable experience for everyone.

Bonus: Testing in Development

As this is our final blog in the series, I thought I’d include some extra information on accessibility testing in development. Tilt is a React house, which is pretty great because there are a bunch of React tools that help with accessibility testing. Of course, they don’t replace manually testing your site for things like tabbing order or screen reader compatibility, but they can help identify technical issues as you go.

We’ve set up all our projects to use ESLint’s accessibility plugin, which is a great tool for identifying accessibility issues directly in your raw code, such as missing role attributes or alt texts. In the past, we’ve also used a package called @axe-core/react in conjunction with Chrome DevTools to highlight accessibility issues in our compiled code. Unfortunately, this package doesn’t support newer versions of React.

For a comprehensive overview, we rely on Lighthouse, which has been integrated into Chrome’s DevTools since around 2018. Lighthouse is an invaluable tool for testing various aspects, including accessibility, helping us ensure our projects meet the highest standards for all users.

QA

QA is the lynchpin that holds every part of the process accountable. Having QA involved from start to finish is crucial for catching visual accessibility issues early on. Jordan, our resident QA and accessibility guru shares how he pulls it all together to ensure our projects meet accessibility standards.

Testing Visual Accessibility

Ensuring a website is visually accessible involves meticulous testing and adherence to established Web Content Accessibility Guidelines (WCAG 2.2).

We use a structured approach when testing for visual accessibility, covering contrast, visible tab focus indicators, descriptive links, and responsive design.
Although there are numerous automated tools available to check contrast, a manual check with a contrast tool yields the best results.

At Tilt, I use Colour Contrast Analyser and WebAIM’s Contrast Checker to identify areas of low contrast. Generally speaking, the minimum expected contrast ratio for text against its background is 4.5:1. For user interface elements, it’s slightly lower at 3:1. It’s also recommended to inspect critical elements like text, buttons, and links across different browsers and devices, not forgetting to check hover states and tab focus indicators to ensure adequate contrast.

Visual accessibility is far more than contrast. In addition to contrast checks, we ensure that steps are taken that mean that content can be navigated without issue. We confirm that consistent navigation is provided across all of the pages/screens within the experience so that all users, including those with disabilities, can efficiently and effectively navigate without becoming disoriented. We also verify that forms have clear and consistent visual labels and that clear instructions are present before each form control. Additionally, it is crucial that all error messages are clear and concise and provide helpful information on how to rectify the error.

Further visual checks are carried out to ensure that content does not flash more than three times in any one-second period and that moving content can be paused, stopped, or hidden. Checks are also carried out to confirm that controls to pause, stop, or hide the content are accessible and easily identifiable.

Final Words

We’ve thoroughly enjoyed sharing our journey into designing, developing, and testing inclusive, accessible experiences with you. Throughout our series, we’ve delved into essential aspects of accessibility, including keyboard, screen reader, and visual accessibility. By prioritising these elements, we not only fulfil our social responsibility to make the web accessible to all users, but we also enhance the experience for everyone. 

If there’s one key takeaway from our series, it’s that retrofitting accessibility features is far more challenging than incorporating them from the outset. A proactive approach, with accessibility at the heart of every stage – from conception to delivery – not only streamlines the development process but also ensures a more inclusive and seamless user experience.

Here at Tilt, we strive to improve with each project, and, in short, this is the best advice we can give. As with anything in life, tackling a challenge can often feel overwhelming at first. But start small, break it down into smaller, more manageable goals, and then build on success.

Read the previous articles in the series:

Access All Areas 1: Insights on Web Accessibility 

Access All Areas 2: Essential Aspects of Web Accessibility 

Access All Areas 3: Keyboard Accessibility from Design to QA

Access All Areas 4: Ensuring Screen Reader Compatibility