Digital accessibility
Why implement WCAG in technology
The Web Content Accessibility Guidelines (WCAG) are the international standard defining how websites, apps and digital tools should be built so that everyone can use them, including people with disabilities. Below we explain why this matters and present two open source portals we created as practical AAA-level references.
According to the World Health Organization, about 1.3 billion people, roughly 16% of the world's population, live with a significant disability. In Brazil, the national statistics agency (IBGE) estimates more than 17 million people with disabilities. Blind and low-vision people depend on screen readers, magnification and high contrast; people with motor impairments depend on the keyboard or assistive devices; deaf people need captions and text alternatives for audio.
When a digital tool ignores accessibility, it denies these people autonomy, information and participation. As the population ages, the audience that benefits only grows: vision, hearing and mobility loss increase with age. And the same features designed for disability help everyone on a sunlit screen, with busy hands or on a poor connection, the so-called curb-cut effect.
Four reasons to take WCAG seriously
Dignity and rights
Accessibility is inclusion and a human right. An accessible tool lets people study, work, shop and connect autonomously, without depending on others.
Legal obligation
In Brazil, the Brazilian Inclusion Law (Law 13,146/2015) requires accessibility on company and government websites. The US has the ADA and Section 508; the European Union has EN 301 549 and the European Accessibility Act. Ignoring them creates legal and reputational risk.
Market and reputation
Accessible products do not exclude customers: they widen reach and conversion. Accessibility is a frequent requirement in public tenders and corporate contracts, and it strengthens the brand.
Technical quality
Semantic HTML, text alternatives, visible focus and clear structure improve SEO, performance and maintainability. Building accessibly from the start costs little; fixing it later costs a lot.
The four WCAG principles
The whole standard is organized around four principles, summarized by the acronym POUR. Each principle unfolds into guidelines and testable success criteria.
Perceivable
Information and interface components must be presented in ways people can perceive: text alternatives, captions, sufficient contrast and adaptable content.
Operable
All components and navigation must be operable by keyboard, with enough time, without seizure-inducing content and with clear ways to find one's way around.
Understandable
Readable text, predictable behavior and help to avoid and correct mistakes, so people understand both the content and how the interface works.
Robust
Content that can be interpreted by a wide variety of user agents, including current and future assistive technologies, with correct use of HTML and ARIA.
Conformance levels
- A
- Minimum requirements. Without them, whole groups of people are prevented from using the content.
- AA
- The reference level required by most legislation and public policies, including 4.5:1 contrast and consistent navigation.
- AAA
- The highest level: 7:1 contrast, full reading control, plain language, no time limits and contextual help. It is the level adopted in the two demonstration projects below.
Legal and regulatory framework
Brazil
Brazilian Inclusion Law (Law 13,146/2015, art. 63), Decree 5,296/2004, the e-Government Accessibility Model (eMAG) and ABNT NBR 17060 for mobile apps.
International
WCAG 2.x, published by the W3C and adopted as ISO/IEC 40500; in the US, the ADA and Section 508; in the European Union, EN 301 549 and the European Accessibility Act, in force since 2025.
Demonstration projects
Two open source portals at level AAA
We created and maintain two public, open source portals to demonstrate that a modern, beautiful and fully accessible experience is achievable. Both run in production on our own infrastructure and serve as references for development, design and QA teams.
DevTools Khori
Everyday developer tools built as an accessibility reference, with a focus on visually impaired users.
dev.tools.khori.com.br · github.com/khoriati/devtools-khori
DevTools Khori is a mini-platform of utilities for developers, architects and system administrators: programmer's calculator, IP subnetting, chmod, JWT decoder, Base64, hashes, UUID, timestamps, JSON formatter, Brazilian CPF and CNPJ generator and validator, WHOIS, ping, traceroute, DNS lookup, HTTP inspector, quick references for Linux, Docker, Kubernetes, ffmpeg, ImageMagick, PowerShell, Azure CLI and AWS CLI, plus a WCAG contrast checker and a guide to command-line accessibility validators.
The project exists, first and foremost, as an example of an accessible portal. It shows that dense, technical tools can be 100% navigable by keyboard and screen reader, with a minimum contrast of 7:1, without sacrificing a modern interface.
What it demonstrates
- Three themes (light, dark and high contrast), with a minimum 7:1 contrast and support for Windows forced-colors mode
- Full keyboard navigation, skip links, semantic landmarks and a single h1 per page
- Screen reader announcements via aria-live regions
- Touch targets of at least 44 px and focus never obscured by the sticky bar
- Glossary of terms and abbreviations (criteria 3.1.3 and 3.1.4) and comfortable line width (1.4.8)
- Five languages (pt-BR, en-US, es, de, fr) with a synchronized lang attribute
- Brazilian Sign Language (Libras) translation via the VLibras widget when the language is Portuguese
- Respects prefers-reduced-motion and prefers-color-scheme; legible typography (Atkinson Hyperlegible)
Technology
React 18, TypeScript, Vite and MUI on the front end; Node.js and Express on the back end with an application WAF; Docker and Kubernetes with automatic TLS. Automated accessibility tests with axe-core and Playwright covering every tool.
Scope and caveats
- The AAA claim covers the portal's own interface. The VLibras avatar is a third-party component, and advanced technical reading content (criterion 3.1.5) is out of scope.
- Data tools run entirely in the browser; nothing is sent to the server. Network tools run on the back end with strict validation, usage limits and masking of the origin address.
- The automated validators listed perform a superficial technical check and do not replace QA testing with qualified professionals and people with disabilities.
WCAG AAA · Accessibility Demonstration
An application that demonstrates WCAG 2.2 level AAA best practices end to end, designed to be technically exemplary and pleasant for anyone.
wcag.tool.khori.com.br · github.com/khoriati/wcag-tool
WCAG Tool walks, section by section, through the groups of WCAG 2.2 success criteria: enhanced contrast, reading control, keyboard operation, visible focus, error prevention, ARIA components following the W3C Authoring Practices Guide (APG), media alternatives, plain language and orientation. Each section explains the criterion, shows the implementation working and points to where it lives in the code.
Unlike a theoretical checklist, it is a product users can adjust to their own taste: theme, contrast, text size, spacing, column width, motion and font, all persisted in the browser with no login required.
What it demonstrates
- Enhanced 7:1 contrast across the whole theme, with a maximum-contrast mode in pure black and white (1.4.6, 1.4.11)
- Reading panel: text size, line height, spacing and column width (1.4.8, 1.4.12, 1.4.4)
- 100% keyboard operation with roving tabindex and a thick, always-visible focus indicator (2.1.1, 2.1.3, 2.4.7, 2.4.12, 2.4.13)
- Form with review step and full error prevention (3.3.5, 3.3.6, 1.3.6)
- Tabs, accordion, modal dialog and toasts implemented per the ARIA Authoring Practices Guide (4.1.2, 2.2.4, 3.2.5)
- Media alternatives: transcript, audio description and captions (1.2.6, 1.2.7, 1.2.8)
- Glossary and plain language (3.1.3, 3.1.4, 3.1.6); generous touch targets and orientation (2.4.8, 2.5.5)
- Reduced motion, dyslexia-friendly font, aria-live regions and a final checklist of every criterion covered
Technology
React 19 and Vite with no external UI dependencies, served by nginx in a rootless container, deployed on Kubernetes with automatic TLS.
Scope and caveats
- This is a demonstration and educational application. WCAG conformance is evaluated page by page and depends on manual auditing with assistive technologies; the demonstration is not a seal or certification.
- The structure was audited (semantics, heading hierarchy, landmarks, accessible names, labels, lang and aria-live) with no issues found. We recommend complementing with axe DevTools, Lighthouse and tests with NVDA, VoiceOver and keyboard only.
- The media section uses sample content to illustrate the alternatives the standard requires.
Important notices
- Both portals are demonstration and reference projects, offered free of charge and without warranties, with open source code for study, reuse and contribution.
- Neither requires registration or login, and neither collects personal data for tracking or advertising.
- WCAG conformance is not a permanent state: every new version of a product must be re-evaluated. Use the portals as a starting point, not as a substitute for a professional evaluation of your own product.
- WCAG and W3C are trademarks of the World Wide Web Consortium. Marcos Khoriati (Khori) is not affiliated with the W3C; the portals implement the standard's public guidelines.
Frequently asked questions
Want to make your product accessible?
We assess, fix and train your team to deliver experiences everyone can use.