Relatório de conformidade de acessibilidade (ACR): BeryX 1.0.0

ACR baseado no VPAT® 2.5 (WCAG edition), em versão simplificada: só a tabela WCAG 2.2 de nível A e AA, com a cláusula correspondente da EN 301 549. VPAT® é uma marca registada do Information Technology Industry Council (ITI).

É uma auto-avaliação da BeryxTech Não é uma auditoria externa nem uma certificação, e não afirma conformidade com a EN 301 549. Cada estado diz o que o código faz hoje e onde está a prova. Quando não verificámos, dizemo-lo.

Âmbito

• Aplicação web (app.praxis.lbostuff.tech). A SPA React de frontend/src, com as 40 rotas de frontend/src/App.tsx, nos temas escuro (por omissão) e claro e nas línguas pt, en e es. Inclui as páginas sem sessão: login e registo, definir password, partilha pública de dataset (/publico/:token), montra pública do data product (/p/dominios/:token), revisão de contrato, subprocessadores, DORA/NIS2 e o modo TV (/tv).
• Site público (praxis.lbostuff.tech). O site Next.js (repositório praxis-site) em pt, en e es: páginas do produto, documentação, RFP, segurança, preços, legal, changelog, diagnóstico e Área de Cliente.

Fora do âmbito deste relatório. Não foram avaliados e não contam como «Not Applicable»:

• os emails (digest por persona em backend/app/domain/insights/digest_email.py, verificação de conta, convites);
• as exportações em PDF (backend/app/infra/pdf.py) e os ficheiros CSV, XLSX e JSON de relatórios;
• os documentos descarregáveis do site (PDF e PPTX em /recursos);
• a consola interna da BeryxTech (/consola, só para staff);
• a API REST, o SDK, a CLI, o servidor MCP e as integrações, que não têm interface gráfica;
• as páginas de terceiros para onde a app encaminha: o checkout do Stripe e o IdP de SSO do cliente.

Método de avaliação

Verificações automáticas, que correm em cada PR. As 1 a 4 estão no job «Frontend (tsc + build)» de .github/workflows/ci.yml, a 5 no job do backend e a 6 no job «E2E (Playwright)»:

1. Lint estático eslint-plugin-jsx-a11y (frontend/eslint.config.js), com alt-text, aria-props, aria-role, click-events-have-key-events, no-static-element-interactions e label-has-associated-control como erro. A prova de que o lint chumba está em frontend/src/a11y-lint.test.ts::chumba <div onClick> sem teclado nem papel.

2. axe-core 4.13 em vitest/jsdom (frontend/src/a11y.test.tsx), com as tags wcag2a, wcag2aa, wcag21a, wcag21aa e wcag22aa. Cobre Layout, Login e registo, Modal, ConfirmDialog, Atividades, Datasets, Regras, CatalogTreemap, QualityCalendar, DomainEditor, o erro de rota e os quatro separadores da Equipa. Tem dois limites:

   • color-contrast está desligada, porque o jsdom não calcula cores;
   • heading-order só avisa.

   Das 40 rotas, só Login, Atividades, Datasets, Regras e Equipa são renderizadas como página. As restantes não são cobertas, incluindo os dashboards com gráficos, Problemas e Notificações.

3. Contraste dos tokens (frontend/scripts/check-contrast.mjs) nos dois temas: texto ≥4,5:1 e não-texto ≥3:1. Falha com um par abaixo do mínimo, com uma classe de cor sem par ou com um anel de foco de cor fixa. As falhas conhecidas ficam declaradas como followUp.

4. Testes de comportamento: prisão de foco e Esc dos diálogos (frontend/src/components/Modal.test.tsx), skip link, foco e título por rota (frontend/src/components/Layout.test.tsx, frontend/src/lib/usePageTitle.test.tsx) e avisos temporizados (frontend/src/components/Toast.test.tsx).

5. Guardas estáticas deste relatório (backend/tests/test_accessibility_conformance.py). Provam, no código da app, as ausências que o axe não vê: window.confirm, bloqueio de colar, bloqueio de orientação ou de zoom, sensores de movimento, multimédia e reordenação por CSS. No site, o equivalente é praxis-site/tests/accessibility.test.mjs, que corre no pnpm test do CI do site.

6. axe-core no browser real, nos e2e dos 10 fluxos do guião (cartão #324, docs/GUIAO_TESTES.md): @axe-core/playwright com as mesmas tags, agora com color-contrast e target-size, em cada ecrã visitado por F1–F10 (diálogos abertos incluídos). Impacto serious ou critical fora da allowlist (frontend/e2e/a11y-allowlist.json, vazia; cada entrada exige cartão e razão) falha o job (frontend/e2e/support/a11y.ts::expectNoA11yViolations). O projeto mobile (Pixel 5, 393 px) corre F2 e F3 e falha com scroll horizontal; o projeto es percorre as páginas dos fluxos em ES e falha com chaves pedidas sem tradução (frontend/e2e/support/i18n.ts::expectNoMissingTranslations).

No CI do site correm também, desde o cartão #331, o contraste dos tokens (praxis-site/scripts/check_contrast.mjs, porta do script da app, no pnpm build) e o axe no browser (praxis-site/scripts/check_a11y_browser.mjs). O axe corre com as mesmas tags na home, em /datavault e em /diagnostico, nos dois temas e com «Reduzir movimento». O mesmo script percorre o menu móvel só com teclado a 390 px e confirma que nada se mexe com a preferência ligada.

Verificações pontuais, fora do CI:

7. Browser real (Chromium com axe color-contrast e target-size) em Problemas, Regras e Equipa, nos dois temas, com as paragens de Tab medidas em Login, Conexões e Steward. Está em docs/verificacao/cartao-302/README.md; os rácios de contraste antes e depois estão em docs/verificacao/cartao-301/README.md. No site, o mesmo axe correu na página deste ACR e no RFP, em pt e en, nos dois temas, a 1280 px e a 320 px (docs/verificacao/cartao-313/README.md). Depois do cartão #331 repetiu-se nessas páginas, em /farol/energia e em /tese, e o Lighthouse (Accessibility) deu 100 na home, em /datavault e em /diagnostico, nos dois temas (docs/verificacao/cartao-331/README.md).
8. Revisão de código por critério, feita para este relatório a 2026-09-28, na app e no site.

O que não foi feito:

• auditoria externa;
• testes com pessoas com deficiência;
• sessões sistemáticas com leitores de ecrã. O frontend/README.md tem um roteiro manual de VoiceOver, mas não há registo de execução;
• medição a 200 % e 400 % de zoom e a 320 px de largura. Na app não houve nenhuma; no site só se mediu a página deste ACR, o RFP e três docs;
• axe em browser real fora dos ecrãs dos 10 fluxos do guião, e viewport móvel fora de F2 e F3;
• axe no browser nas restantes páginas do site. O CI do site cobre a home, /datavault e /diagnostico (cartão #331).

Legenda

• Supports: sem falhas conhecidas, e a nota indica a prova (teste, lint ou script do CI, guarda estática, ou a verificação feita para este relatório).
• Partially Supports: há partes que não cumprem, ou a verificação não cobriu o âmbito todo. A nota diz qual das duas e onde.
• Does Not Support: a maior parte da funcionalidade não cumpre.
• Not Applicable: não existe esse tipo de conteúdo (por exemplo, multimédia).

Regra deste relatório: nada é «Supports» só por não termos procurado.

4.1.1 Parsing. Não entra na tabela. O WCAG 2.2 retirou-o por estar obsoleto e considera-o sempre cumprido em HTML. A EN 301 549 V3.2.1 ainda o lista (9.4.1.1). Os seis critérios novos do WCAG 2.2 (2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 e 3.3.8) não têm cláusula nessa versão da norma e aparecem com «—».

Resumo

Nem a app nem o site cumprem ainda o WCAG 2.2 AA na íntegra. App: a base está no CI (estrutura, teclado, foco, títulos, diálogos, contraste dos tokens), mas faltam o score das folhas do treemap em texto, tooltips que se possam dispensar e a verificação no browser e em móvel fora dos 10 fluxos do guião (que o CI já cobre com axe, 393 px e ES desde o cartão #324). Site: tem skip link, lang por locale e tabelas marcadas. Desde o cartão #331, o contraste dos tokens e o axe no browser (home, /datavault e /diagnostico, nos dois temas) estão no CI do site. As animações param com «Reduzir movimento» e o menu móvel anuncia o estado. Faltam um controlo de pausa para quem não usa a preferência do sistema e o axe nas restantes páginas. As lacunas, com o plano de cada uma, estão em Lacunas conhecidas e plano.

Critérios WCAG 2.2 A e AA

Lacunas conhecidas e plano

Cada lacuna abaixo tem de ter cartão próprio antes de o estado mudar. Não se corrige no ACR. A data só aparece quando está agendada.

Contacto e revisão

• Feedback e formatos alternativos. Para reportar uma barreira de acessibilidade ou pedir um formato alternativo, envie um email para suporte@praxis.lbostuff.tech com o assunto «Acessibilidade». Respondemos por email. Os clientes com contrato têm os prazos de suporte do contrato.
• Revisão. Este relatório revê-se todos os anos: a próxima revisão é até 2027-09-28. Também se revê antes disso quando um critério muda de estado, quando sai uma versão major ou quando a cobertura dos e2e com axe muda — a revisão de 2026-09-28 (cartão #324) registou a entrada do axe no browser, do viewport móvel e do locale ES no CI. A de 2026-09-29 (cartão #331) passou o 2.2.2 do site a «Partially Supports» e registou a entrada do contraste e do axe no CI do site. A versão e o commit em produção estão em GET /api/v1/version.
• Declaração de acessibilidade. Este ACR é a peça para procurement. A Diretiva (UE) 2016/2102 obriga cada organismo público a tornar acessíveis os seus sites e aplicações e a publicar a sua própria declaração. Quando compra software, o que pede ao fornecedor é evidência face à EN 301 549, e é esse o papel deste relatório. Uma declaração pública da BeryxTech no modelo da Decisão de Execução (UE) 2018/1523 fica para quando os critérios em falta puderem passar a «Supports», para não publicarmos uma declaração que envelhece mal.