We drive system change and build a more equitable world for everyone by design. That means the creation of more accessible practices, policies, products, and services. We must model our own guidance and advice, and so our new accessible website is a tangible example of raising standards and reaching best practice.

The website project started for our team in late 2024 and continued until our soft launch at the end of July 2025. It was a significant undertaking for our small business, but when we began we knew that we wanted to open-source our learnings, and use the process to publish recommendations. 

Our outcomes are a collaborative effort. We invested considerable time to find a web design partner who shared our ambition in accessibility, and partnered with New Graphic for impactful, user-centred design and development. We also extended our relationship with Cova Communications, who have been our long-time branding and marketing partner, for content strategy and creation, as well as support on user testing.

Our co-design approach

In our day-to-day consulting practice, our approach uses a framework of co-design. This is where Disabled people are valued as experts in shaping solutions. As a majority-Disabled team, our human-centred design process is by and with Disabled people,  never executed ‘for’ them. We value lived experience as intellectual property. 

We believe that Disabled expertise is a vital part of the whole design process, not an afterthought, or for auditing when a project is complete. Getting to compliance is only the starting point for us, and when we build with lived experience, we create innovative solutions. We also believe that lived experience deserves fair compensation. Too often, Disabled people are asked to provide feedback without financial recognition. We always ensure that any participants from our research database are paid fairly for their time, insights, and contributions.

Accessibility goals for the new website

We had many business and communication goals for this project and we wrote about why this redesign was needed in “Our Journey to create a beautiful and accessible website”. We set out to prove that appealing and beautiful design does not have to be sacrificed to make an accessible website. And, that a beautiful website can and should provide an enjoyable, comfortable, and independent user experience. 

We also had two primary technical accessibility standards that we had to follow. 

The new European Accessibility Act standards

With the introduction of the European Accessibility Act (EAA) in June 2025, we wanted to demonstrate how to adhere to the new legislation and standards for digital communication. The EAA came into law across the EU with each member state translating the directive into their own local laws. It was created to improve the minimum standards for accessibility across member states and unify those standards. It also is to ensure that more people have access to essential services, and accessible physical and digital products. 

The standard we look at for websites is Standard EN 301 549 which can be applied to any type of ICT-based products and services. This includes software (web pages, mobile applications, desktop applications) and hardware (smartphones, personal computers, information kiosks). 

Web Content Accessibility Guidelines (WCAG)

We also followed the Web Content Accessibility Guidelines  (WCAG), a universal set of standards created to make web content more accessible. WCAG is not legally binding as it is a set of technical guidelines that are used to support compliance with EAA or other laws globally like the ADA (Americans with Disabilities Act). It is a framework for creating accessible digital content with detailed success criteria. 

The WCAG framework uses 4 Principles of Accessibility for assessment.

  1. Perceivable: Information and user interface components must be presentable to users in ways they can perceive. It can’t be invisible to all of their senses.
  2. Operable: User interface components and navigation must be able to operate the interface. The interface cannot require interaction that a user cannot perform.
  3. Understandable: Users must be able to understand the information as well as the operation of the user interface. The content or operation cannot be beyond their understanding.
  4. Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. As technologies and user agents evolve, the content should remain accessible. 

We aim to be compliant with WCAG version 2.2, fulfilling the A and AA requirements, which is the minimum standard for accessible websites. AAA is the highest level of accessibility but some of the success criteria are very strict or depend on user needs that can be in conflict with each other. Because of this, meeting all AAA requirements for every part of a site isn’t always possible. Where it was possible to meet AAA criteria, we implemented solutions. 

The requirements we set for the project

We focused our efforts on delivering a digital experience that meets the following requirements: 

  • Can be viewed on multiple devices
  • Can be navigated using a keyboard only
  • Can be magnified effectively up to 300%
  • Content can be translated to other languages
  • Compatible with commonly-used screen reader technologies
  • Visual assets have alternative text and captions 
  • Imagery is not the only method of conveying essential information and there is an alternative format provided
  • Video and audio content have subtitles and transcripts available 
  • Forms that are fully accessible integrated with third party platforms
  • Neurodivergence and cognitive disabilities are considered for technology compatibility and content creation. 

 

Our recommendations to add to your accessible design process

The insights from our four rounds of testing during the research, design, and development phases of the project, directly informed crucial decisions. Aside from the WCAG and EAA criteria checklist, here is our advice to bring to your own design process to improve access. 

  1. Test with Disabled people from the beginning: Be open to learn and change direction, and not just validate what you already believe. If you can, speak to your testers to clarify and expand on their challenges and feedback for a deeper understanding of the problem. 
  2. Lived experience is intellectual property: No matter what size your team is, you can engage in user testing and research. There is so much to learn online, standards to follow and lots of quantitative user testing findings. However, if you can, testing with Disabled people with lived experience can fundamentally shape your innovation and solutions. It is vital to understand that this is valuable work that can lead to innovation and we must ensure it is paid, respectful, and community-led.
  3. Examine your brand elements: Accessibility begins with your core brand elements – colour and fonts. The best time to check them is during a branding project and the second best time is now. 
  4. Review your testing questions: Look at the language you are using when testing. Is it biased or leading? In early stages it is important to ask open inviting questions in order to explore common barriers and uncover challenges in other solutions. Your question sets the expectation for the answer. 
  5. Content and cognitive load: Finding the balance between offering choices to participants and not overwhelming them, is an important discovery process. Reducing the cognitive load had a positive impact on participants and they were more engaged in browsing content as a result.  
  6. Consistent styling: Implementing a cohesive, simple, and intuitive visual language reduces friction for your audience. Your designs become more operable and understandable as they are able to predict what action will occur.
  7. More variation and personal experience: Check how robust your accessibility is by having participants test remotely on their personal devices. Development teams will never be able to replicate the variety of combinations of assistive technology that Disabled people use in their daily life.

Our accessibility statement and ongoing work

Accessibility is a continuous and evolving practice. Our work doesn’t end with the website launch. It’s important to us that we are transparent around the steps we are taking to continually improve digital access. We are committed to continuous review, updating, and improvement of our website’s accessibility and usability. 

Currently, in September 2025, we are conducting a further external independent audit to verify the standards and goals we set out.

We are also updating our internal content guidelines and updating our content archive where older media (PDFs and Videos) may not meet the requirements. We will continue working with assistive technology users to respond to feedback on the website.

If you would like to learn more you can read our accessibility statement.

Detailed breakdown of the testing outcomes in the co-design process

For designers, developers, and those interested in learning more about accessible digital design, we have put together a detailed breakdown of our four rounds of testing in partnership with Disabled people. 

Round 1: The research and wireframe phase

  • Focus: Review our old website and content. Determine the new site architecture and taxonomy. 
  • Participants: Tilting the Lens team with New Graphic and Cova Communications
  • Methods: A series of online interactive workshops led by New Graphic, that included card sorting, wireframing, and prioritisation tasks. 

Approach

In the research phase, all teams conducted an audit of the old website and created a matrix and prioritisation for things to improve. We looked at external feedback and findings to create an outline for the website we were going to build. 

We participated in a series of workshops led by New Graphic, looking at content and information organisation and site architecture so that we could speak about our work clearly and effectively. 

Key Insights

  • Revise the language around our services and clarify our offering
  • Introduce new features like filters and skip links to aid navigation
  • Expanding the number of pages to accommodate newer topics like school visits, partnerships and events. 
On a yellow background, there are 3 examples of wireframe web pages. Each consists coloured blocks and a line of text describing the content that would go in
We did sorting and wireframing activities to determine information architecture

Round 2: The visual design phase

  • Focus: To get feedback on key visual elements, colour palettes, fonts, button designs, and on language use and navigation expectations. 
  • Participants: Disabled research participants with diverse experiences – including Low vision (but not using screenreaders), colour blindness, Neurodivergence, cognitive disabilities, and Dyslexia.
  • Testing methods: Remote, unmoderated testing via a Google Form with visuals and a link to a static web page. Participants had the option to submit their feedback by form, video or audio recording, or a video call. In some cases, we followed up with a guided video call for deeper insights and an opportunity to explore challenges. 

Approach

At this design stage, we had flat visual designs in Figma of our key pages and elements. They weren’t interactive so this limited the types of assistive technology that we could test. What was important to test at this early stage, was our use of language, navigation, and core brand elements. 

We needed to check that our internal language and assumptions from our wireframes, for services and navigation etc., were going to be “perceivable” and “understandable” for users from the WCAG principles.  

Testing our primary brand elements to make confident decisions was essential before we got to development and wasted time and resources.

We deliberately used the word “comfortable” to assess the tester’s experience rather than “prefer” or a simple binary “yes or no”. We were looking beyond comprehension and compliance, and aiming for a feeling of ease. The use of “comfortable” invited our testers to contemplate the experience they were having and rate it on a personal scale, not a legal one. 

Two boxes displaying A and B options for font types and for button styles.
When asked to compare two font types for use in longer sentences and paragraphs, 100% of users chose the sans serif in Option B. When asked a similar question about button styles, 80% chose Option A, a black button with white text.

Key insights 

  • There were clear font winners: Feedback highlighted the importance of checking font readability for brand fonts. We tested our fonts against alternative options and we got a clear answer back. 
  • We had too many buttons and styles: Early designs had more button styles with different colours and an outline button option. Again there was a clear format winner but we also got feedback about the consistency of button styling across the site to create easy, predictable pathways. 
  • Too much content was overwhelming: Testers were overwhelmed by our first homepage layout. It was simply too long. We had so much to tell them and thought that by offering them lots of choice it would encourage browsing, but “it feels like you’re throwing everything at me all at once.” 
  • There was too much space between elements: Participants struggled with content proximity when we were leaving large gaps and padding. “I prefer to click-through a menu than to keep scrolling, not knowing if I will find what I need at the bottom”.
  • Colour compliance standards were “not comfortable”: An interesting finding occurred when asking about comfort and colour contrast for text and background colours. We discovered that as the contrast approached the WCAG standard, participants were able to read the text, but it took more effort and it was not a comfortable user experience. 
  • We needed a dark mode solution: 80% of our testers used dark mode regularly on their devices.
The first graphic shows the original design of skip links, they were in pale blue buttons. Underneath is the new version with the text simply underlined with a small arrow icon following it.
We altered the design for the skip links after testing, even though we wanted less button styles. We discovered that for many users their expectation was that a button shape will bring you away from the page you are on.

Round 3: Navigation and browsing development phase

  • Focus: This round focused on the accessibility of the main elements – like navigation, menus, written content, and images – and overall browsing experience. We tested a new homepage, and two example case study pages of the live test site on various user devices.
  • Participants: Disabled people employing a range of assistive technologies such as voice-activated software (Siri, Co Pilot), text-to-speech features on iOS, screen magnifiers, large text, and screen readers (NVDA, Talkback).
  • Testing methods: Again we used remote, unmoderated testing with a link to a live test site. Participants had the option to provide feedback via a Google Form, video/audio recording, or a Google Meet call. This was followed up in some cases with a guided video call to further understand some of the responses.  

Approach

In the first testing round on a live test site, we focused on independent navigation through the site and accessing all the content on the pages. This included many combinations of devices, browsers, and assistive technology to gain insights through personal experience. 

This was phase one of the development process and testing was carried out with only a few pages built and the core components added. We continued with our approach to get the core right before expanding as it is much easier to fix before you expand into other complicated features. 

A goal for this round and the next was to test for the fourth WCAG principle, “robust”. Our content and site must be interpreted reliably by a wide variety of user agents, including assistive technologies. We did this by asking each participant to test on two personal devices, and this increased the technology combinations we were getting feedback on. People may not engage with their phone and laptop in the same way. 

“I love ‘Client, Date, People, Sector’ on the case studies. You do not have to explore the website or page too much and are given the information immediately which is really lovely.”

Key insights

  • Testers successfully used the main menu: They navigated to various pages using their preferred devices and browsers, with interactions working smoothly across different screen sizes. 
  • Some issues were highlighted with particular devices and visual descriptions: This was beneficial to gain an understanding of different screen readers and their particular nuances. We needed clear labelling that could be accessed for icons and image-based elements to ensure everyone would have the same experience. 
  • Specific usability issues were identified: We picked up on lots of smaller issues – the search bar exit function and the reduced contrast of the menu on mobile in dark mode. 
  • A need for context and explanation for terms: Some testers highlighted the need for plain English for certain complex words or specific terms that might be unfamiliar. It was a good reminder as the team wrote content to ensure we were explaining any terminology clearly. 
  • Adding more semantic tagging: For case studies, news etc. we use a summary box at the top and we had useful feedback on how to improve this feature for screen readers. 
  • More proximity insights for content: Now that we had reduced the spacing throughout the site, it solved most of the issues for magnified browsing. However, we uncovered valuable learning around our layouts in case studies. For one user, their mobile experience was OK but on their laptop they were seeing large vertical gaps in content when zoomed in as our text switched sides. “I am zoomed in and it took a lot of navigation to find text. For example picture on the left and writing on the right and it switches for the next and then switches back again.”

“Although clear alt texts were set, there seem to be challenges with some devices and configurations.”

Round 4: Focus development testing with specific features

  • Focus: This round aimed to further refine specific page types and functionalities, particularly on the Resources Landing Page, an Article Page, the Meet the Team page, and the Events page. This included testing navigation, filtering mechanisms, and reviewing page content like videos and links.
  • Participants: Disabled people including individuals with low-vision or blindness using screen readers/magnifiers, colour-blindness, and mobility/physical disabilities who navigate using keyboards, joysticks, or voice.
  • Testing method: Testing web pages with complex elements on two devices, focusing on technical accessibility and browsing experience with assistive technology. Users had the option to provide feedback via a Google Form, video or audio recording, or a video call.

Approach

For this round of live testing and part two of our development phase, we took a deep dive into specific and more complex elements. We looked at the filters, news and resource pages, upcoming event cards and team member profiles.

We also revisited our new language in action as we asked participants to perform certain navigation tasks with vague instructions.

We asked binary questions when we asked testers to complete a task, but left openings to add context and detail around their experience. 

“Navigation followed a logical structure, with clear focus on headings, textual content, and interactive links etc.”

Key insights

  • We were able to verify a lot of development work that had been done by the New Graphic team to ensure a number of assistive technology users were able to navigate and access content across the site. We had very few issues reported at this late stage in the project.
  • Feedback on some link clarity and labelling throughout
  • One participant reported issues with their tech and the labelling of the mobile menu states which we were able to fix. 

“Links [on the event card] such as registration or external resources are functional via touch but could benefit from more detailed labels.”

Other Resources

View all resources