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