Digital Accessibility — WCAG 2.2 in Practice

Digital accessibility typically enters the conversation too late — when the product is already ready and someone realizes it doesn't work with a screen reader, or that the contrast would fail a basic audit. When that happens, fixing it is expensive. Incorporating it from the start is not.

Version 2.2 of the WCAG (Web Content Accessibility Guidelines), published by the W3C, updates the accessibility criteria for web and mobile products. For organizations, what matters to understand isn't the technical criteria themselves, but what this standard represents as a product decision.

Market reach and legal obligation

In Brazil, the Brazilian Inclusion Law (Law 13.146/2015) establishes that websites and apps must ensure accessibility for people with disabilities. Internationally, the regulatory context is becoming more restrictive — the European Union, for example, has growing requirements for digital services.

Beyond the legal aspect, the potential reach is significant: more than 17% of the Brazilian population has some type of disability, according to IBGE. An inaccessible product systematically excludes part of your market.

What WCAG 2.2 introduces

The main new criteria in version 2.2 particularly affect mobile products and interfaces with heavy interaction: minimum touch target size, keyboard focus visibility, and authentication consistency without relying on complex cognitive tests. For products that already followed WCAG 2.1, the jump isn't dramatic — but it requires review.

What matters for decision-makers: conformance with level AA — the standard required in public contracts and by most regulations — requires the design and development team to consider accessibility in every new component created, not as a final approval step.

Accessibility as quality, not audit

The most common mistake in accessibility implementations is treating it as a checklist to execute after the product is ready. The cost of fixing accessibility issues after development is estimated at 10 to 100 times the cost of preventing them in design.

Teams that integrate accessibility into the process — checking contrast during component creation, testing with keyboard during development, using automated tools in the build process — deliver accessible products without special "accessibility correction" projects.

What to expect from the investment

Accessible products tend to have better usability for all users — not just those using assistive technology. Readable fonts, consistent navigation, and predictable interfaces benefit elderly users, users in low-visibility conditions, and people in temporary situations like a broken arm.

For organizations that depend on public procurement or contracts with large companies, WCAG compliance isn't a differentiator — it's an entry requirement. For B2C products, it's a growing competitive advantage in a market that is beginning to demand digital accountability from brands.

The most efficient path is not an isolated accessibility project. It's making accessibility part of the "done" criteria for any new feature that goes into production.