Acessibilidade

docs.scrimba.com

As pessoas acessam a web de muitas maneiras. Algumas veem a tela e movem um mouse. Algumas não conseguem ver a tela e a ouvem ler em voz alta. Algumas nunca tocam um mouse e se movem pela página com o teclado, com voz ou com um botão que pressionam. Acessibilidade é a prática de construir páginas que todos possam usar, e a maior parte dela se resume a escrever HTML da maneira como foi pensado.

Por que acessibilidade importa

Acessibilidade significa garantir que todos possam usar sua página, independentemente das circunstâncias e de como navegam. Alguém pode não conseguir ver a tela e ouvi-la em vez disso, através de software que lê a página em voz alta. Alguém pode não usar um mouse e se mover pela página com o teclado. Alguém pode precisar de texto maior ou cores mais fortes para ler confortavelmente.

Pense em um edifício com uma rampa ao lado dos degraus. A rampa ajuda pessoas que não conseguem subir escadas e não tira nada de ninguém que consiga. HTML acessível é a mesma ideia: abre a página para mais pessoas sem piorar para ninguém.

A parte tranquilizadora é que HTML é acessível para começar. Você chega a maior parte do caminho gratuitamente ao usar o elemento correto para cada pedaço de conteúdo.

Acessibilidade, frequentemente abreviada como a11y (um "a", depois onze letras, depois um "y"), é sobre sua página funcionar em toda a gama de formas como as pessoas acessam a web: leitores de tela que falam a página, navegação apenas por teclado, controle por voz, ampliação de tela e modos de exibição com cores reduzidas ou alto contraste.

O enquadramento prático que mais ajuda: HTML oferece acessibilidade como posição inicial, não como algo que você adiciona no final. A maior parte do trabalho é escolher o elemento correto e não desfazer o que o navegador já faz por você. As falhas tendem a vir de um pequeno conjunto de causas: widgets personalizados reconstruídos a partir de elementos genéricos, campos de formulário sem rótulo, contraste de cor fraco e comportamento que só responde a um mouse.

Acessibilidade é se as pessoas que usam tecnologia assistiva (software ou hardware que ajuda alguém a operar um computador, como um leitor de tela que fala a página, um dispositivo de botão pressionado em vez de clicar ou controle por voz) podem perceber, operar e entender sua página. O padrão de referência é WCAG, as Diretrizes de Acessibilidade para Conteúdo Web, organizadas em torno de quatro princípios: o conteúdo deve ser perceptível, operável, compreensível e robusto.

Duas consequências valem a pena ser lembradas. Primeiro, a mesma estrutura bem formada em que a tecnologia assistiva se baseia também é o que mecanismos de busca e outras máquinas leem do DOM (modelo em memória da página do navegador), então acessibilidade e SEO puxam na mesma direção em vez de competir por seu tempo. Segundo, em muitos lugares acessibilidade é um requisito legal para sites públicos, não um agrado. A forma útil de pensar sobre tudo isso: uma página acessível é principalmente uma página construída corretamente. Quase tudo neste capítulo é HTML padrão usado conforme pretendido.

JunoPor que acessibilidade importa Acessibilidade significa que todos podem usar sua página, quem quer que sejam e como chegarem lá. A parte legal é que HTML oferece a maior parte disso gratuitamente no momento em que você escolhe o elemento certo para o trabalho. Imagine uma rampa ao lado dos degraus: mais pessoas entram e ninguém fica pior.

JunoPor que acessibilidade importa Acessibilidade é sua página funcionando para leitores de tela, teclados, ampliadores e todos no meio. Você começa de um bom lugar porque HTML é acessível pronto para usar, então a maioria das falhas vem de desfazer isso com widgets personalizados e rótulos ausentes. Construa com os elementos certos e você já está na maior parte do caminho.

JunoPor que acessibilidade importa O padrão é WCAG e seus quatro princípios: perceptível, operável, compreensível, robusto. A mesma estrutura que ajuda um leitor de tela ajuda um rastreador de busca a ler o DOM, então isso não é um imposto separado sobre seu tempo. Trate o resto do capítulo como HTML ordinário usado conforme pretendido, porque é isso que a maioria é.

HTML semântico como fundação

A coisa única mais eficaz que você pode fazer pela acessibilidade é usar o elemento que corresponde ao significado do conteúdo, em vez de um elemento genérico estilizado para parecer certo.

HTML semântico significa escolher uma tag pelo que o conteúdo é, não por como se parece. Um título usa <h1> a <h6>. Um botão usa <button>. Um link usa <a>. Uma lista usa <ul> ou <ol>. Cada um desses já carrega significado que um leitor de tela pode anunciar, então um ouvinte sabe "isto é um botão" ou "isto é um título" sem ver.

É como rotular caixas quando você se muda de casa. Uma caixa marcada "cozinha" ajuda quem a carrega, não apenas a pessoa que a embalou. Tags semânticas rotulam seu conteúdo da mesma maneira, então o navegador e a tecnologia assistiva sabem o que cada parte é.

Na prática, isso significa usar <button> quando você quer um botão, não uma <div> que você estilizou para parecer uma. O <div> pode ser feito para parecer idêntico, mas não diz nada sobre o que é. O capítulo HTML Semântico passa pelo conjunto completo.

Elementos semânticos chegam com comportamento e significado já anexados. Um <button> é focalizável, responde a Enter e Space, e é anunciado como um botão. Um <nav> marca uma região de navegação. Títulos <h1> a <h6> formam um esboço por meio do qual um usuário de leitor de tela pode navegar, da forma como um leitor com visão escaneia uma seção.

A regra que salva mais problemas: use o elemento nativo antes de construir o seu próprio. Um <div role="button" tabindex="0"> com um manipulador de clique pode ser feito para funcionar, mas você está reimplementando foco, suporte a teclado e a função à mão, e uma dessas partes tende a escapar. Um <button> real oferece tudo isso de uma vez. Os elementos de ponto de referência (<header>, <nav>, <main>, <aside>, <footer>) fazem o mesmo trabalho em escala de página: permitem que um usuário de leitor de tela pule direto para uma região em vez de ouvir através de tudo acima dela. O capítulo HTML Semântico cobre cada um.

HTML semântico é a fundação porque o navegador mapeia cada elemento semântico para uma função na árvore de acessibilidade (a versão simplificada da página que a tecnologia assistiva lê, descrita na íntegra na seção ARIA abaixo). Um <button> recebe a função de botão, seu comportamento de foco e seu tratamento de teclado sem trabalho seu. Reconstruir a partir de um <div> e você não herda nada disso: agora você é responsável pela focalizabilidade, tratamento de tecla e a função anunciada à mão, e cada lacuna é um defeito para alguém.

Dois hábitos carregam a maior parte do peso. Dê aos títulos uma estrutura real: um <h1> para a página, depois <h2> e <h3> aninhados sem pular um nível, porque os usuários de leitores de tela navegam por título e um salto de <h2> para <h4> é lido como uma seção que desapareceu. E use os elementos de ponto de referência (<main>, <nav>, <header>, <footer>, <aside>) para que a página exponha regiões navegáveis. O modo de falha a reconhecer é "sopa de div", uma página montada quase inteiramente de <div> e <span>: renderiza perfeitamente e expõe quase nada à tecnologia assistiva, porque esses dois elementos não carregam nenhuma função.

JunoHTML semântico como fundação Escolha tags pelo que o conteúdo é, não como se parece: <button> para um botão, <h1> para um título, <a> para um link. Cada um já diz a um leitor de tela o que é, então você obtém isso gratuitamente. Uma <div> estilizada pode parecer igual e ainda não dizer nada.

JunoHTML semântico como fundação Elementos nativos vêm com foco, suporte a teclado e uma função falada já conectados, então um <button> bate uma <div> fingindo ser um. Use o elemento real antes de reconstruir, e confie em pontos de referência como <nav> e <main> para que as pessoas possam pular por aí. Esse é a maior parte do trabalho aí.

JunoHTML semântico como fundação Todo elemento semântico mapeia para uma função na árvore de acessibilidade, então <button> oferece a função, foco e teclas juntos, enquanto uma <div> oferece uma fatura para todos os três. Mantenha títulos em ordem sem níveis pulados, já que as pessoas navegam por eles. Sopa de div renderiza bem e não diz nada à tecnologia assistiva, que é exatamente o problema disso.

Alternativas de texto, rótulos, foco e teclado

Alguns conteúdos não podem falar por si. Uma imagem é invisível para um leitor de tela até você descrevê-la. Um campo de formulário é um palpite até ser rotulado. E uma página que responde apenas a um mouse deixa de fora todos que não usam um. Essas quatro áreas são onde um pouco de cuidado vai longe.

Alguns hábitos confiáveis cobrem a maior parte disso:

• Imagens precisam de texto alternativo. O atributo alt descreve uma imagem para quem não consegue vê-la. Se a imagem é apenas decorativa, um alt="" vazio diz ao leitor de tela para pulá-la.

<img src="red-fox.jpg" alt="Uma raposa vermelha enrolada dormindo na neve">

• Campos de formulário precisam de rótulos. Um <label> diz tanto ao visitante quanto ao leitor de tela o que digitar em um campo.

<label for="email">Endereço de e-mail</label>
<input id="email" type="email">

• Botões e links precisam de texto claro. "Saiba mais" por si só é unclear quando lido fora de contexto; "Saiba mais sobre preços de ingressos" faz sentido por si só.
• A ordem de teclado deve corresponder à ordem de leitura. Alguém pressionando Tab se move pela página na ordem em que os elementos aparecem em seu HTML, então mantenha essa ordem sensata.

Os capítulos Imagens e mídia e Formulários e entradas aprofundam-se no texto alternativo e rótulos.

Associe cada controle de formulário com um <label>. A forma confiável é fazer a correspondência do atributo for do rótulo com a id da entrada:

<label for="postcode">CEP</label>
<input id="postcode" type="text" name="postcode">

Agora clicar no rótulo foca o campo e um leitor de tela anuncia o rótulo quando o campo ganha foco. O capítulo Formulários e entradas cobre as variações.

Para texto alternativo, descreva a finalidade, não os pixels: alt="Logotipo da empresa" bate uma lista de cores e formas, e uma imagem decorativa leva um alt="" vazio para ser pulada em vez de lida como um nome de arquivo.

A ordem de foco segue a ordem dos elementos no DOM, então mantenha sua ordem de código correspondendo à ordem de leitura visual. Evite valores tabindex positivos (tabindex="1" e acima); eles inventam uma sequência de abas separada que é difícil de manter correta. Use tabindex="0" para adicionar um controle personalizado à ordem natural, e tabindex="-1" para tornar algo focalizável por script mas não por Tab.

Para operabilidade com teclado, a regra é curta: tudo o que você pode fazer com um mouse deve funcionar com o teclado. Se um clique abre um menu, Enter também deve. E mantenha um contorno de foco visível para que os usuários de teclado possam ver onde estão. Contraste de cor importa aqui também: WCAG pede uma proporção de contraste de pelo menos 4.5:1 entre texto normal e seu fundo e nunca confie apenas na cor para carregar significado, já que nem todos distinguem as mesmas cores.

Essas quatro áreas são todos os lugares onde o DOM tem que carregar significado que o layout visual carrega para um usuário com visão que usa mouse.

Rótulos. Um <label> vinculado a um controle por for/id, ou envolvendo a entrada, dá a esse controle seu nome acessível (o texto que a tecnologia assistiva anuncia para um elemento). Sem um rótulo, um leitor de tela lê o tipo do campo e nada sobre sua finalidade. Texto de espaço reservado não é um rótulo: desaparece na entrada e é anunciado inconsistentemente.

Alternativas de texto. alt é o nome acessível de uma <img>. Escreva-o por finalidade, não aparência. Uma imagem decorativa leva alt="" (vazio, presente mas em branco) para que seja descartado da árvore de acessibilidade; omitir alt inteiramente é diferente, e alguns leitores de tela voltam para ler o nome do arquivo, o que não ajuda ninguém.

Foco. A ordem de foco é ordem de DOM a menos que você a substitua, e tabindex positivo é quase sempre um erro porque constrói uma segunda sequência de abas que você então tem que manter contra o layout visual. Use tabindex="0" para integrar um controle personalizado à ordem natural e tabindex="-1" para tornar um elemento focalizável apenas por script, que você precisa ao mover o foco após uma ação. Mantenha um indicador de foco visível: nunca defina outline: none sem fornecer uma substituição, ou os usuários de teclado perdem a noção de sua posição. Fique atento também a uma armadilha de teclado (foco que um usuário de teclado pode mover, mas não para fora), que WCAG chama especificamente.

Teclado e contraste. Cada operação deve ser alcançável e operável por teclado, em uma ordem lógica. Para contraste, WCAG AA pede 4.5:1 em texto do corpo e 3:1 em texto grande e na borda visual de um controle, e o significado nunca deve depender apenas da cor. Um campo obrigatório marcado apenas em vermelho é invisível para alguém que não percebe essa diferença; emparelhe-o com texto ou um ícone.

JunoAlternativas de texto, rótulos, foco e teclado Quatro pequenos hábitos carregam a maioria disso: dê às imagens um alt, dê aos campos de formulário um <label>, escreva o texto do botão e link que faz sentido por si só, e mantenha a ordem de abas correspondente à ordem de leitura. Nenhum deles leva muito tempo. Imagens decorativas recebem um alt="" vazio para que sejam puladas.

JunoAlternativas de texto, rótulos, foco e teclado Ligue cada entrada a um <label> com correspondência de for e id, e escreva alt por finalidade, vazio para decorativo. Mantenha a ordem de foco como ordem de DOM e pule tabindex positivo. A linha a lembrar: qualquer coisa que um mouse possa fazer, o teclado também deve fazer, e verifique se seu contraste atinge 4.5:1.

JunoAlternativas de texto, rótulos, foco e teclado Rótulos e alt definem o nome acessível de um elemento, então um espaço reservado não é um rótulo e um alt ausente não é um vazio. Deixe o foco na ordem de DOM, evite tabindex positivo e nunca retire o contorno de foco sem substituir. Atinja 4.5:1 em texto e nunca deixe a cor ser o único sinal, ou um marcador obrigatório apenas em vermelho não alcança ninguém que não consiga ver o vermelho.

ARIA e por que não a alcançar primeiro

Há um conjunto de atributos HTML feitos especificamente para acessibilidade, chamado ARIA. É útil no lugar certo, e é uma das partes mais usadas incorretamente da plataforma, então vale a pena entender tanto o que faz quanto quando deixá-la de lado.

ARIA significa Aplicações Ricas de Internet Acessíveis. É um conjunto de atributos extras que você pode adicionar a um elemento para dizer à tecnologia assistiva mais sobre ele. O nome faz parecer como a primeira ferramenta a alcançar, e geralmente é a última.

A razão é simples: a maioria do que ARIA pode descrever, HTML já diz por si próprio. Um <button> já é anunciado como um botão. Adicionar role="button" a ele não muda nada. Se você se encontrar adicionando ARIA para explicar o que um elemento é, isso geralmente é um sinal para trocar pelo elemento HTML simples que já o diz.

Imagine uma nota adesiva adicionada a uma caixa de mudança. Se a caixa já está impressa "cozinha", uma nota adesiva lendo "cozinha" só adiciona bagunça. Guarde a nota para a caixa que não tem rótulo próprio. ARIA é para as partes de uma página que HTML não tem elemento, o que é mais raro do que parece.

ARIA adiciona três tipos de informação a um elemento: papéis (o que é, como role="dialog"), estados (sua condição atual, como aria-expanded="false"), e propriedades (relacionamentos extras, como aria-describedby apontando para algum texto de ajuda). Leitores de tela usam estes para anunciar widgets personalizados que não têm equivalente HTML nativo, como um painel de abas ou um controle deslizante.

A orientação a liderar é a primeira regra de ARIA: não use ARIA se um elemento nativo já faz o trabalho. Um <button> nativo bate <div role="button"> sempre, porque o elemento nativo traz comportamento e o atributo ARIA traz apenas um rótulo. Pior, um atributo ARIA errado ou desatualizado é pior que nenhum, porque substitui o que o navegador teria dito. Coloque aria-hidden="true" no elemento errado e você esconde conteúdo real de usuários de leitores de tela enquanto fica visível na tela. Alcance ARIA quando você está construindo um widget que HTML não tem elemento, e então siga um padrão estabelecido em vez de inventar atributos.

Comece com a coisa que ARIA edita. A árvore de acessibilidade é uma estrutura paralela que o navegador constrói ao lado do DOM. Para cada elemento, ele registra uma função (o que o elemento é: botão, link, título), seus estados e propriedades (condições e relacionamentos, como aria-expanded, aria-checked, ou disabled), e seu nome acessível e descrição (o texto que é anunciado). A tecnologia assistiva lê essa árvore, não seu CSS e não o HTML bruto.

ARIA é o vocabulário para editar essa árvore diretamente: papéis (role="tablist"), estados que mudam com o tempo (aria-selected="true"), e propriedades que descrevem relacionamentos mais estáveis (aria-labelledby, aria-controls). A primeira regra de ARIA é que se um elemento HTML nativo ou atributo já fornece o papel, estado ou propriedade que você precisa, use-o e não adicione ARIA. A razão é que ARIA muda apenas a árvore de acessibilidade e não adiciona comportamento próprio. role="button" em uma <div> faz um leitor de tela chamá-la de botão, mas não concede focalizabilidade, nenhuma manipulação de Enter ou Space, e nenhum suporte desabilitado. Você adicionaria cada um desses você mesmo, e no dia em que você esquecer um, você terá um controle que anuncia como um botão mas não age como um, o que é pior que uma <div> honesta.

Poucas regras mantêm ARIA de causar o dano que ela deveria prevenir. Prefira elementos nativos. Não substitua semântica nativa (sem role="heading" em um <button>). Não coloque elementos interativos dentro de uma subárvore marcada com aria-hidden="true", ou você cria controles focalizáveis que um leitor de tela não consegue ver. E mantenha os estados sincronizados com seu JavaScript, já que um aria-expanded desatualizado mente para o usuário. Quando você realmente precisa de ARIA, construa a partir das Práticas de Autoria WAI-ARIA, os padrões publicados para widgets comuns, em vez de compor atributos do zero. Para testar qualquer coisa disso, o inspetor de acessibilidade do navegador mostra a função, nome e estado computados para um elemento fornecido, que é exatamente o que a tecnologia assistiva receberá.

JunoARIA e por que não a alcançar primeiro ARIA é um conjunto de atributos extras que descrevem um elemento à tecnologia assistiva. Parece ser a primeira coisa a alcançar e geralmente é a última, porque um <button> real já diz que é um botão. Guarde ARIA para a parte rara de uma página que HTML não tem elemento, e mantenha todo o resto simples.

JunoARIA e por que não a alcançar primeiro ARIA adiciona papéis, estados e propriedades para widgets personalizados que HTML não tem elemento. A primeira regra de ARIA é pulá-la quando um elemento nativo já faz o trabalho, já que um atributo errado ou desatualizado é pior que nenhum. Se você está rotulando um <button> como um botão, pare e use o botão.

JunoARIA e por que não a alcançar primeiro ARIA edita a árvore de acessibilidade: papéis, estados e propriedades, e nada mais, então nunca adiciona comportamento. Essa é exatamente a razão para a primeira regra de ARIA, já que role="button" em uma <div> anuncia um botão que não tem teclas e sem foco até você construir. Mantenha os estados sincronizados com seu JavaScript, e quando você realmente precisa de um widget, copie um padrão publicado em vez de inventar atributos.

Uma auto-auditoria rápida

Você não precisa de software especializado para capturar os problemas mais comuns. Alguns testes com ferramentas que você já tem na sua máquina encontram a maioria deles, e levam apenas alguns minutos para rodar.

Aqui está uma checklist curta que você pode rodar em qualquer página:

• Coloque o mouse de lado e pressione Tab. Você consegue alcançar cada link e botão, em uma ordem que faz sentido? Você consegue ativá-los com Enter?
• Cada imagem tem um atributo alt?
• Cada campo de formulário tem um <label>?
• Seus botões e links ainda fazem sentido quando lidos por conta própria?
• O texto está claro para ler contra seu fundo?

Rodar estes em sua própria página é rápido, e captura os problemas que as pessoas encontram com mais frequência. Se a tecla Tab ficar presa em algum lugar, ou uma imagem não tiver alt, você encontrou algo que vale a pena corrigir.

Construa uma passagem repetível em seu fluxo de trabalho:

1. Teclado. Abas por toda a página. Todo elemento interativo deve ser alcançável, em uma ordem sensata, com um indicador de foco visível, e operável com Enter ou Space. Se o foco desaparecer ou ficar preso, corrija isso antes de qualquer outra coisa.
2. Títulos e pontos de referência. Confirme que há um <h1>, que títulos não pulam níveis, e que as regiões principais usam <main>, <nav> e outros pontos de referência.
3. Nomes. Cada imagem tem um alt, cada controle tem um rótulo, e cada link e botão é lido claramente fora de contexto.
4. Contraste. Verifique o texto contra seu fundo nas ferramentas de desenvolvimento do seu navegador, que relatam a proporção e sinalizam qualquer coisa que falha.

Verificadores automatizados como o painel Lighthouse nas ferramentas de desenvolvimento do Chrome ou a extensão do navegador axe capturam uma parcela útil de problemas, mas apenas uma parcela. Eles não conseguem julgar se um texto alternativo é significativo ou se uma ordem de abas faz sentido, então a passagem manual por teclado permanece essencial.

Uma auditoria funcional combina passagens automatizadas e manuais, porque a automação cobre apenas parte do terreno: a ferramenta confiável encontra alt ausente, rótulos ausentes e falhas de contraste (aproximadamente um terço dos critérios WCAG), e não consegue julgar se um texto alternativo é preciso ou uma ordem de abas é lógica.

• Automatizado. Execute axe ou Lighthouse primeiro para limpar as falhas mecânicas.
• Teclado. Coloque o mouse de lado e abas por toda, confirmando alcançabilidade, uma ordem lógica, um anel de foco visível, operabilidade completa e nenhum lugar onde o foco não consiga voltar. Essa passagem sozinha superfícies a maioria dos defeitos de widget personalizados.
• Leitor de tela. Ligue um (VoiceOver é fornecido com macOS via Cmd+F5, NVDA é um download gratuito no Windows, TalkBack é integrado no Android) e ouça alguns fluxos principais. Você está verificando se os nomes são anunciados, as funções estão certas, e as mudanças de estado são realmente faladas.
• A árvore de acessibilidade. As ferramentas de desenvolvimento do navegador mostram a função, nome e estado calculados para qualquer elemento, que diz a você o que a tecnologia assistiva realmente receberá, independente de como o elemento parece.

Execute as passagens de teclado e leitor de tela mesmo quando as ferramentas automatizadas reportarem verde, porque as coisas que elas não conseguem verificar são as coisas que mais afetam uma pessoa real usando a página.

JunoUma auto-auditoria rápida Coloque o mouse de lado e abas pela sua página: você consegue alcançar e usar tudo em uma ordem sensata? Depois verifique se cada imagem tem um alt, cada campo tem um <label> e o texto se lê claramente contra seu fundo. Alguns minutos disso capturam os problemas que as pessoas encontram mais.

JunoUma auto-auditoria rápida Faça isso rotina: abas para alcançabilidade e ordem, verifique um <h1> e sem títulos pulados, confirme nomes em imagens e controles, e leia o contraste nas ferramentas dev. Ferramentas automatizadas como axe e Lighthouse ajudam, mas eles só capturam parte disso, então continue fazendo a passagem por teclado à mão.

JunoUma auto-auditoria rápida Automação encontra alt ausente, rótulos ausentes e contraste, sobre um terço de WCAG, e julga nada sobre significado ou ordem. Portanto, emparelhe-o com uma passagem de teclado, uma escuta através de um leitor de tela e uma olhada no inspetor de acessibilidade para a função e nome calculados. Os testes que uma ferramenta não consegue rodar são os que mais importam, então execute-os você mesmo mesmo quando o relatório está verde.