Accessibility has moved from something you could quietly defer to something that appears on your storefront and, for a growing number of businesses, something with a regulatory deadline that has already passed. Two changes did it. Apple's Accessibility Nutrition Labels, introduced at WWDC 2025, put a declaration of which accessibility features an app supports directly on its App Store product page. And the European Accessibility Act has applied since 28 June 2025 to businesses selling to consumers in the EU, regardless of where the business itself is located.
Neither of those is a design trend. They are both mechanisms that make the state of your app's accessibility visible to someone other than your own team - a prospective user in the first case, a regulator in the second.
What the store labels actually change
The labels let developers declare which device accessibility features their app supports - VoiceOver, Voice Control, larger text, dark appearance and others - and that declaration shows on the product page before a download. Apple has indicated that providing this information will become part of submitting new apps and updates rather than remaining optional.
The commercial consequence is more interesting than the compliance one. A declaration is a public, checkable statement, and users can filter on it. That changes the calculus in two ways. Declaring support you do not really have is now a visible claim rather than an internal shortcut. And declining to declare anything is itself a signal on a page where competitors are declaring something.
It also removes a familiar internal argument. Accessibility work has historically been hard to prioritise because its absence was invisible to everyone except the users it excluded. A field on the storefront makes it visible to the people who set the roadmap.
The EAA has a wider reach than most Australian businesses expect
The European Accessibility Act applies to consumer-facing e-commerce services, websites and mobile apps sold to consumers in the EU. The trigger is the customer, not the company - an Australian business selling into the EU is in scope on the same terms as a European one.
Three obligations matter for a product team. The service has to be designed to the accessibility requirements. There has to be a published accessibility statement describing how it meets them. And there has to be a process for maintaining conformity as the product changes, which means it is not a one-off remediation project. Member states set their own penalties, with administrative fine ceilings commonly in the tens of thousands of euros per infringement.
The practical implementation route is the harmonised European standard EN 301 549, which in turn points at the Web Content Accessibility Guidelines. That is the useful part for a build team, because it converts a legal obligation into a technical specification that engineers can work to.
Closer to home, the Disability Discrimination Act 1992 has always applied to Australian services, and WCAG is the reference point there as well. The obligation is not new in Australia. What is new is that two much more concrete mechanisms now make it observable.
What this changes in a build, concretely
Accessibility is cheap when it is a constraint on the design system and expensive when it is a remediation pass. The difference is almost entirely about where in the project it happens.
- Colour and type decisions are made once, in the design system. Contrast ratios and minimum type sizes are properties of the tokens, not of individual screens. Fixed at the token level they cost nothing; fixed screen by screen after the fact they are a repricing of the whole interface.
- Every interactive element needs a name, a role and a state. This is where most retrofits actually go wrong. A custom control built as a styled container has no semantics, and giving it some later usually means rebuilding it rather than annotating it.
- Dynamic type has to be a layout assumption. Supporting larger text is straightforward if layouts were built to grow, and close to a rewrite if they were built to fixed heights.
- Focus order and keyboard navigation are architectural. They follow the structure of the view hierarchy, so they are inherited from decisions made early rather than added late.
- It has to be tested on the actual assistive technology. An automated checker verifies the mechanical rules and cannot tell you whether a flow is usable with VoiceOver. We run quality assurance as its own discipline on real devices in real conditions, and this is a case where that distinction does the work.
None of that is exotic engineering. It is ordinary engineering done at the right time, which is the same reason it becomes expensive when it is done at the wrong one.
Where we sit on this
We build products to the accessibility requirements that apply to them, in the same way we build to any other regulatory requirement a client's product carries. That is ordinary delivery work and we have done it across regulated environments, including products handling patient and financial data and a field platform for Flinders University with forensic-grade chain-of-custody.
What we do not do is act as the assessor. Independent accessibility audit and formal conformance verification are performed by a third party, and that is deliberate rather than a gap - it is not good practice for the same team to build a system and certify it, and an independent assessment produces a result that stands up to scrutiny. If you need a conformance statement you can rely on, you want it from someone who did not write the code.
The honest starting point
If you have an app in the store today and no clear answer about its accessibility, the useful first step is not a remediation project. It is finding out where you actually stand: run the platform's own accessibility audit tooling, then have someone navigate your three most important flows using VoiceOver or TalkBack and watch what happens. That takes an afternoon and it usually reframes the conversation, because the failures are rarely spread evenly - they cluster in a few custom components that get used everywhere.
If you would like that built in properly rather than bolted on, our app design and UX work is where it belongs, and you can talk to us about scoping it.