Acessibilidade: O guia para uma web universal
Tags: html, acessibilidade, a11y, usabilidade
Published: 2019-12-07 14:41:15

Muito me encanta a internet. Quando me aventurei neste universo pela primeira vez, era apenas uma padawan. Ela não era tão vasta e rica como hoje e muito dos conceitos que temos atualmente não eram nem sequer uma preocupação, afinal, a web consistia apenas de links envoltos de layouts tabelados e cores extremamente toscas.

Hoje em dia tudo é diferente e a internet está disponível para grande parte da população, mas a acessibilidade **ainda** não.

Quando consegui meu primeiro emprego como desenvolvedora front-end junior, não conhecia nenhum destes conceitos. Até que um dia ligaram na agência em que trabalhava procurando pelo meu chefe, pois um cliente deficiente visual de um site de leilões online tinha ligado e reportado que no antigo site era possível navegar no site através dos leitores de tela, mas no atual não. O novo site não tinha sido desenvolvido levando a acessibilidade em mente.

Aquilo de certa forma me marcou. Até aquele em dia em questão, não fazia ideia de como pessoas portadoras de deficiência faziam para acessar a internet e muito menos como poderia transformar sua experiência. Me senti responsabilizada por impedir que outras ligações como aquela ocorressem. Inevitavelmente, aprendi outros conceitos muito importantes ao longo do caminho e que se complementam: [usabilidade](https://developers.google.com/web/fundamentals/design-and-ux/principles?hl=pt-BR) e [performance web](https://developers.google.com/web/fundamentals/performance/why-performance-matters).

Estudar e aplicar esses conceitos me fizeram uma desenvolvedora melhor e mais `empática`. Foi quando entendi que a internet é universal e deve ser desenvolvida para **todos**.

Após finalizar  as próximas seções, você está apto à:

- codificar de forma semântica e otimizada para leitores de tela e navegadores;
- escrever conteúdo de forma mais simples e compreensível;
- tornar seu site mais performático;
- melhorar o posicionamento em mecanismos de buscas;
- aplicar conceitos de usabilidade em projetos pessoais e profissionais;


## 📗 Código semântico

Nos primórdios da web, o `HTML (Hypertext Markup Language)` era uma terra sem lei. Os elementos `table` e `div` eram como pais de santo que faziam todo tipo de milagre. Loja virtual? Taca uma tabela aí. E-mail marketing? Tabelas fazem todo o sentido, é claro! (neste caso em específico ele permanece até hoje, infelizmente). 

Era nesse caos em que viviamos até o surgimento do `HTML5`. Ele veio pra revolucionar a forma como escrevemos páginas web, trazendo semântica para cada novo elemento inserido e significado a informação.

> Apesar disso, a semântica reside na web desde sempre. Elementos como os cabeçalhos `(h1, h2...h6)` e `buttons` estão desde a primeira especificação do HTML.
 
Como dito anteriormente, não existiam tags que diferenciassem um `header` de um `footer`, ou dissessem ao navegador que uma página possui um menu de navegação, mas hoje com a nova especificação do HTML5, elas existem!


![Marcação antiga vs Marcação com HTML5](https://thepracticaldev.s3.amazonaws.com/i/9dlqph9744jnzmntmy0y.png)

Legenda: marcação antiga VS marcação atual com HTML5

Com as novas tags do HTML5, podemos demarcar quando uma sessão de uma página é um `footer`, `header`, `nav `ou mesmo comportará um artigo. Desta forma, o navegador também terá conhecimento do tipo de conteúdo que ele está renderizando.

### Listas ordenadas e não-ordenadas

Um erro comum que cometemos é esquecermos da existência das listas ordenadas. Não é apenas uma questão de escolher entre  `<ul>` e `<ol>` e sim sobre qual atende melhor a necessidade do projeto.

```
<ul class="breadcrumbs>
    <li><a href="/home">Home</a></li>
    <li><strong class="current>Contato</strong></li>
</ul>
```

Semânticamente, seria melhor representado:

```
<ol class="breadcrumbs>
    <li><a href="/home">Home</a></li>
    <li><strong class="current>Contato</strong></li>
</ol>
```

### Idioma do documento com ``[lang]``

Nas versões anteriores ao HTML5 era possível definir o conteúdo do documento através da metatag nativa.

```
<meta http-equiv="Content-Language" content="pt-br">
```

O atributo ``lang``foi introduzido no HTML5 e informa ao navegador qual o idioma do documento.

```
<html lang="pt-br">
```

Ele pode ser usado como atributo em qualquer elemento, informando a linguagem do conteúdo demarcado:

```
<p lang="en-us">
    Augusta Ada King, Countess of Lovelace was an English mathematician and writer, chiefly known for her work on Charles Babbage's proposed mechanical general-purpose computer, the Analytical Engine. She was the first to recognise that the machine had applications beyond pure calculation, and published the first algorithm intended to be carried out by such a machine. As a result, she is sometimes regarded as the first to recognise the full potential of a "computing machine" and one of the first computer programmers.
</p>
```

### Gerenciando visibilidade com ``[hidden]``

O atributo ``hidden `` é uma alternativa semântica ao `display: none`.
Para tornarmos nosso desenvolvimento mais otimizado para leitores de tela, precisamos fixar o seguinte conceito: tudo o que fazemos no CSS é puramente visual. Nunca estaremos atingindo tecnologias assistivas com folhas de estilo. Por isso o CSS é o lugar ideal para colocar imagens decorativas e firulas criadas pelos designers (que particularmente, eu adoro).

### Navegação sequencial pelo teclado com ``[tabindex]``

Uma página acessível deve poder ser navegada unicamente através do teclado. O atributo ``tabindex`` é muito útil neste quesito. Ele permite que controlemos a ordem dos elementos que serão navegados por meio da teclada ``tab``. Os valores aceitos para essa propriedade são:

- ``[tabindex="1"]`` (**valor positivo**): o elemento deve ser focável e que pode ser acessado através da navegação sequencial do teclado. O valor atribuído será a posição dentro da sequência;
- ``[tabindex="-1"]`` (**valor negativo**): o elemento deve ser focável, mas não será acessível por meio da navegação sequencial, ou seja, não será acessado através da tecla ``tab``;
- ``[tabindex="0"]`` (**zero**): o elemento deve ser focável, poderá ser acessado através da navegação sequencial, mas sua posição será definida pela ordem em que se encontra no código-fonte;

### 💬 Descritivos em imagens com ``[alt]``

Imagens são ilustrativas e esclarecedoras por si só, certo? (não entraremos no assunto obras de arte, no entanto). 
Claro, se você puder vê-las. Mas muita gente por aí não pode. 

O atributo ``alt`` existe desde sempre no HTML e serve para fornecermos a descrição de uma mídia visual presente no documento.

```
<img src="https://http.cat/202" alt="Gatinho comendo de boca aberta">
```

> Além de ser valiosa para leitores de tela, o atributo ``alt `` é utilizado quando, por algum motivo, uma imagem não foi carregada na página. Pode ser um problema de conexão, o servidor na qual ela foi hospedada ficou fora do ar ou o usuário simplesmente desabilitou-as para ter uma experiência mais rápida.

### SVGs semânticos com ``[title]`` e ``[desc]``

A internet não é composta só de imagens. Na verdade, uma das grandes evoluções da web foi o surgimento do SVG `Scalable Vector Graphics`, tornando-a mais adaptável e leve.

Assim como imagens, o SVG possui atributos que aumentam a acessibilidade de nossos vetores escaláveis: ``[title]`` e ``[desc]``. Elas servem para informar um título ao nosso vetor e uma descrição mais detalhada do mesmo.

```
<symbol id="icon-close" viewBox="0 26 100 48">
    <title>Título do ícone</title>
    <desc>Descritivo do ícone</desc>
    <!-- <path>s and whatever other shapes in here -->  
  </symbol>

```

### Legendas e subtítulos com ``<track>``

Com o HTML5 também é possível inserir arquivos de áudio e vídeo de forma nativa, sem a necessidade de plugins, utilizando as tags: ``<video>`` e ``<audio>``. 
Além disso, ele também disponibiliza a tag ``<track>`` que incorpora legendas e subtítulos em nosso arquivo de mídia, no formato WebVTT `(Web Video Text Tracks Format)`.

> Fala sério, a internet é **demais**.

```
<video controls autoplay>
  <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>
```


## ♿️ WAI-ARIA

A **WAI-ARIA** `Especificação dos Aplicativos Ricos Acessíveis de Internet da Iniciativa para Acessibilidade da Web` é um consórcio internacional, que define formas de tornar o conteúdo da web mais acessível para deficientes.

Com a criação dessa especificação, ganhamos mais uma ferramenta dentro de nosso arsenal, sendo elas as chamadas `ARIA roles`.

**Roles** são alguns bytes de código adicionais ao nosso código padrão, que não machucam, nem mesmo aumentam o tempo de desenvolvimento, mas que em contrapartida trazem informações preciosas para leitores de tela.

Digamos que por falta de conhecimento (ou bom senso), alguém crie um botão desta maneira:

```
<div>I'm a button!</div>
```

Visualmente, isso não nos diz nada, certo? E adivinhem: para os leitores de tela e navegadores também não. A única evidência de que se trata de um botão é seu próprio texto, que em muitos casos, pode ser insuficiente.

```
<div role="button">I'm a button!</div>
```

Os **roles** são atributos incorporados no próprio HTML que servem para explicitar o tipo de conteúdo que está sendo fornecido para leitores de tela. Existem diversos tipos de roles e na sessão sobre semântica podemos ver dois exemplos interessantes: **banner** e **content-info**.

> Roles devem ser incorporados em elementos que não fornecessem uma semântica padrão. Eles são redundantes em elementos nativos, como `<button>` e `<checkbox>`, pois os mesmos já possuem as características que seriam fornecidas pelo atributo.

Talvez esse exemplo não pareça ser muito eficiente, afinal de contas, já existe um elemento ``button`` que fornece essa semântica para nós.

Vamos dar uma olhada num conhecido framework: nosso querido `boostrap`.

```
<div class="accordion" id="accordionExample">
  <div class="card">
    <div class="card-header" id="headingOne">
      <h5 class="mb-0">
        <button class="btn btn-link" type="button" data-toggle="collapse" data-target="#collapseOne" aria-expanded="true" aria-controls="collapseOne">
          Grupo de itens colapsável #1
        </button>
      </h5>
    </div>

    <div id="collapseOne" class="collapse show" aria-labelledby="headingOne" data-parent="#accordionExample">
      <div class="card-body">
        Eu sou um body! #1
      </div>
    </div>
  </div>
  <div class="card">
    <div class="card-header" id="headingTwo">
      <h5 class="mb-0">
        <button class="btn btn-link collapsed" type="button" data-toggle="collapse" data-target="#collapseTwo" aria-expanded="false" aria-controls="collapseTwo">
          Grupo de itens colapsável #2
        </button>
      </h5>
    </div>
    <div id="collapseTwo" class="collapse" aria-labelledby="headingTwo" data-parent="#accordionExample">
      <div class="card-body">
        Eu sou um body! #2
      </div>
    </div>
  </div>
  <div class="card">
    <div class="card-header" id="headingThree">
      <h5 class="mb-0">
        <button class="btn btn-link collapsed" type="button" data-toggle="collapse" data-target="#collapseThree" role="button" aria-expanded="false" aria-controls="collapseThree">
          Grupo de itens colapsável #3
        </button>
      </h5>
    </div>
    <div id="collapseThree" class="collapse" aria-labelledby="headingThree" data-parent="#accordionExample">
      <div class="card-body">
        Eu sou um body!#3
      </div>
    </div>
  </div>
</div>
```

Esse é o código padrão para inserir um ``accordion`` em nossa página. Ele é composto inteiramente por elementos `div` e possui um comportamento complexo. Para descrever tal comportamento em leitores de tela e tecnologias assistivas, são utilizadas as seguintes ``roles``:

``aria-labelledby:`` informa o ID do elemento correspondente ao rótulo;
``aria-expanded:`` informa o estado atual do elemento colapsável;
``aria-controls:`` informa qual o elemento sendo atingido pelo controle;

A WAI-ARIA possui uma vasta documentação para implementação em diversos tipos de casos. Neste repositório do github podemos encontrar um [WAI-ARIA cheatseet](https://github.com/filipelinhares/WAI-ARIA-cheatsheet) com todas as ``roles`` possíveis para se utilizar durante o desenvolvimento.


## 🚥 Precisamos falar sobre Daltonismo

Cores são muito bonitas e esclarecedoras, para quem pode enxergá-las. Mas alguns simplesmente não podem (não da maneira na qual enxergamos). Venho falar dos daltônicos, que compõem [8,5% da população masculina mundial](http://www.daltonicos.com.br/daltonico/daltonismo.html) e também precisam que a internet seja desenvolvida para eles!

Uma diretriz que resume a acessibilidade para daltônicos:

> A cor não é usada como o único meio visual de transmissão de informações (Nível A) - [Web Content Accessibility Guidelines 2.0](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0#qr-visual-audio-contrast-without-color)

![Motivo pelo qual daltônicos odeiam gráficos de pizza](https://thepracticaldev.s3.amazonaws.com/i/nbu5ujm6hho0nqcz1yex.jpg)

Legenda: Imagem com a mensagem “Razões pelas quais eu odeio gráfico de pizza”, e abaixo um gráfico de pizza com a legenda “porque eu sou daltônico”

Segue algumas diretrizes:

- Não dependa apenas de cores para informar algum dado ao usuário. Utilize de rótulos e ícones para complementar a informação:

![Gráfico de pizza com rótulos](https://thepracticaldev.s3.amazonaws.com/i/8r7qid9oeandk74w38tb.png)

- Utilize mensagens de erro para transmitir feedback ao usuário:

![Validação de formulário apenas com cores VS Validação de formulário com cores, rótulos e ícones](https://thepracticaldev.s3.amazonaws.com/i/ajetbd3au33o2yggykkv.png)

- Não use apenas cores para diferenciar um link do resto do texto. Por padrão, o elemento ``<a>`` possui a propriedade ``text-decoration:underline``, que define um sublinhado para <em>hyperlinks</em> e torna sua identificação independente da cor.

![Link com a cor destacada em azul VS Página em preto e branco, ](https://thepracticaldev.s3.amazonaws.com/i/bvvoah7806f45rs8zz50.png)

Legenda: Do lado esquerdo uma página com o link destacado em azul e do lado direito a mesma página em preto e branco, demonstrando que a cor não serve mais como um indicativo e que a informação de que é um <em>hyperlink</em> se perde.

> Existe muito mais sobre acessibilidade e daltonismo. Utilizei alguns exemplos do artigo [Acessibilidade para Daltônicos](https://medium.com/acessibilito/acessibilidade-para-dalt%C3%B4nicos-casos-de-falha-e-sucesso-d76bf6e4261e) e recomendo fortemente sua leitura.


## 🔗 Conteúdo

Não é atoa que **SEO** e **semântica** são praticamente <em>bffs</em>. Um código semântico e uma linguagem de fácil entendimento são essenciais para uma boa acessibilidade. E usabilidade. E SEO. E tudo.

A verdade é que: seres humanos são extremamente inteligentes, possuem uma alta capacidade cognitiva, mas não gostam de pensar muito e odeiam linguagens complexas.

Se comunicar de maneira simples faz toda a diferença quando não sabemos quem é o usuário - e dada as infinitas possibilidades - devemos tornar nosso conteúdo acessível, pensando que nosso avô de 86 anos pode estar acessando um site nosso.

###  Abreviações

Caso seja possível, evite-as. Caso não seja, explique seu significado. Aplico essa premissa enquanto escrevo este artigo. 
Algumas maneiras de fazer isto:
- Explicar o significado da abreviação logo após usá-la pela primeira vez. Na sessão sobre semãntica, pode notar que cito o HTML pela primeira vez e logo em seguida lhe entrego o significado da informação. O resultado será parecido com este: ``HTML (Linguagem de Marcação de Hipertexto)``

- Linkar a abreviação à uma página que explique sobre o conteúdo ou mesmo adicionar notas no rodapé, como nos livros!. Exemplo: [HTML](https://pt.wikipedia.org/wiki/HTML)
- Utilizar a tag `<abbr>` e aplicarmos em seu atributo ``[title]``a explicação referente à abreviação: Exemplo: <abbr title="Linguagem de Marcação de Hipertexto">HTML</abbr>


## 📝 Formulários

Acessibilidade em formulários é um tópico sensível. Afinal, se um usuário não sabe com exatidão o que precisa ser inputado, como ele irá fornecer qualquer tipo de informação ao nosso site?

Pegaremos como exemplo um formulário de login que pede usuário e senha.

![Formulário sem rótulo VS Formulário com rótulo](https://thepracticaldev.s3.amazonaws.com/i/m9d835lriii7pr0s2901.png)

Qual das opções torna a ação do usuário mais clara? Tenho certeza que você respondeu a `segunda`. Ela diz, implicitamente: sei que você pode ser meio leigo, logo estou me adiantando.

Nosso site precisa ser um guia para o mais iniciante da internet. Se uma criança de 5 anos conseguir navegar por ele, estamos fazendo um bom trabalho.

Segue algumas dicas para melhorar a acessibilidade de seus formulários:

### Organização de formulários com ``<fieldset>``, ``<legend>`` e ``<optgroup>``

Imagine uma página de cadastro onde o usuário precisa fornecer informações **pessoais**, **de cobrança e entrega** e de *login* para acessar sua conta. Agora imagine que esse formulário não tivesse nenhum tipo de separação, sendo apenas uma linguiça gigante.

O ``<fieldset>``serve para dividir nosso formulário em seções, tornando mais fácil a identificação dos diferentes tipos de dado que o usuário precisa fornecer. Sendo assim, teriamos um ``<fieldset>`` para cada bloco de informação e usariamos o ``<legend>`` para fornecer um título para cada uma dessas sessões.

Também temos o elemento ``<optgroup>``, utilizado para agrupar elementos ``<option>``por categorias de dentro de um ``select``.

```
<select>
  <optgroup label="Front-end">
    <option>HTML5</option>
    <option>CSS3</option>
    <option>Javascript</option>
  </optgroup> 
  <optgroup label="Back-end">
    <option>Python</option>
    <option>Node.JS</option>
    <option>Ruby on Rails</option>
  </optgroup>
</select>
```

### Fornecendo orientações com ``[placeholder]``

O atributo ``[placeholder]`` faz exatamente o que vimos no exemplo anterior. Ele fornece uma instrução ao usuário sobre que tipo de informação ele precisa preencher. Pode ser aplicado de algumas formas:
- modo imperativo: `Insira sua usuário...`;
- fornecer uma máscara padrão: ``exemplo@seudominio.com.br`` ou ``00/00/0000``;
- sugerir através de respostas comuns: `Google, indicação de amigos, anúncios...`

### Fornecendo rótulos com ``<label>`` e ``[aria-labelledby]``

A tag ``<label>`` serve para relacionar um elemento com um rótulo, através do atributo ``[for]`` e passando o ``ID`` do elemento.
Outra forma de referenciar um rótulo ao elemento é através do atributo ``[aria-labelledby]``, inserido na própria tag de formulário.

```
<label for="password">Senha:</label>
<input name="password" type="password" placeholder="Insira sua senha..." aria-labelledby="password" />
```

### Dando feedback de interação com ``:hover`` e ``:focus``

Fornecer um feedback ao usuário é cruciadl para **usabilidade** e **acessibilidade**. Uma cor de borda diferenciada enquanto o usuário digita a informação é suficiente para que ele não se perca durante a navegação de seu site.


## 🔧 Ferramentas para desenvolvedores

Apresentarei algumas ferramentas que auxiliarão você na hora do desenvolvimento de sites mais acessíveis:

- **[tota11y](https://khan.github.io/tota11y/)**: fornece informações a respeito de violações de acessibilidade que seu documento possui;
- **[goodUI](https://goodui.org/)**: não é um projeto sobre **acessibilidade** e sim sobre **usabilidade**. Sua leitura é importante e seguir as diretivas indicadas antes de desenvolver interfaces para seu projeto também. Assim, teremos uma internet mais padronizada e familiar aos nossos usuários;
- **[webDevChecklist](https://webdevchecklist.com/)**: checklist para desenvolvimento de projetos web.  Além de **acessibilidade**, possui outros tópicos, como: **performance**, **semântica**, **boas práticas** e outros;
- **[webDevChecklist for chrome](https://chrome.google.com/webstore/detail/web-developer-checklist/iahamcpedabephpcgkeikbclmaljebjp)**: extensão da ferramenta acima para `google chrome`;

![WebDeveloperChecklist para Google Chrome](https://thepracticaldev.s3.amazonaws.com/i/vjpgtxcw0u1oixc2v2k5.PNG)`


## Conclusão

Estou longe de abordar todos os assuntos referentes a acessibilidade web. É um campo de estudo abrangente e crucial para uma web mais inclusa.

Espero ter fornecido com este artigo um caminho das pedras de **como** e ***porque*** começar.

### Leituras adicionais

- **[Web accessibility for developers](https://www.wuhcag.com/)**: acessibilidade para desenvolvedores web; 
- **[Web Content Accessibility Guidelines](https://www.w3.org/TR/WCAG20/)**: guia oficial da W3C para desenvolvimento de documentos acessíveis;
- **[WAI-ARIA no MDN](https://developer.mozilla.org/pt-BR/docs/Web/Accessibility/ARIA)**: documentação do mozilla sobre WAI-ARIA;
- **[Acessibilidade na Google](https://developers.google.com/web/fundamentals/accessibility?hl=pt-BR)**: documentação de acessibilidade da Google.