Coverpage

This book is a curated documentation of web content accessibility guidelines applicable for the elderly and modified slightly to make them suitable for mobile apps. This is a completely free resource. Any distribution of the content of this document for monetary purposes is not cool!

This is also a multi-tab document, so make sure that you go through all the tabs to get the entire content.

Written by

Dr. Aashutosh Kulkarni

Nicknamed double-A, just like the accessibility standard.

Product Designer | Design system expert | Accessibility Philosopher | PhD (h.c.) in Digital Accessibility and Inclusive design | CPACC | Invited expert at W3C | About to be an AI Engineer | Product Manager

doublea11y.com 

Preface

CHAPTER ZERO

Preface

We're only getting older, baby
And I've been thinking about it lately
Does it ever drive you crazy
Just how fast the night changes?

– One Direction

Now there is a generation, the people born in the 80s, born into a pre-internet era, who are not willing to admit that all of us are getting older, but there are signs! The back pain that won't go away, the cracking noise the knee makes after a deep squat, myopia almost everywhere, and the list goes on!

The thought for this book began with a clear sign. One week sometime in January, I noticed the font size on my wife's phone increased very slightly. The apps that we regularly use started showing truncated text. Later that week, she started increasing the distance between the phone screen and her face to get a clearer image. Furrows forming all over her forehead. The following week, the phone was at maximum distance she could hold, font size increased by another notch, truncating the text a bit more, the brightness increased. The ophthalmologist gave her a prescription for corrective lenses for presbyopia.

This made me think that all of us are getting older and we will definitely in the near or distant future need the apps to be accessible. Now accessibility has traditionally been focused on people with disabilities. Although aging is not a disability, there are signs! (nobody would like to admit it, but there are!). The memory starts its tricks, the visual focus is gone, the high tones disappear, tremors start and learning new things starts becoming more and more difficult. I started looking at how our parents or the older generations are using their mobile phones and jotted down a few salient points. The brightness is always at 100% the font size is always at the biggest possible setting and if they can't perform the operation they offload that task to their children or just abandon the app completely. I am an avid technology user and I want to continue using all my favorite apps as long as I can or as long as I have to.  I understand that whatever my lovely wife went through, I will go through the same, one day, pretty soon. Hence I started looking at accessibility guidelines ,to be made stricter so as to enforce these guidelines by law so that our generation, when it reaches the future, can interact with digital media effortlessly.

Call me selfish, but after looking at the way everything is being developed with AI right now, I believe that we are already too late to set the right precedent. The million project highlights that about 97% of the web pages on the internet do not satisfy the accessibility criteria. The research done in Washington University tells us that 23% of the apps had more than 90% labels missing. If AI is trained on this kind of data, how will we ever secure our own future? This is an attempt to set forth the guidelines that can help our future generation of designers, to design the apps for the future us!

Why Elderly-Friendly Design Matters

CHAPTER ONE

Why Elderly-Friendly Design Matters

The problem isn't with the people. It's with the design.

Let us introduce you to two people. Their names are Mark and Julie. Once you meet them, you'll see them everywhere. In every app that's a little too hard. In every website that's designed with text a little too small. In every login screen that asks too much from a perfectly capable person.

Meet Mark

Mark is 67 years old. He spent 35 years advising some of the biggest companies in Europe on their finances. He is sharp, curious, and genuinely loves technology. That might surprise you. He has the latest iPhone. He tries out new apps. Every morning at his kitchen table in Amsterdam, with the canal glittering outside and a strong coffee in hand, he spends at least an hour on his phone. News. Markets. WhatsApp with the kids. Instagram with the grandchildren, group chats with his golfing buddies.

Meet Julie

Julie is 65. She spent her career in insurance. The high-stakes kind where you price enormous risks and have to be right far more often than you're wrong. She's brilliant. She's also on her phone four hours a day. Recipes on YouTube. FaceTime with the grandchildren. Instagram, which she joined three months ago because her granddaughter Sophia kept posting photos Julie was missing.

Together, Mark and Julie are exactly the kind of customers every digital company claims to want; because they have money and they have time. They're loyal to products they love. They travel. Bali, United States, Portugal, Vietnam. They are not technophobes. They are not helpless.

And they are, every single day, let down by the apps and websites they use.

Not because Mark and Julie are bad at technology. It's because the people who build these apps aren't building them for Mark and Julie. They're building them for a 28-year old designer with perfect eyesight, designing on a calibrated screen, inside a shaded office, with steady hands, and a brain trained from childhood to navigate digital interfaces without thinking twice.

The Numbers Are Impossible to Ignore

Let's start with the scale of it. Right now, there are roughly 750 million people over 65 on earth. By 2030 that number will cross one billion. By 2050, the World Health Organisation estimates it will reach 1.5 billion. That's one in six people on the planet.These are not people stepping back from the world. They are people like Mark and Julie: active, travelling, spending, and online.

The fastest-ageing region in the world is Asia. Japan already has 29% of its population over 65, almost one in three. By 2050, nearly 40% of the populations of Japan, South Korea, Taiwan and Hong Kong will be 65 or older. Singapore, where Mark has several clients, will see one in four residents over 65 by 2030. In China, the over-65 population has already grown from 7% in 2000 to 15% today. Their collective spending is on track to triple, from $750 billion to $2.1 trillion, within a decade.

Europe is no different. Italy and Germany are already classified as 'super-aged societies'. Countries where more than 20% of the population is over 65. Italy, where Julie once attended a cooking course in Bologna, has a median age of 49. Several other European countries are close behind. The European Union's own research found that only one in four older Europeans has basic digital skills. Yet they are increasingly required to use digital services to access healthcare, banking, government support and even ordering food!

Now the “SILVER ECONOMY”. Adults over 50 control roughly 70% of all disposable income in the United States. In the UK, older consumers represent more than £320 billion in annual spending. Japan's 'longevity economy' (the market built around older consumers) is expected to grow to $780 billion by 2040. Across Asia Pacific as a whole, senior spending is projected to exceed $5 trillion per year by 2030. The global silver economy (products and services aimed at the over-60s) was valued at $5.5 trillion in 2023 and is growing at roughly 5% per year.

This is not a niche. It is the fastest-growing, highest-spending consumer group on earth. Right now, most of the apps and websites they use were built without them in mind.

Who are we designing for?

Here is something the statistics often miss: 29% of adults aged 65 to 72 are still in full-time employment. They are not sitting at home with unlimited time and patience. They are professionals, using your tools in between meetings, on their phones, with all the time pressure any working adult faces. Becca Selah makes this point precisely: designing for "older users" as if they are all retired leads to patronising decisions. [Selah, Salesforce/Medium]

What happens when design gets it wrong

Mark is sitting by the pool in Phuket

He is trying to do his online banking while on holiday in Thailand. The app logs him out after two minutes of inactivity. While he is reading the screen. He has to log in again. The password field won't let him paste from his password manager. He types his 18-character password by hand. Gets it wrong twice. The sticky air and the sweat are not helping. On the third attempt, the account locks. He calls the bank's international support line. Fifteen minutes later, he's in.

Not the relaxed afternoon he had planned.

Julie is on a train

She is setting up her Instagram account. The verification step times out while Julie is looking for the code in her email. The page tells her time has run out and she has to start again. She doesn't understand what she did wrong. She feels, for just a moment, like perhaps this isn't for people like her.

It is for people like her. The design just didn't know that.

...and what happens when design gets it RIGHT!

Curb cuts were originally designed for wheelchair users. But who else uses them? People with prams. Cyclists. Delivery workers. Almost everyone, at some point. Designing for elderly users works exactly the same way. When you make text bigger and easier to read, everyone benefits. When you make buttons easier to tap, everyone benefits. Good design for elderly users isn't a special accommodation. It's just a good design.

How this book works

This book takes 25 guidelines from the Web Content Accessibility Guidelines and explains them in plain language, without jargon.

• The Must-Haves -> 11 guidelines that address the most severe and universal barriers. Without these, you are actively locking real people out every single day.
• The Good-to-Haves -> 10 guidelines that separate an adequate product from one people actually trust and return to.
• The Honourable Mentions -> 4 guidelines that matter in specific contexts.
• The ones beyond → A few rules for designing apps better suited for elderly and everyone

Ready? Here we go!

Understanding Your Elderly Users

CHAPTER TWO

Understanding Your Elderly Users

They are not broken. Design is!

Elderly users aren't a special category of broken people who need a dumbed-down version of your app. They are thoughtful, capable, experienced people experiencing physical and cognitive changes that your current design doesn't account for. The fix is to design your one product well.

1. Vision: The world gets Hazier

Mark is sitting on the terrace of their villa in Ubud. He's trying to check the restaurant reservation in the hotel's recently redesigned app. Elegant light-grey text on a white background. In the studio where someone designed this, it looked stunning. In the Bali sun, the screen washes with glare and the text has vanished. He squints. Tilts the screen. Cups his hand like a visor. He can make out maybe half the words.

The lens of the eye changes with age. It yellows. It stiffens. This affects contrast sensitivity: the ability to tell apart colours and tones that are close. That light-grey text on a white background? To a 30-year-old on a calibrated monitor, it looks sophisticated. To Mark at 67, in the sun, it's invisible. Julie has early cataracts. Completely normal, not yet serious enough to treat. But it means everything she sees has a slight haze. Lots of visual information at once feels overwhelming.

2. Hearing: The High Notes Disappear First

Julie is boarding a flight to Chiang Mai. She hears the boarding announcement, or she thinks she does. The gate number sounds like it might be different from where she's been waiting. She's not sure. She looks up, checks the boards, checks her phone. She was fine. But for ten seconds she wasn't certain. The announcement was a high-frequency voice over a PA in a noisy terminal, and that combination is specifically what her hearing now struggles with.

Most age-related hearing loss isn't about volume. It's about frequency. The high-pitched sounds go first. This affects roughly one in three people over 65. Mark wears hearing aids. He loves them. But when he watches a video on his phone without headphones, in a noisy café in Ho Chi Minh City, he still misses words.

3. Motor Control: The Small Things Get Harder

Mark has a very mild tremor. Barely noticeable in conversation. But on a touchscreen, aiming for a small icon is genuinely difficult. The close button and the confirm button are next to each other. He taps one. It's the wrong one. He calls customer service. They're very nice. But it's 45 minutes he didn't plan to spend.

Julie has arthritis in her left hand. On cold mornings, her fingers are stiff. Precise movements like hitting a tiny checkbox or tapping a small icon are genuinely hard. She often hits the wrong thing on densely-packed apps. She doesn't blame the apps. She blames herself. That's the insidious thing about bad design: users absorb the failure as a personal inadequacy.

4. Cognitive Processing: The Brain Takes Longer

Julie is halfway through a form. She switches to another app to check the details. When she comes back, the form has reset. Everything she entered is gone. She stares at the empty fields. She starts again. Gets to the same field. Checks. Comes back. The form has reset again. She closes the app. She doesn't subscribe.

Cognitive processing speed slows with age. This does NOT mean elderly people are less intelligent. Mark can still analyse a financial situation faster than most people half his age. The change is more specific: the speed of processing new information in unfamiliar environments. The design lesson is simple. Be predictable. Label everything. Explain errors. Give people time. Let them paste. Don't reset forms.

Four Myths Worth Busting Right Now

✗ They don't use smartphones.

Wrong. Smartphone adoption among the over-65 group is the fastest-growing segment globally. Mark and Julie each use their phones four hours a day. Others, even more!

✗ They just need a bigger font.

Incomplete. Font size is one of the dimensions. An app with 20-point text that auto-submits on dropdown change, that times out after 2 minutes, is still a terrible experience.

✗ They'll ask for help if stuck.

False. Most elderly users disengage rather than ask for help. Julie will close an app three times before she calls her daughter. Abandonment is the default.

✗ They need a simplified version.

Patronising. Mark doesn't need a 'senior mode.' He needs the same product everyone gets, designed properly. Good design is the answer.

The Must-haves

CHAPTER THREE

The Must-Haves

These 11 guidelines are the floor, not the ceiling. Without them, you're actively locking Elderly and by extension- revenue out!

1. Resize Text - WCAG 1.4.04 · Level AA

Mark is in Porto, brilliant late-afternoon sun streaming behind his phone screen. He's trying to read the terms and conditions for a travel insurance policy. The text is small. His phone is already set to 150%  font size, but the app did not respect that. He pinches to zoom. The text gets bigger . but now the page doesn't fit his screen, and he has to scroll left and right to read each line, like reading a newspaper turned on its side. After two paragraphs, he gives up. He signs up without reading the terms. Which might be fine. Or might not be.

WHAT THE GUIDELINE SAYS

Text must be resizable up to 200% without losing content, functionality, or requiring horizontal scrolling.

WHAT THIS MEANS IN PRACTICE

Fixed-height containers . boxes whose height doesn't grow when text inside gets bigger . are the main offender. When the font doubles and the container doesn't grow, text gets cut off. The fix is flexible layouts: containers that grow with their content, buttons whose height adjusts to the label inside them, text that wraps gracefully.

ON NATIVE MOBILE

On the web, text zoom is handled by browser CSS. On native iOS and Android, users scale fonts system-wide through Accessibility settings — iOS Dynamic Type, Android font scale. Your app must honour these system settings. Text must reflow, not clip or overlap, when the user has their phone set to the largest font size. This is not optional behaviour; it is the platform equivalent of browser zoom.

So…Who Does what

DESIGNERS

• Design all components with auto-height containers. Never fixed pixel heights on text-bearing elements.
• Test every screen at 150% and 200% text size before sign-off.
• Use a design system text-scale token rather than hard-coded sizes.
• Avoid placing long strings in fixed-width badges or chips. Test wrapping behaviour.

CONTENT TEAM

• Keep labels short enough to wrap gracefully across two lines without losing meaning.
• Never embed text inside images. It cannot be resized by the OS.
• Avoid abbreviations that only make sense at single-line width.

ENGINEERING

• Use relative units (rem/em) for all font sizes. Never px on text.
• Set min-height instead of fixed height on any container that holds text.
• Test with iOS Dynamic Type and Android font scaling enabled at the largest setting.
• Ensure all text containers use overflow: visible or wrap correctly.

The Broader Lesson

Mark isn't asking for anything special. He's using a built-in accessibility feature on his phone that's been there for years. When your app breaks that feature, it's not Mark's fault. It's yours.

2. Text Contrast - WCAG 1.4.03 · Level AA

Julie is at Amsterdam Airport, about to board a flight to Jaisalmer. She's checking her hotel booking in the hotel's recently redesigned app. The new design is beautiful. Elegant golden text on a white background. At Schiphol, under fluorescent lights with sunlight streaming in, Julie cannot read it. She ends up forwarding the confirmation to her email app, which has plain black text on white, and reads it fine there.

WHAT THE GUIDELINE SAYS

Text must have a contrast ratio of at least 4.5:1 against its background. For large text (18pt+ or 14pt bold), the minimum is 3:1.

WHAT THIS MEANS IN PRACTICE

That elegant light-grey, or golden in this case, text almost certainly fails. The soft blue placeholder text inside a form field fails. Run every colour combination through a contrast checker before it lands in the design system. Checking takes 30 seconds. There is no excuse for skipping it.

WHAT RESEARCH SAYS

WCAG requires a 4.5:1 contrast ratio, but research suggests going further. Becca Selah recommends a 7:1 ratio for older users, whose lenses yellow with age (a phenomenon she calls the "ginger-ale glasses" effect). This yellowing makes it especially hard to distinguish blues and purples. [Selah, Salesforce/Medium]

So…Who Does what

DESIGNERS

• Run every text/background colour pair through a contrast checker (Colour Contrast Analyser, Who CanUse) before adding to the design system.
• Document approved colour pairings with their contrast ratios in Figma.
• Flag placeholder text, disabled text, and footer text. These fail most often.
• Set 4.5:1 as the minimum. Target 7:1 for primary body text.

CONTENT TEAM

• Never write placeholder text in light grey. It must also meet 4.5:1.
• Avoid using colour alone to convey status (e.g. red error text must also have an icon).
• Ensure captions and subtitle text embedded in video meet contrast requirements.

ENGINEERING

• Never override text colour outside the approved design system palette.
• Ensure dynamically loaded text (API responses, user-generated content) renders in approved styles.
• Test all themes and dark/light modes for contrast compliance.
• Add contrast checking to the UI component test suite.

The Broader Lesson

Julie is not using her phone in a dark room. She's using it in airports, cafés, gardens, in the back of a taxi. Contrast that barely works in ideal conditions fails in real conditions. Design for the real world.

3. Non-Text Contrast - WCAG 1.4.11 · Level AA

Mark is updating his shipping address in a shopping app. He can see there are form fields. But one seems to be highlighted, maybe selected. There's a very faint border. Or maybe that's just a shadow. He taps what he thinks is the next field. He's actually tapped outside the form entirely. The form closes. He has to start again. The form field borders were a very light grey on a white background. The focus ring was even lighter.

WHAT THE GUIDELINE SAYS

Non-text elements (buttons, form field borders, icons, focus rings, checkboxes) must have a contrast ratio of at least 3:1 against adjacent colours.

WHAT THIS MEANS IN PRACTICE

Form field borders, focus rings, icon-only buttons, toggle switches, radio buttons and checkboxes are all subject to this rule. The beautiful minimal aesthetic (white buttons with barely-there borders, ghost buttons, pastel-on-pastel) is a consistent accessibility failure. Minimal doesn't mean invisible.

WHAT RESEARCH SAYS

For older users, contrast requirements extend beyond text. Age-related lens changes make it harder to distinguish UI boundaries, button edges, and form fields from their backgrounds. Matthew Stephens highlights that a clear typographic and visual hierarchy helps older users scan interfaces without feeling lost or overwhelmed. [Stephens, UX Collective]

So…Who Does what

DESIGNERS

• Ensure all form field borders (default, hover, focus, error, disabled states) meet 3:1 contrast against the page background.
• Design focus rings to be highly visible. At least 3:1 but aim for 4.5:1. Never style them away.
• Check icon-only buttons: the icon itself must meet 3:1 against its background.
• Include contrast ratios for all component states in design system documentation.

CONTENT TEAM

• All icon labels and tooltip text must meet standard text contrast requirements.
• If an icon conveys meaning alone (no text label), flag it for designer/engineer review.

ENGINEERING

• Never use outline: none on focus states. Design the focus ring instead.
• Ensure all component hover/focus/active states maintain 3:1 non-text contrast.
• Test with browser high-contrast mode enabled.
• Implement focus-visible polyfill for keyboard-only focus indication where needed.

The Broader Lesson

The interface is not decoration. Its job is to show people what they can do. If interactive elements can't be seen, they can't be used. And when they can't be used, people don't think 'this interface is invisible.' They think 'I can't figure this out.’

4. Reflow - WCAG 1.4.10 · Level AA

Julie has discovered she can zoom into news websites by pinching. The text gets bigger, which is wonderful. The problem is that half the websites she zooms into become unusable. The text gets bigger but the page doesn't adapt. Now she has to scroll left and right to read each line. Like reading a banner stretched across the whole room. After two paragraphs she either resets the zoom and goes back to tiny text she can't read, or she leaves.

WHAT THE GUIDELINE SAYS

Content must reflow at 320 CSS pixels wide without requiring horizontal scrolling or losing information. Everything must stack into a single, scrollable column.

WHAT THIS MEANS IN PRACTICE

This is one of the most ignored guidelines, affecting more than 37% of mobile users performing daily tasks. Design a single-column layout first. Data tables, side-by-side content blocks, and fixed-width elements are the most common failures. Test at browser zoom 400%. If content starts scrolling horizontally, you have a reflow failure.

ON NATIVE MOBILES

The web standard targets 320px-wide viewports. On native mobile, Reflow also applies to orientation changes. Rotating a phone from portrait to landscape; something older users do frequently to read text more easily, must not cause content loss, horizontal scrolling, or broken layouts. Test both orientations. They are not the same screen.

So…Who Does what

DESIGNERS

• Design mobile-first: single-column layout as the baseline, side-by-side as an enhancement.
• Ensure every component in the design system has a defined behaviour at 320px width.
• Never design side-by-side layouts without specifying the stacking behaviour for narrow screens.
• Avoid horizontal data tables. Design card-based or list alternatives for small widths.

CONTENT TEAM

• Write content that reads sequentially. Never design a reading order that depends on visual position.
• Keep paragraph line lengths reasonable so text wraps cleanly at any width.
• Avoid content that only makes sense when two columns are visible side by side.

ENGINEERING

• Use flexbox with flex-wrap: wrap or CSS grid with auto-fill for all multi-column layouts.
• Give data tables a horizontal scroll wrapper. Never let them break the page layout.
• Use percentage widths, not fixed pixel widths, for all layout containers.
• Test all screens at browser zoom levels 150%, 200%, and 400%.

The Broader Lesson

When someone zooms in, they're telling you the text is too small to read. The right response is to make that content easier to read. Zooming in shouldn't mean trading one problem for a worse one.

5. No Complex Gestures - WCAG 2.5.1 · Level A

Mark's granddaughter Sophia loves a recipe app, so Mark downloaded it so they could cook together on video calls. Beautiful swipe interface: swipe left for next step, right to go back, up for tips, down for ingredients. Sophia does it without thinking. Mark's mild tremor sometimes sends the swipe diagonally, triggering the wrong gesture. He ends up at the ingredient list while he wanted ‘the next step’. The chicken was overcooked. He and Julie laughed about it. But he doesn't use that recipe app anymore.

WHAT THE GUIDELINE SAYS

Any functionality that uses complex gestures (swiping in a specific direction, pinching, drawing a path) must also be available through simple single taps. The gesture can exist. It just can't be the only way.

WHAT THIS MEANS IN PRACTICE

Carousels must have visible previous/next buttons. Maps must have zoom buttons. Swipe-to-delete must have a visible tap alternative. Signature fields must offer a 'type your name' option. The gesture stays. It's a delight for users who find it natural. But there must always be a tap-based route.

ON NATIVE MOBILES

WCAG 2.5.1 specifically targets path-based gestures — swipe-to-delete, drag-to-reorder, pull-to-refresh. Every gesture of this kind needs a button alternative that requires no motor precision. On iOS and Android, built-in swipe patterns feel familiar to many users but are invisible to anyone who hasn't discovered them by accident.

Never make a gesture the only path.

So…Who Does what

DESIGNERS

• For every gesture interaction in the design, add a visible tap/button equivalent. Document both in the spec.
• Carousel components must always show prev/next buttons. Never gesture-only.
• Map interactions must include zoom in/out buttons, not just pinch-to-zoom.
• Signature or drawing inputs must include a 'type your name instead' option.

CONTENT TEAM

• Label all button alternatives clearly and descriptively: 'Next slide,' 'Zoom in,' 'Go back'.
• Write an onboarding copy that mentions tap alternatives, not just gesture controls.

ENGINEERING

• Implement all gesture listeners alongside tap/click event alternatives. Never gesture-only.
• Ensure swipe-to-action components (delete, archive) expose the same action through a long-press menu or visible button.
• Test all gesture interactions with a single-pointer device (stylus or mouse).

The Broader Lesson

Gestures are invisible. They announce themselves to no one. Buttons are visible. They announce themselves. Use both. Always

6. Minimum Target Size - WCAG 2.5.8 · Level AA

Julie is in Bangkok. Third day, having the time of her life. She's using a travel guide app and wants to save a restaurant to her favourites. She taps the little heart icon. She misses. Something else activates. The map jumps. She taps back, finds the restaurant, tries again. Misses again. She finds it a third time. Holds her breath. Taps very carefully. Gets it. Three attempts. One small icon. One long day of walking. Slightly unsteady fingers. A 16×16 pixel target.

WHAT THE GUIDELINE SAYS

Interactive targets must be at least 24×24 CSS pixels, or have enough empty space around them so adjacent targets don't crowd each other.

WHAT THIS MEANS IN PRACTICE

24×24 is the floor, not the target. Apple recommends 44×44. Google recommends 48×48 and 56×56 in hard to read areas like top and bottom of the phone screen (considering single handed use). Considering an average finger size of 9mm, 48×48 scalable pixels is the real-world minimum for touch. You can add an invisible extended hit area around a small icon without changing the visual design at all.

ON NATIVE MOBILES

WCAG 2.2 sets 24×24 CSS pixels as the floor. WCAG2Mobile translates this to native platform guidance: 44×44pt on iOS (from Apple's Human Interface Guidelines) and 48×48dp on Android (from Google's Material Design). These are the practical minimums for older users with reduced motor precision. A 24px target is survivable on desktop. On a phone held in an ageing hand, it is a consistent failure point.

So…Who Does what

DESIGNERS

• Set all interactive elements to a minimum of 44×44pt in design files. Annotate hit areas separately from visual sizes.
• Ensure adjacent targets are at least 8pt apart to prevent accidental activation.
• Never place multiple tappable elements closer than one average finger-width apart.
• Use Figma hit-area annotations to specify tap zones that extend beyond visual bounds.
• Avoid adding multiple links very close to each other in a single paragraph. .

CONTENT TEAM

• N/A. This is a design and engineering concern, but flag any design with dense link lists for review.

ENGINEERING

• Use padding (not margin) to extend tap areas. Padding is included in the hit area, margin is not.
• On iOS: implement minimum 44×44pt tap targets; on Android: minimum 48×48dp.
• For inline links in text: add extra line-height and padding to increase the tap zone.
• Use accessibility inspector tools to audit tap target sizes before release.

The Broader Lesson

Human fingers have not been updated. They are the same size they've always been. A touch target smaller than a fingertip is a design error. Test your designs with your actual finger. Notice how often you miss.

7. Enough Time - WCAG 2.2.1 · Level A

Mark is doing his taxes on a government portal. He's been working through it carefully. 25 minutes in, he gets to a section involving his pension from a firm that was acquired. He opens another app to look it up, reads the paperwork, makes a note, comes back to the browser. The form has timed out. 10 minutes was the session limit. Everything he entered is gone. He closes the laptop. He calls his accountant instead. The accountant charges him €150 for what should have been a 30-minute online task.

WHAT THE GUIDELINE SAYS

Where a time limit is set, users must be given the option to turn it off, adjust it, or extend it. There should be advance warning before time runs out.

WHAT THIS MEANS IN PRACTICE

Timeout warnings need genuine advance notice. At least 2 minutes, ideally more. The 'extend session' button must be large and clearly labelled, not tucked away in a modal. For forms: save progress automatically. If a session expires, restore what the user entered when they return. Users relying on assistive agents consistently require more time to complete tasks than most people.

WHAT RESEARCH SAYS

When users feel rushed, executive function declines — and older adults are more vulnerable to this than younger ones. Under pressure, they may click recklessly on anything just to escape the situation. Michal Halperin Ben Zvi and Kinneret Yifrah found that urgency cues in interfaces trigger disproportionate stress responses in older users. [Halperin Ben Zvi & Yifrah, UX Collective]

ON NATIVE MOBILE

Native apps have no browser-level session warning. Unlike the web, there is no standard timeout alert — apps must implement their own. An in-app warning with enough time to respond, shown before a session expires or a form clears, is a mobile-specific implementation responsibility. Most apps skip it entirely.

So…Who Does what

DESIGNERS

• Design a timeout warning dialog with large, clearly labelled 'Continue' and 'Log out' buttons.
• Warn users at least 2 minutes (ideally 5 minutes) before session expiry. Not 20 seconds.
• Design visible auto-save indicators so users know their progress is being preserved.
• Design a 'restore saved progress' state for when users return after a session expiry.

CONTENT TEAM

• Write timeout warnings in plain language: 'Your session will expire in 5 minutes. Tap Continue to stay logged in.'
• Write auto-save confirmations: 'Your progress has been saved.'
• Never use technical language like 'session timeout'. Say 'you'll be logged out'.

ENGINEERING

• Save form data to local storage or server at regular intervals (every 30 seconds minimum).
• Restore saved form data automatically when a user returns after session expiry.
• Trigger the warning dialog with sufficient advance notice. Implement a countdown.
• Allow session extension without any loss of entered data or page state.

The Broader Lesson

Mark wasn't dawdling. He was being thorough. The design rewarded his thoroughness by destroying his work.

That is a design failure, full stop.

8. Captions for Audio and Video - WCAG 1.2.2 · Level A

Julie has been learning about investing. Her financial advisor keeps recommending YouTube videos. The presenter is enthusiastic but speaks quickly, with a slight American accent Julie finds hard to follow. She turns up the volume. She pauses and replays. She gets about 70% of it. One day she notices a small 'CC' button in the corner of the video player. She turns it on. Suddenly she can follow every word. She watches the entire video in one sitting. Then three more. The captions were there all along. She just hadn't known to look for them.

WHAT THE GUIDELINE SAYS

All prerecorded audio and video content must have synchronised captions that accurately reflect what is being said.

WHAT THIS MEANS IN PRACTICE

Auto-generated captions are a starting point, not a finish line. They need review, especially for speaker names, industry terms, and proper nouns. Caption text must be high-contrast, clearly sized, and surfaced prominently. Consider making captions the default. Users who don't need them can turn them off.

So…Who Does what

DESIGNERS

• Include a dedicated caption display area in every video component design. Below the video or as a non-overlapping overlay.
• Ensure caption text meets contrast requirements (4.5:1 minimum against the caption background).
• Design a caption toggle button that is prominent. Not buried in a settings menu.
• Specify maximum caption line length and font size in the design system.

CONTENT TEAM

• Review all auto-generated captions for accuracy before publish. Correct speaker names, technical terms, and proper nouns.
• Write captions in sync with speech rhythm, not just as a transcript block.
• For multi-speaker video, include speaker identification in captions.
• Caption all sound effects that convey meaning (e.g. '[door slams]', '[alert sound]').

ENGINEERING

• Implement caption support using platform APIs: AVPlayer caption tracks on iOS, SubtitleTrack on Android.
• Default captions to 'on'. Respect user OS caption preferences.
• Ensure the caption file format (VTT, SRT) is validated and correctly synced.
• Never hardcode captions into the video. Use a separate caption track for editability.

The Broader Lesson

Captions don't just help people with hearing loss. They help anyone in a noisy environment, watching in a second language, or in a room where someone else is sleeping. One feature, universal benefit. Users who don't need them can turn them off.

9. Easy Logins - WCAG 3.3.8 · Level AA

Mark uses a password manager. He takes security seriously. His investment account has a password like '4kF#mR9pLx@2nQvT'. He's in Phuket, sitting by the pool. His password manager tries to autofill. He accepts. He taps submit. The app rejects it. He tries again. He discovers the app has disabled pasting. He must type his 18-character password by hand. He gets it wrong twice. The account locks. He calls the hotline for international support.

Fifteen minutes later, the problem is solved. The afternoon could not be saved!

WHAT THE GUIDELINE SAYS

Memorising and typing complex passwords must not be the only way to authenticate. Copy-paste must be allowed. Password manager autofill must be supported. Alternative methods like biometrics or email-link login should be provided.

WHAT THIS MEANS IN PRACTICE

Never disable paste in a password field. Never. There is no security benefit. It prevents no known attack, and only hurts users doing the right thing. Elderly users might forget passwords, because in some cases memory also fades with age, and it is essential to allow password managers to fill in credentials on their behalf. Add biometric login. Consider magic-link login: a link sent to the user's email that logs them in with a single tap.

ON NATIVE MOBILE

On mobile, this criterion carries additional weight. Password fields must permit paste — blocking paste breaks password managers. Biometric authentication (Face ID, fingerprint) is a fully valid WCAG-compliant alternative to cognitive tests. Apps must also support the platform autofill framework: iOS UITextContentType and Android autofillHints. Without these, the password manager the user trusts cannot help them.

So…Who Does what

DESIGNERS

• Design biometric login (Face ID, fingerprint) as the primary, most prominent option.
• Include a 'magic link' or 'email login' option as a secondary path.
• Never design password fields with a visual indicator that paste is blocked.
• Design a visible 'show/hide password' toggle on all password fields.

CONTENT TEAM

• Write login instructions that acknowledge password managers: 'You can use your password manager to fill in your credentials'.
• Provide clear error messages for auth failures: 'That password doesn't match our records. Try again or reset your password.'
• Write magic-link emails in plain language: 'Tap the button below to log in instantly. No password needed'..

ENGINEERING

• Never call preventPaste(), preventDefault(), or equivalent on password fields. Ever.
• Implement correct autocomplete attributes: username and current-password.
• Support biometric auth APIs: LocalAuthentication on iOS, BiometricPrompt on Android.
• Implement a magic-link login path using time-limited, single-use tokens delivered by email.

The Broader Lesson

Easy logins are a security feature. When logins are hard, people use simple, repeated passwords. When logins are easy, people use password managers. The decision that makes Mark's life harder also makes the product less secure.

10. Point to and Explain Errors - WCAG 3.3.1 · Level A

Julie is booking a surprise cooking class in Rome for Mark's birthday. She fills in the form carefully. Hits submit. At the top of the page a small red banner says: 'There were errors with your submission. Please check your form.' Julie looks at the form. Everything looks fine. She submits again. Same message. She calls the cooking school and books by phone. What had gone wrong: the phone number field required a local Italian format. There was no message next to that field. No highlight. Just a vague banner.

WHAT THE GUIDELINE SAYS

When an input error is detected, the specific item in error must be identified and the error described in text. Next to the field, not in a banner at the top.

WHAT THIS MEANS IN PRACTICE

Every error message must answer two questions: what went wrong and how do I fix it. 'Invalid input' is not an error message. 'Please enter your phone number with the country code, for example +31 6 12345678' is an error message. In an ideal case, validations happen immediately after the user moves focus from the field. Not only ‘on submit’.

WHAT RESEARCH SAYS

Older adults are more likely to interpret error messages as personal failures. The microcopy around errors must be warm, never accusatory. Phrases like "We couldn't find that address" work better than "Invalid input." The error must also persist disappearing alerts are missed entirely by users who process information more slowly. Processing speed for written content is 1.4 to 1.7 times slower for older adults. [Halperin Ben Zvi & Yifrah, UX Collective]

ON NATIVE MOBILE

Toast notifications and snackbars that auto-dismiss after a few seconds fail this criterion for older users, who process text 1.4 to 1.7 times more slowly. An error that disappears before it is read has not been communicated. Errors must persist next to the relevant field — not float, not animate away, not require re-triggering to see again.

So…Who Does what

DESIGNERS

• Show error messages inline, directly adjacent to the relevant field. Never only in a banner at the top of the page.
• Use icon + colour + text for error indication. Never colour alone.
• Design a clear visual error state for each form field (border, icon, message placement).
• If multiple fields fail on submit, scroll to and focus the first error automatically.

CONTENT TEAM

• Write every error message as: field name + what went wrong + how to fix it.
• Example: 'Phone number: Please enter a valid number with country code, e.g. +31 6 12345678'.
• Never write 'Invalid input,' 'Error,' or 'Required' alone. These tell users nothing actionable.
• Pre-empt errors with visible format hints below input fields before submission.

ENGINEERING

• Trigger inline validation on field blur (not only on submit) wherever the validation logic is known.
• Programmatically associate error messages with their fields using accessibility APIs.
• Never clear a valid field's value when showing an error on another field.
• On submit errors, shift focus to the first erroneous field and announce the error count.

The Broader Lesson

Julie knew her phone number. The system knew the format was wrong. The only person who didn't know how to fix it was Julie. The system didn't tell her. An error message isn't a notification. It's an instruction.

11. Input Labels - WCAG 3.3.2 · Level A

Mark is filling in a form for a new streaming service. About six fields. He fills in the first three. Gets to the fourth. The placeholder text, the grey hint inside the field, has vanished because he typed in the previous fields. He stares at the blinking cursor. Is this for his date of birth or his account creation date? No label outside the field. No hint. He guesses: date of birth. It was for his postcode. He has to go back. And now he's not sure he hasn't confused two other fields as well. He starts over from the beginning.

WHAT THE GUIDELINE SAYS

Every form field must have a visible, persistent label that describes what it's for. It must not disappear when the user starts typing.

WHAT THIS MEANS IN PRACTICE

Placeholder text is not a label. The moment someone starts typing, it disappears. A persistent label positioned above the field is the correct implementation. Always visible, always clear. The floating label pattern (placeholder that rises to become a label as you type) is an acceptable middle ground. Every field. Every time. No exceptions.

WHAT RESEARCH SAYS

Long forms are a significant barrier for older users. Michal Halperin Ben Zvi recommends breaking forms into sections and showing clear progress indicators. When users know where they are in a process, they are less likely to abandon it. Shortcuts and autofill also reduce the actions required which matters when motor precision has declined. [Halperin Ben Zvi, Smashing Magazine, 2023]

So…Who Does what

DESIGNERS

• Place a persistent, visible label above every form field. Never use placeholder text as the sole label.
• If using the floating label pattern, ensure the label text remains fully visible at all times while typing.
• Required field indicators (asterisk, 'Required') must be explained at the start of the form. Not assumed knowledge.
• Label text must be unambiguous: 'Date of birth (DD/MM/YYYY)' not just 'Date'.

CONTENT TEAM

• Write label text that is clear without being verbose. 'Email address,' not 'Enter your electronic mail address'.
• Include format hints in the label or as persistent sub-label text: 'Phone number (+country code)'.
• For required fields: explain the indicator once at the top. 'Fields marked * are required'.
• Write label text that can be read independently of the visual form layout.

ENGINEERING

• Use semantic label elements (or platform equivalents) associated with each input via 'for'/'id' pairing
• Never remove or hide labels programmatically. The label must remain in the DOM and be visible
• Ensure labels are correctly exposed to screen readers at all times, including during error states
• Never rely on aria-placeholder as a substitute for a persistent label.

The Broader Lesson

Forms are already stressful for many elderly users. A visible label costs nothing and eliminates a significant source of confusion. It is one of the easiest, highest-impact improvements a design team can make.

The Good-to-haves

CHAPTER FOUR

The Good-to-Haves

These 10 guidelines separate a product people tolerate from one they actually trust.

If the must-haves are the ramp at the door, the good-to-haves are the comfortable space inside. They are what makes someone feel welcomed and respected rather than merely admitted.

12. Purpose of Field (Autofill) - WCAG 1.3.5 · Level AA

One travel app gets it right. Julie taps the name field. Her phone immediately offers 'Julie van der Berg.' She taps it. Taps the email field. Her email appears. Taps the address. The whole address fills in, correctly split across street, city, postcode. Form completed in about 12 seconds. No errors. She loves this app. She uses it every trip. She has recommended it to four friends.

WHAT THE GUIDELINE SAYS

The purpose of each input field must be programmatically determinable. This means the code tells the browser what kind of information goes in each field, so autofill can work.

WHAT THIS MEANS IN PRACTICE

Every form field in your design spec needs the correct autocomplete attribute annotated. This is closely tied to Guideline 3.3.2 Input Labels. The difference is that this guideline is about passing the purpose to assistive technology and browser autofill. Guideline 3.3.2 is about making users understand the purpose visually.

ON NATIVE MOBILE

On the web, autocomplete attributes handle this. In native apps, the equivalent is the platform autofill API: iOS UITextContentType for fields like name, email, phone, and address; Android autofillHints for the same. Without these annotations, the OS cannot offer to fill the field from the user's saved data. For older users managing multiple accounts and addresses, autofill is not a convenience — it is the difference between completing a task and abandoning it.

So…Who Does what

DESIGNERS

• Annotate every form field in your design spec with the correct autocomplete type. Include this in your Figma handoff notes.
• Most important values: name, email, tel, street-address, postal-code, bday, current-password, new-password.
• Mark which fields should and should not trigger autofill (e.g. security challenge fields should be excluded)

CONTENT TEAM

• If writing UI copy, ensure field labels match the data type so autofill suggestions make sense to users.

ENGINEERING

• Add the correct autocomplete attribute to every input field. Cross-reference the design spec.
• For password fields: use current-password for login, new-password for registration. These tell password managers what to do.
• Never disable autocomplete on non-sensitive fields. Only disable it where there is a genuine security reason.
• To prevent format errors, add real-time input validation: e.g. phone number fields reject letters instantly.

The Broader Lesson

Autofill exists because filling forms is a chore. For elderly users with arthritis or slower typing speeds, autofill isn't a luxury. It's a genuine relief. Supporting it costs almost nothing.

13. Persistent Tooltips - WCAG 1.4.13 · Level AA

Mark is reviewing a financial dashboard. He wants to know what 'unrealised gain' means. He taps on the tiny question mark. A tooltip appears, four lines of small text. He gets to line two. The tooltip disappears. He hovers again. It appears. He reads quickly. It disappears again before he finishes. He reads the definition in four separate passes before he has the whole thing. Ironically, the most crucial part of that particular text was on line #4

WHAT THE GUIDELINE SAYS

Hoverable and focusable content must remain visible long enough to read, must not disappear when the user moves their cursor onto the tooltip itself, and must be dismissible by pressing Escape. On mobile phones, it should be dismissible by tapping the cross button.

WHAT THIS MEANS IN PRACTICE

Tooltips must not auto-dismiss on a timer. Users must be able to move their cursor onto the tooltip to keep it open. They are trying to read it. For touch interfaces, use a 'toggletip' pattern: tap the icon to show a persistent overlay with a close button, not a hover-triggered disappearing popup. Also ensure overlays don't hide any vital information or block navigation elements.

ON NATIVE MOBILE

This criterion was written for hover states, which do not exist on touch screens. The mobile equivalent: any content revealed on tap or focus must remain visible until the user explicitly dismisses it. Auto-hiding toasts and snackbars fail this criterion  entirely for older users. If it disappears before the user has finished reading it, it might as well not exist.

So…Who Does what

DESIGNERS

• Design tooltips as persistent overlays with an explicit close (✕) button. Not a timed auto-dismiss.
• For touch interfaces, use a toggletip pattern: tap to open, tap ✕ or press Escape to close.
• Ensure tooltips don't cover adjacent content or navigation elements.
• If the tooltip needs to be dismissed by the user, the close button must be clearly marked and accessible.

CONTENT TEAM

• Write a tooltip copy that is complete and self-contained. Users must understand it without referring back to the triggering element.
• Keep tooltip text concise: if it needs more than 3–4 lines, consider a dedicated help page instead.
• Use plain language. Tooltips are help text, not legal copy.

ENGINEERING

• Keep tooltips visible when the user moves their cursor from the trigger onto the tooltip itself.
• Bind tooltip close to the Escape key.
• Ensure tooltip text is exposed to screen readers via aria-describedby.
• Never auto-dismiss on a timer shorter than the time needed to read the full content at a slow reading pace.
• Ensure tooltips do not obscure any controls or vital information at all text sizes.

The Broader Lesson

Help content exists because something in the design wasn't self-explanatory. If the help then disappears before you've finished reading it, you've replaced one problem with a worse one.

14. Descriptive Link Labels - WCAG 2.4.04 · Level A

Julie is reading a travel blog about Vietnam. The article has useful information, but at several points it says 'click here to book,' 'read more,' or 'learn more.' Click here to book . What, exactly? A hotel? A tour? She clicks one 'learn more' and lands on a newsletter signup. Another takes her to terms and conditions. She stops clicking the links entirely and switches to a different travel site.

WHAT THE GUIDELINE SAYS

The purpose of every link must be clear from the link text. 'Click here,' 'read more,' and 'learn more' are failures . They tell you nothing about where the link leads

WHAT THIS MEANS IN PRACTICE

Links on the UI are read by assistive technology exactly as written. If a link is named 'read more,' the destination is unknown. The link should contain the consequence of clicking or the destination. This is as much a copywriting decision as a design one. In the case described above, these links should have been ‘Sign up for Newsletter’, ‘Book a Consultation’, and ‘Terms and Conditions’.

So…Who Does what

DESIGNERS

• Create a design system rule that prohibits generic link text. Add a linting check to design reviews.
• Use card-link patterns where the entire card is tappable and the heading provides the link context.
• Annotate designs with the intended link label text. Never leave it to developers to guess.

CONTENT TEAM

• Rewrite every instance of 'click here,' 'read more,' and 'learn more' to describe destination or action.
• Every link label must make sense out of context. Imagine reading all the links on a page without the surrounding text.
• Good examples: 'Book your Ha Long Bay cruise,' 'Read our Vietnam travel guide,' 'Download the annual report (PDF, 2.4MB)'.

ENGINEERING

• Audit links during code review for generic text.
• Use aria-label to extend short link text when visual context is available but programmatic context is not.
• Example: <a aria-label='Read our Vietnam travel guide'>Read more</a>

The Broader Lesson

Links are promises. 'Click here' is a promise with no content. For elderly users already cautious about clicking online, an unexplained link is often a link that won't get clicked.

15. No Auto-Submit on Input - WCAG 3.2.2 · Level A

Mark is booking a flight on a comparison site. He selects 'business class' from the dropdown. The moment he selects it, the page reloads completely. He's back at the top of the results. All his previous filters . preferred airline, departure time, seat preference . have reset. He sets them all again. Selects 'direct only.' Page reloads again. He books through a different site.

WHAT THE GUIDELINE SAYS

Changing the setting of a UI component must not automatically cause a context change unless the user has been warned in advance.

WHAT THIS MEANS IN PRACTICE

Auto-navigation on dropdown selection is almost always a bad idea. Use an explicit 'Apply' or 'Search' button. Date pickers, filter panels, and preference dropdowns are the most frequent offenders.

So…Who Does what

DESIGNERS

• Never design auto-navigation on dropdown selection . always include an explicit 'Apply' or 'Search' button
• Document which interactions do and don't trigger context changes

CONTENT TEAM

• If an auto-submit is unavoidable, display a clear warning: 'Changing this setting will refresh the page'
• Write button labels that describe the consequence: 'Apply filters' not just 'Go'

ENGINEERING

• Remove all JS event listeners that trigger navigation on select element 'change' events
• Batch filter applications behind button submission
• Test all dropdowns to confirm no unexpected navigation occurs

The Broader Lesson

Mark made a selection to change one thing, and the system changed everything. Users should always feel in control. An interface that makes changes on their behalf, without warning, cannot be trusted.

16. Consistent Navigation - WCAG 3.2.3 · Level AA

Julie has gotten very comfortable with her banking app. She knows where everything is . accounts under 'My Money,' payments are the second item in the bottom bar, statements are under 'History.' She can navigate without thinking. Then the bank updates the app. 'Payments' is now the third item in the navigation . 'History' is now 'Activity' and has moved. Julie spends ten minutes finding the statements. Neither she nor Mark trust the app quite the same way afterwards.

WHAT THE GUIDELINE SAYS

Navigation that appears on multiple pages must appear in the same relative order every time.

WHAT THIS MEANS IN PRACTICE

Ensuring navigation items are in a logical and consistent place helps users with cognitive, visual and motor impairments locate signage faster. The design should help users predict where navigation items might be . and ensure they are available at the predicted location.

WHAT RESEARCH SAYS

Working memory capacity declines with age, meaning older users cannot hold a mental map of the interface the way younger users do. Consistent navigation is not a nicety — it is survival. Breadcrumbs and persistent landmark elements let users orient themselves without having to remember where they came from.[Halperin Ben Zvi, Smashing Magazine, 2023]

ON NATIVE MOBILE

On mobile, consistent navigation means bottom tab bars, side drawers, and top bars must stay in the same position and order on every screen. An app that hides the tab bar inside certain views — a common pattern in modals and full-screen flows — breaks the user's spatial model of the app. If navigation disappears, the user must work out where they are from scratch.

So…Who Does what

DESIGNERS

• Define and lock navigation order in the design system
• Treat any navigation structural change as a breaking change requiring design review
• Require a migration plan and user communication before any structural navigation change ships
• Whenever the navigation redesign is a must make sure that the new navigation is explicitly highlighted and users are informed with a tooltip or dismissible overlay.

CONTENT TEAM

• Navigation labels must be identical across all pages . never rename an item contextually
• If a navigation item is renamed as part of a rebrand, update it everywhere simultaneously

ENGINEERING

• Never conditionally reorder navigation items based on user state, feature flags, or A/B tests
• Lock navigation component order in code . implement order as a constant

The Broader Lesson

Consistency is respect. When Mark and Julie learn your navigation, they're investing attention in your system. Every time that system changes without warning, that investment is invalidated.

17. Consistent Icons - WCAG 3.2.4 · Level AA

Mark uses a health tracking app. On the home screen, 'add entry' is a blue circle with a plus. In the food section, it's a green square with a plus. In the exercise section, it's a white plus with no background. Three icons for the same action. The heart icon means three completely different things depending on where he is. He stopped trusting his instincts in this app. Every tap is now a guess.

WHAT THE GUIDELINE SAYS

Components with the same functionality must be identified consistently. The same action must always use the same icon, label, and interaction pattern throughout the product.

WHAT THIS MEANS IN PRACTICE

Use globally accepted icons for globally accepted meanings. The trash can icon means delete. The floppy disk means save. These are not arbitrary . They are learned conventions that should not be broken.

So…Who Does what

DESIGNERS

• Create a design system icon-to-function mapping table and enforce it . one icon, one meaning, always
• Prefer icon + text label over icon-only for all primary and secondary actions
• Use globally accepted icons for globally accepted functions: trash = delete, ✕ = close

CONTENT TEAM

• Write consistent button and icon labels across all screens . the same action must always have the same name

ENGINEERING

• Import icons exclusively from the design system library . never add ad-hoc icons
• Ensure all icon-only buttons have a consistent accessible name via aria-label

The Broader Lesson

Icons are a language. Languages need consistency to be meaningful. If the same icon means something different in every section, your icon vocabulary is useless. and the cost falls entirely on the user.

18. Consistent Help Access - WCAG 3.2.6 · Level A

Julie is transferring money to her niece in Belgium. She gets to a step she doesn't understand . Something about BIC codes and IBAN validation. She looks for a help button. Checks the header . nothing. Checks the footer of the form . nothing. Scrolls below . There's a tiny 'FAQ' link buried beneath three paragraphs of legal text. She taps it. It takes her to a general FAQ page. Not specific to bank transfers. She exits the app. Calls the helpline. Waits 12 minutes on hold.

WHAT THE GUIDELINE SAYS

Help mechanisms must appear in the same relative location on every page and be findable from wherever the user is, including inside forms.

WHAT THIS MEANS IN PRACTICE

Help should be available at a consistent place throughout the application. If users can't reach help, they abandon the task, make mistakes, or reach out to others. The design should help users predict where help will be, and ensure it's at the predicted location.

So…Who Does what

DESIGNERS

• Place a help button in the same location on every screen, Especially in critical operations like finance, healthcare and insurance.
• Design a floating help button for forms and checkout flows specifically
• Design contextual help: clicking help from within a specific form should surface relevant help

CONTENT TEAM

• Write help content that is contextual to the current screen or task . not a generic FAQ
• Write help headings that match the language users would use when stuck

ENGINEERING

• Implement help as a persistent, always-visible component
• Pass the current screen context to the help system so it surfaces relevant content first

The Broader Lesson

Being stuck is frustrating. Not being able to find help when you're stuck is demoralising. Many elderly users interpret 'I can't find the help button' as 'I'm not capable of using this product.'

19. Error Correction Instructions - WCAG 3.3.3 · Level AA

Mark is registering for a new medical portal. He fills in his date of birth the way he always does: 14/03/1958. He submits. An error appears: 'Invalid date.' That's all it says. Is the format wrong? Is there a typo? He has no way of knowing. He tries different formats. Eventually he tries ISO format.  1958-03-14 . and it works. He spent four minutes on a field that should have taken four seconds.

WHAT THE GUIDELINE SAYS

If an error is detected and a correction is known, it must be provided. 'Invalid date' is not a correction. 'Please enter your date of birth in DD/MM/YYYY format; for example, 14/03/1958' is a correction.

WHAT THIS MEANS IN PRACTICE

Make the expected data type and format visible to users before they make an error, not only after. The best error is the one the user never sees.

So…Who Does what

DESIGNERS

• Design error messages with two mandatory components: what went wrong + how to fix it
• For date fields: design a date picker to eliminate format errors entirely
• Design in-field format hints as permanent sub-label text

CONTENT TEAM

• Write correction instructions that are specific and actionable . never 'Invalid input' alone
• Good: 'Date of birth: Please enter as DD/MM/YYYY . for example, 14/03/1958'

ENGINEERING

• Trigger specific error messages based on validation type: format vs. range vs. required . each needs a different message
• For date, phone, and postcode fields: use formatted input masks that prevent format errors

The Broader Lesson

Mark knew his date of birth. The system knew the format was wrong. The only person who didn't know how to fix it was Mark - because the system didn't tell him. Error messages that give correction instructions convert failures into successes.

20. Confirmation Steps - WCAG 3.3.4 · Level AA

Julie is shopping online . a beautiful silk scarf for their trip to Hoi An. She adds it to her basket, reviews it, taps 'Place Order.' A screen appears: 'Your order has been placed.' Wait. She hadn't checked the delivery address. And she'd meant to apply a discount code. There's no cancel button. She emails customer service. The order has been dispatched. The scarf arrives at her friends' house in Brussels, two weeks after she's come home.

WHAT THE GUIDELINE SAYS

For legal, financial, or irreversible actions, there must be a way for users to review, correct, confirm, or reverse the action before it's completed.

WHAT THIS MEANS IN PRACTICE

During high-stakes interactions like legal, data entry and finance, the system needs to show all the information for review before actual submission. This allows users to correct mistakes during sensitive operations and aids users with limited memory spans.

ON NATIVE MOBILE

On mobile, this criterion carries additional weight. Password fields must permit paste — blocking paste breaks password managers. Biometric authentication (Face ID, fingerprint) is a fully valid WCAG-compliant alternative to cognitive tests. Apps must also support the platform autofill framework: iOS UITextContentType and Android autofillHints. Without these, the password manager the user trusts cannot help them.

So…Who Does what

DESIGNERS

• Design a review step before all purchases, deletions, account changes, and irreversible submissions
• For destructive actions: lead with the consequence: 'This will permanently delete your account'
• Include a 'cancel' path that is easy to find

CONTENT TEAM

• Write a review screen copy that summarises the action: 'You are about to place this order. Please check the details below.'
• Write 'undo' confirmation messages with a time limit: 'Message sent. Undo (5s)'

ENGINEERING

• Implement a review step before all API calls that create, delete, or irrevocably modify data
• Add optimistic rollback where technically feasible
• Do not allow double-submission . disable the submit button after first tap

The Broader Lesson

The review step is not friction. It's a service . the digital equivalent of a waiter reading back your order. It catches errors before they become problems. For the product, it reduces returns, refunds, and support contacts.

21. No Re-entry of Known Data - WCAG 3.3.7 · Level A

Mark is booking a hotel in Lisbon. He creates an account: name, email, phone number. Verifies his email. Logs in. The booking form asks for his name, email, and phone number again. He fills them in. The checkout form asks for his billing address. He enters it. The booking confirmation screen then asks for his address a third time . 'for documents to be mailed to.' He enters it again. At no point does the system say: 'We already have this . want to use what you gave us?'

WHAT THE GUIDELINE SAYS

Information already provided in the same session must not be required again.

WHAT THIS MEANS IN PRACTICE

Ask for one piece of information only once. Users relying on assistive agents may find it difficult and annoying to key in the same information again. If information has been provided earlier, auto-populate it . Don't ask again.

WHAT RESEARCH SAYS

Recognition over recall is a foundational principle for age-inclusive design. Users should never need to remember what they entered earlier in a flow. Michal Halperin Ben Zvi specifically calls this out as critical for older adults, whose working memory is under greater strain. Pre-filling known data and surfacing past choices keeps cognitive load low. [Halperin Ben Zvi, Smashing Magazine, 2023]

So…Who Does what

DESIGNERS

• Design forms with pre-populated fields for all data already collected in the current session
• Include a clearly visible 'same as above' checkbox for address fields
• Design multi-step forms so data carries forward automatically

CONTENT TEAM

• Write a copy that acknowledges pre-population: 'We've filled in your details from earlier. Please review and update if anything has changed.'

ENGINEERING

• Store form session state and pass data between steps automatically
• Retrieve and pre-populate profile data (name, email, address) into every form at load time
• Persist entered form data across accidental navigations and session expiry

The Broader Lesson

Asking someone to re-enter information they've already given says: 'We weren't paying attention.' For elderly users who may type slowly and find data entry tiring, it is more than inconvenient . It signals the product doesn't value their time.

Honourable Mentions

CHAPTER FIVE

The Good-to-Haves

These four guidelines don't apply to every product . but when they do and you haven't thought about them, the consequences can be significant.

22. Not More Than 3 Flashes Per Second - WCAG 2.3.1 · Level A

Mark was playing a mobile strategy game his grandson recommended . bright, animated, fast-paced. One evening, a dramatic in-game event triggered a rapidly flashing effect. Red, white, red, white. Quick and bright.

Mark didn't have a seizure. But he got a sudden headache, felt disoriented, and put the phone down immediately. He picked it up the next morning but found he didn't want to play the game anymore. Something about it felt unsafe.

WHAT THE GUIDELINE SAYS

Nothing in your product should flash more than three times per second. Rapid alternation between high-contrast colours can trigger photosensitive seizures. The combined flashing area should not be more than 341×256 CSS pixels . but as a general rule, flashing should always be avoided.

WHAT THIS MEANS IN PRACTICE

This concern was first identified in 1997 when a Pokémon episode was aired, resulting in 658 children being hospitalised with seizures, temporary blindness,  and dizziness. The principle applies to all digital products today . games, loading animations, notification indicators, and video content.

So…Who Does what

DESIGNERS

• Avoid strobe effects and rapid alternating colour animations in all motion design
• For all animations: provide a reduced-motion alternative design
• Prefer smooth, continuous animations over sharp, alternating ones

CONTENT TEAM

• Flag any video content that may contain rapid flashing for engineer review before publishing

ENGINEERING

• Respect the CSS prefers-reduced-motion media query in every animation
• Test all animations for flash rate compliance using PEAT (Photosensitive Epilepsy Analysis Tool)

23. Wait for Click (Up-Event Triggering) - WCAG 2.5.2 · Level A

Julie has occasionally triggered things she didn't mean to. She'll reach for one button and, as her slightly unsteady hand approaches the screen, something else fires before she's fully committed to the tap. Some apps trigger actions the moment your finger touches the screen . rather than waiting for you to lift it. If an action fires on press-down, there's no way to cancel by moving your finger away. If it fires on lift, you can change your mind mid-tap.

WHAT THE GUIDELINE SAYS

Actions triggered by pressing a pointer should fire on the release event (when you lift your finger), not the press event. Where down-event triggering is unavoidable, there must be a way to abort or reverse the action.

WHAT THIS MEANS IN PRACTICE

Users with tremors in their hands may accidentally tap on something they did not intend to activate. It is essential to be able to cancel a tapping action in high-stakes situations . purchases, deletions, submissions. The abort mechanism is: move your finger or mouse off the target before lifting.

So…Who Does what

DESIGNERS

• Specify up-event (pointer-release) triggering in all interactive component specs
• For destructive or financial actions: include a visual 'press and hold' confirmation pattern

CONTENT TEAM

• N/A . This is primarily a design and engineering concern

ENGINEERING

• Bind all click/tap actions to pointerup or touchend events . never pointerdown or touchstart
• For any irreversible action: add a short post-action undo window as a safety net

24. Alternative to Motion Input - WCAG 2.5.4 · Level A

Mark uses a step-counting app his doctor recommended. One update introduced a 'shake to dismiss' feature. Mark first discovered this when his phone was in his pocket during his morning walk. He came back to find the app had been dismissed several times and his step count was gone. A word puzzle game he enjoys introduced a 'tilt to navigate' mechanic. His hands aren't perfectly steady, and the game constantly registered movement he didn't intend. He stopped playing.

WHAT THE GUIDELINE SAYS

If functionality is triggered by device motion . shaking, tilting . there must be an alternative input method, and the motion input must be able to be disabled to prevent accidental activation.

WHAT THIS MEANS IN PRACTICE

The functions activated by motion could be difficult or impossible for users with tremors. Before implementing a shake or tilt feature, ask: if the tap alternative works just as well, why add the motion trigger?

So…Who Does what

DESIGNERS

• For every motion-triggered feature, design a visible tap/button equivalent
• Include a settings toggle to disable all motion-triggered features

CONTENT TEAM

• Label motion-alternative buttons clearly: 'Shake to undo' → 'Undo' button
• Write settings copy that explains what each motion feature does and how to disable it

ENGINEERING

• Implement all motion listeners alongside button/tap event alternatives . never motion-only
• Add a user preference to disable device-motion features entirely . store in user settings

25. Live Captions - WCAG 1.2.4 · Level AA

Julie had a video consultation with a specialist through the hospital's patient portal. The doctor spoke quickly and had an accent Julie found hard to follow. She asked him to repeat several things. She still wasn't sure she'd caught everything. At her next appointment, her GP mentioned the patient portal had a caption feature. Julie hadn't known. It was in a settings menu she'd never opened. 'They should make that more obvious,' she said. Her GP agreed.

WHAT THE GUIDELINE SAYS

Live audio content in video . webinars, video calls, live product demos . must have synchronised real-time captions.

WHAT THIS MEANS IN PRACTICE

This applies to telehealth platforms, financial advisory video calls, customer support video, and live shopping events. Real-time captioning must be surfaced prominently . not buried in settings where users who most need it are least likely to find it.

So…Who Does what

DESIGNERS

• Include a caption toggle button as a prominent UI element in all video call screens
• Design an onboarding prompt that surfaces the caption feature the first time a user enters a live video

CONTENT TEAM

• Write UI labels for the caption button in plain language: 'Turn on captions' not 'Enable CC'
• Provide a transcript download option for all recorded live sessions

ENGINEERING

• Integrate a real-time caption API: Google Cloud Speech-to-Text, AWS Transcribe, or equivalent
• Surface the caption toggle prominently . implement as a default-visible control, not a settings submenu
• For telehealth: ensure caption data is not retained beyond the session

The Broader Lesson

Telehealth is one of the fastest-growing digital services for the over-65 demographic. If Julie can't follow what her doctor is saying, that isn't just a usability problem. It's a healthcare risk.

Beyond The Checklist

CHAPTER FIVE

The Good-to-Haves

WCAG is a technical floor, not a ceiling. These practices come from research into how real people — older adults, people with ADHD, people with dyslexia, people encountering a product category for the first time — actually use mobile apps. None of them are in the standard. All of them matter.

---

LANGUAGE AND CLARITY

26. Use the same word for the same thing, every time

WCAG checks that icons look consistent but says nothing about language consistency. If your app says "Submit" on one screen, "Send" on another, and "Continue" on a third — all meaning the same action — users with ADHD, early cognitive decline, or low digital literacy will hesitate, second-guess, and often back out. This is especially disorienting in multi-step flows where users are already tracking several things at once. Pick one word. Own it everywhere.

[Stephens, UX Collective; COGA Working Group]

27. Jargon is a wall, not just an inconvenience

WCAG 3.1.5 covers reading difficulty — but only at the AAA level, and only as a measurable grade score. It says nothing about domain vocabulary. For an older adult encountering their first financial app or telehealth platform, words like "sync," "token," "dashboard," or "push notification" can cause abandonment — not confusion. Confusion implies they tried to understand it. Abandonment means they decided it was not for them. Write as if the reader has never used this category of app before. [Stephens, UX Collective; Halperin Ben Zvi & Yifrah, UX Collective]

28. Avoid metaphors, idioms, and figures of speech

Metaphors ("the cloud," "your wallet," "threads") and idioms ("go live," "sync up") require cultural and domain fluency that cannot be assumed. For older adults and for many neurodiverse users who process language literally, these phrases create invisible friction. The user reads the words and understands them individually. The combined meaning is a different matter. Plain language means using the word for the thing, not a clever shorthand for it.

[Stephens, UX Collective; Halperin Ben Zvi & Yifrah, UX Collective]

---

COGNITIVE FLOW

29. One idea per screen

Progressive disclosure is not in WCAG. Showing everything at once — all settings, all options, all form fields — is the fastest way to lose an older user or someone with ADHD. Each screen should have one clear purpose and one primary action. The rest can wait. This is not about dumbing down. It is about respecting that working memory has limits, and those limits shrink with age and vary with neurodivergence. A dense screen is not a complete screen. It is a screen that does not get completed. [Halperin Ben Zvi, Smashing Magazine, 2023]

30. Reduce the actions required, not just the complexity

WCAG deals with structure and information. It does not count how many taps something takes. Research shows older adults benefit significantly from minimising the number of required steps — autofill addresses, save payment details, remember preferences, and pre-select the most common option. Every unnecessary tap is a failure point. Every field that could have been pre-filled and wasn't is a question that the user has to answer twice. Fewer actions means more completed tasks. [Halperin Ben Zvi, Smashing Magazine, 2023]

31. Let users see where they left off

WCAG says nothing about session continuity. For older users and those with ADHD, the question "what was I doing?" is a real barrier. An app that resumes where you left off; an open form, an unfinished booking, a half-read article — removes the tax of reorientation. This is especially important in multi-session flows like onboarding, insurance applications, or health check-ins, where interruptions are common and restarting from scratch causes permanent abandonment.

[Halperin Ben Zvi, Smashing Magazine, 2023]

32. Left-align body text. Limit line length.

WCAG 1.4.12 covers text spacing adjustments but says nothing about typographic defaults. Fully justified text creates uneven word spacing that slows reading for users with dyslexia and low vision. Lines longer than 65 characters increase the effort of returning to the start of the next line — a cost that compounds when text is small or the reader is fatigued. These are not aesthetic preferences. They are legibility decisions with measurable effects on reading speed and comprehension. [British Dyslexia Association; Plain Language research]

---

EMOTIONAL SAFETY

33. Explain what will happen before asking for it

WCAG covers error recovery but not pre-action explanation. Before any significant action - deleting, submitting, paying - the interface should tell the user what happens next in plain language, before the confirmation tap. "This will remove your card from all future orders" is not a warning. It is a courtesy that reduces anxiety and prevents the panic- cancel that many older and neurodiverse users experience after accidental commits. Say what will happen. Then ask.

[Halperin Ben Zvi & Yifrah, UX Collective]

34. Make undo more powerful than "Are you sure?"

WCAG 3.3.4 requires a way to reverse or confirm high-stakes actions. But the modal dialog approach — "Are you sure? Yes / Cancel" — is a poor pattern for older and neurodiverse users. It interrupts the flow, adds cognitive overhead, and forces a decision under pressure. A better pattern: let the action happen, then offer a clearly visible, persistent undo option. The user feels in control. They are not being interrogated before they can proceed. Undo is more graceful than warning.

[Halperin Ben Zvi & Yifrah, UX Collective; COGA Working Group]

35. Never make users feel watched or compared

WCAG is silent on this. Research on older adult digital anxiety shows that interfaces displaying real-time performance metrics, comparison data, or any hint of surveillance cause disengagement and avoidance. Streaks, leaderboards, and public scores actively harm this audience. If you include motivational elements, make them private, personal, and tied to the user's own progress — not to anyone else's. Progress relative to yourself is encouraging. Progress relative to "most users" is a measure of inadequacy.  [Stephens, UX Collective; COGA Working Group]

---

TRUST

36. Build trust before you ask for anything

WCAG says nothing about trust. Research shows older adults are significantly more likely to abandon an app if they are not sure it is legitimate. A visible privacy policy link, a real phone number, a human name, and a plain-English "about this app" explanation do more for conversion with older users than any UI optimization. Trust is not a marketing function. For this audience, it is the precondition for use. Without it, the rest of the design is irrelevant. [Stephens, UX Collective]

37. Write privacy in plain English, at the point of collection

A generic privacy policy link at the bottom of a form does not communicate anything. Research on older adult trust shows that the moment of data collection is when explanation matters most. A one-sentence plain language note next to each data point - "We use your phone number to send a login code. We do not share it." - is more effective than any privacy document. Specific. Present. In plain English. At the moment it is needed.  [Stephens, UX Collective]

Conclusion

CONCLUSION

Design as an Act of Respect

Mark and Julie don't think of themselves as elderly. Most people don't. Not until circumstances force the point.

Mark thinks of himself as an experienced professional who recently gained the freedom to travel more. Julie thinks of herself as someone who's finally getting to spend time on things she loves. They both happen to be 65 and 67 years old. They have the eyes, ears, hands, and cognitive patterns of people who have lived full and complex lives.

When an app is built for them, truly built with their needs in mind, they don't feel accommodated. They don't feel like a special case. They feel like the product was made for someone like them. And that feeling, of being understood, respected, and served well, is what turns a user into a loyal customer.

The 25 guidelines in this book are not about compliance. They're about Mark reaching his investment account from a poolside in Phuket without wanting to throw his phone into the water. They're about Julie watching a cooking tutorial from beginning to end, coming away having learned something wonderful.

Every single one of these guidelines describes a real pain that real people experience every day. And every single one of them is fixable. Build one product, thoughtfully, for everyone.

Good design for the elderly is just good design. The curb cut that helps a wheelchair user also helps a parent with a pram, a cyclist, and a delivery worker. The caption that helps someone with hearing loss also helps someone on a noisy train. The large tap target that helps someone with a tremor also helps someone using their phone in the rain.

Every improvement you make for Mark and Julie makes the product better for everyone. That is the business case, the ethical case, and the design case all in one.

They deserve apps that WORK. So does everyone!

Let’s build them that way.

References and Downloads

APPENDIX

Reference and Downloads

List of downloads

The Elderly-friendly checklist

Other Resources on Accessibility

https://doublea11y.com/resources/ 

References

This book draws on original research and practitioner writing from the following sources. I am grateful to these authors for advancing the field of age-inclusive design.

Michal Halperin Ben Zvi

"Designing Age-Inclusive Products"

Smashing Magazine, 2023. smashingmagazine.com 

Michal Halperin Ben Zvi & Kinneret Yifrah

"Better Microcopy for Older Adults"

UX Collective. uxdesign.cc 

Becca Selah

"What You Can Learn From Older Adults About Accessible Design"

Salesforce / UX of Aging. medium.com 

Matthew Stephens

"Designing for Older Audiences: Checklist + Best Practices"

UX Collective. uxdesign.cc 

World Health Organization

Ageing and Health: Key Facts

who.int/news-room/fact-sheets/detail/ageing-and-health 

Web Content Accessibility Guidelines (WCAG) 2.1

W3C Recommendation

w3.org/TR/WCAG21/

WCAG2Mobile

W3C’s draft on using WCAG for the mobile apps

https://www.w3.org/TR/wcag2mobile-22/