Accessibility testing intimidated me at first because it sounded like specialist territory: audits, compliance reports, expert reviewers. Then I turned on a screen reader and found three real bugs in ten minutes. Most of the highest-impact accessibility problems do not need an expert to find them; they need a QA engineer willing to spend fifteen minutes with the phone in hand, on every feature, every time.
The fifteen-minute screen reader pass
Turn on TalkBack on Android or VoiceOver on iOS and swipe through the screen you are testing. Three questions: does every interactive control announce a meaningful label, does the announcement order match the visual order, and can you complete the core flow end to end without looking at the screen? The most common failure is the unlabeled icon button, which a screen reader announces as just "button." For a blind user, that is a locked door. Decorative images should be skipped entirely; informative ones need a real description.
Touch targets and contrast
Platform guidelines put minimum touch targets around 44 points on iOS and 48dp on Android, and the most frequent offenders are tiny close buttons on modals and icon rows packed too tightly. If I keep missing a tap on a real device, that is a bug regardless of what the spec says. For contrast, the WCAG baseline is a 4.5:1 ratio for normal text, and I do not trust my eyes on this one; light gray placeholder text on white passes a glance and fails a checker constantly.
Font scaling and focus order
Set the device font size to maximum and walk the main flows. This one setting exposes truncated labels, overlapping text, buttons pushed off screen, and fixed-height containers that clip their content. It is also the accessibility check most likely to affect everyone, since a huge share of users bump their font size up at least one notch. Focus order matters on the same pass: navigation should move logically from start to end, top to bottom. Testing RTL builds taught me to be careful with the word "start," because in an Arabic layout start means right, and I have caught focus orders that marched left to right across a right-to-left screen.
Labels are cheap to fix and expensive to skip
Content descriptions on Android and accessibility labels on iOS take a developer minutes to add, which makes them easy wins to report. Form fields deserve extra attention: the field should announce its label and current value, and when validation fails, the error needs to be announced, not just painted red. A red border is invisible to a screen reader user and nearly invisible to a colorblind one, which makes it two bugs in one control.
Folding accessibility testing into regular passes
The classic mistake is treating accessibility testing as a separate phase that never actually gets scheduled. What works for me is folding it into passes I already do: every new feature gets the screen reader walk, the maximum font check, and a label review before it ships, as ordinary checklist items sitting next to the functional cases. Some of it can even be automated; a UI test can assert that critical buttons expose accessibility identifiers, though the screen reader walk itself stays human. Ten extra minutes per feature, and accessibility stops being a launch-week panic.