WCAG and Accessibility for Web and Mobile Apps Built with AI

Accessibility is about making your product usable by people with different abilities and in different situations: low vision, color blindness, motor impairments, hearing loss, a bright sun on the screen or one free hand. It is also increasingly a legal and commercial topic in Europe. Coding agents can produce clean-looking interfaces that nonetheless fail basic accessibility checks, so it needs deliberate attention.

The WCAG principles in plain terms

The Web Content Accessibility Guidelines (WCAG) are organized around four principles, often abbreviated as POUR.

• Perceivable: content can be perceived, with text alternatives for images, captions, and sufficient contrast.
• Operable: everything works with a keyboard, a switch device or a screen reader gesture, with adequate time and no traps.
• Understandable: consistent navigation, clear labels, helpful error messages.
• Robust: markup and components that assistive technologies can interpret reliably.

WCAG has versions and conformance levels, and mobile apps are commonly assessed against its success criteria too. Check the current version and the W3C's guidance for details, and verify legal requirements that apply to you, such as the European Accessibility Act, with qualified advisors.

Typical problems in AI-generated interfaces

1. Missing names: icon-only buttons and inputs with no accessible label.
2. Div soup: clickable elements built from generic containers, with no role, focus or keyboard support.
3. Low contrast: pale gray text and subtle borders that look elegant but fail contrast ratios.
4. Small touch targets: controls too tiny or too close together for reliable tapping.
5. Poor focus handling: modals that do not trap or restore focus, or an illogical reading order.
6. Color-only meaning: errors or statuses signaled only by red or green.
7. Fixed text sizes: layouts that break when users enlarge system text.
8. Unlabeled form errors that screen readers never announce.

Web and mobile specifics

On the web, use native elements such as buttons, links, headings, lists and labels before reaching for custom widgets, and add ARIA only when native semantics are not enough. In apps, both iOS and Android provide accessibility APIs, labels and traits, plus screen readers (VoiceOver and TalkBack) and system settings for larger text, reduced motion and high contrast. In web view apps, your web content must be accessible and the native shell must not block it. Also test orientation, zoom and dark mode.

How to test

• Automated checks: linters and scanners catch missing labels and contrast issues, but only a fraction of real problems.
• Keyboard-only run: tab through every flow on the web version.
• Screen reader run: complete sign-up and the core action with VoiceOver and TalkBack on real devices, eyes closed.
• System settings: largest text size, reduced motion and high contrast.
• People: if possible, test with users who rely on assistive technology.

Prompting agents for accessibility

Agents follow instructions, so write accessibility into your project rules: use semantic elements, require labels for every control, keep minimum touch target sizes, meet contrast requirements, and never signal state by color alone. Put these in your instructions file, as explained in AGENTS.md and CLAUDE.md: Writing Instructions Coding Agents Follow, and add automated accessibility checks to your pipeline, as in CI/CD for AI-Built Apps.

How apprat.io builds accessibility in

Automated tools and agents reduce effort, yet accessibility needs human judgment: does the reading order make sense, is the error message helpful, does the flow work with VoiceOver? At apprat.io, senior AI Code Engineers review every change, test on real iOS and Android devices with assistive technologies enabled and take accountability for the outcome. We do not provide legal certification of conformance, but we can build and test toward accessibility goals. Learn more on our custom development service page.

Make it part of the definition of done

Accessibility is cheapest when it is part of every change instead of a late audit. Add a short checklist to your pull request template: labels present, contrast checked, focus order sensible, text scales, and a screen reader pass for new flows. When a defect is found, fix it and add a test or a rule so it does not return. Over time this builds a habit that outlasts any single release.

Quick wins

• Give every icon button a text label.
• Raise contrast on body text and form borders.
• Enlarge small tap targets.
• Announce form errors next to the field and to screen readers.
• Run one full flow with a screen reader this week.