A senior care app is judged at the largest text size.

One record, two front doors

Write the two users down before you design anything, because their screens share almost nothing. The older adult gets few screens, one action per screen, and type that survives being scaled up. No red badges, no unread counts, nothing that implies she is behind on something. The family gets density: today, this week, who did what, and a notification when something slips.

Underneath both sits one record per person: a routine, a set of contacts, a visit log, a note history. When both sides read and write the same record, an argument about whether Dad took his tablets becomes a timestamp instead of a phone call. The routine is where most of the detail lives, and it grows into its own product quickly. That is why a medication tracking app is often built first, with the care app growing around it.

The third user, if there is one, is a paid carer, and they will not create an account to help you. Anything that needs a login from somebody paid by the hour does not get filled in. Either design a link that opens straight to today's visit, or design the carer out of the app and let the family record the visit instead.

What a screen owes the reader at 200 percent text

The published bar is specific. WCAG 2.2 asks that text can be resized without assistive technology up to 200 percent without loss of content or functionality. That is not advice about font choice. It means that at double size every word is still there, nothing is cut off at an edge, and every control still works. Most app layouts fail it quietly, because the text grows and the box around the text does not.

Contrast has a number too: 4.5 to 1 for normal text and 3 to 1 for large text. Light grey on white is the most common failure in this category. It is also the one that makes an app useless to exactly the person it was built for. Targets need room as well. Android's own accessibility guidance asks for a focusable area of at least 48dp by 48dp, and larger is better for a hand that is not steady.

So does any of this come free? We looked, because the question comes up about generated apps. A Newly build is a React Native and Expo project. React Native's Text component carries an allowFontScaling prop, which in the framework's own words specifies whether fonts should scale to respect Text Size accessibility settings. It defaults to true, and the starter project these builds begin from never switches it off. So yes: text follows the phone's own setting by default. That same starter also ships a button fixed at 44 pixels tall around 16 pixel text, another at 50, and a tab row at 60. The text scales. Those boxes do not. Scaling is on by default. Surviving it is still something you have to check.

Check it the cheap way. Put a real phone at its largest text size, open every screen, and look for three things: words cut off at a container edge, two lines of a label overlapping, and a button whose text is visible but whose tap area has quietly shrunk. Replace fixed heights with minimum heights and padding. That single change fixes most of what you find.

W3C, WCAG 2.2 success criterion 1.4.4 Resize text

A check-in is a promise about what happens when nobody answers

A daily check-in is trivial to build and easy to get wrong. The button is not the feature. The feature is the ladder that runs when the button is not pressed: a second prompt twenty minutes later, then a notification to the first contact, then to a second contact, then a plain instruction to phone. Write that ladder out in sentences before you write code. It is the part of an aging in place app that everyone will judge.

Every rung needs a time, a named person and a fallback. Quiet hours matter, because a reminder at seven in the morning is helpful and the same reminder at eleven at night is frightening. Time zones matter too. Family are often somewhere else, so the schedule belongs to the older adult while the alerts belong to whoever receives them. And a missed check-in is not an emergency on its own. People go out. The app should report what it knows and not what it fears.

All of it rests on one assumption worth testing early: that the check-in reminder that has to arrive actually arrives. The phone may be in low power mode, with notifications half muted and the app closed since Tuesday. That is a delivery problem rather than a scheduling one, and it is worth understanding before you design a ladder on top of it.

What you are allowed to write down about another adult

People assume HIPAA covers anything with health in it. It does not. The regulation defines a covered entity as a health plan, a health care clearinghouse, or a health care provider who transmits health information in electronic form in connection with a transaction covered by the rules. A son building an app to track his mother's appointments is none of those, and neither is most of what gets sold as an elder care app.

That does not mean nothing applies. The Federal Trade Commission's Health Breach Notification Rule, 16 CFR Part 318, reaches vendors of personal health records and related entities that are outside HIPAA and are not business associates of a covered entity. It requires notification after a breach of unsecured identifiable health records. If you hold health information about other people's families, read that part before you launch. If you are an agency rather than a family, the picture changes again, and a home health care app carries obligations a household tool does not.

Put consent in the product, not in a policy page. The older adult should be able to open one screen, see every person who can read her record, and remove one of them. Capacity changes over time and so do families, so a share granted once and never reviewed is an argument waiting to happen. Log who changed what and when as well. A care record whose history you cannot reconstruct is not evidence of anything.

45 CFR 160.103, definition of covered entity