Acessibilidade Web para Cidadãos com Necessidades Especiais

Acessibilidade à Web
por Cidadãos com Necessidades Especiais
Anexo ao Caderno de Encargos
Directrizes de Acessibilidade do Conteúdo da Web do W3C
Presidência do Conselho de Ministros
UMIC - Unidade de Missão Inovação e Conhecimento
Programa ACESSO
Setembro 2003
Índice
Prefácio...................................................................................................................................... 3
Introdução .................................................................................................................................. 5
Secção 1. Enquadramento e estrutura das Directrizes de Acessibilidade à Web ...................... 7
Secção 2. Listas de verificação da acessibilidade Web para pessoas com Deficiência ............ 8
Subsecção 2.1. Prioridade 1 ................................................................................................ 11
2.1.1. Lista de verificação prioridade 1: Conformidade nível A ......................................... 11
2.1.2. Casos gerais ........................................................................................................... 13
2.1.3. Casos em que são utilizados mapas de imagem.................................................... 16
2.1.4. Casos em que são utilizadas tabelas ..................................................................... 17
2.1.5. Casos em que são utilizadas frames ...................................................................... 19
2.1.6. Casos em que são utilizados applets e programas interpretáveis .......................... 20
2.1.7. Casos em que são utilizados multimédia ................................................................ 20
2.1.8. E se, apesar de todos os esforços... ....................................................................... 20
Subsecção 2.2. Prioridade 2 ................................................................................................ 21
2.2.1. Lista de verificação prioridade 1 e 2: Conformidade nível AA ................................ 21
2.2.2. Casos gerais ........................................................................................................... 23
2.2.3. No caso de serem utilizadas tabelas ...................................................................... 27
2.2.4. No caso de serem utilizadas frames ....................................................................... 27
2.2.5. No caso de serem utilizados formulários ................................................................ 27
2.2.6. No caso de serem utilizados applets e programas interpretáveis ........................... 28
Subsecção 2.3. Prioridade 3 ................................................................................................ 31
2.3.1. Lista de verificação prioridade 1, 2 e 3: Conformidade nível AAA .......................... 31
2.3.2. Casos gerais ........................................................................................................... 32
2.3.3. No caso de serem utilizadas imagens e mapas de imagem ................................... 34
2.3.4. No caso de serem utilizadas tabelas ...................................................................... 35
2.3.5. No caso de serem utilizados formulários ................................................................ 35
Secção 3. Avaliação ................................................................................................................ 37
3.1. Avaliação Manual .......................................................................................................... 37
3.2. Avaliação Automática .................................................................................................... 37
Secção 4. Conformidade ......................................................................................................... 39
Secção 5. Referências ............................................................................................................. 41
2
3
Prefácio
"O poder da Web está na sua universalidade.
O acesso por todos não olhando à incapacidade é um aspecto essencial."
Tim Berners-Lee, Director do W3C e inventor da World Wide Web
A todas as Direcções-Gerais e serviços equiparados, institutos públicos nas suas diversas
modalidades,
A Resolução do Conselho de Ministros n.º 135/2002, de 20 de Novembro, definiu o novo
enquadramento institucional da actividade do Governo em matéria de sociedade da
informação, governo electrónico e inovação.
Compete à Unidade de Missão Inovação e Conhecimento (UMIC) da Presidência do Conselho
de Ministros, nos termos da alínea d) do n.º 2 do referido diploma, actuar no âmbito da
participação dos cidadãos com necessidades especiais na sociedade da informação.
No caso do acesso à informação a oportunidade de participação dos Cidadãos com
Necessidades Especiais, nomeadamente idosos e pessoas com deficiência, na Sociedade da
Informação que estamos a construir, passa por uma política de acessibilidade aos conteúdos
digitais. No caso da presença da Administração Pública na Internet é importante continuar na
senda da Resolução do Conselho de Ministros 97/99, não perdendo de vista os nobres e
essenciais objectivos, os quais deverão fazer parte de todos os cadernos de encargos que
envolvam a produção de conteúdos. Em relação a estes é preciso garantir que a:
“a) respectiva leitura possa ser feita sem recurso à visão, movimentos precisos, acções
simultâneas ou a dispositivos apontadores, designadamente ratos;
b) obtenção da informação e a respectiva pesquisa possam ser efectuadas através de
interfaces auditivos, visuais ou tácteis.”
No momento tecnológico actual, no entender do Estado Português, que é também convicção
do Conselho da Europa, do Parlamento Europeu e da Comissão Europeia, afirmado no Plano
de acção eEurope 2002 e reforçado no eEurope 2005, as directrizes internacionais que
melhor respondem a tão nobres objectivos são as emanadas pelo consórcio criador da Web: o
World Wide Web Consortium - W3C.
Assim, para a Administração Pública Portuguesa, apontamos como objectivo até 2005 a
conformidade com o nível AA das Directrizes de Acessibilidade do Conteúdo Web
apresentadas neste documento.
TagusPark, 1 de Outubro 2003.
Diogo Vasconcelos
Gestor da Unidade de Missão Inovação e Conhecimento
Presidência do Conselho de Ministros
4
5
Introdução
O presente documento visa servir de anexo a um caderno de encargos. Perante o desafio
proposto e a redacção das condições de exigência mencionadas no prefácio, no caderno de
encargos, há que explicitar quais são as directrizes de que estamos a falar, quais os pontos a
verificar, como efectuar a avaliação e a quem recorrer em caso de necessidade. O presente
documento apresenta também algumas notas, embora rápidas, de técnicas a utilizar. As
técnicas apresentadas no documento fazem uso de HTML.
O presente “anexo ao caderno de encargos” foi pensado para que os organismos públicos o
forneçam a quem vai produzir e desenhar os conteúdos digitais a publicar na Internet, pelo
que o seu conteúdo foi desenvolvido com linguagem que se espera seja acessível ao seu
grupo-alvo: designers e criadores Web profissionais.
O presente “anexo ao caderno de encargos” funciona em conjugação com o “Guia de Boas
Práticas na Construção de Web Sites da Administração Directa e Indirecta do Estado”, cuja
versão de 2003 foi responsabilidade da UMIC.
O presente “anexo ao caderno de encargos” apresenta as Directrizes de Acessibilidade do
Conteúdo Web 1.0 (WCAG 1.0). Decidimos avançar com a produção do presente documento
mesmo sabendo que o W3C se encontra actualmente a preparar a versão 2 das WCAG. Do
acompanhamento próximo que efectuamos dos trabalhos, verificamos que os mesmos ainda
estão atrasados e que tudo leva a crer que em nada eles irão destruir as actuais
recomendações. Está Inclusivamente em preparação uma tabela de conversão entre as novas
directrizes e as actuais directrizes.
O presente “anexo ao caderno de encargos” foi estruturado em 5 blocos principais:
(1) enquadramento e estrutura das Directrizes de Acessibilidade à Web;
(2) listas dos pontos de verificação;
(3) avaliação;
(4) conformidade;
(5) referências que permitem responder a muitas das perguntas e dúvidas para as
quais não se encontra resposta no actual ”anexo”.
O primeiro ponto visa de uma forma sucinta explicar qual a razão da existência da
preocupação da acessibilidade à Web por parte das pessoas com deficiência, bem como dar
conta da forma como as Directrizes de Acessibilidade do Conteúdo Web do W3C estão
estruturadas.
A secção 2 do presente “anexo” é das mais importantes e de certa forma a razão da sua
existência. Ela explicita, em notas breves, os diversos pontos de verificação. Foram
concebidas três subsecções, cada qual dedicada aos três níveis de prioridade. Cada uma
destas subsecções abre com uma lista completa dos pontos de verificação a validar em cada
um dos níveis de prioridade.
Para auxiliar na validação, a secção 3 dá conta de alguns instrumentos, para uso manual ou
para produção automática de relatórios de acessibilidade. Há sempre a possibilidade de se
solicitar um relatório de acessibilidade ao Programa ACESSO da UMIC.
Feita a validação, entra-se na secção da conformidade, e aqui surge o “Símbolo de
Acessibilidade à Web” para afixar na primeira página, bem como a publicitação do nível de
conformidade com as directrizes de acessibilidade, para os quais se sugere os logos do W3C.
6
Apesar do objectivo do presente “anexo” ter sido fixado ao nível dos pontos de verificação de
prioridade AA, incentivamos vivamente a adopção dos pontos de verificação de nível 3,
também apresentados no presente documento.
Por último, a 5ª secção dá conta de um conjunto de referências que permitem localizar um
conjunto mais vasto de informações sobre as directrizes de acessibilidade, incluindo algumas
tecnologias não W3C, como é o caso do JavaScript e do Flash, bem como informações sobre
ajudas técnicas para pessoas com deficiência.
7
Secção 1. Enquadramento e estrutura das Directrizes de
Acessibilidade à Web
Em Portugal a acessibilidade à Internet tornou-se lei para a Administração Pública pela
Resolução do Conselho de Ministros 97/99, a qual constituiu a resposta do Governo àquela
que ficou conhecida como a primeira petição electrónica ao parlamento Português. Em Agosto
de 1999 a resolução intitulada “Acessibilidade dos sítios da Administração Pública na Internet
pelos Cidadãos com Necessidades Especiais”, obrigava a partir de então que as DirecçõesGerais e serviços equiparados, bem como os institutos públicos nas suas diversas modalidades,
assegurassem que a:
a) respectiva leitura possa ser feita sem recurso à visão, movimentos precisos, acções
simultâneas ou a dispositivos apontadores, designadamente ratos;
b) obtenção da informação e a respectiva pesquisa possam ser efectuadas através de
interfaces auditivos, visuais ou tácteis.
No “Guia de Boas Práticas na Construção de Web Sites da Administração Directa e Indirecta
do Estado” (versão de 2003), há diversas referências ao longo do documento, consideradas
de boas práticas, que estão directamente relacionados com acessibilidade. Para além disso,
existe ainda um capítulo específico dedicado às “Facilidades para Cidadãos com
Necessidades Especiais”.
As Directrizes de Acessibilidade do Conteúdo da Web, da Iniciativa pela Acessibilidade Web
(WAI) do W3C perfazem um total de 14 directrizes. As doze primeiras estão relacionadas com
um dos princípios mais importantes em acessibilidade: o princípio da transformação
harmoniosa. Na prática, este principio permite que um dado elemento texto, áudio ou imagem
se transforme harmoniosamente em qualquer um dos outros dois (i.e. transformar texto em
áudio, áudio em texto, texto em imagem, imagem em texto, etc.).
Na área do acesso à informação digital, nomeadamente através de computadores, o sentido
da visão, da audição e do tacto assumem uma vital importância. Qualquer dificuldade de
percepção por parte de um destes sentidos acarreta uma necessidade especial, que no caso
da informação representa a necessidade da sua transformação de acordo com as
capacidades do utilizador. A estas vêm-se juntar algumas dificuldades de carácter motor,
como seja o facto de não conseguir trabalhar com um teclado ou com um rato, caso por
exemplo das pessoas tetraplégicas.
Hoje em dia, algumas dessas transformações são possíveis de efectuar graças aos agentes
do utilizador usados no acesso à Web (p.e. navegadores e mesmo ajudas técnicas). É hoje
possível transcrever texto para áudio automaticamente via sintetizador de fala, passar textos
para suporte Braille, efectuar ampliações do ecrã, modificar os contrastes das cores utilizadas.
No entanto existem técnicas e regras que os Designers Web têm de seguir para facilitar a vida
aos agentes de utilizador nessa tarefa de adequação às necessidades do utilizador.
A I&D tem soluções já em estado bastante avançado no que respeita à conversão de áudio
em texto (p.e. sistemas de reconhecimento de voz) e mesmo de texto em imagem (p.e.
avatares para língua gestual, linguagem pictográfica para pessoas com défice cognitivo), mas
na Web elas não são ainda de uso corrente. Isto exige um trabalho adicional dos criadores de
páginas Web em busca da tal transformação harmoniosa. Ao colocarem um trecho de áudio é
necessário disponibilizar também um equivalente textual e mesmo um equivalente em língua
gestual para que a mensagem seja inteligível pelas pessoas surdas.
8
Na área das conversões automáticas de imagem em texto ou mesmo de imagem em áudio, a
I&D ainda desbravou pouco terreno. Para estas, os criadores de páginas Web têm que
desenvolver actualmente todo o trabalho, ou seja: ao colocarem uma imagem é necessário
acrescentar uma legenda e no caso de se justificar, uma descrição para que exista um
equivalente textual da mesma para pessoas cegas.
É desta transformação que tratam as doze primeiras directrizes de acessibilidade. As duas
restantes abordam a problemática da navegação numa página Web.
Mas não são apenas as pessoas com necessidades especiais que beneficiam de uma
informação que incorpore as directrizes de acessibilidade. Quando estes princípios são
empregues, eles fazem com que os conteúdos Web se tornem acessíveis a uma variedade de
dispositivos de navegação Web, tais como telefones, assistentes portáteis de mão, quiosques,
aplicações de rede, etc. Ao fazer conteúdos acessíveis para uma maior variedade de
dispositivos, esse conteúdo vai também estar disponível para as pessoas numa maior
diversidade de situações.
A própria tecnologia ganha “capacidades de leitura” e
“interpretação”. Por exemplo, os motores de busca ganham a capacidade de efectuar
procuras em trechos áudio e mesmo de efectuar pesquisas em elementos como imagens. Os
navegadores são, por vezes, capazes, numa colecção de documentos, de identificar por eles
próprios onde está o índice, para já não falar na capacidade de negociar com o próprio
servidor qual o idioma preferido do seu utilizador. Tecnologias como leitores de ecrã, para uso
por utilizadores cegos, ganham a capacidade de distinguir um parágrafo de um cabeçalho.
O desafio da acessibilidade é grande mas é também fascinante.
As 14 directrizes, encontram-se organizadas por 65 pontos de verificação, os quais se
encontram arrumados por 3 níveis de prioridade. Na secção 2 encontra-se a definição de
cada um destes níveis.
Secção 2. Listas de verificação da acessibilidade Web para
pessoas com Deficiência
Aconselhamos a efectuar uma primeira leitura logo dos pontos de verificação constantes nas
listas que se encontram em 2.1.1, 2.2.1 e 2.3.1. Os restantes pontos do documento
apresentam esclarecimentos adicionais para melhor compreensão dos pontos de verificação.
Nesta secção são percorridos os 65 pontos de verificação a ter em conta para ir ao encontro
da acessibilidade preconizada nas Directrizes de Acessibilidade do Conteúdo da Web (versão
1.0) do W3C. Estes 65 pontos de verificação encontram-se aqui organizados por níveis de
prioridade.
Os níveis de prioridade têm a seguinte definição:
[Prioridade 1]
Pontos que os criadores de conteúdo Web têm absolutamente de satisfazer. Se não o
fizerem, um ou mais grupos de utilizadores ficarão impossibilitados de aceder a informações
contidas no documento. A satisfação deste tipo de pontos é um requisito básico para que
determinados grupos possam aceder a documentos sedeados na Web.
[Prioridade 2]
9
Pontos que os criadores de conteúdo Web devem satisfazer. Se não o fizerem, um ou
mais grupos de utilizadores terão dificuldades em aceder a informações contidas no
documento. A satisfação deste tipo de pontos traduzir-se-á na remoção de obstáculos
significativos ao acesso a documentos sedeados na Web.
[Prioridade 3]
Pontos que os criadores de conteúdo Web podem satisfazer. Se não o fizerem, um ou
mais grupos poderão deparar-se com algumas dificuldades em aceder a informações contidas
nos documentos. A satisfação deste tipo de pontos irá melhorar o acesso a documentos
sedeados na Web.
Pelas definições apresentadas, facilmente se depreende que os primeiros pontos de
verificação a tratar são os de prioridade 1. Só depois se deverá partir para os de nível 2 e
finalmente para os de nível 3 (consulte o capítulo 4 sobre conformidade).
10
11
Subsecção 2.1. Prioridade 1
A este nível encontramos os requisitos básicos, que constituem verdadeiras barreiras
intransponíveis para grupos de utilizadores que, sem o seu cumprimento, ficam
impossibilitados de ter acesso à informação publicada no sítio Web.
Esta subsecção compreende 16 dos 65 pontos de verificação, os quais foram agrupados de
acordo com os diferentes tipos de elementos que se podem encontrar numa página Web.
Assim, caso se esteja perante determinado tipo de elemento afixado numa página Web há
que verificar se estamos a contemplar o ponto de acessibilidade mencionado.
A subsecção contempla ao nível dos pontos de verificação de prioridade 1: casos gerais;
casos em que são utilizadas imagens e mapas de imagem; casos em que são utilizadas
tabelas; casos em que são utilizadas frames (molduras); casos em que são utilizados applets
e programas interpretáveis; casos em que é feito uso de elementos Multimédia. Por fim, se
depois de todos os esforços não for possível criar uma página acessível... O que se deve
fazer?
2.1.1. Lista de verificação prioridade 1: Conformidade nível A
A presente lista, composta por 16 pontos de verificação, nem todos aplicáveis (N.A) às
páginas em concreto pela não existência dos elementos, deve ser validada pelo Designer e/ou
criador do sítio Web e entregue à entidade que solicitou a produção dos conteúdos. Os pontos
de verificação desta lista devem ser observados em todas as páginas do sítio Web. Quando
tal acontece, estamos perante uma página conforme com o nível A das Directrizes de
Acessibilidade do Conteúdo da Web 1.0 do W3C, o mesmo é dizer que respeita os pontos de
verificação de prioridade 1.
Casos Gerais
Sim
1.1 - Forneça um equivalente textual para todo o
elemento não textual.
Pode ser feito através do atributo "alt" ou "longdesc", ou no
conteúdo do elemento. Isto abrange: imagens,
representações gráficas de texto, incluindo símbolos,
regiões de mapas de imagem, animações, como é o caso
dos GIFs animados, applets e objectos programados, arte
ASCII, frames, programas interpretáveis, imagens utilizadas
em listas como sinalizadores de pontos de enumeração,
espaçadores, botões gráficos, sons (reproduzidos com ou
sem interacção do utilizador), ficheiros de áudio
independentes, pistas áudio de vídeo e trechos de vídeo.
2.1 - Certifique-se de que toda a informação transmitida
com base na cor se encontra também disponível sem
cor.
O equivalente informativo pode ser feito através do contexto
ou através do uso apropriado da notação.
4.1 - Identifique claramente quaisquer alterações de
idioma no texto de um documento, incluindo os
equivalentes textuais (caso das legendas das imagens
e de outros elementos).
Não N.A.
12
6.1 - Organize os documentos de forma a que os
mesmos sejam passíveis de serem lidos sem o uso das
folhas de estilo.
Quando um documento HTML é apresentado sem a folha
de estilo a que está associado, deve ser, mesmo assim,
possível ler o documento.
6.2 - Certifique-se que o equivalente para conteúdo
dinâmico é actualizado quando se dá a alteração
dinâmica do conteúdo.
7.1 - Evite concepções que possam provocar
intermitência do ecrã, até que os agentes do utilizador
possibilitem o seu controlo.
14.1 - Use linguagem clara e o mais simples possível
apropriada ao conteúdo do sítio Web.
Casos em que são utilizados mapas de imagem
1.2 - Forneça links de texto redundantes para cada
região activa de um mapa de imagens “server-side”.
9.1 - Providencie mapas de imagens “client-side” em
vez de mapas de imagens “server-side”, excepto
quando as regiões não possam ser definidas por uma
das figuras geométricas disponíveis.
Sim
Não N.A.
Casos em que são utilizadas tabelas
5.1 - Nas tabelas de dados, identifique as linhas e as
colunas que constituem os cabeçalhos.
5.2 - Nas tabelas de dados que têm dois ou mais níveis
lógicos de linhas ou colunas use notação para associar
células de dados e células de cabeçalhos.
Sim
Não N.A.
Casos em que são utilizadas frames (molduras)
12.1 - Forneça um título (<TITLE>) para cada “FRAME”,
facilitando assim a sua identificação e navegação.
Sim
Não N.A.
Casos em que são utilizados applets e programas
interpretáveis
6.3 - Certifique-se que as páginas são usáveis quando
scripts, applets, ou outros objectos programáveis se
encontram desactivados ou não são suportados. Se
isto não for possível, forneça informação equivalente
numa página alternativa acessível.
No momento da produção deste documento aconselha-se a
seguir este procedimento em relação à tecnologia Flash da
Macromedia, uma vez que ainda existem poucas
tecnologias de acesso a suportar esta linguagem.
Sim
Não N.A.
Casos em que é feito uso de elementos Multimédia
1.3 - Forneça uma descrição em áudio da informação
relevante da pista visual de uma apresentação
multimédia, até que os agentes do utilizador possam ler
automaticamente em voz alta o equivalente textual de
uma pista de vídeo.
Sim
Não N.A.
13
1.4 - Para qualquer apresentação multimédia
temporizada (e.g., um filme ou animação), sincronize
alternativas equivalentes (e.g., legendas ou áudio
descrição de pistas visuais) com a apresentação.
E se, apesar de todos os esforços...
11.4 - Se, depois de todos os esforços, não conseguir
criar uma página acessível, forneça um link para uma
página alternativa que use as tecnologias W3C na sua
versão acessível, com informação equivalente (ou com
as mesmas funcionalidade), que seja actualizada tantas
vezes quantas as páginas inacessíveis (originais).
Sim
Não N.A.
2.1.2. Casos gerais
Os casos gerais comportam 7 pontos de verificação, curiosamente cada um deles dedicado a
um tema diferente de acessibilidade: equivalente textual, cor, alterações de idioma ao longo
do texto, existência de folhas de estilo, alteração dinâmica de conteúdo, conteúdos
intermitentes (cintilantes) e por fim o uso de linguagem clara.
EQUIVALENTE TEXTUAL
Forneça conteúdo que, quando apresentado ao utilizador, cumpra no essencial a mesma
função ou propósito que o conteúdo visual ou sonoro.
Imagem
As necessidades em termos de equivalente textual para uma imagem são geralmente de dois
níveis: uma legenda e uma descrição. Geralmente a legenda é suficiente para identificar e
transmitir a mensagem transmitida pela imagem. Lembre-se que a legenda não deverá
ultrapassar os 80 caracteres. Para este efeito o código HTML dispõe do atributo ALT.
Nunca deixe uma imagem por legendar. Mesmo que legende uma imagem por ALT=”” ou
ALT=” “, como poderá ser o caso de algumas imagens meramente decorativas. Mas atenção
nunca legende uma imagem por “imagem” e muito menos “image0001.gif” ou algo
semelhante, muito menos “imagem decorativa”, nem tão pouco “separador”, nem tão pouco
“bullet”, ou mesmo “link para...”, ou “GIF animado”, ou “seta”, ou “seta para a esquerda
vermelha com a ponta verde”. Imagine a leitura em texto dessa página e veja como estas
legendas podem causar um ruído, um cansaço e um tédio fabuloso. Lembre-se que os casos
aqui apresentados são reais e foram encontrados já em enumeras páginas analisadas pelo
autor deste documento.
Imagem-Gráfico / Descrição de imagens
Quando necessita de mais de 80 caracteres para descrever uma imagem em HTML recorra
ao elemento LONGDESC, ou faça da imagem um link para a sua descrição ou ainda coloque
um link assim identificado [D] (técnica chamada de link-D) ao lado da imagem.
Por estranho que pareça o atributo LONGDESC é dos três, o menos aconselhável. A razão
prende-se com o facto das Ajudas Técnicas usadas por pessoas com Deficiência raramente o
conseguirem identificar.
14
Assim aconselha-se o uso de fazer da imagem um link para a sua descrição e neste caso
aconselha-se a construir um ALT do género ALT=”População com Deficiência em Portugal #
contém link para descrição”.
Esta mesma técnica deve ser usada na descrição de imagens como seja o caso de peças de
museus ou qualquer outras que requeiram uma descrição mais exaustiva.
Imagem-link / botões
Legende a imagem de acordo com as regras para construção do texto dos links,
nomeadamente compreensíveis fora do contexto.
<A HREF="home.htm">
<IMG SRC="home.gif" ALT="Ir para a página de entrada.">
</A>
Figura 1: Exemplo de legendagem de um botão gráfico que nos leva para a Página de
Entrada.
A legenda constante do ALT deve ser feita de acordo com a sua função. Neste caso colocar
um ALT=”Desenho de uma casa”, apesar de ser uma legenda não seria de grande utilidade
para o utilizador.
Imagem-Bullets
No caso de Bullet aconselha-se o uso de um ALT=”*”, ou “-“, ou mesmo “item: “. No entanto,
usando CSS é possível fazer com que o equivalente textual de um bullet gráfico seja mesmo
um bullet verdadeiro. Basta construir uma estrutura do tipo <ul><li>...</li>...</ul> (lista) e
depois fornecer o estilo com CSS. Um dos estilos possíveis é substituir o bullet por um gráfico.
Imagem-separador
No caso de um separador legende, por exemplo, por “-*-“ ou por “-xx-“, mas nunca por
“separador” ou pior ainda “separador de cor amarela e vermelha”. Não use também “------------------------------------------------------------------------------------------------------------------------“.
Normalmente para uma ajuda técnica, “----“ ou mesmo “---“ é suficiente.
Imagem-decorativa
Se a imagem for identificadora de uma secção legende-a com o nome da secção. Uma das
melhores formas de tratar as imagens decorativas é usar CSS. Neste último caso, como a
imagem fica na CSS, não há necessidade de a legendar. Até porque, neste caso, ela nunca
surge referenciada na estrutura de HTML.
Imagem-representação gráfica de texto
O rótulo de representações gráficas de texto, muito utilizada em menus e cabeçalhos, deve
conter um ALT com o mesmo texto que é visível no gráfico.
Pistas de áudio
Se o ficheiro de som for muito curto, pode incluir o equivalente textual no atributo ALT de uma
imagem que acompanha o link para o ficheiro de som.
15
<A HREF="work-e.wav">
<IMG SRC="audio.gif" ALT="Ficheiro som: Venha daí trabalhar connosco
na acessibilidade.">
Escute uma mensagem deixada pelo autor.
</A>
Figura 2: Exemplo para alternativo equivalente: pequeno trecho de áudio.
Se o ficheiro áudio contém muita informação, então provavelmente vai querer efectuar um link
para um ficheiro que contenha uma transcrição integral.
Vídeo
O vídeo requer dois tipos de equivalente textual. Por um lado a legendagem dos diálogos e
por outro lado uma descrição das cenas relevantes para a compreensão da acção e da
mensagem transmitida.
Esses elementos poderão ficar num ficheiro texto (ver figura 2) ou então deverão ser
sincronizados com o próprio elemento multimédia.
Legenda: “Tem a palavra o Exmo. Sr. Professor Doutor X”
Descrição: “o Sr. Professor Doutor X, levanta-se da mesa de honra e
dirige-se ao púlpito”.
Legenda: “Exmo. Senhor Presidente da mesa, meus senhores e minhas
senhoras”
Figura 3: Exemplo de equivalente textual não sincronizado para vídeo.
COR
Um bom exemplo do uso da cor para transmissão de informação pode ser dado com este
mesmo documento. Imagine que lhe pediam que: numa primeira fase apenas se deve
preocupar com os pontos impressos nas listas de verificação a vermelho. Procurava as listas
dos pontos de verificação e identificava facilmente os pontos de verificação alvo do seu
interesse. Não? Então qual é a dificuldade? Este documento está impresso a preto e branco!
Essa é a dificuldade de algumas ajudas técnicas para identificar informação que tem o seu
suporte na cor. Por exemplo, as linhas Braille são uma das tecnologias de acesso que para
saber a cor do texto é necessário executar um conjunto de comandos com o leitor de ecrã,
nem sempre à mão ou na mente do utilizador.
ALTERAÇÕES DE IDIOMA AO LONGO DO TEXTO
De todos os 16 pontos de verificação de prioridade 1 este é um dos pontos mais difíceis de
cumprir. Difícil pela atenção que requer, e pelo consumo de horas no seu tratamento. Difícil
também pela não existência de uma ferramenta que ajude no seu tratamento mais automático.
No entanto, o valor que o seu cumprimento acrescenta à página é grande. A importância não
se revela só para as tecnologias de apoio como também para os mecanismos de indexação e
16
busca automática na página. O seu cumprimento faz com que motores de busca, apesar de
uma página estar escrita em Português, encontre também no seu interior palavras em língua
estrangeira (ver exemplo da figura 4).
Hoje vou ao Shopping-Centre comer um Sourvette.
Código:
<p>Hoje vou ao <span lang=”en”>Shopping-Centre</span> comer um <span
lang=”fr”>Sourvette</span>.</p>
Figura 4: Exemplo da mudança de idioma ao longo do texto.
EXISTÊNCIA DE FOLHAS DE ESTILO
Use folhas de estilo (CSS – Cascading Style Sheet) para dar estilo aos elementos de uma
página HTML mas também para posicionar os respectivos elementos. Tenha no entanto em
atenção as situações como a que foi referida no ponto relativo à COR, mencionado acima,
mas também verifique se a ordem dos elementos, sem a presença da folha de estilo, é lógica.
Para o verificar deverá desactivar ou retirar a folha de estilo e efectuar a leitura. Uma das
ferramentas óptimas para efectuar esta verificação dá pelo nome de Opera (veja a secção
sobre Avaliação).
ALTERAÇÃO DINÂMICA DE CONTEÚDO
Ao colocar por exemplo imagens que mudam dinamicamente (temporizadas) o respectivo
equivalente textual deve ser modificado de acordo com a imagem apresentada no momento.
CONTEÚDO INTERMITENTE (CINTILANTE)
Pessoas com epilepsia fotossensível podem despoletar um ataque epiléptico com a
intermitência ou cintilar constante numa banda de 4 a 59 intermitências por segundo (Hertz),
bem como com alterações rápidas do escuro para o claro (como sucede com as lâmpadas
das discotecas). Tenha isso em linha de conta quando desenhar imagens GIF animadas ou
outro tipo de conteúdos que se repetem em ciclos infinitos.
USO DE LINGUAGEM CLARA
Não baralhe as ideias e vá direito ao assunto. Esta é uma das matérias mais subjectivas das
Directrizes de Acessibilidade do Conteúdo da Web. Tente ser objectivo na forma como
constrói o texto. Evite o uso de jargão, nomeadamente o que deriva da informática, quando o
assunto tratado não está relacionado com informática. Lá por estarmos a falar de conteúdo
digital para circular na Internet, não quer dizer que o conteúdo faça uso de jargão de
informáticos. Tente redigir o documento de acordo com o grupo-alvo ao qual o mesmo é
dirigido.
2.1.3. Casos em que são utilizados mapas de imagem
Ao nível da prioridade 1, verifica-se claramente, em termos de Directrizes de Acessibilidade,
uma clara tendência para levar os Designers ou criadores de páginas Web a deixarem de usar
mapas de imagem “server-side” (ver pontos de verificação 1.2 e 9.1) em benefício dos mapas
de imagem “client-side”.
17
Em relação aos mapas de imagem “client-side”, que são os mais comuns actualmente, há
apenas que considerar o ponto de verificação 1.1 (equivalente textual) e considerar a
legendagem das regiões que compõem o mapa de imagens.
2.1.4. Casos em que são utilizadas tabelas
Os dois pontos de verificação de prioridade 1 dizem respeito a tabelas que comportam dados.
Ou seja, é tratado o elemento <TABLE> de acordo com o significado ou semântica para o qual
este elemento foi criado na sua origem.
Ambos os pontos estão relacionados com a necessidade de se rotular a estrutura das tabelas,
ou seja, de identificar explicitamente as células da tabela que funcionam como cabeçalhos e
as que funcionam como células para comportar dados.
Assim, para ir ao encontro do ponto de verificação 5.1 temos que usar os diversos atributos
existentes numa tabela para lhe dar a estrutura devida (ver figura 5)
Exemplo de uma simples tabela de dados criada com notação HTML.
Cabeçalho da coluna 1 Cabeçalho da coluna 2
Cabeçalho da linha 1 Célula de dados C1L1
Célula de dados C2L1
Cabeçalho da linha 2 Célula de dados C1L2
Célula de dados C2L2
O código HTML desta tabela é:
<TABLE border=1>
<CAPTION>Exemplo de uma tabela
notação HTML.</CAPTION>
<TR>
<TD></TD>
<TH>Cabeçalho Col. 1</TH>
<TH>Cabeçalho Col. 2</TH>
</TR>
<TR>
<TH>Cabeçalho linha 1</TH>
<TD>C1L1</TD>
<TD>C2L1</TD>
</TR>
<TR>
<TH>Cabeçalho linha 2</TH>
<TD>C1L2</TD>
<TD>C2L2</TD>
</TR>
</TABLE>
de
dados
simples
criada
com
Figura 5: Exemplo de identificação dos elementos de estrutura de uma tabela. Uso de
<CAPTION> para fornecer o título à tabela, <TD> para identificar célula de dados, <TH> para
identificar célula de cabeçalho, <TR> para identificar linha.
Em tabelas mais complexas a associação dos cabeçalhos aos dados nem sempre é fácil e
para além da identificação dos elementos da tabela (proposta do ponto 5.1) é também preciso
efectuar explicitamente associações entre as células de dados e os cabeçalhos a que estão
ligados (proposta do ponto 5.2). Veja a figura 6 para exemplo.
18
Exemplo 1: DESPESAS DE VIAGEM (custo actual, euros)
VIAGEM
data
Refeições
Alojamento
Trans. Total
25 Ago 97
37.74
112.00
45.00
26 Ago 97
27.28
112.00
45.00
Subtotal
65.02
224.00
90.00
Lisboa
379.02
Se os elementos da tabela não estiverem identificados e não existir explicitamente no código
associações entre eles a tabela surge aos “olhos” das ajudas técnicas da seguinte forma:
DESPESAS DE VIAGEM (custo actual, euros) VIAGEM, Refeições Alojamento Trans Total
data Lisboa 25 Ago 97 37.74 112.00 45.00 26 Ago 97 27.28 112.00 45.00 Subtotal 65.02
224.00 90.00 379.02
O código HTML devidamente rotulado e estruturado desta tabela é:
<TABLE BORDER="1" CELLPADDING=2 CELLSPACING=3>
<CAPTION>DESPESAS DE VIAGEM (custo actual, euros)</CAPTION>
<THEAD>
<TR>
<TH>
<P>
<SPAN ID="t1-r1-l1">VIAGEM</SPAN>,<BR>
<SPAN ID="t1-r1-l2">data</SPAN></P>
</TH>
<TH SCOPE="column">Refeições</TH>
<TH SCOPE="column">Alojamento</TH>
<TH SCOPE="column"><ABBR="Transporte">Trans.</ABBR></TH>
<TH SCOPE="column">Total</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TH SCOPE="rowgroup" HEADERS="t1-r1-l1">Lisboa</TH>
</TR>
<TR>
<TD SCOPE="row" HEADERS="t1-r1-l2">25 Ago 97</TD>
<TD>37.74</TD>
<TD>112.00</TD>
<TD>45.00</TD>
</TR>
<TR>
<TD SCOPE="row" HEADERS="t1-r1-l2">26 Ago 97</TD>
<TD>27.28</TD>
<TD>112.00</TD>
<TD>45.00</TD>
</TR>
<TR>
19
<TD SCOPE="row">Subtotal</TD>
<TD>65.02</TD>
<TD>224.00</TD>
<TD>90.00</TD>
<TD>379.02</TD>
</TR>
</TBODY>
</TABLE>
E se os elementos da tabela estiverem identificados e existir explicitamente no código
associações entre eles, como mostra o exemplo de código anterior, a tabela surge aos “olhos”
das ajudas técnicas da seguinte forma:
Caption: DESPESAS DE VIAGEM (custo actual, euros)
Viagem: Lisboa, Data: 25 Ago 97, Refeições: 37.74, Alojamento: 112.00, Trans. 45.00
Viagem: Lisboa, Data: 26 Ago 97, Refeições: 27.28, Alojamento: 112.00, Trans. 45.00
Viagem: Lisboa, Subtotal, Refeições: 65.02, Alojamento: 224.00, Trans. 90.00, Total: 379.02
Figura 6: Exemplo de uma tabela complexa com a estrutura devidamente rotulada.
2.1.5. Casos em que são utilizadas frames
Ao nível dos pontos de verificação de prioridade 1, a exigência quando se usam FRAMES vai
apenas para a sua identificação, através do elemento <TITLE> (ver figura 7). Isto permite ao
utilizador de ajudas técnicas identificar a FRAME em que se encontra. No entanto, quando na
página proliferam uma quantidade significativa de FRAMES, adjectivo que se pode aplicar
quando se usa mais de 3 FRAMES, a navegação torna-se confusa e nem sempre é fácil de
compreender a forma como a página se encontra organizada.
Os navegadores de texto e as ajudas técnicas mais inteligentes, mesmo quando não
suportam texto, usam geralmente esta legenda, existente no atributo <TITLE>, para construir
menus de texto, o que permite ao utilizador continuar a dispor da possibilidade de progredir no
sítio Web consultando a página que se encontra embutida numa FRAME individual. No
entanto, este procedimento nem sempre se torna um procedimento muito claro e deve-se ir
um pouco mais longe em termos de acessibilidade, nomeadamente respondendo a pontos de
verificação com nível de prioridade mais elevado, que se encontram também descritos neste
documento.
Para fugir aos FRAMES e obter algo semelhante poderá usar CSS – Cascading Style Sheet.
<FRAMESET ROWS="20%,*,30%">
<FRAME SRC="f1.htm" title="Título e frame da barra de navegação
principal">
<FRAMESET COLS="20%,*,">
<FRAME SRC="f2.htm" title="Frame do índice">
<FRAME SRC="f3.htm" title="Frame para visualização do conteúdo">
</FRAMESET>
<FRAME SRC="f4.htm" title="Copyright, agradecimentos e frame de
navegação secundária">
</FRAMESET>
Figura 7: Exemplo de uma página com 4 FRAMES devidamente identificadas com uma
legenda.
20
2.1.6. Casos em que são utilizados applets e programas interpretáveis
Quem desenvolve conteúdos tem de assegurar que as páginas são acessíveis com os scripts
desligados ou com navegadores que não suportam scripts.
Por exemplo, o uso da seguinte notação <A href="javascript:">...</A> para permitir
ao utilizador seleccionar um link é completamente impossível de ser visto por quem, por
qualquer razão, não consegue usar JAVASCRIPT.
A tecnologia Flash é hoje, ao nível dos objectos programáveis, uma das mais preferidas pelos
designers. Aconselha-se a ver as especificações para o efeito publicadas pela Macromedia
(ver secção 5), e aconselha-se também, dado que se trata de uma tecnologia ainda com
poucas ajudas técnicas que a suportem, a construir uma alternativa acessível, nomeadamente
feita com uma tecnologia W3C. Sempre que utilize um elemento desenhado em FLASH
construa um elemento que garanta um equivalente alternativo à sua funcionalidade. A sua
colocação poderá ser feita usando a mesma técnica já referenciada anteriormente por link-D
ou seja um link do tipo [D] ao lado do elemento FLASH.
2.1.7. Casos em que são utilizados multimédia
Já na subsecção 2.1.1. Casos Gerais foi feita referência à necessidade de se encontrar uma
alternativa equivalente para os elementos áudio e vídeo. O ponto de verificação 1.3 reforça a
ideia de se ter uma alternativa equivalente. Neste caso em áudio, da informação contida na
pista visual de uma apresentação multimédia. É o apelo claro à áudio-descrição de vídeos
para pessoas cegas. Esta vertente de permitir que o elemento multimédia seja enriquecido por
forma a servir diversos tipos de receptores que necessitam de amplificar determinado tipo de
informação para fazer uso das suas capacidades perceptivas, é reforçado com o ponto de
verificação 1.4 que apela à sincronização dos diversos elementos.
Apresentações em Real Áudio, em Media Player, em Quick Time, são hoje passíveis de
permitir esta sincronização. Consulte nomeadamente o software de sincronização de
elementos Multimédia MagPie da NCAM (ver secção 5. Referências).
2.1.8. E se, apesar de todos os esforços...
Para quem se dedica à acessibilidade à Web esta é a última sugestão que se pode fazer. No
entanto, dada a originalidade dos projectos, poderá, num caso extremo, ter-se que ir para esta
solução. Mas lembre-se que ao tomá-la não deverá esquecer que:
É necessário manter uma página exactamente com as mesmas funcionalidades que
sigam as regras de acessibilidade deste documento;
 Que é preciso que esse sítio Web alternativo esteja sempre a par, no que diz
respeito aos conteúdos, com o sítio Web “original”, o que poderá resultar numa
duplicação de trabalho.
 Para qualquer efeito, a organização fica sempre com duas presenças oficiais na
Internet, e os motores de busca tanto nos podem deixar na versão original ou na versão
alternativa. No estado actual da tecnologia é bem provável que os motores de busca
tenham maior facilidade em encontrar a versão alternativa.
 Lembre-se que uma versão acessível não é uma versão texto. Os cidadãos com
necessidades especiais não são apenas pessoas cegas. Mesmo um cego pode andar à
procura de uma imagem – um retrato, uma fotografia, um gráfico, etc.

21
Subsecção 2.2. Prioridade 2
A este nível encontramos os requisitos necessários à remoção de obstáculos significativos à
informação. Com a sua eliminação determinados grupos de utilizadores não serão
confrontados com dificuldades de acesso à informação publicada no sítio Web.
Nesta subsecção encontramos 30 pontos de verificação que foram agrupados de acordo com
os diferentes tipos de elementos que se podem encontrar numa página Web. Assim, caso
estejamos perante determinado tipo de elemento afixado numa página Web há que verificar
se estamos a contemplar o requisito de acessibilidade mencionado.
Temos então a seguinte tipificação: casos gerais; casos em que são utilizadas tabelas; casos
em que são utilizadas frames (molduras); casos em que são utilizados formulários; casos em
que são utilizados applets e programas interpretáveis.
2.2.1. Lista de verificação prioridade 1 e 2: Conformidade nível AA
A presente lista, composta por 30 pontos de verificação, nem todos aplicáveis (N.A) às
páginas em concreto pela não existência dos elementos, deve ser validada pelo Designer e/ou
criador do sítio Web e entregue à entidade que solicitou a produção dos conteúdos. Os pontos
de verificação desta lista devem ser observados em todas as páginas do sítio Web. De notar
que os pontos de verificação constantes desta lista são apenas os correspondentes à
prioridade 2. O seu cumprimento “de per si” não lhe confere qualquer tipo de conformidade. O
sítio Web apenas está conforme com o nível AA das Directrizes de Acessibilidade do
Conteúdo da Web 1.0 do W3C, se cumprir os pontos de verificação de prioridade 2 em
acumulação com os de prioridade 1 (constantes no ponto 2.1.8. deste documento).
Casos Gerais
2.2 - Certifique-se que as combinações das cores de
fundo e do texto fornecem um contraste suficiente
quando visualizados por alguém que tenha défices de
percepção de cor ou quando a mesma é visualizada
num ecrã a preto e branco.
3.1 – Sempre que existir uma linguagem com notação
apropriada, use a notação em vez das imagens para
transmitir a informação.
3.2 - Crie documentos validando a notação com a
gramática formal publicada.
3.3 - Use folhas de estilo para controlar a disposição
dos elementos na página e a forma de os apresentar.
3.4 - Use unidades relativas em vez de absolutas nos
valores dos atributos da linguagem de notação e
valores das propriedades das folhas de estilo.
3.5 - Use os elementos cabeçalho (<H1>...<H6>) para
transmitir a estrutura dos documentos e utilize-os de
acordo com as especificações.
Sim
Não N.A.
22
3.6 - Faça uso da correcta notação para as listas
(<ul>...<ol>) e para os seus pontos de enumeração
(<li>).
Aconselha-se a sua utilização em todos os menus
existentes nas páginas. O aspecto visual dos menus,
construídos como listas de elementos, devem ser
controlados por CSS, quer se tratem de menus com
disposição vertical quer horizontal.
3.7 - Use a notação correcta para citações (<Q> para
citação curta e <BLOCKQUOTE> para citação longa,
normalmente superior a três linhas).
Não utilize a notação de citação para formatar efeitos
visuais tais como tabulação/entalhe.
6.5 - Certifique-se que o conteúdo dinâmico é acessível
ou forneça uma apresentação ou página alternativa.
7.2 - Evite concepções que possam provocar o piscar
(modificação do conteúdo em intervalos constantes) do
conteúdo das páginas, até que os agentes do utilizador
possibilitem o seu controlo.
7.4 - Não crie páginas de reiniciar periódicamente
automáticas, até que os agentes do utilizador
possibilitem interromper o processo.
7.5 - Não use a notação para redireccionar páginas
automaticamente até que os agentes do utilizador
disponham da capacidade para interromper o processo.
Em vez disso, aconselha-se a configurar o servidor para
executar esse redireccionamento.
10.1 - Não provocar o aparecimento de janelas de
sobreposição ou outras, e não fazer com que a janela
actual seja modificada sem que o utilizador disso seja
informado, até que os agentes do utilizador tornem
possível a desactivação de janelas secundárias.
11.1 - Use tecnologias W3C quando a mesma esteja
disponível e seja apropriada para uma tarefa. Utilize as
versões mais recentes, desde que suportadas.
11.2 - Evite o uso de notação desactualizada das
tecnologias do W3C.
12.3 - Divida grandes blocos de informação em grupos
mais geríveis e apropriados.
13.1 - Identifique claramente o destino de cada link.
13.2 - Forneça metadados para acrescentar
informações semânticas às páginas e aos sítios Web.
13.3 – Forneça informação sobre a organização geral
do sítio Web (e.g. mapa do site, índice).
13.4 - Use mecanismos de navegação de uma forma
consistente.
Casos em que são utilizadas tabelas
5.3 - Não deve usar tabelas para formatar páginas a não
ser que a tabela faça sentido quando em formato linear.
Caso contrário, se a tabela não fizer sentido, forneça
um equivalente alternativo (o qual poderá ser uma
versão linear).
Para formatar páginas recomenda-se o uso de CSS.
Sim
Não N.A.
23
5.4 - Se uma tabela for utilizada para formatar uma
página, não utilize qualquer notação de estrutura para
efeitos de formatação visual.
Casos em que são utilizadas frames (molduras)
12.2 - Descreva o propósito das fremes e a forma como
as mesmas estão relacionadas umas com as outras,
caso essa relação, suportada apenas nos títulos das
frames, não seja óbvia para o utilizador.
Sim
Não N.A.
Casos em que são utilizados formulários
10.2 - Até que os agentes do utilizador suportem
associações explicitas entre os rótulos e os controlos
de formulário, para todos os controlos com rótulos
implicitamente associados, certifique-se que os rótulos
se encontram apropriadamente posicionados.
12.4 - Associe explicitamente os rótulos aos
respectivos controlos.
Em HTML essa associação faz-se geralmente através do
elemento <LABEL>.
Sim
Não N.A.
Casos em que são utilizados applets e programas
Sim
interpretáveis.
6.4 - No caso dos scripts e dos applets, certifique-se
que os eventos que o manipulam funcionam
independentemente do dispositivo de entrada.
7.3 - Enquanto os agentes do utilizador não permitam
congelar o movimento do conteúdo, não use
movimento nas páginas.
8.1 - Faça com que os elementos programáveis tais
como scripts e applets sejam directamente acessíveis
ou compatíveis com tecnologias de apoio.
9.2 - Certifique-se de que qualquer elemento dotado de
interface própria funciona independentemente do
dispositivo utilizado.
9.3 - No caso dos scripts, especifique manipuladores de
eventos por software em vez de manipuladores de
eventos dependentes de dispositivos.
Não N.A.
2.2.2. Casos gerais
Os casos gerais comportam 19 pontos de verificação e abordam as seguintes temáticas: uso
de cores contrastantes; uso da linguagem de programação (notação) para transmitir
informação em detrimento das imagens; uso de folhas de estilo para controlar a disposição
dos elementos e a apresentação dos mesmos; uso de unidades relativas em detrimento das
unidades absolutas; identificação clara do destino de cada link; uso de elementos
estruturantes como cabeçalhos, listas, citações, divisão de grandes blocos de informação em
grupos mais pequenos; validação da gramática utilizada, uso de tecnologia W3C e não
utilização de notação desactualizada; uso de mecanismos de navegação consistentes e
clarificação da organização do sítio Web, não esquecendo a adição de metadados para
fornecer informação semântica capaz de ser utilizada pelas próprias tecnologias.
24
USO DE CORES CONTRASTANTES
O ponto de verificação 2.2. assume uma particularidade interessante. É o único ponto de
verificação que pertence a dois níveis de prioridade: prioridade 2 e 3.
No que diz respeito ao contraste existente nas imagens, incluindo aqui lettering gráfico,
estamos a falar de prioridade 2. Quando falamos em termos de texto propriamente dito,
estamos a falar de prioridade 3. O facto das imagens gozarem de um nível mais exigente do
ponto de vista de níveis de prioridade, está relacionado com o facto de as ajudas técnicas não
permitirem aos utilizadores o controlo e personalização das cores afixadas neste tipo de
elementos. No caso do texto propriamente dito, o utilizador dispõe hoje de uma série de
funcionalidades, nomeadamente de navegadores de uso corrente, que permitem essa
personalização. O uso de CSS facilita bastante este trabalho, podendo os utilizadores usar
inclusivamente folhas de estilo personalizadas.
A combinação de vermelho com verde deve ser de todo evitada. Use cores com um fundo
suave. Não utilize padrões de cor próximos para a cor da letra e para a cor de fundo.
Um dos contrastes excelentes continua a ser o padrão: cor de fundo branco e cor de letra
preta.
USO DA LINGUAGEM DE PROGRAMAÇÃO (NOTAÇÃO) PARA TRANSMITIR
INFORMAÇÃO EM DETRIMENTO DAS IMAGENS
Faça uso de folhas de estilo para formatar texto e controlar o layout. Evite, por exemplo,
utilizar imagens para representar texto - em vez disso use texto e folhas de estilo.
O uso de MathML, por exemplo, para construir equações matemáticas poderá vir a ser uma
realidade dentro em breve. Navegadores como o Amaya (do W3C) e mesmo as novas
versões do Opera já suportam algumas das suas funcionalidades. A representação actual de
equações matemáticas, em bitmap, que proliferam na Web não são acessíveis. Mesmo os
seus equivalentes textuais são, do ponto de vista de estrutura matemática, pobres.
USO DE FOLHAS DE ESTILO PARA CONTROLAR A DISPOSIÇÃO DOS ELEMENTOS E A
APRESENTAÇÃO
Use folhas de estilo para controlar a cor e o tamanho do texto. Elementos tais como:
BASEFONT, FONT, COLOR, encontram-se desactualizados nas versões HTML 4.0. Comece
desde já a livrar-se deles. Em vez de os repetir 100 vezes numa página HTML, faz apenas
uma única referência numa folha de estilo externa.
Não use elementos cabeçalho do tipo H1...H6 como uma forma expedita de alterar o tamanho
das fontes. A sua utilização desta forma só destrói por completo a estrutura do documento.
Utilize folhas de estilo externas em vez da sua colocação no cabeçalho <HEAD> das páginas
de HTML. Uma das grandes vantagens de tal procedimento prende-se com o facto de poder
alterar elementos de cor, tamanho de letra, tipo de letra, entre outros, mexendo apenas num
único ficheiro. Mesmo que tenha milhões de páginas com um dado padrão de cor, desta forma
todas elas ficam modificadas com uma simples e rápida modificação.
USO DE UNIDADES RELATIVAS EM DETRIMENTO DAS UNIDADES ABSOLUTAS
Por exemplo, em CSS, use 'em' ou dimensões em percentagem em detrimento de 'pt' ou 'cm',
as quais são unidades absolutas. Desta forma consegue uma construção independente da
25
resolução do ecrã do utilizador e a página ajusta-se à resolução do utilizador, sem que este
tenha de efectuar varrimentos horizontais da página; sempre aborrecidos.
No caso de utilizadores com baixa visão, que necessitam de uma maior ampliação da letra,
poderão fazê-lo tendo a garantia de que a página se ajusta automaticamente ao tamanho do
ecrã. Caso contrário, estes utilizadores vão ter que recorrer a varrimentos horizontais,
extremamente penosos de operar por este tipo de utilizador.
IDENTIFICAÇÃO CLARA DO DESTINO DE CADA LINK
O texto dos Links deverão ter um significado suficiente para fazer sentido quando lidos fora do
contexto -- quer por si só quer como parte de uma sequência de links. Não use links com texto
do tipo “Ver mais...”, ou “Mais informação”, ou “Ver texto”, ou “>”.
O texto do link deve também ser conciso (ver figura 8).
1. Ganhe um prémio dado por um dos nossos milhares de patrocinadores.
O texto que compõe o link, "ganhe um prémio", é conciso, compreensível fora do contexto e
suficientemente interessante para lhe despertar a atenção quando lida isoladamente.
2. Ganhe um prémio dado por um dos nossos milhares de patrocinadores.
É desnecessário seleccionar a frase na sua totalidade como link, com a agravante de os links
grandes poderem ser quebrados no ecrã, o que poderá ser fonte de confusão na mente de
alguns utilizadores.
3. Clique aqui para ganhar um prémio dado por um dos nossos milhares de patrocinadores.
"Clique aqui". Onde? Porque razão devo "clicar aqui"? E qual será o resultado se eu não
"clicar" mas usar o teclado para seleccionar o link? Perguntas suficientes para que deixemos
de usar esta formula!
Figura 8: Texto dos links.
Para incrementar a acessibilidade pode usar o atributo <TITLE> existente no elemento link
para disponibilizar mais informação sobre o destino do link:
<A href="next.htm" title="Tudo sobre receita fiscal: IRS e IRC. ">Vá
para capítulo 2: Finanças.</A>
Figura 9: O uso de <TITLE> no elemento <A>
USO DE ELEMENTOS ESTRUTURANTES COMO CABEÇALHOS, LISTAS, CITAÇÕES,
DIVISÃO DE GRANDES BLOCOS DE INFORMAÇÃO EM GRUPOS MAIS PEQUENOS
Use os elementos cabeçalho <H1>...<H6> de forma ordenada e hierarquizada. São algumas
as tecnologias, nomeadamente as de indexação, que fazem uso dos cabeçalhos para
interpretar a estrutura dos documentos. Por exemplo as ajudas técnicas fazem muito uso
destes elementos para facilitar a navegação. É o caso dos leitores de ecrã, para pessoas
cegas, que se socorrem dos cabeçalhos para permitirem ao utilizador navegar de cabeçalho
em cabeçalho, o que torna o varrimento do texto bem mais simples e compreensível..
26
As listas são outro elemento de estrutura importante que facilita a leitura visual da informação.
Mas o seu uso também permite às ajudas técnicas um conjunto de funcionalidades adicionais:
navegar de lista em lista; antes de entrar numa lista, informação sobre quantos elementos
estão na lista; informação da existência de subelementos na lista; indicação de fim de lista. As
listas são um elemento essencial para estruturar menus. Deve fazer com que todos os menus
que se encontram no sítio Web sejam listas, quer eles tenham uma disposição horizontal quer
eles tenham uma disposição vertical. O seu estilo deve ser controlado por CSS.
O uso do elemento <BLOCKQUOTE> é na generalidade usado de forma incorrecta. Quase
sempre prevalece o seu aspecto visual (informação com entalhe) em detrimento da sua
função de identificação de uma citação. Recomenda-se o uso de <BLOCKQUOTE> apenas
para uma citação longa, superior a 3 linhas, e o uso do elemento <Q> para uma citação curta.
Os elementos cabeçalhos e listas podem ser utilizados para dividir grandes blocos de
informação. Dentro de um elemento <SELECT> o <OPTGROUP> pode agrupar elementos
<OPTION>. No caso dos formulários <FORM> os controlos devem ser agrupados com
FIELDSET e LEGEND.
VALIDAÇÃO DA GRAMÁTICA UTILIZADA, USO DE TECNOLOGIA W3C E A NÃO
UTILIZAÇÃO DE NOTAÇÃO DESACTUALIZADA
Valide o código de notação usando o serviço “Markup Validation Service” do W3C, o qual
confronta os documentos HTML e XHTML com as recomendações do W3C. Encontra o
serviço disponível on-line em: http://validator.w3.org/ .
USO DE MECANISMOS DE NAVEGAÇÃO CONSISTENTES E CLARIFICAÇÃO DA
ORGANIZAÇÃO DO SÍTIO WEB
Um estilo consistente de apresentação nas diversas páginas permite aos utilizadores
encontrar facilmente os diversos elementos da mesma, nomeadamente os mecanismos de
navegação. Este procedimento diminui a curva de aprendizagem para qualquer utilizador. No
caso de pessoas com dificuldades de leitura e aprendizagem tal procedimento resulta em
enormes vantagens. A predição da localização da informação é maximizada desta forma.
Um mapa do sítio Web em modo texto (ver figura 10) é um bom instrumento, uma vez que é
relativamente fácil de manter (e não requer equivalente alternativo como sucede com mapas
do tipo gráfico). Certifique-se de que o texto que forma o link deve corresponder ao título da
página principal ou a um dos cabeçalhos H1 existentes na página-alvo, de forma a não
confundir o utilizador.
Página de Boas-vindas
Página de Entrada (página principal)
Produtos
Sistemas
Sistema 1000
Sistema 2000
Sistema 3000
CPUs
Figura 10: Exemplo de um Mapa ou Índice do sítio Web
27
2.2.3. No caso de serem utilizadas tabelas
Em termos de prioridade 2, a indicação no que diz respeito a tabelas vai para tabelas
utilizadas para formatar páginas. O primeiro ponto de verificação (5.3) vai para a não
utilização de tabelas para este efeito caso a sua forma linear não faça sentido. Recomenda-se
mesmo o uso de CSS para formatar páginas. Hoje em dia são inúmeros os navegadores e
mesmo as tecnologias de acesso que fazem uso de CSS.
O ponto de verificação 5.4 vai para as preocupações que se devem ter quando se usam
tabelas para formatar páginas. Ao contrário das tabelas que comportam dados, as tabelas
para formatar páginas não devem ter a estrutura rotulada. Na prática o uso do atributo <TD> e
<TR> serão suficientes para dispor os elementos.
2.2.4. No caso de serem utilizadas frames
No Ponto de Verificação 12.1 (Prioridade 1), usámos o atributo "TITLE" do elemento
<FRAME> para fornecer uma breve explicação da função de cada frame.
Nalguns casos pode-se sentir que o propósito do conteúdo do FRAME ou FRAMESET
(conjunto de frames) é demasiado complicado para ser explicado apenas em meia dúzia de
palavras. Nestes casos, é aconselhável usar o atributo "LONGDESC" do elemento FRAME
para fornecer um link para um documento que contenha uma descrição completa da página
de frames, ou das relações existentes entre as várias frames (veja figura 11).
<FRAME src="main.htm" longdesc="maindesc.htm" title="Frame do Conteúdo
Principal.">
e a página MAINDESC.HTM teria um conteúdo do género:
Existem quatro frames neste exemplo. O frame que se encontra no
topo da página é para o título da página e a barra de navegação
primária. O frame mais estreito (ao centro e à esquerda) é para
ser utilizado para a lista de links. O frame mais largo (ao
centro e à direita) é onde o conteúdo dos documentos escolhidos
na lista de links irão surgir. O frame que se encontra na base
da página destina-se à mensagem de copyright, à navegação
secundária e a outras informações constantes.
Figura 11: Exemplo de uma descrição de uma página construída com FRAME com um
sistema complexo.
2.2.5. No caso de serem utilizados formulários
Os dois pontos de verificação de prioridade 2, estão ambos relacionados com os controlos,
nomeadamente os campos de edição, e as legendas ou rótulos a eles associados.
Assim o ponto 10.2 sugere que o posicionamento dos comandos e dos respectivos rótulos
seja o usualmente empregue e não formas menos próprias para apresentar os elementos.
A) Forma usual do botões de rádio: permite detecção implícita por parte das ajudas técnicas
28
B) Forma não usual: não permite detecção implícita por parte das ajudas técnicas. A detecção
só é possível caso exista no código associação explicita e caso a AT suporte esse tipo de
funcionalidade.
C) Campo de edição bem posicionado para detecção implícita. A ajuda técnica vai buscar, por
defeito, o rótulo que se encontra posicionado imediatamente atrás do controlo. Verifica-se
neste exemplo que existe um valor dentro do campo de edição (ponto prioridade 3), bem
como a existência de uma tecla de atalho (alt+1 no IE).
Figura 12: Posicionamento implícito dos campos de edição e botões de rádio.
Já o ponto 12.4 dá indicação para uma explicitação no código, da associação entre os
controlos e os respectivos rótulos. Hoje em dia, dada a evolução das tecnologias de apoio,
somos levados a pensar que estamos mais ao nível deste último ponto de verificação,
podendo sempre que assim se justifique descurar o ponto 10.2.
2.2.6. No caso de serem utilizados applets e programas interpretáveis
Nem todos os utilizadores têm um ambiente gráfico com rato ou outros dispositivos
apontadores. Alguns utilizadores dependem do teclado. A navegação pelos links é feita
através de teclados alternativos (nomeadamente teclado de conceitos e teclados virtuais de
ecrã) ou através de entrada por voz. É também com estes dispositivos que activam controlos
de formulários e controlam as interfaces dos objectos programados.
Quem desenvolve conteúdos, deve sempre assegurar que os utilizadores podem interagir com
a página através de dispositivos que não os dispositivos apontadores. Uma página desenhada
para ser acessível via teclado (em adição ao acesso via rato) é na generalidade acessível a
utilizadores com outros dispositivos de entrada. Para além disso, ao desenhar uma página
acessível via teclado está também a acrescentar valor ao seu design permitindo ao utilizador
comum um leque maior de opções de escolha.
Para assegurar que as pessoas obtém a mesma mensagem equivalente em sistemas que não
suportam scripts e event-handlers (manipuladores de eventos), inclua algum conteúdo
equivalente no elemento <NOSCRIPT>.
No ‘EVENT-HANDLER’ do ‘SCRIPT’ inclua a possibilidade de o manipular com o rato
('OnMouseOver') mas também de o fazer com o teclado ('OnFocus' ).
Caso precise de usar atributos dependentes do equipamento, forneça mecanismos de entrada
redundantes (i.e. especifique dois manipuladores para o mesmo elemento). São disso
exemplo:



Use "onmousedown" com "onkeydown".
Use "onmouseup" com "onkeyup"
Use "onclick" com "onkeypress"
A acessibilidade de objectos com o seu próprio interface é independente da acessibilidade do
agente do utilizador. A acessibilidade deve por isso ser construída nos objectos ou ser
fornecida como uma alternativa. Se é programador deve estar consciente dos recursos
29
disponíveis que o ajudam a verificar se os seus programas são acessíveis (Veja o ponto 5
para algumas referências sobre diferentes tecnologias).
Se um applet (criado com OBJECT ou APPLET) requerer a interacção do utilizador (e.g., a
capacidade de manipular uma experimentação física) a qual não possa ser duplicada num
formato alternativo, faça o applet directamente acessível.
30
31
Subsecção 2.3. Prioridade 3
A este nível encontramos os requisitos necessários à remoção de determinados ruídos no
acesso à informação. A remoção destes ruídos melhora o acesso a um ou mais grupos à
informação.
Nesta subsecção encontramos 19 pontos de verificação que foram agrupados de acordo com
os diferentes tipos de elementos que se podem encontrar numa página Web. Assim, caso
estejamos perante determinado tipo de elemento afixado numa página Web há que verificar
se estamos a contemplar o requisito de acessibilidade mencionado.
Temos então a seguinte tipificação para os pontos de verificação de prioridade 3: casos
gerais; casos em que são utilizados mapas de imagens; casos em que são utilizadas tabelas;
casos em que são utilizadas frames (molduras); casos em que são utilizados formulários.
2.3.1. Lista de verificação prioridade 1, 2 e 3: Conformidade nível AAA
A presente lista, composta por 19 pontos de verificação, nem todos aplicáveis (N.A) às
páginas em concreto pela não existência dos elementos, deve ser validada pelo Designer e/ou
criador do sítio Web e entregue à entidade que solicitou a produção dos conteúdos. Os pontos
de verificação desta lista devem ser observados em todas as páginas do sítio Web. De notar
que os pontos de verificação constantes desta lista são apenas os correspondentes à
prioridade 3. O seu cumprimento “de per si” não lhe confere qualquer tipo de conformidade. O
sítio Web apenas está conforme com o nível AAA das Directrizes de Acessibilidade do
Conteúdo da Web 1.0 do W3C, se cumprir os pontos de verificação de prioridade 3 em
acumulação com os de prioridade 1 e 2 (constantes no ponto 2.1.8. e 2.2.6. respectivamente,
deste documento).
Casos gerais
4.2 - Especifique por extenso cada abreviatura ou
acrónimo quando da sua primeira ocorrência num
documento.
4.3 - Identifique o idioma principal do documento.
9.4 - Crie uma sequência lógica de "tabs" para
percorrer os links, controlos de formulários e objectos.
9.5 - Defina teclas de atalho para links importantes
(incluindo os que se encontram nos mapas de imagem
"client-side"), controlos de formulário, e grupos de
controlos de formulários.
10.5 – Até que os agentes do utilizador consigam
distinguir links adjacentes, inclua caracteres "nãolinkados", circundados por espaços, entre os links
adjacentes.
11.3 - Disponibilize a informação necessária de forma a
que os utilizadores recebam os documentos de acordo
com as suas preferências.
13.5 - Providencie barras de navegação para salientar e
dar acesso aos mecanismos de navegação.
De preferência faça use o elemento de notação para listas
(<ul>...<ol>) para estruturar esses mecanismos. Use CSS
para lhes dar estilo.
Sim
Não N.A.
32
13.6 - Agrupe links relacionados, identifique o grupo
(em benefício dos agentes do utilizador) e, até que os
agentes do utilizador o façam, forneça uma forma de
saltar um grupo.
13.7 - Caso seja fornecida uma função de pesquisa,
active diferentes tipos de pesquisa de modo a
corresponderem a diferentes níveis de competências e
às preferências dos utilizadores.
13.8 - Coloque informação diferenciada no início dos
cabeçalhos, parágrafos, listas, etc.
13.9 - Providencie informação sobre colecções de
documentos (i.e. documentos compostos por múltiplas
páginas).
13.10 - Providencie um meio de saltar por cima de
múltiplas linhas em arte ASCII.
14.2 - Reforce a mensagem texto através de gráficos
e/ou áudio na medida em que os mesmos facilitem a
compreensão da página.
14.3 - Crie um estilo de apresentação que seja
consistente ao longo das páginas.
No caso de serem utilizados mapas de imagens
1.5 - Até que os agentes do utilizador alcancem o
equivalente textual dos links existentes nas regiões
activas dos mapas de imagem “client-side”, forneça
links textuais redundantes para cada região activa do
mapa.
Sim
Não N.A.
No caso de serem utilizadas tabelas
5.5 - Providencie sumários para as tabelas.
5.6 - Use abreviaturas na designação dos cabeçalhos
das tabelas.
10.3 - Até que os agentes do utilizador identifiquem
correctamente o texto colocado lado a lado,
disponibilize uma alternativa linear do texto (na página
actual ou numa outra) para todas as tabelas que
disponham o texto de forma paralela, ao longo dos
limites das colunas.
Sim
Não N.A.
No caso de serem utilizados formulários
10.4 - Até que os agentes do utilizador consigam
manipular controlos vazios correctamente, inclua
caracteres predefinidos de preenchimento nas caixas
de edição e nas áreas de texto.
Sim
Não N.A.
2.3.2. Casos gerais
São diversos os temas gerais tratados no nível dos pontos de verificação de prioridade 3:
forma de escrita; identificação de idiomas dos conteúdos e sua personalização; navegação;
documentos de grande dimensão.
33
FORMA DE ESCRITA
Tentando ir em direcção ao objectivo do uso de linguagem natural, sempre que se usam
abreviaturas (<abbr>) e acrónimos (<acronym>), de acordo com o ponto 4.2, deverá ser
fornecido a sua designação por extenso (ver exemplo figura 12).
Definição de acrónimo: “Palavra formada pela justaposição de uma ou mais sílabas de outras
palavras”. (Dicionário Língua Portuguesa, Porto Editora, 5ª Ed., 1976)
<abbr title=”Unidade de Missão Inovação e Conhecimento”>UMIC</abbr>
<acronym title=”Sistema Modular de Ensino à Distância>SisMeDis</acronym>
Figura 12: O uso de abreviaturas.
De acordo com o ponto 13.8 deve-se diferenciar cada bloco de informação logo no início dos
elementos que o estruturam (cabeçalhos, listas e mesmo parágrafos).
Usar:

Visite o Programa do evento, para mais informações.
Em vez de:

Para mais informações visite o programa do evento.
Figura 13: Exemplo da técnica front-end.
Relacionada com a aparência das páginas está a consistência ao longo das páginas (ponto
14.3). Tipos de letra, tamanhos de letra, cores, posicionamento de elementos são todos
importantes para a manutenção da consistência do sítio Web. Aconselha-se vivamente o uso
de CSS como uma das formas rápidas de alcançar este objectivo.
IDENTIFICAÇÃO DE IDIOMAS DOS CONTEÚDOS E SUA PERSONALIZAÇÃO
De acordo com o ponto 4.3 deve ser explicitado o idioma principal em que a página se
encontra escrita. Pode usar para o efeito o elemento <HTML lang=”pt”>. De notar que as
modificações de idioma ao longo do texto são de prioridade 1. Uma boa ferramenta para testar
esta funcionalidade é o Opera 7.11, o Home Page Reader da IBM e mesmo o JAWS 5.
Em vez de colocar informação do tipo “Versão Inglesa”, “Versão Francesa”, “Versão
Portuguesa” deve, de acordo com o ponto 11.3, implementar a técnica de Negociação de
Conteúdos, que permite ao navegador e ao servidor negociar qual o idioma a apresentar de
acordo com as preferências definidas no agente do utilizador (navegador). Veja mais
informação a respeito em:
http://www.w3.org/International/O-HTTP.html .
NAVEGAÇÃO
Agrupe os menus de navegação de forma lógica, crie uma sequência lógica de navegação
(verifique principalmente a sequência de TABs nos campos e controlos de um formulário –
34
percorra-o com a ajuda do teclado e verifique se a sequência corresponde à lógica de
preenchimento).
Privilegie o uso do elemento <UL> ou <OL> (listas) para construir barras de navegação.
Dê ao utilizador a possibilidade de saltar os grupos de menus, nomeadamente com links para
bookmarks do género: Saltar Menu.
Forneça teclas de atalho para alguns links importantes da página. O motor de busca é um dos
campos prioritários em termos de utilização de uma tecla de atalho.
<a href=”mapa.html” accesskey=”2”>Mapa do sítio</a>
Figura 14: Definição de teclas de atalho
DOCUMENTOS DE GRANDE DIMENSÃO
O ponto 13.9 aconselha a que se crie uma certa unicidade dos documentos de grande
dimensão disponibilizados no sítio Web. Assim é aconselhável fazer índices para os
documentos, criar estruturas (ver figura 14) que permitam ligar semanticamente as diversas
páginas dos documentos HTML. Disponibilize também versões em formatos compactados,
como ZIP e providencie sumários em HTML dos mesmos.
<head>
(…)
<link rel="prev" href="pontos_prioridade_2.htm">
<link rel="contents" href="indice.htm">
<link rel="next" href="conformidade.htm">
(...)
</head>
Figura 15: Ligação das páginas de um documento feito em HTML. Confere ao documento
uma unicidade compreensível pela própria tecnologia.
No caso de usar documentos PDF siga os seguintes procedimentos:
-
faça correr no Acrobat a rotina “Make Accessible” (existente no menu Documents);
disponibilize um formato alternativo: Word e/ou HTML;
na página de download do documento (nos diversos formatos) disponibilize um
sumário, uma ficha técnica e o índice do documento em HTML;
Dê indicação do tamanho e do formato do ficheiro para download: p.e. Caderno de
Encargos (PDF; 2,5 MB). Esta indicação é válida para qualquer tipo de ficheiro para
download.
2.3.3. No caso de serem utilizadas imagens e mapas de imagem
No que diz respeito aos mapas de imagens o ponto 1.5 faz depender a sua necessidade dos
agentes do utilizador. Existem ainda hoje no mercado agentes do utilizador, nomeadamente
navegadores que permitem a visualização das páginas em texto, que não interpretam o ALT
colocado nas regiões dos mapas de imagens. Aconselha-se por isso, face ao actual momento
tecnológico, a disponibilização de links redundantes em texto correspondentes aos existentes
nas regiões do mapa de imagens.
35
2.3.4. No caso de serem utilizadas tabelas
Dos três pontos de verificação de prioridade 3 existentes para o tratamento de tabelas, dois
deles (5.5 e o 5.6) são prioritários. O uso do atributo <SUMMARY> (ponto 5.5) – ver figura 15
- permite fornecer informação adicional sobre a tabela. Esta informação não é visível mas é
interpretada por tecnologias de apoio. O ponto 5.6 incentiva ao uso de abreviaturas nos
cabeçalhos das colunas. A forma como se tratam abreviaturas já foi indicado neste
documento.
Chávenas de café consumidas por cada deputado
Nome Chávenas Tipo de Café Açúcar?
Sr. A
10
Sra. B 5
Expresso
Não
Capuccino
Sim
<TABLE border="1"
summary="Esta tabela contém os dados relativos ao número de
chávenas de café consumidas por cada deputado, o tipo de café
(expresso ou capuccino), e se o toma com ou sem açúcar.">
... table markup ...
</TABLE>
Figura 16: O atributo Summary do elemento TABLE
2.3.5. No caso de serem utilizados formulários
Hoje em dia são enumeras as tecnologias de acesso que implicitamente ou fazendo uso da
notação explicita de ligação entre os rótulos e os controlos de formulário, conseguem discernir
qual é o rótulo do comando em que se encontra o cursor. Assim, a atribuição de um valor por
defeito, nomeadamente nos campos de edição, é cada vez menos necessário. Caso não
utilize notação explicita nomeadamente através do elemento <LABEL> aconselha-se a usar a
proposta do ponto 10.4.
36
37
Secção 3. Avaliação
Os designers e criadores de páginas Web podem efectuar dois tipos de teste às páginas Web:
uma avaliação manual, feita com base em algumas ajudas técnicas e uma avaliação
automática, feita com base em software que produz relatórios de acessibilidade.
Podem também solicitar relatórios de acessibilidade, de preferência ao longo do processo de
desenvolvimento do sítio Web, ao Programa ACESSO da UMIC. Para tal veja os contactos no
sítio Web do Programa ACESSO, nomeadamente a página dedicada ao HelpDesk da AP
(http://www.acesso.umic.pcm.gov.pt/abc/lista.htm).
3 .1 . A v a l i a ç ã o M a n u a l
Aconselha-se sempre que possível a recorrer a utilizadores com necessidades especiais para
efectuar alguns testes às páginas Web. Sempre que tal não seja possível, aconselha-se o uso
do navegador Opera que possibilita diversas transformações harmoniosas do seu sítio Web,
pressionando para o efeito em apenas uma tecla:
-
navegue pelos links com A e Q;
navegue pelos diversos elementos com D e E;
pressione G para retirar todas as imagens;
pressione CTRL+G para linearizar o site – um site que se arruma todo à esquerda é
geralmente um site que responde bem às questões de acessibilidade, caso contrário
continue a trabalhar;
Pode efectuar um download gratuito do Opera em: http://www.opera.com .
Pode ainda usar o JAWS (leitor de ecrã com sintetizador de voz em Português-brasileiro).
Aconselhamos a utilizá-lo com o Internet Explorer.
Pode efectuar o download da versão demo do JAWS em: http://www.freedomscientific.com .
Trata-se de uma versão demo para 30 minutos, ao fim dos quais terá que reinicializar o
computador para continuar.
Veja o Manual "Acessibilidade aos sítios Web da AP para Cidadãos com Necessidades
Especiais - Requisitos de Visitabilidade" para mais informações sobre como configurar estas
duas ferramentas. Disponível on-line em:
http://www.acesso.umic.pcm.gov.pt/abc/manualv1.htm .
3 .2 . A v a l i a ç ã o A u to m á ti c a
Outra das formas de obter um relatório completo de acessibilidade é usar ferramentas
automáticas. Aconselhamos três das ferramentas actualmente existentes:
-
Bobby (Inglês): http://bobby.watchfire.com/bobby/html/en/index.jsp .
Cynthia Says (inglês): http://www.cynthiasays.com/ .
Test Accesibilidad à la Web (TAW) (Espanhol): http://www.tawdis.net/ .
38
Pode acompanhar o desenvolvimento das ferramentas de avaliação na página do Programa
ACESSO da UMIC na secção “O meu site é Acessível?” em:
http://www.acesso.umic.pcm.gov.pt/acessivel.htm .
39
Secção 4. Conformidade
O cumprimento dos pontos de verificação de nível 1 “de per si” são sinónimo de conformidade
com o nível A. Já o cumprimento dos níveis de prioridade 2 e 3 “de per si” não confere ao sítio
Web qualquer tipo de conformidade. Para que exista conformidade AA é necessário que se
verifiquem os pontos de verificação nível 1 e 2 cumulativamente. O mesmo se passa com a
conformidade AAA que exige o cumprimento dos pontos de verificação 1, 2 e 3.
SIMBOLO DE ACESSIBILIDADE À WEB
Depois de validar as listas dos pontos de verificação existentes neste documento, solicite ao
Programa ACESSO (http://www.acesso.umic.pcm.gov.pt) uma verificação.
Do Programa ACESSO poderá obter um relatório de acessibilidade que visa incrementar a
acessibilidade do seu sítio Web ou a indicação de que o seu sítio Web está em condições de
entrar na Galeria da Acessibilidade durante o próximo.
Recebida a confirmação de acessibilidade por parte do Programa ACESSO da UMIC afixe o
Símbolo de Acessibilidade à Web na Página de Entrada do sítio Web. Findo o periodo de um
ano, o site terá que ser novamente certificado pela equipa do Programa ACESSO da UMIC,
para que a afixação do símbolo seja renovada.
O ALT da imagem do símbolo é composto pelo seguinte texto “Símbolo de acessibilidade à
Web”
A imagem deverá formar um link para uma página de enquadramento, alojada no site, com o
conteúdo constante em:
http://www.acesso.umic.pcm.gov.pt/sawdescrica.htm .
CONFORMIDADE W3C
De acordo com o nível de conformidade A, AA ou AAA deverá também afixar o respectivo
Símbolo do W3C, nas páginas conformes ou caso seja indicativo de conformidade do sítio
Web basta afixar na primeira página:
Nível de conformidade "A": quando foram satisfeitos todos os pontos de verificação de
prioridade 1;
ALT=”Símbolo de conformidade nível A das Directrizes de Acessibilidade Web”
Nível de conformidade "Duplo A": quando foram satisfeitos todos os pontos de verificação de
prioridades 1 e 2;
ALT=”Símbolo de conformidade nível AA das Directrizes de Acessibilidade Web”
40
Nível de conformidade "Triplo A": quando foram satisfeitos todos os pontos de verificação de
prioridades 1, 2 e 3.
ALT=”Símbolo de conformidade nível AAA das Directrizes de Acessibilidade
Web”
41
Secção 5. Referências
Endereços Gerais

Programa Acesso da UMIC - Acessibilidade a Cidadãos com Necessidades Especiais à
Sociedade de
http://www.acesso.umic.pcm.gov.pt .

Documento da Resolução do Conselho de Ministros Nº 97/99 sobre acessibilidade dos
sítios da administração pública na Internet pelos cidadãos com necessidades especiais.
http://www.acesso.umic.pcm.gov.pt/acesso/res97_99.htm .

Documento da Resolução do Conselho de Ministros Nº 110/2003 relativo ao Plano Nacional
para a Participação dos Cidadãos com Necessidades Especiais na Sociedade da
Informação.
http://www.acesso.umic.pcm.gov.pt/legis/pnpcnesi.htm .

Directrizes de acessibilidade do conteúdo da Web - 1.0 do W3C.
http://www.utad.pt/wai/wai-pageauth.html.

Iniciativa para a acessibilidade da Web do W3C.
http://www.w3.org/wai .

CERTIC / UTAD – Centro de Engenharia em Reabilitação em Tecnologias de Informação e
Comunicação.
http://www.acessibilidade.net .

Fundação SID@R - Acesso Universal.
http://www.sidar.org .

Microsoft Accessibility - Technology for Everyone
http://www.microsoft.com/enable/ .

IBM – Accessibility Center
http://www-3.ibm.com/able/accessweb.html .

Adobe: access.adobe.com
http://access.adobe.com/ .

Macromedia – Accessibility
http://www.macromedia.com/macromedia/accessibility/ .

Apple – People with Special Needs
http://www.apple.com/disability/ .

SUN – Accessibility
http://www.sun.com/access/ .
Listas de discussão

ACESSO-WEBMASTERS / HelpDesk da AP para a área da acessibilidade
http://www.egroups.com/group/acesso-webmasters

ACESSIBILIDADE
http://www.egroups.com/group/acessibilidade
42

ACCESO WEB (Espanha)
http://www.egroups.com/group/accesoweb

W3C-WAI-IG
http://www.w3.org/WAI/IG/
Análise de Acessibilidade

Bobby – Avaliação Automática de Sites.
http://bobby.watchfire.com/bobby/ .

TAW – Teste de Acessibilidade à Web
http://www.tawdis.net/ .

Cynthia Says
http://www.cynthiasays.com/ .

Accessibility Prompt.
http://aprompt.snow.utoronto.ca/ .

WebTV Viewer Tool.
http://developer.webtv.net/design/tools/viewer/Default.htm .
Filtros

BETSIE - The BBC's Text-to-Speech Internet Enhancer
http://www.bbc.co.uk/education/betsie/ .

TABLIN – Linearizador de tabelas em HTML do W3C
http://www.w3.org/WAI/References/Tablin/ .
Tecnologias de Acesso

Teclados, dispositivos apontadores, manípulos alternativos.
http://www.infogrip.com/

CERTIC/UTAD – Avaliação de Ajudas Técnicas
http://www.acessibilidade.net/at/avalat.html .

Tiresias – Base de Dados de Ajudas Técnicas para Deficientes Visuais.
http://www.tiresias.org .

FreedomScientific (JAWS) – Leitor de ecrã para sintetizador e linha Braille.
http://www.freedomscientific.com .

Software de Ampliação – Lunar
http://www.dolphinuk.co.uk/ .

Leitor de ecrã – HAL
http://www.dolphinuk.co.uk/ .
Browsers com funcionalidades especiais

Áudio Browser – Navegador com voz e ampliação incorporado – grátis – Univ. Minho
http://ideafix.di.uminho.pt/ab/ .

Braille Surf
http://www.snv.jussieu.fr/inova/bs4/uk/
43

Home Page Reader
http://www-3.ibm.com/able/hpr.html

Lynx Viewer
http://www.delorie.com/web/lynxview.html .

Opera
http://www.opera.com .
L e g e nd a g e m d e V í d e o s

Tecnologia SAMI.
http://www.microsoft.com/enable/sami/default.htm .

Especificação SMIL (Synchronized Multimedia Integration Language).
http://www.utad.pt/~leonelm/w3ctranslations/smil/ .

Microsoft: Accessibility Aids.
http://www.microsoft.com/enable/products/aids.htm .

Media Access Generator (MAGpie)
http://www.wgbh.org/wgbh/pages/ncam/webaccess/magindex.html .