Calorie tracker accessibility checklist: test the logging flow

Complete the meal, including a correction

Start with the task you want to finish: add a meal, check that it saved and change the amount. If any part is hard to find, hear or reach, include it in the comparison. A readable first screen is not enough when the next action is blocked.

Begin with a repeatable route. Open the daily view, add a food and calorie value, save it, edit it, remove it, choose a past day, and reuse a recent item.

Repeat the route offline, then reconnect. A feature tour can miss hand-offs where focus disappears, labels become ambiguous, or a status changes silently.

For each step, note what you expected and where the task became difficult. Include the focused control, spoken label and result of saving. That gives you a specific issue to ask about or report rather than having to say only that the app is awkward.

WCAG 2.2 Level AA is a useful design and engineering baseline, including for principles such as reflow, contrast, target size, focus, names and roles, and status messages. A native app still needs interpretation through the iOS and Android accessibility APIs and real assistive-technology testing. A checklist supports that work; it is not an independent certification.

• Record the device, operating-system version, app build, text-size setting, display setting, and assistive technology used.
• Test a successful entry, a validation error, an offline save, a reconnect, and a rejected change.
• Keep the food names and calorie values synthetic so the evidence contains no personal ledger data.
• Retest the same route after a fix instead of checking only the individual control that changed.

Hear which meal you’re editing and whether it saved

With VoiceOver or TalkBack running, move through the day, its entries and the add control. Check whether the spoken names make sense without needing to see their position on the screen. Try the whole entry and correction rather than stopping at the first labelled button.

Every interactive element needs a concise name, the correct role, and an accurate state or value. “Add food” is useful; “plus button” merely describes the artwork.

A day selector should expose the selected date, an editable calorie field should identify its purpose and current value, and repeated delete controls should make clear which entry they affect. Do not bake words such as “button” or “selected” into a label when the native role or state already supplies them.

Complete data entry with the screen reader running. Confirm that labels remain associated with fields, validation explains both the problem and how to correct it, the on-screen keyboard does not strand focus, and dismissing a sheet returns focus somewhere predictable. Then use screen-reader actions to edit or remove an entry without relying on a swipe gesture that has no accessible equivalent.

After saving, check whether you can tell if the entry is saved locally, pending or rejected. Those results need different actions. You shouldn’t have to search the list to discover a status that changed silently.

Trigger each state and confirm that it is announced at the right time without moving focus unnecessarily or speaking the same message in a loop. A tick that silently changes colour does not tell a screen-reader user whether the entry is local, synchronised, or refused.

• Labels make sense out of context and distinguish repeated actions.
• Headings, groups, fields, buttons, and selected states use appropriate native semantics.
• Focus enters and leaves sheets, alerts, and validation summaries in a predictable place.
• Dynamic totals and save states are announced without interrupting required input.
• VoiceOver and TalkBack communicate equivalent meaning, even when their gestures and phrasing differ.

Keep every control usable with larger text

Increase the system text size and try the same meal on a small supported screen. You still need the food name, amount, errors and Save control in full. A rearranged layout is fine if the information and actions remain available.

Look for clipped food names, calorie values that collide with controls, buttons reduced to a single mysterious letter, and fixed footers covering the field or error that currently has focus. Cards and summary rows may need to grow vertically or stack. Horizontal scrolling should not become the price of reading ordinary labels, and text should not be replaced by unexplained icons merely to keep a row tidy.

Open the software keyboard while the largest text is active. The focused field, its visible label, its error message, and the save action should remain reachable. Rotate the device if the app supports rotation and revisit sheets, alerts, empty states, long translated strings, and a day containing enough entries to scroll.

Reflow also includes what happens after state changes. If an error inserts another line or a pending badge becomes a longer rejected message, the layout should adapt without hiding content or throwing focus to the top. Pair screenshots with task notes because a still image cannot prove reading order or focus behaviour.

Edit without a precise tap or swipe

If you use an external keyboard or switch access, try reaching the same controls you would need by touch. Add a meal, change the day and correct an amount. Check where focus goes and whether each action is available.

Focus should be visible, ordered, and confined to elements that can actually be used. A decorative card should not take a stop, while an icon-only edit action should not disappear from the sequence.

Check that all touch functionality has a selectable control or accessible action. Dragging, swiping, long-pressing, and tapping a particular corner can be convenient additions, but they cannot be the only route to edit, delete, change a date, close a sheet, or reveal status detail. Escape or platform-appropriate back behaviour should dismiss temporary surfaces without discarding work unexpectedly.

Target size matters even when keyboard access is sound. For Haps mobile work, the project requirement is a minimum 44 by 44 point tap area.

Inspect the active area rather than the visible artwork: a small icon can sit inside a larger target, while a large-looking row can still expose only a narrow tappable patch. Check spacing between adjacent actions so a correction does not become a deletion through one slightly inaccurate tap.

Switch scanning adds another useful test. Each actionable item should be highlighted once, groups should not trap the scan, and the user should be able to add and correct an entry without an unreasonable number of stops.

Note where the route takes too many stops or repeatedly loses your place. An action can be reachable and still take a lot of effort to repeat at every meal. Include that effort when choosing an app or reporting a barrier.

• A visible focus indicator survives light and dark surfaces.
• Focus order follows the task rather than the component creation order.
• Every gesture has a selectable control or accessible action.
• Interactive targets meet the project minimum and do not overlap.
• A switch user can complete, correct, and cancel the logging task without a focus trap.

Tell save states apart without colour or animation

If you can’t distinguish saved, pending and rejected entries without colour, you may not know whether to wait or take action. Turn on greyscale or a colour filter and read the same day again. Look for text or another persistent cue carrying the status.

Check contrast in the screens you actually use, including errors, placeholder text, selected controls and pending entries. A clear button in an example screen does not settle whether the same button remains readable over a different background or while pressed.

Enable the operating system setting for reduced motion and repeat the flow. Decorative transitions should reduce or stop, while the underlying state change remains clear.

A saved entry still needs understandable feedback when a bounce, pulse, slide, or progress animation is removed. Avoid replacing motion with a flash or sudden focus jump that creates a different barrier.

Try the settings you use together. Larger text, reduced motion, a screen reader and increased contrast can all affect the same save or edit. Check the complete task in that combination rather than assuming separate checks cover it.

Ask about the task you need to complete

Ask which phones, builds and assistive technologies were used to check the app. Explain the task you need to complete, especially if you have already found a barrier. Automated results alone do not show that a meal can be entered and corrected with your setup.

For an app on both platforms, check the outcome on the phone you intend to use. You need to create and correct an entry, understand its date and status, and recover from an error. VoiceOver and TalkBack may use different gestures while communicating the same information.

Haps is available on iPhone through the App Store and on Android through Google Play. Its project requirement and design baseline is WCAG 2.2 Level AA, applied through native accessibility APIs with equivalent VoiceOver and TalkBack outcomes. The baseline also requires keyboard and switch access, text scaling and reflow, sufficient contrast, non-colour cues, 44 by 44 point targets, reduced motion, and accessible validation and status feedback.

That statement describes what Haps is required to meet, not independently certified conformance and not proof that every release candidate has passed. Required validation includes manual VoiceOver and TalkBack passes, maximum supported text size, display zoom, external keyboard or switch access, contrast or colour-filter settings, reduced motion, and device testing of the affected flow. Release evidence must record the actual results and unresolved gaps.

Use the Haps support route if you want to ask what has been validated or report an accessibility barrier. Haps records calorie values and daily target comparisons; it does not determine whether a value or target is accurate or suitable for a person, and this checklist is a usability review rather than health or nutrition advice.

Common questions