Acessibilidade digital

Como contratar SaaS acessível? Cláusulas contratuais, critérios de aceitação e fluxo de homologação (dimensão: Digital)

Dimensão: Digital. Resposta direta: para contratar um SaaS acessível, inclua no processo de seleção e no contrato (1) requisitos normativos concretos (ex.: WCAG nível alvo), (2) evidência técnica prévia (ACR / VPAT atualizado, auditoria independente, demonstração em cenários reais), (3) critérios de aceitação mensuráveis (testes automatizados, testes manuais com teclado e leitores de tela, testes com usuários com deficiência), (4) compromissos contratuais de correção (plano de remediação com prazos e marcos) e (5) governança pós-contrato (SLA, relatório de acessibilidade, atualizações e fluxo-down para subcontractados). Este artigo delimita o foco: cláusulas e fluxo de homologação aplicáveis à compra/adoção de SaaS (web e mobile) por organizações públicas ou privadas no Brasil; não trata de aspectos legais específicos de licitações públicas além das referências citadas nem substitui consulta jurídica técnica.

Redação Hub de Acessibilidade · 2026-10-09

Reunião de três profissionais e uma pessoa com deficiência visual em sala iluminada, avaliando evidências de acessibilidade em laptop e documentos; um dos participantes aponta para a tela enquanto outro toma notas em papel rotulado “Relatório de Acessibilidade”. — Ilustração gerada por IA

A pergunta que este texto responde

Como gestores devem estruturar cláusulas contratuais, critérios de aceitação e um fluxo de homologação para garantir que um SaaS seja entregue e mantido de forma acessível aos usuários, incluindo pessoas com deficiência? O foco é a dimensão digital: requisitos técnicos, verificação e mecanismos contratuais práticos aplicáveis a SaaS (aplicações web e mobile entregues como serviço).

Escopo e limites (delimitação)

Inclui: definição de padrões (WCAG/versão alvo), evidência prévia (ACR/VPAT), tipos de teste (automático, manual, com usuários), exemplo de critérios de aceitação, etapas do fluxo de homologação e cláusulas contratuais sugeridas. Exclui: redação legal final, orientação jurídica personalizada e detalhes de processos licitatórios específicos (para casos de licitação pública consulte área jurídica e normas aplicáveis).

Princípios e referências base

Use referências técnicas reconhecidas como base do requisito. No Brasil, a Lei Brasileira de Inclusão (Lei nº 13.146/2015) e o eMAG (Modelo de Acessibilidade em Governo Eletrônico) orientam políticas públicas; internacionalmente, adote as Web Content Accessibility Guidelines (WCAG) como critério técnico e considere EN 301 549 ou Section 508 quando aplicável. Para relatórios de conformidade, peça um ACR/VPAT atualizado segundo o template do ITI/VPAT. Essas referências servem para definir requisitos, métodos de teste e níveis aceitáveis de conformidade.

Principais cláusulas contratuais (o que exigir no contrato)

1) Obrigação de conformidade técnica e nível alvo: o fornecedor deve declarar e garantir conformidade com WCAG (ex.: WCAG 2.1 ou 2.2, nível AA) para o escopo funcional contratado.

2) Entregáveis de evidência antes da assinatura/ativação: ACR/VPAT atualizados; relatório de auditoria independente (se aplicável); demonstração operacional dos fluxos críticos com AT (leitores de tela).

3) Acesso para testes: acesso a ambiente de staging com dados de teste, APIs e contas de administrador para execução de testes durante homologação.

4) Critérios de aceitação e gates de pagamento: vincule marcos de pagamento a critérios objetivos de acessibilidade (ver seção “Critérios de aceitação”).

5) Plano de remediação contratualizado: quando houver não conformidades, exigir plano com atividades, responsáveis, prazos e marcos, e obrigação de correção dentro de prazos fixos.

6) SLAs operacionais de acessibilidade: tempo de resposta para incidentes de acessibilidade, prazos de correção por severidade e relatórios periódicos.

7) Direitos de auditoria: direito do contratante de contratar auditoria técnica independente e de exigir evidências de testes (logs, resultados de ferramentas, gravações de sessões de testes com usuários).

8) Obrigações de fluxo-down: o fornecedor deve obrigar subcontractados e parceiros cuja solução interfira na experiência do usuário a cumprir os mesmos requisitos de acessibilidade.

9) Gestão de mudanças e releases: manter versão ACR/VPAT atualizada sempre que houver alteração estrutural; aprovação prévia de releases críticos se afetam fluxos acessíveis.

10) Remédios contratuais: retenção de pagamento, multas contratuais, cronograma de remediação obrigatório e, em último caso, rescisão por não conformidade persistente.

11) Exclusões razoáveis e responsabilidade: identificar responsabilidades por conteúdo fornecido pelo contratante (que não será responsabilidade do fornecedor) e limites de indenização, além da ressalva de que a conformidade pode depender de integrações externas.

12) Treinamento e documentação: obrigação do fornecedor em prover guias de uso acessíveis, material de treinamento para administradores e checklist de boas práticas para conteúdo gerado pelo cliente.

Critérios de aceitação sugeridos (prática gerenciável)

1) Defina severidades: por exemplo, Critical (bloqueia uso por pessoa com deficiência), Serious (impede parte relevante da tarefa), Minor (impacto menor de usabilidade).

2) Metas de go-live: nenhum item Critical aberto; itens Serious devem estar corrigidos ou incluídos em um Plano de Remediação contratual com prazo máximo (ex.: 30 dias) e marcos claros; número de itens Minor com plano de correção em backlog priorizado.

3) Método de verificação: a) varredura automatizada (ferramentas reconhecidas) para cobertura inicial; b) testes manuais com foco em teclado, foco visível, rotulagem semântica, ARIA e navegação; c) testes com leitores de tela e ampliadores nas combinações de navegador/plataforma acordadas; d) testes de usabilidade com pelo menos 3 a 5 pessoas com deficiência por jornada crítica quando possível; e) auditoria independente que documente evidências e recomendações.

4) Escopo de páginas/funcionalidades em homologação: liste explicitamente as jornadas críticas (login, preenchimento de formulários, checkout, criação/edição de conteúdo, dashboards).

5) Evidências aceitas: relatório da ferramenta + planilha de achados com passos para reproduzir + gravações e logs de sessão + relatório de auditoria independente + resultados de testes com usuários + ACR/VPAT atualizado.

6) Frequência e atualização de ACR/VPAT: exigir atualização a cada release major ou a cada X meses (por exemplo, a cada 6 meses) e sempre que houver alterações que impactem acessibilidade, conforme orientações de ACR/VPAT.

Esses critérios se baseiam em práticas adotadas por órgãos e guias técnicos internacionais e por cartilhas de contratação de acessibilidade.

Fluxo de homologação recomendado (passo a passo)

1) Pré-contratação / avaliação inicial: solicite ACR/VPAT atual, demo com cenários críticos e relatório de auditoria atual (se houver). Use essas informações para short-list.

2) Assinatura e provisionamento de staging: no contrato, exija ambiente de homologação que reproduza a produção.

3) Plano de testes de homologação (anexo contratual): definam casos de teste, ferramentas, combinação de plataformas, participantes para teste de usuários e cronograma.

4) Execução dos testes: realizar (a) varredura automática; (b) testes manuais por equipe técnica (incluindo checklist de WCAG); (c) testes com leitores de tela e teclado; (d) pelo menos uma rodada de testes com usuários com deficiência nas jornadas críticas. Registrar resultados e reproduzir evidências.

5) Auditoria independente (gate crítico): contratar auditoria externa (se previsto) e obter relatório técnico com classificação de itens e evidências.

6) Aceitação condicional ou rejeição: decisão baseada nos critérios de aceitação (ex.: go-live somente se não houver Criticals; Serious com cronograma contratualizado). Se rejeitado, vendor entrega Plano de Remediação e novo ciclo de testes.

7) Go-live com monitoramento: após aceitação, permitir deploy para produção com monitoramento ativo, relatório mensal de acessibilidade e correção de regressões em SLA definido.

8) Governança contínua: manutenção da ACR/VPAT atualizada, comunicação de mudanças que afetam acessibilidade, revisões periódicas e auditorias programadas (por exemplo, semestrais ou anuais).

Inclua gatilhos contratuais claros: se remediação não cumprir prazos, aplicar penalidades ou medidas de contingência previstas em contrato.

Exemplos curtos de redação (modelo para adaptar)

Abaixo trechos exemplificativos. Adapte com apoio jurídico e técnico.

1) Obrigação de conformidade: "O Fornecedor declara e garante que os Serviços atenderão, no escopo contratado, aos requisitos de acessibilidade conforme WCAG 2.1 Nível AA (ou versão/nível X), exceto itens expressamente listados e justificados no ACR/VPAT anexo."

2) Entregáveis: "Antes do início da homologação, o Fornecedor deverá entregar: (a) ACR/VPAT atualizado; (b) relatório de auditoria técnica independente (se solicitado); (c) acesso ao ambiente de staging com credenciais administrativas e dados de teste."

3) Aceitação e remediação: "A aceitação final estará condicionada à inexistência de falhas classificadas como Critical. Falhas Serious deverão ser corrigidas conforme Plano de Remediação apresentado em até 30 (trinta) dias úteis após emissão do laudo de homologação. Falhas não corrigidas sujeitarão o Fornecedor às penalidades previstas."

4) Auditoria e direito de verificação: "O Contratante terá o direito de contratar auditoria independente às custas do Contratante; caso a auditoria confirme não conformidade grave, os custos adicionais de conformidade correrão por conta do Fornecedor."

Checklist rápido para gestores (o que pedir, em ordem prática)

1) Definir nível WCAG alvo e escopo funcional (listar jornadas).

2) Solicitar ACR/VPAT atual e relatório de auditoria prévio.

3) Pedir acesso de staging e incluir prova de acessibilidade em demo comercial.

4) Anexar Plano de Testes de Homologação ao contrato com critérios objetivos (zero Criticals, prazos para Serious).

5) Exigir Plano de Remediação contratual com marcos e multas/retenção vinculadas a marcos.

6) Garantir cláusula de fluxo-down para subcontractados.

7) Prever atualização periódica do ACR/VPAT e monitoramento pós-go-live (relatórios).

8) Planejar orçamento para auditorias independentes e testes com usuários durante homologação e periodicamente.

Limites, riscos e recomendações finais

1) O ACR/VPAT é um documento informativo; não substitui auditoria técnica. Reforce evidências com testes manuais e testes com usuários.

2) Nem todo fornecedor pode alterar componentes de terceiros ou da infraestrutura; identifique dependências e registre-as no contrato e na ACR/VPAT.

3) Exija direitos claros de teste e auditoria em ambientes controlados; proteja dados e defina responsabilidades por dados de teste.

4) Consulte área jurídica para adaptar cláusulas a regimes de contratação (público ou privado) e para redação de remédios e penalidades.

5) Acessibilidade é contínua: inclua governança, treinamento e critérios de aceitação em renovações e atualizações.

Seguir essas práticas reduz risco operacional e reputacional e aumenta a probabilidade de entregar um serviço útil para todas as pessoas, incluindo pessoas com deficiência.