Calorie tracker accessibility checklist: test the logging flow

Test the task, not the accessibility menu

A logging screen can pass a colour check and be impossible to use. The test starts when someone must add breakfast, correct the value, lose the connection, and work out whether the entry saved.

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.

Write down the expected result for each step: what is visible, what receives focus, what a screen reader says, and whether the action works without a precise tap or custom gesture. This turns “seems accessible” into reproducible evidence.

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.

Listen to the whole logging flow with a screen reader

Turn on VoiceOver or TalkBack before opening the flow. Navigate by swiping through elements rather than hunting by touch, and listen for a logical order from the day heading and calorie summary to entries and the add action. Visual proximity does not guarantee a sensible spoken sequence.

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.

Status feedback is the part a static audit tends to miss. Pending, saved, rejected, retried, and rolled back are different outcomes.

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.

Increase text until the layout has to tell the truth

Default text size is the showroom model. Increase the system text setting through the largest size the app supports, enable display zoom where available, and repeat the logging route on a small supported screen. The goal is not to preserve the original composition; it is to preserve the information and the task.

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.

Leave precision tapping out of the acceptance criteria

Now put the touchscreen aside. Connect an external keyboard or configure switch access, then move through every control in the same logging route.

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.

Record the count when a common action feels laborious. “Technically reachable” can still describe a miserable recurring task.

• 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.

Remove colour and motion as sources of essential meaning

Calorie trackers often compress a busy day into colour: green for saved, amber for pending, red for rejected, and another shade for calories over target. Turn on greyscale or a colour filter and inspect every one of those states. Text, an icon with an accessible name, shape, or another persistent cue should carry the distinction; colour can reinforce it but cannot do the job alone.

Measure contrast for text, essential icons, input boundaries, focus indicators, and status treatments in each theme and state. Do not test only the pristine component sheet. Disabled controls, placeholder text, validation messages, charts, pressed states, and content shown over images or tinted cards are where comfortable ratios tend to evaporate.

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.

Finally, test the combination: large text, increased contrast, reduced motion, and a screen reader or switch. Accessibility settings do not arrive one at a time in real use. A fix that works only while every other setting remains at its default has not survived the logging flow yet.

Ask for evidence, then judge Haps by the same checklist

A useful product comparison separates a requirement from a verified result. Ask which devices and builds were tested, which assistive technologies were used, which failures remain open, and whether disabled people participated in evaluation. Automated scanners and component tests can find defects, but they do not prove that a person can complete the workflow.

For cross-platform apps, “accessible on mobile” is too vague. Require the same meaningful outcome on iPhone and Android: the entry can be created and corrected, the date and calorie state can be understood, errors can be recovered from, and pending, saved, or rejected work can be distinguished. VoiceOver and TalkBack do not need identical words or navigation mechanics, but neither platform should receive a second-class task.

Haps is preparing for its first public release on iPhone and Android and is not currently available for public installation. 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