Escrevendo HTML com acessibilidade em mente
Fala galera! Tudo bem? Hoje, trazendo mais uma tradução aqui para o meu blog no Medium e sobre Acessibilidade. Se lembra do texto Escrevendo JavaScript com acessibilidade em mente ? Então, ele possui um texto anterior. O Escrevendo HTML com acessibilidade em mente, estou acompanhando está série muito rica de conteúdo e trazendo ela para você, meu querido leitor. Agora chega de conversa, vamos ao texto.
Desenvolvimento pessoal e mudança de perspectiva
Quando eu fiz meu primeiro site, minha maior prioridade foi fornecer o conteúdo online. Eu não me importava muito com usabilidade, acessibilidade, performance, UX ou compatibilidade entre browsers. Mas por que eu deveria? Eu fiz um robusto layout baseado em tabelas e oferecia uma versão 800 x 600 e 1024 x 768 do meu site. No topo, eu informava aos usuários que o site era otimizado para Internet Explorer 5.
Isso foi, é claro, antes de eu começar a trabalhar profissionalmente como um web designer e minha perspectiva não era o que importava. Anos depois, em vez de ditar os requisitos para os meus sites, comecei a otimizá-los para todos os principais navegadores. Comecei com Ethan Marcotte’s game changing article, e comecei a dar mais atenção a outros dispositivos. Fazer sites para todos os tipos de navegadores ou dispositivos é bom, mas inútil se os sites forem lentos. Então eu aprendi tudo sobre CSS crítico, índices de velocidade, carregamento de fontes, CDNs e tudo mais.
Começando com acessibilidade (a11y)
Recentemente minha perspectiva mudou novamente e eu percebi que fazer um site rápido e responsivo que funciona em navegadores mais antigos não é suficiente se, por exemplo, não for navegável via teclado. Mas acessibilidade ainda não é um item de nossa to-do list antes de começarmos nossos sites. Acessibilidade é a fundação do que nós fazemos como web designers e desenvolvedores web, e é nossa obrigação tratá-la como tal.
Eu investi os últimos meses lendo, ouvindo e falando sobre acessibilidade na web. Levei algum tempo para colocar na minha cabeça algumas coisas e ainda estou no começo, mas quanto mais eu aprendo, mais fico surpreso com o quanto posso fazer agora sem ter que aprender nada completamente novo.
Eu expando meu conhecimento de HTML, CSS e JavaScript, mas a coisa mais importante que aprendo é que acessibilidade não é somente um termo médico que se aplica a somente alguma certa porcentagem da população. Acessibilidade é algo que abrange a todos nós, você e eu, todos os dias. O que nós criamos é inútil se não for acessível.
Nesta série de artigos, eu quero compartilhar um pouco do meu conhecimento adquirido recentemente com você. Você não deve tratar as dicas que eu vou lhe dar como uma lista de verificação, mas como um ponto de partida. Incorporar estas técnicas ao seu fluxo de trabalho irá iniciar você com acessibilidade e ajudá-lo a motivar você a aprender e cuidar mais dos seus usuários.
Sem mais delongas, aqui vai minhas dicas de acessibilidade:
É importante definir uma linguagem natural para o seu documento
Falando para o navegador qual linguagem você está usando em seu documento traz muitos benefícios. É bom para o SEO, ajuda a ferramentas de tradução de terceiros e aos navegadores a identificar a correta linguagem e dicionário. Definir a correta linguagem em uma página HTML ajuda a tecnologias assistivas a escolher o perfil correto de voz ou conjunto de caracteres(1). Adrian Roselli reuniu alguns dos maiores benefícios de se usar o atributo lang no site dele.
<html lang="en">
…
</html>Assista a demonstração do atributo lang em uso no Youtube. (o vídeo é pequeno e muito importante)
Se você precisa mudar a linguagem dentro do seu documento, você pode usar o atributo lang em tags específicas.(2)
<p>There is a certain <i lang="fr" class="idiomatic">je ne sais quoi</i> in the air.</p>Certifique-se de definir a linguagem correta. Steve Faulkner fez um vídeo que ilustra o que acontece se você não usa o atributo lang corretamente. Toda a linguagem de código são listadas em IANA Language Subtag Registry.
Você pode esconder conteúdo usando o atributo hidden
Se você quer esconder conteúdo visualmente e dos leitores de tela, use o atributo hidden.
O suporte dos navegadores para este atributo é muito bom, exceto para os IE 10 e antigos. Você pode prover um suporte para navegadores antigos adicionando um fallback ao seu CSS:
[hidden] {
display: none;
}Às vezes é melhor adicionar um atributo alt em branco ao elemento <img>
Se uma imagem é usada como conteúdo, aplicar o atributo alt para descrevê-la funciona perfeitamente. . Quando você fizer isso, não comece com “Figura / Imagem / Gráfico de …”, porque o leitor de tela já faz isso de qualquer maneira.
Se a imagem é puramente decorativa ou não acrescenta nenhum valor informativo, considere colocar ela na página como um background-image . Se você quer ou tem que adicionar ela em seu HTML, não remova o atributo alt, só o deixe vazio. (3)
<img src="decorative_image.jpg" alt="" />É importante que você não omita o atributo alt.
Ao omitir este atributo completamente indica que a imagem é uma parte chave do conteúdo, e nenhum equivalente textual está disponível. Definindo este atributo como um texto vazio alt="" indica que a imagem não parte chave do conteúdo e que navegadores não visuais podem omití-la da renderização. Fonte completa.
Há mais algumas dicas de uso do atributo alt na página do projeto A11y, em Dica Rápida: usando o atributo alt corretamete.
Se você precisa de um botão, use o elemento <button>
Em geral, você deveria sempre escolher usar elementos nativos do seu HTML, não use outros. Por exemplo, se você precisa de um botão, use o elemento <button>, não uma <div> .
Botões tem muitos benefícios / características cruciais, por exemplo:
- Focalizável
- Clicável
- Leitores de tela o identificam como botões
Rob Dodson realizou um bom trabalho explicando os benefícios do atual <button> em relação a uma <div> . Assista ao episódio do A11ycasts, Apenas use botão para mais detalhes e exemplos.
Se você não tem certeza de quando usar um botão ou um link, leia o post de Marcy Suttons, Links vs. Buttos em Aplicações Web Modernas.
Estruturar seu markup corretamente com cabeçalhos é importante
Ao usar em suas página cabeçalhos <h1> — <h6> você está ajudando aos usuários a entenderem melhor a estrutura de sua página e os relacionamentos entre as seções individuais. No final de tudo, ajudará os usuários com tecnologias assistivas na hora da navegação. Leitores de tela fornecem diferentes formas de mover de um conteúdo para outro. Por exemplo, ao se usar o leitor de tela NVDA, usuários podem pular de um título para outro usando atalhos, como as teclas H e shift + H.
Link de um vídeo demonstrativo
Quando você aninhar os títulos, os pulos de nível devem ser evitados (4). Também. não use múltiplos <h1> aninhados. Adrian Roselli explica o porque nestes artigos, Não há nenhum algorítimo para esboço de documento e A Verdade sobre Múltiplas Tags H1.
<!-- Don't skip levels: -->
<body>
<h1>My website</h1>
<h4>Heading</h4>
<h2>Subheading</h2>
<h3>Heading</h3>
</body><!-- Don't rely on inexistent outline algorithms: -->
<body>
<h1>My website</h1>
<section>
<h1>Heading</h1>
<section>
<h1>Subheading</h1>
</section>
</section>
<section>
<h1>Heading</h1>
</section>
</body><!-- Do this: -->
<body>
<h1>My website</h1>
<h2>Heading</h2>
<h3>Subheading</h3>
<h2>Heading</h2>
</body>
total11y fornece uma boa forma de checar se seu outline (esboço em tradução livre) é consistente. Outra forma é desabilitar o CSS e checar se página é legível e se a estrutura faz sentido.
Use landmarks para ajudar as pessoas a navegarem no seu site
É possível e aconselhado que você use as tags de seção do HTML5, tais como article, aside, nav e section. Você também pode usar os atributos roles da WAI-ARIA para os navegadores antigos ou seções que não tem uma tag explícita, como search(5). Seccionar elementos não é trocá-los por um elemento<div>. Use-os para marcar pedaços maiores de conteúdo relacionado que são distintos de outros conteúdos. Não use exageradamente elementos de seção. Use <div> para CSS / JS e seções para a semântica.
Um dos benefícios principais é que usuários leitores de tela serão capazes de navegar pela página pulando de seção em seção. Esta navegabilidade é chamada de landmark(7). Assista a um vídeo demonstrativo deste tipo de navegação no Youtube.
<body>
<header> <!-- landmark -->
<nav> <!-- landmark -->
...
</nav>
</header> <aside> <!-- landmark -->
</aside>
</body>
Você pode simular esta característica de pular de um landmark para outro com uma extensão para navegadores chamado Landmarks. Pressione ALT + Shift + N para mover para o próximo e ALT + Shift + P para voltar ao anterior.
Se você quiser aprender mais sobre seções, de uma olhada na página de tutoriais de acessibilidade na web da W3C.
Observe que nem todos os softwares irão tratar cada landmark como tal.
O conteúdo principal, o cabeçalho e o footer também são landmarks
Envolvendo o conteúdo principal de seu site com o elemento<main> você permite que alguns leitores de telas possam pular diretamente para tal conteúdo usando um atalho. O elemento <main> representa a seção principal do corpo do documento ou aplicação e não deve ser usado mais de uma vez no documento. (5)
Como já dito, dividir seu conteúdo em landmarks é uma boa coisa. <header> e <footer> funcionam na maioria dos navegadores como landmarks se eles não estão aninhados dentro de uma <section> ou <article> . Se você precisa suportar navegadores mais antigos, você pode usar o atributo role no conteúdo principal. Para o header, existe o valor bannere para o footer, o valor contentinfo (6).
<!-- The extra role attributes are only important for older browsers -->
<body>
<header role="banner">
<h1>My personal blog</h1>
</header>
<main>
<section>
<h2>Blog posts</h2>
....
</section>
</main>
<footer role="contentinfo">
© 2016 Me
</footer>
</body>fieldsets são ótimos para agrupar elementos do formulário e dar-lhes mais contexto
Você provavelmente já precisou ter de adicionar vários elementos radio button ou checkbox a um formulário. Adicionando estes elementos e os correspondendo com seus labels não é a melhor coisa, às vezes. Mas qual elemento você escolheria, se quer um rótulo para agrupar os radio buttons ou checkboxes?
<form>
Shirt size
<input type="radio" id="s" name="shirtsize" />
<label for="s">S</label>
<input type="radio" id="m" name="shirtsize" />
<label for="m">M</label>
<input type="radio" id="l" name="shirtsize" />
<label for="l">L</label>
</form>Como você rotularia a frase Shirt size? Um <p> provavelmente funcionaria, mas não está associado com o grupo de radio buttons.
Um abordagem muito melhor é envolver tudo em um fieldset e colocar T-shirt size em uma tag<legend> . Leitores de tela saberão que este <legend> está associado com os radio buttons e lerão os valores quando selecionado.
<form>
<fieldset>
<legend>T-Shirt size</legend>
<input type="radio" id="s" name="shirtsize" />
<label for="s">S</label>
<input type="radio" id="m" name="shirtsize" />
<label for="m">M</label>
<input type="radio" id="l" name="shirtsize" />
<label for="l">L</label>
</fieldset>
</form>Com <section> seja cuidadoso ao envolver seus elementos de formulários em fieldsets. Como regra geral, use somente <fieldset>se tiver vários elementos de formulário que formam um grupo e um label correspondente para esse grupo, algo que se encaixaria em um <legend>.
Indo além
Isso é tudo por agora. Eu acredito que estas dicas irão ajuda-lo a escrever um HTML mais acessível. Um grande obrigado ao Heydon Pickering, pois este seu livro, Inclusive Front-End Design Patterns deu a fundação de tudo que você leu. Se quiser aprender mais sobre acessibilidade e design inclusivo eu super recomendo este livro.
Lista de referência:
(1) Pickering, Heydon; Inclusive Design Patterns, p.5
(2) w3.org Wiki — i element
(3) WebAIM — Alternative Text
(4) Web Accessibility Tutorials — Headings
(5) WAI-ARIA — main (role)
(6) Using navigation landmarks
(7) Landmarks must identify content regions
Bem galera, mais um texto traduzido do Manuel Matuzovic. Um grande agradecimento a ele por ter escrito um grande texto. Se gostou, não deixe de recomendar e compartilhar, para que mais pessoas tenham acesso a este conhecimento. Lembre-se: tornar um site acessível não é uma opção :). Até mais galera!
