O que significa aqui “mira a WCAG 2.2 AAA”
A palavra mira é deliberada. Esta página diz com precisão o que é verificado, por quê, o que não é verificado por nada e o que pretendemos fazer a respeito dessa lacuna. A Lily nunca afirma “conformidade” com a WCAG — nenhuma auditoria a sustenta.
Verificado continuamente
- O elemento semântico canônico, os atributos ARIA e as classes de gancho de cada componente — verificados por conjuntos de testes unitários de cada framework (mais de 15.000 casos em sete frameworks).
- Cada uma das 571 páginas de demonstração de componentes no aplicativo de exemplo SvelteKit está livre de erros do axe (conjuntos de regras WCAG 2.0/2.1 A+AA e 2.2 AA) — a varredura de todo o catálogo, com linha de base inicial em 2026-08-27 e repetida em 2026-10-06 — além das linhas de base por aplicativo nas rotas inicial, de catálogo e compostas dos sete aplicativos de exemplo.
- Contratos de teclado por componente interativo, documentados nos metadados canônicos de cada componente e exercitados pelos conjuntos de testes; os pacotes de assistentes executam ainda especificações Playwright em navegadores reais.
- Pisos de tamanho de alvo e proteções contra estouro da WCAG 2.2 nos 45 temas; link de salto, marcos de página e ausência de rolagem horizontal em quatro tamanhos de janela por aplicativo; aplicação de
lang/dir, incluindo a inversão para escrita da direita para a esquerda.
Não verificado por nada
- Nenhuma auditoria de conformidade jamais foi realizada. Nem VPAT, nem certificação. As ferramentas automáticas cobrem uma minoria dos critérios de sucesso da WCAG.
- Os critérios específicos do nível AAA (contraste aprimorado, entre outros) são intenções de design, não propriedades verificadas; os conjuntos de regras do axe rodam em A/AA. Ainda não há um tema dedicado de alto contraste.
- O comportamento com leitores de tela é em grande parte não testado. Os conjuntos de testes verificam atributos ARIA, não o que o VoiceOver, o NVDA ou o JAWS anunciam — e este projeto já entregou mais de uma vez testes verdes sobre defeitos reais, cada um registrado no histórico de mudanças justamente porque os testes não conseguiam enxergá-los.
O que pretendemos fazer a respeito
Uma auditoria de acessibilidade independente é o primeiro uso previsto de qualquer financiamento do projeto, e o escopo de que um auditor precisa já está preparado. Até lá, relatos de leitores de tela são a contribuição que este projeto mais deseja: “o componente X anuncia Y, o que está errado porque Z” é diretamente acionável.
Relatar um problema
Abra uma issue em github.com/LilyDesignSystem/lily-design-system ou escreva para joel@joelparkerhenderson.com. Citar um critério da WCAG ajuda, mas não é obrigatório — “Não consegui operar X pelo teclado” é um relato completo.
A declaração completa, com a tabela de verificação e seu histórico de revisões, está no repositório: docs/accessibility-statement.md.