Quem não enxerga bem também precisa marcar consulta
Acessibilidade não é widget nem selo. Priorize jornadas essenciais, siga WCAG 2.2 e combine testes automáticos, manuais e com pessoas.
Comece pelas jornadas essenciais: entender quem atende, localizar a clínica e iniciar contato. Adote WCAG 2.2 como referência técnica, teste teclado, foco, zoom, contraste, leitor de tela e erros. Automação encontra parte das barreiras, mas não certifica conformidade nem substitui avaliação humana.
- Use elementos nativos e ordem de leitura coerente antes de ARIA.
- Teste toda ação com teclado, zoom e tecnologias assistivas.
- Priorize bloqueios reais e registre escopo, navegador e evidência.
- Não publique selo ou “100% acessível” baseado apenas em ferramenta.

Uma pessoa pode ter baixa visão, não usar mouse, navegar com leitor de tela, precisar de legendas, ter dificuldade cognitiva ou estar temporariamente com o braço imobilizado. Também pode tentar localizar a clínica sob luz forte, com zoom e conexão ruim. Acessibilidade considera essa variação no projeto, no conteúdo e na operação. Ela não cabe em um botão flutuante e não termina quando um scanner mostra zero erros.
Para a gestão, o ponto de partida é a tarefa: a pessoa consegue identificar a clínica, compreender o serviço, conferir localização e iniciar contato sem depender de uma única forma de perceber ou operar? A resposta deve ser testada em páginas inteiras, incluindo cabeçalho, consentimento, mapa, formulário, mensagens de erro, WhatsApp e conteúdo incorporado. Um componente correto dentro de uma jornada bloqueada não resolve o acesso.
A obrigação legal e a referência técnica
O artigo 63 da Lei Brasileira de Inclusão determina acessibilidade nos sites mantidos por empresas com sede ou representação comercial no país e por órgãos de governo, garantindo acesso às informações conforme melhores práticas e diretrizes internacionais. Isso afasta a ideia de acessibilidade como gentileza opcional. Ao mesmo tempo, este artigo não substitui parecer jurídico sobre escopo, responsabilidade, prova ou remediação de uma clínica específica.
A WCAG 2.2 é uma Recomendação do W3C para acessibilidade de conteúdo web. Ela organiza critérios sob quatro princípios: perceptível, operável, compreensível e robusto. Os níveis A, AA e AAA dependem de conjuntos de critérios e dos requisitos de conformidade; os documentos Understanding explicam os critérios, mas são informativos. Conformidade se aplica a páginas completas: não é correto excluir um formulário ou terceiro que integra a página porque é difícil de corrigir.
Comece pelas jornadas que sustentam a decisão
Auditar todo o site sem prioridade pode gerar uma lista extensa e pouco acionável. Use os Easy Checks do W3C apenas como primeira revisão e escolha três a cinco tarefas essenciais: entender quem atende, conhecer um serviço, localizar a clínica, escolher um canal e enviar um pedido de contato. Inclua estados de sucesso e falha. Se o formulário apaga tudo depois de um erro ou o foco some atrás do banner, a barreira está na tarefa, ainda que cada tela pareça bonita.
| Tarefa | Barreira comum | Primeiro teste | Evidência de correção |
|---|---|---|---|
| Identificar a clínica | Título genérico e ordem visual diferente da leitura. | Navegar por headings e ler a página em sequência. | Título único, hierarquia coerente e conteúdo compreensível. |
| Conhecer o serviço | Texto em imagem ou vídeo sem alternativa. | Desativar imagens e conferir legenda e transcrição. | Informação equivalente disponível em formato acessível. |
| Localizar endereço | Mapa sem endereço em texto ou link utilizável. | Usar teclado e leitor de tela para obter o destino. | Endereço, instrução e link nomeado funcionam sem o mapa. |
| Escolher contato | Ícone sem nome, alvo pequeno ou foco encoberto. | Percorrer com Tab, zoom e toque em tela estreita. | Nome acessível, foco visível e alvo operável. |
| Enviar formulário | Rótulo ausente e erro indicado só por cor. | Forçar erros e tentar recuperar sem mouse. | Mensagem ligada ao campo, instrução e dados preservados. |
| Ler política | Modal prende teclado ou texto não reflui no zoom. | Usar 200% e 400%, orientação e tecla Escape. | Conteúdo permanece legível e o foco retorna corretamente. |
A página sobre o que um site odontológico precisa ter ajuda a listar os conteúdos essenciais; este guia acrescenta a pergunta “por quantas formas essa informação pode ser percebida e operada?”. A resposta não é criar uma versão separada inferior. É fazer a jornada principal funcionar com estrutura, alternativas e interação compatível.
Uma ordem de correção que reduz bloqueios
Da base técnica à manutenção
- 1
Semântica e nome
Use títulos, listas, links, botões, rótulos e campos nativos conforme sua função. O guia de práticas ARIA apoia widgets específicos; ARIA pode complementar, mas não transforma um elemento errado em controle confiável. - 2
Teclado e foco
Toda ação deve funcionar sem mouse; a ordem precisa acompanhar a leitura; foco deve permanecer visível, não ficar preso e retornar ao ponto certo após diálogos. - 3
Percepção e reorganização
Garanta contraste, zoom, orientação, texto redimensionável, espaço e conteúdo que se reorganiza sem exigir rolagem em duas direções na situação coberta pelo critério. - 4
Alternativas e linguagem
Descreva imagens conforme sua função, forneça legenda e transcrição quando aplicável, explique siglas e escreva instruções que não dependam só de cor, som ou posição. - 5
Erros e autenticação
Identifique o problema, preserve entradas, ofereça instrução e evite barreiras cognitivas desnecessárias. WCAG 2.2 acrescenta critérios sobre entrada redundante e autenticação acessível. - 6
Regressão
Transforme correções repetíveis em testes e critérios de aceite, mantendo revisão manual para leitura, propósito, ordem e interoperabilidade.
Por que automação, overlay e selo não bastam
Scanners encontram ausência de nome, contraste calculável, atributos inválidos e alguns padrões de estrutura. São valiosos para cobertura frequente e regressão. Porém, uma ferramenta não sabe sozinha se o texto alternativo comunica a função, se a ordem faz sentido, se a mensagem de erro ajuda, se o leitor de tela anuncia uma mudança no momento certo ou se uma pessoa consegue concluir a tarefa. O W3C declara explicitamente que nenhuma ferramenta isolada determina se um site atende aos padrões.
Overlays ou widgets podem oferecer preferências específicas, mas não reparam automaticamente HTML, ordem, rótulos, documentos, integrações e processo editorial. Eles também entram na própria superfície que precisa ser testada. Não trate instalação como conformidade. Exija inventário do que o recurso modifica, compatibilidade, privacidade, impacto de performance, forma de desligar, suporte e evidência de teste com tecnologias assistivas.
Selos sem declaração de escopo criam falsa segurança. Um relatório sério informa URL ou amostra, data, versão da WCAG, nível, navegadores, tecnologias assistivas, métodos, exclusões, problemas restantes e responsável. A orientação do W3C para declarações de acessibilidade ajuda a comunicar compromisso, medidas, limitações e contato. “100% acessível” apaga a variabilidade de conteúdo, terceiro, dispositivo e pessoa.
Teste manual, tecnologia assistiva e participação de pessoas
Uma rodada mínima inclui teclado, foco, zoom, reorganização do conteúdo, contraste, títulos, nomes acessíveis, formulários, erros, movimento e alternativas de mídia. Depois, leitor de tela e outras tecnologias relevantes ao público e ao escopo ajudam a verificar interoperabilidade. Testar apenas no navegador da equipe deixa lacunas; registrar versão, sistema e configuração permite repetir o achado. Para a relação entre estabilidade e experiência, veja site lento e agendamento.
Pessoas com deficiência trazem barreiras e estratégias que uma checklist não antecipa. A participação deve ter tarefas realistas, remuneração e consentimento adequados, proteção de dados e espaço para observação sem transformar uma pessoa em representante de todas. Combine essa contribuição com avaliação experiente e critérios técnicos. Quando um achado divergir da automação, investigue a tarefa real em vez de descartar a experiência.
| Camada | Boa para | Não resolve sozinha | Frequência sugerida |
|---|---|---|---|
| Automação | Erros programáveis e regressões frequentes. | Propósito, qualidade, leitura e conformidade completa. | A cada mudança relevante e na validação contínua. |
| Revisão manual | Teclado, foco, zoom, estrutura, conteúdo e estados. | Diversidade completa de uso e tecnologia. | Antes de release e por amostra periódica. |
| Tecnologia assistiva | Interoperabilidade e anúncio da interface. | Necessidades de todas as pessoas e contextos. | Jornadas essenciais e componentes novos. |
| Pessoas com deficiência | Barreiras reais, compreensão e estratégias de uso. | Cobertura normativa de todos os critérios. | Ciclos de pesquisa e após mudanças materiais. |
| Revisão jurídica | Obrigações, risco e resposta no caso concreto. | Implementação técnica e experiência cotidiana. | Conforme escopo, incidente e mudança normativa. |
O limite atual da Candea
A Candea mantém uma base técnica limitada de responsividade, teclado, foco, semântica e verificações automatizadas em superfícies selecionadas. Essa base é útil para prevenção e regressão, mas não equivale a certificação WCAG 2.2, conformidade com a LBI ou auditoria humana completa. Escopo, páginas, navegadores, tecnologias assistivas e problemas conhecidos precisam acompanhar qualquer afirmação.
A Candea é adequada quando a clínica procura site gerido e aceita tratar acessibilidade como trabalho contínuo, com prioridades e validação de escopo. Não é a escolha suficiente se o contrato exige imediatamente certificação independente, auditoria jurídica abrangente ou suporte especializado contínuo a um conjunto de tecnologias assistivas que não esteja incluído. Nesse cenário, contrate avaliação especializada e coordene a correção com o fornecedor do site. Veja como verificar uma entrega em demonstração da Candea.
Plano verificável de 30 dias
Entregáveis para sair do discurso
- Definir três a cinco tarefas essenciais, páginas completas, nível WCAG 2.2 adotado e integrações incluídas.
- Executar automação e revisão manual com teclado, foco, zoom, reorganização, contraste, estrutura, formulário e erros.
- Registrar cada barreira com tarefa, critério relacionado, ambiente, evidência, gravidade, responsável e prazo.
- Corrigir primeiro bloqueios de informação e contato, repetir o mesmo roteiro e anexar evidência comparável.
- Planejar teste com tecnologias assistivas e participação remunerada de pessoas com deficiência no escopo prioritário.
- Criar testes de regressão para regras mecânicas e agenda de revisão manual para conteúdo e componentes novos.
- Publicar um canal acessível para relatar barreiras e um compromisso que declare limites sem usar selo absoluto.
Acessibilidade madura aparece quando a clínica consegue mostrar quais tarefas avaliou, quais barreiras corrigiu, o que ainda falta e quando revisará novamente. Esse registro é mais útil do que uma nota isolada: orienta orçamento, fornecedor e manutenção. Para linguagem clara e conteúdo verificável, o guia de SEO para dentistas oferece princípios complementares, sem reduzir acessibilidade a uma técnica de ranking.
Estado da Candea neste artigo
Verificado na data de atualização. Recursos limitados ou planejados não devem ser tratados como disponíveis para toda clínica.
- Disponibilidade limitadaA Candea aplica uma base técnica limitada de responsividade, teclado, foco, semântica e verificações automatizadas; isso não certifica conformidade WCAG 2.2 ou jurídica.
- DisponívelA Candea oferece criação e manutenção gerida de site odontológico, com escopo de acessibilidade que deve ser confirmado e testado na jornada contratada.
Perguntas frequentes
O artigo 63 da LBI se aplica a sites de empresas?
O texto legal torna obrigatória a acessibilidade em sites mantidos por empresas com sede ou representação comercial no Brasil. A aplicação completa ao caso deve ser avaliada juridicamente.
Um plugin torna o site odontológico acessível?
Não sozinho. Pode apoiar funções específicas, mas não corrige necessariamente semântica, teclado, conteúdo, documentos, integrações ou decisões de projeto.
Teste automático é suficiente para aprovar a página?
Não. O W3C afirma que nenhuma ferramenta isolada determina conformidade. Automação precisa ser combinada com avaliação humana, manual e por tecnologias assistivas.
Atender WCAG 2.2 significa atender todas as pessoas?
Não. A WCAG cobre ampla variedade de barreiras, mas reconhece que não atende todas as necessidades e combinações de deficiência. Participação e melhoria contínua permanecem necessárias.
Acessibilidade melhora o SEO do site?
Algumas boas práticas se sobrepõem, como estrutura e clareza, mas acessibilidade tem finalidade própria. Não deve ser reduzida a tática de ranking nem promessa de tráfego.
Afirmações, fontes e limites
O artigo 63 torna obrigatória a acessibilidade em sites mantidos por empresas com sede ou representação comercial no Brasil e por órgãos de governo.
Presidência da República — Lei Brasileira de Inclusão, art. 63Brasil · conferida em 14/08/2026 · vigente. Limite: Este artigo não fornece parecer jurídico nem determina sozinho todo o escopo de obrigação, responsabilidade, prova ou remediação aplicável à clínica.
A Recomendação WCAG 2.2 organiza critérios testáveis sob os princípios perceptível, operável, compreensível e robusto, com níveis e requisitos de conformidade.
W3C — Web Content Accessibility Guidelines 2.2Padrão técnico internacional · conferida em 14/08/2026 · vigente. Limite: WCAG cobre amplo conjunto de barreiras, mas não todas as necessidades; uma declaração de conformidade exige escopo, nível, páginas inteiras e métodos adequados.
A orientação oficial afirma que ferramentas ajudam a avaliar, mas nenhuma ferramenta isolada determina conformidade; avaliação humana qualificada é necessária.
W3C WAI — Evaluating Web Accessibility OverviewOrientação técnica internacional · conferida em 14/08/2026 · vigente. Limite: A página oferece visão geral; avaliação completa requer método, amostra, tecnologias assistivas, conhecimento e participação de pessoas.
Fornece explicações informativas dos critérios e conceitos da WCAG 2.2, incluindo teclado, foco, reorganização no zoom, formulários e autenticação.
W3C WAI — Understanding WCAG 2.2Orientação técnica internacional · conferida em 14/08/2026 · vigente. Limite: Os documentos Understanding são informativos e não fazem parte dos requisitos normativos da WCAG nem substituem avaliação de conformidade.
Oferece verificações iniciais de título, alternativas, headings, contraste, zoom, teclado, foco, formulários e mídia para uma primeira revisão.
W3C WAI — Easy Checks, a first reviewOrientação técnica internacional · conferida em 14/08/2026 · vigente. Limite: Os próprios Easy Checks cobrem poucos problemas e não constituem avaliação definitiva ou abrangente de acessibilidade.
Apresenta padrões, práticas de teclado, nomes e propriedades para widgets acessíveis baseados em ARIA, com exemplos e avisos de implementação.
W3C WAI — ARIA Authoring Practices GuideOrientação técnica internacional · conferida em 14/08/2026 · vigente. Limite: Copiar ARIA ou um exemplo não garante qualidade, compatibilidade, WCAG ou funcionamento no contexto; HTML nativo deve ser preferido quando adequado.
Orienta declarações de acessibilidade com compromisso, padrão aplicado, medidas, limitações conhecidas, ambientes e canal de retorno.
W3C WAI — Developing an Accessibility StatementOrientação técnica internacional · conferida em 14/08/2026 · vigente. Limite: Uma declaração comunica escopo e trabalho; não prova conformidade, não corrige barreiras e não substitui obrigações jurídicas aplicáveis.
Guia produzido pela equipe Candea com apoio de inteligência artificial e publicado após verificações automáticas de fonte, de conformidade e de profundidade. A responsabilidade editorial é da Candea. Como produzimos e o que o nosso build recusa publicar.
Este guia resolveu sua dúvida?
Sua resposta ajuda a escolher a próxima melhoria.
Continue neste assunto
- Busca com IA: o que muda para a clínica odontológica
A IA pode sintetizar respostas antes do clique, mas não cria atalho secreto. Clareza, rastreabilidade, conteúdo original e presença local continuam sendo a base.
- Candea vs Wix para dentista: qual faz sentido?
Wix oferece autonomia e um conjunto amplo de ferramentas. A Candea combina site gerido e operação odontológica. Decida pelo trabalho real, não pelo número de recursos.
- O risco de depender só do Instagram na clínica
Instagram pode ser um canal útil, mas concentrar identidade, alcance e contato em uma conta terceirizada cria um ponto único de falha.
Este guia faz parte de Presença digital, com 18 guias sobre o assunto.
Quer avaliar o mecanismo na sua própria clínica?
A gente prepara uma demonstração do site com escopo e limites claros. Você vê antes de decidir se faz sentido continuar.
Pedir uma demonstração