Size the interaction area deliberately
Android accessibility guidance recommends touch targets of at least 48 × 48 dp for interactive elements. Padding or an appropriately implemented touch region can enlarge the target without making the icon itself oversized.
Check adjacent controls. Enlarged targets should not overlap in a way that makes the activated action unpredictable. Test list rows, small close buttons, overflow menus and inline icon actions on a physical device.
Measure contrast by content type
For text, WCAG's common AA contrast thresholds are 4.5:1 for normal text and 3:1 for qualifying large text. Relevant non-text controls and visual indicators have their own contrast requirements and exceptions. Do not apply a single ratio indiscriminately to every decorative pixel.
| State | Common missed issue |
|---|---|
| Placeholder or secondary text | Too faint to read against a light surface |
| Focus/selection | State communicated only by a subtle color shift |
| Dark theme | Colors copied from light mode without remeasurement |
| Error | Red color without a text explanation |
| Image background | Contrast varies beneath the label |
Test scale and semantics together
Use large font and display settings, then check wrapping and control reachability. A label that technically meets contrast but is clipped to two unreadable characters does not solve the task.
Verify that the screen reader announces the action and state. Increasing the visual target cannot repair an unnamed button.
Keep platform units separate
Android dp and CSS pixels are not interchangeable units for blindly transferring numeric requirements. WCAG 2.2's web target-size criteria also have specific thresholds and exceptions distinct from Android's design recommendation.
APKLint's Accessibility Checker can support a review, but measurements and task testing still need the actual UI. Use Android's accessible-app guidance, testing tools and WCAG 2.2 to document the standard and method used. Fix the source components so the improvement survives the next screen redesign.
Measure the hit area of two neighboring actions
Imagine a list row with separate edit and delete icons. Enlarging each icon's touch region can improve usability, but the regions must still select the intended action consistently. Test near each edge and in the space between them on a supported device. A small visual icon can have an adequate target, while a large background can still contain a surprisingly small clickable area.
The Android accessibility guidance provides platform recommendations. Keep measurements in the units appropriate to the implementation and inspect the actual clickable bounds. A screenshot's pixel count alone does not establish the density-independent interaction area on the device.
Review the colors after selection and after an error
Use the component's actual foreground and background in each relevant state. A dark label on a white card can become unreadable when the selected state places it on a saturated brand color. A focus outline or error indicator also needs to remain understandable against its surrounding surface.
For text, distinguish normal from qualifying large text when applying the chosen contrast criterion. Review non-text indicators under their applicable criterion rather than treating all pixels as text. Decorative elements and disabled controls can have different treatment, but an essential status should not be hidden behind a convenient exception.
Change to dark theme and repeat the measurement. Then enlarge text and inspect wrapping, clipping and the relationship between each label and action. A mathematically adequate color pair does not make a clipped label useful, and a visible icon does not provide an accessible name by itself.
Test a non-color cue for selected, failed and complete states. Pair a meaningful label, shape or symbol with the color so a user does not need to distinguish two similar hues to understand the outcome. Ensure a screen reader receives the same state information.
After repairing the shared component, revisit representative screens that use it. Different backgrounds, neighboring controls and text lengths can reveal a regression not visible in the original example. Record both the measured values and the completed interaction task, keeping the numerical check connected to the user's actual experience.
Sources and further reading
- Android Developers: Accessibility principles
- Android Developers: Test accessibility
- W3C: Web Content Accessibility Guidelines 2.2
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
