Acessibilidade web na pratica

Enquanto estudava sobre assuntos que poderiam agregar meus conhecimentos para fazer entregas cada vez melhores, principalmente na programação voltada para o front-end, percebi que há alguns assuntos que ainda são um pouco negligenciados e deixados de lado durante o desenvolvimento, um deles que abordarei neste post é sobre a acessibilidade!

Há muitas e muitas desculpas que ocorrem por aí sobre o motivo de desenvolvedores negligenciarem este assunto. Acham que o uso da acessibilidade não terá um impacto significativo em suas aplicações que possa valer a pena o "esforço" de aplicar estes conceitos, ou que faz mais sentido criar software para a "maioria" do que "minoria". Como citei anteriormente, tudo isto não passa de desculpas.

Acessibilidade não é apenas mais uma feature do projeto!

A partir do momento que você aprende sobre, não se faz necessário "gastar um tempo" para tornar a página web mais acessível, visto que, durante o desenvolvimento, já estaríamos aplicando estes conceitos de uma maneira super natural.

“O poder da Web está em sua universalidade. O acesso de todos, independentemente da deficiência, é um aspecto essencial." - Tim Berners-Lee

Através deste post, pretendo lhe mostrar maneiras e recursos principais que irão melhorar a qualidade de seus códigos e, consequentemente, sua aplicação ficará acessível e com a usabilidade super favorável, afinal, acessibilidade e usabilidade andam juntas!

Não pense que deixar páginas web acessíveis são aspectos positivos apenas para pessoas que possuem alguma deficiência. A acessibilidade web significa garantir o acesso a todas as pessoas, independente de alguma limitação, seja ela permanente ou temporária.

As pessoas conseguirão ler o conteúdo da sua página direitinho se elas estiverem andando apressadamente durante uma manhã ensolarada na cidade? Pense no público alvo da sua aplicação e veja o quão importante é garantir que a usabilidade do seu software não se comprometa enquanto as pessoas estiverem utilizando em cenários diferentes ou que estejam no momento com algum tipo de limitação física, seja permanente ou temporária!

Primeiramente, vamos tentar entender alguns tipos de deficiências e aspectos que poderemos melhorar:

• Deficiência visual:

  • São utilizados leitores de tela e uso de atalhos que facilitam a navegação pelo site
  • Para quem possui uma baixa visão, é necessário fazer uso de recursos que aplicam e melhoram a forma de leitura da página, seja aumentar tela ou as fontes.

• Deficiência auditiva:

  • É importante dar uma atenção a recursos de transcrições em mídias digitais, seja audio ou video.

• Deficiência motora:

  • Uso de comandos de voz ou controle da navegação pelo teclado
  • Importante fazer uso de tags semânticas do HTML corretamente e saber construir uma boa usabilidade, levando em consideração espaçamentos, semântica, etc.

Diretrizes de acessibilidade

• WCAG: Principal documento de acessibilidade na Web no qual o desenvolvedor se baseia para tornar o conteúdo acessível. As WCAG orientam de forma muito simples como identificar e implementar técnicas que eliminam barreiras de acesso para pessoas com deficiência.
• WAI-ARIA: Foi criada com o objetivo de lidar com conteúdos dinâmicos em aplicações Web.
• ATAG: Tem como objetivo oferecer documentação para a criação de ferramentas de autoria que gerem conteúdo acessível e que seja acessível para as pessoas com deficiência.
• UAAG: Disponibiliza diretrizes para quem vai desenvolver agentes de usuários (como navegadores) ou tecnologia assistiva para o acesso à Web. As WCAG estão para o desenvolvedor Web, enquanto o UAAG está para o navegador e tecnologia assistiva.
• WCAG-EM: Documento que descreve um procedimento para avaliar sites e inclui considerações para orientar os avaliadores e promover boas práticas. Não é uma ferramenta de validação e sim um guia para orientar os responsáveis por auditar a acessibilidade das páginas Web.
• EMAG: Este é o modelo de acessibilidade do governo federal. Ele foi construído com base nas diretrizes internacionais do W3C, mas diferente das recomendações internacionais; não existem níveis de adoção: para os sites governamentais, tudo é obrigatório.
• COGA: O documento aborda técnicas de acessibilidade na Web para contemplar o acesso de pessoas com deficiências neurológicas, limitações cognitivas e dificuldades de aprendizado.

Como começar a melhorar a acessibilidade?

A partir do que foi abordado na lista acima, já conseguimos ter uma noção de passos importantes para se seguir:

• Instalar leitores de tela e fazer testes;
• Garantir que o aumento de fontes não impossibilite a leitura ou navegação;
• Verificar o contraste entre o texto e o fundo da página;
• Garantir que não existem barreiras para a navegação por teclado;
• Evitar bloquear a customização pelo usuário (por exemplo, evitar o bloqueio de zoom em dispositivos móveis);
• Não definir cores como única fonte de sinalização (colocar sempre um texto alternativo para descrever a sinalização);
• Texto alternativo nas imagens;
• Usar labels de forma clara em formulários;
• Projetar estados de foco de maneira clara.

Se aprofundando no WAI-ARIA!

WAI-ARIA é a especificação do W3C para aprimorar a acessibilidade de maneiras que o HTML puro não consegue. A missão do W3C é levar a Web a todo o seu potencial, desenvolvendo protocolos e diretrizes relevantes. Isso é obtido principalmente pela criação e publicação de padrões da Web.

Atributos do WAI-ARIA

O ARIA é possui um conjunto de atributos especiais para a acessibilidade, no qual você pode utilizar em suas tags HTML. O atributo da função define qual é o modelo de objeto (tais como um artigo, um alerta, ou algo que deslize).

Os 3 principais componentes ARIA são as roles (funções/papéis), properties (propriedades) e states (estados). Este componentes podem ser definidos nas tags HTML diretamente, ou podem ser dinamicamente definidas e alteradas usando scripts.

Os estados e atributos ARIA sempre começam com aria-, por exemplo, aria-required="true".

• Roles: São as representações da função ou papel de um elemento. Definem o que um elemento é ou faz. (estrutura de documento, widgets…). Definir um elemento como role=img determina que a semântica da tag vai mudar para que ele se comporte como uma imagem, ou um role=presentation vai determinar que o elemento perdeu toda a semântica da sua aplicação. Exemplo: <form role="search">: Determina que este form possui um comportamento de pesquisa!
• Properties: Definem semânticas adicionais não suportadas no HTML padrão. Exemplo: <button aria-haspopup="true">. Essa propriedade estende o botão padrão para fazer com que um leitor de tela anuncie que o botão, se ativado, acionará um pop-up.
• States: Atributos que definem a condição atual de um elemento. Exemplo: <input aria-invalid="true">. Essa propriedade fará com que um leitor de tela leia essa entrada como inválida no momento (o que significa que precisa ser corrigida), mas esse valor de estado pode ser facilmente alterado para false dinamicamente com base no quê é preenchido.

Boas práticas com WAI-ARIA

• Se puder, use valores semânticos e atributos nativos do HTML. O botão já possui o comportamento de um botão, evite mudar o seu papel para que se comporte como um elemento de imagem, por exemplo.
• Não altere a semântica nativa dos elementos
• Todos os controles interativos devem ser acessíveis via teclado
• Controles interativos devem ter semântica adequada e não podem ser ocultados
• Todos elementos interativos devem ter um nome acessível

Técnicas para melhor acessibilidade

Titulo da página

O elemento title serve para dar a primeira informação sobre o que o usuário encontrará na página. A informação dentro do elemento <title> precisa ser clara não só para o usuário quanto para ferramentas de busca que indexam esse conteúdo. A sintaxe é simples: <title>Blog da Mandy</title> Porém, esse recurso requer cuidado. Utilizar o mesmo título para todas as páginas é ruim, pois não transmite a informação de qual a página em que o usuário acabou de entrar. Também não é uma boa prática colocar a área do site depois do nome.

Em vez de fazer isso: <title>Blog da Mandy | Sobre</title> Faça isso: <title>Sobre | Blog da Mandy</title>

Quando não se usa essa ordem, duas dificuldades podem ser listadas: os leitores de tela sempre vão repetir o nome do site/instituição primeiro e ferramentas de busca podem não conseguir exibir textos longos.

Estrutura semântica

Antes do HTML5, a web era dominada pelos elemento <div>. Por ser um container genérico, ele facilitou e flexibilizou o desenvolvimento de aplicações, mas deixou a semântica e o significado de cada bloco de lado. Com o HTML5, isso ficou mais fácil, pois existem containers específicos para cada tipo de necessidade.

Diferente dos elementos <b> e <i> que apresentam o texto respectivamente em negrito e itálico sem peso semântico, os elementos <strong> e <em> podem apresentar o conteúdo para usuários de leitores de tela com diferentes entonações para seus usuários, devido ao seu peso semântico.

Existe uma série de atributos de WAI-ARIA que servem para estender a semântica dos elementos, utilizando o atributo role. Valores como role=banner e role=navigation servem para marcar áreas equivalentes aos elementos header e nav, respectivamente, quando são utilizados como containers genéricos, por exemplo, utilizando um elemento div.

Porém, quando utilizamos os elementos estruturais do HTML5, estes atributos tornam-se dispensáveis. Em casos onde fica difícil mudar a semântica de elementos (como em sistemas legados, por exemplo), existe a possibilidade de adicionar atributos de WAI-ARIA para garantir a semântica da estrutura. Por exemplo, em um sistema que trata um botão como um elemento genérico pode utilizar atributos de WAI-ARIA para que ele se comporte como um botão (<span role="button">Enviar</span>), uma imagem (<div role="img"></div>) ou mesmo uma aplicação mais complexa, como um slider (<div role="slider"></div>) ou uma barra de progresso (div role="progressbar"/></div>).

O uso de atributos de WAI-ARIA deve ser feito de forma a identificar as áreas da página.

Estrutura semântica para campos de formulário

A documentação do HTML5 também trouxe significado para campos de formulário. No passado utilizávamos type=text nos inputs para todo o tipo de informação, fosse um campo para preenchimento de e-mail ou de busca. No HTML5.2 temos à disposição o seguinte conjunto de atributos para uso em formulários:

• Elementos do HTML5.2 herdados do HTML4:

  • input type=text - para uma string simples e genérica de texto alfanumérico;
  • input type=hidden - para uma string simples e genérica de texto alfanumérico que fica escondida;
  • input type=password - para preenchimento de senha;
  • input type=checkbox - para campos checkbox;
  • input type=radio - para campos radiobox;
  • input type=file - para o upload de arquivos externos;
  • input type=submit - botão para envio do formulário;
  • input type=image - para uso de imagem para o botão de envio do formulário;
  • input type=reset - para apagar o formulário;
  • input type=button - botão genérico.

• Novos elementos disponíveis a partir do HTML5:

  • input type=search - para campos de busca;
  • input type=tel - para campo numérico de telefone;
  • input type=email - para preenchimento de e-mail;
  • input type=url - para preenchimento de um endereço na Web;
  • input type=date - para preenchimento de data;
  • input type=month - para preenchimento de mês;
  • input type=week - para preenchimento de semana;
  • input type=time - para preenchimento de horário;
  • input type=datetime-local - para preenchimento horário em determinado timezone;
  • input type=number - campo numérico;
  • input type=range - valor numérico para uso de slider;
  • input type=color - para criar um picker de cor.

Tecnologia assistiva pode fazer uso da semântica dos elementos para dar ênfase às informações da página.

Tabela acessível

A principal recomendação para o uso de tabelas em uma página é que ela seja o mais simples possível. Lembre-se de que parte do público pode acessar a tabela utilizando um smartphone. Quando utilizar uma tabela, lembre-se da semântica dos elementos:

Uma tabela simples ficaria da seguinte forma:

<table>
  <caption>Tabela de dados</caption>
    <tr>
      <th>Data</th>
      <th>Fonte</th>
      <th>Tamanho</th>
    </tr>

    <tr>
      <td>21 de abril</td>
      <td>Banco de dados</td>
      <td>125 Kb</td>
    </tr>
</table>

Este exemplo anterior é simples, mas para tabelas maiores e mais complexas é necessário considerar o uso de atributos para relacionar linhas e colunas:

<table>
  <caption>Horário de atendimento:</caption>
  <tr>
    <td></td>
    <th scope="col">Segunda-feira</th>
    <th scope="col">Terça-feira</th>
    <th scope="col">Quarta-feira</th>
    <th scope="col">Quinta-feira</th>
    <th scope="col">Sexta-feira</th>
  </tr>

  <tr>
    <th scope="row">09:00 - 11:00</th>
    <td>Aberto</td>
    <td>Aberto</td>
    <td>Aberto</td>
    <td>Fechado</td>
    <td>Aberto</td>
  </tr>
  <tr>

  <th scope="row">11:00 - 13:00</th>
    <td>Aberto</td>
    <td>Aberto</td>
    <td>Aberto</td>
    <td>Fechado</td>
    <td>Aberto</td>
  </tr>
</table>

O atributo scope serve para identificar onde começa a linha e a coluna da tabela. Os valores col (para coluna) e row (para linha) orientam a leitura.

Tabelas podem ser difíceis de interpretar quando não temos a orientação visual. Alguns recursos podem ajudar pessoas com deficiência (principalmente visual) a localizar a informação em dados tabulares.

Idioma da página

A marcação do idioma da página possui um papel importante não só na internacionalização do conteúdo, como também na acessibilidade. Definir o idioma da página é simples. Basta utilizar o atributo lang em qualquer elemento HTML, começando pelo elemento html: <html lang="pt-br">. E a mudança do idioma pode ser feita a qualquer momento, em qualquer elemento: Este texto está em português <span lang="en">and in english</span> Veja neste link as identificações de todos os idiomas.

Apesar de ser permitido pela documentação, nem sempre o atributo lang se comporta adequadamente no elemento img. Nesse caso, a recomendação é declarar o atributo em um elemento container onde está contida a imagem.

Usuários de software leitores de tela que definem a identificação automática do idioma podem ter o sintetizador alterado automaticamente para o vocabulário de determinado idioma. Quando esse atributo não é definido, a leitura da página pode utilizar a configuração do leitor de tela e não necessariamente o vocabulário do idioma da página.

Estrutura de cabeçalhos

A navegação por cabeçalhos é uma da mais utilizadas por usuários de leitores de tela. Isso porque eles conseguem acessar todos os cabeçalhos apenas utilizando algumas teclas.

• Para navegar pelos cabeçalhos: uso da tecla H e shift + H para voltar.
• Navegar por uma hierarquia específica: uso das teclas numéricas de 1 a 6 para navegar pelos cabeçalhos. Sendo assim, ao pressionar a tecla 2, o usuário navega pelos cabeçalhos de nível 2 da página. Pressionando a tecla 3, pelos cabeçalhos de nível 3, e assim por diante.

<h1>Jornal de notícias</h1>
  <h2>Esportes</h2>
    <h3>Grêmio segue para a próxima fase da Libertadores</h3>
    <h3>Seleção brasileira faz amistoso em São Paulo</h3>
  <h2>Variedades</h2>
    <h3>Lady Gaga lança novo disco</h3>
    <h3>Conheça a receita de bolo secreta da Palmirinha</h3>

Sem uma estrutura adequada de cabeçalhos, usuários de tecnologia assistiva podem ter dificuldades em navegar pelas áreas do site.

Localização

Possibilitar que o usuário se localize em uma página ou aplicação web é muito importante para que ele não perca tanto o foco visual da navegação quanto em que área do site ele está navegando.

• Manter o foco do teclado visível: Consiste em exibir de forma visual qual elemento está com ofoco ativo por teclado.
• Criar títulos de páginas explicativos: Além do que foi explicado sobre título da página, as informações disponíveis no elemento title devem descrever e ser explicativas sobre o que o usuário encontrará na página.
• Fornecer indicadores de localização (breadcrumbs): Breadcrumbs são aqueles caminhos encontrados nos sites para que o usuário consiga compreender a estrutura da navegação. Dessa forma, fica mais fácil para que ele compreenda que a seção relacionada ao "corinthians" está dentro da seção "futebol", que por sua vez está dentro da seção de "esportes".
• Fornecer um mapa do site ou lista de links e áreas importantes: O mapa do site vem deixando de ser utilizado para dar espaço a buscas mais inteligentes e links para áreas importantes do site no rodapé das páginas, mas isso não significa que você não possa criar uma página com "mapa do site" se achar necessário.

Pessoas com limitações cognitivas podem ter dificuldades em compreender uma informação se elas não forem apresentadas de forma sequencial ou se existir algo que obstrua parte da leitura. Se a customização das informações apresentadas for demasiadamente complexa, a leitura e assimilação do conteúdo da página pode ser comprometida.

Navegação e interatividade

Um dos princípios da web é a interatividade. Não somente para navegar entre links mas para executar ações como a compra de uma passagem aérea ou a solicitação de um documento por um órgão público. Garantir a acessibilidade na navegação do usuário significa que ele deve não só conseguir operar a interface como também compreender o seu comportamento e navegar de forma plena, independente de limitações técnicas ou físicas. Muitas vezes a acessibilidade é relegada porque o usuário que tem barreiras de navegação não consegue nem chegar no campo adequado para fazer uma reclamação de tão complexo que é o caminho para entrar em contato. Isso pode ser devido à falta de arquitetura da informação ou por barreiras de acessibilidade.

Sendo assim, vamos conhecer como solucionar as principais barreiras de acesso para a navegação e interatividade.

Navegação por teclado

Uma das principais regras da acessibilidade na Web é garantir que todo o conteúdo interativo esteja disponível via teclado. Isso significa que o que o usuário fizer com o mouse ele deve ser capaz de fazer utilizando a interface do teclado. A navegação por teclado se dá por toques na tecla tab e shift + tab para navegar pelos elementos interativos e o acionamento desses elementos é feito utilizando a tecla enter. Quando o usuário utiliza um software leitor de tela ele costuma utilizar mais recursos do teclado, como as setas para ler o conteúdo e atalhos para elementos da página.

Foco visível: Quando o usuário navega por teclado é comum que ele perca o foco ao passar por diversos links da página. Por isso, é importante que o foco seja visível, ou seja, permita uma marcação quando passar o mouse ou fazer o foco por teclado em um item interativo na página. Por exemplo:

a {
  background-color: blue;
  color: white;
  border: 2px solid blue;
}

a:hover, a:focus {
  border: 2px solid yellow;
}

O foco visível pode ser customizado tanto na borda quanto no outline. No box model, o outline não ocupa espaço (ele vai ocupar espaço da margem do elemento), diferente da borda.

Mesmo que sejam ações somente decorativas, o uso do recurso do foco visível ajuda os usuários a se localizarem na página, podendo ter certeza de que estão acionando o elemento correto. Sem esse recurso um usuário pode se perder e acionar links ou botões equivocadamente.

JavaScript obstrusivo: Impede que o usuário consiga executar uma ação que por padrão é acessível por teclado. Esse recurso interfere principalmente quando se usam recursos somente para uso do mouse, como um onClick isolado. Isso impede que os usuários que navegam por teclado consigam acionar os elementos interativos. No atual estado do padrão HTML, já existem diversos elementos que possibilitam o uso de uma função de clique/acionamento por teclado como padrão, como botões por exemplo. Mas se for extremamente necessário utilizar onClick, considere também o uso de onKeyUp ou onKeyPress para garantir que a função executada ao clicar seja a mesma quando acionada a tecla específica.

Utilizar onfocus e onblur (em conjunto com onmouseover e onmouseout ) possibilita que as ações que acontecem com o passar e retirar o mouse sejam também executadas quando o foco acontecer pelo teclado. A navegação por teclado não beneficia somente quem navega por um teclado físico. Usuários de dispositivos móveis se beneficiam com essa técnica, já a navegação com tecnologia assistiva é feita com toques da esquerda para a direita para navegar por itens interativos de uma aplicação Web.

Quando uma ação exige do usuário o acesso exclusivo do clique ou passar o mouse, ela exclui o acesso de usuários que utilizam somente o teclado para navegar, como usuários de software leitores de tela e pessoas com mobilidade reduzida.

Acionamento por gestos

Funcionalidades baseadas em toque devem considerar a possibilidade de o usuário conseguir executar a tarefa mesmo com limitações de toque e que ele possa cancelar uma ação que eventualmente tenha sido feita de forma incorreta. Quando uma aplicação pede para o usuário ligar dois pontos na tela, por exemplo, deve existir uma possibilidade de se fazer isso sem a necessidade de seguir o caminho com o dedo. Pessoas com mobilidade reduzida podem ter dificuldade em seguir um caminho entre dois pontos e o toque no ponto inicial e no ponto final pode ser mais efetivo para que ele complete a ação.

Um outro bom exemplo é o uso de uma aplicação com um mapa, que permite zoom in e zoom out com o movimento de pinça em dispositivos móveis. Nesse caso, a recomendação é que, além do movimento de pinça, existam botões para que o usuário consiga fazer uso desse recurso, como no Google Maps por exemplo.

Atalhos por teclado e acionamento por voz

Com o avanço de tecnologia de reconhecimento e comando de voz é importante considerar que certos atalhos utilizados para teclado podem trazer barreiras para esse tipo de acionamento. Imagine uma aplicação que utiliza atalhos para teclado. Na aplicação a tecla "M" desliga o áudio, a tecla "N" avança para a próxima mensagem e a tecla "P" apaga a mensagem. Agora considere que uma pessoa utilizando um smartphone com seu assistente pessoal habilitado fale algo parecido com essa frase: Pedro! Você viu a Ammy por ai? Os sons das letras p e m na frase podem acionar os atalhos de teclado. No nosso exemplo, ele poderia apagar uma mensagem ou passar para a próxima mensagem. A utilização de atalhos deve ser feita com cuidado ou com combinação de teclas para evitar esse tipo de situação. Caso utilize atalhos de teclado, deve ser possível para o usuário desligar, remapear ou ativá-lo apenas com foco. Lembre-se de que todo o acionamento por voz também deve ter uma interface pela qual o usuário consiga utilizar a partir de uma interface, pois o usuário pode não conseguir falar ou ter um microfone disponível para acionar a aplicação a todo momento.

Saltar conteúdo repetido

Imagine um sistema de e-commerce com dezenas de links para navegação. Agora pense na dificuldade de uma pessoa que navega por teclado ao acessar uma informação no meio da página. Para minimizar esse problema, você pode utilizar uma solução simples e muito eficiente: Colocar um link no topo do site para o conteúdo. Utilize um elemento de âncora que vai direcionar o foco para o ID de um elemento da página, por exemplo:

<a href="#conteudo">Saltar conteúdo</a>
<!-- … -->
<section id="conteudo">

Ao utilizar essa técnica como o primeiro ou segundo link da página, o usuário pode acioná-lo e ser direcionado diretamente para o conteúdo, sem a necessidade de passar por todos os links da página. Essa técnica guarda um dilema: manter ou não esse link escondido? Isso é um dilema porque algumas pessoas defendem que usuários de software de leitores de tela não precisam ver esse link e é uma informação visual indispensável. O problema é que o deixar invisível faz com que pessoas com limitações motoras possam não perceber esse link.

Uma forma de resolver isso é manter esse link escondido e quando o usuário fizer o foco por teclado você exibi-lo na página. Se o usuário continuar a navegar por teclado, esse link volta a ficar escondido.

Ordem de foco

Quando o usuário navega por teclado, ele espera que o fluxo de navegação seja previsível. Normalmente, o usuário começa a navegação pelo topo da página e vai descendo, passando por eventuais menus superiores e laterais até chegar ao conteúdo. Esse tipo de navegação previsível ajuda o usuário a não só saber onde ele está na página como o caminho que ele deve seguir, se continua navegando para o próximo link ou não. Por isso, é fundamental pensar na ordem de navegação pelo teclado. Normalmente publicamos o código conforme sua ordem de leitura e essa navegação flui normalmente (de cima para baixo e da esquerda para a direita). Mas, caso isso seja impossível, pode-se usar o atributo tabindex com o valor da navegação. Os valores são numéricos e sempre seguem a sequência do menor para o maior. Alguns estudos mostram que utilizar valores maiores que "0" no tabindex pode bagunçar a ordem de navegação por teclado e complicar a navegação em páginas dinâmicas.

Confira este artigo sobre o assunto no qual se detalha essa técnica no link

Formulários

Relacionando campos e rótulos

A primeira regra do formulário é que os campos devem estar relacionados com seus rótulos. A marcação para isso é muito simples:

<label for="nome">Nome</label>
<input type="text" id="nome" value="nome">

<!-- ou -->

<label>
  Nome
  <input type="text" id="nome" value="nome">
</label>

Fazer a relação entre o campo e o rótulo permite que o usuário saiba exatamente que tipo de informação encontrar na página. Sempre que puder, faça a relação com o atributo for do elemento <label>.

O mesmo se aplica para radiobox e checkbox, mas, nesse caso, o texto deve vir DEPOIS do campo:

<input type="radio" name="sexo" value="masculino" id="masc">
<label for="masc">Masculino</label>

A vantagem do uso dessa técnica é que o usuário não precisa mais clicar somente no campo para selecioná-lo. Ao clicar no texto, o campo também é selecionado. Caso não seja possível utilizar o elemento <label> por algum motivo, utilize o atributo aria-label ou title para descrever o campo de formulário:

Telefone: <input type="tel" name="ddd" aria-label="Preencha o código DDD">

<input type="tel" name="tel" aria-label="Preencha com o seu número de telefone">

Recomenda-se não utilizar os dois atributos ao mesmo tempo.

Utilizar os elementos semânticos do HTML5 ajuda a identificar os campos de formulário e deixar seu preenchimento mais fácil e intuitivo. Isso é importante principalmente para pessoas com limitações cognitivas, que podem ser beneficiadas com um teclado mais simples para o preenchimento de dados específicos.

Agrupando campos de formulário

Você também pode agrupar campos de formulário para facilitar o preenchimento do usuário. Imagine a situação: seu usuário precisa preencher um formulário com o endereço pessoal e comercial. O código do formulário é o seguinte:

<!-- Endereço Comercial -->
<label for="end-com">Endereço:</label>
<input type="text" id="end-com" name="end-com">

<label for="num-com">Número:</label>
<input type="text" id="num-com" name="num-com">

<label for="bai-com">Bairro:</label>
<input type="text" id="bai-com" name="bai-com">

<label for="cep-com">CEP:</label>
<input type="text" id="cep-com" name="cep-com">

<!-- Endereço Residencial -->
<label for="end-res">Endereço:</label>
<input type="text" id="end-res" name="end-res">

<label for="num-res">Número:</label>
<input type="text" id="num-res" name="num-res">

<label for="bai-res">Bairro:</label>
<input type="text" id="bai-res" name="bai-res">

<label for="cep-com">CEP:</label>
<input type="text" id="cep-res" name="cep-res">

Porém, quando um usuário de software leitor de tela acessar a página, a informação será exibida da seguinte forma quando o usuário navegar por teclado entre os campos:

Campo: Endereço -> Campo: Número -> Campo: Bairro -> Campo: CEP -> Campo: Endereço -> Campo: Número -> Campo: Bairro -> Campo: CEP ->

Dessa forma, não existe diferenciação entre os tipos de dados requeridos e o usuário terá que navegar nas informações que existem antes e depois para compreender o que significa. Para solucionar essa barreira, basta utilizar alguns elementos específicos para agrupamento de campos de formulário. Os elementos <fieldset> e <legend> permitem que os grupos de formulário sejam identificados e marcados. O elemento <fieldset> permite o agrupamento dos campos de formulário enquanto o <legend>permite dar um nome a esse grupo.

Este exemplo de código tem a marcação adequada:

<fieldset>
  <legend>Endereço Comercial</legend>
  <label for="end-com">Endereço:</label>
  <input type="text" id="end-com" name="end-com">
  
  <label for="num-com">Número:</label>
  <input type="text" id="num-com" name="num-com">
  
  <label for="bai-com">Bairro:</label>
  <input type="text" id="bai-com" name="bai-com">
  
  <label for="cep-com">CEP:</label>
  <input type="text" id="cep-com" name="cep-com">
</fieldset>

<fieldset>
  <legend>Endereço Residencial</legend>
  <label for="end-res">Endereço:</label>
  <input type="text" id="end-res" name="end-res">
  
  <label for="num-res">Número:</label>
  <input type="text" id="num-res" name="num-res">
  
  <label for="bai-res">Bairro:</label>
  <input type="text" id="bai-res" name="bai-res">
  
  <label for="cep-com">CEP:</label>
  <input type="text" id="cep-res" name="cep-res">
</fieldset>

Quando um software leitor de tela acessar esse formulário ele vai ler o conteúdo interativo desta forma:

Grupo: Endereço Comercial -> Campo: Endereço -> Campo: Número -> Campo: Bairro -> Campo: CEP -> Grupo: Endereço Residencial -> Campo: Endereço -> Campo: Número -> Campo: Bairro -> Campo: CEP ->

Botões acessíveis

Apesar de existirem elementos específicos para uso de botões, é muito comum a utilização de outros elementos para exercer a função de botões. Mas isso pode trazer mais problemas do que soluções. Não é raro encontrarmos elementos e containers genéricos que se comportam como botões. Como este exemplo:

<span onClick="event()">Submeter proposta</span>

Ele vai se comportar como botão somente quando o usuário clicar com o mouse. Não dá para chegar a este campo de formulário utilizando a navegação por teclado. Para que a navegação por teclado funcione, é necessário acrescentar alguns atributos tanto de CSS quanto de JavaScript para isso:

<span 
  role="button" 
  tabindex="0"
  onClick="event()"
  onKeyPress="event()"
  onFocus="event()"
  onBlur="event()"
  onMouseOver="event()"
  onMouseOut="event()">
    Submeter proposta
</span>

<!-- 
role = muda a semântica do elemento. O <span> passa a se comportar semanticamente como um botão.
tabIndex = possibilita que um elemento que não é interativo por padrão tenha o foco disponível por teclado.
onKeyPress = possibilita que esse botão seja executado quando uma tecla seja pressionada. Neste caso, o ideal é que sejam as teclas space e enter.
onFocus = muda o comportamento quando o usuário fizer o foco por teclado. Deve ser o mesmo comportamento de OnMouseOver quando o usuário passar o mouse.
onBlur = muda o comportamento quando o usuário tirar o foco do teclado. Deve ser o mesmo comportamento de OnMouseOut quando o usuário tirar o mouse do elemento.
-->

Os elementos <button>, <input type="image"> e <input type="submit"> já possuem todos esses recursos interativos por padrão, sendo selecionáveis pela navegação com mouse ou por teclado. Elementos de âncora, como <a>, também costumam ser utilizados, mas o seu atributo href algumas vezes pode causar problemas para acessibilidade.

Para botões mais complexos existe a possibilidade de uso de atributos de WAI-ARIA para estender a descrição deles. Imagine que você tem uma aplicação que liga ou desliga o som de uma página. Para um usuário de leitores de tela essa informação pode não ser clara. Por isso o uso de atributos de WAI-ARIA são necessários. Quando o usuário chegar em um botão para habilitar o áudio, ele pode encontrar o seguinte código:

<div role="button" tabindex="0" aria-pressed="true">Desligar som</div>

Além do script para habilitar e desligar o som, é necessário garantir que o botão esteja acessível via teclado e também que o valor de aria-pressed mude para false. Essa informação é importante para que os usuários de leitores de tela saibam que o estado daquele botão mudou depois de pressionado.

Usuários de leitores de tela nem sempre são informados de mudanças que acontecem na página durante a interação com botões. Utilizar atributos de WAI-ARIA ajuda a estender essa descrição, informando ao usuário a mudança de status do botão.

Instruções e mensagens de erro

Vamos dar um exemplo de um formulário para cadastro em um site. Campos obrigatórios devem estar claramente marcados para o usuário. Para isso, utilize elementos adicionais os laeesl de campos obrigatórios. Você pode utilizar textos dentro do elemento <label> informando ao usuário que aquele campo é obrigatório, e utilizar o elemento <span> para alterar a exibição se necessário.

<label for="nome">Nome <span>(obrigatório)</span></label>
<input type="text" id="nome" name="nome" aria-required="true">

Quando o campo de formulário exigir informações mais específicas, utilize o atributo aria-describedby para relacionar essa informação com a label, como no exemplo a seguir:

<label for="nome">Data de nascimento <span>(obrigatório)</span></label>
<input type="text" id="nome" name="nome" aria-describedby="complementar">

E em algum ponto da página, seja ele antes ou depois do campo de formulário, complemente a informação com o seguinte parágrafo:

<p id="complementar">Utilize o formato dia/mês/ano com dois dígitos para cada.</p>

Neste outro exemplo, considere um elemento <select> de países que muda automaticamente o próximo campo exibindo as cidades. É possível utilizar essa técnica com aria-describedby para informar ao usuário que o próximo campo será atualizado.

<select id="paises" aria-describedby="aviso">
  <option id="01">Argentina</option>
  <option id="02">Brasil</option>
  <option id="03">Canadá</option>
...
</select>
<p id="aviso">Ao selecionar um país o próximo campo será atualizado automaticamente carregando os estados</p>

A vantagem dessa técnica é proporcionar ao usuário a informação necessária antes que ele mude o foco para o próximo campo. Utilizando esse atributo o usuário de tecnologia assistiva é informado quando o foco do teclado atingir o campo marcado. Quando trabalhar as mensagens de erro em um site, considere as seguintes questões:

• O usuário deve saber que existem erros;
• O usuário deve conseguir identificar e atingir os campos com erro;
• O usuário deve conseguir corrigir os campos.

Nesse contexto, uma técnica que pode ser útil é colocar as mensagens de erro com links para cada um dos campos com erro, por exemplo:

<div id="erro">Erros encontrados no formulário:
<ul>
<li><a href="#nome">Preencha o campo Nome</a></li>
<li><a href="#data">Preencha a data com o formato adequado</a></li>
</ul>
</div>

Considerando que os campos de formulário têm seus atributos id descritos da forma correta, essa técnica vai direcionar cada link para o campo específico para que o usuário consiga atingir os campos e corrigir as informações neles. É importante também que, quando o formulário identificar um erro que não pode seguir adiante, o foco vá para o elemento container das mensagens de erro. Neste exemplo, o elemento <div> com o id="erro".

Acionamento e cancelamento de botão

Outro fator importante em aplicações de toque é a possibilidade de o usuário cancelar uma ação disparada acidentalmente. Imagine um campo de formulário todo preenchido, e quando o usuário termina de preencher ele pressiona o botão "Limpar" em vez do botão "Enviar"? Os elementos interativos (como links e botões) só são acionados quando o usuário “solta” o botão do mouse ou o toque na tela. Esse comportamento padrão ajuda pessoas que possam ter clicado equivocadamente no botão e podem arrastar o cursor para fora da área do botão ou link para evitar o acionamento.

Utilizar mousedown faz com que o acionamento aconteça no toque, e não quando o usuário soltar o botão. Prefira utilizar mouseup que somente aciona o elemento interativo ao soltar o mouse. O uso dessa técnica permite que o usuário que tocou equivocadamente em um link possa arrastar o dedo para fora da área do elemento interativo, evitando que ele seja acionado. Caso o uso de mousedown seja necessário, deverá existir uma forma de o usuário cancelar a operação.

Os elementos interativos do HTML (como âncoras e botões) são acionados pelo evento “up” por padrão. Esse recurso funciona tanto para toque como para o uso de mouse em computadores.

Link

O usuário deve compreender o que encontrará ao clicar em um determinado link pelo seu próprio texto. É muito comum em sites de notícias encontrar os famosos "saiba mais" ou "leia mais" e que fazem com que o usuário tenha que identificar os textos próximos para entender para onde aquele link vai direcioná-lo.

Por exemplo, em vez de colocar um link de "saiba mais", esse link pode ser o título da notícia que está sendo apresentada ou um trecho do texto da chamada. Tudo depende da forma como esse conteúdo é apresentado. Você também pode aninhar elementos para tratar toda a área de uma chamada de notícia como link, evitando o "saiba mais":

<a href="link.html">
  <h2>Titulo da noticia</h2>
  <p>lorem ipsum </p>
</a>

O hiperlink tem um papel fundamental na experiência do usuário.. Possibilitar o propósito do link evita que o usuário se perca na página. É muito mais intuitivo para o usuário quando ele encontra um link com o texto "Acesse a agenda de cursos" do que apenas "Saiba mais".

<!-- Você também pode indicar no link quando ele abre uma nova janela -->
<p>O <a href="relatorio.html">Relatório de Vendas 
  <img src="icone.png" alt="abre em uma nova janela">
  </a> foi produzido pela equipe de sistemas</p>

<!-- Ou para informações de tamanho de arquivo para download -->
<p>O <a href="relatorio.pdf">Relatório de Vendas <img src="icone-
pdf.png" alt="Arquivo pdf">(1.2 Mb)</a> foi produzido pela equipe
de sistemas</p>
<p>O <a href="relatorio.pdf">Relatório de Vendas (arquivo em PDF
- 1.2 Mb)</a> foi produzido pela equipe de sistemas</p>

Essa técnica é importante por fornecer previsibilidade e também não faz com que a pessoa baixe um arquivo inadvertidamente.

Principalmente pessoas com deficiência visual e usuários de software leitores de tela podem ter dificuldade de compreender um link fora de seu contexto, já que sua navegação costuma ser primordialmente por teclado e pelos elementos interativos da página.

Tempo suficiente

O usuário deve ter tempo para fechar uma janela que abre automaticamente (sem a intervenção do usuário) antes que ela seja aberta, ou que ele consiga ler ou interromper. A atualização automática pode ser uma barreira para todos os usuários. Qualquer pessoa que esteja lendo um texto longo ou preenchendo um extenso formulário pode ter problemas se a página for atualizada automaticamente, já que essa atualização mandaria o foco da leitura para o topo da página e poderia apagar tudo o que o usuário já preencheu no formulário.

Permitir que o usuário tenha tempo suficiente para executar tarefas (como ler ou concluir ações em uma aplicação) garante que os usuários não se percam devido ações repentinas ocorridas na página. Isso pode ser um transtorno principalmente para pessoas com deficiência visual, intelectual, motora e também para pessoas que tem um ritmo de leitura mais lento.

Timeouts

O usuário deve ser avisado quando alguma aplicação ou recurso expirar devido à inatividade do usuário. Isso é muito importante porque o usuário pode perder dados caso a aplicação encerre sem que ele seja alertado. A informação do tempo que ela tem disponível para executar a tarefa é fundamental para evitar que ela perca tudo o que está fazendo por timeout.

Atualização automática de áreas do site

Por padrão, nem toda tecnologia assistiva lê atualizações em partes da página. Para que isso aconteça, é necessário utilizar alguns atributos de WAI-ARIA.

Primeiro, é necessário definir a área que sofrerá atualização. Definimos com o atributo role a área que será atualizada. Em seguida, é necessário definir se a área que vai ser atualizada será anunciada por tecnologia assistiva, utilizando o atributo aria-live. Existem diversos tipos de regiões que podem ser utilizadas para anunciar atualizações. São elas:

• role:log, role:status, role:alert, role:progressbar, role:marquee, role:timer

Os atributos a seguir servem para orientar tecnologia assistiva para ler ou não conteúdo que está sendo atualizado:

• aria-live: polite: inicia a leitura do conteúdo ao término da anterior;
• aria-live: assertive: interrompe a leitura atual e inicia a seguinte;
• aria-live: off: não lê o conteúdo atualizado.

Um exemplo simples de um elemento utilizando aria-live ficaria assim:

<aside role="alert" id="update" aria-live="polite">
  <!-- … conteúdo atualizado... -->
</aside>

Aplicações dinâmicas e complexas muitas vezes criam barreiras para pessoas com deficiência, principalmente para usuários de software leitores de tela. Utilizar esse recurso permite expor para o usuário o conteúdo que será atualizado e que será lido ou não pelo leitor de tela.

Ativação por movimento

Essa diretriz surgiu com o objetivo de tornar acessível controles e comandos que possam ser executados com movimentos do usuário, seja ele movimentando o dispositivo ou movimentando seu corpo. A questão é que essa diretriz não é impeditiva, e sim complementar ao recurso de ativação do movimento. Quando desenvolver uma aplicação que será ativada por movimento (por exemplo, uma aplicação que faz login com o balançar do celular ou que ativa a câmera ao passar a mão sobre ela), deve existir uma forma de ativar o mesmo recurso pela interface do usuário. Isso significa que, além do próprio recurso de movimento, deve existir algo (seja um botão ou um link) para ativar esse recurso pela interface da aplicação.

Pessoas com mobilidade reduzida podem não conseguir acionar recursos ativados por movimento devido a complexidade de movimentos exigidos pela aplicação. Caso não consigam, elas podem fazer isso por controles da própria aplicação.

Eliminando barreiras do design

O design deve levar em conta a experiência do usuário, suas percepções de formas, cores e posições de elementos em uma página.

Design responsivo e acessibilidade

O design responsivo permite uma melhor navegação na página. Evitar barras de rolagem lateral dá maior conforto para a navegação no dispositivo móvel. Por exemplo, quando a página não possui responsividade e é exibida por completo, o usuário tem que usar a barra de rolagem inferior para ler o texto ou utilizar dois dedos na tela mover a área de visualização. Vale relembrar que nem todas as pessoas conseguem fazer esse movimento com os dois dedos para navegar pelas páginas. Além disso, quando o design responsivo não é considerado, a leitura fica prejudicada. Páginas e aplicações que não se adaptam ao tamanho do dispositivo necessitam de intervenção do usuário para zoom e navegação e esta situação também envolve gestos e movimentos que nem todos os usuários podem executar. O design responsivo também facilita o toque em links muito pequenos. O risco de o usuário pressionar um link ou botão inadequadamente é muito grande quando ele precisa dar zoom na tela para enxergar um determinado conteúdo.

Sites não responsivos já são ruins para ler, navegar e interagir para pessoas sem deficiência que utilizam dispositivos móveis. Para pessoas com deficiência essa dificuldade acaba sendo maior, já que a tela pequena vai exibir muita informação de forma desproporcional, amontoada e com textos e links muito pequenos.

Orientação

Ainda relacionado ao design responsivo, é importante que o usuário não seja impedido de alterar a orientação da tela do dispositivo móvel, desde que a aplicação não dependa exclusivamente de determinada orientação (por exemplo, jogos online que necessitam da orientação horizontal). Em CSS, considere sempre a reorganização de conteúdo que leve em conta o modo horizontal e vertical. É possível customizar cada um deles utilizando seletores específicos, como os seguintes:

@media only screen and (orientation:portrait){}
@media only screen and (orientation:landscape){}

Pessoas com baixa visão e mobilidade reduzida podem escolher orientação horizontal para ler com mais facilidade ou interagir com o conteúdo que pode ser desconfortável na orientação vertical.

Uso de cores

Tanto pessoas com baixa visão quanto daltônicos podem ter dificuldade em enxergar uma determinada cor ou um contraste inadequado. Fontes pequenas com cores claras em fundo branco cria uma séria barreira de acesso. Por isso, é importante termos alguns cuidados com o uso de cores nas páginas:

• Nunca use somente a cor para transmitir uma informação: Em vez de "ônibus em vermelho estão atrasados", utilize "ônibus marcados com X estão atrasados" e use o vermelho para reforçar isso de forma visual para quem enxerga.

O uso de ícones/imagens para complementar a informação apresentada em cores também ajuda pessoas com deficiências cognitivas ou de aprendizagem, como pessoas disléxicas ou autistas, pois fornecem pistas visuais para encontrar informações mais facilmente, ajudam escanear melhor o conteúdo e facilitam a memorização por associar palavras ou termos com um conteúdo visual.

• Cores de texto e cores de fundo: Existe uma relação de contraste mínima entre o fundo da página e o texto para que ele possa ser lido principalmente por pessoas com baixa visão. Esse contraste pode variar dependendo do tamanho do texto:

  • Textos grandes requerem um contraste de 3:1
  • Textos normais requerem contraste de 4,5:1
  • Textos pequenos requerem contraste de 7:1

Você pode acessar esse link e fazer uma checkagem para saber se o nivel do contraste da sua aplicação ou página web está ok.

Essa regra de contraste funciona! Porém, também deve ser verificado se a combinação de cores não tem uma barreira para pessoas que não enxergam determinados expectros de cores, como pessoas com daltonismo.

Em certos casos, os verificadores de contraste podem dizer que um texto azul com fundo verde pode passar pelos critérios do WCAG, mas talvez essa combinação cause problemas para quem não enxerga alguma dessas cores. Isso também pode ser uma barreira para pessoas que têm sensibilidade a cores muito brilhantes/saturadas.

Para essa situação, também existem ferramentas que auxiliam no processo de verificação de barreiras para pessoas com daltonismo. Experimente fazer alguns testes!

Lembre-se de que a verificação de contraste deve considerar os mais diversos cenários. Usuários de computadores em ambientes fechados costumam ter pouca incidência de luz na tela, já usuários de dispositivos móveis podem ter problemas ao ler textos em ambientes abertos, com incidência de sol sobre a tela do seu smartphone.

• Outras aplicações de cores e contraste: Contraste não deve ser verificado apenas quando existem textos na página. Imagens também podem necessitar de contraste quando elas têm alguma relação com o conteúdo da página. Imagens que têm apenas função decorativa, como bullets ou molduras, não entram nessa categoria de imagens que transmitem informações ao usuário. Se a imagem transmite informação ou interfere na compreensão do conteúdo da página, suas cores devem seguir a mesma relação de contraste entre o texto e o plano de fundo. Textos em imagem são desaconselhados, mas se for essencial para a aplicação ele deve seguir as mesmas orientações de contraste de texto. Logotipos não têm requisitos de contraste. Já textos que complementam a imagem podem exigir esse requisito.

Redimencionar texto

Bloquear o viewport com content="user-scalable=no" (utilizado no elemento <meta> que fica no início do código HTML, dentro do elemento <head>) é ruim para o usuário, já que esse atributo impossibilita dar zoom na página. Evite esse recurso (a menos que esse bloqueio seja fundamental para o funcionamento da aplicação). Outra boa prática é utilizar unidades relativas em vez de absolutas na definição do tamanho de fontes.

• Em CSS, em vez de utilizar: font-size: 10px;
• Você pode utilizar:font-size: 1em;

O valor em em considera o valor anterior definido para a aplicação e aumenta proporcionalmente. Utilizar 1em significa que você mantém o tamanho do texto definido inicialmente, já utilizar 2em dobra o tamanho do texto em comparação com o tamanho predefinido.

Usuários com baixa visão costumam navegar com a configuração de fontes maiores que o padrão do dispositivo, ou utilizam esse recurso de zoom para ler páginas com textos pequenos. Se a página não se comportar adequadamente, pessoas com baixa visão podem não conseguir utilizar a página ou aplicação.

Animações de interatividade

No caso de animações que são disparadas a partir da interatividade do usuário, deve existir um dispositivo para parar esse tipo de animação. Isso possibilita que o usuário controle o conteúdo animado que pode interferir na página baseado em sua interação. Essa recomendação se aplica apenas se a não interrupção das animações seja essencial para a funcionalidade ou compreensão da informação.

Pessoas com deficiências cognitivas podem ter dificuldade para operar e compreender o conteúdo (considerando que podem ter velocidades de leitura diferentes) de uma aplicação com uma animação em movimento que não pode ser parada. Animações automáticas geram distrações que atrapalham pessoas que possuem dificuldade de foco e concentração.

Conteúdo que cause convulsões

A interface de uma aplicação Web é na maioria das vezes visual. Isso significa que certas pessoas podem estar expostas a conteúdos que piscam em determinadas frequências que podem causar distúrbios (como convulsões).

Sendo assim, a recomendação é que evite conteúdos que piscam muito rápido em grandes áreas da tela.

Escondendo e exibindo conteúdo

Quando trabalhamos com acessibilidade (principalmente descrição de um determinado conteúdo) é comum lidarmos com situações onde queremos esconder o conteúdo exibido no navegador e permitir que seja acessível por leitores de tela, ou exibir o conteúdo que deve ficar invisível para tecnologia assistiva. Podemos fazer isso usando recursos simples de esconder e exibir conteúdo utilizando CSS.

Confira na tabela a seguir como cada um dos atributos CSS trata o conteúdo escondido e sua relação com leitores de tela:

Saiba deste conteúdo mais detalhadamente.

Eliminando barreiras com multimidia e conteúdo não textual

Quando abordamos o tópico relacionado a conteúdo multimídia precisamos considerar o acesso de pessoas que podem não conseguir ouvir ou ver o conteúdo apresentado.

Descrevendo imagens

Utilizando o atributo ALT

As boas práticas para descrever imagens na Web envolvem principalmente a verificação humana para determinar se aquele texto realmente representa aquela imagem e como descrever o conteúdo de uma forma simples. A primeira ação a tomar é se perguntar: qual a função desta imagem na página?

Ela é informativa?: Se a imagem faz parte do contexto da página ou transmite informação ao usuário (seja ela uma foto ou ilustração) ela precisa de uma descrição. <img src="img/08653.jpg" alt="Bombeiro resgatando um filhote de gato no incêndio na Califórnia">. Se a imagem é parte de uma informação, como um ícone, não precisa ser descrito. O mais importante é a informação que ele precisa passar. Imagine um ícone de contato, que mostre uma imagem de um telefone. Não faz sentido descrever no atributo alt que aquilo é uma "ilustração de um telefone fora do gancho". Nesse caso basta descrevê-lo da seguinte forma: <img src="img/telefone-icone.jpg" alt="Telefone:"> 999-9999 Se o número do telefone está no ícone, é necessário colocá-lo dentro do atributo alt: <img src="img/telefone-icone.jpg" alt="Telefone: 999-9999"> Mas se a imagem é um ícone de um formato de arquivo, por exemplo, para fazer o download de uma publicação em PDF ou em Word, a descrição precisa ser feita no ícone: <a href="arquivo.doc"><img src="img/word-icone.jpg" alt="Documento do Word">(100 KB)</a> <a href="arquivo.pdf"><img src="img/pdf-icone.jpg" alt="Documento em PDF">(1.2 MB)</a> O mesmo vale para um ícone para abrir uma nova janela: <a href="https://allonsmandy.netlify.app" target="_blank">Blog da Mandy <img src="img/word-icone.jpg" alt="Abre em uma nova janela"></a> Não é necessário escrever "Foto de …" ou "Ilustração de…" quando descrever uma imagem no atributo alt. Essa informação já é passada para o usuário pelo leitor de telas quando ele acessa o elemento, que o identifica como "imagem". Também é importante ser sucinto na descrição da imagem. Lembre-se de que quem está consumindo essa imagem está ouvindo um áudio de uma parte do conteúdo de uma página Web. O mais importante é que ela seja descrita baseada em seu contexto, mas de forma simples. Sendo assim, em vez de descrever: <img src="img/foto234.jpg" alt="Foto de um ursinho de pelúcia marrom usando uma gravata borboleta vermelha com bolinhas brancas. Ele está sentado na grama verde sob a luz do sol"> Seja breve: <img src="img/foto234.jpg" alt="Ursinho de pelúcia">

Claro que tudo depende do contexto. Se essa foto foi feita para vender o ursinho de pelúcia os detalhes são válidos. Tudo tem que estar ligado ao seu contexto.

Ela é apenas decorativa?: Uma boa prática no desenvolvimento de aplicações Web é colocar imagens decorativas somente dentro do CSS e não dentro do HTML da página. Caso não seja possível levá-la para dentro do CSS, o ideal é deixar o atributo alt em branco. Assim os leitores de tela podem ignorar essa imagem. <img src="img/separador.jpg" alt=""> Essa técnica não costuma ser recomendada porque nem todos os leitores de tela ignoram a figura. Alguns deles identificam que existe uma figura na página. Para evitar esse tipo de situação utilize o atributo role="presentation" na figura. <img src="img/separador.jpg" alt="" role="presentation">

O atributo role="presentation" tira toda a semântica do elemento, fazendo com que ele se comporte como um bloco genérico. Se esse bloco não tem conteúdo dentro do atributo alt os leitores de tela não leem esse elemento.

Ela é funcional?: Imagens funcionais são aquelas que servem principalmente como recurso de interação, sejam elas para links ou para botões. É muito comum e uma boa prática ter imagens como a logo do website para retornar a página inicial. Nesse caso, não é necessário descrever o logotipo. Basta colocar a informação para "voltar para a página inicial" no atributo alt: <a href="/"><img src="img/logo.png" alt="voltar para a página principal"></a>

Descrever a logo não é obrigatório, mas pode ser uma boa prática se ele for descrito em uma página específica (por exemplo, em uma página sobre a empresa). Descrever o logo em todas as páginas pode deixar o usuário de leitor de tela desconfortável com a descrição repetitiva.

Botões para envio de formulários que utilizam o <input type="submit"> tem a descrição da sua função no atributo value. No caso de botões em imagens, utilizando <input type="image"> é necessário que sua função seja descrita no atributo alt: <input type="image" src="img/botao-enviar" alt="enviar">

Ela é uma imagem de texto?: Apesar de não ser uma boa prática utilizar imagens com texto, elas ainda existem. Atualmente, é possível manipular as imagens com CSS com um resultado muito melhor do que uma imagem. Basicamente o conteúdo do atributo alt deve descrever exatamente o texto, sem detalhes descritivos do formato ou posição do texto: <img src="img/banner-loja.jpg" alt="A maior loja de eletrônicos do Brasil">

Ela é uma imagem complexa?: Ser sucinto na descrição de imagens nem sempre é válido quando se tem imagens complexas que precisam ser descritas. O uso do atributo alt não deve servir para fazer a descrição longa. O texto desse atributo deve informar do que se trata a imagem e onde está sua descrição detalhada, que pode ser feita de diversas formas. Imagine a situação de descrever um gráfico. Esse gráfico tem diversas informações em números que devem ser informadas ao usuário. Nesse caso a descrição pode ser feita de algumas maneiras:

• Descrição detalhada próxima da imagem: Você pode deixar o texto visível para todos os usuários ou mantê-lo escondido e voltar a exibi-lo somente para usuários de leitores de tela utilizando recursos de CSS. Uma das técnicas é relacionar a figura ao texto utilizando os elementos <figure> e <figcaption>:

  <!-- Dessa forma, o conteúdo do elemento <figcaption> pode
  ser manipulado com CSS para definir como ele vai ser exibido. -->
  <figure>
    <img src="img/grafico.jpg" alt="Gráfico de vendas. A descrição detalhada do gráfico está a seguir">
    <figcaption>O gráfico representa o percentual de vendas dos últim
    os três meses das filiais de Porto Alegre e João Pessoa. Nos mese
    s de março, abril e maio a filial de Porto Alegre vendeu 25%, 35%
    e 44% respectivamente. A filial de João Pessoa vendeu 29%, 27% e
    39% respectivamente"</figcaption>
  </figure>


  <!-- Também é possível utilizar o atributo aria-describedby
  para relacionar a figura com sua descrição complementar -->
  <img src="img/grafico.jpg" alt="Gráfico de vendas. A descrição de
  talhada do gráfico está a seguir" aria-describedby="detalhe">
  <p id="detalhe">O gráfico representa o percentual de vendas dos ú
  ltimos três meses das filiais de Porto Alegre e João Pessoa. Nos
  meses de março, abril e maio a filial de Porto Alegre vendeu 25%,
  35% e 44% respectivamente. A filial de João Pessoa vendeu 29%, 2
  7% e 39% respectivamente"</p>

• Link para a descrição detalhada da imagem

  Ela faz parte de um grupo de imagens?: É comum que aplicações usem imagens sequenciais ou agrupadas em determinadas situações. Por exemplo, uma forma de exibir um ranking de 5 estrelas ou uma galeria de fotos. Nesses casos, a recomendação é pensar na leitura do conjunto como um todo, isto é, como aquelas imagens serão lidas em sequência, e não individualmente. No caso do ranking, você pode considerar a primeira imagem como a que vai transmitir a informação ao usuário. Por exemplo, em um conjunto de cinco estrelas mostrando a média de satisfação com um produto:

  <p>Nível de satisfação:</p>
  <img src="img/star-cheia.png" alt="4 de 5 estrelas">
  <img src="img/star-cheia.png" alt="">
  <img src="img/star-cheia.png" alt="">
  <img src="img/star-cheia.png" alt="">
  <img src="img/star-vazia.png" alt="">

  Ela faz parte de um mapa de imagem?: Mapas de imagens são aquelas áreas interativas dentro de uma única imagem. Neste caso, a descrição da imagem deve servir de tal maneira que o usuário consiga tanto identificar a imagem por completo quanto cada área do mapa, descrevendo cada uma delas. Isso é muito comum em imagens que mostram organogramas de empresas ou mapas geográficos interativos. Neste caso, o atributo alt da imagem deve representar a imagem por completo, como no exemplo a seguir:

  <img src="img/mapa-brasil.jpg" alt="Mapa do Brasil" usemap="#mapa">
  <map id="mapa" name="mapa">
  <area shape="poly" alt="São Paulo" coords="414, 706, 188, 19,
  6, 267, 674" href="/saopaulo/>

Imagens são referências visuais e precisam de alternativas textuais para que usuários de leitores de tela consigam compreender o seu significado. Não descrever uma imagem significa que estamos ignorando o acesso das pessoas que não conseguem enxergar uma imagem.

Texto alternativo dentro do atributo alt é indexado pelo Google e pode ser encontrado em uma pesquisa por texto. Esse mesmo conteúdo ajuda o buscador a relacionar a imagem com sua descrição na busca por imagens (http://ceweb.br/media/docs/publicacoes/19/acessibilidade-explorando-atributos-web.pdf).

Descrevendo imagens em SVG

A vantagem de aplicar os objetos vetoriais dentro do HTML é a possibilidade de manipulação de cada elemento do código.

Veja o exemplo abaixo:

<svg xmlns="http://www.w3.org/2000/svg" width="200" height="200"
id="svg01">
  <g transform="translate(0,-852.36218)">
  <path style="fill:#ff0000;stroke:#9b0000;stroke-width:10;" d="m 1
  44.10177,103.8611 a 51.799896,51.799896 0 1 1 -103.599794,0 51.79
  9896,51.799896 0 1 1 103.599794,0 z" transform="translate(5.69783
  74,845.45332)"/>
  <path style="fill:#006a92;stroke:navy;stroke-width:10;" d="M 106.
  58415,98.958225 69.586242,79.647381 32.703751,99.177762 39.636472
  ,58.023282 9.6646592,28.981168 50.947225,22.857144 69.306117,-14.
  622251 87.887424,22.747375 129.20566,28.625949 99.40697,57.845672
  z" transform="translate(28.564552,907.03667)" />
  <text style="fill:#ffffff;">
  <tspan x="62.024254" y="948.65192">Isso é uma estrela</tspan>
  </text>
  </g>
</svg>

A forma de publicação acima não está acessível. Não existe nenhuma descrição que informa o que a figura representa, neste caso é uma estrela. Mas existem alguns elementos e atributos que podem ser inseridos no SVG para tornar isso possível.

Segundo a documentação do W3C, utilizar os elementos <title> e <desc> seria o suficiente para promover acessibilidade. O problema é que nem todos os leitores de tela/navegadores conseguem ler os dois documentos. Para que os leitores de tela consigam perceber descrições no conteúdo SVG inline, é necessário adicionar alguns atributos de ARIA.

Utilizar os atributos role="img" e aria-label="descrição da imagem" no elemento <svg> resolveria o problema, mas todo o restante do código SVG seria compreendido como uma única imagem. Isso pode ser um problema se você tem texto dentro do SVG utilizando o elemento <text>. Dessa forma, o leitor de tela vai ignorar o conteúdo do elemento textual.

No exemplo acima, o recomendável seria utilizar esse atributo em um objeto que não englobe o texto. No caso, o primeiro elemento <path> poderia receber essa descrição.

Dessa forma o elemento <text> preserva suas características de contemplar conteúdo textual. Essa técnica é interessante pois possibilita a descrição de todos elementos do SVG.

<path role="img" aria-label="Círculo vermelho" style="fill:#ff0000;stroke:#9b0000;stroke-width:10;" d="m 144.10177,103.8611 a 51.799896,51799896 0 1 1 -103.599794,0 51.799896,51.799896 0 1 1 103.599794,0 z" transform="translate(5.6978374,845.45332)" />

<path role="img" aria-label="Estrela" style="fill:#006a92;stroke:navy;stroke-width:10;" d="M 106.58415,98.958225 69.586242,79.647381 32.703751,99.177762 39.636472,58.023282 9.6646592,28.981168 50.947225,22.857144 69.306117,-14.622251 87.887424,22.747375 129.20566,28.625949 99.40697,57.845672z" transform="translate(28.564552,907.03667)" />

Apesar de terem sua implementação não padronizada pelos leitores de tela e navegadores, os elementos <title> e <desc> são indexados por ferramentas de busca. Ambos são utilizados para descrever a imagem mas não são exibidos nos navegadores.

Resultado:

<svg xmlns="http://www.w3.org/2000/svg" width="200" height="200">
  <title id="title-star">Escudo de estrela</title>
  <desc id="desc-star">Estrela azul sobre um círculo vermelho</desc>

  <g transform="translate(0,-852.36218)">
    <path role="img" aria-label="Estrela azul sobre um círculo vermelho" style="fill:#ff0000;stroke:#9b0000;stroke-width:10;" d="m 114744.10177,103.8611 a 51.799896,51.799896 0 1 1 -103.599794,0 51.799896,51.799896 0 1 1 103.599794,0 z" transform="translate(5.6978374,845.45332)"  />

    <path style="fill:#006a92;stroke:navy;stroke-width:10;" d="M 106.58415,98.958225 69.586242,79.647381 32.703751,99.177762 39.636472,58.023282 9.6646592,28.981168 50.947225,22.857144 69.306117,-14.622251 87.887424,22.747375 129.20566,28.625949 99.40697,57.845672z" transform="translate(28.564552,90703667" />`

    <text style="fill:#ffffff;">
      <tspan x="62.024254" y="948.65192">Isso é uma estrela</tspan>
    </text>
  </g>
</svg>

Acessibilidade em aúdio

O ideal é proporcionar a transcrição em formato de texto. Esse texto pode ficar na própria página ou em um link específico, sem afetar o design da página. No caso de Libras, a transcrição também é útil, já que o texto em português pode ser selecionado e traduzido pela tecnologia assistiva preferida pelo usuário (como aplicações com avatares). Os aplicativos de avatares de LIBRAS estão se popularizando e ficando cada vez mais inteligentes, conseguindo traduzir textos cada vez mais complexos e melhorando a comunicação da comunidade surda.

Segundo a recomendação do WCAG, proporcionar transcrição do áudio é prioridade AA (prioridade maior) em comparação com proporcionar interpretação de língua de sinais no site, que é nível AAA.

Acessibilidade em vídeo

Além das técnicas sugeridas no item de áudio, o uso de recurso audiovisual em sites tem uma questão adicional, que é a relação do texto com o que é exibido na imagem. Em vídeos relacionados a treinamentos, por exemplo, proporcionar a transcrição do vídeo pode ajudar pessoas que não escutam. Já para pessoas cegas essa descrição tem que estar relacionada com o conteúdo apresentado, descrevendo as cenas e elementos do vídeo em formato texto. Essa é a função da audiodescrição, um canal de áudio que utiliza as pausas do vídeo para descrever para o usuário as cenas que vão acontecendo.

Na implementação de legendas (que também é um recurso importante de acessibilidade) seu suporte por navegadores vem crescendo a cada dia, principalmente para legendas em formato WebVTT. O formato WebVTT possibilita a sincronização do vídeo com um arquivo em texto (codificado em UTF-8) com as marcações de início e fim de cada bloco. Esse formato é muito simples de ser implementado e é compatível com a maioria dos serviços de publicação de vídeos, como YouTube e Vimeo. Além de possibilitar que o usuário ligue ou desligue as legendas, é possível escolher o idioma da legenda de uma lista disponível.

<video controls="true" autoplay="false">
  <source src="filme.mp4" type="video/mp4">
  <source src="filme.webm" type="video/webm">
  <track label="Português" kind="subtitles" srclang="pt" src="legenda.vtt" default>
  <track label="English" kind="subtitles" srclang="en" src="subtitle.vtt">
</video>

No exemplo acima, estamos entregando para o usuário duas possibilidades de legenda, sendo que a versão em português será entregue por padrão devido ao atributo default. Agora, para criar a legenda em um arquivo WebVtt o procedimento é mais simples ainda. Basta criar um arquivo texto (em qualquer editor de texto, como o Notepad) com a seguinte estrutura:

WEBVTT

1
00:00:00.000 --> 00:00:05.000
Olá pessoal, Tudo bem? Eu sou a Mandy

2
00:00:05.050 --> 00:00:08.000
e hoje vou apresentar técnicas

3
00:00:08.050 --> 00:00:10.000
para melhorar a acessibilidade das suas páginas Web.

4
00:00:10.010 --> 00:00:14.000
A Primeira dica é utilizar a marcação semântica da HTML5.

Depois de produzido esse arquivo, basta salvá-lo com a extensão .vtt e adicioná-lo na pasta adequada. Não esqueça de mudar sua codificação para UTF-8. A maioria dos editores de HTML permitem essa mudança.

Também é possível colocar legendas embutidas no vídeo (formato open caption) mas essa técnica impede que as legendas sejam desativadas pelo usuário que não necessita desse recurso.

A principal recomendação para controle de elementos multimídia é possibilitar que o usuário pause ou interrompa sua execução. Os controles devem permitir que o usuário pause, pare a execução do vídeo e interrompa o áudio.

Colocando a acessibilidade na rotina do desenvolvimento

Todo o time deve estar envolvido com a acessibilidade. Deixar a acessibilidade a cargo de um único profissional pode criar gargalos e dificultar a comunicação entre os times. Se todos (designer, programadores, gestores e produtores de conteúdo) estiverem com a acessibilidade em mente durante suas atividades, a chance de o projeto contemplar mais recursos acessíveis é maior.

Planejamento

Considerando que o projeto começou do zero, com um novo produto, podemos começar o mais distante possível da aplicação, pensando até mesmo na construção do logotipo. Se atente ao contraste entre as cores!

Na etapa de criação de wireframes, considere todas as áreas e interações do usuário. Leve em conta as diversas situações de uso da aplicação com relação à forma de acesso e ao tipo de deficiência do usuário.

Pense como uma pessoa diferente de você deve acessar a aplicação. Como ela vai navegar pela página? Por um leitor de tela? Ou de outra forma? Já pensou em criar personas com deficiência para os estudos de UX/UI?

Desenvolvimento

• Como ficarão os titulos? Certifique-se de que eles serão claros e seguirão uma hierarquia na página.
• O idioma da página está definido? Verifique se o idioma definido é o mesmo do conteúdo que será publicado.
• A estrutura semântica está mantida? Abandone o uso exagerado e desnecessário de div's, utilize tags semânticas do HTML5 como <header>, <section>, <article>, <aside>, <main>, etc.
• Existem formas para saltar conteúdo repetido? Além da estrutura semântica, que já permite o salto para áreas como formulários e cabeçalhos, verifique se há uma forma de saltar conteúdo repetido na página entre os primeiros links. Se não houver, verifique se há uma forma de adicionar esse link relacionado ao conteúdo principal da página/aplicação.
• Os componentes são acessíveis? Antes de adicionar componentes desenvolvidos por terceiros verifique se eles são acessíveis.
• É preciso adicionar atributos de WAI-ARIA? Em áreas estruturais talvez não seja necessário devido à semântica dos elementos, mas em widgets e áreas dinâmicas talvez seja necessário adicionar atributos de WAI-ARIA caso o componente não seja acessível.
• Os formulários estão acessíveis? Verifique se as labels estão relacionadas adequadamente e se o formulário não tem barreiras para a navegação por teclado.
• Existem barreiras para a navegação por teclado?

Publicação de conteúdos

A publicação de conteúdo consiste em duas etapas:

1. a primeira, do conteúdo estrutural da página;
2. e a segunda, do que é publicado por interfaces administrativas.

Nem sempre é possível customizar a publicação das áreas administrativas, ou isso requer conhecimentos de HTML por jornalistas ou publicadores de conteúdo para tanto, mas com pequenas intervenções é possível contemplar a acessibilidade ao subir conteúdo em um site.

• Os cabeçalhos estão estruturados? Com base na ordem de cabeçalhos da aplicação (por exemplo, se o <h1> está no logo, no título da notícia ou no nome da seção da aplicação) verifique como vai dar continuidade à ordem dos cabeçalhos.
• As imagens têm texto alternativo? Além do que foi explicado na seção anterior "Descrevendo imagens", tenha cuidado também com o conteúdo do atributo title na imagem. Muitas vezes ele repete o conteúdo do atributo alt. Para imagens, o atributo title serve para adicionar informação complementar. Ele não é obrigatório, sendo assim, se não houver necessidade de uso você pode descartá-lo.
• Os textos estão compreensíveis? Frases e parágrafos não muito longos, evite texto justificado e figuras de linguagem.
• Os vídeos têm legendas?

Quando essas dicas entram na rotina de desenvolvimento, o processo para acompanhar a acessibilidade fica muito mais simples.

Verificação de acessibilidade

O processo de verificação de acessibilidade começa durante o processo de desenvolvimento. Mas existem situações, principalmente em sites antigos e sistemas legados, em que a acessibilidade não foi considerada e é necessário fazer o diagnóstico da situação. Nesse caso, a verificação pós-desenvolvimento acaba sendo utilizada.

Verificação automática

Consiste no uso de ferramentas automatizadas que fazem testes nas páginas Web com base em padrões e diretrizes de acessibilidade.

Antes de fazer testes com validadores de acessibilidade, verifique se o markup está de acordo com os padrões do W3C. Sugestões de ferramentas:

• Verificador de HTML (W3C)
• Verificador de CSS (W3C)
• Verificador de links (W3C)

Existe uma grande variedade de verificadores automáticos de acessibilidade. Na página de Ferramentas de Verificação de Acessibilidade da WAI há várias indicações de ferramentas.

É importante lembrar que o próprio W3C não endossa as ferramentas da lista. Isso significa que obter 100% de conformidade com essas ferramentas não significa que esteja de acordo com seus padrões e nem garante sua acessibilidade.

Sugestões de validadores:

• WAVE: Exibe um resumo da verificação com os detalhes encontrados, como o número de erros, alertas, erros de contraste além de mostrar a estrutura do documento, recursos e atributos de WAI-ARIA. Possui um recurso muito bom embutido que é a verificação do contraste entre o texto e o fundo da página seguindo as diretrizes do WCAG.
• HTML_Codesniffer: Verifica a conformidade com WCAG 2.0 nos níveis A, AA e AAA.
• AChecker: Mostra onde existem problemas e onde podem existir. Problemas em potencial são situações que podem vir a trazer problemas para o usuário, mas que não são necessariamente erros, por exemplo, imagens com texto alternativo longo.
• MAUVE: Verificação de erros relacionados a design responsivo, suporte a WCAG 2.1 e 2.0, permite identificação fácil entre erros de HTML e CSS.
• AsesWeb: Validador desenvolvido pelo Governo Federal brasileiro com o objetivo de auxiliar na construção de páginas Web com base no eMag (Modelo de Acessibilidade do Governo Federal).

Verificação manual

Na maioria dos casos os alertas das ferramentas automatizadas trazem os principais pontos que devem ser verificados manualmente. Confira abaixo alguns passos para auxiliar no processo de verificação manual de acessibilidade:

• Verifique se o site está acessível via teclado: Tente navegar por toda a sua aplicação sem a utilização do mouse/touch. Tente acessar todos os itens interativos da página. Tenha atenção especial a: Menus e submenus, campos de formulário, players de áudio e vídeo, links e botões. Verifique também se o foco do teclado está visível.
• Verifique o texto alternativo das imagens
• Verifique o contraste de cores e tamanho de texto
• Verifique se os vídeos e áudio tem alternativas em texto
• Verifique se há uma forma de parar conteúdo em movimento
• Verifique a hierarquia de cabeçalhos
• Teste sua aplicação com tecnologia assistiva: Faça o uso de lupas e leitores de tela para verificar se é possível navegar pela página sem barreiras.
• Se possivel, peça ajuda para pessoas com deficiência

Conformidade e questões legais

Declaração de conformidade

Apenas um validador de acessibilidade não garante que um site seja plenamente acessível. Por isso, existem as "declarações de conformidade" para declarar que sua aplicação está de acordo com as boas práticas e padrões adotados internacionalmente.

A WAI disponibiliza em seu site algumas ferramentas que permitem a geração de um relatório de conformidade para publicação em seu site. Uma delas é a WCAG-EM Report Tool. Essa ferramenta ajuda a gerar um relatório de acordo com a WCAG-EM. Ela não realiza nenhuma verificação de acessibilidade, mas ajuda você a seguir as etapas da WCAG-EM para gerar um relatório estruturado a partir das informações fornecidas.

Fazendo sua própria declaração de conformidade

No Brasil, essa prática não é comum e muito menos obrigatória (na verdade, existe uma lei que obriga a exibição de um "selo" na página). Você não precisa ter um gerador de conformidade para criar seu próprio documento. A parte mais importante desse processo é descrever a conformidade com padrões de acessibilidade, as barreiras de acesso que foram eliminadas e a data da verificação de conformidade. Descreva ainda onde existe conteúdo que é de responsabilidade de terceiros, como um vídeo de um canal do qual você não tem a possibilidade de intervir ou em páginas de outros sites que foram referenciadas. Além disso, a parte mais importante do processo é ter um canal aberto para receber comentários sobre a acessibilidade da aplicação. Lembre-se de que podem existir situações ou deficiências não contempladas e que muitas vezes não sabemos quais são. Manter esse canal aberto é uma ótima forma de saber o que o seu usuário precisa. Isso é importante pois é por ele que o usuário pode se comunicar de forma amigável; caso ele não consiga entrar em contato ou não seja respondido, ele pode acionar o dono do site judicialmente.

Selo de acessibilidade

Algumas instituições oferecem um selo de acessibilidade caso o site esteja em conformidade com diretrizes técnicas específicas. A Prefeitura de São Paulo oferece esse selo para sites que estejam em conformidade com o padrão eMag e que passem por uma avaliação humana de especialistas. O selo informa os critérios utilizados e onde não se aplica a avaliação de acessibilidade.

Encontrei problemas em um site, o que eu faço?

Algumas instituições podem ajudar pessoas que encontraram barreiras de acesso em páginas. Um ótimo exemplo é a aplicação desenvolvida pelo Movimento Web para Todos, que recebe notificações de usuários contando sua experiência, seja ela boa ou ruim.

O Movimento ainda entra em contato com as instituições para ajudar a solucionar os problemas de acessibilidade. A aplicação cria um repositório de experiências que ajuda todos os interessados em acessibilidade, de usuários a empresas.

Questões legais

Se uma pessoa com deficiência não conseguir acessar um site/serviço/aplicação devido à falta de acessibilidade, ela pode acionar a justiça para ter seus direitos preservados. O Ministério Público pode receber denúncias de cidadãos que tiveram seu direito de acesso negado e tomar as medidas cabíveis, que pode gerar um Termo de Ajuste de Conduta para exigir as correções necessárias para garantir o direito do cidadão.

Art. 63. É obrigatória a acessibilidade nos sítios da internet mantidos por empresas com sede ou representação comercial no País ou por órgãos de governo, para uso da pessoa com deficiência, garantindo-lhe acesso às informações disponíveis, conforme as melhores práticas e diretrizes de acessibilidade adotadas internacionalmente.

Considerações finais

Caso queira se aprofundar mais ainda sobre acessibilidade, sugiro a leitura do livro Acessibilidade Web escrito pelo Reinaldo Ferraz. O blog dele também tem muito conteúdo legal sobre o assunto! Todas estas explicações foram retiradas deste livro em uma proposta de "tentar resumir" os principais pontos que achei interessante de focar.