An Android text size testing brief defines whether someone can still read and operate a business app after changing the phone's text settings. A design can look comfortable at its default size while hiding a price, cutting off a field label or pushing a confirmation button outside the usable area when text grows.
Include this discussion when commissioning Android app development in Kenya. The useful requirement is not that every screen remains visually identical. It is that the agreed user tasks remain understandable and operable under the settings and devices included in the test scope.
This guide is a focused acceptance worksheet for text and layout behaviour. It is not a complete accessibility audit, a legal assessment or a guarantee about every Android device. The examples are illustrative and should be adapted to the actual app workflow.
Start with tasks that depend on readable information
Choose the important journeys before collecting screenshots. A customer might need to understand an amount, correct an address or review a request before submitting it. A staff member might need to identify the right job among similar entries. These tasks reveal whether information remains available when the layout changes.
For each journey, list the screens and the text needed to complete it. Include labels, instructions, validation messages, amounts and action names. A large headline is not the only content that matters; a small explanation beside a required field can determine whether someone knows how to continue.
Record the expected outcome in plain language. The reviewer should be able to say whether the task is possible without guessing what hidden text means. Keep that outcome separate from aesthetic preferences about whether a card has become taller or a paragraph now wraps onto another line.
Agree the device and setting matrix
Ask the developer to propose representative supported devices and Android versions. Combine that with the business's actual audience information where available. Do not claim that one expensive demonstration phone represents every device your customers or staff may use.
Android's platform guidance describes nonlinear font scaling up to 200% starting with Android 14. Use that as a reason to include real system text-setting changes in the evaluation. Ask the implementation team how the app responds within its supported environment rather than assuming a fixed design export demonstrates scaling support.
Write the chosen settings into a small matrix. Record device, Android version, display setting, text setting and app build. Where an option is unavailable on a particular device, label it accordingly. Comparable evidence requires knowing what was tested, not simply naming a screenshot large text.
Use content that exposes real layout demands
Prepare harmless sample records containing long names, multi-line addresses and realistic reference formats. Short placeholder text can conceal clipping or overlap that appears only after the app receives ordinary business information. Include both empty and populated states where the layout differs.
Choose an amount with enough digits to exercise the actual summary design, without presenting it as a real price or transaction. Keep the amount, currency label and action understandable together. A screen that displays the number but hides the explanation has not necessarily preserved the decision the user needs to make.
Include long button labels and messages in the languages the project supports. Translation can change layout demands, so a successful short English label does not establish that every approved language behaves correctly. Use the actual reviewed wording where possible rather than inventing abbreviations purely to make the demonstration fit.
Check forms with the keyboard visible
Open an important form, change the text setting and review it while the keyboard is on screen. Confirm that the active field, its label and any relevant validation message can be understood. The person should be able to move through the form without losing the instruction explaining what to enter.
Try correcting an error rather than testing only a successful path. A multi-line validation message may expose a layout issue that an empty field does not. Review whether the error remains associated with the relevant input and whether the next action is clear after the correction.
Check confirmation screens separately. A readable form is not enough if the final summary hides a quantity, address or consent choice. Agree the fields someone must review before submitting, and use controlled test arrangements for any action that would otherwise create a live record or send a message.
Review lists, cards and navigation
Look at repeated components as well as full screens. A record card may contain a title, status and action within a compact space. At larger text sizes, those elements may need more room. The review should establish whether their relationship remains understandable rather than insisting on the original fixed card height.
For lookup journeys, coordinate with the Android record search brief. A search result must still reveal enough permitted information to distinguish it from similar records. Enlarging text should not turn several meaningful results into identical truncated labels.
Check navigation labels and return paths. A person should understand which section is active and how to leave a detail screen. If icons are used, evaluate their meaning and accessible presentation through the project's broader review process rather than assuming that removing all text solves a space problem.
Test dialogs and temporary messages
Open confirmation dialogs, selection panels and error messages under the chosen settings. These smaller surfaces can contain important decisions within limited space. Confirm that the full question and available actions remain reachable and that the meaning of each action is clear.
Distinguish layout faults from brief message timing. Someone may need more time to read a longer explanation. Record whether the information remains available through an appropriate route instead of relying solely on a momentary notification that disappears before the person can act.
Use an interrupted or failed operation as a scenario. The app should explain the current state without overlapping controls or concealing the recovery action. Do not approve a design only because its ideal success screen looks tidy at the largest setting.
Record issues as reproducible observations
For each finding, save the task, starting state, setting combination, action and observed barrier. Attach a screenshot when it helps, using controlled data. A note that says the screen looks wrong gives the developer less useful information than identifying which instruction was clipped and how it prevented the task.
Separate a shared component fault from a single unusual record. If the same action bar appears throughout the app, ask the team to review its other uses after a correction. Fixing the sample screen alone may leave the same barrier elsewhere.
Retest the original scenario after the change. Keep the result tied to a build so the business can tell which evidence applies to the release being accepted. Do not label an issue resolved solely because someone supplied a redesigned image without demonstrating the implemented interaction.
Include readable-content ownership in handover
Decide who approves future wording and when a change needs another layout review. A longer status label or new language can affect a previously accepted component. Give editors and product owners examples of content that requires checking rather than a blanket instruction never to change text.
Keep the setting matrix and issue register with release documentation. Use the Android app updates brief to connect meaningful interface changes to acceptance and support. A passed review of an older build should not automatically stand in for evidence about a later redesign.
When comparing proposals, ask which tasks, settings and correction rounds are included. Review Mocky's app portfolio as background, then request an app development quotation based on your supported devices and acceptance needs. Avoid treating attractive default-size screenshots as the complete usability scope.
Frequently asked questions
Does larger text mean every screen must keep its original shape?
No. Agree the important information and tasks, then review how the implemented layout adapts. More wrapping or scrolling may be appropriate when the content and controls remain understandable.
Is one screenshot at the largest setting enough?
It is useful evidence for one state. Review complete tasks, error states and representative settings rather than treating one image as coverage of the whole app.
Can we shorten every label to avoid layout changes?
Only when the revised wording still communicates the required meaning. Hiding essential instructions or replacing clear labels with unexplained abbreviations does not resolve the underlying task problem.
Does this checklist certify accessibility?
No. It addresses a focused part of acceptance testing. Agree a broader evaluation scope with the appropriate team where the project requires one.
