Today
27 phone-screens
17,910 pixels of content
−25%
Looking ahead

~7 phone-screens of scrolling could be reclaimed on this page if these findings are addressed.

A care home's profile page (Abney Court, Cheadle). The densest page in the audit, with 27 phone-screens of scrolling. Eight dark-purple panels announce each section with a heading, short intro and CTA, but at 280–520 px tall they take roughly 18% of the page to deliver 2–3 lines of content each. 81% of images on the page also cause it to jump as they load.

This is the densest page in the audit. The page’s structure is dominated by eight inverse-purple intro panels: each one carries a heading, a short intro and a CTA, but takes 280–520 px of vertical space to do so. Across the eight instances that’s around 2,686 px (about 18% of the page) given to section announcements. The panels function as section promos rather than as the section content itself, which then sits underneath each one.

Page-specific findings

F1.1 Medium density 2

Welcome body is 5 paragraphs of body-md with no lead, no key-facts band

~750 px of unstructured prose on a critical first-fold positioning module. All five paragraphs equal weight, hard to scan.

On the page
F1.4 Medium density 3

Trust block (How we are doing + reviews) split across 4 zones with ambiguous boundaries

The trust signals, "How we are doing" purple panel, carehome.co.uk reviews, CQC rating, awards, are scattered across four zones with no clear container hierarchy. Each carries its own intro panel, so the user reads four different "this is the trust section" cues.

On the page
F1.16 Low density

"Nearby homes" component packs several data points into a small space

The "Nearby homes" block on the care home page shows multiple homes with location pins, distances and metadata in a tight layout. Each home's information is dense; the component reads as busy. Padding around the pin block is also uneven, reinforcing the alignment finding (C-ALIGN.1) at component level.

F1.2 Low density 1

Duplicate H2 "Abney Court" 70 px below the hero ribbon

The hero ribbon already labels the home, the H2 "Abney Court" is redundant. Adds 120 px of wasted vertical and a heading-rotor entry that says nothing.

On the page
F1.12 Low layout 3

Carousel containers create uneven horizontal bars on mobile

The Events / Offers and Awards carousels both render with a light-purple container background. On larger viewports the background sits cleanly behind the carousel content. On mobile the background bleeds beyond the slides as uneven bars at the top and bottom of the section, making the carousel read as misaligned with the rest of the page.

On the page
F1.7 High touch 4

Slick.js carousel pagination dots, 15+ instances at 20×20 px

All slick.js dots on this page are 20×20, below the 24×24 AA minimum. The dots are the primary pagination affordance for image carousels (swipe is the alternative but discoverability is mixed).

On the page
F1.9 Medium touch 1

Map directions overlay links sub-AA

The "Download directions" / map-overlay links sit at small touch sizes overlaid on the static map preview.

On the page
F1.10 Medium typography

39 elements at 11 px, 38 at 12 px on this page

This page alone has 39 elements at 11 px, 38 at 12 px, 99 at 14 px, concentrated in carousel framing, gallery captions, and the footer.

F1.6 Medium typography 1

Trips and outings list uses heavy pink-square bullets

Filled-pink square bullets in front of every list item create disproportionate visual weight relative to body text. The eye snaps to the bullet column rather than the content.

On the page
F1.11 Low typography 1

Welcome body lead paragraph carries no extra weight

The opening positioning sentence is the same `body-md` as everything else. No visual signal that this is the page's lead.

On the page
F1.3 Medium navigation 3

"Meet our team" introduces the section but only shows one person

A dark-purple panel announces "Meet our team" but the section beneath it shows only one person, the Home Manager. The heading implies a team where the page delivers a single bio. The mismatch sets up an expectation the section doesn't meet, and gives the user no path to the rest of the team if they were hoping to see them.

On the page
F1.5 Medium navigation 4

Multiple horizontal-scroll carousels interrupt the page's vertical flow

The page hosts four or more horizontal-scroll carousels (facility images, events, awards) plus a separate gallery overlay, stacked down a long, otherwise vertically-scrolled page. Each carousel is its own interaction, by default only the first slide is visible, so anything past slide one needs the user to engage with the widget. Stacking four of these on one page asks the user to repeatedly switch between vertical scrolling (reading the page) and horizontal scrolling (consuming carousel content). The cognitive cost is real, and content beyond the first slide is also less likely to be seen.

On the page
F1.13 Low navigation 3

Carousels keep scrolling past their last slide

The slick.js carousels on this page (events, awards, reviews) don't stop when the user reaches the last slide; the user can continue swiping into empty or cloned slides indefinitely. There's no clear signal that the end has been reached, and the cloned-slide infrastructure adds DOM weight without serving the user.

On the page
F1.15 Low navigation 1

News article cards have no date or metadata so they read as ambiguous blocks

The "What's going on" rail on the care home page presents three article cards as image + heading only. There's no date, no event date, no "Article" or "Event" label. Users have to read the headline and study the image to infer what these blocks are; they could just as easily be product cards, links to other sections, or signposts. The result is that the rail reads as ambiguous content rather than as a list of articles.

On the page

Cross-page findings that apply here

These are component-level findings catalogued in the Cross-page findings view. Each is observed on multiple pages, so they're worth highlighting separately from page-specific issues.

C-ALIGN.1 High layout P01P02P03P04P05P06 3

Section components sit with inconsistent alignment to the page edges, breaking visual flow

Across the audit, several different section components on the same page render with mismatched left and right page margins. Some sit flush to the left edge with a wider right gutter; others reverse it; some sit roughly centred but with their inner content offset. On a mobile viewport where horizontal space is already at a premium, the result is a page that reads as misaligned. Each section starts at a slightly different horizontal position, the vertical rhythm down the page breaks, and the side with exaggerated padding wastes content area. Beyond the wasted space, the inconsistency carries a cognitive cost. Each new section asks the eye to re-anchor on a different horizontal axis. The user is constantly recalibrating where content begins and ends, which interrupts the natural top-to-bottom reading flow and adds friction to scanning the page. On a long page (the Care Home Detail page is 27 phone-screens deep), that friction compounds. The pattern is observable on the Care Home Detail page across the purple intro panels, the lighter-grey content cards, the Feature text panels (variants A and B), Care at our home, Reviews & Ratings, and the Nearby homes block. It carries over to the listing, promo-landing and careers templates, which inherit the same section components.

On the page
C-CHAT.1 High layout P01P02P03P04P05P06 2

Two persistent bottom-anchored widgets compound on every screen

Two competing always-on bottom widgets reduce the effective scrollable viewport by ~80–200 logical px on every screen of content the user reads. WCAG 2.4.11 (Focus Not Obscured), content under a persistent widget cannot be focused without scrolling around it. Per page: - P01, Olark chat icon + Recently Viewed (2 widgets) - P02–P03, Recently Viewed only - P04, Recruiting Assistant + Recently Viewed (2 widgets) - P05–P06, Recently Viewed only

On the page
C-CAROUSEL.1 High touch P01P04 3

Slick.js pagination dots are 20×20 px (sub WCAG AA touch minimum)

The dots are 20×20 logical px, below the WCAG 2.5.8 AA minimum of 24×24 px. They are the primary affordance for paginating image carousels on mobile, where swipe is the alternative but discoverability of swipe vs the dots is mixed.

On the page
C-IMG.1 High layout P00P01P02P03P04P05P06 2

71% of images across the audit are missing width / height / aspect-ratio

Images without explicit dimensions cause **layout shift** as they load, content jumps as the browser reserves space. This produces a poor Core Web Vitals CLS score (a Google ranking signal) and a janky perceived performance. The brief explicitly calls this out. Per page: - P00: 21 / 72 (29%) - P01: 242 / 297 (81%) - P02: 13 / 15 (87%) - P03: 10 / 12 (83%) - P04: 18 / 69 (26%) - P05: 3 / 5 (60%) - P06: 104 / 106 (98%)

On the page
C-PANEL.1 High density P00P01 3

Inverse-purple section-intro panels are used heavily across the page

Eight dark-purple panels announce sections across the page, each carrying a heading, a 2–3 line intro and a single CTA. On their own each panel is a reasonable section header; at this density they accumulate, and the dark-purple treatment dilutes the same colour used elsewhere for primary CTAs. The panels themselves vary in height, short on some sections, taller on others, and we don't have a per-panel measurement we can stand behind, but across the eight instances they take a substantial share of the page, before the user reaches the section content that sits beneath each one.

On the page
C-PANEL.2 Medium density P01P06 2

"At a glance" / "Job at a glance", long table-like metadata block

Stacks 4–6 rows of metadata (Location, View map, CQC Rating, Availability, Pricing PDF, Contract PDF on P01, Location, Pay, Shifts, Contract, Reference on P06). Sits in the second viewport on both pages.

On the page
C-FONT.1 Medium typography P00P01P02P03P04P05P06

11–14 px text used in 100+ places site-wide

WCAG and iOS HIG both recommend ≥ 16 px for body text. 11–12 px text is below that floor; 14 px is borderline (acceptable for footnotes / captions, not body copy). P01 alone has 39 elements at 11 px, 38 at 12 px, 99 at 14 px.

C-NAV.1 Low density P00P01P02P03P04P05P06 2

Top utility tab bar consumes ~50 logical px on every page

The three audience tabs (CAREERS / CARE HOMES / CUSTOMERS) sit at the very top of every page, they're a Care UK Group navigation (sister-site switcher) but consume permanent vertical space on a small viewport.

On the page
C-FOOTER.1 Low touch P00P01P02P03P04P05P06

Eight footer navigation links sit below the WCAG AA tap minimum on every page

Eight footer links measure 19 px tall on every audited page: About Care UK, Press & media, Feedback & complaints, Careers at Care UK, Legal & regulatory information, Privacy policies, Cookies policy, Web Accessibility. The WCAG 2.5.8 AA minimum is 24×24 px. These don't qualify for the inline-text exception in 2.5.8, since each link is its own row in a stacked footer navigation list, not a phrase inside a sentence. They are explicit navigation controls.

Potential ways forward

Observations on patterns that could improve the issues above. These are possibilities worth exploring, not committed solutions, the audit's deliverable is the diagnosis.

Signposting

Several of the eight inverse panels currently tell the full story of a section inline. They could function as doorways into deeper content elsewhere, giving the user enough to self-identify and click through, rather than having to consume the whole story on one page.

Progressive disclosure

Modules like "At a glance", news cards, and the reviews block could surface the one or two facts that drive a decision and let the rest expand on demand, instead of presenting everything at once.

Brand and button hierarchy

Heavy use of dark purple as a section background dilutes the same colour used for primary CTAs. With clearer separation between the two, primary actions become easier to find and signposting works better.