Driving inclusive housing with digital accessibility

Challenge

Stonewater is one of the UK's largest social housing providers and a charitable registered housing association. The website supports some of the most essential moments in people's lives: finding a home to rent or buy, managing a tenancy, paying rent, and reporting repairs. The site launched in 2023 and had received incremental improvements since, but had never been through a full accessibility audit against current standards.

One in five people in England lives with a disability that affects how they use the web, whether that's auditory, cognitive, motor or visual. Stonewater wanted to understand whether its website was usable by everyone who needed it, including the significant number of visitors who use assistive technology, and to fix the issues identified, in line with WCAG 2.1 AA and the newer WCAG 2.2 AA criteria (required for public-facing digital services). With further legislation such as the European Accessibility Act raising the bar across Europe, they asked us to audit the site thoroughly, uncover barriers they couldn't see from the inside and fix them with technical rigour and user insight. 

Our audit specifically targeted recurring barriers mapped to WCAG success criteria 1.3.1 (Info and Relationships), 1.4.11 (Non-text Contrast), 2.1.1 (Keyboard), 2.1.3 (Keyboard - No Exception), 2.4.7 (Focus Visible), 2.4.13 (Focus Appearance), and 4.1.2 (Name, Role, Value).

Solution

To ensure comprehensive coverage, Manifesto and Stonewater agreed on eight to ten templates which encompass all the components in the website. This approach eliminates the need to duplicate issue logs; because the site is built on atomic design principles—a methodology for constructing interfaces by breaking them down into fundamental, reusable building blocks like atoms, molecules, and organisms—resolving a barrier in one component automatically remediates it across all templates.

We tested Stonewater's website using four methods together so that the limitations of any single approach wouldn't leave gaps in our findings.

The four testing methods we combined:

• Automated testing with Axe DevTools, Siteimprove and WAVE swept our agreed templates and found the issues which can be created while coding the website against the WCAG 2.2 AA criteria. Normally this process find 40-50%  of issues

• Assistive technology testing — macOS VoiceOver, screen magnification, keyboard-only navigation — took us off the spreadsheet and onto the site itself, showing us what it actually felt like to use rather than what a scanner said about it.

• A full code review by our development team got under the bonnet, catching structural issues that only surface when you're elbow-deep in the markup.

• User testing sessions with five people living with visual, auditory, cognitive and motor impairments. This went across ten pages covering Stonewater's core journeys and told us how real people experience the site day to day — the part no tool can simulate.

The three accessibility issues we found most often:

1. Missing or under-used ARIA labels

• 4.1.2 Name, Role, Value (Level A) — the core one; interactive elements must expose an accessible name so assistive tech can announce what they do.

• 1.3.1 Info and Relationships (Level A) — often relevant too, since missing ARIA frequently means the relationship between elements (label to input, etc.) isn't programmatically conveyed, not just the name.

2. Poorly coded interactive elements (SVGs blocking keyboard access)

• 2.1.1 Keyboard (Level A) — the headline breach; all functionality must be operable via keyboard.

• 4.1.2 Name, Role, Value (Level A) — usually cited alongside it, since custom-coded SVG controls typically lack a proper role as well as keyboard support.

• 2.1.3 Keyboard (No Exception) (Level AAA) — worth a mention if you want to flag the stricter standard, though AA is the practical benchmark most orgs target.

3. Focus states with poor colour contrast

• 1.4.11 Non-text Contrast (Level AA) — the primary one; UI components and states (including focus indicators) need at least 3:1 contrast against adjacent colours.

• 2.4.7 Focus Visible (Level AA) — focus must be visibly indicated at all, separate from whether the contrast is sufficient.

• 2.4.13 Focus Appearance (Level AAA, added in WCAG 2.2) — the newer, more specific criterion covering focus indicator size and contrast if Stonewater is being assessed against 2.2 rather than 2.1.

In total, we identified and fixed 105 accessibility issues across the site, from these recurring patterns to smaller, page-specific fixes, and measured the outcome using before and after Lighthouse scores across all eight core templates.

Impact

Accessibility scores improved on every template where fixes were made, by an average of 4 points, with identical results on desktop and mobile throughout. The largest improvement was on the Contact Us page, up from 88 to 97, both the lowest starting score of any template and the biggest single gain.

In the three months following the work, completions of the site's complaint form fell by 13% compared with the previous quarter. Read alongside the Lighthouse results, this is a promising early signal: the Contact Us page had both the lowest starting accessibility score and the largest improvement, and it's plausible that removing barriers there reduced the friction that had previously led some users to the complaints form.

Stonewater now has a clearer picture of where their site's accessibility barriers were, a fully remediated set of core templates, and a foundation to keep improving as new standards and user needs evolve.