HTML
Conteúdo deste capítulo:
Introdução
A linguagem de marcação de hipertexto, ou HTML do inglês HyperText Markup Language, é uma linguagem do World Wide Web Consortium (W3C) que "visa a preparação de documentos com gráficos e hiperligações, para visualização na World Wide Web (WWW) ou em sistemas compatíveis" (Glossário para a SI 2011, APDSI).
Em 1997, o W3C criou a Web Accessibility Initiative (WAI). Incorporar nas suas linguagens os princípios do Design for All de forma a possibilitar a produção de conteúdos digitais acessíveis a pessoas com incapacidades é um dos objetivos da WAI. Fruto desse trabalho, em 1999 o W3C publicou uma das suas recomendações finais na área da produção de conteúdos acessíveis a que deu o nome de Web Content Accessibility Guidelines (WCAG). Esta mesma recomendação foi atualizada para a sua versão 2.0 em dezembro de 2008, a qual corresponde à versão em vigor à data da redação dos presentes tutoriais. Se desejar, pode consultar a versão 2.0, em português, das Diretrizes de Acessibilidade para o Conteúdo da Web.
Apesar da leitura dos presentes tutoriais se destinar a um público especialista, com conhecimento das linguagens de marcação de conteúdos, a redação dos mesmos foi feita de forma a poderem ser facilmente apreendidos por um público que agora se inicia nestas matérias.
Para quem se inicia, mas também para os que já são especialistas, é sempre bom recordar a "morfologia" de uma página HTML.
Recorrendo a um desenho que já todos fizemos quando éramos crianças – e que nós continuamos a fazer - do boneco com uma cabeça redonda e mais meia dúzia de riscos para representar o tronco e os membros (ver figura seguinte), não ficamos com uma representação tão perfeita das proporções do Homem quanto a conseguida por Leonardo Da Vinci, mas com um boneco que representa um ser com uma cabeça, um corpo e neste uns quantos membros, entenda-se, por estes últimos, tronco, braços, mãos, pernas e pés.
Uma página HTML é também ela um "objeto" que obedece a uma estrutura bastante semelhante a este "ser". Também ela tem uma cabeça, com início <head> e fim </head>, um corpo, delimitado pelas tags <body> e </body> e este é composto por vários elementos. Em vez de tronco, pernas, mãos, braços temos cabeçalhos (<h1>, <h2>, ..., <h6>), parágrafos (<p>), listas (<ul>), tabelas de dados (<table>), e mais uns quantos outros elementos. Tal como num ser humano, que é possível delimitar, ou seja observar onde começa e onde acaba, também o início e o fim de uma página Web se encontram delimitados: o seu início com <html> e o seu fim com </html>.
Figura 36 - Estrutura base de uma página HTML
Se criar uma nova página Web num editor de HTML, por exemplo no Adobe Dreamweaver, o código que vai aparecer é exatamente uma estrutura do tipo:
<html>
<head>
<title>Título da página</title>
</head>
<body>
( .... conteúdo da página .... )
</body>
</html>
De notar que um "ser" tem sempre uma cabeça e um corpo. Nem mais, nem menos. Este mesmo princípio deve ser adotado para definir uma página HTML. A nossa experiência mostra-nos que esta regra é frequentemente violada pelos profissionais Web, o que causa, por vezes, alguns problemas de interpretação por parte dos diversos agentes de utilizador (browsers e tecnologias de apoio incluidos).
Elementos HTML
Estrutura de cabeçalho
A correta estrutura dos documentos é um dos aspetos fundamentais em acessibilidade. A estruturação dos cabeçalhos é um desses elementos. Hoje em dia praticamente ninguém lê uma página Web na íntegra. Geralmente saltamos blocos de informação à procura de palavras que respondam à ou às perguntas que temos em mente e que nos levaram a consultar aquela página. Os cabeçalhos são um excelente auxiliar para efetuarmos rapidamente estes saltos na informação e que nos dão, geralmente pelo tamanho de letra usada, a importância relativa dos diversos blocos de informação. Também para quem usa tecnologias de apoio, os cabeçalhos permitem saltar blocos de informação, em busca do mais relevante para o utilizador. Mas as tecnologias em geral, e as de apoio em particular, não medem a importância da informação pelo seu aspeto gráfico mas pela forma como a informação está marcada. Para que uma tecnologia possa identificar um texto como sendo um cabeçalho é preciso que o mesmo esteja devidamente marcado.
Como marcar um cabeçalho em HTML?
Imagine que tem uma página com o título "Diretrizes de Acessibilidade para o Conteúdo da Web" e que pretendia marcá-lo como cabeçalho.
Em HTML bastaria colocar:
Quantos níveis hierárquicos estão disponíveis em HTML e qual a lógica de marcação?
No HTML estão disponíveis 6 níveis de cabeçalho assim identificados h1, h2, h3, h4, h5, h6. Visualmente o seu grau de importância é distinguível através do tamanho de letra que lhe está associada, sendo o h1 o mais importante.
A lógica de marcação de cabeçalhos em HTML deve obedecer aos seguintes princípios:
- Por página deve existir apenas um cabeçalho h1, o qual deve marcar o texto que identifica o título da página;
- O h2 marca os blocos de informação que podemos identificar como sendo as secções principais da página. Logicamente podem existir vários textos marcados com h2;
- O h3 marca os títulos dos sub-blocos de informação ou subsecções. A marcação de uma subsecção pressupõe a existência de uma secção à qual aquela pertence. Assim, um cabeçalho h3 pressupõe a existência de um cabeçalho h2 ao qual aquele pertence e com o qual se encontra encadeado;
- Os cabeçalhos h4, h5 e h6 têm exatamente a mesma natureza do h3 e marcam títulos de blocos de informação hierarquicamente encadeados; marcar um título de um bloco de informação com h4 sem existir um título h3 não é aconselhável;
Qual o resultado final pretendido?
Esta estrutura de cabeçalhos dá ao utilizador um mecanismo que lhe permite, por um lado, compreender a forma como a informação está relacionada, e por outro, saltar rapidamente pelo documento.
Como posso verificar o resultado na minha página?
Ao validar a sua página no Validador de (X)HTML do W3C e ativar a opção Show Outline, vai encontrar no final do relatório um índice construído automaticamente a partir da marcação de cabeçalhos que se encontram na página. Verifique se ele responde corretamente ao índice que deseja fornecer.
Descrição de gráficos
Quando se fala em equivalentes textuais para as imagens referimo-nos, na maioria das vezes, a dois tipos: uma necessidade de legendar a imagem e uma necessidade de descrever a imagem. A regra costuma ser: todas as imagens precisam de uma legenda e algumas, porque transmitem muita informação, impossível de conter numa legenda que se pretende concisa, precisam de uma descrição.
Em HTML existem formas de marcar estas duas realidades. A parte difícil é responder às perguntas: qual a legenda mais adequada para a imagem? qual a descrição mais adequada para a imagem? No caso dos gráficos que transmitem visualmente dados, colocam-se, em simultâneo, ambas as questões, uma vez que é vulgar não ser possível sintetizar os dados do gráfico apenas usando a legenda. No presente tutorial de HTML, não vamos discutir a resposta àquelas duas perguntas (para isso, veja o capítulo Microsoft Word - Imagens/elementos gráficos) mas a técnica HTML que permite colocar a legenda e, principalmente, a descrição longa.
Figura 37 - Avaliação automática à acessibilidade dos conteúdos Web da AP Portuguesa Central. Média do índice web@X - web at eXaminator por Ministério ( 0%-100%)
Na figura anterior apresenta-se o exemplo de um gráfico do tipo radar. Como se pode observar, a informação apresentada é demasiado densa para ser sintetizada apenas numa legenda concisa (algo em redor de 100 carateres).
Como fazer a descrição do gráfico?
Uma vez que a legenda a colocar também depende da técnica a usar para colocar a descrição, vamos primeiro pensar nas técnicas possíveis para posicionar esta última.
Podemos, pelo menos, recorrer a três técnicas possíveis:
- Colocar a descrição do gráfico incorporada no próprio texto;
<img src="grafico.png" width="686" height="375" alt="Gráfico radar com a média do índice webax (0% - 100%) por Ministério [consulte a tabela de dados que se encontra a seguir]" />
A legenda foi colocada no atributo alt do elemento <img>. Atente na chamada de atenção, na legenda, para o posicionamento do equivalente alternativo do gráfico.
- Colocar a descrição do gráfico numa página à parte, fazendo da própria imagem que comporta o gráfico um link para essa página;
<a href="grafico_descricao.html">
<img src="grafico.png" width="686" height="375" alt="Gráfico radar com a média do índice webax (0% - 100%) por Ministério [contém link para a sua descrição]" />
</a>Neste caso, a página grafico_descricao.html contém a descrição longa da imagem e a legenda foi corrigida, face à primeira técnica, para alertar o utilizador para o facto da própria imagem ser um link para a sua própria descrição.
- Colocar um link [D] ao lado da imagem.
<img src="grafico.png" width="686" height="375" longdesc="grafico_descricao.html" alt="Gráfico radar com a média do índice webax (0% - 100%) por Ministério [a descrição encontra-se no link D que se segue]" /> [<a href="grafico_descricao.html" title="Contém descrição longa do gráfico radar com a média do índice webax por Ministério">D</a>]
De notar que nesta técnica, à semelhança das duas técnicas anteriores, corrigimos a legenda para refletir a nova posição da descrição longa; adicionámos o atributo longdesc cujo conteúdo é a página grafico_descricao.html, o qual é interpretado por poucos agentes de utilizador (leia-se nomeadamente browsers) e que por isso obriga a uma colocação redundante, a qual, o W3C recomenda que seja posicionada num link D, ao lado da imagem.
Conteúdo da página grafico_descricao.html
O melhor equivalente textual para um gráfico de dados é fornecer a tabela de dados que lhe deu origem. Assim, no exemplo da figura 37 teremos, em HTML:
<h1>Descrição do Gráfico com a Média do índice webax (0% - 100%) por Ministério</h1>
<p>A tabela que se segue contém a média do índice webax de uma recolha efectuada com o validador automático eXaminator a 351 sítios, num total de 42010 páginas, de organismos da Administração Pública Portuguesa Central. A média do índice webax, no total dos organismos pertencentes aos 14 Ministérios mais os organismos sob tutela da Presidência do Conselho de Ministros, é de 58%.</p>
<table summary="O MCTES pode ser considerado o motor da AP em termos de acessibilidade ao obter uma média de 86,3%, bastante superior à média de 58%">
<caption>Média do índice webax, convertido em %, por Ministério da AP Portuguesa Central</caption>
<tr>
<th>Ministério</th>
<th>Média webax (%)</th>
</tr>
<tr>
<td>001 MAI - Ministério da Administração Interna</td>
<td>57,1%</td>
</tr>
<tr>
<td>002 - MADRP - Ministério da Agricultura, Desenvolvimento Rural e Pescas</td>
<td>56,6%</td>
</tr>
<tr>
<td>003 - MCTES - Ministério da Ciência, Tecnologia e Ensino Superior</td>
<td>86,7%</td>
</tr>
<tr>
<td>004 - MC - Ministério da Cultura</td>
<td>50,7%</td>
</tr>
<tr>
<td>005 - MDN - Ministério da Defesa Nacional</td>
<td>50,5%</td>
</tr>
<tr>
<td>006 - MEID - Ministério da Economia, Inovação e Desenvolvimento</td>
<td>45,8%</td>
</tr>
<tr>
<td>007 - ME - Ministério da Educação</td>
<td>59,8%</td>
</tr>
<tr>
<td>008 - MJ - Ministério da Justiça</td>
<td>59,2%</td>
</tr>
<tr>
<td>009 - MS - Ministério da Saúde</td>
<td>54,4%</td>
</tr>
<tr>
<td>010 - MFAP - Ministério das Finanças e da Administração Pública</td>
<td>54,7%</td>
</tr>
<tr>
<td>011 - MOPTC - Ministério das Obras Públicas, Transportes e Comunicações</td>
<td>57,9%</td>
</tr>
<tr>
<td>012 - MAOTDR - Ministério do Ambiente, Ordenamento do Território e Desenvolvimento Regional</td>
<td>53,7%</td>
</tr>
<tr>
<td>013 - MTS - Miinistério do Trabalho e da Solidariedade</td>
<td>63,4%</td>
</tr>
<tr>
<td>014 - MNE - Ministério dos Negócios Estrangeiros</td>
<td>61,4%</td>
</tr>
<tr>
<td>015 - PCM - Presidência do Conselho de Ministros</td>
<td>62,8%</td>
</tr>
</table>
<p>Fonte: UMIC, IP, maio de 2011</p>
Marcação de cabeçalhos numa tabela de dados
Em 1994 o HTML viu introduzido mais um elemento que, rapidamente, se tornaria popular entre os desenvolvedores Web, embora pelos piores motivos: tem sido aplicado de forma errada.
Trata-se do elemento <table>, criado originalmente para estruturar dados tabulares, como horários, tabelas de preços, tabelas de dados demográficos, de temperaturas, etc.
A facilidade com que permite a arrumação de objetos gráficos e/ou textuais numa página, levou a que os Web designers passassem a usá-lo como uma forma simples e prática de produzirem os seus templates: as tabelas passaram a ser usadas como forma de estruturar o layout de páginas em vez de estruturarem dados, contrariando o objetivo inicial que levou à sua criação.
Ainda hoje a esmagadora maioria dos sites usa, contrariamente ao preconizado pelo W3C, tabelas para organizar links, imagens, texto, menus, botões, caixas de edição, etc.
Em lugar de se usarem tabelas para controlar a apresentação e o layout da página, devem usar-se folhas de estilo (CSS). Esta técnica, sendo a correta, tem o inconveniente de ser aparentemente mais complexa, levando a que, por uma tendência natural, se opte pelo mais fácil!
Por esse motivo não abordaremos a acessibilidade na utilização de tabelas para controlo do layout, porque não é uma boa prática, mas sim no uso destas para estruturar dados.
Para um utilizador sem problemas de visão, a informação estruturada de forma tabular resulta mais inteligível: mais fácil percecionar a relação entre os dados; mais rápido pesquisar e aceder aos dados.
Se tomarmos como exemplo uma tabela simples com os horários de partida de uma estação de comboios, verificamos que é fácil, a partir do cruzamento das linhas e colunas, saber a que horas parte o nosso comboio. Se complicarmos a tabela, adicionando mais informação como, a hora de chegada ao destino, a linha de partida, o horário de fim de semana, etc., embora tenha mais informação, continua a ser, graças à forma aleatória como o utilizador acede à informação, completamente inteligível.
Para os utilizadores com deficiência da visão, que percorrem uma página Web de forma sequencial, linearizada pelo leitor de ecrã, a leitura de uma tabela pode ser um exercício complexo, demorado e, acima de tudo, de resultados erráticos.
Felizmente que os leitores de ecrã atuais possibilitam uma leitura seletiva e inteligente das tabelas. Assim, para além da leitura da tabela como um todo, é possível ler linha a linha, sendo identificada a coluna de cabeçalho e lido o conteúdo da célula. Numa célula é possível ler o cabeçalho da coluna e linha correspondente, bem como aceder ao seu conteúdo.
No entanto, para que isto funcione é necessário que a tabela esteja corretamente construída.
O objetivo da técnica de marcação de cabeçalhos é preservar as relações nas informações, mesmo quando os utilizadores não conseguem ver a tabela ou o formato de apresentação tiver sido alterado. As informações são consideradas como dispostas em tabelas quando existem relações lógicas a duas dimensões (vertical e horizontal) entre texto, números, imagens ou outros dados.
As relações são representadas em colunas e linhas, e estas têm de ser reconhecíveis por ordem, para que as relações lógicas sejam percebidas.
Em tabelas de dados, devem identificar-se os cabeçalhos de linha e de coluna (Prioridade 1). Por exemplo, em HTML, utilizar <td> para identificar as células de dados e <th> para identificar os cabeçalhos.
Recomendações para a acessibilidade do conteúdo da Web - Ponto de verificação 5.1: A utilização do elemento <table> com os elementos subordinados <tr>, <th> e <td> torna estas relações percetíveis.
As técnicas, tais como inserir separadores para criar colunas ou utilizar o elemento <pre>, são meramente visuais, e as relações lógicas visualmente implícitas são perdidas se o utilizador não puder ver a tabela ou a apresentação visual tiver sido alterada.
Alguns exemplos errados
Neste primeiro exemplo, embora o efeito visual seja tabular, não existe nenhuma tabela, tendo a informação sido construída com base em espaços e alinhamento entre linhas. As relações lógicas visualmente implícitas são perdidas.
<pre>
Destino H/partida H/chegada Linha
Aveiro 10:05 10:35 4
Coimbra 10:15 11:10 1
Viana 10:42 11:45 1
</pre>
O leitor de ecrã lerá a pretensa tabela da seguinte forma:
Neste segundo exemplo, embora tenha sido construída uma tabela, a sua estrutura está incorreta. O único elemento de marcação é o identificador de célula (<td>) não existindo distinção entre as células de cabeçalho e as células de dados.
<p>Horário das ligações para o dia de hoje</p>
<table>
<tr>
<td>Destino</td>
<td>H/partida</td>
<td>H/chegada</td>
<td>Linha</td>
</tr>
<tr>
<td>Aveiro</td>
<td>10:05</td>
<td>10:35</td>
<td>4</td>
</tr>
<tr>
<td>Coimbra</td>
<td>10:15</td>
<td>11:10</td>
<td>1</td>
</tr>
...
</table>
O leitor de ecrã fará a seguinte interpretação:
Destino
H/partida
H/chegada
Linha
Aveiro
10:05
10:35
4
Coimbra
10:15
11:10
1
table end
Embora neste terceiro exemplo as células de cabeçalho se diferenciem visualmente das células de dados, o problema de estrutura continua, tal como no segundo exemplo, uma vez que o efeito visual é obtido através da utilização de elementos de estilo (alinhamento ao centro e negrito).
<p align="center">Horário das ligações para o dia de hoje</p>
<table cellSpacing="3px" border="1" width="700px">
<tr>
<td align="center"><b>Destino</b></td>
<td align="center"><b>H/partida</b></td>
<td align="center"><b>H/chegada</b></td>
<td align="center"><b>Linha</b></td>
</tr>
<tr>
<td>Aveiro</td>
<td>10:05</td>
<td>10:35</td>
<td>4</td>
</tr>
<tr>
<td>Coimbra</td>
<td>10:15</td>
<td>11:10</td>
<td>1</td>
</tr>
...
</table>
Em nenhum dos exemplos o leitor de ecrã conseguirá fazer uma leitura lógica.
Neste último exemplo, sendo uma tabela simples, as dificuldades de leitura não seriam muito percetíveis, no entanto tudo se complicaria se fosse mais extensa, com mais informação, ou mais complexa, com linhas ou células unidas.
Como tornar uma tabela acessível?
Pegando no terceiro exemplo, retiraremos os estilos e ficamos apenas com a estrutura da tabela. Os estilos, alinhamento, dimensões da tabela, negritos, etc, serão tratados através da utilização de uma folha de estilos (CSS).
Marcação de cabeçalhos
A marcação consiste na substituição das células <td> por <th> usadas como cabeçalho.
Assim, a tabela do exemplo 3 fica:
<!-- Linha com as células de cabeçalho -->
<tr>
<th>Destino</th>
<th>H/partida</th>
<th>H/chegada</th>
<th>Linha</th>
</tr>
<!-- Linhas com as células de dados -->
<tr>
<td>Aveiro</td>
<td>10:05</td>
<td>10:35</td>
<td>4</td>
</tr>
<tr>
<td>Coimbra</td>
<td>10:15</td>
<td>11:10</td>
<td>1</td>
</tr>
...
</table>
Embora se tenha retirado o alinhamento ao centro (align="center") e o negrito (<b>) o efeito visual é o mesmo que o do exemplo 3, uma vez que o cabeçalho (<th>) tem por defeito este mesmo estilo, ou seja centrado e negrito, pelo que, embora simplificando o código, não se perdeu nada.
Embora simples, esta marcação de cabeçalhos, possibilitará a muitas tecnologias de apoio conseguirem fazer corresponder de forma correta os dados existentes nas células de dados (<td>) com os respetivos cabeçalhos em coluna e em linha (<th>).
Associação de cabeçalhos a uma célula de dados
As linhas de uma tabela devem estar associadas aos seus respetivos cabeçalhos.
Os leitores de ecrã utilizam estas informações para indicar ao utilizador a que coluna a informação da célula pertence.
Com o HTML 4 foi introduzido o atributo headers para as células de tabelas <td>. Este atributo é usado em conjunto com o atributo id na célula de cabeçalho <th> com a finalidade de associar uma ou várias células aos seus respetivos cabeçalhos.
Exemplo de utilização do headers
Pegando na tabela com os horários dos comboios, tornámo-la um pouco mais complexa, adicionando uma célula de cabeçalho "Horário" que abarca duas colunas a "de partida" e a "de chegada".
<!-- Associação do cabeçalho <th> através do atributo "id" -->
<tr>
<th id="destino" rowspan="2">Destino</th>
<th id="horario" colspan="2">Horário</th>
<th id="linha" rowspan="2">Linha</th>
</tr>
<tr>
<th id="partida">de partida</th>
<th id="chegada">de chegada</th>
</tr>
<!-- à respetiva célula através do atributo "headers" -->
<tr>
<td headers="destino">Aveiro</td>
<td headers="horario partida">10:05</td>
<td headers="horario chegada">10:35</td>
<td headers="linha">4</td>
</tr>
<tr>
<td headers="destino">Coimbra</td>
<td headers="horario partida">10:15</td>
<td headers="horario chegada">11:10</td>
<td headers="linha">1</td>
</tr>
...
</table>
Este exemplo mostra como associar células de dados, criados com o elemento <td>, com os cabeçalhos correspondentes, através do atributo <headers="...">. Este atributo especifica uma lista de células, linhas e colunas, associadas com o conteúdo da célula. Para esta associação, é necessária a utilização do atributo <id="...">.
Melhorando a acessibilidade
Adicionando outros elementos de estrutura podemos melhorar a acessibilidade de uma tabela.
Atributo summary
Este atributo serve para clarificar a forma como os dados estão estruturados numa tabela. Particularmente útil em tabelas complexas. A informação contida não é visível pelos browsers.
Atributo caption
Este elemento fornece o título para a tabela.
Frequentemente este título é colocado fora da tabela numa tag separada, normalmente em elementos cabeçalho <h> ou parágrafo <p>. Nalguns casos o título é colocado dentro da tabela na linha superior <tr> ou mesmo numa célula <td>.
Em qualquer um dos casos, estas soluções trarão problemas aos utilizadores de tecnologias de apoio, sendo o uso do elemento <caption> o caminho mais apropriado para a acessibilidade a um título de tabela.
Para o browser, este título surge logo acima da tabela, centrado, no entanto, o seu estilo pode ser alterado recorrendo às CSS.
Veja-se, agora, a tabela completa:
<caption>Horário das ligações para o dia de hoje</caption>
<tr>
<th id="destino" rowspan="2">Destino</th>
<th id="horario" colspan="2">Horário</th>
<th id="linha" rowspan="2">Linha</th>
</tr>
<tr>
<th id="partida">de partida</th>
<th id="chegada">de chegada</th>
</tr>
<tr>
<td headers="destino">Aveiro</td>
<td headers="horario partida">10:05</td>
<td headers="horario chegada">10:35</td>
<td headers="linha">4</td>
</tr>
<tr>
<td headers="destino">Coimbra</td>
<td headers="horario partida">10:15</td>
<td headers="horario chegada">11:10</td>
<td headers="linha">1</td>
</tr>
...
</table>
A linearização que pode ser observada automaticamente no Tablin (um script que o W3C tem online para linearizar tabelas) fica com este aspeto:
Summary: Esta tabela fornece informação sobre os horários de partida, chegada ao destino e linha de embarque
Destino = Aveiro, Horário , de partida = 10:05, Horário , de chegada = 10:35, Linha = 4
Destino = Coimbra, Horário , de partida = 10:15, Horário , de chegada = 11:10, Linha = 1
O Tablin possibilita a análise do efeito da rotulagem de uma tabela, dando-nos a visão da mesma aos "olhos" de uma ajuda técnica, como é o caso de um leitor de ecrã (o Jaws, por exemplo). O Tablin lineariza a tabela e, recorrendo aos elementos de acessibilidade introduzidos, nomeadamente a identificação explícita dos cabeçalhos e a sua associação às diversas células de dados, para que a versão linear da tabela continue legível.
Associação de etiquetas a campos de edição (label)
Os formulários são a forma mais comum de interação do utilizador com uma página Web. Se é quase impossível criar um formulário inacessível, existem, no entanto, alguns cuidados que melhorarão a usabilidade e acessibilidade no preenchimento dos mesmos, tanto para utilizadores com pouca prática na utilização do rato, como para os que possuem deficiência motora ou visual.
Um desses cuidados consiste na associação da etiqueta (label) a um campo de edição.
A associação de uma etiqueta de texto ao campo de um formulário, permite que a ação de clicar com o botão esquerdo do rato sobre o texto seja equivalente à validação, seleção ou ação (no caso dos botões) que o próprio campo admite.
Para um utilizador com leitor de ecrã, ao colocar o foco no campo de formulário, será informado da sua finalidade. Pode ser também colocada informação adicional, como algum detalhe de preenchimento ou mesmo o facto de este ser obrigatório.
Assim, cada elemento label é ligado a um controlo de formulário específico através da utilização do atributo for. O valor deste atributo tem de ser igual ao valor do atributo id do controlo de formulário.
O atributo id tem de ter o mesmo valor do atributo name, ambos têm de ser fornecidos, e cada id tem de ser único na página Web.
Associação da etiqueta label:
<input type="text" name="nap" id="nap">
Indicação da obrigatoriedade de preenchimento:
<input type="text" name="nap" id="nap" />
O elemento label é usado com os elementos textarea, select e input de tipo "text", "checkbox", "radio", "file" e "password".
Não é usado nos seguintes elementos:
- button: o conteúdo funciona como etiqueta;
- input de tipo "image": usa-se o atributo alt como etiqueta;
- input de tipo "submit" e "reset": usa-se o atributo value como etiqueta;
- input de tipo "hidden": não se usa etiqueta.
A posição do elemento label é também importante para a correta associação entre este e o controlo de formulário. A label deve situar-se:
- Antes do controlo em elementos textarea, select e input de tipo "text", "file", "password";
<label for="text_1">Exemplo de campo de texto</label>
<input type="text" name="text_1" id="text_1" /> - Depois do controlo para elementos input de tipo "checkbox" e "radio".
<input type="checkbox" name="checkbox_1" id="checkbox_1" />
<label for="checkbox_1">Exemplo de label em checkbox</label>
Agregação de elementos de edição (fieldset)
Num formulário, ao existirem vários grupos de elementos relacionados entre si, cada conjunto deve estar agrupado dentro de um elemento fieldset.
Da mesma forma, cada elemento fieldset deve conter um elemento legend onde se inclui uma descrição do grupo de controlos de formulário.
Sempre que existirem grupos de controlos de formulário relacionados, deve-se seguir este método. Contudo, isto é especialmente importante para os grupos e controlos do tipo "radio" e "checkbox" (que possuam o mesmo valor no atributo name).
<legend>Extras adicionais</legend>
<input id="opt1" type="checkbox" name="extras" value="abs" />
<label for="opt1">Travagem antibloqueio</label>
<input id="opt2" type="checkbox" name="extras" value="jll" />
<label for="opt2">Jantes de liga leve</label>
<input id="opt3" type="checkbox" name="extras" value="tda" />
<label for="opt3">Teto de abrir</label>
</fieldset>
Para esta técnica ser eficiente recomenda-se evitar a criação excessiva de grupos de controlos de formulário. O elemento fieldset mostra por defeito uma linha que rodeia os controlos para se reconhecer o grupo visualmente. Com o recurso às CSS podemos modificar a apresentação, mas recomenda-se manter a agrupação visual dos elementos.
Se o formulário tiver poucos controlos, não há grupos de controlos, estando estes claramente identificados com o elemento label, então nesse caso não é necessário usar o fieldset.
Estilo
Associar estilo aos elementos HTML através do CSS
As Cascade Style Sheets, ou folhas de estilo em cascata são as que controlam a componente visual de uma página. Assim, tudo o que esteja relacionado com a visualização deve estar incluído nas CSS.
No entanto, as CSS não se limitam simplesmente a controlar a forma como os objetos HTML são modificados. Elas definem muitas vezes o padrão de acessibilidade de uma página.
As CSS são então uma ferramenta muito poderosa para ajudar e melhorar a acessibilidade de um determinado website. O conceito que está por detrás da sua utilização é simples: podem existir várias folhas de estilo atribuídas a uma só página. Estas funcionam como uma cascata onde todas as folhas de estilo estão encadeadas. Caso existam atributos diferentes para o mesmo elemento HTML, vai prevalecer o atributo que estiver na folha de estilo chamada mais tarde.
Nestas folhas de estilo vamos definir qual a dimensão de determinados elementos HTML, incluir todas as imagens decorativas, definir o tamanho dos textos, as cores usadas, etc.
As folhas de estilo vieram resolver um problema que existia no HTML. Este foi criado para atribuir estrutura aos conteúdos. Com o tempo começaram a surgir elementos visuais e ao HTML foram acrescentadas capacidades de controlo visual. Isto levou a grandes e graves problemas porque o tempo necessário para modificar era muito e havia sempre a possibilidade de as páginas não ficarem iguais. Para isso foram criadas as CSS externas. Agora, para modificar o tamanho do texto, por exemplo, basta ir às CSS que todo o texto de todas as páginas do site será alterado.
Uma CSS simples é composta por seletores, propriedades e valores:
background-color: black;
}
No exemplo acima, body é um seletor, background-color é uma propriedade e black é o valor da propriedade. Um mesmo seletor pode ter várias propriedades:
background-color: black;
color: green;
}
Para utilizarmos as CSS, precisamos de criar um ficheiro com a extensão .css e associar esse ficheiro a um ou mais documentos HTML. Um mesmo ficheiro CSS pode ser utilizado para infinitos documentos HTML, e quaisquer mudanças nesse ficheiro CSS terão efeito na aparência de todas as páginas HTML relacionadas.
O que associa uma página HTML a uma folha CSS é um elemento posicionado no HTML que referencia a CSS. Trata-se do elemento <link rel="stylesheet" type="text/css">, que fica dentro do cabeçalho do documento.
O exemplo abaixo define que o body de uma página HTML associada a esse estilo terá fundo preto (black) e texto em verde (green):
<head>
<title>Título da Página</title>
<link rel="stylesheet" type="text/css" href="estilos.css">
</head>
<body>
<p>Corpo da Página</p>
</body>
</html>
Tamanhos de letra
Uma das decisões a tomar, quando se procede à formatação de conteúdos digitais, está relacionada com a definição dos tamanhos de letra. Mais concretamente, quais são as unidades de medida que devemos selecionar? Devemos usar unidades de medida absolutas ou relativas?
No texto das WCAG 2.0 a resposta a esta pergunta é dada de uma forma mais "funcional" do que técnica. Do ponto de vista do utilizador, o que é que se pretende que os conteúdos sejam capazes de fazer? Assim, existem nas recomendações de acessibilidade do W3C dois critérios de sucesso que tratam a questão do tamanho de letra. Dizem o seguinte:
e
(...)
5. O texto pode ser redimensionado sem tecnologia de apoio até 200 porcento, de um modo que o utilizador não necessita efectuar um varrimento horizontal para ler uma linha de texto numa janela em ecrã completo.
A resposta a estes dois critérios é dada pelo documento "Técnicas e falhas para as WCAG 2.0" do W3C, através de 4 técnicas. As três primeiras passam por:
- C12: Utilizar percentagem para tamanhos de letra.
- C13: Utilizar tamanhos de letra nomeados (larger, small, ...).
- C14: Utilizar unidades em para tamanhos de letra.
A quarta técnica sugerida pelo W3C passa por:
- G178: Fornecer controlos na página Web que permitam aos utilizadores alterar, gradualmente, o tamanho de todo o texto numa página até 200%
A técnica G178 visa tornar explícito na própria interface da página Web a existência de um mecanismo de ampliação e redução do tamanho de letra. Segundo o W3C, estão na categoria dos utilizadores que precisam deste mecanismo, pessoas idosas, com dificuldades de visão, que necessitam de efetuar ajustamentos ao tamanho da letra para conseguirem ler o conteúdo das páginas, que não dispõem de software de ampliação e estão menos familiarizadas com as funcionalidades dos próprios browsers para o efeito.
De notar que a utilização destas quatro técnicas não obedece a nenhuma ordem em particular. Tendo em conta o articulado das três técnicas (C12, C13, C14) e a forma como as mesmas respondem aos critérios de sucesso 1.4.4 e 1.4.8 parece poder-se depreender que o uso da unidade de medida em é a eleita.
Mas, afinal qual é a definição de unidade absoluta e de unidade relativa?
As unidades absolutas têm uma representação física fixa e conhecida. São disso exemplo, mm=milímetros, cm=centímetros, in=polegadas, pt=pontos, pc=picas. Um ponto corresponde a 1/72 da polegada e uma pica corresponde a 1/6 da polegada.
As fontes absolutas não devem ser utilizadas para definir tamanhos de letra num ecrã, uma vez que é difícil de controlar unidades físicas num dispositivo como um ecrã, que pode ter, logo à partida, diferentes dimensões e representa a realidade de forma relativa. As unidades absolutas devem ser utilizadas para as definições de tamanho de letra numa impressora, a qual utiliza um suporte físico capaz de representar com naturalidade, exatidão e consistência as unidades físicas.
As unidades relativas não têm uma representação física fixa. Elas dependem do tamanho de letra que é atribuída ao próprio elemento. No caso da unidade em, o tamanho das letras é calculado em relação ao M (m maiúsculo). No caso da unidade ex, o tamanho das letras é calculado de acordo com a letra x (x minúsculo).
No caso dos píxeis, eles são considerados relativos, uma vez que não correspondem a nenhuma representação física e a sua dimensão depende da distância de visualização.
Esta classificação dos píxeis como unidades relativas não tem nada a ver com o conceito de unidades relativas proposto pelas Diretrizes de Acessibilidade para o Conteúdo da Web (WCAG), em que "relativo" significa que o texto escala em relação à unidade definida para o elemento a que pertence. Por exemplo, na figura abaixo definimos o tamanho da palavra "utilizador" e da palavra "muito" com font-size=15px. É visível que a palavra "utilizador" e a palavra "muito" se apresentam visualmente com o mesmo tamanho, apesar de pertencerem a elementos diferentes. Isto é assim, mesmo quando se procede à ampliação da letra através do browser. Já na figura seguinte, onde as mesmas palavras foram definidas com font-size=1.5em, i.e. unidade relativa, verifica-se que as palavras "utilizador" e "muito" são escaláveis com relação aos elementos a que pertencem. Assim, o tamanho de letra da palavra "utilizador" é maior do que o tamanho da letra da palavra "muito", uma vez que a sua dimensão é calculada em relação ao elemento a que pertencem. Assim, a palavra "utilizador" é uma vez e meia o tamanho definido para o cabeçalho e a palavra "muito" é 1 vez e meia o tamanho definido para o parágrafo.
Figura 38 - Uso de tamanhos de letra absolutos
Ao efetuar-se a ampliação verifica-se que as palavras "utilizador" e "muito", aumentam mas mantêm entre si o mesmo tamanho. Ou seja, as palavras "utilizador" e "muito" não reagem relativamente aos elementos a que pertencem, mantendo o seu tamanho absoluto. Neste caso, o efeito de aumento do tamanho de letra fica-se a dever ao "engordar" do píxel – efeito que as versões anteriores ou iguais à 7 do Microsoft Internet Explorer não operam.
Figura 39 - Uso de tamanhos de letra relativos
Ao efetuar-se a ampliação verifica-se que as palavras "utilizador" e "muito", aumentam proporcionalmente o tamanho relativamente ao elemento a que pertencem.
Por último, quando o tamanho de letra é especificado em qualquer unidade de medida absoluta, incluindo aqui os píxeis, os comandos de menu Tamanho de Texto no Microsoft Internet Explorer 7 e versões anteriores não redimensionam, pura e simplesmente, o texto.
ARIA - Accessible Rich Internet Applications
Para que serve o ARIA
Vídeo 11 - Introdução ao ARIA
Accessible Rich Internet Applications (ARIA) é uma especificação emergente do W3C, a qual, no momento em que escrevemos este tutorial, não chegou ainda ao seu estado acabado de Recomendação Final do W3C. A última versão do ARIA, publicada a 18 de janeiro de 2011, tem a classificação de Recomendação Candidata, classificação tipicamente atribuída a um documento W3C antes da etapa final de aprovação.
O ARIA é um esforço em tornar as aplicações Web mais acessíveis que conta, já hoje, com o apoio de um conjunto vasto de empresas, quer fabricantes de ferramentas de autor quer agentes de utilizador, nomeadamente fabricantes de navegadores Web e tecnologias de apoio. O ARIA já é hoje suportada pelos principais navegadores Web (Microsoft Internet Explorer, Mozilla Firefox, Opera, Apple Safari) assim como tecnologias de apoio, principalmente leitores de ecrã (JAWS, Supernova, NVDA, Window-Eyes, ZoomText e VoiceOver).
O próprio W3C incentiva o uso de ARIA, sendo já possível validar as aplicações que dele fazem uso. O HTML5 já o suporta e o XHTML1.1 tem igualmente uma extensão ARIA que pode ser validada pelo validador de HTML do W3C. Apresentam-se abaixo as declarações de DOCTYPE que já suportam ARIA.
Para (X)HTML5 a declaração é:
HTML 1.1 + Aria 1.0:
O ARIA está concebida para proporcionar acessibilidade de um ponto de vista técnico, ou, dito de outra forma, aquilo a que se costuma designar por "acessibilidade programática" (no nosso tópico O link "ver mais" o conceito de acessibilidade programática fica particularmente evidenciado).
O ARIA proporciona três tipos de respostas para incrementar a acessibilidade:
- Novas formas de comunicar o significado dos elementos, aquilo a que tecnicamente designamos de Web semântica;
- Novas formas de comunicar as relações existentes entre os diversos blocos de informação;
- Colmata as insuficiências das especificações (X)HTML, melhorando a usabilidade para todos os utilizadores ao permitir, em ambiente Web, modelos de navegação familiares aos existentes nas aplicações de computador.
Vídeo 12 - Incrementar a acessibilidade através do ARIA
Nestes tutoriais, a marcação de pontos de referência web (landmarks) são um exemplo de melhoria semântica. O tutorial o link “ver mais” é um bom exemplo para estabelecer programaticamente uma relação entre um link e um cabeçalho.
Tecnicamente, o ARIA introduz as suas funcionalidades através dos atributos dos elementos. Há três tipos de atributos ARIA, que nos permitem comunicar respetivamente:
- Qual é o papel (role) que um componente, em particular, desempenha numa interface;
- Quais são as propriedades (property) que esse componente tem, e
- Qual é o estado (state) atual do componente.
Exemplo: pontos de referência (landmarks)
Vídeo 13 - Pontos de referência Web (landmarks) no ARIA
Atualmente é raro lermos um documento na íntegra, varrendo todas as suas linhas da esquerda para a direita e de cima para baixo. Isto é particularmente verdade no caso das páginas Web. Quase sempre, quando consultamos documentos na Web levamos uma pergunta de partida e tentamos encontrar, nos documentos que consultamos o bloco de informação que poderá conter, a resposta para essa ou essas perguntas. A leitura não linear, vulgarmente chamada de leitura em diagonal, é muito vulgar para quem faz uso da visão. Os fabricantes de tecnologias, principalmente os que se dedicam ao setor das tecnologias de apoio, têm tentado dotar, as mesmas, de funcionalidades que permitam aos seus utilizadores um maior grau de liberdade no varrimento dos documentos. Saltar para o corpo principal da página ou encontrar os menus de navegação de uma página são necessidades frequentes, por exemplo para um utilizador cego que usa um software de leitura de ecrã. Hoje em dia, o salto para o corpo principal da página é disponibilizado pelo criador da página ao colocar como primeiro link, da mesma, o link "saltar para o corpo da página". Inclusivamente, é frequente atribuir-lhe uma tecla de atalho. Mas não haverá uma maneira mais consistente de identificar a parte principal do documento? No caso dos menus, como listas de opções que são, têm sido marcados como listas não ordenadas. Mas como distinguir um menu de navegação de uma lista de elementos não ordenados que surge no próprio texto? Ao atribuir a diferentes áreas da página, semanticamente identificadas, pontos de referência (landmarks), estamos a dar às tecnologias formas programáticas para que estas áreas sejam identificadas.
Como adicionar um ponto de referência Web (landmark) a um contentor de conteúdo?
Por exemplo, imaginemos que pretendemos identificar o Ou seja: Desta forma, as tecnologias de apoio vão conseguir saber que este contentor ( São vários os tipos de landmarks disponíveis. Destacamos aqui alguns dos pontos de referência básicos com os quais produzimos o exemplo abaixo. Para mais informação, consulte: Accessible Rich Internet Applications (WAI-ARIA) 1.0: W3C Candidate Recommendation 18 de Janeiro de 2011. No teclado português, para navegar pelos pontos de referência Web usar: Em modo de navegação Web, no NVDA, para uma rápida navegação, pode usar as seguintes teclas para saltar de ponto de referência em ponto de referência: No VoiceOver, uma das formas mais fáceis de navegar pelos pontos de referência é usar o trackpad. Basta ativar o "controlador do trackpad" - VO + dois dedos para a direita no trackpad, como quem está a rodar um botão para a direita. Depois, rodando de novo esse “botão imaginário” para a direita ou para a esquerda em cima do trackpad até selecionar a opção "pontos de referência web". Finalmente, basta pincelar com um dedo para cima ou para baixo para se deslocar pelos diversos pontos de referência Web existentes na página.
A toda a largura do topo da página encontra-se marcada a região banner. Na coluna do lado esquerdo encontra-se a região navigation. A coluna central encontra-se marcada com main. Dentro de main temos uma região marcada com application. A coluna do lado direito está marcada com complementary. Dentro desta, temos uma região marcada com form e dentro desta, ainda temos uma região marcada com search. No rodapé encontra-se, a toda a largura da página, uma região marcada com contentinfo. Ao marcarmos todas estas regiões da página, damos aos utilizadores de tecnologias de apoio a possibilidade de, rapidamente, se posicionarem numa destas áreas. Na imagem que se segue apresenta-se um exemplo típico de um link com o texto "ver mais". Neste caso, apresentam-se duas notícias em que o seu desenvolvimento está agarrado ao link "ver mais". Quando o utilizador é confrontado com o link "ver mais" de forma descontextualizada, pergunta-se: "ver mais" sobre o quê?
O código correspondente a este exemplo é: A Universidade do Porto está a promover mais uma edição do questionário sobre o Cartão U.Porto, dirigido a todos os membros da comunidade académica (funcionários e estudantes). Conhecer a situação profissional dos diplomados da U.Porto, assim como a sua trajetória no mundo do trabalho, é o objetivo do Inquérito que o Observatório do Emprego promove, a partir do dia... Uma das regras constantes das WCAG 2.0 diz-nos que um link tem de ser compreensível fora do seu contexto. Na verdade, o texto das WCAG 2.0 não diz exatamente isto, mas, no critério de sucesso 2.4.4, de prioridade A, pode ler-se: Como vemos, se a regra inicial, em português corrente, nos parece simples, a leitura das WCAG 2.0 parece-nos estranha e o nosso primeiro pensamento é o de que, o texto do critério não está corretamente traduzido para português. Mas, na verdade, não é assim. Se partirmos a frase em 3 partes, tudo fica mais claro. A primeira afirmação, e talvez a mais simples de compreender, é "A finalidade de cada link pode ser determinada a partir apenas do texto do link". Assim, um texto como "ver mais" suscita de imediato a interrogação "ver mais sobre o quê"?, ou seja uma interrogação sobre a própria finalidade. À luz desta afirmação, o critério de sucesso seria satisfeito se usássemos uma solução em que o texto dos links explicitasse a finalidade. No Exemplo B, que se apresenta na figura seguinte, é possível distinguir claramente ambos os links atendendo ao texto utilizado.
A segunda afirmação, e talvez a mais complexa de compreender, é "[A finalidade de cada link pode ser determinada] a partir do texto do link juntamente com o respectivo contexto do link determinado de forma programática". No nosso exemplo em concreto, significa: o que é que temos de fazer para que a tecnologia de apoio consiga, ao passar pelo link "ver mais", determinar programaticamente que ele está associado ao cabeçalho da notícia respetiva? No leque de técnicas adicionais, ou seja de tipo aconselhado, o W3C aponta o uso de ARIA como uma das formas para solucionar o problema: Com ARIA a apresentação corresponde ao que se vê no Exemplo A, mas o código é ligeiramente alterado, sendo adicionado um id a cada cabeçalho da notícia, os quais são respetivamente referenciados pelo atributo aria-describedby. Deixa-se a seguir aquele que será o código do Exemplo C: A Universidade do Porto está a promover mais uma edição do questionário sobre o Cartão U.Porto, dirigido a todos os membros da comunidade académica (funcionários e estudantes). Conhecer a situação profissional dos diplomados da U.Porto, assim como a sua trajetória no mundo do trabalho, é o objetivo do Inquérito que o Observatório do Emprego promove, a partir do dia... Já agora, ainda existe uma exceção, no critério de sucesso, expressa da seguinte forma: "exceto quando a finalidade do link for ambígua para os utilizadores em geral". Ou seja, quando a ideia, com a construção do link, é gerar ambiguidade na mente de qualquer utilizador, então o critério de sucesso não se aplica. Derivado do critério de sucesso (CS) 3.2.4 ainda podemos concluir, e citando o documento das WCAG 2.0, que: e uma descrição, de acordo com o CS 3.2.4, deve ser consistente, sendo a consistência assim definida: Isto significa que o link "ver mais" nesta página deveria ser sempre construído da mesma forma.Quais os tipos de landmarks disponíveis?
Nota: num documento não se deve marcar mais do que um elemento como banner.
Nota: dentro de um documento ou aplicação, o autor deve marcar apenas um elemento com o role="main".
Nota: dentro de um documento ou aplicação, o autor deve marcar apenas um elemento com o role="contentinfo".Navegar com o JAWS pelos pontos de referência Web (landmarks)
Navegar com o NVDA pelos pontos de referência web (landmarks)
Navegar com o VoiceOver pelos pontos de referência Web (landmarks)
Figura 40 - Um exemplo de um esquema de marcação de landmarks numa página Web
Retirado de http://www.html5accessibility.com/tests/roles-land.html.O link "ver mais"
Figura 41 - Exemplo A: o caso do uso de múltiplos links "ver mais" que ligam a desenvolvimentos de notícias diferenciadasNotícias
Questionário: O que é que acha do Cartão U.Porto?
inquérito aos Diplomados da U.Porto 2010
Figura 42 - Exemplo B: os dois links "ver mais" do Exemplo A foram transformados respetivamente em "ver mais sobre o Questionário: o que é que acha do Cartão U.Porto" e " ver mais sobre o inquérito aos Diplomados U.Porto 2010".Notícias
Questionário: O que é que acha do Cartão U.Porto?
inquérito aos Diplomados da U.Porto 2010
Última actualização: 2020-06-22
Página gerada em: 2024-11-09 às 00:23:42