Categoria: Acessibilidade (Page 1 of 2)

6 maiores erros de acessibilidade digital

A acessibilidade digital é o assunto do momento, a pandemia evidenciou bastante, nesse post eu trato sobre alguns erros que são bem comuns no mundo digital.

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:

Ferramentas para verificação

Após compreendermos as regras relacionadas ao constraste, devemos elencar ferramentas para corrigir o problema.

Atualmente estou usando o Accessible Colors gosto dele pela simplicidade, provavelmente escreverei sobre ele.

Para exemplificar, imagine que você foi contratado para validar o contraste do menu de um site. Você iria inspecionar a cor usada no background do menu e as cores decada item de menu, usando o Acessible Colors, o resultado será semelhante a:

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

Tendo o resultado em mãos, você pode reportar as inconsistências. Essa correções são feitas alterando as CSS, e com poucas linhas de código o problema é sanado.

🔥 Você pode encontrar uma lista delas no Awesome A11y.

Imagens sem texto alternativo

Imagem quebrada

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 possuiam texto alternativo (sem contar o alt="") que é uma forma válida. Mais da metade das imagens sem texto alternativo.

Fundo degradê roxo com um homem negro vestindo um terno cinza e blusa salmão, colocando as mãos na cabeça se sentindo surpreso. Escrito em branco ao centro 'Oh, lord, Jesus. What!?'

Existe uma grande discussão ao redor do atributo alt, 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" />
🔥 Consulte o artigo: Texto alternativo: o guia definitivo

Links vazios

Links vazios, são um dos maiores erros que já encontrei em avaliações de acessibilidade. Frequentemente me deparo com ele, geralmente ocorrem quando precisamos incluir um ícone, em uma página.

Para entendermos isso, vamos consultar a definição do propósito do elemento <a>:

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

Além de descumprir com a especificação do HTML, descumpre também a recomendação 2.4.4 – Finalidade do link (em contexto) [A] – WCAG 2.0 (em inglês).

Exemplo prático

Existem duas soluções que podemos aplicar, quando preciso usar um ícone e somente ele ser exibido, posso usar essa abordagem:

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

Qualquer validador de acessibilidade que se deparar com esse elemento, encontrará uma inconsistência, pois ele informa um elemento <a> sem um conteúdo textual, descumprindo com o propósito de uso dele. Sem nenhum texto isso fica confuso para usuários de leitores de tela.

Nesse exemplo especifíco, um leitor de tela poderia ler o link da da URL ou o conteúdo do pseudo elemento :before que seria f002. f002 não quer dizer pesquisa ou nenhuma outra informação. não é mesmo?

Uma abordagem 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.
🔥 Aprenda a usar o Font Awesome do jeito certo

Labels de formulários ausentes

55% dos 4,2 milhões de formulário identificados na pesquisa do WebAIM, não estavam usando o elemento <label> ou aria-label ou aria-labelledby.
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.

É preocupante a má da escrita do HTML na web, a grande maioria dos sites possíveis erros básicos de marcação.

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>

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:

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>

Documentos HTML sem definição de linguagem

A linguagem do 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 um sintetizador de voz embutido nos softwares para ler o conteúdo. Uma das primeiras coisas que o sintetizador de voz faz ao navegar em uma página é procurar a definição do idioma daquele documento HTML, quando isso acontece ele configurará a entonação, ritmo e sotaque da língua definida no documento. Caso não encontre uma definição ele utiliza o inglês como padrão.

Além dessa confusão linguística, 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>
Para descobrir mais sobre o atributo lang, acesse: explorando o atributo lang.

Conclusão

Bom se fosse chegou até aqui parabéns! Concluímos a maratona dos seis maiores erros de acessibilidade digital. Vimos detalhamente cada erro e quais recomendações eles ferem, também possíveis soluções para cada um.

A conclusão que chego é que existe um défict enorme sobre os padrões web na comunidade de desenvolvedores. A maioria dos problemas de acessibilidade são problemas estruturais e educacionais.

Reciclar nosso conhecimento sobre os fundamentos é sempre importante, pois os frameworks da moda irão passar, mas os velhos amigos HTML, CSS e JavaScript estarão por ai.

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.

O que podemos fazer para mudar essa situação? Deixe sua sugestão do que podemos fazer para construirmos uma web acessível para todas as pessoas.

Referências

Repensando sobre o HTML

Introdução

O HTML é o bloco de construção mais básico da web. É o responsável por definir duas características importantíssimas: significado e a estrutura do conteúdo da web.

Além dessas características primordiais, também contribui para um melhor posicionamento de nossas páginas na web, ocasionando assim, maior visibilidade e lucro.

Outro fator não menos importante, é a promoção do conteúdo para todas as pessoas, visto que, uma vez escrito corretamente consegue atingir todos os públicos, garantindo assim a interoperabilidade do conteúdo, sem se preocupar com plataformas ou devices.

Um breve contexto

O ano é 2020, frameworks de frontend, especialmente de javascript nascem a cada seis segundos com a promessa quase messiânica de resolver nossos problemas.

Basta rodar um comando e voilá, seu projeto está pronto só esperando fazer o que é necessário: codar.

O desenvolvedor satisfeito com a agilidade fica contente e inicia seu trabalho feliz com tudo isso, começa a criar componentes “reutilizáveis”, utiliza JSX, Typescript, Webpack, Sass, Styled Components e mais de milhares de dependências do nosso amado NPM.

Passa-se alguns dias e seu projeto vai para produção, mas será que a escrita da forma mais básica cumpre os princípios básicos de significado e conteúdo?

Bom, essa analogia demonstra a realidade de muitos de nós, pensamos nas melhores arquiteturas, tecnologias e abordagens de DevOps e o pobre e velho HTML, coitado, é deixado de lado.

Frameworks são excelentes ferramentas, mas não são uma bala de prata, devemos ter cuidados e prudência, afinal você não precisa de um canhão para matar uma formiga.

Uma tendência

Atualmente a maioria dos projetos web tem alguma lib ou framework de javascript por trás, por um lado isso é excelente, a web evoluiu e fazer frontend não é a mesma coisa do que 10 anos atrás.

Lembro dos dias áureos de Dreamwever, CSS puro e VanillaJS. Era muito difícil fazer certas coisas, hoje nossa realidade é bem mais simples, temos excelentes libs, como o React e VueJS para construir componentes reutilizáveis.

Essas libs por sua vez possuem frameworks para deixar o desenvolvimento, digamos “vitaminado”, e, ser mais rápida a produção de nossas apps.

O problema é que a maioria desses frameworks possuem erros grotescos de html, ao ponto de renderizar um componente de select, por exemplo, com várias divs aninhadas.

Um exemplo do framework Vuetify com o componente select:

<v-select :items="items" label="Standard"></v-select>

Aparentemente é um componente simples e elegante, mas qual é sua saída no código HTML? Sua saída é parecida com isso:

<div class="v-input theme--light v-text-field v-text-field--is-booted v-select"></div>
  <div class="v-input__control">
    <div role="button" aria-haspopup="listbox" aria-expanded="false" aria-owns="list-1359" class="v-input__slot">
      <div class="v-select__slot">
          <label for="input-1359" class="v-label theme--light" style="left: 0px; right: auto; position: absolute;">Standard</label>
          <div class="v-select__selections">
              <input id="input-1359" readonly="readonly" type="text" aria-readonly="false" autocomplete="off">
          </div>
          <div class="v-input__append-inner">
              <div class="v-input__icon v-input__icon--append">
                <i aria-hidden="true" class="v-icon notranslate mdi mdi-menu-down theme--light"></i>
              </div>
          </div>
          <input type="hidden">
      </div>
        <div class="v-menu"></div>
    </div>
    <div class="v-text-field__details">
        <div class="v-messages theme--light">
            <div class="v-messages__wrapper"></div>
        </div>
    </div>
  </div>
</div>

Já no bom e velho HTML, o componente de select se parece com isso.

<select>
  <option>Selecione uma opção</option>
  <option>1</option>
  <option>2</option>
  <option>3</option>
</select>

Simples, não?

Exemplos assim, estão recheados aos montes pela web. A WebAIM uma empresa que presta treinamentos e consultorias sobre acessibilidade web, realizou no ano de 2019 uma pesquisa onde mapeou 1 milhão de páginas e detectou problemas relacionados a acessibilidade. E pasmem, a maioria dos problemas não era coisas hiper complexas, mas extremamente simples.

Abaixo uma tabela demonstrando os problemas mais recorrentes nas páginas.

Falhas mais comuns de acessibilidade na web. Fonte: [The WebAIM Million](https://webaim.org/projects/million/#intro)
Tipo de falha da WCAG % de home pages em Fevereiro de 2020 % de home pages em Fevereiro de 2019
Baixo contraste 86.3% 85.3%
Imagens sem texto alternativo 66.0% 68.0%
Links vazios 59.9% 58.1%
Faltando label em formulários 53.8% 52.8%
Botões vazios 28.7% 25.0%
Linguagem do documento ausente 28.0% 33.1%

Fica nítido uma coisa, temos um problema gritante com a semântica e estrutura

HTML semântico

Quando falamos sobre semântica, estamos falando sobre o conteúdo ter significado. Assim como um livro ou TCC respeita uma estrutura lógica de hierarquia de informação o HTML também possuí.

Nele podemos marcar corretamente: datas, cabeçalhos, sessões, citações longas e curtas, paragráfos, ênfase e diversos outros recursos.

Um dos grandes problemas na web não é a falta de acessibilidade, mas escrita incorreta de HTML, CSS e Javascript.

O nosso problema é que não conseguimos fazer o básico bem feito e logo queremos usar frameworks para resolver nossos problemas…

Muitos desenvolvedores não conseguem escrever um HTML semântico, mas sabem criar um componente super complexo que um componente nativo do HTML resolveria.

Eu sempre tenho um mantra comigo: Sempre utilize componentes nativos. SEMPRE!, mas existem casos que não é possível, nossa função é informar que não utilizando um componente nativo podemos perder em semântica, acessibilidade, posicionamento e até mesmo grana.

Essa semana a Talita Pagani iniciou uma conversa no twitter sobre o mesmo tema. Você pode ver um trecho logo abaixo.

Esse assunto no Twitter me fez lembrar de outra conversa com o Reinaldo Ferraz em um BrazilJS. Estávamos falando sobre o estado atual da acessibilidade web no Brasil e os avanços que temos feito. Ele disse uma frase que me marcou muito:

> Estamos em um momento que as pessoas precisam reaprender como escrever HTML. Só assim, conseguiremos tornar a web mais inclusiva.

Conclusão

A minha dica é desacelerar e voltar a base, não adianta nada saber os melhores frameworks e técnicas de desenvolvimento frontend, sendo que, o essencial não está bem fundado.

Isso me lembra a Parábola dos dois fundamentos, segue um trecho:

Todo aquele, pois, que escuta estas minhas palavras, e as pratica, assemelhá-lo-ei ao homem prudente, que edificou a sua casa sobre a rocha;
E desceu a chuva, e correram rios, e assopraram ventos, e combateram aquela casa, e não caiu, porque estava edificada sobre a rocha.
E aquele que ouve estas minhas palavras, e não as cumpre, compará-lo-ei ao homem insensato, que edificou a sua casa sobre a areia;
E desceu a chuva, e correram rios, e assopraram ventos, e combateram aquela casa, e caiu, e foi grande a sua queda.
(Mateus 7:24-27)

Uma fundação com estrutura sólida nos dá segurança e confiança, mas uma fundação sem segurança e instável é passível de diversas falhas.

A fundação HTML, CSS, Javascript devem ser sólidas, frameworks vem e vão.
Que tal refletirmos e escrevermos de forma semântica?

Conteúdos relevantes

Separei alguns links para aprender a escrever HTML semântico, espero que os ajude.

* Recomendações de acessibilidade
* HTML5 and CSS fundamentals
* HTML5 Coding Essentials and best pratices
* Referência da MDN sobre HTML

Referências:

* Referência da MDN sobre HTML
* Pesquisa WebAIM
* Vuetify Select

Como um artigo pode impactar as pessoas

Recentemente por incentivo do meu mentor o Júlio de Lima, postei o meu primeiro vídeo sobre acessibilidade no meu canal no Youtube, onde mostro a ferramenta NoCoffee Vision Simulator.

O NoCoffee é uma extensão para o Chrome e Firefox que permite simularmos algumas deficiências visuais, comentei sobre ele neste artigo.

Eu topei desafio e gravei o vídeo sobre o NoCoffee. Postei no Linkedin e muitas pessoas visualizaram e comentaram no vídeo um desses comentários me surpreendeu. Meu colega do TSPI o Thiago Santos deixou o seguinte comentário no meu vídeo.

Cara, eu tenho uma cicatriz na mácula do olho direito e acabei de testar o NoCoffee, baseado no vídeo do Bruno. Agora eu posso exemplificar para os meus amigos exatamente como é isso. Antes da pandemia a minha empresa se reuniu para coletar ideias para agregar valor ao nosso sistema e eu sugeri deixá-lo mais acessível. Com essa ferramenta, que eu já vou começar a usar, isso vai acontecer.

Thiago Santos

Foi uma supresa para mim saber que alguém que estava perto, sofria de algo que muita das vezes colocamos como distante no nosso cotidiano. Nesses casos torna-se primordial a acessibilidade.

Para quem não conhece o que é uma mácula na visão, a experiência de navegação é assim:

Navegação em um site com visão máculada

Desafios

O gif me fez pensar nos desafios que essas pessoas enfrentam, sua experiência infelizmente é comprometida por interfaces não inclusivas.

A acessibilidade te deixa por diversas vezes desconfortável, sim acontece quase sempre. Mas ela chega com um sinal que podemos mudar a realidade de pessoas que são excluídas. Pense nisso, acessibilidade não é entrar em conformidade com leis e diretrizes, mas sim dar acesso a informação independente das limitações do usuário.

Conclusão

O comentário do Thiago foi cedido gentilmente e devidamente autorizado para estar nesse post. Que possamos construir juntos uma web inclusiva a todas as pessoas.

Você conhece o poder do atributo lang?


Nesse post iremos explorar um dos atributos HTML que passam desapercebidos no dia a dia, o atributo lang.

O atributolang ajuda a definir o idioma de um elemento: a língua em que elementos não-editáveis são escritos, ou a língua em que elementos editáveis devem ser escritos pelo usuário[1].

Cenário de exemplo

John é um jornalista cego, que trabalha para uma agência internacional de notícias. Ele faz correspondência dela no Brasil. Um dos maiores passatempos de John é ler resenhas de livros e breves sumários para realizar o seu sonho: montar uma grande biblioteca.

John estava procurando uma resenha sobre o livro Peter Pan, quando encontrou uma página escrita em inglês. Porém, o desenvolvedor, ao criar a página, utilizou a marcação da linguagem em pt-br ou seja, em português.

A experiência de John, foi mais ou menos a seguinte:

Exemplificando

Como vocês podem perceber, o título e os dois primeiros parágrafos soaram totalmente estranhos, parecido com o Joel Santana tentando falar em inglês.

Porém, os dois últimos parágrafos estão totalmente compreensíveis.

O que aconteceu no vídeo é algo bem simples, mas se não prestarmos atenção o conteúdo pode ficar incompreensível. A marcação HTML desse trecho é:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Peter Pan Test Atrribute Lang</title>
</head>
<body>
  <h1 lang="pt-br">Peter Pan summary</h1>
  <p lang="pt-br">Every night Peter visits the Darling family house and listens to Mrs. Darling tell bedtime stories. He sits on the window listening. One evening, they see Peter trying to escape. As he tries to run away, he loses his shadow. He goes back to get his shadow. He wakes up the daughter of the house, Wendy Darling. Wendy helps him attach his shadow to his body again. Wendy tells him she knows a lot of bedtime stories too.</p>
  <p lang="pt-br">Peter invites Wendy to return to Neverland with him. He wants her to be the mother of the Lost Boys. Wendy agrees to the mission and asks for her brothers Michael and John to join them.</p>
  <p lang="en">They have a magical flight as they travel to Neverland and have many adventures along the way. Wendy is nearly killed and the boys build her a house in the trees to recover. After Wendy is okay, she takes the role of the mother.</p>
  <p lang="en">After all their adventures and fun, Wendy decides that her place is at home with their mother. Wendy helps all the Lost Boys return to London. But Peter doesn’t want her to go. Instead he tries to trick her. He tells her that their mother doesn’t want them anymore. However, he understands how sad their mother must be. In the end, he decides to let them go home.</p>
</body>
</html>

O documento HTML acima deve ser observado com cuidado, pois existem dois pontos importantes a serem observados.

  • Por definição o documento HTML, deve conter uma linguagem definida para o escopo global. Quando isso não acontece, o browser seleciona automaticamente o idioma do browser;
  • Tags HTML, podem receber o atributo lang para serem lidos de forma correta.

Já pensou ter que consumir conteúdo de páginas que possuem esse tipo de problema? O quão frustante isso pode ser? Essa experiência basicamente acontece todos os dias quando pessoas que possuem deficiência visual, auditiva e cognitiva tentam acessar páginas com idiomas com a definição de linguagem errada.

Uma possível solução para o problema seria:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Peter Pan Test Atrribute Lang</title>
</head>
<body>
  <h1>Peter Pan summary</h1>
  <p>Every night Peter visits the Darling family house and listens to Mrs. Darling tell bedtime stories. He sits on the window listening. One evening, they see Peter trying to escape. As he tries to run away, he loses his shadow. He goes back to get his shadow. He wakes up the daughter of the house, Wendy Darling. Wendy helps him attach his shadow to his body again. Wendy tells him she knows a lot of bedtime stories too.</p>
  <p>Peter invites Wendy to return to Neverland with him. He wants her to be the mother of the Lost Boys. Wendy agrees to the mission and asks for her brothers Michael and John to join them.</p>
  <p>They have a magical flight as they travel to Neverland and have many adventures along the way. Wendy is nearly killed and the boys build her a house in the trees to recover. After Wendy is okay, she takes the role of the mother.</p>
  <p>After all their adventures and fun, Wendy decides that her place is at home with their mother. Wendy helps all the Lost Boys return to London. But Peter doesn’t want her to go. Instead he tries to trick her. He tells her that their mother doesn’t want them anymore. However, he understands how sad their mother must be. In the end, he decides to let them go home.</p>
</body>
</html>

Ao incluirmos o escopo de global de linguagem, o documento usa essas configurações para toda a página. Assim, o leitor de tela irá carregar a entonação e sotaque daquela linguagem especificada.

Algo muito impressionante, não é mesmo?

Uma dica de ouro é:

Usar as tags e atributos corretos para gerar uma boa experiência de uso.

Curiosidades

A WCAG um documento que contém as diretrizes de acessibilidade web, informa que ao não fazermos a definição da linguagem descumprimos a diretriz 3.1.1[2].

O nível de impacto para os usuários é considerado alto.

O elemento do documento HTML deve conter um atributo lang válido ou deve corresponder a um código lang válido para usuários de leitores de tela multilíngues que podem preferir um idioma diferente do padrão.

Em todo documento HTML é obrigatório definir o idioma da página.

Conclusão

Percebemos que o atributo é extremamente importante para nossas páginas web e sua implementação é bastante simples. Existem casos em sites multilíngues que o atributo pode ser alterado dinamicamente via linguagens de programação. Meu conselho é: sempre que iniciar o desenvolvimento de uma página defina a linguagem e não tenha esse tipo de problema.

Gostou? Tem alguma dúvida ou sugestão? Escreva um comentário.

Referências

  • [1] Atributos globais > Lang. Mozilla Developer Network, 2019. Disponível em: Language of Page. Acesso em 14 de jan. de 2020.

Criando links acessíveis e válidos


Post traduzido por Bruno Pulis e escrito originalmente por Emma Patricios. Publicado em 15 de Fevereiro, 2019

O elemento de âncora é frequentemente citado como o principal bloco de construção da World Wide Web. Ele é utilizado para criar um link para outras páginas, para âncoras na mesma página, para outros recursos (como um PDF) ou para um endereço de e-mail. Como podemos ter certeza que eles são acessíveis a todos?

Comece com HTML válido

Para ser um link válido, deve ter:

– um **atributo `href`** – a localização da âncora, página ou recurso;
– **conteúdo do link** – texto descrevendo para onde o link está indo, pode ser um texto simples ou o `atributo alt` de uma imagem;
– abrindo e fechando tags.

Escrever texto do link com sentido

Textos comuns de links inúteis são “clique aqui”, “leia mais” e “link”.

Estes são problemáticos porque quando uma pessoa usa um leitor de tela para navegar através de links, eles serão lidos fora do contexto. Onde você esperaria que esses três links fossem se você os ouvisse? É impossível saber.

Pense em reestruturar sua sentença para remover clique aqui ou link e, em seguida, coloque a parte significativa no link.

<!-- ruim -->
Para verificar nossa documentação <a href="/README.md">clique aqui</a>.

<!-- melhor -->
Disponibilizamos nossa <a href="/README.md">documentação</a>.

“Leia mais” pode ser corrigido, incluindo o que vamos ler mais sobre:

<!-- ruim -->
<a href="/full-article">Leia mais</a>.

<!-- melhor -->
<a href="/full-article">Leia mais - Pontos de referência acessíveis</a>

E quanto ao atributo title

O atributo title não é exposto por todos os navegadores de uma forma acessível, isso significa que as pessoas que usam touch-devices e teclados provavelmente nunca verão essas informações.

“Se você quiser ocultar conteúdo de usuários de dispositivos móveis e tablets, bem como usuários de tecnologia assistiva e usuários de teclado, use o atributo de title.” Usando o atributo title HTML – The Paciello Group

Portanto, não é recomendado utilizar o atributo title em elementos <a>. Se você usá-lo, não use o mesmo nome do link, isso pode gerar leituras duplicadas desnecessárias para alguns leitores de tela.

Foco e teclado

Alguns desenvolvedores/designers vêem o outline como um recurso feio e os removem. As pessoas que navegam usando o teclado precisam desse estado para saber onde estão.

A melhor prática é nunca remover o outline, mas existem soluções acessíveis para o estilo, que estão definidas na Dica Rápida: Nunca remova outline do CSS. (em inglês)

Por padrão, um elemento <a> com um href pode ser ativado pela tecla Enter.

Lembre-se de não substituir essa funcionalidade se anexar outro script personalizado. Além disso, não é esperado que a tecla Space ative os links.

Quando você deve usar button

Se você tiver um elemento <a> que tenha:

  • um atributo vazio ou sem href
  • script anexado via atributo onclick ou listerners.

Leitura adicional

Informando empresas sobre problemas de acessibilidade


Esse artigo é uma adaptação livre da página do WAI. É um guia para informar organizações que possuem problemas de acessibilidade em seus sites.

Introdução

Esse artigo é uma forma de incentivar a você poder contribuir para as organizações criem sites mais acessíveis. Muitas vezes encontramos pela web, sites que precisam de alguns ajustes em questões de acessibilidade.

Informar as barreiras de acessibilidade é crucial para criarmos um ambiente digital inclusivo. Eis alguns motivos:

  • beneficiaria você que encontrou as barreiras;
  • a organização não ficaria esperando uma multa ou punição legal;
  • beneficia também os usuários do site.

Os proprietários de sites têm muitas prioridades para alterações e melhorias. Quanto mais uma organização ouvir sobre acessibilidade de pessoas que usam seu site, maior a probabilidade de se tornar uma prioridade mais alta. O feedback positivo é útil, bem como o feedback crítico.

A grande maioria dos proprietários de sites desconhecem da importância de tornar seu site acessível. Os sites precisam estar acessíveis em muitos países pelas políticas nacionais, especificamente no Brasil temos a Lei Brasileira de Inclusão.

A Convenção das Nações Unidas sobre os Direitos das Pessoas com Deficiência declara que as pessoas com deficiência têm o direito de acessar informações e serviços via Internet. Além disso, sites acessíveis oferecem benefícios comerciais para os proprietários de sites e benefícios para pessoas sem deficiência.

Observe que a maioria das barreiras à acessibilidade é causada pelo mau design e desenvolvimento do site, Comentei sobre isso num post anterior no blog, consulte HTML não é tão simples quanto você pensa.

No entanto, alguns problemas de acessibilidade podem estar relacionados às configurações no seu navegador ou na tecnologia de assistiva. Para obter orientações para ajudá-lo a personalizar seu navegador da Web específico e a configuração do computador para facilitar o uso de sites, consulte Melhor navegação na Web: dicas para personalizar seu computador

Pensando na melhor abordagem

Considere qual abordagem utilizará para obter os resultados desejados. Seu tom nos e-mails, telefonemas e outras formas de comunicação influencia a maneira como as pessoas reagem e respondem.

Lembre-se de que existem diferentes razões pelas quais os sites não estão acessíveis. Algumas organizações não sabem sobre acessibilidade e não sabem como tornar seus sites acessíveis. Alguns estão apenas aprendendo sobre acessibilidade e tentando tornar seu site acessível, embora ainda não o estejam fazendo o suficiente. E existem algumas organizações que optam por não tornar seus sites acessíveis.
{: .notice–info}

Geralmente, a melhor estratégia e quando você entra em contato com uma organização. Você pode ajustar sua abordagem com base na resposta deles e no que aprender sobre a posição da organização em acessibilidade. A resposta deles pode ajudá-lo a escolher ações de acompanhamento que provavelmente serão mais eficazes.

Peça ajuda

Considere pedir ajuda para entender o problema e comunicá-lo. Alguém pode ajudá-lo a entender o site ou as tecnologias de assistivas. Alguém pode ajudá-lo a se comunicar com os proprietários do site. Por exemplo, um advogado.

Incentivar sites acessíveis

Reconheça e incentive as organizações que tornam seus sites acessíveis. O feedback positivo pode motivar indivíduos e organizações.

Pode incentivar outras organizações a investir em acessibilidade na web.

Forma de contato

Tente encontrar a pessoa responsável pela página ou aplicativo que está inacessível. Ou encontre a pessoa responsável pela acessibilidade da organização. Às vezes, você terá que usar qualquer contato para encontrar.
Procure links em seus sites, como:

  • Acessibilidade;
  • Editor;
  • Autor;
  • Proprietário da página;
  • Desenvolvedor;
  • Entre em contato;
  • Feedback;
  • Comentários;
  • Ajuda;
  • Suporte;
  • Atendimento ao cliente.

Alguns links serão endereços de email, outros serão enviados para formulários on-line e outros fornecerão outras maneiras de entrar em contato com a organização.

Se você não conseguir encontrar contatos no site, outros locais para procurar:

  • lista telefônica;
  • biblioteca local e bibliotecário;
  • diretório de empresas locais;
  • registro de empresas públicas.

Descrevendo o problema

Descreva a barreira de acessibilidade de forma clara. Isso ajudará a organização a corrigir o problema. Inclua:

  • a página que foi encontrado o problema;
  • qual é o problema;
  • qual computador e software utilizou;
  • uma captura de tela da página.

Onde está o problema

Inclua a URL ou uma descrição da página.

Exemplo de URL

Exemplo de descrição da página

  • HTML não é tão simples quanto você pensa – Bruno Pulis
  • Sobre – Bruno Pulis

Qual é o problema

Forneça detalhes sobre o que você estava tentando fazer e por que era difícil ou impossível fazê-lo.

Exemplos de descrições de problemas

  • navegação no teclado – não consigo acessar a página inicial das páginas para pagar minha conta. Não consigo usar o mouse, então uso o Tab para acessar os links, mas não consigo acessar o link Pagar suas contas.
  • clique do mouse – é difícil para mim fazer o mouse parar em pequenas coisas. Na pesquisa, é difícil clicar nos pequenos círculos. Em outras pesquisas que usei, posso clicar nas palavras e nos círculos, o que é muito mais fácil.
  • texto pequeno – não consigo ler os horários dos ônibus porque o texto é muito pequeno. Defino o tamanho do texto como Maior no meu navegador, mas o texto não ficou maior.
  • sobreposição de texto – tive problemas para ler o texto pequeno. Aumentei o tamanho do texto no meu navegador, mas muito do texto se sobrepôs a outro texto e às imagens. Isso tornou impossível ler.
  • combinações de cores – é difícil ler algumas descrições do produto porque as cores dificultam a visualização do texto. Tenho problemas com combinações de cores azul/amarelo e azul/laranja.
  • texto alternativo – estou usando um leitor de tela para ouvir seu site. Os leitores de tela não conseguem ler imagens; eles lêem o texto alternativo do código. As imagens desta página estão com texto alternativo ausente. Por exemplo, ouço “240.gif”, que meu amigo me diz que é uma imagem para descontos especiais.
  • animações perturbadoras – achei a página inicial muito confusa e foi difícil encontrar as informações desejadas com todas as coisas animadas por toda a página. Eles continuaram a desviar minha atenção do que eu estava tentando ler.
  • legendas – me disseram que existem bons tutoriais em vídeo no seu site. Mas não consigo obter muitas informações dos vídeos porque não consigo ouvi-los. Faltam legendas nos vídeos.

Qual computador e software estava utilizando

Forneça detalhes sobre o seu computador e software. Se você não souber, talvez um amigo, parente ou colega possa ajudá-lo a encontrar essas informações. Caso contrário, você pode pular esta parte.

Incluir:

  • o sistema operacional que você está usando e a versão (por exemplo, Windows 10, macOS 10.13 ou Linux Ubuntu 17.10);
  • o software do navegador usado para exibir a Web e a versão (por exemplo, Edge, Internet Explorer (IE) 11, Firefox 60, Chrome 62.0, Opera 45, Safari 10.1.2 etc.)

Inclua também as seguintes informações, se estiverem relacionadas ao problema que você está tendo:

  • quaisquer configurações que você personalizou (por exemplo, defino o Tamanho da fonte como Maior no meu navegador)
  • qualquer tecnologia de assistência que você usa (por exemplo, leitor de tela, software de ampliação de tela, software de reconhecimento de voz para entrada)
Exemplos de descrições detalhadas de computador e software:
  • Eu uso o Windows 10 com o Internet Explorer 11 e o software de reconhecimento de voz Tazti;
  • Eu uso o leitor de tela NVDA versão 2017.2 com o Windows 10 Home edition e o navegador Firefox versão 60.

Mesmo se você não souber todos os detalhes, inclua o que sabe.

Exemplos de descrições simples:
  • Uso um Mac com o navegador Safari e defino o Universal Access para nunca usar fontes menores que 14;
  • Eu uso o Windows com Edge. Alterei as cores do Windows para fornecer texto amarelo em fundo preto, pois é mais fácil de ler;
  • Uso o navegador Opera no Windows e pressiono as teclas para navegar nos sites. (Não consigo usar o mouse.);

Nota: Não revele informações pessoais, como senhas, por e-mail ou de outra forma. Não forneça nenhuma informação que você não esteja confortável em divulgar.
{: .notice–danger}

Incluir fontes para obter mais informações

Ajude a organização entender as barreiras de acessibilidade. Considere incluir links exemplificando:

Solicite uma resposta

Peça à organização para responder a você. Se você estiver confortável em fornecer seu número de telefone, inclua seu número, caso desejem discutir o problema.

Acompanhamento conforme necessário

As organizações responsáveis acompanharão você. No entanto, às vezes você pode precisar acompanhá-los.

Esteja disponível para acompanhamento

Os desenvolvedores do site podem precisar de mais informações suas para ajudá-los a diagnosticar e corrigir o problema.

Mantenha registros para acompanhamento posterior

Você pode precisar de registros se, posteriormente, decidir executar outras ações. Em particular:

  • Mantenha cópias do site quando você encontrar o problema. Por exemplo, faça capturas de tela, salve as páginas no disco rígido ou imprima as páginas. Se o site mudar, faça novas cópias.
  • Mantenha cópias impressas ou eletrônicas de toda a correspondência, incluindo e-mail, correio e formulários on-line.
  • Mantenha registros de todas as chamadas telefônicas. Inclua as datas, os nomes de quem você falou e notas sobre o que foi dito.

Obtendo uma resposta

Você pode obter uma resposta rápida ou pode demorar mais para ouvir de volta. Depende da cultura, políticas e sistemas internos da organização.

Você pode receber uma resposta automática de que a organização recebeu seus comentários. A organização deve acompanhar mais tarde com uma resposta direta ao seu problema.

Às vezes, a organização não possui experiência em acessibilidade. Eles podem não entender seus comentários. Eles podem assumir que o problema está no seu navegador ou na tecnologia assistiva.

A organização pode corrigir o problema e não notificá-lo.

Se você não receber respostas satisfatórias dentro de um prazo razoável, considere tomar outras medidas, descritas abaixo.

Ações adicionais a considerar

Se você acha que a organização não está resolvendo adequadamente o problema de acessibilidade, considere tomar outras medidas. Por exemplo:

  • Entre em contato com advogados para ver se eles se envolverão;
  • Entre em contato com a gerência sênior da organização, como o CEO, o diretor administrativo ou o diretor comercial;
  • Use recursos da comunidade on-line, como blogs ou redes sociais, para contar aos outros sobre o site inacessível. Compartilhe o que a organização fez em resposta ao seu contato;
  • Entre em contato com a imprensa ou escreva uma “carta ao editor”;
  • Iniciando uma petição (talvez online);
  • Se for um site do governo, entre em contato com o governo local;
  • Apresentar uma queixa formal com no Ministério Público;
  • Entre em contato com o departamento governamental responsável pelos direitos da pessoa com deficiência, pelos idosos ou pelos direitos humanos;
  • Considere uma ação legal. Por exemplo, com base nos requisitos de acessibilidade da Web em regulamentos antidiscriminação em seu país.

E-mail de exemplo

Irei colocar o exemplo que acho mais completo os demais estão na página da W3C:

Assunto: Acessibilidade da página de notícias da Citylights

Olá Diretor da Citylights,

Sua página de notícias (http://www.cl.example.com/news/news.html) não está acessível. Eu escuto páginas da Web com o leitor de tela NVDA (versão 2017.2). Eu uso o Windows 10 e o Internet Explorer 11.

Meu colega me disse que você tinha algumas informações sobre ondas de calor, então eu fui para a página de notícias, mas havia algo estranho acontecendo. Encontrei uma frase sobre a onda de calor e as temperaturas, mas havia algo no caso do violino. Grande parte da página parecia confusa e era confusa para mim ouvir – parece que não foi escrita de maneira linear, para que alguém como eu, usando um leitor de tela, possa entendê-la.

Além disso, sua página de notícias não possui títulos. Os títulos são importantes porque eu os uso para obter uma visão geral da página e para me ajudar a navegar pelas histórias.

Verifique essas informações de acessibilidade da Web no W3C:

Informe-me quando esses problemas forem solucionados.

Obrigado pela sua atenção.

Bruno

Conclusão

Adotando esses passos podemos ter um feedback bastante positivo das organizações, fique a vontade de adaptar para o seu contexto. Esse artigo é somente um norte em como fazer o contato com as organizações.

Espero que te ajude!

Abraços,
Pulis.

Referências

Convention on the rights of persons with disabilities. United Nations, 2020. Disponível em: https://www.un.org/development/desa/disabilities/convention-on-the-rights-of-persons-with-disabilities.html Acesso em: 18 de maio de 2020;

Contacting Organizations about Inaccessible Websites. W3C WAI, 2020.
Disponível em: https://www.w3.org/WAI/teach-advocate/contact-inaccessible-websites. Acesso em: 18 de maio de 2020.

Better Web Browsing: Tips for Customizing Your Computer. Web Accessibility Initiative, 2020.
Disponível em: https://www.w3.org/WAI/users/browsing.php. Acesso em: 18 de maio de 2020.

Lei Brasileira de Inclusão. Planalto Federal, 2020.
Disponível em: http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13146.htm. Acesso em: 18 de maio de 2020.

« Older posts

© 2021 Bruno Pulis

Theme by Anders NorenUp ↑