TL;DR: App accessibility means people with disabilities can complete the same tasks in your web or mobile app as everyone else: people using screen readers, keyboard-only users, people with low vision or color blindness, people who are deaf or hard of hearing, and people with motor or cognitive impairments. WCAG 2.2 at level AA is the standard most buyers, regulators and courts point to. The cheapest way to meet it is to put it in the brief, build it into the design system and test it in every release. Retrofitting a finished product costs far more than building it in from the start, and an overlay script does not fix it.
Accessibility usually shows up late: a procurement questionnaire asks for a conformance report, or a user writes in because they cannot get past sign-up. By then every fix touches code that already shipped.
This guide covers what accessibility requires, what it costs and what to ask a development team. It is not legal advice. If you have a specific legal obligation, confirm it with counsel.
What WCAG is and which level to aim for
The Web Content Accessibility Guidelines (WCAG) are published by the W3C. The current version is WCAG 2.2. The guidelines are organized around four principles: content must be perceivable, operable, understandable and robust. Under those sit testable success criteria, each assigned a level:
- Level A covers the most basic barriers, such as images with no text alternative or functions that cannot be reached by keyboard.
- Level AA adds the criteria most organizations commit to, such as minimum color contrast, visible focus, resizable text and consistent navigation.
- Level AAA is the strictest and is not usually required for an entire product, because some criteria cannot be met for every kind of content.
For almost every business app, the practical target is WCAG 2.2 AA. Some policies and procurement documents still reference WCAG 2.1 AA or 2.0 AA. Because 2.2 builds on 2.1, which builds on 2.0, meeting 2.2 AA generally covers the older versions too.
WCAG was written for web content, but its principles apply to native mobile apps as well, and both Apple and Google publish their own accessibility guidance that maps onto it.
Why it matters to your business
There are three reasons, and the legal one is often not the biggest.
Customers and markets. Disability can be permanent, temporary or situational. Someone with a broken wrist or using a phone in bright sunlight benefits from the same features a screen reader user depends on.
Procurement. Enterprise, education and public-sector buyers increasingly ask for an accessibility conformance report, often in the VPAT format, before they sign. If your product cannot produce one, you may not get to the shortlist.
Legal exposure. The rules depend on where you operate and who you sell to. In the United States, the ADA has been applied to websites and apps in a steady stream of lawsuits, and federal agencies buying technology are bound by Section 508. In the European Union, the European Accessibility Act has applied since June 2025 to a range of products and services, including e-commerce, consumer banking and e-books, and the related standard, EN 301 549, references WCAG. Other countries have their own rules.
What accessibility actually covers in an app
It helps to translate the guidelines into the things a team actually builds.
Screen readers and semantics
Screen readers such as VoiceOver, TalkBack and NVDA read out what is on screen and let users navigate by headings, buttons, links and form fields. That only works if the app tells them what each element is. On the web this means real buttons, links, headings, labels and landmarks, not clickable boxes. On mobile it means setting accessibility labels, roles and traits on every control. An icon-only button with no label is read as "button," which tells the user nothing.
Keyboard and switch access
Everything a mouse or finger can do should be possible from a keyboard or a switch device. Focus should move in a logical order, be clearly visible, and never get trapped inside a modal or a custom widget. WCAG 2.2 also added criteria for alternatives to dragging and for minimum target size, which matter on both web and touch screens.
Vision, contrast and text size
Text needs enough contrast against its background, information cannot be conveyed by color alone, and the layout has to survive large text and zoom. On mobile this means supporting the system's dynamic text size settings instead of fixing font sizes, and testing that screens still work when the text is at its largest. Animations should respect the reduced-motion setting; immersive products face a larger version of that problem, covered in XR accessibility.
Audio, video and time
Video needs captions, audio-only content needs a transcript, and anything that times out should warn the user and let them extend it. For a product that records or plays content, this is a feature in its own right. With LectureNotes AI, which records lectures and turns them into summaries and outlines, the text output is itself an alternative way to access spoken content, which is a good example of an AI feature and an accessibility benefit being the same piece of work.
Forms, errors and cognitive load
Forms are where most apps fail real users. Every field needs a visible label, errors need to say what went wrong and how to fix it, and users should not have to re-enter information they already gave. WCAG 2.2 also addresses authentication that relies on memory or puzzles, which affects login and verification flows.
Accessibility in different kinds of products
The work looks different depending on what you are building.
- Data-heavy business software. A platform like Fyuel, which brings customers, suppliers, tankers, ledgers and reports into one system for the fuel trade, lives on tables, filters and forms. The accessibility work there is mostly proper table markup, keyboard-friendly data entry and clear error handling, which also make the product faster for power users.
- Consumer mobile apps. For apps with onboarding flows, cameras and gestures, the critical paths are sign-up, the core action and payment. A safety app like Covoisino, which uses QR verification, needs an alternative path for anyone who cannot complete a camera-based step easily.
- Voice and conversational products. A phone line handled by an AI agent can widen access for people who find apps difficult, but it brings its own requirements, such as clear prompts, patience with slower responses and a route to a person. Language is part of access too, which is why products like Fortell support intake in 100+ languages, as we discuss in multilingual voice AI.
Build it in, do not bolt it on
Most accessibility cost comes from fixing things after they are built. The cheapest path is to make it part of the normal process.
- Put it in the brief. State the target, usually WCAG 2.2 AA, and the platforms it applies to. A requirement that is not written down will not be priced or delivered. Our guide to writing a software project brief covers how to state requirements like this.
- Design for it. Contrast, focus states, text scaling and error states should be in the design files, not invented during development.
- Build accessible components once. A design system with accessible buttons, inputs, modals and menus means every new screen inherits the work instead of repeating it.
- Choose the stack with it in mind. Native platforms give you system accessibility behavior for free. Cross-platform frameworks vary in how well they expose it, and custom-drawn interfaces can hide content from screen readers entirely. We compare the options in native vs cross-platform app development.
- Test it every release. Accessibility regresses quietly when screens change.
Automated and manual testing
Automated tools catch missing labels, low contrast and broken markup, and belong in the build pipeline. They cannot tell you whether a label makes sense, whether the focus order is logical or whether a screen reader user can actually finish checkout. That takes manual testing with VoiceOver, TalkBack and a keyboard on the critical paths, and ideally sessions with disabled users. We describe how this fits into a wider test plan in software testing and QA.
Why overlays are not the answer
Accessibility overlays are scripts that promise to make a website compliant with one line of code. They do not change the underlying markup, they often interfere with the assistive technology users already rely on, and they do nothing for a native mobile app. If a vendor tells you an overlay solves accessibility, treat that as a warning sign.
Fixing an existing product
If your app is already live, start with an audit of the flows that matter most: sign-up, login, the core task and payment. Fix the shared components first, because one repaired button or form field can fix hundreds of screens at once. Then work through the rest by severity and add automated checks so they do not return.
If the audit shows the problems are structural, such as an interface built from non-semantic elements throughout, accessibility can become one of the arguments for rebuilding a part of the product rather than patching it. We discuss how to make that call in legacy system modernization.
What it costs
Building accessibility in from the start typically adds modest effort to design, component work and testing, spread across the project. Retrofitting it into a finished product costs much more, because each issue means reopening designs, changing components and re-testing screens that were considered done. There is no honest single number: it depends on your custom components, platforms and distance from the target.
When you compare quotes, check that accessibility is listed as a requirement with a stated level, not left as an assumption. Our guides to MVP development cost and fixed price vs time and materials explain how requirements like this change an estimate.
Questions to ask your development team
- Which WCAG version and level are we targeting, and on which platforms?
- Is accessibility in the design files, including focus, contrast, text scaling and error states?
- Are our shared components accessible, and who owns them?
- How does our chosen framework expose content to VoiceOver and TalkBack?
- Which automated checks run in the pipeline, and which flows are tested manually each release?
- Will we test with disabled users before launch?
- Can we produce an accessibility conformance report if a customer asks for one?
The bottom line
Accessibility is a quality attribute, like performance or security. Decide the target, usually WCAG 2.2 AA, write it into the brief, build it into the design system and test it every release. Done that way it is a manageable part of the build. Left until a customer or a lawyer asks, it becomes expensive rework.
Building a web or mobile app and want accessibility built in from day one? Book a demo and we will scope it with you. See our work: LectureNotes AI, Fyuel, Covoisino, Fortell and more.