Guia de acessibilidade web

Introdução

Este guia foi desenvolvido como parte da iniciação científica “Internet Para Todos”, pela aluna Sarah Rodrigues Campos sob orientação da Profa. Dra. Fernanda Henriques. O objetivo é guiar desenvolvedores na construção de sites acessíveis. Os créditos de todas as imagens são do Freepik.

O que é acessibilidade web

Acessibilidade web é a possibilidade de o conteúdo e os serviços da web estarem disponíveis para todas as pessoas e de pessoas diferentes poderem  entendercompreendernavegarinteragir e contribuir com a web. Isso também inclui a possibilidade de utilizar a web em diferentes dispositivos e em diferentes locais.

Um erro comum é entender a acessibilidade como exclusiva para pessoas com deficiência. Pelo contrário, a acessibilidade é baseada no conceito de Design Universal e um de seus principais fatores é a inclusão social.

A diferença é que:

Para a maioria das pessoas, a tecnologia torna a vida mais fácil. Para uma pessoa com necessidades especiais, a tecnologia torna as coisas possíveis.
Jorge Fernandes e Francisco Godinho, 2003.

Isto é, a tecnologia é instrumento de autonomia para pessoas com deficiência. Um site sem acessibilidade é uma barreira para pessoas com deficiência, impede que tenham acesso à informação e que se comuniquem.

A acessibilidade web garante que o site tenha páginas bem estruturadas, o que é um benefício enorme para qualquer usuário. Quem nunca passou raiva tentando preencher um formulário em um site? Ou desistiu de uma compra porque o site era muito complexo?

Para donos de websites, a acessibilidade permite que consiga alcançar o público-alvo em sua totalidade. Ou seja, se converte em mais visitas, maior visibilidade e, consequentemente, mais lucro.

Diretrizes de acessibilidade web

Antes de partir pra implementação, é preciso entender alguns conceitos importantes. A primeira coisa que o desenvolvedor deve saber é que existem diretrizes mundiais de acessibilidade web, ou seja, regras estabelecidas que definem o que um site acessível deve ter.

Essas diretrizes estão reunidas em um documento chamado Diretrizes de Acessibilidade para Conteúdo Web (WCAG, atualmente na versão 2.1). A WCAG foi criada e é mantida pela Iniciativa de Acessibilidade Web (WAI), um órgão do World Wide Web Consortium (W3C).

O W3C é um consórcio internacional, ou seja uma união de organizações, com a missão de garantir o crescimento da World Wide Web (WWW ou rede mundial de computadores). Para isso, produzem protocolos, padrões e diretrizes gratuitos e abertos.

A WAI é dividida em grupos que são responsáveis pela criação de várias diretrizes de acessibilidade, como o Guia de Acessibilidade para Ferramentas de Autoria (ATAG) e o Guia de Acessibilidade para Agentes do Usuário (UAAG).

Existem outras diretrizes de acessibilidade, como as definidas pela Apple e pelo Android. No Brasil, no contexto de sites da web, a outra diretriz importante é o Modelo de Acessibilidade em Governo Eletrônico (eMAG), uma versão adaptada da WCAG para o governo brasileiro. O eMAG traz complementos importantes, como checklists de acessibilidade, que serão abordados depois neste guia.

WCAG

Para desenvolvedores, a WCAG é  o documento mais importante, que deve guiar todas as suas ações e decisões. Ela está dividida em quatro camadas de orientação:
  1. Princípios: são a base da acessibilidade. Consistem em 4 princípios: perceptível, operável, compreensível e robusto;
  2. Diretrizes: existem 13 diretrizes abaixo dos princípios. Fornecem os objetivos básicos para criar um conteúdo mais acessível. Não são testáveis;
  3. Critérios de sucesso: para cada diretriz, existem critérios de sucesso testáveis. Os critérios são encaixados em três níveis de conformidade: A, AA e AAA (mais baixo ao mais alto, respectivamente).
  4. Técnicas: para cada diretriz e critérios de sucesso, existem técnicas para alcançá-los. Existem duas categorias de técnicas: necessárias (para satisfazer o critério) e sugeridas (vão além do que é exigido).
Em resumo, os princípios definem características que o site deve ter e, no documento, são os capítulos mais abrangentes (1, 2, 3 e 4). Dentro de cada um, existem diretrizes, que são o segundo nível no documento (exemplo, o tópico 4 possui apenas uma diretriz, o subtópico 4.1). Dentro de cada diretriz, há os critérios de sucesso, que são testáveis. É ideal que os websites alcancem o nível AA de conformidade e, para isso, a WCAG apresenta diferentes técnicas. Na versão atual da WCAG, 2.1, existem 78 critérios de sucesso no total. Em adição à WCAG, existem três outros documentos, todos em inglês:
  • Como cumprir a WCAG: É uma referência rápida que pode ser usada de checklist. Tem a possibilidade de filtrar os critérios por tipo de componente, nível de conformidade, tecnologia, entre outros.
  • Compreendendo a WCAG: É um documento mais detalhado do que a WCAG. Explica os critérios a fundo, com exemplos de sucesso e falha, além de indicar quais os seus benefícios e relacionar as técnicas utilizadas.
  •  Técnicas da WCAG: Concentra todas as técnicas para satisfazer os critérios de sucesso, instruções para desenvolvedores.

Elementos da web

Neste tópico, são definidos alguns conceitos fundamentais para entender acessibilidade web. Eles serão utilizados posteriormente neste guia.

De acordo com o W3C, existem sete componentes que devem trabalhar em conjunto para que a acessibilidade web seja atingida:

  • Conteúdo: informação disponibilizada na aplicação (texto, conteúdo multimídia, código e marcação);
  • Agentes de usuário (navegadores, tocadores de mídia, entre outros);
  • Tecnologia Assistiva (T.A.): dispositivos que auxiliam pessoas com deficiência a exercer suas atividades (leitores de tela, teclados alternativos, etc);
  • Usuários (e seus conhecimentos e experiências);
  • Desenvolvedores: designers, programadores, autores e usuários que contribuem com conteúdo;
  • Ferramentas de autoria: software para criar websites;
  • Ferramentas de avaliação: verificam acessibilidade do site ou validam HTML e CSS.

Implementando acessibilidade

Por onde começar

Antes de tudo, é importante que o desenvolvedor esteja ciente de como seus usuários utilizam o site. Pessoas com deficiência fazem uso de tecnologias assistivas (T.A.) para auxiliar em suas tarefas. É importante que o site seja compatível com essas ferramentas.

Para uso da web, a mais comum é o leitor de tela, utilizado majoritariamente por pessoas com deficiência visual e intelectual. Seu funcionamento básico é ler em voz alta o conteúdo em texto trazido pelo computador. No Brasil, o leitor mais utilizado é o NVDA. Também é importante ressaltar que usuários cegos utilizam apenas o teclado e que alguns também utilizam display braille.

Pessoas com baixa visão recorrem a T.A.s como ampliadores de tela e softwares de ajuste de contraste. Usuários com deficiência motora nos membros superiores têm dificuldades em utilizar mouses e teclados. É possível utilizar uma TA que acompanhe o movimento dos olhos ou uma ponteira de cabeça.

Além das tecnologias, alguns usuários dependem de mecanismos dos próprios sites. Por exemplo, usuários surdos dependem de legendas e intérprete de libras para compreender determinados conteúdos.

Vale mencionar também que existem diferentes formas de acessar a web. Os usuários podem estar em dispositivos diversos como smartphones, computadores, tablets, entre outros. Também podem utilizar navegadores que sejam apenas texto ou outros tipos de navegadores.

Depois de ter assimilado como os usuários acessam a web, o desenvolvedor deve ter um entendimento dos critérios da WCAG. Recomenda-se que leia a WCAG em português e, caso não compreenda algum critério, acesse o documento Compreendendo a WCAG (em inglês).

No entanto, a leitura da WCAG é cansativa e muitas vezes complexa. Por isso, para ter uma noção básica, é possível acessar a seção Boas Práticas deste manual ou o conteúdo de boas práticas preparado pelo Movimento Web Para Todos.

Para uma leitura mais completa do que a lista de boas práticas, recomenda-se a Cartilha de Acessibilidade do W3C Brasil. É uma leitura leve e simples, mas possui muitas páginas, o que pode levar um certo tempo. Ela é separada nos seguintes fascículos:

  1. Fascículo I: Introdução.
  2. Fascículo II: Benefícios, Legislação e Diretrizes de Acessibilidade na Web.
  3. Fascículo III: Conhecendo o público-alvo da acessibilidade na Web.
  4. Fascículo IV: Tornando o conteúdo web acessível.

Boas práticas

Separamos algumas boas práticas por tipo de conteúdo. Para um entendimento maior, recomenda-se a leitura da WCAG.

  • Componentes
    • Todos os componentes devem ser identificados de acordo semanticamente. Exemplo: uma lista  de itens deve ser marcada com a tag UL ou LI.
    • Em geral, a cor do componente deve ter contraste suficiente em relação a cor de fundo. Para verificar, é recomendada a ferramenta Contrast Checker.
    • Componentes interativos devem ter uma área clicável de no mínimo 54px por 54px.
    • Devem ser acessíveis via teclado.
    • Se for um componente complexo que não existe no HTML, é possível recorrer ao WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications), uma especificação que complementa o HTML.
  • Conteúdo multimídia
    • Todo conteúdo não-textual deve ter uma alternativa em texto.
    • Imagens não decorativas devem ter texto alternativo. As decorativas devem ter atributo alt vazio (alt=””). Para decidir se a imagem deve ter texto alternativo, o W3C preparou uma “árvore de decisão sobre alt“.
    • Vídeos devem ter legenda e intérprete de libras (caso tenham áudio) e, se for o caso, audiodescrição.
    • Áudios devem ter transcrição e serem identificados com legenda. Para a legenda, recomenda-se o uso das tags figure e figcaption.
  • Texto
    • Blocos de texto devem ser alinhados à esquerda.
    • Os textos devem ter espaçamento suficiente entre as letras, parágrafos e palavras.
    • Títulos devem ser identificados semanticamente com as tags de cabeçalho (H1, H2, H3, etc). Não é recomendado pular níveis de cabeçalho.
    • O texto deve ter um tamanho de fonte adequado. Recomendado para corpo de texto: 20px.
    • Mudanças de língua devem ser avisadas semanticamente (atributo “lang” da tag span),
  • Formulários
    • Todos os campos de formulários devem ter rótulos identificados semanticamente (tag label
    • Erros não devem ser comunicados apenas por cor. Devem ser claros, para que o usuário possa corrigir.
    • Oferecer sugestões de preenchimento.
  • Botões e links
    • Deve ser possível compreender do que se trata o link/botão apenas por seu texto (ou nome), fora de contexto. Títulos como “saiba mais”, “clique aqui” são práticas ruins.
    • Caso abra um PDF, o usuário deve ser avisado.
    • Links devem ser identificados visualmente com facilidade (texto azul ou sublinhado).
  • Animações
    • Evitar animações que começam sozinhas.
    • Ter um mecanismo de pausa (isso inclui GIFs).
    • Não ter animações com flashes (podem causar convulsões).

Passo a passo

Aqui, reunimos um resumo de como fazer um site acessível.
  1. Compreender como os usuários acessam a web;
  2. Entender os critérios da WCAG mais recente
    1. Ler as boas práticas;
    2. Ler a cartilha de acessibilidade do W3C Brasil (opcional);
    3. Ler a WCAG e, caso tenha alguma dificuldade com algum critério, o “Compreendendo a WCAG” (opcional).
  3. Implementar as boas práticas estudadas no tópico anterior.
  4. Rodar uma avaliação automática primária. O W3C possui uma lista de ferramentas de avaliação. A principal ferramenta recomendada é a WAVE (Web Accessibility Evaluation Tool).
  5. Corrigir os erros encontrados. E repetir a avaliação automática até retornar zero erros.
  6. Realizar testes com a equipe técnica. Para isso, é possível utilizar o documento “Como cumprir a WCAG” ou o site Guia WCAG de Marcelo Salles como checklist ou fazer a própria checklist da equipe. É importante testar utilizando diferentes T.A.s e o teclado.
  7. Realizar testes com usuários com deficiência ou especialistas em acessibilidade. O eMAG possui uma checklist para testes com deficientes visuais.
    1. Fase 1: Testes não dirigidos. O usuário navega pelo site como se faz com qualquer site.
    2. Fase 2: Testes com metas. A equipe deve estabelecer metas para o usuário, como por exemplo preencher um formulário, clicar um botão.
  8. Manutenção constante. O website deve estar sempre se atualizando e corrigindo erros que possam vir a surgir. É importante que disponibilize um canal de contato, para que usuários possam reportar erros.