App accessibility: requirements, common barriers, and where to start

An icon shaped like a shopping cart with no label is enough to block a purchase. People who use a screen reader hear only "button," and the same goes for the menu, the search magnifier, and the back button.

App accessibility means making every screen perceivable, usable, and understandable, including with VoiceOver, TalkBack, an external keyboard, or an enlarged system font. In this guide you'll find what the rules require, the digital barriers that come up most often in audits by our accessibility experts, and the seven fixes with the best ratio of impact to effort.

What app accessibility means

The Italian Law 4/2004 (Stanca Law) defines accessibility as the ability of IT systems to provide services and information that people who use assistive technologies can access. The burden of adaptation therefore falls on the system, not on the person.

The principle applies to native iOS and Android apps, web apps, and mobile sites. The Web Content Accessibility Guidelines (WCAG) were written for the web, but their criteria apply to native app screens too, and the European standard EN 301 549 covers mobile as well.

The four WCAG principles translate into concrete terms on a smartphone screen:

• A screen is perceivable if it has alternative text, adequate contrast, and text that scales up.

• It is usable if every gesture has an alternative and touch targets are large enough.

• It is understandable if errors are clear.

• It is robust if the name, role, and state of every control reach assistive technologies.

People who use an app differently than you designed it

A person with a visual disability uses VoiceOver on iOS or TalkBack on Android and listens to the screen instead of looking at it. Someone living with a motor disability may rely on an external keyboard, a switch, or voice commands. Someone with low vision enlarges the system font and expects the app to respect it.

The same solutions help in temporary situations too: direct sunlight on the screen, one hand occupied, an arm in a cast. What a group of people needs every day, many people need now and then.

When app accessibility is mandatory

For public sector bodies, the obligation has existed for some time: Directive (EU) 2016/2102 requires public sector websites and mobile apps to be accessible. Each member state transposes it into national law.

Since 28 June 2025, the European Accessibility Act applies in EU member states through national laws. It extends the obligations to economic operators for the products and services within its scope. E-commerce, consumer banking services, and passenger transport services are covered, even when they run through an app. Service microenterprises are excluded.

The technical reference is the EN 301 549 standard, which references WCAG level AA. Public sector bodies also publish an accessibility statement with an accessible feedback mechanism. Enforcement and penalties depend on each member state.

Acting early leaves more room: fixes go into the normal release cycle, with no scrambling to catch up.

The most common barriers in apps

Audits by our accessibility experts show patterns that repeat. They fall into four families of digital barriers, and each one maps to specific WCAG criteria.

Controls without a name, role, or state

Icons, graphic-only buttons, and custom components often don't expose a name, role, or state to assistive technologies (criterion 4.1.2). The screen reader says "button" and nothing else, or doesn't announce whether a switch is on. The control becomes unusable.

The same happens with images. Informative images without a text alternative and decorative images that aren't hidden (criterion 1.1.1) lose information and add noise for anyone listening.

Structure and fields that don't make sense

Titles not marked as headings, field labels not associated with the field, lists and groups not declared: all of this falls under criterion 1.3.1. Without headings, navigating by heading is impossible. Without associated labels, people who use a screen reader can't tell what to fill in during sign-up, login, and checkout.

Keyboard, gestures, and focus order

Functions that require complex gestures or swipes (criterion 2.1.1) leave people who use an external keyboard or a switch stuck. Focus order matters too (criterion 2.4.3): if it is illogical, or if focus isn't managed on modals and screen changes, content gets skipped or reached out of context.

Locked orientation and text that doesn't scale

An app locked in portrait or landscape (criterion 1.3.4) is unusable for people who keep their device fixed in one position, for example on a mount. Text that doesn't grow, or that gets cut off when the system font is enlarged (criterion 1.4.4), excludes people with low vision. The cause is often fixed heights in containers.

Seven fixes to improve app accessibility right away

You don't need to redo the app from scratch. A few targeted fixes recover a lot, and we've ranked the best seven by the ratio of impact to effort.

How to test the accessibility of an app

Automated tools find the problems that are easiest to detect. To know whether people can use the app, you need three levels of verification.

The first is manual testing.

Turn on VoiceOver or TalkBack and complete an entire flow, for example login, search, and purchase. Then connect a Bluetooth keyboard and move around with Tab and Enter, enlarge the system font, and rotate the device.

The second level is tools.

On Android there's Accessibility Scanner, on iOS the Accessibility Inspector in Xcode, and Android also offers automated tests for Compose interfaces. They flag contrast, touch targets, and missing labels, but they can't tell you whether a label makes sense to the person listening to it.

The third level is testing with people with disabilities.

An app can be accessible and still hard to use: only people who use it with assistive technologies every day can say whether a flow is effective and satisfying.

How we support you with an app

An Accessiway audit of an app follows WCAG 2.2 level AA and the EN 301 549 standard, and it's built with input from people who use assistive technologies every day. The result is a list of digital barriers ranked by impact, with remediation guidance written for developers.

From there, the work continues with every release, because conformance is maintained over time.

Find out more with an Accessiway audit: a 15-minute conversation is enough to see where to start with your app.

Frequently asked questions about app accessibility

What does app accessibility mean?

App accessibility is the ability of an app to be perceived, used, and understood, including with assistive technologies such as VoiceOver and TalkBack, an external keyboard, or enlarged text. The app adapts to the person.

Do the WCAG apply to apps too?

Yes, the WCAG criteria apply to native app screens too. The European standard EN 301 549 covers mobile software and uses WCAG level AA as the reference for content.

When is accessibility mandatory for an app?

For public sector bodies, the obligation has existed for some time. Since 28 June 2025, the European Accessibility Act extends it, through national laws, to economic operators with services in scope, excluding service microenterprises.

How do you check the accessibility of an app?

It takes a mix of manual testing with VoiceOver or TalkBack, an external keyboard, and enlarged text, tools such as Accessibility Scanner or Accessibility Inspector, and testing with people with disabilities.

Which fixes should you start with?

With accessible labels on icons and graphic-only buttons, then screen titles, always-visible field labels, and announced errors. They take little time and have a high impact.

Content generated with the support of artificial intelligence and subject to human oversight and review