WCAG compliance is the floor, not the ceiling. I’ve reviewed dozens of digital products built by UK teams who ticked every accessibility checkbox, shipped their app, and then watched users aged 60 and over abandon it within two minutes. The guidelines cover contrast ratios and keyboard navigation. They do not cover the lived reality of designing for someone who has never used a smartphone until their late fifties, has some degree of age-related macular degeneration, and finds most app navigation patterns genuinely baffling. App design for older users UK accessibility is a specialist discipline, and treating it as a WCAG checklist exercise is where most teams go wrong.
The UK’s Office for National Statistics puts the over-60 population at roughly 16 million, and that figure keeps climbing. NHS apps, council portals, financial tools, and retail platforms all need these users. They are not a niche edge case.
Cognitive load is the real killer, not contrast
Working memory declines with age. That is not a controversial claim; it is well-documented cognitive science. What it means for interface design is that the number of simultaneous choices, the density of options on a screen, and the length of multi-step flows all need to come down significantly compared to what you’d ship for a general adult audience.
I tend to think about it like this: if a 35-year-old can hold four things in their head while navigating your onboarding flow, design as if your 68-year-old user can hold two. That means progressive disclosure is not just a nice UX pattern, it is load-bearing. Break multi-step processes into single-question screens. Put one primary action per view. Cut every secondary option that does not absolutely need to exist on that particular screen.
The NHS App is a reasonable reference point here. Its appointment booking flow keeps each step minimal, labels are plain English, and the confirmation screen repeats key information rather than assuming users retained it from two screens back. That repetition feels redundant to a younger user and essential to an older one. You cannot design for both with the same screen, and that is fine. Design for the user who needs the most support and you will not alienate the one who needs less.
Touch target sizing: the WCAG minimum is not enough
WCAG 2.5.5 recommends a 44×44 CSS pixel minimum for touch targets. In practice, for users over 60, particularly those with any degree of tremor, reduced fine motor control, or arthritis, 44px is still small. Research from the Nielsen Norman Group puts comfortable touch target size for older users closer to 60x60px, with generous spacing between adjacent targets to reduce mis-taps.
Mis-taps are a huge source of frustration. When a user taps the wrong button repeatedly, they lose confidence in the interface and in themselves. That confidence collapse is much harder to recover from in an older user than a younger one. I’d argue the emotional cost of a mis-tap is asymmetric across age groups, and that asymmetry should drive your sizing decisions.
Some practical rules I use: make primary call-to-action buttons at least 56px tall, keep destructive actions (delete, log out, cancel) physically separated from confirmatory ones, and never place two tappable elements closer than 12px apart. On a related note, the accessible palette decisions UK product teams often get wrong apply doubly here, older users have reduced contrast sensitivity that compounds the touch accuracy problem when buttons are poorly differentiated visually.
Font legibility goes further than size
The standard recommendation is 16px body text minimum. For interfaces targeting users over 60, I’d go to 18px as a floor, with headings at 24px or above. But size is only part of font legibility. The typeface choice itself matters enormously.
Age-related changes to the lens of the eye reduce sensitivity to fine detail, which is why highly stylised typefaces, thin weights, and fonts with low x-heights become genuinely difficult to parse. Avoid any font weight below 400 for body copy. Prefer humanist sans-serifs, Inter, Atkinson Hyperlegible, or system UI fonts, over geometric ones. Atkinson Hyperlegible was specifically designed for users with low vision and performs exceptionally well in this context; the British Dyslexia Association also endorses it for overlapping reasons.
Line height matters too. Tight leading, common in sleek modern UI, forces the eye to work harder to track from one line to the next. Set line height at 1.6 or above for body text. And if you are using fluid typography with CSS clamp(), make sure your minimum clamp value never drops below 18px in older-user-facing contexts, even on small viewports.
NHS-informed interaction patterns worth stealing
The NHS design system is publicly available and genuinely excellent. The team that built it consulted heavily with patients across age groups, and the patterns reflect real-world usability testing rather than theoretical best practice. A few things in particular stand out.
First: plain English labels over clever microcopy. “Continue” beats “Let’s go.” “Your appointments” beats “My health hub.” Older users map UI labels directly to mental models formed outside digital contexts. The closer the label matches the real-world concept, the faster comprehension happens.
Second: explicit error messages that tell users exactly what to fix. “Invalid input” is useless. “Your date of birth should be entered as DD/MM/YYYY, for example, 15/03/1958” is useful. The NHS form patterns specify this level of specificity as standard, and it drastically reduces abandonment in older cohorts.
Third: visible, persistent navigation. The hamburger menu is a learned pattern that many older users simply never learnt. If your app can run with a bottom tab bar or persistent side navigation rather than a hidden drawer, do it. The cognitive cost of remembering that the menu is behind a three-line icon is higher than it looks.
You can read more about how strong institutional UI work informs everyday product design in my piece on the design principles behind BBC iPlayer, a lot of the same “reduce ambiguity, increase predictability” logic applies across user groups.
Testing with real users, not assumptions
The single most common mistake I see is teams designing for the mythical “older user” based on assumptions rather than running sessions with actual people aged 60 and over. It is not the same thing. The variance within that group is enormous, a 62-year-old software developer has completely different needs from a 78-year-old who has owned a smartphone for six months.
Age UK runs digital skills programmes across the UK and has published research on common barriers older users face with digital services. Their findings consistently point to confidence and trust as primary blockers alongside the interaction design issues covered above. Users need to feel that the app will not do something unexpected, will not lose their data, and will always give them a clear way back. Irreversible actions without confirmation dialogs are particularly damaging to trust in this cohort.
Recruit test participants through local libraries, NHS patient groups, or organisations like Age UK. Run tasks, observe without prompting, and note every hesitation. Those hesitations are your redesign brief.
The data visualisation and information density decisions that come up in ageing-population app design also map directly onto the broader challenge of designing data-dense interfaces that actually work, the same principle of ruthless information hierarchy applies whether your user is 30 or 70.
WCAG is necessary. It is not sufficient. Get the cognitive load right, size your targets properly, pick legible type, borrow from the NHS design system, and test with real older users. That is the actual brief.