Saltar para os conteúdos

Introdução

Durante muito tempo (e mesmo para algumas pessoas hoje em dia) quando se falava em acessibilidade, apenas se pensava em versões alternativas dos sites em texto para poderem ser lidas por sistemas de leitura de ecrã para invisuais.

A acessibilidade na web é muito mais do que isso. É permitir o acesso à informação de forma universal, para todos os utilizadores, independentemente das suas necessidades especiais.

E quando falamos em necessidades especiais, podemos estar a falar de um invisual, de um surdo, de uma pessoa com paralisia cerebral, ou até mesmo de utilizadores com outro tipo de "deficiências" como por exemplo uma deficiência tecnológica (usa um computador antigo; o rato está avariado) ou uma deficiência temporária (o braço que costumava usar o rato está partido e tem de usar o outro braço).

Assim, existem um conjunto de recomendações de acessibilidade que devem ser seguidas para que o acesso aos conteúdos seja universal e que todos consigam navegar e ler a informação disponível:

Como medir a acessibilidade?

Existem várias ferramentas online que permitem fazer uma verificação inicial de acessibilidade. Todos eles usam ou as WCAG 1.0 ou as WCAG 2.0 como base para mostrar os resultados, por isso o resultado num validador irá ser muito semelhante em outro validador. O que pode variar são as dicas de ajuda e resolução dos problemas que cada validador apresenta.

Uma vez que as WCAG 1.0 já estão obsoletas, recomendamos o uso apenas de validadores que usem as WCAG 2.0 como base. Alguns exemplos de validadores online são:

O facto de uma ferramenta automática indicar que o site passa na validação não garante que seja acessível, mas está no bom caminho. O problema é que os validadores automáticos apenas conseguem validar itens que possam ser testados por uma máquina, ou seja, verificam o código HTML e procuram por padrões e problemas conhecidos.

Um validador automático tem mais dificuldades em verificar o contraste entre cores ou se os textos e elementos clicáveis são suficientemente grandes para poderem ser lidos e usados por todos os utilizadores.

Desta forma, sempre que possível, além da validação automática, recomendamos o teste com alguns utilizadores com necessidades especiais de modo a validar se o site é ou não totalmente acessível. Na impossibilidade de recrutar esse tipo de pessoas, podemos testar simulando alguns constrangimentos, como por exemplo:

  • Tentar navegar no site usando apenas o teclado;
  • Ligar o screen reader (em OS X basta ligar o VoiceOver; em Windows pode-se instalar o NVDA gratuitamente) e tentar navegar com os olhos fechados;
  • Usar o site sentado a 1 e 2 metros do ecrã e ver se consegue ler os textos e se consegue navegar nos menus;
  • Usar o rato com a mão não dominante e tentar clicar nos links e botões para perceber se utilizadores com mobilidade reduzida conseguiriam usá-los.

Nos capítulos seguintes, vamos listar algumas dicas e recomendações de acessibilidade que permitem tornar os websites mais acessíveis e que são normalmente de fácil implementação.

Vamos começar!

Navegação

Tornar a navegação acessível é uma das principais preocupações a ter em conta para fornecer um acesso universal aos conteúdos. O facto dos utilizadores conseguirem navegar até ao conteúdo que pretendem aceder, é meio caminho andado para um website acessível.

É importante que o website seja navegável com qualquer sistema, quer seja o rato, o teclado ou um outro dispositivo apontador. E devem ser dadas pistas visuais sobre a localização do cursor no ecrã, de modo a que os utilizadores não se percam na navegação.

De seguida, daremos algumas dicas e sugestões para melhorar a acessibilidade da navegação num website.

Para ajudar os utilizadores que usam dispositivos de navegação assistida (ex: screen-readers), devem ser fornecidos atalhos para saltar os blocos de links que se repetem em todas as páginas.

Para os utilizadores que navegam com screen-readers torna-se bastante entediante ter que ouvir todos os links do menu sempre que carregam uma nova página, além do tempo que isso demora até chegar ao conteúdo em si. Para facilitar a navegação e melhorar a experiência de utilização, devemos colocar no topo do site um link para saltar os menus e ir diretamente para os conteúdos.

No HTML basta colocar um link no topo da página (logo a seguir ao <body>). Para fazer com que o link salte para o bloco dos conteúdos, o endereço deverá ser igual à id do bloco para onde queremos saltar:

Muito importante: Para fazer com que a navegação com o teclado continue a partir dos conteúdos em vez de voltar ao topo da página, deve-se adicionar o atributo tabindex="0" para tornar o bloco de conteúdos "focável" pela navegação com o teclado.

<body>
	<div id="saltar">
		<a href="#conteudos">Saltar para os conteúdos</a>
	</div>
	
	<nav>
		<!--Lista interminável de links de navegação-->
	</nav>
	
	<div id="conteudos" tabindex="0">
		<!--Os conteúdos da página-->
	</div>
</body>

Através de CSS podemos esconder o link dos utilizadores que não utilizem dispositivos de navegação assistida, fazendo com que ele fique apenas disponível para quem usa screen-readers, browsers de texto (sem folhas de estilo) ou outros dispositivos assistivos. Podemos também remover o outline que alguns browsers adicionam aos elementos focados, mas apenas para a div dos conteúdos e nunca para todos os links da página:

#saltar {
	position: absolute;
	left: -10000px;
	top: -10000px;
}

#conteudos:focus, #conteudos:active {
	outline:none;
}

Nota: Não usar o CSS {display: none;} para esconder o link, pois isso irá esconder o link tanto do ecrã como dos screen-readers, perdendo assim o seu efeito.

Para quem navega com o teclado, podemos voltar a mostrar estes links escondidos assim que o utilizador passar pelo link. Isto permite que o utilizador saiba onde se situa na página (qual o link que está seleccionado) se estiver a navegar usando a tecla TAB.

Mudando um pouco o CSS podemos reposicionar os links no topo da página (invertendo as instruções anteriores) assim que forem ativados pelo teclado:

#saltar a:focus, #saltar a:active {
	display:block;
	position:absolute;
	top: 10000px;
	left: 10350px;
	background: #fff;
}

Pode ver-se um exemplo real da aplicação desta navegação neste site (SAPO UX), bastando para isso navegar com o teclado (tecla TAB) assim que a página carregar.

Aumentar tamanho dos textos e elementos clicáveis

Para utilizadores com mobilidade reduzida ou com paralisia cerebral, o maior problema é conseguirem acertar em pequenos links ou botões numa página. Seguindo a Lei de Fitts, quanto maior for o alvo, mais fácil é de lhe acertar. Assim, quanto maiores forem as áreas clicáveis, mais facilmente elas poderão ser usadas por pessoas com mobilidade reduzida.

Algumas correções simples que se podem aplicar são:

  • Aumentar o texto global do site. Às vezes, um texto um pouco maior, ao mesmo tempo que melhora a legibilidade, permite que os links presentes no texto possam também ser mais facilmente clicados. Recomendamos sempre que sejam usados textos de tamanho superior a 14px (16px seria ótimo) para os conteúdos de modo a serem bem legíveis;
  • Adicionar um espaçamento extra (padding) a alguns links mais pequenos, como por exemplo, os links de paginação;
  • Aumentar os botões e eventuais ícones que sejam usados para despoletar ações. Quanto maior for o botão, mais fácil será de lhe conseguir acertar;
  • Aumentar o espaçamento entre linhas e entre parágrafos para melhorar a legibilidade dos conteúdos.

Segundo a Lei de Fitts, quanto maior for o alvo, mais fácil é de lhe conseguir acertar

Esta recomendação (aumentar os elementos clicáveis) é das poucas que tem impacto visual no site, pois normalmente a maioria das recomendações de acessibilidade têm apenas impacto no código HTML da página.

Fornecer alternativas textuais aos elementos não-textuais

Os elementos não-textuais (gráficos, imagens, etc.) devem conter alternativas em forma de texto. O texto alternativo nas imagens deve ser colocado dentro do atributo alt="texto alternativo da imagem".

No caso das imagens não transmitirem nenhuma informação relevante, é preferível manter o texto alternativo vazio, mas deve ser sempre adicionado o atributo alt="". Isto fará com que os screen-readers e outros sistemas assistivos possam ignorar a imagem.

Um exemplo de uma imagem que não transmite qualquer relevância para o conteúdo é a foto de uma bola de futebol num artigo desportivo.

<!-- As imagens que sejam relevantes, devem conter uma descrição-->
<img src="Obama-Putin-shakehands.jpg" alt="Obama e Putin apertam as mãos em sinal de entendimento" />

<!-- As imagens que não são relevantes devem ter o alt vazio -->
<img src="ball.jpg" alt="" />

Nota: Deve ser evitado o uso de imagens decorativas no meio do HTML (ex: cantos arredondados, imagens de espaçamento, etc). Todos os elementos relacionados com a apresentação/decoração devem ser incluídos via CSS.

Não remover o outline dos elementos clicáveis

Outline nos links clicados

O outline que os browsers adicionam aos links quando se faz foco com o teclado ou quando se clica com o rato é uma ajuda útil para que os utilizadores percebam em que elemento da página estão a navegar, especialmente quando se navega com o teclado.

Muitos web designers removem esse outline porque o acham inestético, no entanto, ao fazer isso estão a impedir que uma fatia de utilizadores consiga usar eficazmente o website.

/* Não fazer isto */
a {
	outline:none;
}

O que se pode fazer, se quisermos ter um maior controlo sobre o efeito do outline, é usar os mesmos estilos do :hover e copiá-los para o :focus. Assim, a navegação com o teclado terá o mesmo feedback que a navegação com o rato.

a:hover, a:focus {
	/* Inserir aqui os estilos ao passar com o rato ou navegar com o teclado */
}

Outra alternativa é desligar o outline apenas nos links ativos. Isto evita que o outline "inestético" permaneça à volta dos links clicados no website ao mesmo tempo que permite que a navegação com o teclado funcione normalmente.

/* Remove o outline apenas após clicar no link */
a:active {
	outline:none;
}

Não devem ser criados links sem o atributo href ou sem conteúdo entre as tags <a>.

Todos os links devem ter algum conteúdo textual que possa ser lido. Caso seja usada uma imagem como link, ela deve ter o atributo alt preenchido, pois será esse o texto do link.

<!-- Links vazios serão ignorados pelos screen readers -->
<a href="http://exemplo.pt"></a>
<a href="http://exemplo.pt"><img src="imagem.png" alt="" /></a>
<!-- Todos os links devem conter algum elemento textual -->
<a href="http://exemplo.pt">Texto do link</a>
<a href="http://exemplo.pt"><img src="imagem.png" alt="Texto do link" /></a>

Uso de Font Icons

Os Font Icons são pequenos ícones que podem ser usados no meio do texto e dos links para transmitir uma mensagem visual ao texto ou ao link. No entanto, estes ícones não têm qualquer significado semântico ou textual além do seu significado visual.

Ao criar links que contenham exclusivamente Font Icons (sem qualquer outro texto associado) é preciso adicionar um texto que possa ser lido em substituição do ícone.

<!-- O ícone não é um conteúdo legível -->
<a href="/pesquisa.html"><span class="fa fa-search"></span></a>

Existem duas formas de adicionar texto aos ícones e que não têm grande impacto na estrutura dos elementos. A primeira é usando o atributo aria-label de modo a dar um significado textual ao elemento que contém o ícone:

<!-- Exemplo para links -->
<a href="/pesquisa.html" aria-label="Pesquisa"><span class="fa fa-search"></span></a>
<!-- Exemplo para botões -->
<button type="submit" aria-label="Guardar"><span class="fa fa-save"></span></button>

Esta solução é válida, mas como se pode ver, não existe conteúdo real (textual) dentro das tags <a> e <button>, ficando o texto apenas disponível se o browser ou screen-reader suportar WAI-ARIA.

Uma outra forma de o fazer é adicionando o texto da ação dentro das tags, mas primeiro, é preciso criar um estilo para esconder o texto de forma que ele não fique escondido dos screen-readers:

.hide-text {
	position: absolute !important;
  	height: 1px; 
  	width: 1px; 
  	overflow: hidden;
  	clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
  	clip: rect(1px, 1px, 1px, 1px);
}

Mais informações sobre como esconder conteúdo de forma acessível.

Depois, podemos passar o ícone para o elemento envolvente e escrever o conteúdo dentro das tags:

<!-- Exemplo para links -->
<a href="/pesquisa.html" class="fa fa-search"><span class="hide-text">Pesquisa</span></a>
<!-- Exemplo para botões -->
<button type="submit" class="fa fa-save"><span class="hide-text">Guardar</span></button>

Pode ser visto um exemplo de utilização desta técnica no ícone do formulário de pesquisa do SAPO UX.

Links com interatividade JavaScript

Quando se usa JavaScript para adicionar interatividade a um link, muitas vezes essa interatividade é despoletada através de uma class ou id presente no link, e o destino final do link href é ignorado ou deixado em branco.

<!-- O href não pode ser ignorado -->
<a id="ajax_faz_coisas">Texto do link</a>

O href tem de estar sempre presente.

<!-- Caso não exista uma página de destino sem JavaScript, deve-se usar um # -->
<a href="#" id="ajax_faz_coisas">Texto do link</a>
<!-- Mas o ideal é que a funcionalidade exista mesmo que o JavaScript não carregue -->
<a href="pagina-faz-coisas-sem-js.html" id="ajax_faz_coisas">Texto do link</a>

Os links que apontem para websites externos devem ser identificados como tal. É importante que os utilizadores percebam que vão abandonar o site atual e vão entrar num novo site assim que clicarem no link.

O ideal será adicionar um ícone a seguir ao link (normalmente uma seta a sair para fora de uma janela) e incluir um texto (usando o atributo title) que indique que o link irá abrir um novo website:

<a class="external" href="http://www.site-externo.pt" alt="Link para site externo">Texto do link</a>

Links que abrem em novas janelas/tabs

A mesma solução pode ser usada para links que abrem em novas janelas/tabs.

Não recomendamos que os links abram em novas janelas, mas para abrir sites externos ou em algumas situações em que se justifique, pode-se usar o atributo target="_blank" com um ícone e uma indicação de que o site vai abrir numa nova janela no atributo title.

<a class="external" target="_blank" href="http://www.site-externo.pt" alt="Link para site externo (abre numa nova janela)">Texto do link</a>

Links para documentos não HTML

Os links para documentos não HTML (ex: PDF, DOC, etc) também devem ser claramente identificados.

Uma forma fácil de fazer isto é adicionar à frente do link o formato do ficheiro. Isto pode ser feito facilmente e automaticamente para todos os links do site via CSS:

/* Deteta todos os links para ficheiros PDF */
a[href$=".pdf"]:after {
	content:" (PDF)";
}

/* Deteta todos os links para ficheiros DOC */
a[href$=".doc"]:after {
	content:" (DOC)";
}

Referências

  1. Outline none - Don't do it
  2. Hiding content for accessibility
  3. Making accessible icon buttons

Mais dicas e recomendações

Uma vez que as regras de usabilidade e acessibilidade contemplam muitos pontos em comum, além das dicas e recomendações acima, devem também ser aplicadas as recomendaçoes de usabilidade para navegação disponiveis na secção Usabilidade do SAPO UX.

Tabelas

As tabelas são normalmente considerados o "bicho de sete cabeças" quando se fala em acessibilidade web.

Durante muitos anos as tabelas foram usadas para definir a estrutura do layout das páginas web, em que os elementos eram arrumados no ecrã dentro de uma estrutura em grelha criada através de combinações de células e tabelas dentro de tabelas.

À medida que a própria Internet foi evoluindo, foi começando a haver maior preocupação com a acessibilidade e em fazer a separação entre o conteúdo e a apresentação. Os browsers começaram a suportar melhor o CSS e começaram a ser definidos standards para simplificar as interações entre os utilizadores e os websites.

Com isto, as tabelas passaram a ser usadas com o propósito para o qual foram criadas: mostrar dados tabulares.

No entanto, é preciso ter alguns cuidados adicionais se queremos que o conteúdos mostrado nas tabelas seja perceptível para um utilizador que esteja dependente de um screen-reader ou outros dispositivos assistivos.

Evitar o uso de tabelas para layout

Estrutura de um website feito com tabelas

Apesar de ser uma recomendação, isto não significa que seja proibido usar tabelas para layout. Em alguns casos (se a tabela não for muito complexa) não existe qualquer problema de acessibilidade em ter um site feito com tabelas. Só é preciso ter em conta que os conteúdos irão ser lidos sempre linha a linha, da esquerda para a direita (seguindo a ordem com que aparecem no HTML), e que devem fazer sentido quando lidos nessa ordem.

Neste exemplo, os conteúdos irão ser lidos pela seguinte ordem: cabeçalho, links de menu, conteúdos, rodapé. Se não houverem demasiados níveis e sub-níveis e se o conteúdo se mantiver legível seguindo a ordem do HTML, nãoe xistem grandes problemas de acessibilidade.

Hoje em dia, as tabelas ainda são usadas para criar o layout de newsletters, de modo a serem compatíveis com todos os clientes de Mail existentes, já que o suporte a CSS é bastante limitado.

Os screen-readers conseguem detetar automaticamente se uma tabela está a ser usada para criar um layout ou para mostrar dados tabulares procurando por identificadores específicos nas tabelas. Assim, se forem usadas tabelas para criar layouts, não se deve usar de forma alguma elementos como <caption> ou <th>, pois pode fazer com que os conteúdos da tabela sejam confundidos com dados tabulares e o comportamento do screen-reader irá mudar e tornar a navegação extremamente confusa.

Usar os cabeçalhos corretamente

A existência de cabeçalhos na tabelas são o que normalmente identifica que os seus conteúdos são dados tabulares. Servem essencialmente para dar um título aos conteúdos que vão aparecer na linha ou coluna correspondente.

Uma tabela sem cabeçalhos é simplesmente uma lista de células com conteúdos lá dentro e que irão ser lidas linha a linha, da esquerda para a direita.

Empresa Nº Trabalhadores Data de Fundação
Apple, Inc. 98000 1976
Google, Inc. 55000 1997

No exemplo acima, um screen-reader irá ler a tabela da seguinte forma:

Empresa, Nº Trabalhadores, Data de Fundação, Apple, Inc., 98000, 1976, Google, Inc., 55000, 1997

Quanto mais linhas tivesse a tabela, mais confusa seria a leitura da mesma, pois apenas iriamos ouvir o nome de uma empresa seguida de dois números, sem qualquer indicação dobre a que se referem esses números.

O uso de cabeçalhos permite que a tabela passe a comportar-se de maneira diferente. Basta substituir os <td> das células que servem de título por <th> para que os conteúdos comecem a fazer mais sentido.

<table>
	<tr>
		<th>Empresa</th>
		<th>Nº Trabalhadores</th>
		<th>Data de Fundação</th>
	</tr>
	<tr>
		<td>Apple, Inc.</td>
		<td>98000</td>
		<td>1976</td>
	</tr>
	<tr>
		<td>Google, Inc.</td>
		<td>55000</td>
		<td>1997</td>
	</tr>
</table>

Como se pode ver no exemplo em baixo, visualmente (com a ajuda de alguns estilos CSS) a tabela já começa a fazer mais sentido.

Empresa Nº Trabalhadores Data de Fundação
Apple, Inc. 98000 1976
Google, Inc. 55000 1997

E para os utilizadores que dependem de um screen reader, já deverão ouvir os conteúdos da tabela da seguinte maneira:

Empresa: Apple, Inc., Nº Trabalhadores: 98000, Data de Fundação: 1976,
Empresa: Google, Inc., Nº Trabalhadores: 55000, Data de Fundação: 1997

Encurtar os cabeçalhos

Como vimos em cima, um screen-reader irá ler o cabeçalho de cada coluna antes do valor de cada célula. Se os títulos forem demasiado longos, estar a ouvir repetidamente a mesma coisas pode tornar-se aborrecido.

Podemos usar o atributo abbr para fornecer uma versão abreviada dos cabeçalhos, que será lida em vez do texto comprido.

O exemplo seguinte foi modificado de propósito para tornar os cabeçalhos mais longos. O atributo abbr poderá ser usado da seguinte forma:

<table>
	<tr>
		<th abbr="Empresa">Nome da Empresa</th>
		<th abbr="Nº Trabalhadores">Número de Trabalhadores</th>
		<th abbr="Fundação">Data de Fundação</th>
	</tr>
	...
</table>

Apesar de ser possível adicionar estas abreviaturas, recomendamos que os cabeçalhos devam ser o mais curtos possível. Assim, em vez de usar o abbr para abreviar um cabeçalho longo, devemos tentar fazer o contrário, ou seja, usar o atributo title para dar uma descrição mais longa a um cabeçalho curto.

Adicionar títulos ou legendas às tabelas

Para dar algum contexto à tabela, pode ser usado o elemento <caption> com uma pequena descrição da tabela. Quando usado, o elemento <caption> tem de ser colocado imediatamente após a abertura da tag <table>:

<table>
	<caption>Tabela 1: Informação sobre as empresas</caption>
	<tr>
		<th>Empresa</th>
		<th>Nº Trabalhadores</th>
		<th>Data de Fundação</th>
	</tr>
	...
</table>
Tabela 1: Informação sobre as empresas
Empresa Nº Trabalhadores Data de Fundação
Apple, Inc. 98000 1976
Google, Inc. 55000 1997

Os conteúdos dentro do elemento <caption> ficarão visíveis para todos os utilizadores. No entanto, podemos adicionar um resumo mais detalhado da tabela apenas para screen-readers usando o atributo summary.

<table summary="O número de trabalhadores e ano de fundação de algumas empresas tecnológicas">
	<caption>Tabela 1: Informação sobre as empresas</caption>
	<tr>
		<th>Empresa</th>
		<th>Nº Trabalhadores</th>
		<th>Data de Fundação</th>
	</tr>
	...
</table>

Associar os cabeçalhos às linhas ou colunas correspondentes

Para tabelas mais complexas, em que por exemplo temos cabeçalhos de colunas em conjunto com cabeçalhos de linhas, torna-se necessário associar corretamente os conteúdos aos respetivos cabeçalhos.

No exemplo em baixo, podemos ver que agora os nomes das empresas passaram a ser também cabeçalhos, mas são cabeçalhos de cada linha e não da coluna.

Tabela 1: Informação sobre as empresas
  Nº Trabalhadores Data de Fundação
Apple, Inc. 98000 1976
Google, Inc. 55000 1997

Para que a informação faça sentido para os utilizadores que não conseguem visualizar a tabela, é preciso definir o âmbito de cada cabeçalho através do atributo scope. Assim, podemos indicar que cada cabeçalho é o título da coluna (scope="col") ou da linha (scope="row") em que estiver inserido.

A estrutura da tabela deverá ser a seguinte:

<table summary="O número de trabalhadores e ano de fundação de algumas empresas tecnológicas">
	<caption>Tabela 1: Informação sobre as empresas</caption>
	<tr>
		<td></td>
		<th scope="col">Nº Trabalhadores</th>
		<th scope="col">Data de Fundação</th>
	</tr>
	<tr>
		<th scope="row">Apple, Inc.</th>
		<td>98000</td>
		<td>1976</td>
	</tr>
	<tr>
		<th scope="row">Google, Inc.</th>
		<td>55000</td>
		<td>1997</td>
	</tr>
</table>

Se quisermos manter o título da coluna em cima do nome das empresas, então devemos voltar a usar <td> para as células com o nome das empresas, mas podemos adicionar na mesma o atributo scope. O que não convém é ter uma célula de cabeçalho <th> que é título de outra <th>.

<table summary="O número de trabalhadores e ano de fundação de algumas empresas tecnológicas">
	<caption>Tabela 1: Informação sobre as empresas</caption>
	<tr>
		<th scope="row">Empresa</td>
		<th scope="col">Nº Trabalhadores</th>
		<th scope="col">Data de Fundação</th>
	</tr>
	<tr>
		<td scope="row">Apple, Inc.</td>
		<td>98000</td>
		<td>1976</td>
	</tr>
	<tr>
		<td scope="row">Google, Inc.</td>
		<td>55000</td>
		<td>1997</td>
	</tr>
</table>

Com um pouco de CSS, podemos usar a tag <strong> para que o nome das empresas também fique a bold, ou em alternativa, usar um seletor de CSS que o faça automaticamente para todas as <td> com scope:

td[scope] {
	font-weight:bold;
}
Tabela 1: Informação sobre as empresas
Empresa Nº Trabalhadores Data de Fundação
Apple, Inc. 98000 1976
Google, Inc. 55000 1997

Outra técnica que se pode usar é fazendo a ligação das células de conteúdos com os respetivos cabeçalhos, dando a cada cabeçalho um id único.

Depois, usando o atributo headers podemos definir uma lista de cabeçalhos que se aplicam ao conteúdo da célula. Esta técnica é bastante mais complicada de usar e apenas deve ser usada quando há células que precisam de estar associadas a mais do que um cabeçalho, e em que o atributo scope não é suficiente para desempenhar esa função.

Para ilustrar este tipo de casos, a tabela foi alterada para indicar o género sexual dos empregados de cada empresa:

<table>
	<caption>Tabela 1: Informação sobre as empresas</caption>
	<tr>
		<td rowspan="2"></td>
		<th id="trabalhadores" colspan="2">Trabalhadores</th>
		<th id="fundacao" rowspan="2">Data de Fundação</th>
	</tr>
	<tr>
		<th id="homens">Homens</th>
		<th id="mulheres">Mulheres</th>
	</tr>
	<tr>
		<th id="apple">Apple, Inc.</th>
		<td headers="apple trabalhadores homens">65000</td>
		<td headers="apple trabalhadores mulheres">33000</td>
		<td headers="apple funcadao">1976</td>
	</tr>
	<tr>
		<th id="google">Google, Inc.</th>
		<td headers="google trabalhadores homens">45000</td>
		<td headers="google trabalhadores mulheres">20000</td>
		<td headers="google funcadao">1997</td>
	</tr>
</table>
Tabela 1: Informação sobre as empresas
  Trabalhadores Data de Fundação
Homens Mulheres
Apple, Inc. 65000 33000 1976
Google, Inc. 45000 20000 1997

Estruturar a tabela em secções

Usando as tags <thead>, <tfoot> e <tbody> podemos dividir a estrutura da tabela em cabeçalho, rodapé e conteúdos, respetivamente.

As vantagens de fazer esta separação são, entre outras:

  • Torna mais fácil estilizar o cabeçalho, rodapé e a zona dos conteúdos da tabela de forma indepentende, sem ter de adicionar classes aos elementos;
  • Quando se imprimem tabelas longas, alguns browsers irão repetir a informação do cabeçalho e rodapé em todas as páginas impressas, tornando mais fácil a leitura da tabela em papel;
  • A separação do cabeçalho e rodapé dos conteúdos também torna possível que se possa fazer scroll apenas na zona dos conteudos, mantendo o cabeçalho e rodapé fixos.

Se uma tabela tiver uma secção <thead>, ela deve aparecer antes das secções <tfoot> e <tbody>. O rodapé <tfoot> também deve aparecer antes da secção dos conteúdos <tbody>.

Podem ser adicionadas várias secções independentes de conteúdos <tbody>:

<table>
	<thead>
		<tr>
			<!-- cabeçalho da tabela -->
		</tr>
	</thead>
	<tfoot>
		<tr>
			<!-- rodapé da tabela -->
		</tr>
	</tfoot>
	<tbody>
		<tr>
			<!-- primeira secção de conteúdo -->
		</tr>
	</tbody>
	<tbody>
		<tr>
			<!-- segunda secção de conteúdo -->
		</tr>
	</tbody>
</table>

Se não forem usadas as secções <thead> e <tfoot> então não é preciso usar o <tbody>, mas pode usar-se na mesma sem problemas.

Benefícios das tabelas acessíveis

Pode parecer que dá demasiado trabalho criar uma tabela acessível em HTML. Para tabelas complexas sim, é verdade que vai dar muito trabalho. No entanto, para tabelas simples, o uso de células com o atributo scope é suficiente e é fácil e rápido de implementar.

É óbvio que as pessoas que mais irão beneficiar das tabelas acessíveis são os utilizadores com screen readers e outros dispositivos assistivos. No entanto, tentar fazer sentido de uma tabela altamente complexa, por muito acessível que ela seja, continua a ser um desafio. Por isso, sempre que possível, devemos tentar simplificar as tabelas que disponibilizamos na web.

Um outro benefício menos óbvio das tabelas acessíveis é que os web designers passam a ter muitos mais elementos sobre os quais podem aplicar estilos CSS, e uma tabela bem desenhada pode tornar-se também mais fácil de ler para todos os utilizadores, e não apenas para os que têm necessidades especiais.

Referências

Formulários

Os formulários são a principal forma de interação dos utilizadores com um website e também o local onde normalmente ocorrem os principais problemas de interação.

Para utilizadores com necessidades especiais, torna-se ainda mais crítico que os formulários possam ser preenchidos de forma simples e sem complicações.

Assim, os campos de preenchimento devem ser óbvios sobre o que é pretendido que o utilizador preencha, e devem fornecer mecanismos que facilitem a sua utilização (como por exemplo o aumento da área clicável de uma checkbox ou radio-button).

Atribuir "labels" a cada elemento dos formulários

Todos os elementos (campos) dos formulários devem ter uma <label> associada. O uso de labels permite aumentar a área clicável do elemento incluindo também a sua legenda, ex:

Tamanho da zona clicável com e sem label

Existem duas formas de associar uma label a um determinado campo de preenchimento. A primeira é adicionar o atributo for e fazê-lo corresponder ao id do campo:

<p>
	<input type="checkbox" name="compras" value="leite" id="leite" />
	<label for="leite">Leite</label>
</p>

A segunda forma de associar uma label a um campo é fazer com que o campo de preenchimento esteja dentro das tags da label:

<p>
	<label><input type="checkbox" name="compras" value="leite" /> Leite</label>
</p>

Com CSS podemos dar um feedback adicional quando o utilizador passa com o rato por cima do texto da label. Por exemplo, podemos mudar o cursor para dar o aspeto de que o item é clicável ao passar com o rato por cima:

label:hover { 
	cursor: pointer; 
}

Uma label para múltiplos campos?

Podem também haver casos em que alguns campos não têm legenda e como tal não vão ter uma label associada. Nestes casos, o campo em si deve ter o atributo title definido, como por exemplo:

Dois campos, uma label

<p>
	<label for="horas">Horário de abertura</label>
	<input type="text" name="horas" id="horas" title="horas" /> :
	<input type="text" name="minutos" title="minutos" />
</p>

Permitir que o submit dos formulários seja feito apenas com HTML

O submit dos formulários deve ser feito exclusivamente com HTML. Isto significa que não deve ser usado código JavaScript do tipo "submit()" ou "onClick()" para que os formulários enviem os dados preenchidos pelo utilizador. Assim, o submit deve ser sempre feito através de um botão/input e nunca através de um link. Ex:

<input type="submit" value="Gravar Alterações" />

ou:

<button type="submit">Gravar Alterações</button>

A vantagem do uso da tag <button> é que permite incluir qualquer elemento dentro do botão, incluindo imagens ou ícones (ex: Font Awesome):

<button type="submit">
    <span class="fa fa-save"></span> Gravar Alterações 
</button>

Isto não invalida que não se possa usar JavaScript para fazer validações dos dados introduzidos pelo utilizador de modo a dar as mensagens de erro/sucesso correspondentes, mas é necessário garantir que se o JavaScript estiver desativado, o formulário é enviado e os erros são detetados e mostrados no formulário via server-side.

Agrupar elementos relacionados

Quando temos formulários extensos pode ser uma boa ideia agrupar vários campos em blocos separados. Isto pode ser feito usando a tag <fieldset> para agrupar um conjunto de campos. Por cada grupo é ainda possível adicionar um título usando a tag <legend>.

Estes agrupamentos permitem melhorar a leitura do formulário tanto para utilizadores "normais" (caso se usem os separadores entre <fieldsets>) como para utilizadores que usam screen-readers. No exemplo seguinte, o uso de um grupo permite facilitar a forma como o screen-reader interpreta o formulário.

<fieldset>
    <legend>Filtrar por:</legend>
    <label for="a"><input type="radio" name="filter" id="a"> Televisão</label>
    <label for="b"><input type="radio" name="filter" id="b"> Rádio</label>
</fieldset>

O que o screen-reader lê neste caso é: "Filtrar por: radio-button Televisão, radio-button Rádio"; ou então (dependendo do sistema usado): "Filtrar por Televisão; Filtrar por Rádio".

Usar tabindex para guiar a navegação com o teclado no formulário

Deve-se usar o atributo tabindex para guiar os utilizadores no preenchimento de um formulário.

Tipicamente, quando se está a preencher um formulário, é normal os utilizadores saltarem entre campos usando a tecla TAB. Podemos aproveitar esse comportamento para guiar corretamente os utilizadores para os campos certos no formulário caso estes não sigam a mesma ordem no HTML.

Por exemplo, podemos guiar os utilizadores neste formulário (cujos campos não aparecem no HTML pela ordem correta) indicando a ordem pela qual os campos devem ser preenchidos:

<form>
	<p><label>Nome: <input type="text" tabindex="1"/></label></p>
	<p><label>E-mail: <input type="email" tabindex="2"/></label></p>
	<p><button type="submit" tabindex="4">Entrar</button></p>
	<p><label><input type="checkbox" tabindex="3"/> Lembrar-se de mim</label></p>
</form>

Valores "0" e "-1"

O tabindex="0" e tabindex="-1" funcionam de forma diferente e têm um significado distinto dos restantes tabindex.

O tabindex="0" permite que um elemento que normalmente não seria navegável com o teclado, como por exemplo uma <div tabindex="0"> possa receber foco durante a navegação sem que seja um link ou um botão.

O tabindex="-1" serve para remover um item da navegação, ou seja, irá ser ignorado na navegação com o teclado e o foco passará para o item seguinte. Uma vez que isto remove o item da navegação, deve evitar-se usar esta regra em elementos importantes da navegação ou campos importantes do preenchimento de um formulário.

Referências

  1. Keyboard accessibility: tabindex
  2. Fieldsets, lewgends and accessibility

Mais dicas e recomendações

Uma vez que as regras de usabilidade e acessibilidade contemplam muitos pontos em comum, além das dicas e recomendações acima, devem também ser aplicadas as recomendaçoes de usabilidade para formulários disponiveis na secção Usabilidade do SAPO UX.

Cores e Contrastes

O uso da cor é um dos principais problemas de acessibilidade que acabam por passar despercebidos quando se está a fazer o design de um website.

O problema é que nem todas as pessoas percebem a cor da mesma maneira, e como tal, o uso exclusivo da cor para passar uma mensagem por vezes pode tornar essa mensagem ambígua.

É também preciso ter em conta o contraste entre a cor dos textos e a cor de fundo, pois nem todas as cores combinam bem nem permitem uma legibilidade a 100% dos conteúdos.

Não confiar apenas na cor para fornecer informação

Devemo-nos assegurar que todas as informações fornecidas através de um código de cores podem ser visualizadas sem o uso da cor.

Nunca se deve usar apenas a cor como único meio de indicar atividades críticas. Cerca de 8% das pessoas de sexo masculino e 0.5% do sexo feminino têm dificuldades em distinguir as cores. A maior parte tem dificuldades em ver as cores no espetro verde.

Comparação de mensagens de sucesso e erro vistas por um utilizador com visão normal (à esquerda) e um com Deuteranopia, a forma mais comum de daltonismo (à direita).

Para assegurar que a informação é visível por todos os utilizadores:

  • Escolher combinações de cores que possam ser distinguíveis por utilizadores daltónicos (existem aplicações que permitem simular como um daltónico vê as cores, ex: Color Oracle);
  • Assegurar que existe um contraste suficiente entre o texto e a cor de fundo;
  • Usar ícones representativos das ações ou das informações (ex: uma mensagem de erro pode vir acompanhada de um ícone correspondente em vez de vir apenas com texto a vermelho);
  • Acompanhar sempre a cor de padrões, ícones ou legendas de modo a que a informação possa ser percebida caso a cor se confunda com outra cor.

Exemplo do uso de padrões e texturas como segunda forma (além da cor) de diferenciar cada item no gráfico.

Verificar o contraste entre os textos e a cor de fundo

A cor usada nos textos deve fazer um contraste suficiente com a cor de fundo para garantir uma boa legibilidade. Um mau contraste entre as duas cores pode tornar os textos ilegíveis para uma boa fatia da população, mesmo para pessoas com visão "normal".

Vários exemplos de combinações de cores de texto e fundo sem contraste suficiente.

As recomendações WCAG 2.0 indicam valores de contraste diferentes para textos com menos de 18px e para textos com mais de 18px (ou textos a negrito com mais de 14px). Assim, para passar no teste mínimo de acessibilidade (AA), deve haver um rácio de contraste de pelo menos 4.5:1, e em textos maiores do que 18px esse valor deve ser de pelo menos 3:1.

Na prática, podemos usar sistemas que calculam automaticamente o contraste entre duas cores e nos indicam se passa ou não no teste de acessibilidade:

Exemplo de cálculo do rácio de contraste entre um fundo branco e dois tons de cinza.


Evitar elementos que piscam ou mudam de cores rapidamente

Não usar elementos que façam a página piscar ou mudar de cor em frequências superiores a 2Hz e inferiores a 55Hz (1Hz = 1 rotação/oscilação/imagem por segundo). Ou seja, não usar nada que "pisque" mais do que 3 vezes por segundo.

Cinco por cento dos epiléticos são foto-sensíveis e podem ter ataques causados por determinadas frequências de elementos a piscar.

Se for inevitável o uso destes elementos que piscam, deve-se avisar o utilizador antes de mostrar esse elemento com uma mensagem do género: "AVISO: Este link abre uma página que contém elementos que piscam e como tal não deve ser visualizada por pessoas com epilepsia fotossensível".

Referências

Semântica

WAI-ARIA