Your Toughest Beta Tester Is Turning 74: Running an Accessibility Audit With an Older Relative

Most app audits happen in a bubble. A founder, a designer and a product manager sit around a MacBook in a quiet office, tap through a prototype on a top-end handset, and agree it feels lovely. Then the app goes live, and someone's mum rings because she can't find the button to pay.

That gap matters more than ever. UK over-65s are one of the fastest-growing groups adopting smartphone apps—not just WhatsApp and weather, but banking, NHS services, supermarket loyalty cards and travel. If your product assumes a young, steady hand and perfect eyesight, you are quietly writing off a chunk of the market. Worse, you are probably making the app harder for everyone else too.

So here is a low-tech, high-signal audit you can run before launch. No lab. No eye-tracking rig. Just an older relative, a pot of tea, and a willingness to watch someone struggle without jumping in.

Pick the right relative (and don't call it granny testing)

You want someone who uses a smartphone for everyday things but would not describe themselves as a power user. A parent or aunt who sends WhatsApp voice notes, checks the weather and maybe does a bit of online banking is ideal. Avoid the relative who works in tech, and avoid anyone who needs a lot of help already—unless your app is specifically for people who need support, in which case, even better.

This is usability testing, not a favour. Say thank you properly. If it is family, make lunch. If you recruit outside the family, pay a voucher and respect their time. And please don't call it 'granny testing' in your notes. It's an accessibility and usability session with an older adult.

Set the scene like a real Sunday

Do it at their kitchen table, not in your office. Use their phone if they are happy to, because that is the device they actually know. If you use a spare, don't crank the font size to maximum before you start—start with the default and let the session reveal what happens.

Ask them to complete three short tasks that mirror real use. For example: find the opening times for a local venue, update a saved address, and turn off a notification they don't want. Keep it to 20 minutes. Ask them to think aloud, but resist the urge to guide. If they pause, wait. The pause is the data.

Turn the text up and watch the layout squirm

Go into the phone's display settings and increase the text size a couple of notches. Then try the larger accessibility sizes. On iOS, this is Dynamic Type; on Android, it's font scale. Does your app respect it? Plenty don't.

Look for clipped labels, buttons that shrink to nothing, cards with fixed heights, and text hidden behind icons. Check bold text too. If your app uses custom fonts, make sure they scale. If your headings are images, they won't. And test the bits people skip: error messages, form field labels, and the small print under a price.

Take the phone to the window

Contrast looks fine on a calibrated monitor. It looks different in a grey November kitchen. Hold the phone near a window and check placeholder text, disabled buttons, grey-on-white captions and focus states. If you rely on colour alone to show an error—red border, green tick—add an icon or a word. Older eyes, and plenty of younger ones, will thank you.

Also check dark mode if you ship it. A design that works in light mode can turn into a murky soup at night.

Test taps with a shaky hand and a short thumb

Apple suggests 44 by 44 points; Google suggests 48 by 48 density-independent pixels. Those are minimums, not targets. Watch your relative tap the back arrow, the close cross, a checkbox and the 'pay' button one-handed. If they miss twice, the target is too small or too close to another control.

You can increase the hit area without making the icon huge. Add padding. Space destructive actions away from everyday ones. And check edge gestures—on a big phone, a back swipe near the screen edge can fight with the app's own gestures.

Read the copy out loud

Plain English is an accessibility feature. Permission prompts are where trust leaks. 'Allow App to send notifications?' is a system prompt, but what did you say before it? If the answer is 'personalised experiences', start again. Try: 'We'll only ping you when your delivery is ten minutes away.' Then give them a 'Not now' that actually works.

Check error messages. 'Something went wrong' is not an error message; it's a shrug. 'We couldn't save your address. Check your postcode and try again' tells someone what to do. Use UK spellings and local terms—postcode, not zip code; mobile, not cell. Avoid 'authenticate', 'seamless' and 'leverage'. If a sentence needs a second read, cut it.

Ask five questions afterwards

Once the tasks are done, ask: What was easy? What was annoying? Did you trust it? Would you use it again? What would you tell a friend? Write down their exact words. Don't argue. Don't explain. The moment you say 'actually, it's here', you've lost the insight.

Fix in order, not all at once

Start with blockers: unreadable text, tap targets that fail, permission dead ends where saying no breaks the app. Then fix friction: confusing labels, hidden back buttons, vague errors. Polish comes last. A useful rule: if your tester needs help twice on the same task, treat it as a bug, not a training problem.

Run this audit before every major release, not once. One relative is a start; three older adults from different backgrounds is better. You don't need a research budget to learn what your app feels like at a kitchen table. You just need to stop designing for the quiet desk and start designing for the Sunday roast.