Web Standards + acessibilidade em (quase) 5min

Você com certeza já ouviu esse termo — mas, sabe o real significado dele?

Photo by michael podger on Unsplash

Web Standards ou Web Patterns nada mais são do que recomendações feitas pela W3C para a correta utilização das ferramentas dentro do mundo do desenvolvimento web. O termo web standards é associado com uma série de boas práticas, consideradas como um tipo de filosofia no desenvolvimento de sites, aplicações web e afins.

Essas recomendações existem para que você, desenvolvedor, utilize corretamente os recursos das linguagens (HTML, CSS, JavaScript…) e também crie sites e sistemas acessíveis — para que qualquer pessoa no mundo possa acessar o que você desenvolveu de maneira única e universal, independente de condições físicas, mentais ou até mesmo do tipo de internet que o seu usuário possui.

O termo Web Standards deve ser um mantra para todo desenvolvedor front-end.

O tema acessibilidade na web vem ganhando destaque em tempos recentes — e não só na web. Durante o desenvolvimento de qualquer sistema precisamos levar em conta a parcela dos seus usuários que possuem algum tipo de dificuldade ou deficiência. Afinal, você também está desenvolvendo para eles!

Hoje existe uma grande interseção entre acessibilidade e SEO; são temas diferentes, onde as responsabilidades também são diferentes. Porém, muitas ações que acabamos fazendo para um valem para o outro — seja na otimização dos códigos ou na otimização das interfaces.

O WaSP (Web Standards Project) era um grupo de profissionais que tinha a responsabilidade de difundir e disseminar os padrões web da W3C. Fundado em 1998 por George Olsen, infelizmente o projeto foi descontinuado em 2013. Mas, o site deles ainda continua no ar (em inglês), com uma série de tutoriais simples e didáticos:

https://www.webstandards.org/

Entre as documentações, existe um FAQ sobre "o que são Web Standards e por quê você deveria utilizá-los?". Para explicar um pouco sobre os tais padrões de semântica e acessibilidade, vou utilizar ele (o site do WaSP) como régua; afinal de contas, foi através dele que eu aprendi muita coisa e acredito que seja uma fonte confiável nesse oceano azul chamado internet.

Se pudessemos resumir tudo o que está no FAQ do WaSP, basicamente seria (nas minhas palavras):

Utilize corretamente as linguagens e você terá um resultado final com qualidade, simplicidade e acessibilidade.

Para você ler o FAQ completo:

https://www.webstandards.org/learn/faq/index.html

Bom, vamos começar!

1 — Formulários

Raramente você irá encontrar um site ou sistema que não possua um formulário. Embora seja uma tag que está presente nas specs desde 1997 (pelo menos), muita gente não conhece o quão simples é deixar um form acessível. Aqui, quanto mais simples forem sua estrutura e as regras de negócio (validações), melhor!

Labels + Inputs

Em teoria, todo input deve possuir uma label associada — isso é quase uma regra. Para fazer a associação da label com o input, é só colocar o atributo for="" dentro da <label>, e o valor desse atributo deve ser o id do input seguinte:

<label for="form_name">Nome</label>
<input type="text" id="form_name" name="form_name" />

Submit

Outro exemplo simples de acessibilidade em formulários é o botão de submit. Existe um tipo específico de input para esses casos, o submit. Se existe esse elemento dentro de um <form>, automaticamente quando o usuário clicar enter em qualquer campo, o formulário será enviado (como se o usuário tivesse clicado no botão).

A questão do submit também é um web standard pois ele é o elemento que deve ser utilizado — muitos devs utilizam <a>, ou até mesmo um <span> cheio de estilo e eventos desnecessários — tornando tanto a usabilidade quanto a manutenção do código complicada.

<input type="submit" id="form_submit" name="form_submit" value="Enviar" />
<!-- ou -->
<button type="submit" id="form_submit" name="form_submit">Enviar</button>

2 — Heading Tags

A estrutura do conteúdo em páginas web é importante para acessibilidade e SEO — não pular nem misturar a ordem das heading tags é um grande desafio no desenvolvimento front-end.

Heading Tags, ou Elementos de Cabeçalho, é o conjunto de tags que vai do <h1> ao <h6>, os quais informam para o usuário o início de um artigo ou um novo tema/subtítulo dentro de um conteúdo.

A ordem de importância começa com o 1, sendo o mais importante, e desce para o 6, o menos importante.

Geralmente, os <h1> são utilizados para o título do site, ou o título mais importante da página.

Vamos pegar de exemplo o site da Uol: todos os títulos de artigos são marcados com <h6>.

Quando entendemos a questão de marcação no HTML, a função das heading tags começa a ficar mais clara e conseguimos entender melhor o contexto de aplicação de cada uma delas.

3 — Listas

Um ponto muitas vezes "polêmico" são listas em HTML. Tem gente que usa sempre <ol>, tem gente que usa sempre <ul>, tem gente que faz com <div>… Em grande parte dos casos, parece que cada desenvolvedor tem a sua receita própria para fazer listas.

• <ol>
  Por definição, esse tipo de lista é indicado para listas ordenadas (Ordened Lists), onde a ordem dos itens é importante; Por exemplo, uma receita.
• <ul>
  Listas não-ordenadas (Unordered Lists) são indicadas em casos onde a ordem dos itens não é obrigatória — por exemplo, uma linha do tempo, ou até mesmo essa lista.
• <dl>
  Listas de definição (Definition Lists) são indicadas para conteúdos como um glossário, onde temos os pares de chaves e definições.

Qualquer outro tipo de marcação para listas está semanticamente errado. E aqui quero deixar um grande ponto sobre semanticamente errado:

Apesar de visualmente o conteúdo estar ajeitado e até mesmo validado por um designer (ou um PM/PO), o código estará verdadeiramente correto se você utilizar a marcação correta.

4 — Imagens

Outro ponto de atenção, seja para SEO e/ou acessibilidade, são as imagens. Falando em um grosso modo, hoje existem 2 maneiras de inserir imagens dentro de conteúdo — utilizando a tag <img> (junto, ou não, com a tag <figure>) ou utilizando ela como imagem de fundo (background-image) em algum outro elemento (geralmente uma <div>).

As duas maneiras estão corretas, mas isso depende do contexto em que a imagem está inserida:

• se a imagem faz parte do conteúdo, seja um banner ou um hero, ela obrigatoriamente deve estar dentro de uma tag <img>;
• se a imagem é apenas um recurso visual, um ícone ou ilustração, ela pode estar como background-image.

Mas, por que? — usuários de tecnologias assistivas irão agradecer!

Ainda sobre imagens, um ponto que é muitas vezes esquecido: alt.

O atributo alt nas imagens tem a função de traduzir o conteúdo das imagens para tecnologias assistivas (como um leitor de tela) e para robôs que escaneiam sua página (googlebot, ou qualquer outro crawler). A função dela é simples, porém é muito fácil acharmos imagens sem alt.

Basicamente, quando você não declara o alt nas imagens, os leitores de tela tem 2 saídas:

• falar o nome da imagem para o usuário (xpto123abc.png)
• falar "imagem"

Já com o atributo, o leitor irá falar o conteúdo e o usuário conseguirá ter um contexto melhor sobre o que se trata.

"Ah mas essa minha imagem aqui não precisa de alt, não quero que o usuário interaja com ela"

Para esse caso, podemos declarar o alt vazio:

<img src="imagem.jpg" alt="" />

Dessa forma, a imagem será "ignorada" pelo leitor de tela! Simples, não?

5 — Emojis

Hoje na internet os emojis se tornaram um idioma a parte, e é bem comum encontrarmos eles no meio do conteúdo em diversos sites — particularmente eu até gosto.

Mas, pensando em acessibilidade, precisamos seguir uma regrinha bem básica para que ele seja compreendido e absorvido pelos leitores de tela:

<span role="img" aria-label="bandeira do Brasil">🇧🇷</span>

Aqui vemos os atributos ARIA sendo utilizados para complementar o significado semântico do conteúdo — role vai informar como o elemento deve se comportar, e aria-label funcionará de maneira semelhante ao alt das imagens.

Embora este tema não esteja no FAQ do WaSP, é cada vez mais comum o uso desse tipo de linguagem e achei relevante ele estar figurando aqui.

6 — ARIA

Um grande aliado no desenvolvimento front-end são os atributos ARIA, ou WAI-ARIA (para os mais íntimos).

ARIA significa Accessible Rich Internet Applications - em português, "Aplicações Ricas Acessíveis da Internet".

WAI significa Web Accessibility Initiative - em português, "Iniciativa da Web Acessível"

Essa iniciativa é feita pelo W3C com o objetivo de padronizar algumas práticas no desenvolvimento acessível.

Como vimos no exemplo acima, dos emojis, os atributos ARIA são compostos por 3 grandes grupos:

• Roles
  roles, ou funções, irão definir como um elemento irá se comportar;
• States
  states, ou estados, irão informar sobre possíveis estados do elemento — enabled, disabled, open, selected, expanded, checked…
• Properties
  properties, ou propriedades, são informações adicionais sobre o elemento — labels, descriptions, referências…

Além da documentação do MDN sobre ARIA, utilizei muito esse post do Tableless como referência — espero que eles te ajudem!

Os atributos ARIA podem (e devem) ser utilizados com as definições do HTML5!

Além dos 6 tópicos abordados nesse post, que são uma espécie de cookbook (receita pronta de bolo) para melhorar/corrigir alguns pontos pertinentes a SEO e acessibilidade, existem diversos outros pontos que você, desenvolvedor, deve estar atendo para desenvolver códigos de qualidade, seguindo boas práticas e padrões confiáveis.

Apenas citando, a velocidade de carregamento da página seria um desses outros itens.

Na minha opinião, muita gente acha que HTML/CSS é "coisa fácil" — seja por essas linguagens não serem de programação, ou por não serem compiladas (o que aumenta a margem para erros no código), ou apenas por não conhecerem de fato as grandes responsabilidades que elas possuem — por isso é bom ficar atento aos Web Standards!