10 diretrizes de acessibilidade na web

Planejando uma melhor acessibilidade para seus projetos!

Acessibilidade é inclusão, é diversidade, é web ❤️ — Créditos da imagem Dyno Mapper
Reunimos uma lista de dez diretrizes de acessibilidade na Web que irão melhorar o acesso ao seu site para todas as pessoa. — Eva Ferreira

Há uma citação de Tim Berners-Lee, diretor do W3C e inventor da World Wide Web, que diz: “O poder da web está em sua universalidade”. Como pessoas que ganham a vida fazendo websites, é nossa responsabilidade garantir que todos tenham acesso a elas. A acessibilidade da Web parece um pedido alto no papel, mas é definitivamente muito mais fácil do que parece.

Nossas dez diretrizes de acessibilidade na Web são projetadas para garantir que todos os sites sejam universais.

Isso não apenas ajudará os usuários de leitores de tela, mas também melhorará a experiência de navegação para conexões lentas. Classificamos nossas diretrizes por tempo de implementação, para fornecer uma visão clara de quanto esforço você terá para colocar em prática esse processo. Antes de ficar sobrecarregado, aceite nossa palavra — vale a pena!

E vamos começar pelo começo…

O que diabos é a acessibilidade da Web?

De acordo com o W3C, acessibilidade na web significa que cada pessoa pode perceber, entender, navegar, interagir e contribuir para a web . Nesse quesito, a acessibilidade do site abrange todas as condições que afetam o acesso à Web, incluindo deficiências visuais, auditivas, físicas, de fala, cognitivas e neurológicas.

Você encontrará um monte de conteúdo sobre esse assunto na Web e recomendo você ler atentamente a Iniciativa de Acessibilidade na Web (WAI), se esse tópico lhe interessar.

Com isso em mente, aqui estão nossas diretrizes:

1. Não dependa da cor (~45 minutos)

A cor é uma ferramenta poderosa que costumamos usar para expressar emoções e comunicar mensagens na Web. No entanto, não devemos colocar toda nossa fé em cores para transmitir significado e informações aos nossos usuários.

Por quê?

Por exemplo, é amplamente conhecido que verde significa “certo” e vermelho significa “errado”, mas o que acontece quando usamos isso como nosso único meio de comunicação?

Se exibirmos mensagens importantes em nossas interfaces de usuário usando apenas cores para transmitir informações, estaremos deixando 4,5% da população para trás.

A cor deve complementar um erro ou mensagem de confirmação, mas não pode ser a única ferramenta que usamos. Para ter certeza de que alcançamos todos os nossos usuários, devemos sempre adicionar rótulos ou ícones que mostrem se as informações preenchidas em um formulário estão certas ou erradas.

Uma solução muito interessante foi adotada pela caniuse.com, que fornece uma paleta de cores alternativa para exibir o conteúdo de suas tabelas de compatibilidade.

É ideal para verificar o daltônismo e o contraste, portanto, certifique-se de que você e sua equipe tenham as ferramentas certas. Recomendamos o plugin Stark para Sketch que ajuda você a projetar com acessibilidade em mente!

2. Não bloqueie o zoom (~5 minutos)

Na era do design responsivo, poderíamos ter cometido alguns erros irresponsáveis.

Uma delas é o uso de maximum-scale=1.0, que desativa a funcionalidade de zoom nas páginas da web usando dispositivos móveis.

<meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1">

O astigmatismo afeta entre 30 e 60% dos adultos na Europa e na Ásia, mas a visão embaçada pode afetar pessoas de todas as idades e nacionalidades (Oi mãe! ❤️).

A capacidade de ampliar não é apenas mais uma diretriz de “frescura” das WCAG, mas uma ferramenta para simplificar a vida cotidiana dessas pessoas. Então, da próxima vez que você estiver criando um site responsivo, lembre-se de pensar em minha mãe e cada usuário com uma visão embaçada.

Além de permitir que os usuários façam zoom livremente em dispositivos móveis, lembre-se também de verificar se o layout tem boa aparência, com zoom de até 200% nos navegadores de desktop (utilizando cmd+, Mac ou crtl+, Windows/Linux).

3. Redescubra o atributo alt (~45 minutos)

Não importa há quanto tempo você está fazendo sites, você pode se surpreender ao conhecer essas poucas dicas sobre o famoso, mas misterioso, atributo alt.

  1. O atributo alt é obrigatório para todas as tags img, e um atributo alt vazio é completamente válido. Se uma imagem é decorativa ou não é necessária para entender o conteúdo da página, você pode usar o simples alt=""
  2. Os leitores de tela informam ao usuário que uma tag <img> é uma imagem, portanto não há necessidade de ser redundante e começar seu alt com "Uma imagem de...", vá direto ao ponto
  3. A função de uma imagem é tão importante quanto o seu significado: se o seu logotipo criar um link para à página inicial do seu site, o texto alternativo deverá ser algo como “Página inicial” ao invés de “Logotipo”.
  4. Texto alternativo não é apenas sobre acessibilidade. Às vezes, usuários com conexões lentas desativam as imagens para obter uma experiência mais rápida no navegador. Tenha também esses usuários em mente sempre que você escrever seus atributos alt!

Mas nem todas as imagens em seu site são tags img, certo? Você pode ter um SVG ou dois por aí… ou um sistema inteiro de ícones SVG!

Como podemos tornar o SVG acessível para todos? Felizmente para nós, o padrão Scalable Vector Graphics tem isso como padrão! Para descrever nossos vetores, temos as tags <title> e <desc> para descrições curtas e longas.

<symbol id="langIcon">
<title>Ícone de linguagem</title>
<desc>Uma descrição maior</desc>
<path d="M0 2C6.47 2 2 6.48 2 12s4.47 10 9.99 0h24v24H0z" />
</symbol>

4. Adicione subtítulos e legendas aos seus vídeos (mais de 4 horas)

Esta pode ser uma das diretrizes mais difíceis da WCAG, não por causa da dificuldade técnica, mas porque pode ser demorada. Existem algumas maneiras de fazer isso:

  1. Vamos pegar o YouTube, por exemplo. Depois de enviar um vídeo para a plataforma, você pode habilitar legendas. Elas são geradas automaticamente e podem ser imprecisas em algumas circunstâncias, dependendo do idioma, do ruído de fundo ou do sotaque do interlocutor. No entanto, elas são muito fáceis de implementar e podem funcionar bem na maioria dos vídeos em inglês.
  2. Se estivermos à procura de legendas 100% precisas, é difícil confiar no YouTube para criar uma boa cópia, por isso, devemos escrever as legendas por conta própria ou contratar um terceiro para fazê-lo. O YouTube suporta os formatos de legenda mais comuns, .srt.sub.sbv. Além de nos permitir escrever as legendas na própria plataforma, o que pode ser muito conveniente se não tivermos nenhum software de legenda ou se desejarmos pedir à nossa comunidade para nos ajudar a traduzir o conteúdo sem dar acesso administrativo à nossa conta.
  3. Mas talvez você não queira usar o YouTube como sua plataforma de hospedagem. Talvez você deseje usar um vídeo HTML5 hospedado em seu servidor. Nós temos uma solução! O HTML5 inclui a tag <track>, que você pode usar para anexar facilmente quantos arquivos de legendas e subtítulos desejar, usando o formato WebVTT (Traduções For The Win!).
<video controls>
<source src="movie.mp4" type="video/mp4">
<track label="English Captions" kind="captions" srclang="eN" src="captions.vtt" default>
<track label="Subtitulos en español" kind="captions" srclang="es" src="subs.vtt">
</video>

5. Semântica = acessibilidade (~45 minutos)

Tag de <font> , lembra? Espero que não, aqueles eram tempos sombrios.

Apesar da crença comum, a semântica não nasceu com HTML5. Eles estão conosco desde a primeira página HTML e melhoraram muito desde então. Com o padrão HTML5, novas tags semânticas foram introduzidas para nosso uso diário.

Ok, mas não é semântica apenas para SEO?

Não necessariamente. Quando você escolhe conscientemente uma tag <h1> em um <p> ou um <span>, você está deliberadamente alterando o significado de um elemento, fornecendo hierarquia e criando uma estrutura em árvore das informações da sua página.

Os leitores de tela estão atentos a isso. De fato, a semântica é uma de suas armas mais úteis.

Tenha em mente que, com grande poder, há uma grande responsabilidade, portanto, certifique-se de usar a tag semântica adequada para cada elemento, de h1 à nova tag main.

6. Use a marcação correta (~30 minutos)

Seguindo o ponto anterior, gostaria de discutir alguns falsos amigos e pares controversos:

time vs datetime

O elemento time exibe vários tipos de formatos de data, fusos horários e durações usando o padrão ISO 8601 para representar datas e horas.

datetime é um atributo opcional que ajuda a melhor representar o conteúdo. Vamos ver alguns exemplos:

<time>14:54</time> Horas e minutos
<time>2018-06</time> Ano e mês
<time>-03:00</time> Fuso horário
<time>2h 32m</time> Duração do Harry Potter 2
<p>CSSConf Argentina acontecerá em <time datetime=”2016-08-07”>7 de Agosto</time></p>

del e ins

A web muda constantemente, mas não é necessário que essas mudanças passem despercebidas. Podemos marcar as edições usando as tags ins e del no HTML em combinação com o atributo datetime.

O elemento ins representa uma adição a um documento:

<ul>
<li> <ins datetime="2017-08-02">Sorvete</ins></li>
<li>Doce</li>
<li>Macarrão</li>
</ul>

O elemento del representa o conteúdo excluído:

<ul>
<li><del datetime="2017-06-05">Reassistir Harry Potter 8</del></li>
<li><del datetime="2017-06-05">O personagem ____ morre.</del></li>
<li><del datetime="2017-06-06">Escrever um artigo</del></li>
<li>Reservar uma mesa</li>
</ul>

button vs a

Pegue a pipoca, que essa discussão é boa. Quando devemos usar cada um?

Vamos ver:

As tags a destinam-se a criar um link entre um arquivo a outro ou a abrir links em uma nova guia ou na página atual. No entanto, essa tag não é sempre ideal para acionar ações como menus ou galerias de imagens. O elemento button é a escolha certa para essas situações e geralmente usado com JavaScript.

Além disso, a tag button pode ser facilmente confundida com <input type="button">, a diferença é que o primeiro pode receber mais conteúdo (texto, imagem + texto ou apenas imagens).

Há duas coisas a considerar ao usar a tag button:

Primeiro, se o conteúdo de um botão não for explícito o suficiente (usar “X” em um botão de fechamento, por exemplo), devemos adicionar um atributo aria-label para ajudar a explicar a função.

<button aria-label="Close">X</button>

Em segundo lugar, se adicionar um atributo href faz sentido (um componente de pesquisa ou uma galeria lightbox), então podemos também usar uma tag a e substituir o comportamento do link por JavaScript. Uma galeria de imagens que usa a tags com href irá funcionar caso o JavaScript não estiver ativado.

Mas…

7. Use roles quando necessário (~1 hora)

A fim de informar aos usuários de leitores de tela que nosso link aciona uma ação e não é, de fato, uma tag <a> normal, devemos adicionar o atributo role com o valor button.

Mas cuidado!

Ao escrever seu JavaScript, você precisa chamar suas funções não apenas ao clicar, mas também quando o usuário pressionar a barra de espaço. Isso é necessário porque o comportamento usado para os botões é diferente daquele usado para links e o usuário deve ser capaz de acionar a ação em qualquer um desses comandos.

<a href="img/kitten.jpg" role="button" onclick="handleBtnClick(event)" onKeyPress="handleBtnKeyPress(event)">
Button
</a>


function handleBtnClick(event) {
// Faz algo...
}

function handleBtnKeyPress(event) {
// Verifica se `barra de espaço`
// ou `enter` foram usados
if (event.keyCode === 32 || event.keyCode === 13) {
// Previne a ação padrão, no caso da barra de espaço
// irá previnir o navegador de realizar o scroll
event.preventDefault();

// Faz algo...

}
}

Leia mais sobre isso no MDN.

Tenha em mente que role geralmente não são necessários, a menos que você quebre as regras, como no exemplo acima. Elementos semânticos do HTML têm um papel padrão já aplicado: "navegação" para tags <nav>, "link" para tags <a>, e assim por diante. Isso significa que um atributo role só é necessário quando desejamos alterar esses valores padrão.

8. Elementos escondidos (~1 hora)

Existem alguns métodos disponíveis para ocultar coisas com HTML e CSS. Os exemplos abaixo ajudaram você a encontrar a melhor alternativa para cada situação.

Se você quiser ocultar os elementos da visualização do usuário, mas ainda permitir que os leitores de tela os conheçam, a última opção é a melhor.

Isso é muito útil em labels de formulários ou links para pular conteúdo. A classe .visuallyHidden é um desses códigos CSS que devem ser incluídos nos seus favoritos, por isso é fácil encontrá-los em todos os projetos. Sim, você pode mudar o nome se quiser (minha sugestão é .pottersCloak 😂).

.visually-hidden { 
position: absolute !important;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
padding:0 !important;
border:0 !important;
height: 1px !important;
width: 1px !important;
overflow: hidden;
}

body:hover .visually-hidden a, body:hover .visually-hidden input, body:hover .visually-hidden button { display: none !important; }

9. Siga os padrões de acessibilidade da web (~30 minutos por semana)

A acessibilidade da Web é difícil e os padrões e diretrizes estão aqui para ajudar.

Se olharmos todos os pontos anteriores deste artigo: como o <button> funciona? Quando devemos usá-lo? Qual é a diferença entre display: none; e o atributo hidden?

Pode ser simples no início, mas os padrões do W3C e as diretrizes das WCAG são confiáveis, além de serem educacionais.

Vá em frente e se perca na infinidade de informações que eles fornecem. Eu garanto que você descobrirá código e práticas que você nunca soube que existiam!

10. Auditoria e revisão (~3 horas)

Depois de aplicar todo esse conhecimento, é hora de testá-lo. Aqui está uma lista das melhores ferramentas para auditar a acessibilidade do site:

  • ChromeVox: disponível para usuários de Mac e Windows, essa extensão do Chrome é um leitor de tela que você pode usar para testar seu website.
  • Ferramentas de desenvolvimento de acessibilidade para o Chrome: Outra grande extensão para este navegador que adiciona uma opção de auditoria de acessibilidade às suas ferramentas de desenvolvimento diárias.
  • Filtro de cores: teste seu site para diferentes tipos de daltonismo com essa ferramenta on-line.
  • W3C Validator: Esta ferramenta oficial do W3C permite que você saiba se a sua marcação HTML segue as regras de acessibilidade da web!
  • Plataforma de Conformidade A11Y: O Bureau de Acessibilidade à Internet (BOIA) oferece um relatório detalhado, com uma visão geral de como seu site se sai ao ser testado em relação aos pontos de verificação das WCAG A/AA.
  • WAVE: Uma ferramenta de avaliação de acessibilidade da web feita pelo WebAIM.

Experiência da Aerolab com acessibilidade na web

Tentamos criar o hábito de testar nosso trabalho constantemente. Nosso próximo produto, deve sempre ter como objetivo, ser melhor que o anterior. Sim, às vezes cometemos erros, mas nos esforçamos constantemente para melhorar e nos adaptar, sem mencionar aprender algo de cada desafio.

Queremos que nossos produtos ofereçam a melhor experiência possível aos usuários, e é por isso que começamos a incluir padrões de acessibilidade em nosso fluxo de trabalho pouco a pouco.

Ainda há um longo caminho à nossa frente, bem como um grande espaço para melhorias, mas estamos muito felizes em ter escolhido esse caminho.

As páginas promocionais que fizemos para o Xapo são um exemplo de como estamos aplicando os padrões de acessibilidade nos nossos projetos, caso você queira vê-los:

Finalizando

A acessibilidade de projetos web, nem sempre é fácil de implementar, mas se você incluir isso como parte de seu fluxo de trabalho diário (ao invés de uma lista de verificação de última hora), a implementação e o teste se tornarão mais fáceis com o tempo.

Em caso de dúvida, não tenha medo de perguntar a outros desenvolvedores ou fazer alguma pesquisa. Algumas das minhas fontes de informação favoritas são o The A11y Project, o A11y Wins, o HTML5 Doctor e o MDN.

Créditos