01
Padrão Digital de Governo (DSGov)
O padrão oficial de design do governo federal, publicado pela Secretaria de Governo Digital. É a matriz de referência de todo o governo federal.
Lighthouse na página inicial: 92 de 100. Auditoria da documentação: 202 falhas AA.
Um protocolo aberto de auditoria com recomendações de governança para design systems governamentais. Auditei a documentação do DSGov e do Bold com o mesmo procedimento e encontrei 277 barreiras de nível AA: 202 no DSGov e 75 no Bold. Em um fork isolado do exemplo Menu Push, a correção indicada pelo método reduziu de 22 para zero as sinalizações de duas regras estruturais na mesma auditoria. Até 03/08/2026, o fork não havia sido incorporado pelo mantenedor.
Acessibilidade por Padrão
- TCC defendido na UFSC, nota 10, dezembro de 2025
- Dados abertos
- Método replicável
A conformidade declarada não é a conformidade verificada.
Serviços públicos digitais são infraestrutura essencial de cidadania, não conveniência. A legislação brasileira garante o direito de acesso, e milhões de pessoas dependem dele.
Os dois sistemas declaram conformidade com WCAG e eMAG. A auditoria da documentação encontrou falhas no shell do portal e em exemplos copiáveis; não transferiu esses achados ao código distribuído.
18,6 milhões
de pessoas com deficiência no Brasil em 2022, 8,9% da população.
IBGE, PNAD Contínua 2022
A barreira não está só na tela publicada. Ela pode estar na fonte que produz a tela.
Três objetos, três limites de inferência.
Design systems organizam componentes e exemplos reutilizáveis para a construção de serviços. Quando uma equipe reutiliza um exemplo ou componente, uma barreira presente naquele objeto pode acompanhá-lo.
Este estudo separa o shell do portal, os exemplos copiáveis e o código distribuído. Ele não mediu propagação em serviço derivado.
Diagrama de três objetos auditados sem herança presumida
- Shell do portal
- Exemplos copiáveis
- Código distribuído
Se uma equipe mantenedora adotar uma versão corrigida, a correção pode chegar aos serviços que consumirem aquela versão.
O que foi auditado, e por que estes dois.
02
Bold Design System
Design system do Laboratório Bridge, na UFSC. Contraponto acadêmico auditado com o mesmo procedimento.
Nota de isenção
O procedimento foi idêntico entre os dois: mesmo fluxo, mesma bateria, mesmas 8 categorias de verificação, mesmo ambiente. O estudo também credita o que os sistemas acertam: os dois passaram em 100% das checagens de foco visível, sem armadilha de foco, nos componentes instrumentados.
Nota de vínculo
O autor tem vínculo acadêmico com a UFSC. Ferramentas independentes, procedimento idêntico e a proporção interna de falhas críticas do Bold maior que a do DSGov (40,0% contra 22,3%) são mitigações documentadas para o risco de favorecimento.
Um protocolo em quatro camadas.
O método é o Framework Híbrido de Auditoria e Verificação. Ele integra quatro camadas que se complementam, converte norma abstrata em métrica auditável e deixa cada achado ligado a evidência arquivada.
As quatro camadas
- 01
Auditoria automatizada
axe-core, Lighthouse e WAVE sobre a documentação oficial dos componentes.
- 02
Inspeção heurística
Guiada pelas práticas WAI-ARIA.
- 03
Checklist eMAG 3.1
A norma brasileira, item a item.
- 04
Matriz de síntese
Consolidação e priorização das barreiras encontradas.
Pipeline de contagem
A contagem passa por um funil auditável:
- 1
Bruto
Resultado integral das ferramentas.
- 2
Deduplicação
Por regra mais seletor mais contexto.
- 3
Filtro AA
Só o que fere o nível AA permanece.
Cada achado tem ficha de avaliação de 26 campos, ligada à norma (WCAG, eMAG, WAI-ARIA) e à evidência.
Ambiente reproduzível
Ambiente pinado, com versão de ferramenta, navegador e viewport registrados. Scripts públicos sob MIT, dados sob CC BY 4.0 e hashes SHA-256 permitem reexecutar a auditoria. Até 03/08/2026, a usabilidade desse fluxo por uma equipe real não havia sido testada.
- MIT (scripts)
- CC BY 4.0 (dados)
- SHA-256 (integridade)
Checklist de Verificação por Componente
O Apêndice C do TCC em uma página: as verificações prioritárias por componente, com critérios WCAG e eMAG e as ações recomendadas para cada sistema.
Baixar o checklist (PDF, 1 página)Fonte: Xikota, T. K. C. Acessibilidade Digital em Design Systems Públicos, TCC, UFSC, 2025, Apêndice C.
O que a auditoria encontrou.
277
não conformidades únicas de nível AA na documentação oficial dos dois sistemas.
- Bold27% do total
- 75
- DSGov73% do total
- 202
Unidade de leitura: não conformidade única = regra + seletor + contexto, após deduplicação; ocorrência = nó sinalizado pela regra.
Tabela 4 do TCC
A ilusão da nota alta
Enquanto isso, a nota automatizada de acessibilidade das páginas iniciais era 98 no Bold e 92 no DSGov. A nota alta convive com 75 e 202 falhas verificadas na documentação.
Nota Lighthouse (página inicial)
0 / 100
Bold
98
DSGov
92
Falhas AA verificadas (documentação)
0 / 220
Bold
75
DSGov
202
Tabelas 4 e 7 do TCC
Nota alta não basta.
O paradoxo institucional
A referência oficial do governo reprova na própria régua, dentro do próprio site.
Objeto 01
Shell do portal
É onde a auditoria registrou aria-required-parent (40 ocorrências) e listitem (37 ocorrências) no DSGov, com zero incidência no Bold. São falhas do portal de documentação, sem evidência de herança por serviços consumidores.
Objeto 02
Exemplos de código copiável
É onde se concentram as falhas de contraste da documentação de referência. O Menu Push isolado no piloto pertence a este objeto e tem escopo próprio.
Objeto 03
Código distribuído dos componentes
É um objeto distinto do shell e dos exemplos. Esta auditoria não transfere para ele as falhas estruturais encontradas no portal.
Tabela 5 do TCC
A barreira mais frequente
O contraste abaixo de 4,5:1 é a barreira mais frequente: 128 ocorrências nos dois sistemas somados, concentradas nos blocos de exemplo de código da documentação de referência. No DSGov, o contraste responde por cerca de 53% das falhas.
As razões de contraste medidas incluem 4,02:1 e 3,75:1 no Bold e 3,07:1 e 3,58:1 no DSGov, todas abaixo do mínimo de 4,5:1.
Seção 4.4.5 e Quadro 2 do TCC
Reauditoria
Reexecutei o protocolo sobre a versão atual dos dois sistemas em 30/07/2026, com ambiente pinado, e registrei os diffs frente à coleta de set-nov/2025 no dataset aberto. Nenhum número-âncora do estudo mudou.
Da norma abstrata à decisão de projeto.
A síntese POUR reorganiza os achados pela capacidade humana afetada, sem reabrir a descrição do método.
Perceptível
41 de 137 verificações
Operável
19 de 45 verificações
Compreensível
15 de 20 verificações
Robusto
0 de 0 verificações
O zero em Robusto é artefato de classificação, não ausência de erro: os erros de estrutura ARIA foram codificados sob outra diretriz (1.3.1).
Essa leitura orienta a prioridade pelo efeito sobre a pessoa, não pela ordem em que a ferramenta lista os achados.
Quatro mecanismos propostos de governança.
- 01
Gate de acessibilidade no CI/CD
Se adotado, pode bloquear regressões detectadas pela bateria antes de uma release.
- 02
Contrato de acessibilidade por componente
Proposta de incluir os requisitos no Definition of Done.
- 03
Fonte única de verdade
Proposta de manter um lugar canônico para o componente e seu comportamento acessível.
- 04
Painel público de conformidade
Proposta de publicar a série de não conformidades sob escopo constante.
Nota de factibilidade
Os mecanismos reutilizam o pipeline executado neste estudo. A camada de auditoria produziu as 277 barreiras. Até 03/08/2026, os quatro mecanismos de governança não haviam sido implantados por órgão.
A adoção do protocolo por um órgão pode impedir a entrada de novas barreiras por meio do gate de CI/CD. É recomendação, não implantação.
Prova de conceito da correção
Correção experimental em fork, sem incorporação pelo mantenedor até 03/08/2026
Antes
22 nós
21 aria-required-parent + 1 aria-required-children
Intervenção
Correção semântica no fork isolado do exemplo Menu Push
Depois
0 nós
Na mesma auditoria pinada do fork
A correção especificada pelo protocolo foi aplicada a um fork do código de exemplo do componente de menu do DSGov (variante Push, aba desenvolvedor). Na mesma auditoria pinada, os 22 nós de violação de estrutura ARIA (aria-required-parent 21, aria-required-children 1) deixaram de ser sinalizados. Antes, depois, diff e hashes estão publicados no dataset aberto.
Os 21 nós de aria-required-parent no fork são o escopo de uma página de exemplo, um subconjunto das 40 ocorrências registradas no shell ao longo das páginas do DSGov. A regra listitem não se reproduziu no fork isolado e continua registrada no shell do portal.
Em 31 de julho de 2026, relatei o defeito e a correção experimental ao mantenedor, em issue pública no repositório oficial do DSGov. Até 03/08/2026, a issue estava sem resposta. Ver a issue pública (261)(link externo)
O que já pode ser verificado, e o que ainda depende de adoção.
Entregue e verificável hoje
- A evidência está publicada e pode ser baixada agora.
- 277 barreiras rastreadas, com ficha e evidência arquivada.
- Dataset, checklist e fichas publicados para reuso.
- Protocolo aberto para replicação: os passos, scripts e dados permitem reexecutar a auditoria em outro design system. Até 03/08/2026, a usabilidade desse fluxo por uma equipe real não havia sido testada.
Potencial
- O efeito em escala continua potencial e depende da adoção por uma equipe mantenedora.
- A adoção do gate pode impedir a entrada de novas barreiras.
- Menos retrabalho duplicado, componentes mais longevos e auditorias não repetidas podem reduzir desperdício digital e operacional.
Como se mede sucesso
Pelo número de não conformidades únicas de nível AA sob escopo constante (mesmas páginas, mesma bateria, ambiente pinado), com quebra por severidade. Hoje: 202 no DSGov e 75 no Bold. Sucesso é a série caindo (críticas e sérias primeiro) e não regredindo, publicada no painel de conformidade. O escopo constante é o que impede a régua de ser manipulada por mudança de amostra.
Nota ambiental
Até 03/08/2026, o projeto não havia medido impacto ambiental. Reutilizar evidências abertas, evitar auditorias duplicadas e reduzir retrabalho são hipóteses de eficiência, não resultados ambientais demonstrados.
O que este estudo não fez, dito por inteiro.
- 01
Não houve teste com pessoas. A análise é documental e de código, com auditoria automatizada e inspeção heurística por um auditor. Sem teste com usuários, sem participação de pessoas com deficiência, sem leitor de tela operado pelo autor, sem segundo avaliador.
- 02
A cobertura automatizada alcança cerca de um sexto dos critérios WCAG (Fischer, Lundell e Gamalielsson, 2025). O restante depende de inspeção manual, que tem limite de escala com um único auditor.
- 03
É um retrato de setembro a novembro de 2025. Os sistemas mudam; o número é datado.
- 04
A propagação da barreira pelos serviços consumidores é um mecanismo estrutural da adoção, tratado com linguagem condicional. Não foi medido efeito em nenhum serviço derivado.
- 05
O vínculo do autor com a UFSC é declarado. Mitigações: ferramenta independente, procedimento idêntico, e proporção crítica interna do Bold maior que a do DSGov (40,0% contra 22,3%).
Cada limitação é também o próximo passo. Nada aqui é escondido porque nada aqui precisa ser.
Para onde a evidência pode crescer.
- 01
Sessões com pessoas com deficiência e leitores de tela, para validar em uso as barreiras que a auditoria de código apontou.
- 02
Ampliar a inspeção manual e incluir segundo avaliador, aumentando a cobertura além do que a automação alcança.
- 03
Levar o protocolo a uma equipe mantenedora, para testar o gate de não-regressão em operação real.
- 04
Repetir a auditoria em novos snapshots, transformando o retrato em série temporal.
Estes são passos planejados. Esta página não afirma que qualquer um deles já ocorreu.
Fonte, dados e créditos.
Fonte primária
- Monografia completa (PDF, 86 páginas)
- Registro do depósito, Repositório Institucional da UFSC(link externo)
- Versão arquivada com DOI, Zenodo(link externo)
- Dataset aberto, scripts e relatórios (GitHub)(link externo)
Dados sob CC BY 4.0, scripts sob MIT.
Crédito acadêmico
- Autor
- Thiago Kenji Corrêa Xikota
- Orientador
- Prof. Raul Sidnei Wazlawick
- Banca
- Raul Sidnei Wazlawick, Berenice Santos Gonçalves, Fabiane Barreto Vavassori Benitti
- Instituição
- Universidade Federal de Santa Catarina, Bacharelado em Ciências da Computação
- Defesa
- 10 de dezembro de 2025, nota 10
Um trabalho derivado da mesma pesquisa foi aprovado na lista oficial do Fórum BrasilGov Academy 2026 sob o título Inclusão por Padrão (circuito acadêmico). Acessibilidade por Padrão é o nome do protocolo no circuito de design. Mesma pesquisa, dois circuitos, declarados.
Acessibilidade desta página.
Esta página busca conformidade com WCAG 2.2 nível AA. Uma página que argumenta por acessibilidade tem a obrigação de ser acessível.
- Status de conformidade
- Atende aos critérios WCAG 2.2 nível AA cobertos por esta autoavaliação
- Data da avaliação
- 4 de agosto de 2026
- Método
- Autoavaliação com axe, Lighthouse e checklist manual por um avaliador. Inclui os critérios 2.4.11, Foco não encoberto (mínimo), e 2.5.8, Tamanho do alvo (mínimo). Sem teste com usuários e sem avaliador externo.
- Resultado e evidência
axe: zero violações. Lighthouse de acessibilidade: 100. A nota permanece ligada ao relatório completo para que você verifique o que ela não mostra.
Auditoria completa desta página
Encontrou uma barreira aqui? Escreva para thiagoxikota@gmail.com. O relato será usado para revisar esta autoavaliação.
A prova está aberta
Tudo o que sustenta este case é público: monografia depositada, versão arquivada com DOI e dataset com hashes SHA-256. Confira o método, reproduza a contagem e refute o que não se sustentar.
Se quiser discutir a evidência ou o protocolo, o contato continua aberto.
Conversar sobre o protocolo