Acessibilidade para Programadores: Construir Código Inclusivo
Os programadores são os arquitetos da acessibilidade ao nível da implementação. Enquanto os designers definem as bases visuais e de interação, é o código que, em última análise, determina se um website funciona com navegação por teclado, comunica corretamente com leitores de ecrã e mantém a acessibilidade em diferentes navegadores e dispositivos.
A boa notícia é que a maioria das boas práticas de acessibilidade está alinhada com as boas práticas gerais de código limpo, semântico e conforme às normas. Escrever código acessível não é adicionar complexidade — é escrever código corretamente desde o início.
HTML Semântico em Primeiro Lugar
A coisa mais impactante que pode fazer pela acessibilidade é utilizar corretamente os elementos HTML semânticos. O HTML5 fornece um vocabulário rico de elementos que possuem significado inerente e funcionalidades de acessibilidade. Um elemento <button> é automaticamente focável, ativável pelo teclado e anunciado como botão pelos leitores de ecrã. Um <div> com um handler onclick não tem nenhuma destas funcionalidades sem trabalho adicional significativo.
Utilize <nav> para regiões de navegação, <main> para o conteúdo principal, <header> e <footer> para as respetivas secções, <section> e <article> para áreas de conteúdo, <h1> a <h6> para cabeçalhos na ordem hierárquica correta, <ul> e <ol> para listas, <table> com <th> para dados tabulares, <label> com atributos for para controlos de formulário, e elementos nativos <button> e <a> para controlos interativos.
Estes elementos criam uma árvore de acessibilidade que as tecnologias de apoio utilizam para apresentar o seu conteúdo aos utilizadores. Quando os utiliza corretamente, grande parte da acessibilidade é tratada automaticamente.
Estrutura de Cabeçalhos
Os cabeçalhos criam a estrutura do contorno da sua página. Os utilizadores de leitores de ecrã navegam frequentemente por cabeçalhos para compreender a organização do conteúdo e encontrar secções específicas. Cada página deve ter exatamente um <h1>, e os cabeçalhos devem seguir uma hierarquia lógica sem saltar níveis — um <h3> não deve seguir um <h1> sem um <h2> entre eles.
Nunca utilize elementos de cabeçalho para estilização visual. Se precisa de texto grande e a negrito que não seja um cabeçalho, utilize CSS noutro elemento. Inversamente, se o conteúdo funciona como cabeçalho, marque-o como tal independentemente da sua apresentação visual.
Acessibilidade por Teclado
Toda a funcionalidade deve ser operável apenas através de uma interface de teclado. Isto significa que cada elemento interativo — ligações, botões, controlos de formulário, menus, modais, sliders, separadores — deve ser alcançável através da tecla Tab (ou Shift+Tab para recuar), ativável com Enter ou Espaço, e dispensável quando apropriado.
Nunca crie armadilhas de teclado onde os utilizadores possam entrar num elemento com Tab mas não possam sair. Os diálogos modais devem prender o foco dentro do diálogo enquanto abertos e devolver o foco ao elemento que os acionou quando fechados, mas pressionar Escape deve sempre fechar o diálogo.
Garanta que a ordem do foco segue uma sequência lógica que corresponde ao layout visual. A ordem do DOM deve geralmente corresponder à apresentação visual. Evite utilizar valores positivos de tabindex, que sobrepõem a ordem natural do foco e criam confusão. Utilize tabindex="0" para tornar elementos não interativos focáveis quando necessário, e tabindex="-1" para elementos que devem ser focáveis apenas programaticamente.
Idioma da Página
Defina o idioma predefinido de cada página utilizando o atributo lang no elemento <html>. Isto indica aos leitores de ecrã que regras de pronúncia utilizar. Se o idioma muda dentro do conteúdo — por exemplo, uma frase em francês numa página em português — marque a alteração com um atributo lang no elemento que a contém.
Acessibilidade de Formulários
Os formulários são onde os utilizadores fornecem dados, e são uma fonte frequente de falhas de acessibilidade. Cada controlo de formulário deve ter uma etiqueta associada programaticamente, tipicamente utilizando o elemento <label> com um atributo for que corresponda ao id do controlo. Agrupe controlos relacionados utilizando <fieldset> e <legend>.
Quando são detetados erros na introdução de dados, identifique o campo com erro e descreva o erro em texto. Forneça sugestões de correção sempre que possível. Para campos que aceitam formatos específicos, forneça instruções claras sobre o formato esperado. Utilize o atributo autocomplete para ativar o preenchimento automático do navegador para campos comuns como nome, email, morada e número de telefone.
As mensagens de estado que não recebem foco — como "item adicionado ao carrinho" ou "3 resultados encontrados" — devem ser anunciadas aos utilizadores de leitores de ecrã através de regiões ARIA live ou funções de estado.
Texto Alternativo
Cada imagem não decorativa deve ter texto alternativo significativo que descreva o seu conteúdo ou função. Para imagens informativas, descreva o que a imagem transmite. Para imagens funcionais (como um logótipo que liga à página inicial), descreva a função. Para imagens decorativas que não adicionam informação, utilize um atributo alt vazio (alt="") para que os leitores de ecrã as ignorem completamente.
Imagens complexas como gráficos, diagramas ou infográficos podem necessitar de descrições mais longas fornecidas através de uma legenda, texto adjacente ou descrição detalhada ligada.
WAI-ARIA
A especificação Accessible Rich Internet Applications fornece semântica adicional para situações em que o HTML nativo é insuficiente. O ARIA permite comunicar funções, estados e propriedades às tecnologias de apoio para widgets personalizados e conteúdo dinâmico.
No entanto, o ARIA deve ser utilizado criteriosamente. A primeira regra do ARIA é: se pode utilizar um elemento HTML nativo que tenha a semântica e o comportamento de que precisa, faça-o. O ARIA não adiciona funcionalidade — apenas adiciona semântica. Um <div role="button"> ainda precisa de JavaScript para o tratamento do teclado, enquanto um <button> nativo o trata automaticamente.
Utilize funções de marco ARIA (ou os seus equivalentes HTML5) para definir regiões da página. Utilize aria-label e aria-labelledby para fornecer nomes acessíveis quando o texto visível é insuficiente. Utilize aria-expanded, aria-selected, aria-checked e outros atributos de estado para comunicar o estado atual de widgets interativos. Utilize regiões aria-live para anunciar atualizações de conteúdo dinâmico.
Design Responsivo e Refluxo
O conteúdo deve ser apresentável sem perda de informação a 320 píxeis CSS de largura sem necessitar de deslocamento horizontal. Isto garante que os utilizadores que ampliam a 400% num ecrã de computador padrão possam ainda aceder a todo o conteúdo. Conceba os seus layouts para refluir o conteúdo numa única coluna em larguras estreitas em vez de exigir deslocamento em duas dimensões.
Ligações de Salto
Forneça um mecanismo para os utilizadores de teclado ignorarem blocos de conteúdo repetidos, como menus de navegação, e saltarem diretamente para o conteúdo principal. A implementação mais comum é uma ligação "Saltar para o conteúdo principal" que é o primeiro elemento focável na página e se torna visível quando focada.
Lista de Verificação de Testes para Programadores
Antes de implementar qualquer funcionalidade, verifique: toda a funcionalidade funciona apenas com teclado; a ordem do foco é lógica; o foco é visível em todos os elementos interativos; todas as imagens têm texto alternativo apropriado; todos os controlos de formulário têm etiquetas; o idioma da página está definido; a hierarquia de cabeçalhos está correta; o ARIA é utilizado corretamente e apenas quando necessário; o conteúdo reflui a 320px de largura; e as atualizações de conteúdo dinâmico são anunciadas aos leitores de ecrã.
Nesta secção
O seu website é acessível?
Analise o seu website gratuitamente e obtenha a sua pontuação WCAG em poucos minutos.
Analise o seu site gratuitamente