Declaração de acessibilidade

Última atualização: 2026-09-01

A Talaskill está comprometida em ser utilizável por todas as pessoas, incluindo quem usa tecnologias assistivas como leitores de tela, ampliadores de tela, controle por voz ou navegação somente por teclado.

Nosso compromisso

Estamos trabalhando para estar em conformidade com as Diretrizes de Acessibilidade para Conteúdo Web (WCAG) 2.1, Nível AA. Este é o padrão mais exigido pela legislação de acessibilidade em todo o mundo, e é o padrão que adotamos em toda a plataforma, não apenas em algumas páginas de exemplo.

Como verificamos

Executamos uma auditoria automatizada real — axe-core, conduzida via Playwright — em um conjunto representativo de páginas da plataforma: a página inicial pública, as páginas de cadastro, login e redefinição de senha, a listagem pública de vagas e as páginas legais, além do painel, vagas, credenciais, contratação, recursos (apelos), privacidade, avaliações, criador, guia de habilidades, jogo de descoberta e páginas de administração após o login.

Cada página é verificada em três idiomas: inglês (esquerda para direita), árabe (direita para esquerda — a direção com maior probabilidade de expor um erro que uma auditoria somente em inglês deixaria passar) e espanhol (um segundo idioma da esquerda para a direita, para detectar algo específico do comprimento do texto, e não do conteúdo em inglês). As páginas logadas são verificadas tanto como uma conta de candidato comum quanto, quando relevante, como administrador da plataforma.

O script de auditoria está versionado no código em scripts/a11y-audit.mjs e roda com um único comando, npm run check:a11y, para que possa ser executado novamente antes de qualquer lançamento, em vez de confiarmos que ele permaneça preciso com o tempo.

O que a auditoria mais recente encontrou

Até a data acima, a auditoria verificou 54 combinações de página/idioma (18 páginas distintas × 3 idiomas) e inicialmente encontrou três defeitos reais e distintos:

  • Contraste de cor insuficiente em texto atenuado e nos links de Privacidade/Termos do rodapé do site — 441 elementos afetados em 41 das 54 verificações.
  • Vários campos de formulário nas páginas de login, cadastro, redefinição de senha e perfil cujo rótulo visível não estava associado programaticamente ao campo, de modo que um leitor de tela não conseguia anunciar para que servia o campo — 57 elementos afetados em 15 verificações.
  • Dois menus suspensos — o seletor de nível de exigência de habilidade na página de contratação e o seletor de visibilidade do perfil na página de privacidade — sem nenhum nome acessível — 153 elementos afetados em 6 verificações.

O que fizemos a respeito

Os três defeitos foram corrigidos diretamente no código-fonte: as cores de texto e links foram alteradas para tons que atendem à taxa de contraste de 4,5:1 exigida pela WCAG 2.1 AA para texto de tamanho normal, cada rótulo afetado foi conectado ao seu campo, e ambos os menus suspensos receberam um nome acessível real que descreve o que controlam.

Em seguida, a mesma auditoria automatizada foi executada novamente nas 54 combinações de página/idioma e não encontrou nenhuma violação. Esse resultado — não apenas esta declaração — é o que significa aqui "respaldado por uma auditoria real".

O que isso não cobre

Queremos ser diretos sobre os limites dos testes automatizados, em vez de deixar que uma varredura limpa pareça significar mais do que realmente significa. Ferramentas como o axe-core detectam de forma confiável uma parte relevante dos defeitos de acessibilidade — rótulos ausentes, contraste insuficiente, ARIA inválido e afins —, mas, segundo a própria documentação da ferramenta, as verificações automatizadas sozinhas só conseguem captar cerca de um terço a dois quintos dos critérios de sucesso da WCAG. Elas não conseguem julgar se o texto alternativo de uma imagem realmente a descreve, se o conteúdo é lido em uma ordem sensata para alguém que navega apenas com teclado ou leitor de tela, nem se um usuário de teclado pode ficar preso em alguma parte da página.

Ainda não concluímos uma revisão manual dedicada com leitor de tela (como NVDA ou VoiceOver), um percurso completo somente por teclado em cada fluxo, nem testes com pessoas que usam tecnologia assistiva no dia a dia. Essas são lacunas reais e reconhecidas em nosso processo atual, que não estamos escondendo — fechá-las é um trabalho de acompanhamento à parte.

Mantendo isso atualizado

A lista de páginas do script de auditoria cresce à medida que a plataforma cresce, e pretendemos executá-lo antes de publicar qualquer mudança em uma página que ele cubra. Até a data desta declaração, executá-lo é uma etapa manual, não uma barreira automática na integração contínua — este projeto ainda não possui um pipeline de CI, o que é, em si, uma lacuna conhecida em como publicamos mudanças de forma geral, não específica de acessibilidade.

Diga-nos o que não está funcionando

Se você usa tecnologia assistiva e encontra na Talaskill algo que não funciona como deveria, queremos saber. Entre em contato pelo Talaskill1@gmail.com informando a página em que estava e o que aconteceu, e trataremos isso como um erro real — com a mesma seriedade que daríamos a qualquer outro defeito relatado dessa forma.