Accessible app development: building to WCAG

Accessible app development means building to WCAG so that people with disability can actually use your app, and it matters for three reasons at once: it is increasingly a legal expectation, it is the right thing to do, and it widens your reach rather than narrowing it. The phrase accessible app development WCAG points at the standard most teams build to, the Web Content Accessibility Guidelines, which set out how to make a digital product usable by the widest range of people. In practice the target to name is WCAG 2.2 at level AA, which is the version and conformance level government and enterprise procurement in Australia typically ask for, so it is worth stating explicitly rather than saying "accessible" and leaving it vague. This page covers what accessible development involves, when it is required, and why it improves an app rather than constraining it. On the legal specifics, we are engineers rather than lawyers, so treat that side as a matter to confirm with a qualified adviser.

Why accessibility matters

Accessibility matters first because a real and substantial share of people have a disability that affects how they use an app, whether that means relying on a screen reader, needing larger text or higher contrast, using the app without sound, or being unable to make precise gestures. An app that ignores them simply does not work for those people, which both excludes them and, for many businesses, leaves real users and customers on the table. So accessibility is partly a matter of reach: an accessible app can be used by more people, and an inaccessible one quietly turns some of its potential audience away at the door.

It also matters because it is increasingly expected rather than optional, both ethically and legally. In Australia, the Disability Discrimination Act makes it unlawful to discriminate on the basis of disability, which has been understood to extend to digital services, and government and many large organisations require accessibility standards in what they procure, so for public-facing and government-related apps accessibility is often a firm requirement. Whether and exactly how the law applies to your particular app is a legal question for a qualified adviser, but the direction is clear: accessibility is moving from a nice-to-have to a baseline expectation. Building accessibly is therefore both a safeguard and the right thing to do, and our enterprise app development page touches on where it becomes a procurement requirement. The combination of reach, ethics and expectation makes accessibility worth building in rather than skipping.

What building accessibly involves

In practice, accessible app development is less about exotic techniques and more about following established patterns well and testing with the tools people actually use. The core elements are supporting the device's screen reader, VoiceOver on iOS and TalkBack on Android, so the app can be used without sight; making sure text can be enlarged and contrast is sufficient to read; ensuring everything is operable without relying on precise gestures or on colour alone to convey meaning; providing text alternatives for images and other non-text content; and offering clear, consistent navigation that is easy to follow. These are well-understood practices, and much of accessible development is applying them carefully and checking the result with assistive technology.

The single most important thing about accessible development is when it happens, because building accessibly from the start is far easier and cheaper than retrofitting it into a finished app. When accessibility is part of the design and the build, it is mostly a matter of doing things the right way as you go and testing along the way, whereas adding it to a completed app can mean reworking the design and the code, which is exactly why retrofits are expensive. This is also where accessibility connects to thorough testing, the subject of our app testing and QA page, since verifying an app with screen readers and other assistive tools is part of confirming it actually works for everyone. We build accessibility in from the start because that is where it is cheap and effective, and treating it as a late add-on is both costlier and usually worse. Accessibility belongs in the foundation, not the finishing.

Accessibility is good design, not a limit

A persistent misconception is that accessibility limits design, forcing dull or compromised products, and it is worth dispelling because the opposite is true: accessible design is good design. The qualities accessibility asks for, clear structure, readable text, sufficient contrast, easy operation, consistent navigation, are exactly the qualities that make an app better for everyone, not only for people with disability. Larger, readable text helps someone in bright sunlight; good contrast helps a tired user on a dim screen; clear navigation and not relying on precise gestures help a person with a temporary injury or simply a one-handed grip on a busy train. Accessibility improvements quietly benefit your whole audience.

So accessibility is a constraint that improves the product rather than one that limits it, and skilled designers build apps that are both accessible and genuinely attractive, because the two are not in tension. The belief that you must choose between an accessible app and a beautiful one is a false choice that usually reflects unfamiliarity with accessible design rather than a real trade-off. We build apps that are accessible and well-designed at once, treating accessibility as part of doing the design properly rather than as a tax on it. The businesses that resist accessibility out of fear for the look of their app are usually solving an imaginary problem, since the disciplines of clear, usable, accessible design and of attractive, effective design point in the same direction far more often than they conflict.

Building it in, the right way

Pulling this together, the sound approach to accessible app development is to build to WCAG from the start, following the established patterns, testing with assistive technology, and treating accessibility as part of good design and thorough engineering rather than as an afterthought. Done this way it adds relatively little cost while widening your reach, reducing legal risk, and producing a better app for everyone, which is about as favourable a trade as exists in app development. The general build sequence our how to build an app guide describes has accessibility woven through it rather than tacked on, which is exactly where it belongs.

On the legal side, meeting accessibility standards is our job; how the Disability Discrimination Act or any specific accessibility requirement applies to your app is a question for a qualified adviser, so confirm that side with them while we handle building to WCAG 2.2 AA. For public-facing apps, government-related work, and any business that wants to serve its whole audience and reduce its risk, building accessibly is the clear choice, and it is one we make standard rather than optional. If you would like an app built to be accessible to the widest range of users, to WCAG and with assistive technology in mind, tell us what you are building and who it is for, and we will build it accessibly from the ground up, with a fixed-price quote and accessibility treated as part of doing the job properly.