Native or cross-platform: deciding on evidence rather than preference
Both approaches build excellent products. The decision follows device capability requirements, team composition and roadmap shape.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Standard controls arrive accessible; custom ones do not.
- Icon-only buttons without labels are the most common failure.
- Support dynamic type and test at the largest text sizes.
- Navigate with VoiceOver and TalkBack, screen off.
Use standard controls where you can
Platform controls come with accessibility behaviour already implemented: labels, traits, focus order and gesture support. Custom controls start with none of it.
When a custom control is genuinely necessary, budget for the accessibility work explicitly rather than discovering it during an audit.
Labels, traits and grouping
- Every interactive element needs a meaningful label — icon-only buttons are the most common omission.
- Traits tell assistive technology what an element is: button, link, heading, selected.
- Group related elements so a list item is announced as one unit rather than four fragments.
- Decorative images should be hidden from the accessibility tree entirely.
Respect the user's settings
Support dynamic type so text scales with the system setting, and test at the largest sizes — layouts that assume a fixed text size break badly. Respect reduced motion, increased contrast and bold text preferences.
Ensure touch targets meet the platform minimum. Small targets affect far more people than those who identify as having a disability.
Test with the real tools
Automated checks catch missing labels and contrast issues. They cannot tell you whether a screen makes sense when read aloud in order.
Navigate your main journeys using VoiceOver and TalkBack with the screen off. It is uncomfortable at first and it is the fastest way to find the problems that matter.
Building accessibility into the process
Accessibility that depends on remembering is accessibility that decays. Bring it into the routine work of building features rather than treating it as a periodic audit.
Add accessibility labels to the definition of done for any interactive component, include a keyboard and screen-reader pass in the review checklist, and run automated checks in the pipeline so obvious regressions fail the build.
Design contributes as much as engineering: contrast, touch target size and text scaling are decided in the design and inherited by every implementation of it.
Frequently asked questions
WCAG is written for the web, and its principles are applied to mobile in practice and referenced in procurement. Both platforms also publish their own guidance, which is more directly actionable.
Modest when designed in from the start largely labels, focus order and testing. Retrofitting after a custom interface is built is significantly more expensive.
On tablets especially, yes. Keyboard navigation also benefits switch-control users, and testing it usually surfaces focus-order problems that affect screen reader users too.
