Logo nos primeiros meses que resolvi migrar para a área de desenvolvimento, tive o prazer de participar de uma dinâmica que mudou completamente minha perspectiva sobre aquele monte de código que eu colocava na tela.
Com olhos vendados, e o leitor de tela ligado, meu objetivo era entrar no site da BBC e ler uma notícia. E eu quase não consegui, gostaria de dizer. Fiquei deslumbrada pela acessibilidade na web e quão isso era importante, pois é justamente essa autonomia, de, por exemplo, conseguir ler uma simples notícia que acessibilidade trata.
No meu dia a dia, a funcionalidade de autocompletar do celular é algo que facilita minha digitação. No entanto, para alguém com uma deficiência motora, por exemplo, essa função é a independência de mandar mensagens sozinha.
Resolvi então me aprofundar no tema e escrevi esse artigo introduzindo o assunto.
O conteúdo foi baseado no livro "Acessibilidade na Web" da Casa do Código, escrito por Reinaldo Ferraz, atualmente gerente de projetos no Consórcio World Wide Web (W3C) Brasil e no Centro de Estudos sobre Tecnologias Web (Ceweb.br).
Além de fácil leitura, o livro serve como um guia para tirar dúvidas específicas, seja documentação ou código. Atendendo a todos os públicos, não apenas a desenvolvedores.
Então comecemos :)
Mas o que é e pra quem é acessibilidade ?
Em Julho 2015, a lei Brasileira de inclusão foi sancionada, garantindo com resoluções definitivas, o direito à inclusão de todas as pessoas nos diversos ambientes, inclusive nos sites.
Segundo a W3C, a definição de acessibilidade na web é:
“Acessibilidade na Web significa que sites, ferramentas e tecnologias são projetados e desenvolvidos para que pessoas com deficiências possam usá-los. Mais especificamente, as pessoas podem: a) perceber, entender, navegar e interagir com a Web; b) contribuir para a web."
Além disso, vale salientar que garantir um site acessível beneficia também outros grupos de usuários, que podem não ter deficiência, mas utilizam a aplicação em diferentes cenários. Por exemplo, o contraste bem estabelecido entre cores pode garantir não apenas que pessoas com problemas de visão consigam ler, mas que outras pessoas também consigam quando estão com o celular na rua sob a incidência do sol.
O que eu ganho desenvolvendo meu produto com acessibilidade?
Segundo o IBGE, em média 24% da população possui algum tipo de deficiência, isso é cerca de 46 milhões de pessoas.
Ou seja, se o seu site não for acessível, são 46 milhões de pessoas a menos trafegando por ele. E em relação aos negócios, isso faz toda a diferença, pois além de estar ignorando clientes em potencial, o seu site possuirá um SEO reduzido, e não aparecerá entre os mais relevantes no ranqueamento de pesquisas do Google.
WCAG, sua documentação e o que pode ser aplicado
O Web Content Accessibility Guidelines (WCAG) é o principal documento de acessibilidade na Web, no qual o desenvolvedor deve se basear para tornar o conteúdo acessível.
Nele temos 4 princípios que norteiam a construção da base de acessibilidade:
*Perceptível - A interface do usuário deve ser apresentada em formas que possam ser percebidas pelo usuário. Qualquer conteúdo precisa ter mais de uma forma de ser apresentado ao usuário.
*Operável - Os componentes de interface de usuário e a navegação devem ser operáveis, independente da ferramenta escolhida, celular, tablet, navegação por teclado.
*Compreensível - A interface deve informação e modo de operação compreensível ao usuário. Esse ponto é além do técnico e trata por exemplo do uso de cores e outras diretrizes.
*Robusto - O conteúdo deve ser robusto o suficiente para ser interpretado de forma confiável e acessível a um número maior de navegadores e tecnologias assistivas.
Além disso, existem também os critérios de sucesso, que possuem níveis de conformidade, auxiliando na construção do site baseados nas diretrizes.
*Nível A: Esse nível atinge grupos de pessoas com certos tipos de deficiência fazendo-os acessar de forma plena.
*Nível AA: Contempla um número maior de pessoas além do tipo A, eliminando barreiras de acesso.
*Nível AAA: Engloba os outros níveis de padrão permitindo que mais pessoas sejam incorporadas, mas é o padrão mais difícil de se atingir. É recomendado apenas para setores específicos do site, quando necessário.
Dentro da WCAG, encontramos as também as várias diretrizes, com seus nomes normalmente auto-explicativos, um exemplo seria:
"Tamanho da área clicável (AAA) - Tamanho do ponto de interatividade (toque ou clique)".
O que é WAI-ARIA?
A Accessible Rich Internet Application (ARIA) é uma especificação criada pela Web Accessibility Initiative (WAI), daí vem a sigla WAI-ARIA. Essa documentação (https://www.w3.org/TR/wai-aria-1.1/) foi criada com o objetivo de lidar com os conteúdos dinâmicos em aplicações web, oferecendo regras (em forma de atributos), que podem ser divididos em duas categorias: roles (papéis ou funções) e states and properties (estados e propriedades).
O livro explica bem e de forma simplificada todos os papéis e estados disponíveis para uso. Mas confesso que achei bem divertido o uso dos states and properties e vou dar alguns exemplos.
Há diversos atributos que a tecnologia assistiva usa e são bem importantes de se colocar na construção da sua aplicação.
O primeiro que eu posso trazer é o "role", que define o papel que aquele elemento tem dentro da página. Ele diz ao leitor o que é aquilo e como a pessoa vai interagir com aquele elemento.
A segunda é o "state" daquele elemento. Ele está inativo ou ativo? ele está marcado ou desmarcado (no caso de um checkbox ou radio button)?
Além dessas documentações existem diversas outras, menos conhecidas, mas tão importantes quanto, como:
*Cognitive and Learning Disabilities Accessibility (COGA), foca no acesso de pessoas com deficiências neurológicas, limitações cognitivas e dificuldades de aprendizado
*Mobile Accessibility, área no site do próprio W3C para agrupar diretrizes de acessibilidade direcionadas para dispositivos móveis.
*Accessibility Conformance Testing (ACT), define regras de regras e técnicas para testes de acessibilidade em aplicações web.
*Game Accessibility Guidelines, traz boas dicas para o desenvolvimento de jogos online.
Por onde eu começo?
Existem milhares de implementações possíveis para tornar sua aplicação acessível, mas geralmente com alguns pequenos ajustes já podemos fazer total diferença na navegação.
Alguns pontos foram abordados também no episódio número #21 do podcast do Hipsters.tech (que por sinal SUPER recomendo) pelo próprio Reinaldo Ferraz, que era um dos convidados do episódio.
Tags Semânticas
A página ser semântica ajuda muito na navegação. Por exemplo:
A tag <button> existente no HTML possui nas suas funções nativas diversas propriedades que facilitam inclusive a aplicação das funcionalidades de um botão.
No entanto, é difícil encontrar quem nunca viu um <span>, que apesar do design idêntico ao de um botão, que estava cheio de javascript para que ele tenha as mesmas funções.
Dessa forma o leitor de tela não identifica o elemento que desejamos, pois eles não correspondem à sua tag.
Assim como um botão, outros elementos possuem suas próprias tags nativas, que ajudam na identificação pelo leitor de tela e navegação pelo teclado de forma coerente. Temos por exemplo a tag <header>, <footer>, <nav>.
tabindex
Navegar em um site via teclado significa pular de um elemento focalizável para outro na ordem do DOM. Isso geralmente é realizado usando a tecla Tab.
O atributo tabindex define quais elementos podem receber foco através da navegação pelo teclado e a ordem que isto ocorre. Caso o valor seja -1, esse elemento será ignorado pela sequência.
É importante falar que o tabindex precisa ser dosado no uso. Aconselha-se não usar com números positivos pois essa ordem irá sobrepor a hierarquia do DOM. Colocando apenas valor zero já permite que o elemento se torne focalizável sem alterar sua ordem.
Indico esse artigo que explica como utilizar da melhor maneira sem influenciar negativamente a acessibilidade.
https://adrianroselli.com/2014/11/dont-use-tabindex-greater-than-0.html
Hierarquia de cabeçalhos
Quando estamos criando o título principal do nosso site, ou até para identificarmos o assunto de uma seção com algum conteúdo, é muito mais adequado usarmos a hierarquia corretas do , pois o leitor de tela irá identificar aquilo realmente como um título, não pelo seu design ou tamanho de texto, mas sim porque ele foi marcado como tal.
Além disso, a relação de múltiplos de <h1> dentro da sua página dificulta não só o leitor de tela (pois ele irá identificar diversos títulos principais), mas também o ranqueamento SEO do seu site.
Ah! quase ia esquecendo, não é bacana você pular a hierarquia dos <h>. Não vale colocar o <h1> como título principal do seu site e nos subtítulos colocar um <h3> porque o tamanho da letra está mais adequado. Manter a semântica é crucial.
Não esqueça das Labels
Sempre que possível, utilize labels para descrever os elementos do seu formulário. Isso facilita o usuário saber do que se trata cada campo.
É importante atentar que os placeholders não substituem o uso de uma label. Na verdade, quando focalizado, o leitor de tela não identifica essa informação, e sim apenas um espaço vazio.
Além disso, algumas vezes não podemos usar o label visual devido a estética do site. Caso isso aconteça, coloque a descrição no atributo "aria-label", definindo assim uma label identificável pelo leitor de tela.
Agora por último, e não menos importante
Descrição de imagens
Devo reforçar de início que a imagem deve ser usada com sua tag nativa <img>. Além disso, ela possui um atributo chamado "alt" que se refere a um texto alternativo e uma descrição para o leitor de tela ao que a imagem se refere.
Caso não haja nenhuma descrição, o leitor de tela e a descrição da imagem informarão apenas o nome da imagem sem qualquer grau de relevância para o nosso usuário.
Ah! um alt com valor vazio é diferente de não ter alt!
Quando uma imagem é meramente estética, preencha seu alt vazio, pois assim os leitores de tela irão apenas ignorar aquele conteúdo, deixando a leitura mais agradável.
Infelizmente, apesar de muitas vezes não conseguir implementar 100% no meu código, sigo estudando e colocando aos poucos tudo que aprendi em prática, até o momento que será apenas natural. Pois, como bem dizemos, construímos nosso código para os outros, mas devemos lembrar que esses outros muitas vezes, vai um pouco além do nosso colega que também é desenvolvedor.
Gosto de lembrar que o ponto principal para mim sempre foi empatia, e não é fácil, mas deve ser sempre posto em prática, pois poucas coisas fazem um tanto de diferença na vida de alguém <3
Fico à disposição para trocar ideias, e espero que essa leitura tenha auxiliado você que queria apenas tirar uma dúvida ou está querendo aprender mais sobre o tópico.
Sigamos juntos!
Top comments (0)