Kind: Articles

Acessibilidade é um tema em alta, por isso, traduzi as perguntas frequentes sobre acessibilidade.

Ele vai te ajudar em questionamentos básicos e clarear sua trajetória nesse universo de possibilidades.

Esse artigo é uma tradução livre com permissão do autor. O artigo original encontra-se em Answers to common (web) accessibility questions.

Inspirado nas respostas de Chris Coyier às perguntas comuns sobre design (web), que por sua vez foram inspiradas no post anterior de Dan Mall, aqui está uma lista de perguntas comuns sobre acessibilidade.

1. Devo usar links ou botões?

Sim.

Usamos links quando queremos levar o usuário a algum lugar, botões quando queremos que ele realize alguma ação.

Também usamos botões se a ação for enviar um formulário (mesmo se o usuário for redirecionado a algum lugar depois). Tentando evitar nuances neste post, mas aqui estão algumas nuances sobre botões e links.

2. Temos usuários com deficiência?

Sim.

É improvável que você conheça cada um de seus usuários e exatamente como eles usam a web. É ainda mais improvável que o grupo e as pessoas dentro dele permaneçam exatamente da mesma forma para sempre.

3. O que é uma auditoria de conformidade de acessibilidade?

Alguém verificará se o seu site atende a cada um dos 56 Critérios de Sucesso no WCAG (contando a versão 2.2, Níveis A e AA) ou não.

Escrevi um artigo falando sobre os novos critérios e seu uso.

Idealmente, eles também explicam quais são os problemas e como resolvê-los (para que você possa fazer isso). Isso também é chamado de avaliação de conformidade.

4. Quem deve “fazer” acessibilidade em nosso time?

Todos. Copywriters, desenvolvedores, designers e gerentes de produtos têm tarefas de acessibilidade a fazer.

5. Quais são alguns testes rápidos que posso fazer?

Use sua interface com as teclas Tab/ Shift Tab no teclado (verifique as configurações se estiver usando um Mac), você consegue acessar tudo sem um mouse? A ordem faz sentido?

Clique em rótulos para campos de formulário, eles devem focar no campo ao qual pertencem.

Verifique se seus vídeos e áudios (podcasts?) têm legendas/transcrições.

6. A acessibilidade já foi implementada?

Não. É um processo contínuo, mesmo que sua auditoria diga que você atende a todos os Critérios de Sucesso hoje, é comum deixar de atendê-los depois.

Os sites mudam. Você deve monitorar continuamente a acessibilidade, assim como faz com segurança e privacidade.

7. Temos obrigações legais para tornar nossos produtos acessíveis?

Muito provavelmente. Mesmo se você não for um órgão governamental (por exemplo, consulte a Lei de Acessibilidade Européia).

Existem políticas e leis em todo o mundo.

No Brasil, temos a Lei Brasileira de Inclusão.

8. É tudo culpa do meu site?

Não, alguns problemas podem ser resolvidos pelos navegadores, tecnologias assistivas e/ou ferramentas de autoria, como por exemplo, um CMS.

9. WCAG 3.0 será lançado em breve, certo?

Pouco provável. Os objetivos são bons e eu os apoio há muito tempo (ainda apoio), mas levará muitos anos para que isso se torne realidade.

A WCAG 3.0 ainda está em uma fase muito inicial. O algoritmo de cores que está sendo considerado é interessante para tentar atender desde já, pois atende melhor às necessidades do usuário do que o algoritmo atual do WCAG.

10. A “IA” melhorará a acessibilidade?

A aprendizagem de máquina ou Machine Learning, pode ser uma ótima ferramenta para automatizar parte do processo de legendagem em muitos idiomas, e várias outras coisas.

Mas é improvável que as Large Language Models ou LLMs, frequentemente chamadas de “IA”, gerem código acessível.

Para treinar uma LLM assim, seria necessário um conjunto enorme de código muito acessível (o que não existe).

A construção de componentes e a semântica de acessibilidade também exigem intencionalidade, que esses sistemas especificamente não são bons em fazer.

11. O score do Axe ou Page Insights é tudo o que importa para o meu site? Ou o resultado da auditoria WCAG?

Não. Qualquer sistema que pontue seu site e retorne um número (incluindo auditorias WCAG) não descreve completamente sua situação de acessibilidade.

A acessibilidade é, em última análise, sobre pessoas e se elas podem usar seu site. Trata-se de reconhecer e remover barreiras.

As métricas podem ajudar de várias maneiras, mas não são o objetivo final. E o mais facilmente mensurável nem sempre é o mais impactante.

Postagens de acessibilidade mais detalhadas podem ser encontradas em outros lugares no blog do Hidde.

Se você descobriu a WCAG a pouco tempo, vim te contar que irá acontecer grandes mudanças da WCAG 2.2.

Semana passada, a WCAG 2.2 mudou de status e passou para Proposed Recommendation.

O objetivo nesse estágio é garantir que o documento tenha qualidade suficiente para se tornar um Padrão da W3C.

Iremos percorrer por suas novidades e o que irá impactar de forma prática nos testes de acessibilidade. De forma resumido:

Vamos lá?

Comparação com a WCAG 2.1

A WCAG 2.2, vai continuar o bom trabalho da sua versão anterior. Dessa forma, a nova versão concentrou seus esforços em três grandes grupos:

• usuários com dificuldades cognitivas ou de aprendizagem;
• usuários com baixa visão;
• usuários com deficiências em dispositivos mobile.

Curiosidades

A nova versão é compatível com a anterior, ou seja, um site que está em compliance com a WCAG 2.2 estaria também com a WCAG 2.1.

Um ponto interessante, o critério 4.1.1 Parsing foi descontinuado na WCAG 2.2.

Bem como, o critério 2.4.7 – Foco visível se tornou uma técnica obrigatória de implementação.

WCAG 2.2 e seus novos critérios

A WCAG 2.2 incluiu 9 novos critérios de sucesso. Eles são:

• 2.4.11 Foco não obscurecido (mínimo) (Nível AA)
• 2.4.12 Foco não obscurecido (aprimorado) (Nível AAA)
• 2.4.13 Aparência do Foco (Nível AAA)
• 2.5.7 Movimentos de Arrasto (Nível AA)
• 2.5.8 Tamanho do Alvo (Mínimo) (Nível AA)
• 3.2.6 Ajuda consistente (Nível A)
• 3.3.7 Entrada Redundante (Nível A)
• 3.3.8 Autenticação Acessível (Nível AA)
• 3.3.9 Autenticação Acessível (aprimorado) (Nível AAA)

Vamos explicar cada critério de sucesso e como atendê-lo.

2.4.11 Foco não obscurecido (mínimo)

O critério 2.4.11 diz que o elemento que recebe foco não seja obscurecido pelo desenvolvedor. Embora existam algumas exceções como do sistema operacional e navegadores.

O foco será aplicado somente nos conteúdos que estão de fato focados. no momento.

Como atender 2.4.11

Para atender esse critério se faz necessário que o foco esteja visível e perceptível ao usuário, dessa forma, ele conseguirá interagir com os componentes.

O público mais beneficiado seria pessoas que utilizam o teclado, em especial, usuários com algum tipo de deficiência cognitiva ou de memória. Garantindo assim, que seja fácil de identificar os elementos focados.

2.4.12 Foco não obscurecido (aprimorado)

O critério 2.4.12 é o mesmo que o 2.4.11, exceto que é menos permissivo. O critério falha se qualquer parte do elemento focado esteja obscurecido.

2.4.13 Aparência do Foco

O critério 2.4.13 exige que o “indicador de foco” seja visualmente claro e conciso.

Possui relação com os critérios: 2.4.7 – Foco visível e 1.4.11 – Contraste não textual. Entretanto, possui algumas diferenças:

• Critério 2.4.7: valida a existência de um indicador de foco;
• Critério 1.4.11: define o nível mínimo de visibilidade.

Como atender 2.4.13

De maneira prática, uma vez que, podemos pensar em soluções como, usar contornos sólidos para a indicação de foco.

Entretanto, existem outras possibilidade para atendê-lo.

Recomendo verificar as técnicas de sucesso para cumprir esse critério. Um exemplo seria a imagem abaixo:

2.5.7 Movimentos de arrastar

O critério 2.5.7 lida com interfaces que possibilitam arrastar os componentes. Semelhantemente, podemos citar alguns exemplos:

• um mapa permite que os usuários arrastem sua visualização;
• um board de Kanban que permite o usuário movimentar os cards.

Interfaces que possuem a funcionalidade de movimentos de arrastar, tem quatro ações distintas:

• toque ou clique para estabelecer um ponto de partida e, em seguida,
• pressionar e manter esse contato enquanto…
• realizar o reposicionamento do ponteiro;
• liberar o ponteiro no ponto final.

Não cumprir esse critério, prejudica pessoas com mobilidade reduzida, ou deficiências cognitivas. Contudo o ideal é fornecer outros meios de entrada para o usuário interagir com a interface.

Como atender 2.5.7

Para atender esse critério, se faz necessário ter outros meios de entrada para o usuário.

Um componente, por exemplo, color picker se enquadra nesse critério. Ele é acionado pelo movimento de arrasto.

Mas possui campos de texto para a entrada numérica de valores de cor permitem a definição de uma cor sem a necessidade de movimentos de arrastamento.

2.5.8 Tamanho do Alvo (mínimo)

A princípio o critério 2.5.8 tem como premissa garantir que os usuários possam ativar elementos sem clicar acidentalmente em outro elemento próximo.

Entretanto, existem algumas exceções:

• Espaçamento: O deslocamento do alvo é de pelo menos 24×24 pixels para cada alvo adjacente;
• Equivalente: A função pode ser alcançada através de um controle diferente na mesma página que atenda a esse critério.
• Inline: O alvo está em uma frase ou bloco de texto;
• Controle do agente do usuário: O tamanho do destino é determinado pelo agente do usuário;
• Essencial: Uma apresentação particular do alvo é essencial.

Como atender 2.5.8

A princípio, podemos usar técnicas básicas para cumprir esse critério. O recomendável é utilizar um espaçamento entre os elementos seja 24×24 pixels.

Não necessariamente o elemento deve ter 24×24 pixels, mas a soma do alvo tenha esse tamanho.

Curiosidade: Ao cumprir o critério 2.5.5, automaticamente o 2.5.8 é satisfeito.

3.2.6 Ajuda consistente

O critério 3.2.6, exige que, os usuários consigam ajuda para concluir uma tarefa em um website.

O acesso aos mecanismos de ajuda pode ser diretamente pela página onde o usuário se encontra, ou através de um link para uma outra página com as informações de ajuda.

Dessa forma, o usuário tem opções para encontrar possíveis soluções.

Como atender 3.2.6

O website deve ter um modelo de design consistente, com hierarquia das informações de modo claro.

Se você for oferecer esse tipo de recurso, tenha em mente, de colocá-lo no mesmo local para manter conformidade.

3.3.7 Entrada Redundante

O critério 3.3.7 exige que informações previamente inseridas ou fornecidas pelo usuário sejam preenchidas de maneira automática, ou estejam disponíveis para que o próprio usuário as selecione, se for necessário.

Como atender 3.3.7

É extremamente simples implementar a lógica de sessão para pré-preencher campos usando informações que o usuário já inseriu.

Dessa forma, conseguimos manter a entrada redundante das informações.

3.3.8 Autenticação Acessível

O critério 3.3.8 está preocupado com testes de função cognitiva que são usados para autenticar usuários, como por exemplo, CAPTCHA onde devemos digitar uma série de caracteres, ou identificar um tipo específico de objeto.

Dessa forma, usuários com deficiência cognitiva ou problemas de memória, dislexia, discalculia serão extremamente beneficiadas com ele.

Como atender 3.3.8

Primeiramente atender esse critério é garantir que todas as formas de entrada de autenticação (como campos de nome de usuário e senha) suportem a cópia de seus valores.

Contudo, é uma boa ideia incluir um atributo em todos os campos que pedem as próprias informações de um usuário (conforme descrito no critério 1.3.5, embora isso não seja estritamente exigido pelo 3.3.8.

3.3.9 Autenticação Acessível (aprimorada)

Esse critério é idêntico ao 3.3.8, exceto que não possui exceções para testes de reconhecimento de objetos ou conteúdo pessoal.

A acessibilidade web é um assunto cada vez mais importante para as pessoas interessadas em tornar a internet mais inclusiva. É essencial compreender como criar conteúdo acessível para que todos possam contar com a mesma experiência de navegação.

Neste artigo, vamos discutir sobre o que é acessibilidade na web e como você pode tornar seu conteúdo disponível para todos.

Vamos começar?

O propósito da web

Desde sua fundação, a web tem como propósito ser universal e acessível para todos. Tim Berns-Lee possuí uma frase que exemplifica isso:

O poder da Web está em sua universalidade.
O acesso por todos, independentemente da deficiência, é um aspecto essencial.

Tim Berns-Lee, fundador da web.

O fato curioso é que as especificações e princípios adotados pela W3C, eram e são extremamente passíveis de serem usados

Um deles é o princípio da interoperabilidade, que nada mais é do que sua aplicação conseguir funcionar para todas as pessoas independente do seu hardware, software, idioma, localização ou capacidade.

Quando isso acontece conseguimos incluir pessoas que foram excluídas ao longo de sua vida.

Dessa forma, as pessoas com deficiência são beneficiadas com o acesso, promovendo inclusão digital e autonomia para realizarem tomadas de decisões.

Mas para isso ocorrer necessitamos da acessibilidade, ela é essencial para desenvolvedores e organizações que desejam criar sites e ferramentas da web de alta qualidade e não excluir as pessoas de usar seus produtos e serviços.

Afinal, o que é acessibilidade na web?

Acessibilidade na web significa que nossos sites e aplicativos estejam preparados para serem acessados por qualquer pessoal, independente de sua necessidade específica.

Esses usuários devem poder perceber, compreender, navegar e interagir com o conteúdo sem restrição.

Ela abrange todas as deficiências que afetam o acesso, incluíndo:

• auditivo;
• cognitivo;
• neurológico;
• físico;
• discurso;
• visual.

Acessibilidade então é somente para pessoas com deficiência?

Esse é um mito extremamente comum quando somos leigos no assunto. Em uma explicação bem resumida é: NÃO.

Eu escrevi um artigo sobre 5 mitos de acessibilidade: conceitos incorretos e como corrigí-los, que reforça essa ideia que acessibilidade é para todos.

A acessibilidade traz muitos benefícios para pessoas que não possuem alguma deficiência também, por exemplo:

• usuários de smartphones, smartwatch, outros dispositivos inteligentes como assistentes virtuais;
• pessoas idosas que necessitam de uma nova forma de aprendizado devido a idade;
• pessoas com deficiência temporárias, por exemplo, alguém que quebrou o braço;
• pessoas que necessitam ver um vídeo e não conseguem habilitar o aúdio;
• pessoas com “limitações situacionais”, como enxergar o conteúdo da tela do smartphone contra a luz solar;
• pessoas que utilizam uma internet com conexão lenta.

Técnicas para deixar nossos produtos e serviços mais acessíveis

Diversos aspectos da acessibilidade são extremamente simples de serem implementados, outras são mais complexas.

Por isso a acessibilidade deve ser pensando no início do projeto para evitar retrabalho.

Descreve suas imagens

Imagens são um dos elementos mais utilizados para transmitir informação na web. Dessa forma, devemos permitir que pessoas com deficiência visual possam compreender a informação da mesma maneira que nós.

Para deixarmos as imagens acessíveis devemos utilizar o atributo alt nas imagens. Ele permite que a imagem forneça um texto alternativo equivalente a sua representação visual.

Assim, os não-visuais conseguem compreender o conteúdo da mesma forma.

Você pode conferir o Guia Definitivo de texto alternativo que traduzi, nele contém dicas e informações valiosas sobre descrição de imagens.

Navegação do conteúdo

Quando projetamos conteúdo para web, devemos pensar que as pessoas tem diversos tipos de entrada, como, por exemplo:

• navegação através da fala;
• navegação através do mouse;
• navegação através do teclado;
• navegação com leitores de telas.
  

Todos esses tipos de navegação conseguimos contemplar quando projetamos pensando em várias entradas.

O que devemos ter em mente: todos os recursos disponíveis via teclado devem estar disponíveis para o teclado.

Evite o baixo contraste

Contraste é o campeão quando se trata de problemas de acessibilidade. Para garantir um bom contraste podemos utilizar ferramentas como o Color Contrast Analyzer.

Esssa ferramenta analisa o contraste e traz o resultado se possuí um baixo contraste ou não.

Pessoas que possuem daltonismo e baixa visão são extremamente prejudicadas quando não cumprimos isso.

Nesse sentido, gravei um vídeo usando o Accesible Colors. Ele é uma alternativa para o Color Contrast Analyzer.

Defina rótulos para os formulários

Um leitor de telas necessita que os inputs de um forrmulário estejam atrelados a um rótulo.

Esse rótulo deve representar o propósito do input.

Para resolver esse problema é extremamente simples, confira o trecho de código abaixo:

<label for="firstName">First Name</label>
<input type="text" name="firstName" id="firstName" />

Com o uso do atributo for, criamos um vínculo entre a label e o input. Dessa forma, quando o leitor de telas navegar pelo campo irá identificar corretamente qual é o seu objetivo de preenchimento.

Pode parecer extremamente trivial, entretanto, é bem comum vermos formulários sem esse atributo.

Minha dica é adota hoje mesmo o uso dos atributos corretos para uma melhor navegação nos seus formulários.

Defina o idioma da sua página

Talvez esse seja o defeito mais ignorado de acessibilidade. O atributo lang, é um aliado extremamente poderoso, contudo poucas pessoas utilizam ele da maneira correta.

Já escrevi sobre o uso correto do atributo lang. Basicamente, precisamos definir o idioma padrão do documento, para que, os leitores de tela e outras tecnologias assistivas possam ler da maneira correta.

Conclusão

Acessibilidade é um direto de todas pessoas para promover autonomia e facilidade no assim. Nesse sentido, devemos trabalhar para que os ambientes digitais sejam cada vez mais democráticos e inclusivos.

Desenvolver um produto ou serviço sem pensar em acessibilidade e dar um tiro no pé.

Referências

Algumas informações neste artigo são do documento Web Accessibility Initiative (WAI): Introduction to Web Accessibility. Shawn Lawton Henry. Copyright © 2010 W3C® (MIT, ERCIM, Keio). Status: Atualizado em 31 Março de 2022. https://www.w3.org/WAI/fundamentals/accessibility-intro/

Ao longo da minha carreira já ouvi muita bobagem sobre acessibilidade.
Hoje vou mostrar os 5 mitos sobre acessibilidade.

Vamos lá…

1. Acessibilidade é somente para deficiente

O objetivo da acessibilidade é garantir que o conteúdo da web seja acessível por todos.
Um grupo de pessoas são mais beneficiadas, como por exemplo:

• alguém com mãos ocupadas;
• canhotos (como eu);
• idosos;
• crianças;
• pessoas com baixo letramento.

Ou seja, todos.

Entretanto, Tim Berns-Lee certa vez comentou sobre o tema:

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

Quando contemplamos acessibilidade, pensamos em todos.

2. Ninguém liga para isso

Não quer dizer que você ou sua empresa não se importa que todos seguem o mesmo fluxo.

Segundo o censo do IBGE de 2010, 45 milhões brasileiros necessitam de acessibilidade diariamente, para interagir com seus produtos e serviços na web.

Além disso, é constatado por uma pesquisa que menos de 1% dos sites brasileiroso são acessíveis.

A pandemia, aumentou drasticamente o pensamento de produtos e serviços acessíveis.

3. Não é meu público alvo

A web é multidisciplinar e extremamente diversa, pensar em um público específico é limitar o poder que emana dela.

Pense de forma universal, uma das formas de alcançar isso é utilizar o Design Universal para alcançar esse objetivo.

Não devemos setorizar as pessoas, muito menos pela sua deficiência.

4. Vou criar um site específico para acessibilidade

Lembro como se fosse hoje quando ouvi isso em um meetup. Algo que deve ficar claro: acessibilidade não é vilã dos padrões web.

Soluções como: Flexbox, CSS Grid e propriedades CSS3 contribuem para um site mais acessível.

Além de não fazer sentido, teríamos um custo a mais para desenvolver e segregaríamos as pessoas com deficiência.

5. Acessibilidade é perda de tempo

Ela em si não é perda de tempo, pois iria beneficiar possíveis clientes e novos usuários para nossas aplicações.

Também, iríamos alcançar diversas pessoas. O que pode ocorrer e ter um trabalho a mais devido um mau planejamento.

Outro ponto importante, cumprimos legislações nacionais e diretrizes internacionais.

Se você é desenvolvedor web, ter conhecimento sobre o Web Accessibility Initiative (WAI) é essencial. Neste artigo, vamos explorar sobre a iniciativa e os recursos que ela disponibiliza para tornar a web um local mais acesssível e inclusivo para todas as pessoas.

O que é o Web Accessibility Initiative?

O Web Accessibility Initiative (WAI) é uma iniciativa conjunta entre o W3C e diversas empresas e grupos de usuários que trabalham com foco em acessibilidade digital. O objetivo do WAI é a criação de recursos e recomendações para ajudar desenvolvedores web a criarem conteúdos e websites que contribuam para melhorar acessibilidade digital.

Em outras palavras, é o local ideal para iniciarmos nossa jornada quando o assunto é acessibilidade na web.

Apesar disso, poucos profissionais conhecem o WAI e todos os recursos que ele pode oferecer. Portanto, conhecer a iniciativa é um grande diferencial para nossa carreira como desenvolvedor.

Quais recursos podemos encontrar?

O site é repleto de recursos que irão te auxiliar sobre acesssibilidade, contando com as seguintes categorias:

• Fundamentos da acessibilidade;
• Planejamento e políticas de acessibilidade;
• Design e Desenvolvimento;
• Testes e avaliação;
• Guias de ensino;
• Padrões e diretrizes.

Fundamentos de acessibilidade

Essa sessão é um guia introdutório sobre acessibilidade, nela podemos encontrar uma breve introdução, os objetivos da acessibilidade, os princípios e recomendações de cursos.

Em outras palavras, esse é o lugar para dar seus primeiros passos no assunto.

Planejamento e políticas de acessibilidade

O planjemanto e as políticas são recursos para a visão empresarial. Se você quer adequar sua empresa em acessibilidade aqui é um excelente ponto de partida.

Conta com uma visão ampla de como implementar e os passos que podem ser tomadas para isso. \

Design e Desenvolvimento

Às vezes, é bem difícil encontrar um conteúdo de qualidade sobre acessibilidade. Nessa sessão temos excelente recursos que irão ajudar a desenvolver soluções acessíveis.

Em contrapartida, essa sessão não se destina somente para programadores e designers. Existem recursos para redatores e copywriters também.

Além disso, conta com diversos tutoriais para melhorar a acessibilidade das páginas, como:

• estrutura de uma página;
• construção de menu;
• imagens acessíveis;
• tabelas acessíveis;
• formulários acessíveis;
• carousels acessíveis.

Testes e avaliação

Uma das etapas mais importantes na construção de um software e sua testabilidade. Essa sessão concentra seus esforços em oferecer ferramentas para essa tarefa.

Em suma, você encontrará diversos recursos desde um checklist básica a uma validação mais avançada.

Guias de ensino

A princípio, essa parte é dedicada para pessoas que querem ser porta vozes da causa da acessibilidade. Nela contém referências e guias para evangelizar as pessoas e empresas em relação a acessibilidade.

Acredito que, é um excelente ponto de partida para pessoas que querem produzir conteúdo.

Padrões e diretrizes

Na estrutura do WAI, penso que, essa é a parte mais importante de todo o conteúdo. Nela temos as diretrizes e normas de acessibilidade para tornar o conteúdo acessível.

Dessa forma, temos a documentação oficial e demais recursos para auxiliar nossa jornada.

Recursos extra

Além de todos esses recursos, a iniciativa conta com outras frentes bem interessantes, como, por exemplo:

• Accessibility Guideline Working Group;
• Accessible Platform Architectures (APA) Working Group
• Accessible Rich Internet Applications (ARIA) Working Group;
• Education and Outreach Working Group (EOWG);
• WAI Interest Group (WAI IG)

Conclusão

O Web Accessibility Initiative (WAI) é uma fonte de recursos voltados para acessibilidade, ativo a mais de 20 anos que auxilia a melhorar a acessibilidade digital em todo o mundo.

Se você é desenvolvedor web, então você deve considerar aprender as ferramentas e recursos do WAI para ajudar a tornar o seu conteúdo mais acessível para todos.

Acesse o site da Web Accessibility Initiative e descubra mais sobre o que eles fazem para ajudar a melhorar a acessibilidade digital.

Referências

• https://pt.wikipedia.org/wiki/Tim_Berners-Lee
• The history of the Web – W3C Wiki
• About W3C WAI | Web Accessibility Initiative (WAI) | W3C

Talvez você já tenha visto pessoas utilizando o termo a11y ou até mesmo a hashtag #a11y e não compreendeu a correlação dele com acessibilidade. Este termo refere-se a palavra inglesa accessibility.

Os dois caracteres do meio são o número um, não ” L” s minúsculos . Diga como “A-um-um-Y” ou “A-onze-Y”. Pode ser pronunciado também como, ally ou aliado em português.

Qual o sentido e significado de A11y?

O termo, representa a ideia de ser aliado das pessoas com deficiência, afim de, reivindicar, promover e celebrar o direito ao acesso a informação.

Quando utilizamos, dizemos que somos aliados de uma causa tão nobre e em contrapartida, referenciando a acessibilidade digital em si.

Existem outros termos que utilizam a mesma lógica, por exemplo:

• A internacionalização é representado pela sigla i18n;
• A localização é representada pela sigla i10n;
• World Wide Web, pode ser representado por W3

Voce conhecia esse termo?

Comente abaixo e se esse artigo te ajudou considere me apoiar.

Importante

Este artigo foi originalmente escrito por Karina Chow e traduzido e adaptado por mim. Houve a autorização da autora para realizar a tradução.

No mundo atual da computação ubíqua e no desejo de todo o setor de melhorar a diversidade e inclusão de empresas e produtos, não há mais uma desculpa para não investir em acessibilidade na web. Dito isso, começar a acessibilidade na web pode ser uma tarefa difícil. É difícil saber por onde começar e o que você pode fazer agora para melhorar seu produto!

Quando eu estava começando, estava muito confusa e sentia que estava constantemente pesquisando definições no Google. Felizmente para mim, eu tinha uma colega que era muito qualificado e respondeu implacavelmente a muitas das minhas perguntas. Agora, se você me permitir, gostaria de ser seu colega e apresentar uma introdução abrangente à acessibilidade na web.

Se você trabalha com produtos e gostaria de defender a acessibilidade na web, mas não sabe por onde começar, este é o guia para você!

Se você – ou a liderança da sua empresa – ainda precisa ser convencido de por que vale a pena gastar tempo ou dinheiro em acessibilidade, recomendo a leitura do guia sobre Como convencer a liderança da empresa a se preocupar com a acessibilidade.

O que é acessibilidade web?

Ser acessível significa que sites, ferramentas e tecnologias são projetados e desenvolvidos para que pessoas com deficiência possam usá-los. Dizemos que deve ser P.O.U.R .: Perceptível, Operável, Compreensível e Robusto. Voltaremos ao que tudo isso significa mais profundamente em um momento!

O que é a11y?

Existem onze letras entre o A e Y na palavra accessibility, então as pessoas começaram a abreviá-la como a11y. Tem a vantagem adicional de se parecer com a palavra aliado, por isso as pessoas às vezes a usam como tal. Na maioria das vezes, ouço as pessoas dizerem em voz alta como “a-eleven-y”, mas nesse ponto você também pode dizer “acessibilidade”!

Fonte: The A11y Project

Quem define o que é acessível ou não?

As Diretrizes de Acessibilidade de Conteúdo da Web (WCAG) são o norte quando se trata em medir quão acessível o seu produto digital é. Elas foram criadas pelo  World Wide Web Consortium (W3C), o mesmo grupo que define os padrões web para interatividade, internacionalização, segurança, computação mobile e muito mais. Estes são os padrões internacionais que todos os nossos navegadores seguem.

No contexto americano, se você receber uma ação judicial da ADA, muitas vezes será citada que seu site não está em conformidade com a WCAG como evidência objetiva de sua falta de acessibilidade.

No Brasil, temos a Lei Brasileira de Inclusão, ou LBI, que regulamenta as questões que envolvem acessibilidade no contexto digital.

Como as pessoas podem tentar interagir com meu site?

Assim como a conformidade com HIPAA é um padrão em constante mudança conforme o setor de saúde e a Internet se expandem, a conformidade com WCAG também está sempre evoluindo e não está confinada a uma pequena lista de TODOs do tipo definir e esquecer. Uma equipe não pode “resolver” a acessibilidade em uma empresa; em vez disso, eles devem se comprometer a lidar com isso continuamente.

O padrão WCAG mais recente (no momento da redação deste artigo em 2021) é WCAG 2.1. A WCAG é medida com três níveis de conformidade, de A (mais baixo), AA, a AAA (mais alto). Para medir a acessibilidade do seu site, você mede o quão compatível ele é com qualquer um desses níveis WCAG.

“Conformidade WCAG 2.1 AA” significa “Precisamos aderir ao padrão WCAG 2.1, com conformidade duplo A”

Por exemplo, para mídia baseada em tempo, aqui estão alguns exemplos das diferenças entre os níveis de conformidade:

• A – “Conformidade mínima” – Legendas para vídeo/áudio pré-gravado, alternativas fornecidas para vídeo/áudio pré-gravado (por exemplo, transcrições);
• AA – “Conformidade aceitável” – Tudo em A legendas para vídeo/áudio ao vivo, narrações adicionais fornecidas durante o vídeo pré-gravado;
• AAA – “Optimal Compliance” – Tudo em AA e interpretação em linguagem de sinais para vídeo, narrações mais detalhadas fornecidas durante e em pausas para vídeo pré-gravado, transcrições ao vivo
  Ao estabelecer metas de acessibilidade, pode ser aconselhável definir o nível de conformidade que você gostaria de atender, para que todos que trabalham no projeto possam trabalhar para a mesma meta.

Se você não sabe qual nível de conformidade seguir, a conformidade WCAG 2.1 AA é considerada aceitável e cobrirá a grande maioria dos casos de uso.

Quais são os diferentes tipos de deficiência?

Ao projetar seu produto para a web, você provavelmente está sempre imaginando uma pessoa com um teclado e um mouse. No entanto, diferentes tipos de deficiência proíbem as pessoas de interagir com seu produto dessa maneira tradicional.

Com quais ferramentas as pessoas podem acessar a internet?

As deficiências mais comumente consideradas são as deficiências visuais, mas existem muitas outras categorias, todas as quais você deve considerar ao tornar seu produto acessível:

• Visual – cegueira, daltonismo, baixa visão, glaucoma;
• Audição – surdez, deficiência auditiva;
• Motora – Controle de motor fino limitado;
• Cognitiva – Focalização difícil, dificuldades de aprendizagem;
• Convulsões.

Como devo considerá-los ao testar meu produto digital?

Diferentes tipos de deficiências ditam como você pode acessar e interagir com os sites. Uma lista com algumas alternativas populares:

• Teclado
  Algumas pessoas não utilizam o mouse somente o teclado. Isso é comum entre pessoas com deficiências motoras que não conseguem operar os movimentos finos que um mouse exige.
• Leitores de tela
  Tecnologia assistiva que lê o que está na tela, mais comumente usada por pessoas com cegueira ou baixa visão. Normalmente operado usando apenas um teclado.
• Zoom do Browser (idealmente, suporte até 200%)
  Pessoas com deficiência visual podem usar o recurso de zoom em seus navegadores para compreender melhor o texto e ver as imagens.
• Estilos customizados
  Pessoas com baixa visão ou daltonismo podem ter suas próprias folhas de estilo personalizadas para ajustar estilos como tamanho e cor da fonte

Como aprendo a usar um leitor de tela?

Muitas pessoas veem “acessibilidade” e imediatamente consideram isso “uso do leitor de tela”. O fato é que você não precisa aprender a usar um leitor de tela para tornar seu produto acessível. As diretrizes WCAG são detalhadas o suficiente para que você possa simplesmente segui-las e usar a navegação do teclado para testar a maioria das coisas. E, como aprendemos acima, há muitas maneiras de um usuário usar seu site, além de um leitor de tela.

Dito isso, pessoalmente acho útil aprender a usar um leitor de tela porque ele pode ajudar a desenvolver empatia em você pelo que os usuários que os usam passam e pode ajudar a identificar fluxos de produtos insatisfatórios. As diretrizes podem ensiná-lo a marcar seu HTML corretamente e dar bons conselhos sobre como projetar com acessibilidade em mente, mas nada ilustra verdadeiramente como seu produto pode ser confuso do que ouvir seu conteúdo lido em voz alta em uma ordem sem sentido. Para esse propósito, eu gosto de recomendar que as pessoas pelo menos tentem aprender o básico.

Existem muitas ferramentas interessantes online para ensinar a proficiência básica do leitor de tela. Eu recomendaria este guia Codecademy sobre como inicializar um leitor de tela pela primeira vez. Dependendo de qual leitor de tela você usa, também há guias para cada um individualmente. O VoiceOver do Mac OSX tem muita documentação e também há este glossário de comandos que é útil. O JAWS é muito popular para Windows e também tem uma boa lista de comandos.

Depois de aprender um pouco, você pode praticar suas coisas neste divertido guia prático.

Os sites devem ser P.O.U.R

Vamos circular todo o caminho de volta à nossa declaração inicial. De acordo com as WCAG, existem 4 Princípios da Acessibilidade que todo produto deveria aderir a:

1. Perceptível — as informações precisam estar disponíveis para pelo menos um sentido (visão, audição, tato);
2. Operável — um usuário deve ser capaz de realizar todas as ações da interface (ou seja, com um teclado);
3. Compreensível — um usuário deve entender o idioma em uma página e como operá-lo;
4. Robusto — diferentes agentes de usuário, incluindo tecnologias assistivas, o conteúdo deve ser capaz de acessar todo o conteúdo.

O principal objetivo dos entusiastas de acessibilidade é atingir todos os quatro itens para todos os tipos de deficiência e tipos de dispositivos de entrada. Conforme mencionado anteriormente, existem muitos tipos de deficiência e mais dispositivos de entrada estão sendo inventados o tempo todo, então é uma missão para toda a vida, em vez de um objetivo único.

Espero que você se sinta um pouco menos assustado com o mundo da acessibilidade na web. Gostaria de agradecer a Jenna Lee, aquela colega que me ensinou praticamente tudo o que sei.

Fique atento para artigos futuros sobre como incorporar o trabalho de acessibilidade em seus ciclos de vida de produto, bem como instruções mais acionáveis sobre o que fazer em suas bases de código. Desejo-lhe boa sorte e obrigado pelo seu interesse em ser um defensor da acessibilidade!

Recursos adicionais

Gostaria de aprender ainda mais? Aqui estão alguns ótimos recursos:

• Google’s A11ycasts, uma série de vídeos ensinando o básico de acessibilidade pelo time de desenvolvimento da Google;
• WCAG 2.1 Guidelines, versão atual das diretrizes de acessibilidade;
• WebAIM, muita informação de acessibilidade e até mesmo treinamentos de certificação;
• Awesome A11y, uma lista com recursos sobre acessibilidade;
• ANDI, uma ferramenta de teste de acessibilidade automatizada para executar em suas páginas da web;
• Lighthouse, uma ferramenta automatizada para SEO, acessibilidade e desempenho;
• The A11y Project, educação sobre como fazer designs acessíveis;
• Mozilla’s a11y documentation, documentação sobre a11y fácil de compreender.

Como QA, somos responsáveis por garantir a qualidade do software.

Uma das etapas mais importantes é a análise dos critérios de aceite.

Essa etapa consiste em analisar, validar e verificar os artefatos de cada estória.

Um dos aliados aos critérios de aceite é a acessibilidade. Neste artigo, vamos explorar a sua relação.

Recapitulando, o que é acessibilidade na web?

Antes de mais nada, devemos recapitular o que é acessibilidade na web.

Acessibilidade na web é a capacidade de pessoas com deficiência poderem consumir produtos e serviços na internet de forma autônoma, promovendo assim, liberdade de escolha e qualidade de vida.

Foi dada a largada de mais uma sprint, como um bom analista de qualidade você inicia os preparativos para manter seu trabalho de forma organizada, clara e documentada.

Assim, fazemos uma análise dos requisitos de cadas estória que será trabalhada durante a sprint. Percebemos que o produto não está conformidade as diretrizes de acessibilidade e, por consequencia, quebra um dos pilares da qualidade descritos na ISO 25010.

O que fazer nessa situação?

Conceito de Critério de Aceite

Os critérios de aceitação são as condições que um produto de software deve atender para ser aceito por um usuário, cliente ou outro sistema. Eles são exclusivos para cada história de usuário e definem o comportamento do recurso da perspectiva do usuário final. Critérios de aceitação bem escritos ajudam a evitar resultados inesperados no final de um estágio de desenvolvimento e garantem que todas as partes interessadas e usuários fiquem satisfeitos com o que obtêm[1].

Podemos utilizar os critérios de aceite das mais variadas formas, como, por exemplo:

• Orientado a cenários (Gherkin);
• Checklist;
• Formatos personalizados.

Garantindo a acessibilidade nos critérios

Num ambiente ágil, ocorre a famosa reunião dos Three Amigos, onde PO, QA e líder técnico fazem o refinamento de funcionalidades que são candidatas para uma sprint.

O objetivo dessa reunião e ter uma visão do mesmo problema em aspectos diferentes. O negócio exige determinados aspectos, enquanto o líder técnico apresenta as possibilidades de desenvolvimento. Em contrapartida, nós analistas de qualidade visamos criticar o produto e levantar cenários de testes funcionais e não funcionais.

Neste momento, podemos elencar critérios de acessibilidade. Para exercitarmos, iremos pensar num componente de interface bem comum no cotidiano: uma janela modal.

Escrevendo a estória de usuário

Como descrição da atividade o PO levou para o refinamento os seguintes critérios:

Na aplicação da ACME Corportarion, no fluxo de Compras devemos exibir um botão onde o usuário poderá incluir seu endereço de entrega. Ao clicar nesse botão deve ser exibido uma modal para o preenchimento do seu endereço.

A estória de usuário foi definida, de acordo, com a especificação abaixo:

Como usuário gostaria quando selecionar "Add Delivery Address" seja exibido um formulário para preencher meu endereço.

Em um brainstorming, foi levantado o protótipo que tem o objetivo de concluir a jornada de cadastro de endereço.

Exemplo de modal

Pensando de forma analítica, costumo prestar atenção nos detalhes especificamente quando temos palavras mágicas como: alta retenção, jornada de compras. Sabendo da importância disso, comecei imaginar alguns critérios.

Definindo os critérios

Aparentemente é uma tela inocente de fácil implementação, porém, como diz o ditado “o diabo mora nos detalhes”. Ela servirá de um bom exercício para identificarmos critérios de aceite voltados para a acessibilidade especificamente.

Comportamentos

Devemos prever os comportamentos desse componente, por exemplo:

• quais são as teclas que exibem e ocultam a modal?
• quais teclas de atalho deverão ser mapeadas?
• como será a apresentação desse componente na tela?
• existirá algum elemento que receberá o foco quando ela for exibida?

Com esses questionamentos, poderiamos refinar os critérios conforme abaixo.

[ACME-123] Cadastro de Endereço de Entrega

Como usuário gostaria quando selecionar "Add Delivery Address" seja exibido um formulário para preencher meu endereço.

Critérios de Aceite

A modal deve ocupar 100% da tela, permitindo o conteúdo ser mais fácil de ler e ser exibido em telas pequenas;
Deve ser seguido o mapeamento das teclas de acordo com a tabela Suporte ao teclado
Deve ser exibida a modal através do clique no botão "Add Delivery Address";
Deve ser exibida a modal através do teclado no botão "Add Delivery Address":
deve ser aberta com a tecla ENTER;
deve ser aberta com a tecla SPACE.
A navegação deve ser somente na modal;
Não deve focar outros elementos que não estão no contexto da modal;
O foco inicial deve ser no primeiro input do formulário;
A janela modal não precisa de uma descrição extra (aria-describedy);
O botão de "Cancel" fecha a modal e retornar o foco para o botão "Add Delivery Address";
A tecla ESC deve fechar a modal e retornar o foco para o botão "Add Delivery Address";

Suporte do teclado

Conclusão

Dessa forma, conseguimos prevenir possíveis inconsistências relacionadas a acessibilidade, garantindo assim, o cumprimento das diretrizes de acessibilidade.

Note que fizemos um bom apanhando de critérios e fomos, de certa forma, bem minuciosos. A dica é começar a exercitar isso aos poucos.

E você já conseguiu contribuir com algum critério de aceite, pensando em acessibilidade?

Referências

• Altexsoft.com, 2021. Disponível em: https://www.altexsoft.com/blog/business/acceptance-criteria-purposes-formats-and-best-practices. Acesso em: 22 de Abril de 2021.
• W3C, 2021. Disponível em: https://www.w3.org/WAI/ARIA/apg/patterns/dialogmodal/. Acesso em: 23 de Abril de 2021.

Neste post, mergulharemos nos 6 maiores erros de acessibilidade digital que empresas e desenvolvedores cometem com frequência, sem sequer perceber. Através da conscientização e compreensão desses erros, podemos dar os primeiros passos rumo a uma web mais inclusiva, onde pessoas com deficiência ou necessidades específicas possam navegar e interagir de forma independente.

Ao explorar esses erros, examinaremos os desafios que eles representam e destacaremos soluções práticas para corrigi-los. Afinal, o objetivo final é capacitar todos os usuários a aproveitarem plenamente os benefícios do mundo digital, independentemente de suas limitações.

Então, vamos começar essa jornada para tornar a web mais inclusiva para todos.

Sumário

• Texto com baixo contraste
• Imagens sem texto alternativo
• Links vazios
• Labels de formulários ausentes
• Botões vazios
• Documentos HTML sem definição de linguagem
• Conclusão
• Referências

1. Texto com baixo contraste

Diariamente sofro na pele com isso, para quem não me acompanha ou está chegando por agora no blog, eu possuo ceratocone, uma doença na córnea que aumenta o grau exponencialmente. Algumas combinações de cores e informações ficam bastante confusas para mim.

Para amenizar esse problema eu adotei algumas práticas:

• dar zoom em textos com baixo contraste;
• mudo as cores dos textos para uma com maior contraste via Inspetor de elementos do navegador;
• usar tema escuro.

Guia sobre contraste

Para aplicarmos as correções de maneira efetiva, devemos consultar as recomendações da WCAG. Abaixo as regras que se aplicam ao contraste:

• 1.4.3 – Contraste (mínimo) [AA] – WCAG 2.0 (em inglês);
• 1.4.6 – Contraste melhorado [AAA] – WCAG 2.0 (em inglês);
• 1.4.11 – Contraste Não-Textual [AA] – WCAG 2.1 (em inglês);
• 2.3.1 – Três flashes ou abaixo do limite [A] – WCAG 2.0.

Ferramentas para verificação

Atualmente utilizo o Accessible Colors, é uma boa alternativa para realizar esse tipo de teste.

A grande vantagem dele é seu feedback claro e objetivo, como por exemplo:

Resultado de uma avalição das cores: #ccc para textos do tamanho de fonte 16px e background do site #fff.

Após realizar o teste, podemos abrir os bugs. Uma curiosidade a maioria desses erros conseguimos resolver com poucas linhas de CSS.

No Awesome A11y você pode encontrar diversas ferramentas para validar contraste.

2. Imagens sem texto alternativo

Segundo uma pesquisa do Web AIM, em uma amostragem de 1 milhão de páginas iniciais dos sites mais populares do mundo. Foram encontradas 38,426,701 imagens, ou 38.4% por página inicial em média.

Cerca de 31.3% de todas as páginas iniciais (12 por página em média) não possuíam texto alternativo (sem contar o alt="") que é uma forma válida. Mais da metade das imagens sem texto alternativo.

Existe uma discussão ao redor do atributo <strong>alt</strong>, Reinaldo Ferraz escreveu um artigo, onde demonstra os benefícios do atributo. Além de contribuir para a acessibilidade ele também ajuda no SEO das páginas.

De forma prática a correção desse erro é uma das mais banais, basta preencher o atributo alt com a descrição correta da imagem.

Ex:

<img src="/imagens/duck.png" alt="Pato de borracha amarelo olhando fixamente" />

Traduzi um guia super completo de como escrever um texto alternativo.

3. Links vazios

Esse erro é bem comum, entretanto não deveria ser tão encontrado nas páginas web.

Frequentemente encontramos em ícones ou botões de ação sem nenhuma ação, não é mesmo? Para entendermos isso, vamos consultar a definição do propósito do elemento <strong><a></strong>:

O elemento <strong><em><a></em></strong> em HTML (ou elemento âncora), com o atributo href cria-se um hiperligação nas páginas web, arquivos, endereços de e-mails, ligações na mesma página ou endereços na URL. O conteúdo dentro de cada <a> precisa indicar o destino do link.

Usar sem definir o conteúdo textual descumpre a especificação do HTML e a recomendação 2.4.4 – Finalidade do link (em contexto) [A] – WCAG 2.0 (em inglês).

Exemplo prático

Temos um link que inclui um ícone de rede social, mas não possuí um texto para descrever a ação. Dessa forma, os leitores de tela irão ler: “Link”.

<a href="https://twitter.com/obrunopulis">
  <i class="fa fa-twitter"></i>
</a>

Qualquer validador de acessibilidade vai encontrar esse problema, pois o elemento <strong><em><a></em></strong> encontra-se sem nenhum conteúdo textual, descumprindo seu propósito.

Dessa forma, os leitores de tela não conseguem identificar o link em questão.

Uma possível solução, seria adicionar o texto visualmente ao lado dos ícones, pois eles nem sempre são tão claros para os usuários quanto pensamos.

No caso dos ícones sociais, acho que é bastante claro o que são e o padrão é usado com bastante frequência. Nesse caso, você pode adicionar conteúdo visualmente oculto.

Corrigindo

Queremos adicionar texto para ser lido por um leitor de tela e ter certeza de que o conteúdo adicionado via CSS não seja lido.

<a href="https://twitter.com/obrunopulis">
  <span class="fa fa-twitter" aria-hidden="true"></span>
  <span class="sr-only">Perfil de Bruno Pulis no twitter</span>
</a>

Com essa abordagem os validadores de acessibilidade não encontrarão nenhum problema, pois o link contém um texto oculto que informa o seu destino.

Observação importante

Nem sempre ter um conteúdo oculto é uma boa solução. É preciso haver uma compreensão visual de qual é o conteúdo e os links para usuários videntes, bem como para usuários de leitores de tela.

4. Labels de formulários ausentes

Dos 4,2 milhões de formulário identificados na pesquisa do WebAIM, 55% não estavam usando o elemento <strong><label></strong>, <strong><em>aria-label</em></strong> ou <strong><em>aria-labelledby</em></strong>.

Páginas com pelo menos um controle de formulário sem rótulo tiveram em média mais 43 erros detectáveis do que páginas sem nenhum erro de rótulo.

Com efeito, é preocupante o descuido pela escrita do HTML, a grande maioria dos problemas são originados de uma escrita descuidada.

A saber, formulários são um dos componentes mais importantes para web, podemos dizer que depois do elemento <a> esse componente é o mais importante.

Com essas violações também ferem a recomendação 3.3.2 – Rótulos e instruções [A] – WCAG 2.0 – (em inglês).

Uma das coisas que percebo muito com formulários é o uso inadequado do placeholder, a maioria dos designers e desenvolvedores utilizam o atributo placeholder com a função de um <label>.

Exemplo incorreto

<form>
  <input type="email" placeholder="insira o seu melhor e-mail" />
</form>

O atributo placeholder é uma string que fornece uma breve dica ao usuário quanto ao tipo de informação esperado no campo. Deve ser uma palavra ou frase curta que demonstre o tipo de dados esperado, ao invés de uma mensagem explicativa.

Nota: O atributo placeholder não é semanticamente útil como outras maneiras de explicar seu formulário e pode causar problemas técnicos inesperados com seu conteúdo.

Vale lembrar, para rotular um formulário o elemento correto para ser usado é o label

Exemplo correto

<form>
  <label for="email">E-mail</label>
  <input type="email" id="email" placeholder="insira o seu melhor e-mail" />
</form>

5. Botões vazios

Semelhantemente com os links vazios, os botões vazios querem dizer que o elemento não possuí uma informação textual definida. Quando navegamos no botão, um texto descritivo deve ser apresentado ao leitor de tela para indicar qual tipo de função que o botão possuí.

Além disso, essa violação fere duas recomendações da WCAG:

• 1.3.3 – Características sensoriais [A] – WCAG 2.0 (em inglês);
• 2.5.3 – Rótulo no nome acessível [A] – WCAG 2.1 (em inglês)

O exemplo a seguir, demonstra o problema de um botão sem informação textual.

<button type="submit">
  <svg id="search" viewBox="0 0 16 16.9">
    <path d="M16, 15.7L11.3,11C12.4,9.8,13, 8.2,13,6.5C13"></path>
  </svg>
</button>

Qualquer validador de acessibilidade notificará a inconsistência da violação das guidelines citadas acima, Para eles não existe um conteúdo textual definido, uma abordagem para correção seria inserir o elemento <title> no SVG, pois ele garante que SVGs sejam acessíveis. Scott O’Hara escreveu um artigo imagens acessíveis e SVGS (em inglês).

<button type="submit">
  <svg
    id="search"
    role="img"
    aria-describedby="searchIcon"
    viewBox="0 0 16 16.9"
  >
    <title id="searchIcon">Search</title>
    <path d="M16, 15.7L11.3,11C12.4,9.8,13, 8.2,13,6.5C13"></path>
  </svg>
</button>

6. HTML sem idioma definido

A linguagem no documento HTML na maioria das vezes é ignorada ou esquecida. Já fiz diversas avaliações em sites com conteúdos totalmente em português e a definição do idioma em inglês.

Usuários de leitores de tela, utilizam o sintetizador de voz embutido nos softwares para ler o conteúdo. Dessa forma, uma das primeiras coisas que o sintetizador de voz faz é identificar o idioma atribuído a página.

Além disso, é configurado a entonação, ritmo e sotaque da língua definida no documento. Em contrapartida, se não encontrar um idioma ele define o inglês como padrão.

Além dessa confusão, ele descumpre a recomendação 3.1.1 – Idioma da página [A]- WCAG 2.0 (em inglês)

Corrigindo

<!DOCTYPE html>
<html lang="pt-br">
  ...
</html>

Você também pode, explorar mais sobre o atributo lang em outro artigo que escrevi.

Conclusão

Percorremos todos os bugs, entretanto fica nítido que precisamos de conscientização para resolver esses problemas.

Além disso, os desenvolvedores devem aprender de maneira correta os padrões web e HTML semântico. Dessa forma, grande parte desses problemas vão desaparecer.

Em conclusão, reciclar nosso conhecimento é primordial

E para reflexão gostaria de deixar uma frase do Tim Berners-Lee:

O poder da Web está na sua universalidade. O acesso por todas as pessoas, não obstante a sua incapacidade, é um aspecto essencial.

Referências

• Guia WCAG
• Pesquisa do WebAIM
• Accessible Colors
• Empty link example
• Documentação do elemento A
• Documentação do atributo placeholder
• Explorando o atributo alt