0
Sistemas de Informação
Wander Fernandes Rodrigues Júnior
ACESSIBILIDADE EM SISTEMAS WEB PARA DEFICIENTES
VISUAIS
Cabo Frio
2009
1
WANDER FERNANDES RODRIGUES JÚNIOR
ACESSIBILIDADE EM SISTEMAS WEB PARA DEFICIENTES VISUAIS
Monografia de Conclusão de Curso apresentada ao
Curso de Sistemas de Informação da Universidade
Veiga de Almeida, como requisito para obtenção do
título de Bacharel.
Orientador: Prof. M.Sc. Matheus Bousquet Bandini.
Cabo Frio
2009
2
WANDER FERNANDES RODRIGUES JÚNIOR
ACESSIBILIDADE EM SISTEMAS WEB PARA DEFICIENTES VISUAIS
Monografia de Conclusão de Curso apresentada ao
Curso de Sistemas de Informação da Universidade
Veiga de Almeida, como requisito para obtenção do
título de Bacharel.
Aprovada em: ____/____/2009.
Banca Examinadora:
Prof. MATHEUS BOUSQUET BANDINI
M.Sc. Sistemas e Computação - IME/RJ.
Professor de Sistemas de Informação da Universidade Veiga Almeida.
Prof. FÁBIO BARRETO.
M.Sc. em Engenharia de Sistemas e Computação – COPPE/URFJ.
Professor de Sistemas de Informação da Universidade Veiga Almeida.
Profa. MYRNA CECÍLIA MARTINS DOS SANTOS AMORIM.
M.Sc. Sistemas e Computação - IME/RJ.
Professor de Sistemas de Informação da Universidade Veiga Almeida.
Grau: ___________________.
3
Aos meus pais, pela instrução, compreensão
e tolerância mesmo em momentos árduos. Por suas
ações e caráter honrados, que me ensinam valores
para a vida mais que quaisquer palavras poderiam
fazê-lo.
A minha querida irmã e amiga, por suas
virtudes, por todos os momentos valiosos que
passamos e por me querer bem acima de todas as
circunstâncias.
4
AGRADECIMENTOS
A Deus, sobretudo, por sua graça, seu amor e
fidelidade, demonstrados repetidamente a mim.
A minha família amada, por ser meu
sustentáculo a todo instante.
Aos amigos Felipe Araújo, Marcelo Soares,
Swellen Dezerbelles e Tamiris Nazareth, por todas
as consultas gratuitas e conselhos valiosos que me
tornaram um profissional e um aluno melhor.
A todos os colegas de classe, pela alegria
que trouxeram a minha vida durante estes anos e por
todos os encontros acadêmicos.
Aos professores Fábio Barreto, Glauco
Amorim e Myrna Amorim, nossos amados mestres
não apenas acadêmicos, mas por merecimento.
Nossa classe sempre se espelhou em vocês.
Ao meu orientador, Prof. M.Sc. Matheus
Bousquet Bandini, que aceitou o desafio mesmo
com a limitação do tempo e viabilizou este projeto.
Aos estimados revisores Patrícia Corado e
Pedro, por seu tempo dedicado.
Aos
demais
amigos
conviveram
comigo
durante
aprendizagem
e
e
colegas
este
contribuíram,
indiretamente, para minha formação.
ciclo
direta
que
de
ou
5
“O poder da Web está em sua universalidade.
O
acesso
feito
por
qualquer
pessoa,
independentemente de sua capacidade, é um aspecto
essencial.”
- Tim Berners-Lee -
6
RESUMO
A Internet tornou-se um grande canal de comunicação, aprendizagem, lazer e consumo de
produtos e serviços, atendendo tanto a pessoas quanto a empresas. Estas vantagens,
disponíveis para a maior parte dos usuários que utilizam a rede mundial de computadores,
esbarram em problemas de acessibilidade para aqueles que apresentam algum tipo de
deficiência visual. A Internet pode proporcionar a inclusão digital e social a estes deficientes
visuais, desde que obtenham acesso pleno à informação e aos serviços disponíveis através da
web. Este trabalho apresenta conceitos relacionados à acessibilidade na web, como design
universal, tecnologias assistivas e razões para adotá-la. Seu principal objetivo consiste em
apresentar diretrizes para o desenvolvimento de sites acessíveis a deficientes visuais e
disponibilizar as principais técnicas para que projetistas e desenvolvedores possam aplicá-las.
Além de abordar métodos e ferramentas para a avaliação da acessibilidade web, o trabalho
também propõe um modelo de site acessível.
Palavras-chave: acessibilidade web, diretrizes de acessibilidade web, padrões web, deficientes
visuais, inclusão digital.
7
ABSTRACT
Internet became a large channel of communication, learning, leisure and consuming of
products and services, supporting people and companies. These advantages, available to most
part of users that use the Internet, face accessibility issues to those presenting some kind of
visual impairment. Internet may provide digital and social inclusion to these visual impaired,
since they have full access to information and services available through web. This work
presents concepts related with web accessibility, like universal design, assistive technology
and reasons to adopt it. The main goal of this work consists in showing guidelines to the
development of accessible sites for visual impaired and makes available the main techniques,
so designs and developers may apply them. In addition the approach of methods and tools for
web accessibility assessments, the work also proposes an accessible site model.
Keywords: web accessibility, web accessibility guidelines, web standards, visual impaired,
digital inclusion.
8
LISTA DE ILUSTRAÇÕES
LISTA DE GRÁFICOS
Figura 2.1 - Símbolo utilizado em páginas com acessibilidade.
Figura 4.1 - Selos de níveis de conformidade que podem ser obtidos por uma página web.
Figura 4.2 - Exemplos das principais declarações de tipo de documento – DTD.
Figura 4.3 - Estrutura básica de um documento HTML.
Figura 4.4 - Exemplo de como referenciar o CSS em uma página.
Figura 4.5 - Exemplo da aplicação de folhas de estilo em Cascata auditivas (Aural).
Figura 4.6 - Diferentes tipos de mídia definidos em um mesmo documento de estilo.
Figura 4.7 - A cor não deve ser o único elemento para a transmissão de informações.
Figura 4.8 - Exemplo de declaração de fontes utilizando CSS.
Figura 4.9 - Exemplo de accesskey e tabindex.
Figura 4.10 - Uso de acrônimos e abreviações, atrelados a folhas de estilo.
Figura 4.11 - Exemplo de citação indireta em texto.
Figura 4.12 - Exemplos de definição no texto.
Figura 4.13 - Exemplo de uma lista de definições.
Figura 4.14 - Definição do conjunto de caracteres utilizado em uma página.
Figura 4.15 - Meta dados para links através do atributo title.
Figura 4.16 - Exemplo de link estendido ao contexto.
Figura 4.17 - Links do tipo âncora.
Figura 4.18 - Exemplo de link externo indicado visualmente.
Figura 4.20 - Exemplo de imagens sem acessibilidade.
Figura 4.19 - Definição do comportamento do link, através de CSS, ao receber o foco.
Figura 4.21 - Exemplo do código de uma imagem acessível.
Figura 4.22 - Recurso d-link junto à imagem.
Figura 4.23 - Exemplo de um mapa de imagem acessível.
Figura 4.24 - Comparação entre célula criada com tabela e com o elemento div.
Figura 4.25 - Exemplo das propriedades legenda e sumário em tabelas.
Figura 4.26 - Exemplo de tabela com áreas de cabeçalho e conteúdo.
Figura 4.27 - Exemplo de exibição de tabela em navegador gráfico.
Figura 4.28 - Tabela com células de dados associadas aos cabeçalhos correspondentes.
Figura 4.29 - Tabela com cabeçalhos de linhas e colunas.
Figura 4.30 - Associação de um rótulo a um controle de formulário.
Figura 4.31 - Seqüência lógica de tabulação e teclas de atalho em formulários.
Figura 4.32 - Agrupamento de informações em formulários.
Figura 4.33 - Botões de seleção podem exigir menor precisão.
Figura 4.34 - Grupo de controles sem exibição de borda, utilizando CSS.
Figura 4.35 - Botões gráficos acessíveis.
Figura 4.36 - Script para evitar erro por campos vazios em navegadores antigos.
Figura 4.37 - Exemplo de uso da tag noscript.
Figura 4.38 - Iniciativa de acessibilidade em ferramentas de autoria, como Adobe Flash.
Figura 5.1 - Exemplo de navegador gráfico com imagens desabilitadas.
Figura 5.2 - Exemplo de site testado com o simulador Lynx Viewer.
Figura 5.3 - Modelo proposto de site acessível – www.acessibilidadeweb.com.br.
Figura A.1 – Validação automática de sintaxe (HTML).
Figura A.2 – Validação automática de folhas de estilo.
Figura A.3 – Avaliação automática de acessibilidade.
Figura A.4 – Teste com emulador de navegador textual - Lynx Viewer.
9
Figura A.5 – Teste com Javasript desabilitado.
Figura A.6 – Teste com página sem folhas de estilo vinculadas.
Figura A.7 - Teste com imagens desabilitadas.
Figura A.8 - Simulador Vischeck indicando a visualização de um deficiente com
Deuteranopia.
Figura A.9 - Simulador Vischeck indicando a visualização de um deficiente com Protanopia.
Figura A.10 - Simulador Vischeck indicando a visualização de um deficiente com Tritanopia.
10
LISTA DE TABELAS
TABELA A - Tecnologias assistivas para deficientes visuais (DIAS, 2007, p. 121).
11
LISTA DE ABREVIATURAS E SIGLAS
CORDE – Coordenadoria Nacional para Integração da Pessoa Portadora de Deficiência
CSS – Cascading Style Sheets (Folhas de estilo em cascata)
DTD - Document Type Definition (Declaração de Tipo de Documento)
E-MAG – Modelo de Acessibilidade de Governo Eletrônico
HTML – HyperText Markup Language (Linguagem de marcação de hipertexto)
ONG – Organização não governamental
TTY – Teletypewriters (dispositivos de telecomunicação para surdos)
W3C – World Wide Web Consortium (Consórcio World Wide Web)
WAI – Web Accessibility Initiative (Iniciativa para Acessibilidade Web)
WCAG – Web Content Accessibility Guidelines (Recomendações para acessibilidade de
conteúdo web )
XHTML – Extensible HyperText Markup Language (Linguagem de Marcação de Hipertexto
Extensível)
XML – Extensible Markup Language (Linguagem de Marcação Extensível)
12
LISTA DE SÍMBOLOS
< ... > Símbolo que define uma etiqueta HTML, um código de marcação desta linguagem.
13
SUMÁRIO
CAPÍTULO 1 INTRODUÇÃO ............................................................................................ 15
1.1 Considerações iniciais ..................................................................................................... 15
1.2 Questões norteadoras da pesquisa ................................................................................... 16
1.3 Objetivos da pesquisa ...................................................................................................... 17
1.3.1 Objetivos gerais ........................................................................................................ 17
1.3.2 Objetivos específicos ................................................................................................ 17
1.4 Justificativa da investigação ............................................................................................ 18
1.5 Organização do trabalho.................................................................................................. 19
CAPÍTULO 2 ACESSIBILIDADE EM SISTEMAS WEB ............................................... 20
2.1 Design universal e tecnologias assistivas ........................................................................ 20
2.2 Definição de acessibilidade ............................................................................................. 21
2.2.1 Acessibilidade web ................................................................................................... 21
2.2.2 Mitos sobre acessibilidade web................................................................................. 22
2.2.3 Razões para a acessibilidade web ............................................................................. 23
2.2.4 Aspectos legais sobre acessibilidade ........................................................................ 25
2.2.2 Entidades e iniciativas de acessibilidade no Brasil ................................................... 27
CAPÍTULO 3 DEFICIENTES VISUAIS E BARREIRAS NA UTILIZAÇÃO DE
SISTEMAS WEB .................................................................................................................... 29
3.1 Deficiências: definições e tipos ....................................................................................... 29
3.2 Deficiências visuais ......................................................................................................... 30
3.3 Tecnologias assistivas para deficientes visuais ............................................................... 32
3.4 Barreiras a acessibilidade ................................................................................................ 33
CAPÍTULO 4 DIRETRIZES E TÉCNICAS PARA SISTEMAS ACESSÍVEIS ............ 36
4.1 Diretrizes para acessibilidade web .................................................................................. 36
4.1.1 World Wide Web Consortium ................................................................................... 36
4.1.2 Recomendações para acessibilidade de conteúdo web ............................................. 37
4.2 Técnicas para acessibilidade web .................................................................................... 42
4.2.1 Declaração e estrutura de documentos ...................................................................... 43
4.2.2 Navegação ................................................................................................................. 45
4.2.3 Folhas de estilo ......................................................................................................... 46
4.2.4 Cores e fontes ............................................................................................................ 49
4.2.5 Navegação pelo teclado ............................................................................................ 52
4.2.6 Textos e links ............................................................................................................ 54
4.2.7 Descrição de imagens ............................................................................................... 59
4.2.8 Tabelas e frames ....................................................................................................... 62
4.2.9 Formulários ............................................................................................................... 68
4.2.10 Scripts, applets e plug-ins ....................................................................................... 71
4.2.11 Animações - tecnologia flash .................................................................................. 73
4.2.12 Multimídia .............................................................................................................. 74
CAPÍTULO 5 AVALIAÇÃO DA ACESSIBILIDADE ..................................................... 76
5.1 Métodos de avaliação ...................................................................................................... 76
5.1.1 Validação automática ................................................................................................ 77
5.1.2 Avaliação humana ..................................................................................................... 78
5.1.3 Testes com usuários .................................................................................................. 81
14
5.2 Modelo proposto de site acessível ................................................................................... 81
5.2.1 Avaliação da acessibilidade no modelo proposto ..................................................... 82
CAPÍTULO 6 CONSIDERAÇÕES FINAIS ....................................................................... 85
6.1 Conclusão ........................................................................................................................ 85
6.2 Trabalhos futuros............................................................................................................. 86
ANEXO A – EXEMPLOS DE TESTES DE ACESSIBILIDADE ..................................... 87
REFERÊNCIAS ..................................................................................................................... 92
15
CAPÍTULO 1
INTRODUÇÃO
1.1 Considerações iniciais
Os serviços da Internet concretizaram-se como um forte meio de comunicação –
através da troca de mensagens e arquivos via e-mail e conversas em tempo real; aprendizagem
– com pesquisas em artigos acadêmicos, enciclopédias e livros eletrônicos; lazer – músicas,
vídeos e jogos online; e compra e venda de produtos e serviços. Os benefícios que a web
proporciona às empresas também são exponenciais. Devido ao seu grande alcance, o
marketing se propaga rapidamente e a abrangência de pessoas e a visibilidade do produto
podem ser maiores, se comparados a outros meios de comunicação. Estes serviços estão
disponíveis para a maior parte das pessoas que utilizam a rede mundial de computadores, mas
não para aqueles que apresentam deficiência visual.
Apesar das tecnologias computacionais avançadas disponíveis no mercado, é evidente
o descaso quanto às dificuldades que os deficientes visuais enfrentam para acessar páginas
web. Basta navegar por algumas páginas para descobrir, em pouco tempo, a variedade de
temas, tipos de mídias utilizadas e finalidades a que se propõem os sites. Contudo, a maioria
apresenta um ponto em comum: uso extremo de recursos visuais.
Ligar o computador, conectar-se a um provedor de Internet, executar um programa de
navegação, pagar contas e realizar compras online parecem ações simples, quando se pode
enxergar. Entretanto, a realidade que pode ser observada é que os sites não possuem estrutura
adequada para receber usuários com deficiência visual.
Para este grupo de pessoas, navegar pela Internet ocorre de um modo diferente. Há
aqueles que possuem baixo grau de visão e necessitam que os sites apresentem flexibilidade
para aumentar o tamanho das letras. Outros encaram dificuldades relacionadas às cores, como
os daltônicos, cuja necessidade é o alto contraste de cores – como preto e branco. Existem,
ainda, os cegos. Para estes, as diferenças começam já nos softwares utilizados, onde o áudio é
predominante. Programas sintetizadores de voz fazem a leitura de documentos, em
substituição a um navegador comum com interface gráfica rica. O mouse normalmente não é
utilizado, por ser um recurso que interage estritamente com a visão. Os comandos são
realizados através do teclado.
Outras barreiras se levantam, tratando-se usuários completamente sem visão: imagens
que não possuem uma descrição textual alternativa, vídeos que não possuem narração, tabelas
16
que não fazem sentido quando lidas célula por célula ou em modo linearizado e ausência, nas
páginas, de atalhos para o teclado do computador.
Este é um público-alvo considerável, que não pode ser excluído da rede virtual. Chak
(2004, p. 2) reforça a importância de um site de fácil acesso e que possa ser utilizado por
todos: “Se os usuários não podem navegar e encontrar os itens, eles não podem comprá-los”.
Um levantamento realizado com mais de seiscentos profissionais da web mostrou que
apenas 19,9% consideram a acessibilidade em seus projetos (FREIRE, 2008).
Para profissionais que produzem conteúdo para a web, não conhecer a maneira como
as pessoas com deficiência acessam a Internet, o modo como navegam ou como funcionam os
programas específicos é garantia de um site com páginas mal estruturadas e,
conseqüentemente, inacessíveis.
Soluções existentes para estes problemas devem ser apontadas. Para o escopo da
deficiência visual, existe uma série de técnicas que devem ser aplicadas ao código das páginas
para possibilitar ou facilitar o entendimento de seu conteúdo.
No Brasil, instituições governamentais, ONGs (Organizações não governamentais) e
entidades sem fins lucrativos atuam na conscientização e em projetos que garantam
acessibilidade em páginas web. Existe material didático de referência sobre o assunto,
abordado nos capítulos 4 e 5, como livros na língua inglesa e cartilhas em português, além de
serviços online que avaliam automaticamente o código de sites no quesito acessibilidade,
representando, ainda que imperfeitos, uma excelente alternativa de validação.
Não basta uma leitura superficial sobre o tema na tentativa de se obter resultados
imediatos. É possível acreditar que se conhece o suficiente para desenvolver projetos web
com acessibilidade e estar enganado. Para que se garanta sites realmente acessíveis, é preciso
testar as técnicas aplicadas, incansavelmente.
1.2 Questões norteadoras da pesquisa
Tendo em vista o crescente número de profissionais sem o conhecimento das técnicas
padronizadas para tornar sites acessíveis, o modo e os programas utilizados pelos deficientes
visuais para se navegar, além das fontes existentes de pesquisa, o quadro apresentado
atualmente na web é composto de páginas que excluem um grande número de usuários cuja
visão não pode ser utilizada total ou parcialmente. Devido a esta realidade, a questão
primordial a ser respondida na monografia aqui proposta é: como desenvolver sites realmente
acessíveis para deficientes visuais?
17
Para responder a esta indagação é preciso atentar para outros questionamentos, tais
quais:
a) Em que consiste a acessibilidade na web e quais as razões para aplicá-la?
b) Quais as barreiras encontradas pelos deficientes visuais no acesso e utilização
de sites?
c) Quais diretrizes e técnicas devem ser observadas no desenvolvimento de sites
acessíveis?
d) Como avaliar e assegurar que um site seja realmente acessível?
1.3 Objetivos da pesquisa
1.3.1 Objetivos gerais
Este trabalho propõe expor as dificuldades enfrentadas pelos deficientes visuais na
utilização de sistemas na Internet, bem como demonstrar aos profissionais da web, através de
conceitos, técnicas e modelos, as diretrizes necessárias para o desenvolvimento de páginas
acessíveis a estes deficientes, proporcionando assim uma agregação desse público e também
novas perspectivas de possíveis negócios.
1.3.2 Objetivos específicos
Para que os objetivos gerais sejam alcançados, é necessário:
a) Alcançar a compreensão do termo “acessibilidade”. A proposta aqui explorada
busca definir o que representa a acessibilidade web para o escopo da
deficiência visual, as razões para adotá-la e, em paralelo, apresentar leis e
entidades vinculadas ao assunto;
b) Efetuar o levantamento das reais necessidades de navegação dos deficientes
visuais. O objetivo aqui é retratar as barreiras faceadas em sites não acessíveis
e abordar tecnologias assistivas disponíveis que possibilitam a navegação;
c) Oferecer material para o preparo e conhecimento dos profissionais sobre o uso
das técnicas voltadas para a acessibilidade. Muitos profissionais não detêm o
devido conhecimento das diretrizes existentes para desenvolvimento de
sistemas web acessíveis ou não se encontram suficientemente estimulados para
18
utilizá-las. O objetivo aqui a ser alcançado é abordar as diretrizes por meio de
técnicas que exemplificam sua aplicabilidade;
d) Determinar como se dá a avaliação de sites acessíveis. Serão estudados
métodos para a avaliação de sites, além da disponibilização de um modelo
genérico de site seguindo os padrões apresentados durante o desenvolvimento
desta pesquisa.
1.4 Justificativa da investigação
Esta pesquisa justifica-se por meio de diversos aspectos, abrangendo o cunho social,
cultural, mercadológico, acadêmico e legislativo, como descritos a seguir:
Socio-cultural. Neste âmbito, a pesquisa é justificada pela necessidade de disseminar
uma nova cultura entre desenvolvedores de sistemas web – a cultura de criar sites acessíveis.
Existem mitos a serem desfeitos, como os que argumentam que um “site acessível implica em
baixa qualidade visual” ou “site acessível defasa a usabilidade”. Em adição, é necessário
semear a inclusão digital, para que deficientes visuais tenham acesso pleno a toda informação
disponível na Internet, direito de todo cidadão.
Mercadológico. Grande parte dos profissionais encontra-se despreparada para uma
nova e crescente demanda por sites acessíveis. Conhecer superficialmente, desconhecer ou
não ter interesse no assunto são justificativas comumente encontradas. No entanto, é preciso
atentar ao público com limitações visuais, que é notoriamente expressivo.
Acadêmico. A relevância da pesquisa sob este ângulo reside na escassez de material
didático disponível na língua portuguesa com o teor prático oferecido neste projeto. São raras
as fontes de pesquisa que concentram, de forma profunda e objetiva, barreiras de utilização e
tecnologias assistivas para deficientes visuais e, ao mesmo tempo, diretrizes e exemplos de
código para desenvolvedores. Portanto este estudo justifica-se neste aspecto por proporcionar
material didático para futuras pesquisas na área.
Legislação: No Brasil e em diversos países já existem leis que obrigam os sites
governamentais a se apresentarem de forma acessível, apesar de muitos não seguirem ainda a
regulamentação. Teoricamente, esta iniciativa tende a se alastrar. Não é difícil prever, a curto
ou médio prazo, leis que requeiram acessibilidade em sites institucionais. Portanto a pesquisa
justifica-se por fornecer meios para que profissionais desenvolvam sites em concordância com
o legislativo.
19
1.5 Organização do trabalho
Este trabalho de pesquisa está organizado do seguinte modo: no capítulo 2 são
apresentados conceitos relacionados à acessibilidade na web, como design universal e
tecnologias assistivas, bem como aspectos sobre a própria acessibilidade, como mitos, razões
para adotá-la, legislações, entidades e suas iniciativas. No capítulo 3 são explanadas as
deficiências visuais, barreiras de acesso e utilização de páginas web e tecnologias de apoio.
No capítulo 4 são apresentadas diretrizes para sites acessíveis e as principais técnicas para
aplicá-las. O capítulo 5 aborda métodos e ferramentas para a avaliação da acessibilidade e
propõe modelo de site acessível. Finalmente, no capítulo 6, são apresentadas as principais
conclusões para esta pesquisa e apontamentos para trabalhos futuros.
20
CAPÍTULO 2
ACESSIBILIDADE EM SISTEMAS WEB
A definição do conceito de acessibilidade web requer, igualitariamente, a compreensão
de termos afins como design universal e tecnologias assistivas, descritos a seguir, bem como a
ciência da legislação que incide sobre o tema e as razões pelas quais adotá-lo. Neste capítulo,
alguns mitos sobre a acessibilidade web serão desfeitos e algumas iniciativas concomitantes
serão apontadas.
2.1 Design universal e tecnologias assistivas
Para atender a pessoas com diferentes habilidades ou necessidades é preciso
desenvolver páginas baseadas nos princípios do design universal. Design ou desenho
universal, ou ainda design para todos, compreende um conceito amplo que abrange várias
áreas acadêmicas e profissionais, e recentemente passou a ser utilizado também em
informática. O termo “[...] refere-se à tecnologia desenvolvida de maneira que seja flexível o
suficiente para acomodar as diversas habilidades humanas sem sacrificar a estética, a eficácia,
ou o custo” (FREIRE, 2008, p. 8).
Segundo o Centro para Design Universal, da Universidade Estadual da Carolina do
Norte (North Carolina State University, The Center for Universal Design), Estados Unidos,
os princípios de design universal são: uso equitativo, flexibilidade de uso, uso simples e
intuitivo, informação perceptível, tolerância a erros, baixo esforço físico e tamanho e espaço
para aproximação e uso (THE PRINCIPLES, 1997).
Projetar um produto tendo em mente a universalidade torna seu uso mais fácil para
qualquer pessoa, e resulta em maior aceitação do mesmo. Para Dias (2007, p. 104), o design
universal tem geralmente seu foco em dois aspectos principais:
Desenvolver produtos comerciais flexíveis o suficiente para serem
diretamente utilizados [...] por pessoas com diversas habilidades e sob
diversas circunstâncias, aplicando materiais, tecnologias e conhecimentos
atuais.
Desenvolver produtos compatíveis com tecnologias assistivas que possam
ser usados por aqueles que não sejam capazes de acessá-los e usá-los
diretamente de maneira eficiente.
Tecnologias assistivas são recursos ou serviços os quais possibilitam ou facilitam a
execução de atividades que pessoas com alguma espécie de deficiência ou limitação não
21
poderiam realizar por si só, promovendo independência e inclusão. Estas tecnologias têm
como objetivo assistir pessoas em atividades das mais variadas naturezas, seja no trabalho,
estudo, diversão, acesso a informações, comunicação e até mesmo em atos primordiais, como
andar ou ouvir. Por recursos, compreende-se que sejam produtos, equipamentos e sistemas
cujo uso auxilia as capacidades funcionais de deficientes, enquanto os serviços auxiliam as
pessoas a terem acesso a estes produtos (ASSISTIVA, 2009).
Uma tecnologia assistiva pode ser definida, ainda, como “Ferramenta ou recurso
utilizado com a finalidade de proporcionar uma maior independência e autonomia à pessoa
com deficiência” (SERPRO, 2008). Alguns sinônimos podem ser encontrados, como
tecnologia de apoio ou adaptativa.
A despeito do conceito de tecnologias de apoio ser amplamente empregado na área da
computação, dispositivos apontadores especiais, terminais em Braille, sintetizadores de voz e
leitores de tela não são uma exclusividade. Igualmente classificáveis, constituem ótimos
exemplos: bengalas, óculos, cadeiras de rodas ou rampas de acesso.
2.2 Definição de acessibilidade
Enquanto o design universal aborda a idéia de projetar para todas as pessoas, existe
seu subconjunto que trata especificamente do acesso: a acessibilidade. O termo acessível, na
língua portuguesa, significa “de acesso fácil” e “inteligível, compreensível” (FERREIRA,
2009, p. 10). E, na web, não poderia ser de outra forma.
A Word Wide Web ou meramente web é um serviço da Internet que tem por natureza a
disponibilização, o compartilhamento de informações. O conceito inicial é justamente o
oposto de restrição. Para Tim Berners-Lee, diretor do World Wide Web Consortium (W3C),
“o poder da web está em sua universalidade. Ser acessada por todos, independente de
deficiência, é um aspecto essencial” (SERPRO, 2008).
2.2.1 Acessibilidade web
A acessibilidade na web consiste em desenvolver sistemas online ou sites que
possibilitem aos usuários, deficientes ou não, a obtenção de informações, produtos e serviços
desejados, com ou sem auxílio de tecnologia de apoio, onde quer que estejam e a qualquer
momento.
Eis uma excelente definição de acessibilidade na web (SERPRO, 2008):
22
Acessibilidade na Internet ou acessibilidade na web significa permitir o
acesso à web por todos, independente de tipo de usuário, situação ou
ferramenta. É criar ou tornar as ferramentas e páginas web acessíveis a um
maior número de usuários, inclusive pessoas com deficiências. A
acessibilidade na web beneficia também pessoas idosas, usuários de
navegadores alternativos, usuários de tecnologia assistiva e de acesso móvel.
Apesar de o termo englobar a idéia de acesso à Internet por dispositivos móveis, a
acessibilidade na web está, normalmente, atrelada a idéia de permitir o acesso de usuários
deficientes, com alguma espécie de limitação ou incapacidade. A seguir é apresentado o
símbolo de acesso a web1, utilizado em páginas nas quais foram aplicadas técnicas de
acessibilidade a usuários deficientes.
Figura 2.1 - Símbolo utilizado em páginas com acessibilidade.
A acessibilidade é, por definição, um subconjunto de usabilidade. Usabilidade é a
prática de desenhar sites de modo que os usuários possam realizar as tarefas desejadas sem
impedimentos indevidos. Portanto, existe uma ligação clara entre usabilidade e acessibilidade.
A primeira trata da facilidade de navegação e execução de tarefas e a segunda trata,
geralmente, de auxiliar o acesso de usuários deficientes. Um site pode oferecer usabilidade
sem, contudo, ser acessível. O oposto também é verídico (CLARK, 2002a).
2.2.2 Mitos sobre acessibilidade web
Segundo Dias (2007), para os que não dominam o assunto, existem conceitos errôneos
a serem desmistificados, tais como:
 Site acessível implica em baixa qualidade visual – contudo, as recomendações
sobre acessibilidade não limitam a parte gráfica ou multimídia do projeto. O
1
Símbolo disponível para download em: http://ncam.wgbh.org/webaccess/symbolwinner.html.
23
oposto é verdade, pois a acessibilidade melhora os resultados e permite seu uso
por tecnologias avançadas.
 Deficientes não usam a web – os projetistas que alegam conhecer bem seus
clientes talvez nunca tenham realizado pesquisas para avaliar a satisfação ou
descobrir quais são deficientes. É possível que os deficientes realmente não
visitem seus sites justamente por não serem acessíveis.
 A acessibilidade na web é algo complexo para o projetista mediano – não é
necessário conhecer a fundo HTML (HyperText Markup Language) ou folhas
de estilo para desenvolver páginas acessíveis. Ao fazê-lo, porém, o projetista
aprende como realmente a web funciona, e seu real papel para a sociedade.
 É caro e demorado projetar páginas web acessíveis – desde que a preocupação
com acessibilidade ocorra já no início do projeto, o custo para implementar
acessibilidade é praticamente nulo. E o tempo gasto não é em vão. Pode-se
comparar estes cuidados com a revisão gramatical e ortográfica de um livro,
por exemplo.
Para Spelta (2009), psicóloga, programadora, analista, cega e uma das autoridades em
acessibilidade no Brasil, além destes mitos, há outra convicção equivocada: “meu site é
direcionado a um público específico; ele não interessa a todos os grupos de usuários”. Um
sistema ou página web implementado sob este princípio é potencialmente não acessível. Ela
ressalva, ainda: “quando restringimos o acesso do nosso site ao que julgamos serem as
características do seu público alvo, estamos, na prática, usando a Internet para limitar o nosso
público, ao invés de ampliá-lo”. Páginas web inacessíveis produzem um efeito negativo
persistente, uma vez que potenciais clientes, não encontrando acessibilidade, tendem a não
retornar.
E aos que acreditam que a acessibilidade traz melhorias apenas para deficientes, Krug
(2008, p. 174) destaca: se “tornar sites acessíveis os deixa mais usáveis por todos”, o contrário
também é verdade: “tornar os sites mais usáveis para o „resto de nós‟ é uma das formas mais
eficazes de torná-los mais eficazes para pessoas com deficiências”.
2.2.3 Razões para a acessibilidade web
Projetistas e desenvolvedores, em especial, temem ter mais trabalho, ou que o projeto
possa ser comprometido pela aplicação da acessibilidade. A verdade, entretanto, é que as
razões para adotar a acessibilidade são inúmeras e irrefutáveis.
24
A acessibilidade ajuda a garantir igualdade de direitos e cidadania. Promove
independência, melhoria na qualidade de vida, inclusão social e digital de pessoas com
deficiências visuais, ao permitir acesso igualitário a informações. Queiroz (2006a) assegura:
...Se, enfim, conseguissem utilizar de todas as facilidades que a Internet,
especialmente a web, oferece à maioria de seus usuários, essas pessoas
estariam cada vez menos limitadas. A tecnologia da web não seria mais uma
barreira a ser transposta mas, ao contrário, um veículo de transposição de
barreiras e melhora da qualidade de vida.
Contudo, acessibilidade não é mero altruísmo. E todos estão sujeitos a acidentes e aos
efeitos do envelhecimento, e possíveis deficiências que estes possam acarretar. A
acessibilidade agrega valor ao site, enfatiza Clark (2002b), constituindo mais um atributo a ser
anexado ao projeto no momento da venda. Ao criar sites em conformidade com os padrões
web, projetistas e desenvolvedores demonstram maturidade profissional e social, adicionando
redundâncias benéficas – como um texto que descreve uma imagem. O resultado são páginas
ricas em conteúdo.
O profissional da web desenha sites para pessoas diferentes de si, que usam diferentes
tecnologias e possuem preferências e necessidades distintas. Para Bruno Torres, Coordenador
de Marketing Online do Universo Online (UOL), o maior beneficiado com um site acessível é
o próprio proprietário do site, devido à maximização da exposição de seu produto ou serviço:
“acessibilidade é, antes de qualquer coisa, inteligência e visão de mercado” (TORRES, 2006).
Dados publicados pela Organização Mundial de Saúde (World Health Organization,
WHO) mostram que o número de pessoas com deficiência visual em todo o mundo em 2002
havia excedido 161 milhões, dos quais 37 milhões eram cegos (WHO, 2004).
De acordo com o levantamento de dados realizado no último censo pelo Instituto
Brasileiro de Geografia e Estatística (IBGE), em 2000, 14,5% da população brasileira era
portava uma das deficiências investigadas pela pesquisa. O censo revelou, também, que em
2000 havia 148 mil brasileiros cegos e 2,4 milhões com grande dificuldade para enxergar, e
que 29,5% dos portadores de deficiência ocupados tinham rendimento de até um salário
mínimo (IBGE, 2000).
Além de configurar enorme público potencial, consumidores deficientes são assíduos e
fiéis quando encontram um site acessível – justamente pelas dificuldades faceadas ao
utilizarem meios tradicionais para, por exemplo, fazer compras (SPELTA, 2007a). Suas
aquisições podem ser para uso pessoal ou de terceiros. Nada deveria impedir um deficiente
visual de obter um livro, ainda que não em Braille, para presentear alguém.
25
Existem várias vertentes de conhecimento requeridas de projetistas e desenvolvedores
web para se atingir o objetivo de criar sistemas acessíveis. Os requisitos são completamente
tangíveis, porém, aprofundar-se neste contexto requer motivação. Ademais, argumentos como
código padronizado, informação organizada de forma mais objetiva, abertura para novos
públicos-alvo, e maior visibilidade e otimização do produto pelos robôs de busca são apenas
alguns dos incentivos que se somam aos argumentos apresentados anteriormente para
convencer o profissional a abraçar a acessibilidade.
Segundo pesquisa com usuários realizada nos Estados Unidos e no Japão, sites que
permitem a navegação de usuários deficientes (cegos, com baixo grau de visão ou
dificuldades motoras) tornam-se três vezes mais fáceis de serem utilizados por usuários sem
deficiência (NIELSEN, 2001). Estima-se que 68% dos que usuários abandonam um site o
fazem por não encontrar a informação solicitada (RIBEIRO, p. 32).
Outros fatores técnicos favoráveis podem ser destacados, tratando-se de páginas web
acessíveis: custo mínimo, otimização e acesso por dispositivos móveis (DIAS, 2007, p. 134).
Custo mínimo. Desde que as recomendações para design acessível sejam aplicadas
desde o início do projeto, o aumento no custo de produção de sistemas ou sites web é mínimo.
Otimização. Páginas web com acessibilidade tendem a fornecer melhores resultados
em mecanismos de buscas, permitindo que usuários as encontrem com maior facilidade, visto
que tais mecanismos indexam apenas texto (imagens e arquivos multimídias são indexados
apenas quando oferecem equivalentes textuais). Neste contexto, servidores web que hospedam
páginas acessíveis tornam-se mais eficientes, pois os usuários requisitam menos recursos ao
encontrar, com mais facilidade, os dados desejados.
Acesso por dispositivos móveis. Esta é uma preocupação crescente entre profissionais
web. Aplicar as normas de acessibilidade faz com que o site possa ser acessado por
dispositivos móveis, que possuem tecnologias modernas, como telefones celulares com
navegação na Internet, televisão, e automóveis.
Krug (2008, p. 171) ressalta: “é verdadeiramente a coisa certa a fazer”, e conclui: “e
para aqueles de vocês que não acharem este argumento atrativo, estejam cientes de que haverá
uma obrigação legislativa mais cedo ou mais tarde. Contem com isso”.
2.2.4 Aspectos legais sobre acessibilidade
Diretrizes de acessibilidade na web, sob o aspecto legal, já podem ser encontradas em
alguns países, como Austrália, Canadá e Estados Unidos. Agências e departamentos do
26
governo australiano são obrigados pelo Ato de Discriminação de Deficientes de 1992
(Disability Discrimination Act 1992) a assegurar que serviços e informações online sejam
acessíveis a pessoas com deficiências (ACCESSIBILITY, 2009). O governo canadense
disponibiliza, em seu web site, diretrizes para acessibilidade, interoperabilidade e usabilidade
(COMMON, 2006).
Nos Estados Unidos, o governo estabeleceu, em 1998, a “Seção 508” (Section 508),
uma emenda do Ato de Reabilitação (Rehabilitation Act) que obriga agências federais a tornar
acessível a pessoas deficientes sua tecnologia eletrônica e de informação. O mesmo é exigido
para se realizar negócios com o governo americano. A lei almeja eliminar barreiras em
tecnologia da informação, a fim de possibilitar novas oportunidades para pessoas com
deficiência e encorajar o desenvolvimento de tecnologias que auxiliarão nestes objetivos. De
acordo com a mesma lei, tecnologia inacessível interfere na habilidade individual de se obter
e usar informação rápida e facilmente (508, 1998). O governo americano reuniu, ainda, um
conjunto de leis para formar o American with Disabilities Act (ADA), que regula os direitos
dos cidadãos com deficiência naquele país, e lançou padrões para design acessível - ADA
Standards For Accessible Design (ESTADOS, 2003).
É possível, ainda, encontrar as diretrizes irlandesas para acessibilidade, desenvolvidas
pelo Centro para Excelência em Design Universal (WEB, 2009), traduzidas para a língua
portuguesa (QUEIROZ, 2006b).
No Brasil vigora a Lei 7.853, de 24 de outubro de 1989, que trata das “normas gerais
que asseguram o pleno exercício dos direitos individuais e sociais das pessoas portadoras de
deficiências, e sua efetiva integração social” e institui responsabilidades para a Coordenadoria
Nacional para Integração da Pessoa Portadora de Deficiência – CORDE, entre as quais se
encontram o dever de “coordenar as ações governamentais e medidas que se refiram às
pessoas portadoras de deficiência” e ainda “manter, com os Estados, Municípios, Territórios,
o Distrito Federal, e o Ministério Público, estreito relacionamento, objetivando a concorrência
de ações destinadas à integração social das pessoas portadoras de deficiência” (BRASIL,
1989).
Para promover acessibilidade nos sistemas de comunicação, a Lei 10.098, de 19 de
dezembro de 2000, deixou a cargo do Ministério Público o dever de promover “a eliminação
de barreiras na comunicação” e estabelecer “mecanismos e alternativas técnicas que tornem
acessíveis os sistemas de comunicação e sinalização às pessoas portadoras de deficiência
sensorial e com dificuldade de comunicação”. A Lei garantiu ainda “o direito de acesso à
27
informação, à comunicação, ao trabalho, à educação, ao transporte, à cultura, ao esporte e ao
lazer” (BRASIL, 2000).
Em 2 de dezembro de 2004 foi publicado o Decreto 5.296, que obrigou, num prazo de
doze meses a contar da data de publicação, a acessibilidade em portais e sítios eletrônicos da
administração pública na Internet para deficientes visuais, e garante o “pleno acesso às
informações disponíveis” (BRASIL, 2004). A determinação abrangeu igualmente portais e
sítios de grande porte, exceto se demonstrada alguma inviabilidade para seu cumprimento.
O governo brasileiro lançou, em 14 de dezembro de 2005, a versão revisada do
Modelo de Acessibilidade de Governo Eletrônico (E-MAG), uma cartilha com
recomendações padronizadas para implementação da acessibilidade na web. O E-MAG é
coerente com as necessidades brasileiras e em conformidade com os padrões internacionais, e
a observância de seus padrões é obrigatória em sítios e portais do governo brasileiro (E-MAG,
2007).
2.2.2 Entidades e iniciativas de acessibilidade no Brasil
No Brasil, diversas entidades atuam na conscientização e em projetos que garantam
aos deficientes visuais o acesso à Internet.
Entre as organizações não governamentais, destacam-se a Acessibilidade Brasil e o
Acesso Digital. Acessibilidade Brasil2, também denominada Acesso Brasil, é uma entidade
sem fins lucrativos, que tem como missão a disseminação dos princípios de acessibilidade, na
área digital, visando à inclusão social e econômica de pessoas com deficiência, idosos e
pessoas com baixa escolaridade. Entre suas inúmeras ações, está o desenvolvimento do site
atual do Instituto Benjamin Constant, acessível a deficientes visuais.
O Acesso Digital3 é uma organização não governamental que reúne um experiente
grupo de especialistas em acessibilidade, design, padrões web, usabilidade e tecnologias
assistivas. Além de vários artigos e cursos de capacitação sobre acessibilidade, também
oferece serviços de avaliação, adequação e desenvolvimento de web sites acessíveis e
consultoria.
Na área acadêmica, podem ser destacados os projetos de acessibilidade do Núcleo de
Computação Eletrônica da Universidade Federal do Rio de Janeiro (NCE/UFRJ)4. Em meio a
2
Acessibilidade Brasil - http://www.acessobrasil.org.br/
Acesso Digital - http://www.acessodigital.net/
4
NCE/UFRJ - http://intervox.nce.ufrj.br/
3
28
outros projetos, encontra-se o sistema operacional para microcomputadores DOSVOX,
destinado a cegos. Outra pesquisa significante é o Guia de Referência em Acessibilidade
Web5, da Universidade Federal do Estado do Rio de Janeiro – UNIRIO, o qual reúne uma
coleção de links para sites, projetos e documentos que tratam de acessibilidade na web.
Dentre as ações governamentais, pode-se encontrar o Instituto Benjamin
Constant (IBC)6, ligado ao Ministério da Educação, o qual constituiu-se
como um centro de referência, a nível nacional, para questões da deficiência
visual. Seus esforços são direcionados para a educação e profissionalização
de deficientes visuais, além da realização de projetos sociais, publicações
científicas e em Braille.
O Serviço Federal de Processamento de Dados (SERPRO) é uma empresa pública,
vinculada ao Ministério da Fazenda, que, entre outras iniciativas, desenvolve projetos e
programas que contemplem as questões sociais de acessibilidade e inclusão digital, e apóia as
políticas do governo federal. Em seu sítio eletrônico7, há uma sessão que trata exclusivamente
da acessibilidade.
5
Guia de Referência UNIRIO - http://www.acessibilidadelegal.com/13-guia.php.
IBC - http://www.ibc.gov.br/.
7
SERPRO – Acessibilidade na web: http://www.serpro.gov.br/acessibilidade/.
6
29
CAPÍTULO 3
DEFICIENTES VISUAIS E BARREIRAS NA UTILIZAÇÃO DE SISTEMAS WEB
Para qualquer aspecto que configure motivação para a acessibilidade – obrigação
legal, razões comerciais, razões técnicas ou mera decência humana – será necessário,
primeiro, a compreensão das diferentes deficiências e o estudo das barreiras faceadas
recorrentemente por portadores de necessidades especiais ao navegarem na web, bem como
tecnologias assistivas existentes que ajudem a transpor tais barreiras. Dentre os vários tipos de
deficiências existentes, este trabalho tem seu foco voltado à deficiência visual.
3.1 Deficiências: definições e tipos
A utilização dos termos “deficiente” ou “portador de necessidades especiais” pode ser
confusa, ou errônea, dada a falta de observância de suas definições. Não é toda dificuldade
que pode ser considerada deficiência. Ela deve estar associada a alguma limitação para a
execução de atividades essenciais da vida cotidiana, como locomoção ou leitura. Ainda sobre
o termo, Spelta (2007b) acrescenta que “a deficiência e o seu grau de severidade dependem
das atividades e dos recursos disponíveis em cada cultura. Os testes para avaliar uma
deficiência visual, por exemplo, consideram o melhor olho, após a aplicação da melhor
correção óptica possível”.
Para esclarecer conceitos de saúde e deficiência, a Organização Mundial de Saúde
publicou, em 2001, a Classificação Internacional de Funcionalidades - CIF (International
Classification of Functioning, Disability and Health - ICF). A CIF diferencia os conceitos de
“deficiência” (impairment), “incapacidade” (disability) e “desvantagem” (handicap). A
deficiência pode gerar uma incapacidade que pode acarretar uma desvantagem, de acordo com
o contexto social.
A definição de “pessoa deficiente”, segundo a ONU - Organização das Nações Unidas
- (apud ACESSIBILIDADE, 2004, p. 15) é: “qualquer pessoa incapaz de assegurar por si
mesma, total ou parcialmente, as necessidades de uma vida individual ou social normal, em
decorrência de uma deficiência congênita ou não, em suas capacidades físicas, sensoriais ou
mentais”.
As definições utilizadas no Brasil para a diferenciação entre os conceitos de
deficiência, incapacidade ou desvantagem, segundo a CORDE, são:
30
 Deficiência: “toda perda ou anormalidade de uma estrutura ou função
psicológica, fisiológica ou anatômica” (apud ACESSIBILIDADE, 2004, p.
20).
 Incapacidade: “toda restrição ou falta (devido a uma deficiência) da capacidade
de realizar uma atividade na forma ou na medida em que se considera normal a
um ser humano” (apud ACESSIBILIDADE, 2004, p. 20).
 Desvantagem: “em conseqüência de uma deficiência ou de uma incapacidade,
que limita ou impede o desempenho de um papel que é normal em seu caso
(em função de idade, sexo e fatores sociais e culturais)”, (apud
ACESSIBILIDADE, 2004, p. 20).
Deficiências podem surgir das mais variadas naturezas, acarretando problemas
motores, cognitivos, mentais, de linguagem, auditivos, visuais ou múltiplos.
Sobre o modo como as deficiências afetam a navegação na Internet, Nielsen (2000, p.
298) esclarece:
O conceito de deficiência precisa ser definido de forma relativamente ampla
quando se fala da Web. Não se trata da pessoa usar uma cadeira de rodas; na
verdade, muitos usuários em cadeiras de rodas não precisam de
considerações especiais quando pesquisam a Web. A questão é se o usuário
tem algum problema que dificulta o uso de dispositivos de entrada e saída
tradicionais.
Ainda segundo Nielsen (2000, p. 302), “os problemas de acessibilidade mais sérios
dado o atual estado da Web, relacionam-se a usuários cegos e a usuários com outras
deficiências visuais, posto que a Web é altamente visual”.
3.2 Deficiências visuais
A deficiência visual constitui diminuição ou perda de capacidade visual, em ambos os
olhos, de modo irreversível, a qual não pode ser atenuada ou retificada com o uso de lentes,
tratamento clínico ou cirúrgico. A deficiência visual pode ser desencadeada acidentalmente,
por razão inata ou hereditária.
O decreto nº 5.296, de 2 de dezembro de 2004, define deficiência visual:
Cegueira, na qual a acuidade visual é igual ou menor que 0,05 no melhor
olho, com a melhor correção óptica; a baixa visão, que significa acuidade
visual entre 0,3 e 0,05 no melhor olho, com a melhor correção óptica; os
casos nos quais a somatória da medida do campo visual em ambos os olhos
31
for igual ou menor que 60o; ou a ocorrência simultânea de quaisquer das
condições anteriores;
Para acessar a web, usuários cegos geralmente utilizam, em lugar de um navegador
comum – com interface gráfica, navegadores textuais juntamente com um programa leitor de
telas, que realiza a leitura em voz alta através de um sintetizador de voz.
Existe, ainda, outra problemática denominada visão subnormal, “cujos limites variam
com outros fatores, tais como: fusão, visão cromática, adaptação ao claro e escuro,
sensibilidades a contrastes, etc.” (IBC, 2009).
Usuários que apresentam baixa visão, ou visão subnormal, conseguem enxergar,
porém possuem este sentido drasticamente reduzido. Estes usuários geralmente necessitam de
tamanhos maiores de fontes (letras) para ver - ainda que com dificuldade -, ou do aumento da
tela via software ou hardware. Entretanto, podem facilmente se perder por visualizarem na
tela apenas uma pequena parte do conteúdo da página.
Além de usuários com visão reduzida, os daltônicos apresentam dificuldade para
distinguir cores. Por esta razão, é aconselhável evitar fundos com textura que interfiram na
leitura e páginas com certas combinações de cores entre primeiro e segundo plano, se não
apresentarem alto contraste. Do mesmo modo, a cor não deve ser o único ou principal
elemento a transmitir uma informação.
Apontadas por Clark (2002c), a seguir, os tipos mais comuns de daltonismo (ou
“cegueira de cor”):
Protanopia: Os receptores de cor nos olhos (cones) não podem distinguir vermelhos e
verdes. Vermelhos, além disso, aparentam ser algo escuro. As cores vermelho e preto podem
parecer as mesmas, se o vermelho for suficientemente escuro. Semelhante ao primeiro caso,
pessoas com protanomalia conseguem distinguir entre vermelhos e verdes, porém os
resultados são parecidos. Na verdade, eles conseguem somente perceber que cores diferentes
estão presentes.
Deuteranopia: Pessoas que também não conseguem distinguir vermelhos e verdes. A
diferença é que onde há vermelho, a cor não é percebida como algo escuro. É a forma mais
encontrada de cegueira de cor. A deuteranomalia possibilita a distinção precisa entre
vermelhos e verdes, ainda que não permita enxergar como uma pessoa sem esta deficiência.
Outra categoria, rara, é a tritanopia, que é a insensibilidade envolvendo as ondas
curtas (azuis). Verdes e azuis podem ser confundidos.
32
3.3 Tecnologias assistivas para deficientes visuais
As diferenças para a navegação na Internet começam já nos softwares utilizados pelos
deficientes, onde o áudio é predominante. Para usuários com baixo grau de visão, programas
especiais podem aumentar a tela. Para usuários cegos, programas sintetizadores de voz fazem
leitura de documentos. O mouse normalmente não é utilizado, por ser um recurso apenas
visual.
Os comandos são realizados através do teclado. A principal forma para ir de uma
página a outra é através do conjunto de teclas TAB - cuja função, dentre outras, é saltar de
link em link - e ENTER – que, ao ser pressionado, ativa o link e muda para a página
especificada. Também existem teclas de atalhos que podem ser especificadas em cada site,
mas geralmente não são utilizadas.
Para usuários cegos, existem sistemas operacionais completos – para computadores –
adequados à sua realidade, que trazem consigo uma gama de aplicativos com diversas
funções: leitores de texto, comunicadores instantâneos, navegadores para Internet,
reprodutores de áudio, entre outros.
Um dos sistemas operacionais mais conhecidos é o DOSVOX, que foi desenvolvido
utilizando tecnologia totalmente brasileira, pelo Núcleo de Computação Eletrônica da
Universidade Federal do Rio de Janeiro (NCE - UFRJ). Segundo Antonio José Borges,
professor do Núcleo, “O sistema operacional DOSVOX permite que pessoas cegas utilizem
um microcomputador comum (PC) para desempenhar uma série de tarefas, adquirindo assim
um nível alto de independência no estudo e no trabalho” (BORGES, 2008).
A seguir, é apresentado o quadro com as tecnologias assistivas mais comuns
empregadas por usuários deficientes visuais no uso de computadores (DIAS 2007, p. 121):
Tecnologias Assistivas
Funcionalidade Proporcionada
Software leitor de tela
Permite ao usuário navegar por janelas, menus e controles
enquanto recebe informações textuais e gráficas (com certas
limitações). Esse software interpreta o que é apresentado na tela e
o direciona a um sintetizador de voz (saída em áudio), ou monitor
em Braille (saída táctil). Imagens sem texto equivalente alternativo
associado não são lidas por esse software. Alguns leitores de tela
não conseguem distinguir colunas, tabelas, frames, e lêem páginas
33
web horizontalmente, misturando textos, imagens e links.
Monitor Braille
Apresenta, linha a linha, o texto que aparece na tela, usando uma
série de pinos em forma de símbolos Braille que são
constantemente atualizados (abaixados ou levantados) à medida
que o usuário navega pela interface.
Tradutor de texto em Traduz texto eletrônico, gerado por software leitor de tela ou
voz
navegador textual, em texto falado por meio de um sintetizador de
voz.
Navegador Web textual
Navegador web, como alternativa aos navegadores de interface
gráfica, que pode ser utilizado em conjunto com software leitor de
tela para auxiliar pessoas cegas. Também é usado por pessoas com
conexões de baixo desempenho ou que não queiram aguardar pelo
download de imagens.
Ampliador de tela
Provê o aumento de uma porção ou de toda a tela, incluindo textos,
gráficos e janelas, permitindo, ao usuário, acompanhar o foco de
entrada.
Tabela A - Tecnologias assistivas para deficientes visuais (DIAS 2007, p. 121).
3.4 Barreiras a acessibilidade
Acessar informações de forma online, para deficientes visuais, implica em muitas
vantagens em comparação a informações impressas. Com um computador e acesso a Internet,
usuários deficientes são estimulados a realizar tarefas que seriam difíceis através de outras
tecnologias. Para que este acesso online ocorra, entretanto, é necessário eliminar obstáculos a
acessibilidade.
Os obstáculos a acessibilidade podem ser categorizados em diferentes áreas,
abrangendo: barreiras urbanísticas, nas edificações, nos transportes e nas comunicações e
informações. Os entraves para a acessibilidade na web se enquadram entre as “barreiras nas
comunicações e informações”, definidas pelo Decreto de Lei nº 5.296 (BRASIL, 2004a), da
seguinte forma:
Qualquer entrave ou obstáculo que dificulte ou impossibilite a expressão ou
o recebimento de mensagens por intermédio dos dispositivos, meios ou
sistemas de comunicação, sejam ou não de massa, bem como aqueles que
dificultem ou impossibilitem o acesso à informação.
34
Diferentes empecilhos podem ser encontrados por deficientes visuais quando navegam
por páginas na Internet, de acordo com a deficiência que apresentam. A seguir, exemplos
destes empecilhos, faceados por usuários cegos, com baixa visão e daltônicos (SERPRO,
2008b):
a)
Exemplos de barreiras na web para usuários que apresentam cegueira:

Imagens sem descrição textual alternativa equivalente.

Imagens complexas, relevantes, que não possuem descrição adequada.

Vídeos sem descrição textual ou sonora.

Tabelas que não fazem sentido quando lidas célula a célula ou de forma
linearizada.

Frames (quadros) que não apresentam a alternativa “noframe” (“sem quadro”),
ou nomeados inadequadamente.

Formulários que não admitem uma navegação seqüencial lógica ou não
apresentam seus campos devidamente rotulados.

Navegadores e ferramentas de autoria que não oferecem suporte a navegação
pelo teclado.

Navegadores e ferramentas de autoria que não utilizam programas de interfaces
padronizadas para o sistema operacional em que foram baseados.

Documentos concebidos fora dos padrões web, dificultando a interpretação por
leitores de tela.
b) Exemplos de barreiras na web para usuários que apresentam baixa visão:

Páginas com fontes de tamanho absoluto (fixo), que inviabilizam sua
ampliação ou redução.

Páginas com layout inconsistente e de difícil navegação quando ampliadas.

Páginas ou imagens com contraste de cor e brilho insuficientes.

Textos apresentados no formato de imagens (não permitem quebra de linha
quando ampliados).
c)
Exemplos de barreiras na web para usuários que apresentam daltonismo:

Utilização da cor como único recurso para enfatizar o texto (transmitir
informação).

Contrastes indevidos entre as cores da fonte (primeiro plano) e fundo (segundo
plano).

Navegadores que não possibilitam ao usuário utilizar folhas de estilo
personalizadas.
35
Existem outras barreiras para deficientes visuais, a depender do tipo e extensão da
limitação da visão. Além das citadas acima, animações – que utilizam a tecnologia Flash ou
similar, sem descrição textual ou sonora, compreensíveis somente através da visão – e
ausência de atalhos para o teclado do computador completam o quadro das barreiras mais
ocorrentes.
36
CAPÍTULO 4
DIRETRIZES E TÉCNICAS PARA SISTEMAS ACESSÍVEIS
Para o escopo da deficiência visual, existe uma série de diretrizes que especificam
questões de acessibilidade para páginas na Internet, bem como diversas técnicas que devem
ser aplicadas ao código das páginas web para possibilitar, ou facilitar, o acesso, a navegação e
o entendimento do conteúdo.
4.1 Diretrizes para acessibilidade web
As diretrizes para acessibilidade na web são regulamentadas pelo World Wide Web
Consortium, um grupo empenhado em desenvolver e difundir Web Standards, ou padrões
web.
4.1.1 World Wide Web Consortium
O World Wide Web Consortium (W3C) é um consórcio internacional comprometido
com o desenvolvimento de padrões web. O W3C tem por missão conduzir a World Wide Web
para que atinja seu potencial pleno, desenvolvendo protocolos e diretrizes (guidelines) que
assegurem seu crescimento a longo prazo (W3C, 2009). Fundado em 1994, no Laboratório de
Ciência da Computação do Instituto de Tecnologia de Massachusetts (MIT-LCS), O
consórcio, desde o seu princípio, tem trabalhado incessantemente para promover a evolução e
interoperabilidade da web. O W3C possui representações em diversos países. Seu escritório
no Brasil8 foi fundado em 1 de novembro de 2007.
Para o cumprimento de seus princípios – web para todos (Web for All) e web em todos
os dispositivos (Web on Everything), o W3C lançou a Iniciativa para Acessibilidade Web
(Web Accessibility Initiative - WAI) que trabalha com organizações ao redor do mundo para
desenvolver estratégias, diretrizes e recursos para tornar a web acessível a pessoas com
deficiência. A WAI atua junto a indústrias, organizações que auxiliam deficientes, governos e
instituições de pesquisa sobre acessibilidade, para que as tecnologias, ferramentas de
desenvolvimento e profissionais web apliquem a acessibilidade. Entre as diversas publicações
da WAI, encontram-se as Recomendações para Acessibilidade de Conteúdo Web.
8
http://www.w3c.br/.
37
4.1.2 Recomendações para acessibilidade de conteúdo web
As Recomendações para Acessibilidade de Conteúdo Web 1.0 (WCAG – Web Content
Accessibility Guidelines 1.09) fazem parte de uma série de diretrizes do W3C, publicadas com
a finalidade de auxiliar autores de páginas, projetistas de sites e desenvolvedores de
ferramentas de autoria a tornar o conteúdo da web acessível a deficientes.
As WCAG 1.0 foram lançadas em 5 de Maio de 1999, firmando-se como guia oficial
do W3C, utilizado e traduzido em diversos países, por colaboradores voluntários, em seus
respectivos idiomas. A tradução para a língua portuguesa10 já está disponível.
As recomendações abordam dois temas genéricos: assegurar uma transformação
harmoniosa e tornar o conteúdo compreensível e navegável. A aplicação destas diretrizes
beneficia não apenas deficientes – seu principal objetivo, mas torna o acesso às informações
mais rápido e fácil, mesmo sob circunstâncias adversas, sem o uso das mãos, em um ambiente
com ruídos ou mal iluminado.
Sobre a possibilidade de as WCAG limitarem o conteúdo web, Dias (2007, p. 139):
contradiz:
As recomendações constantes do guia W3C explicam como tornar o
conteúdo web acessível a pessoas com deficiências, sem o intuito de
restringir a utilização de imagem ou vídeo, por parte dos produtores de
conteúdo; ao contrário, explicam como tornar o conteúdo em multimídia
mais acessível a um público mais vasto.
As Recomendações para Acessibilidade de Conteúdo Web 1.0 (W3C, 1999) são
compostas por um conjunto de 14 diretrizes:
1. Fornecer alternativas equivalentes ao conteúdo sonoro e visual: Esta
recomendação destaca a importância de fornecer equivalentes textuais para elementos
não textuais (como imagens, áudio pré-gravado, vídeo). O conteúdo apresentado ao
usuário deve transmitir, em essência, as mesmas funções e finalidade que o conteúdo
sonoro ou visual, para que aqueles que não vêem (ou não podem olhar) atinjam o
mesmo grau de compreensão.
9
As WCAG 1.0 estão disponíveis em: http://www.w3.org/TR/WAI-WEBCONTENT.
As WCAG 1.0 foram em português disponibilizadas até novembro 2009 em:
http://www.geocities.com/claudiaad/acessibilidade_web.html. Contudo, ainda podem ser encontradas em:
http://web.archive.org/web/20071028094752/http://www.geocities.com/claudiaad/acessibilidade_web.html
10
38
2. Não recorrer apenas à cor: Deve-se assegurar a percepção do texto e dos elementos
gráficos quando vistos sem cores, utilizando-se do contexto ou de marcações. A
utilização da cor como único recurso para transmitir informação pode impedir pessoas
que não são capazes de diferenciar certas cores e usuários de dispositivos não
coloridos ou monitores não visuais de receber essas informações.
3. Utilizar corretamente marcações e folhas de estilo: Documentos devem ser
marcados com os elementos estruturais adequados, e a apresentação deve ser
controlada por meio de folhas de estilo, em vez de elementos de apresentação e
atributos. A diferença entre conteúdo, estrutura e apresentação será explanada
posteriormente.
4. Indicar claramente qual o idioma utilizado: Utilizar marcações que facilitem a
pronúncia e a interpretação de abreviaturas ou texto em língua estrangeira. Assim,
sintetizadores de voz e dispositivos Braille podem passar automaticamente para um
novo idioma. O idioma predominante do documento deve ser identificado e siglas de
quaisquer abreviaturas devem ser acompanhadas da versão por extenso.
5. Criar tabelas passíveis de transformação harmoniosa: As tabelas precisam conter
as marcações necessárias (exemplo: cabeçalhos de linhas e colunas) para poderem ser
transformadas harmoniosamente por navegadores acessíveis e outros agentes do
usuário. Tabelas devem ser utilizadas apenas para marcar informações tabulares
genuínas (“tabelas de dados”), e não como recurso de paginação (“tabelas de
disposição”) – a menos que façam sentido quando lidas de modo linearizado.
6. Assegurar que as páginas dotadas de novas tecnologias sejam transformadas
harmoniosamente: É preciso garantir que as páginas sejam acessíveis mesmo quando
as tecnologias mais recentes não forem suportadas ou tenham sido desativadas.
7. Assegurar o controle do usuário sobre as alterações temporais do conteúdo:
Oferecer mecanismos para a interrupção momentânea ou definitiva de movimento,
intermitência, transcurso ou atualização automática de objetos ou páginas. Caso o
usuário não possa controlar estes itens, eles devem ser evitados.
8. Assegurar a acessibilidade direta de interfaces do usuário integradas: Interfaces
devem obedecer a princípios de design para a acessibilidade, permitindo seu acesso
independente de dispositivos (tecnologias de apoio), operacionalidade pelo teclado e
emissão automática de voz (verbalização).
39
9. Projetar páginas considerando a independência de dispositivos: As páginas devem
permitir o acesso e utilização por meio de uma grande variedade de dispositivos de
entrada de comandos (mouse, teclado, voz, ponteiro de cabeça, ou outro).
10. Utilizar soluções de transição: É preciso fornecer soluções de acessibilidade
transitórias, para que as tecnologias de apoio e os navegadores mais antigos funcionem
corretamente.
11. Utilizar tecnologias e recomendações do W3C: deve-se utilizar tecnologias
concordantes com as especificações do W3C e seguir suas recomendações de
acessibilidade. Quando isto não for possível, deve-se fornecer uma versão alternativa,
acessível, do conteúdo.
12. Fornecer informações de contexto e orientações: A provisão de contexto e
orientações para ajudar os usuários a compreenderem páginas ou elementos
complexos é imprescindível.
13. Fornecer mecanismos de navegação claros: Os mecanismos de navegação precisam
ser coerentes e sistematizados, incluindo informações de orientação como barras de
navegação e mapa do site, para aumentar as probabilidades de uma pessoa encontrar o
que procura em um dado site.
14. Assegurar a clareza e a simplicidade dos documentos: Os documentos devem ser
claros, simples e fáceis de compreender. Estes objetivos podem ser alcançados com a
utilização de paginação (disposição em página) coerente e sistemática, de gráficos
reconhecíveis (e com equivalência textual) e de uma linguagem fácil.
Cada diretriz possui pontos de verificação, para que se meça o impacto em termos de
acessibilidade, aos quais foram atribuídos diferentes níveis de prioridade:
Prioridade 1: “Pontos que os criadores de conteúdo web devem satisfazer inteiramente.
Se não o fizerem, um ou mais grupos de usuários ficarão impossibilitados de acessar as
informações contidas no documento” (W3C, 1999).
Prioridade 2: “Pontos que os criadores de conteúdos na web deveriam satisfazer. Se
não o fizerem, um ou mais grupos de usuários terão dificuldades em acessar as informações
contidas no documento” (W3C, 1999).
Prioridade 3: “Pontos que os criadores de conteúdos na web podem satisfazer. Se não
o fizerem, um ou mais grupos poderão se deparar com algumas dificuldades em acessar
informações contidas nos documentos” (W3C, 1999).
O documento WCAG 1.0 estabeleceu, também, níveis de conformidade, para avaliar a
satisfação dos pontos de verificação. Se todos os pontos de verificação de prioridade 1 foram
40
satisfeitos, o nível de conformidade é “A”, o mais baixo. Caso todos os pontos de verificação
de prioridades 1 e 2 foram atendidos, o nível é “AA”. Para o nível de conformidade “AAA”, o
mais elevado, foram satisfeitos todos os pontos de verificação de prioridades 1, 2 e 3. A
imagem 4.1 demonstra os selos dos três níveis de conformidade que podem ser obtidos:
Figura 4.1 - Selos de níveis de conformidade que podem ser obtidos por uma página web.
Outro documento, denominado Técnicas para Acessibilidade de Conteúdo Web 1.0
(Techniques for Web Content Accessibility Guidelines 1.011), explica como implementar os
pontos das WCAG 1.0, provendo maiores detalhes e exemplos usando HTML, CSS
(Cascading Style Sheets, ou Folhas de Estilo em Cascata), e outras linguagens.
Em sua segunda versão, anunciada em 11 de dezembro de 2008, as Recomendações
para Acessibilidade de Conteúdo Web 2.012 (WCAG 2.0) foram organizadas para atender a
quatro princípios que, para o W3C, constituem a fundação da acessibilidade da web:
perceptível, operável, compreensível e robusto.
As WCAG 2.0 baseiam-se nas WCAG 1.0. Seus princípios não são específicos a uma
linguagem de marcação, como HTML, mas sim concebidos para serem aplicados em larga
escala a diferentes tecnologias web. A segunda versão das WCAG é apoiada por outros
documentos, denominados Entendendo o WCAG 2.013 e Técnicas para o WCAG 2.014. Ainda
que não possuam o status formal de recomendação como as WCAG 2.0, fornecem
informações essenciais para a compreensão e implementação das WCAG. As WCAG 2.0
também já podem ser encontradas na língua portuguesa15.
Os três níveis de conformidade (níveis A, AA e AAA) são mantidos na segunda
versão das recomendações. Cada recomendação traz seu nível de conformidade e o critério de
sucesso correspondente (que indica como a diretriz será atendida). Em adição, é reforçada a
idéia de que, para se obter um determinado nível de conformidade, todas as páginas devem
atender aos pontos de verificação, e não apenas uma parte destas. Se determinado processo
11
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/.
As WCAG 2.0 estão disponíveis em: http://www.w3.org/TR/WCAG20/.
13
Entendendo o WCAG 2.0: http://www.w3.org/TR/UNDERSTANDING-WCAG20/.
14
Técnicas para o WCAG 2.0: http://www.w3.org/TR/WCAG20-TECHS/.
15
As WCAG 2.0 em português: http://www.ilearn.com.br/TR/WCAG20/.
12
41
em um site exige mais de uma página, todas devem se adequar ao mesmo nível de
conformidade ou superior.
A seguir as 12 diretrizes para Acessibilidade de Conteúdo Web 2.0, enquadradas nos
quatro princípios, extraídos na integra (W3C, 2008):
Princípio 1: Perceptível - A informação e os componentes da interface do usuário
têm de ser apresentados aos usuários em formas que eles possam perceber.
 Recomendação 1.1: Alternativas em texto - Fornecer alternativas em texto para
qualquer conteúdo não textual permitindo, assim, que o mesmo possa ser
alterado para outras formas mais adequadas à necessidade do indivíduo, tais
como impressão em caracteres ampliados, Braille, fala, símbolos ou linguagem
mais simples.
 Recomendação 1.2: Mídias com base no tempo - Fornecer alternativas para
mídias com base no tempo.
 Recomendação 1.3: Adaptável - Criar conteúdos que possam ser apresentados
de diferentes maneiras (por exemplo, um layout mais simples) sem perder
informação ou estrutura.
 Recomendação 1.4: Discernível - Facilitar a audição e a visualização de
conteúdos aos usuários, incluindo a separação do primeiro plano e do plano de
fundo.
Princípio 2: Operável - Os componentes de interface de usuário e a navegação têm
de ser operáveis.
 Recomendação 2.1: Acessível por teclado - Fazer com que toda a
funcionalidade fique disponível a partir do teclado.
 Recomendação 2.2: Tempo suficiente - Fornecer tempo suficiente aos usuários
para lerem e utilizarem o conteúdo.
 Recomendação 2.3: Ataques epilépticos - Não criar conteúdo de uma forma
conhecida que possa causar ataques epilépticos (Exemplo: mais de três flashs
no período de um segundo).
 Recomendação 2.4: Navegável - Fornecer formas de ajudar os usuários a
navegar, localizar conteúdos e determinar o local onde estão.
Princípio 3: Compreensível - A informação e a operação da interface de usuário têm
de ser compreensíveis.
42
 Recomendação 3.1: Legível - Tornar o conteúdo de texto legível e
compreensível.
 Recomendação 3.2: Previsível - Fazer com que as páginas web surjam e
funcionem de forma previsível.
 Recomendação 3.3: Assistência de entrada - Ajudar os usuários a evitar e
corrigir erros.
Princípio 4: Robusto - O conteúdo tem de ser robusto o suficiente para poder ser
interpretado de forma concisa por diversos agentes do usuário, incluindo tecnologias
assistivas.
 Recomendação 4.1: Compatível - Maximizar a compatibilidade com atuais e
futuros agentes de usuário, incluindo tecnologias assistivas.
A seguir são especificadas as principais técnicas utilizadas para aplicar as diretrizes de
acessibilidade web e satisfazer os critérios de sucesso estabelecidos pelo W3C.
4.2 Técnicas para acessibilidade web
Técnicas simples, aplicadas no código das páginas web, viabilizam a acessibilidade,
como Nielsen (2000, p. 298) destaca:
Tornar a Web mais acessível a usuários com várias deficiências resume-se,
até certo ponto, a usar o HTML da forma pretendida: para codificar
significado em vez de aparência. Desde que a página seja codificada para o
significado, é possível que os browsers alternativos apresentem esse
significado de formas otimizadas às capacidades de usuários individuais e,
assim, facilitem o uso da Web por usuários deficientes.
Um dos primeiros fatores que devem ser compreendidos pelos profissionais da área é a
diferença apontada por Nielsen entre significado e aparência. O termo “significado” pode ser
compreendido também como “conteúdo”, enquanto o termo “aparência” compreende o
mesmo que “apresentação”.
As Recomendações para Acessibilidade de Conteúdo Web 2.0 diferenciam os termos
do seguinte modo:
Conteúdo (conteúdo da Web): Informação e experiência sensorial a serem
comunicadas ao usuário através de um agente de usuário, incluindo o código ou a marcação
que define a estrutura, a apresentação e as interações (W3C, 2008).
43
Estrutura: O modo como as partes de uma página web estão organizadas em relação
umas às outras; e o modo como um conjunto de páginas web está organizado. A estrutura é
composta pelos elementos da linguagem de marcação (HTML), ou código (W3C, 2008).
Apresentação: Composição do conteúdo de forma que seja compreendido pelos
usuários. A apresentação é definida, geralmente, por folhas de estilo – CSS (W3C, 2008).
As principais técnicas para desenvolver sites acessíveis são descritas adiante.
4.2.1 Declaração e estrutura de documentos
A Declaração de Tipo de Documento (DOCTYPE - Document Type Definition)
constitui um importante aspecto para a acessibilidade. A Declaração de Tipo de Documento
(DTD) não é uma tag (etiqueta, marca) HTML, porém instrui os navegadores web sobre a
versão da linguagem de marcação utilizada na página, permitindo a exibição correta do
conteúdo. O DTD também permite aos validadores automáticos de páginas a efetuar uma
avaliação mais precisa, baseando-se nas especificações e regras corretas para a versão do
código utilizado. As principais DTD, segundo Gameleira (2002a), são:
HTML 4.01 Strict - Esta DTD contém todos os tipos de elementos e atributos HTML,
mas não permite a inclusão de apresentação ou elementos depreciados (como a tag <FONT>).
Frames não são permitidos.
HTML 4.01 Transitional - Contém todos os tipos de elementos e atributos HTML, e
permite a inclusão de apresentação e elementos depreciados (ou seja, não mais
recomendados). Frames não são permitidos.
XHTML 1.0 Strict - Contém todos os tipos de elementos e atributos HTML, mas não
permite a inclusão de apresentação ou elementos depreciados. Frames não são permitidos. As
marcações devem ser escritas com XML (Extensible Markup Language, Linguagem de
Marcação Extensível) semanticamente corretos e bem formados.
XHTML 1.0 Transitional - Contém todos os tipos de elementos e atributos HTML, e
permite a inclusão de apresentação e elementos depreciados. Frames não são permitidos. As
marcações devem ser escritas com XML semanticamente corretos e bem formados.
44
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1transitional.dtd">
Figura 4.2 - Exemplos das principais declarações de tipo de documento – DTD.
O W3C disponibiliza uma lista completa com todas as versões de DTD16. A versão
atualmente recomendada é a XHTML 1.0 Strict.
Após uma declaração consistente do documento, é preciso, de acordo com Nielsen
(2000), assegurar que a página possua uma marcação HTML adequada, utilizando <H1> para
o cabeçalho de nível superior, <H2> para títulos importantes dentro de <H1>, e <H3> para
divisões mais sutis de informação, ou seja, subtítulos de <H2>. Desta forma, usuários com
leitores de tela podem ter uma compreensão rápida da página ao instruir o programa para ler
apenas títulos e ganhar tempo ao pular para outra seção, caso a atual não seja interessante.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="pt-br">
<head>
<title>Título do documento</title>
</head>
<body>
<h1>Título principal de conteúdo</h1>
<p>Conteúdo do documento...</p>
</body>
</html>
Figura 4.3 - Estrutura básica de um documento HTML.
O idioma principal do documento é outro elemento que deve ser identificado. A figura
4.3 demonstra, juntamente com a tag HTML, o atributo lang, cujo objetivo é identificar a
16
Lista de DTD recomendadas: http://www.w3.org/QA/2002/04/valid-dtd-list.html.
45
linguagem principal do documento. Além de auxiliar a segmentação por idioma em
mecanismos de busca, o objetivo capital de se especificar a linguagem principal do
documento é permitir que leitores de tela identifiquem automaticamente o idioma e os
sintetizadores de voz leiam adequadamente o conteúdo. As alterações de idioma no decorrer
da página devem também ser identificadas pela mesma razão. O atributo lang pode ser
utilizado em conjunto com outras tags, como as que definem blocos ou parágrafos.
4.2.2 Navegação
Um bom posicionamento e organização do conteúdo resultam em uma página com
estrutura consistente. Áreas de informações específicas do site – como cabeçalho, menus de
navegação (principal e secundário), conteúdo, e rodapé – devem ser definidas e exibidas
sempre nos locais pré-estabelecidos. Se o conteúdo principal da página estiver sempre no
mesmo local, por exemplo, o usuário poderá saltar diretamente para esta parte, desobrigandose de ouvir novamente todas as opções do menu de navegação (GAMELEIRA, 2002b).
Uma navegação ideal também não exige que o usuário acione mais de três links para
chegar à informação pretendida. Uma página sobre a acessibilidade do site precisa estar
disponível, informando aos usuários como o conteúdo está organizado e de que forma se dá a
navegação, incluindo atalhos de teclados em navegadores distintos17(GAMELEIRA, 2002b).
Desenvolvedores freqüentemente utilizam o recurso que direciona o conteúdo de um
link para abrir em uma nova janela. O ponto de verificação 10.1 das WCAG 1.0 adverte que,
até que os agentes do usuário o permitam desativar janelas secundárias, não se deve provocar
o aparecimento de janelas de sobreposição ou outras quaisquer, tampouco fazer com que o
conteúdo da janela atual seja modificado sem que o usuário seja informado (W3C, 1999). No
HTML, o valor “_blank” (nova janela), do atributo target (alvo), utilizado em links, permite
tal situação. O objetivo de se utilizar uma nova janela é fazer com que os usuários se lembrem
de retornar ao site de onde partiram. Mas o que prende a atenção dos usuários é um bom
conteúdo.
É extremamente difícil para um deficiente visual saber se a página aberta está na
mesma janela ou em uma nova. Portanto, o padrão para o destino dos links deve ser a própria
janela. Desta forma, o usuário poderá retornar a página anterior, através da combinação das
teclas BACKSPACE + Seta esquerda ou ALT + Seta esquerda (GAMELEIRA, 2002b).
17
Exemplo de página sobre a acessibilidade do site: http://www.acessibilidadelegal.com/00-acessibilidade.php.
46
4.2.3 Folhas de estilo
Cascading Style Sheets (CSS), ou folhas de estilo em cascata, por princípio, permitem
a separação de apresentação e conteúdo, decoração da essência. O uso de estilos misturados
nas linhas dos elementos HTML é proibido nas verões HTML Strict e XHTML Strict.
Tamanhos de fontes, tipologia, planos de fundos, posicionamento de blocos e
inúmeros outros itens de apresentação são definidos para todas as páginas de um site e
referenciados em um único arquivo de estilo. Um excelente projeto que auxilia no
entendimento da separação entre conteúdo e apresentação é o Zen Garden18, cujo mesmo
conteúdo é apresentado em dezenas de formas diferentes, apenas modificando-se o CSS.
Desenvolvedores podem se inscrever e enviar um novo arquivo de estilo para ser incorporado
aos diversos temas existentes, sempre com o mesmo conteúdo.
As folhas de estilo são suportadas pela grande maioria dos navegadores. As vantagens
assinaladas por Krug (2008) são enormes:
 Controle imensamente maior sobre a formatação.
 Flexibilidade. Uma única alteração na folha de estilo pode modificar a
aparência de todo o site. Não é necessário alterar página por página.
 Consistência entre navegadores. Há a necessidade de maleabilidade e
experimentações, mas é possível que o CSS funcione em todos os navegadores.
 Serialização do conteúdo. O conteúdo pode ser colocado em ordem seqüencial
na página, facilitando o entendimento para usuários de leitores de tela. O
posicionamento visual dos elementos fica a encargo do CSS.
 Possibilidade de mudança no tamanho do texto. O CSS facilita a mudança de
tamanho no texto, funcionalidade útil para usuários com pouca visão (ou que
necessitem de lentes bifocais).
O W3C publicou um documento que descreve as técnicas para a elaboração de folhas
de estilo em cascata19, disponível também na língua portuguesa20.
A segunda versão do CSS, que se tornou uma recomendação do W3C em 12 de maio
de 199821, instituiu “tipos de mídia”, a fim de uma exibição mais apropriada do conteúdo em
determinados tipos de dispositivos de visualização ou leitura. Estas folhas de estilo podem
adaptar apresentações do conteúdo para dispositivos com saída em Braille, sintetizadores de
18
Zen Garden - http://www.csszengarden.com/tr/portuguese/.
Técnicas CSS para acessibilidade - http://www.w3.org/TR/2000/NOTE-WCAG10-CSS-TECHS-20001106/.
20
Tradução das Técnicas CSS para acessibilidade - http://www.maujor.com/w3c/tec_css_acess.html.
21
CSS 2 Specification - http://www.w3.org/TR/1998/REC-CSS2-19980512/.
19
47
voz, ou dispositivos TTY (teletypewriters ou dispositivos de telecomunicação para surdos).
Conforme Clark (2002d), os tipos de mídias principais são os seguintes:

Aural: Planejado para sintetizadores de voz.

Braille: Utilizado para dispositivos que fornecem resposta tátil em Braille.

Embossed: Utilizado para impressoras de páginas em Braille.

Print: Utilizado para impressão em papel, material opaco e para documentos
visualizados na tela em modo de impressão.

Screen: Utilizada principalmente para atender a telas coloridas de
computadores.

Tty: Pretendido para mídias que utilizam caracteres de comprimento fixo, como
teletipos, terminais, ou dispositivos portáteis com capacidade limitada de
exibição.
A lista completa de mídias reconhecidas pelo W3C está disponível em seu site22.
O código presente no gráfico 4.4 demonstra como referenciar folhas de estilo,
exemplificando três tipos distintos de mídia:
<link rel="stylesheet" href="estilo-tty.css"
type="text/css" media="tty" />
<link rel="stylesheet" href="estilo-aural.css"
type="text/css" media="aural" />
<link rel="stylesheet" href="estilo-braille.css"
type="text/css" media="braille" />
Figura 4.4 - Exemplo de como referenciar o CSS em uma página.
O CSS 2 provê propriedades auditivas que levam informações para usuários com
deficiências visuais e auditivas de modo semelhante às informações passadas visualmente
através de textos. O documento do W3C, Técnicas CSS para acessibilidade a conteúdo web Diretrizes 1.0, citado anteriormente, traz exemplos da aplicação de mídias distintas.
22
Lista de tipos de mídias reconhecidas - http://www.w3.org/TR/CSS2/media.html.
48
h1 {
voice-family: paul;
stress: 20;
richness: 90;
cue-before: url("ping.au")
}
Figura 4.5 - Exemplo da aplicação de folhas de estilo em Cascata auditivas (Aural).
O exemplo dado pela figura 4.5 demonstra de que forma variadas nuances do som
(incluindo “voice-family”, que é muito semelhante a uma fonte de áudio) indicam, ao usuário,
que o conteúdo sonorizado é um cabeçalho.
As propriedades a seguir, extraídas das Técnicas CSS para acessibilidade a conteúdo
web - Diretrizes 1.0, fazem parte das folhas de estilo auditivas CSS 2.

“volume” controla o volume do texto lido.

“speak” controla se o conteúdo será ou não lido e, em caso positivo, se será
soletrado ou lido normalmente.

“pause”, “pause-before”, e “pause-after” controla as pausas antes e depois de
uma leitura. Isto permite ao usuário separar conteúdos, melhorando seu
entendimento.

“cue”, “cue-before”, e “cue-after” especificam um som a ser reproduzido antes
e depois do conteúdo, o que pode ser valioso para orientação (bastante
parecido a um ícone visual).

“play-during” controla um som de fundo enquanto o documento é processado
(bastante parecido a uma imagem de fundo).

“azimuth” e “elevation” proporcionam uma dimensão ao som, o que permite ao
usuário distinguir vozes, por exemplo.

“speech-rate”, “voice-family”, “pitch”, “pitch-range”, “stress”, e “richness”
controlam a qualidade do conteúdo lido. Variando estas propriedades para os
diferentes elementos, os usuários podem fazer uma sintonia fina nos conteúdos
lidos da apresentação auditiva.

“speak-punctuation” e “speak-numeral” controlam a maneira como números e
sinais de pontuação são lidos, o que afeta a qualidade da experiência de uma
navegação auditiva.
Existe, ainda, a propriedade “speak-header”, que controla como devem ser lidas as
células de cabeçalho, antes das células de conteúdo (SILVA, 2003).
49
É possível definir, em um mesmo documento de folhas de estilo, vários tipos de mídia.
No exemplo a seguir, são definidos tamanhos diferentes para a fonte (font-size), a depender da
mídia onde o documento será processado, e um mesmo espaçamento entre linhas (line-height)
é determinado para as mídias tela e impressão (screen e print).
@media
body
}
@media
body
}
@media
body
}
print {
{ font-size: 10pt }
screen {
{ font-size: 13px }
screen, print {
{ line-height: 1.2 }
Figura 4.6 - Diferentes tipos de mídia definidos em um mesmo documento de estilo.
4.2.4 Cores e fontes
A diretriz 1.4.1 (WCAG 2.0) afirma que a cor não deve ser o único meio para se
“transmitir informações, indicar uma ação, pedir uma resposta ou distinguir um elemento
visual” (W3C, 2008). Um exemplo simples e prático refere-se aos links. Sempre que um
usuário focar ou ativar um link, ele pode apresentar uma mudança de estilo ou forma (por
exemplo: sublinhado, negrito, itálico ou aumento de fonte), ao invés de apenas modificar a
cor. Usuários com baixa visão, visão monocromática, acromática ou com dificuldade para
distinguir cores são os beneficiados por tal diretriz de acessibilidade.
O contraste compreende outro elemento fundamental para a apresentação visual do
conteúdo. O contraste deve estar presente em todos os elementos, como botões de navegação,
tipografia, ícones e links, principalmente entre primeiro plano e plano de fundo. Um botão ou
link pode ser inserido no site para permitir ao usuário alternar o esquema de cores para uma
versão com alto contraste. Contudo, isto não significa que designers terão que criar páginas
com visual pobre, apenas texto, ou não utilizar imagens (fotografias). Significa que o assunto
carece de alguns cuidados. Onde a cor implicar algum significado, deve-se assegurar que seja
de fácil compreensão e distinção em relação a outras cores, e que o conteúdo esteja disponível
em outro formato. Se a cor não transmitir alguma informação significativa (além de
decoração), alterar a imagem torna-se opcional (CLARK, 2002c). No exemplo a seguir, o
50
gráfico (4.7) de linhas do metrô de Londres pode exibir uma versão alternativa em preto e
branco, além de estar acompanhado de informação textual.
Figura 4.7 - A cor não deve ser o único elemento para a transmissão de informações.
Um dos documentos do W3C, sobre técnicas de acessibilidade, traz uma lista
denominada web-safe colors 23(cores seguras para web), com 26 cores, que resultam em taxas
de contraste aceitáveis quando utilizadas em conjunto com preto (taxa de contraste 3:1) e
branco (taxa de contraste 5:1). Para links, circundados por texto preto (código hexadecimal:
#000000), e fundo branco, a cor azul apresenta um excelente contraste (código hexadecimal:
#3366CC). A cor azul é recomendada para links por afetar pouco a usuários com dificuldade
para distinguir as cores vermelho e verde.
O vermelho e o verde são os tons que mais afetam usuários com deficiências visuais
relativas a cores, os daltônicos. Um fato que ocorre, por vezes, é a confusão que este tipo de
deficiência ocasiona com bege, amarelo e laranja, sendo descritos como vermelho e verde. A
razão é que vermelho e verde podem ser percebidos como falso bege, amarelo ou laranja.
Portanto, os tons que devem ser utilizados com cuidado são: vermelho, laranja, amarelo, bege
e verde (CLARK, 2002c).
Sempre que ocorrer o processo de seleção de cores para determinado site, ao menos
cinco itens precisam ter suas cores definidas: texto, plano de fundo, links normais, links ativos
e links visitados. O padrão mínimo de cinco cores deve ser adotado a fim de evitar conflitos
23
Web-safe colors - http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/workingexamples/G183/link-contrast.html.
51
com as cores padrão do programa de navegação que o usuário faz uso. Durante este
procedimento, algumas combinações de cores precisam ser evitadas:
 O vermelho não deve ser aplicado ao preto, tampouco o preto sobre o
vermelho. O vermelho aparenta escuro para pessoas com protanopia, e a
combinação pode parecer bege, amarelo ou laranja sobre preto. Cinza escuro,
neste caso, tem o mesmo efeito do preto.
 Verde sobre vermelho ou vermelho sobre verde são combinações
complementares que não devem ser aplicadas. A maioria dos cegos de cor irá
confundi-las.
 Duas metades de um par de cores confuso não devem ser posicionadas com
proximidade.
 Bege, amarelo ou laranja não devem ser misturados com vermelho e verde
(CLARK, 2002c).
A diretriz WCAG que trata de cores beneficia igualmente a pessoas que apresentam
monocromia, também conhecida como acromia, e constituem um grupo raro de usuários com
ausência da percepção de cores, enxergando sempre em tons de cinza. E, ainda, usuários que
utilizam telas monocromáticas.
No tangente a tipologia (ou seja, fontes ou tipos de letras), mais de um tipo de fonte
deve ser especificado. Clark (2002c) adiciona uma recomendação para o momento em que se
definem as fontes, através de folhas de estilo: especificar uma família de fonte genérica ao fim
de cada declaração de fonte. Subentende-se que uma fonte genérica estará presente na maioria
dos sistemas de computação utilizados pelos usuários. Caso o sistema não reconheça nenhuma
das fontes determinadas anteriormente, é provável que reconheça ao menos a fonte genérica
indicada.
As famílias de fontes genéricas em CSS nível 2 são: serif, sans-serif, cursive, fantasy e
monospace.
body {
font-family: Georgia, Times New Roman, Times, serif;
font-size:inherit;
}
Figura 4.8 - Exemplo de declaração de fontes utilizando CSS.
52
O tamanho das fontes não deve ser definido de forma absoluta, utilizando unidades
como pontos ou centímetros. Segundo Nielsen (2000b, p. 302), é imprescindível codificar as
informações de forma relativa, utilizando um percentual do tamanho da fonte padrão (default)
utilizada pelo navegador do usuário. Unidades relativas de fontes comuns são “%” e “em”
(SILVA, 2004). Ele acrescenta: “o suporte total a usuários com visão reduzida necessitaria de
que as páginas ficassem igualmente bem em todos os tamanhos de fonte”. Para assegurar que
a página funcione perfeitamente em todos os tamanhos de fontes, Nielsen (2000b) recomenda
o teste das páginas com tamanhos relativos e o navegador ajustado aos padrões 10, 12 e 14
pontos, para que se garanta um design ótimo com estes tamanhos de fontes comuns. E, após
os primeiros testes, testes adicionais com fontes padrão definidas em 18 e 24 pontos, a fim de
garantir que o design funcione nestes tamanhos que aumentam a acessibilidade.
A recomendação 1.4.4 das WCAG 2.0 requisita que o texto possa ser redimensionado
sem tecnologia assistiva em até 200 por cento, sem perder conteúdo ou funcionalidade. O
item 3.2.10 menciona um script disponível na web para atender tal requisição. Mesmo que o
site não forneça nenhuma funcionalidade direta para redimensionar textos, o uso de medidas
relativas permite que o usuário redimensione o texto através do software de navegação
utilizado.
4.2.5 Navegação pelo teclado
Todo elemento de uma página HTML, seja um link, um bloco div, uma tabela, um
parágrafo, entre outros, constitui um objeto, mesmo que não seja visualmente percebido como
tal (GAMELEIRA, 2002b). Estes objetos podem ser acessados através do Modelo de Objetos
de Documento (DOM - Document Object Model). O W3C24 define o DOM como uma
plataforma – e linguagem – de interface neutra que permite programas e scripts a acessarem e
atualizarem dinamicamente o conteúdo, estrutura e estilo de documentos.
Desenvolvedores de conteúdo web precisam ter ciência de que tais objetos são, não
raro, acessados sem o uso de um dispositivo apontador (como o mouse). A alternativa de
navegação mais comum é o teclado. A recomendação 2.1 das WCAG 2.0 é clara: “fazer com
que toda a funcionalidade fique disponível a partir do teclado” (W3C, 2008).
Deficientes visuais que sofrem de cegueira navegam necessariamente pelo teclado.
Dispositivos apontadores, como o mouse, requerem coordenação na visão e nas mãos, que um
usuário cego não dispõe. Portanto, todo o conteúdo deve estar acessível pelo teclado.
24
Definição e outras informações sobre o DOM - http://www.w3.org/DOM/.
53
A navegação ocorre através das teclas TAB, setas para a direita e para a esquerda, de
cima para baixo, da esquerda para a direita, por padrão. Botões de seleção e outros itens
podem ser acionados pela barra de espaço. Links e a maior parte dos comportamentos e
eventos são disparados pela tecla ENTER.
Navegar item por item pode ser tedioso e confuso. Mesmo que o usuário faça uma
varredura na página, procurando apenas por cabeçalhos e links de seu interesse, torna-se
indesejável ter que ouvir novamente o menu de navegação, por exemplo. Outro exemplo
enfadonho é ter que teclar TAB ao menos dez vezes para se chegar ao conteúdo principal da
página visitada. A recomendação 2.4.1 das WCAG 2.0 trata deste tema.
Prover teclas de atalho para os principais links do documento constitui o ponto 9.5 das
WCAG 1.0. Seções importantes da página podem receber atalhos, através do atributo
accesskey do HTML. Este atributo pode ser utilizado em conjunto com números ou letras, e
acionado por uma combinação de teclas, que variam de acordo com o navegador. Mesmo
navegadores gráficos similares, como Internet Explorer25 e Firefox26, ambos gráficos,
possuem teclas de atalhos distintas. Leitores de tela, como o Jaws27 e o Virtual Vision28,
também são dotados de atalhos.
Como muitos atalhos padrões definidos nos navegadores fazem o uso de letras, não é
sensato utilizá-las ao definir atalhos de navegação para sites. Por exemplo: um accesskey
definido como “f”, acessado pelo navegador Internet Explorer, irá substituir o atalho padrão
para o recurso de sites favoritos. Pode-se, contudo, utilizar os números.
Não é obrigatório definir, por exemplo, um atalho para cada item de menu. Este
procedimento exigirá uma carga muito alta de memória do usuário e, dificilmente, todos os
atalhos serão utilizados. As teclas de atalho poderiam, por exemplo, ser definidas para os
seguintes itens: página principal do site, primeiro item de menu principal, primeiro item de
menu secundário, caixa de busca e página sobre a acessibilidade do site. O accesskey deve ser
utilizado apenas em itens importantes para a navegação.
Outro modo de prover um caminho mais curto ao conteúdo desejado é através de
saltos. Os cinco itens cotados acima para receber o accesskey não englobam, entre outros
itens, o conteúdo principal, o início e o fim do documento. O usuário que navega pelo teclado
deve ter a chance de saltar diretamente para o conteúdo principal da página sem ter que ouvir
todos os itens do menu principal novamente. Toda região com muitas opções de navegação
25
Teclas de atalhos para Internet Explorer - http://www.acessibilidadelegal.com/33-teclas-ie.php.
Teclas de atalhos para Firefox - http://www.acessibilidadelegal.com/33-teclas-ff.php.
27
Teclas de atalhos para Jaws - http://www.acessibilidadelegal.com/13-atalhos.php.
28
Teclas de atalhos para Virtual Vision 2.01 - http://www.lupadigital.info/teclas-do-virtual-visiom-201.html.
26
54
deveria conter um salto para o próximo item. A aplicação de saltos será descrita no item 3.2.6
Textos e links.
A seqüência lógica de tabulação, recomendação 9.4 presente nas WCAG 1.0, é outro
fator decisivo para a navegação. As WCAG 2.0, item 2.4.3 também abordam a seqüência de
navegação. É possível definir a ordem de navegação dos elementos de uma página, através do
atributo tabindex, do HTML. O atributo pode ser adicionado a links, objetos (tag object) e a
alguns elementos de formulários.
Existe certa liberdade para a definição dos números que preenchem o tabindex.
Qualquer número pode ser escolhido, entre “0” e “32767” – mas não números negativos. Não
há a necessidade de uma ordem consecutiva, como um, dois e três. O importante é garantir
que o próximo número na ordem de tabulação seja maior que o atual. O incremento pode
ocorrer, por exemplo, de cem em cem: 100, 200, 300, etc.
<a href="acessibilidade.html" tabindex="3" title="Página
sobre acessibilidade do site - Tecla de atalho (2)."
accesskey="2">Acessibilidade</a>
Figura 4.9 - Exemplo de accesskey e tabindex.
4.2.6 Textos e links
O texto compreende um dos formatos mais acessíveis de conteúdo. Entretanto, alguns
cuidados razoáveis devem ser tomados, como instrui Clark (2002e).
A recomendação 3.1, das WCAG 2.0, afirma que o conteúdo de texto precisa ser
legível e compreensível, e cuida para que haja mecanismos que possibilitem o entendimento
de palavras incomuns (como expressões idiomáticas, jargões), definições e abreviaturas.
No HTML, abreviações podem ser indicadas pelas tags ABBR, acrônimos por
ACRONYM, definições por DFN, CITE é usado para citações e CODE para indicar a
presença de códigos descritos no texto.
Abreviações, de modo geral, são indicadas visualmente por um ponto, da mesma
forma que acrônimos por letras maiúsculas. Contudo, para leitores de tela, um ponto indica o
fim de um período, e letras maiúsculas são utilizadas para diversos fins. Por isto a importância
de se indicar tais expressões utilizando estruturas pré-definidas da linguagem de marcação. O
significado completo é atribuído ao title e, se houver mudança de linguagem, esta deve ser
55
indicada pelo atributo lang. Os elementos podem, ainda, ter o visual controlado por folhas de
estilo.
HTML:
<acronym lang="en" xml:lang="en" title="World Wide
Web">WWW</acronym>
<abbr title="Etcetera">Etc.</abbr>
CSS:
abbr, acronym { font-size: smaller; letter-spacing: .1em;
text-transform: uppercase; text-decoration: underline }
Figura 4.10 - Uso de acrônimos e abreviações, atrelados a folhas de estilo.
Para citações, os elementos apropriados são Q, para citações curtas, dentro do mesmo
bloco de texto, e BLOCKQUOTE para citações maiores, que exigem um bloco de texto único
para si. Ambos os elementos são acompanhados do atributo cite, que indica a fonte da
informação (online ou impressa).
Tim Berners-Lee afirma que <q cite="
http://www.w3.org/People/Berners-Lee/">a Web é
universal</q>
Figura 4.11 - Exemplo de citação indireta em texto.
Uma definição (de elemento DFN), por sua vez, é atrelada a um id. No texto, onde o
termo é citado, pode ser inserido um salto para a definição. O uso de saltos será abordado
posteriormente, nesta mesma seção.
No texto:
A <dfn id="def-internet">Internet</dfn> representa...
Texto com salto:
A <a href="#def-internet" title="Definição de Internet">
Internet</dfn> representa...
Figura 4.12 - Exemplos de definição no texto.
56
A explicação dos termos se dá através de uma lista de definição (DL - definition list,
do HTML). Sua estrutura é composta por termos (elemento DT – definition term) e descrições
(elemento DD – definition description).
<dl>
<dt>Internet</dt>
<dd> A <em>Internet</em> é um conglomerado de redes em
escala mundial...</dd>
<dt> World Wide Web</dt>
<dd>A <em>World Wide Web</em> é o serviço mais utilizado e
popular na Internet</dd>
</dl>
Figura 4.13 - Exemplo de uma lista de definições.
A lista completa de elementos que auxiliam a compreensão de conteúdo de texto, na
versão XHTML, pode ser encontrada no site do W3C29.
Mesmo a codificação de caracteres (character encodings ou charset) é essencial para a
acessibilidade. Um charset representa o conjunto de caracteres utilizados em uma página, e
permite uma codificação correta, incluindo caracteres especiais e acentos. As codificações
mais utilizadas atualmente na web são ISO-8859-1 e UTF-830.
<meta http-equiv="content-type" content="text/html;
charset=iso-8859-1" />
Figura 4.14 - Definição do conjunto de caracteres utilizado em uma página.
Após a definição do charset, deve-se assegurar que marcas e caracteres especiais de
texto sejam corretamente codificados, como, por exemplo, utilizar o código &ldquo; para
representar as aspas duplas (“) que iniciam uma citação.
Assim como as citações em um texto fazem referência a outros documentos, a web é
composta por um sistema de documentos hipertexto conectados entre si através de ligações
denominadas hiperlinks, ou simplesmente links.
As recomendações WCAG 2.0 (pontos 2.4.4 e 2.4.9) mencionam que os links devem
revelar sua finalidade a partir de seu próprio texto ou a partir do contexto que os cercam. O
atributo title, do HTML provê informação sobre o próprio link, e descreve sua finalidade.
29
Elementos de texto que auxiliam a acessibilidade - http://www.w3.org/TR/xhtml2/mod-text.html.
O W3C fornece detalhes sobre charsets - http://www.w3.org/TR/html401/charset.html. Tradução disponível
em: http://desenaviegas.com/charset.html.
30
57
<a href="acessibilidade.html" title="Página sobre
acessibilidade do site">Acessibilidade</a>
Figura 4.15 - Meta dados para links através do atributo title.
Para prover acessibilidade através do contexto, Gameleira (2002c) demonstra algumas
soluções possíveis.
Hiperlinks com texto genérico, sem contexto, precisam ser evitados. Expressões
corriqueiras como “saiba mais” e “clique aqui”, se não forem acompanhadas de uma
descrição adequada, não permitirão a compreensão do contexto para usuários de leitores de
tela. Uma solução prática seria dotar o atributo title de mais informações. Enquanto o texto do
link traz a informação “saiba mais”, a descrição poderia conter “saiba mais sobre a
acessibilidade na web”.
Outra abordagem é estender o link ao título ou ao parágrafo, ou seja, envolver estes
elementos com o link. Desta forma, o agente do usuário fará a leitura de todo o bloco de
informação.
<a href="acessibilidade.html">
<h1>o que é acessibilidade na internet?</h1></a>
Figura 4.16 - Exemplo de link estendido ao contexto.
Em concordância com Clark (2002e) deve-se evitar, também, que os links estejam
lado a lado, sem ao menos um caractere separador (uma barra vertical, por exemplo). Alguns
leitores de tela antigos fariam uma leitura consecutiva, e o usuário compreenderia tudo como
um link apenas. A utilização consecutiva de links, sem um elemento separador, causa
confusão até para usuários com perfeita visão, pois a distinção entre os links existentes se
torna difícil.
A navegação feita por hiperlinks pode ser interna – dentro do mesmo site – ou externa,
para outro site (outro banco de dados, segundo o W3C31). Há ainda a navegação por links para
dentro da própria página.
Quando um link permite um salto para um elemento específico (um id na mesma
página, por exemplo) recebe o nome de âncora. Estas âncoras permitem ao usuário, por
exemplo, saltar diretamente para o conteúdo da página e evitar a leitura repetitiva do menu de
navegação. A composição de um link âncora se faz em duas etapas: o objeto de destino recebe
31
Lista de definição de termos do W3C - http://www.w3.org/Terms.html.
58
um id, e o valor deste id é referenciado no link, precedido pelo sinal pré-definido “#”. Outros
exemplos de aplicações para links do tipo âncora seriam: link para o topo do site, links para
definições, links para determinadas áreas de outra página, construção de sumários com
hiperlinks que dão acesso diretamente ao conteúdo referido em cada item.
Link:
<a href="#conteudo" title="Saltar para o conteúdo">Saltar
para o conteúdo</a>
Objeto de destino:
<div id="conteudo">Conteúdo principal da página...</div>
Figura 4.17 - Links do tipo âncora.
Em links externos, o usuário pode ser avisado que está prestes a entrar em um novo
site. O atributo title pode trazer a informação adicional “site externo” e uma imagem padrão
(um quadrado ou janela com uma seta) pode ser utilizada, através do CSS, para indicar
visualmente ao usuário sobre a mudança. Conforme explanado anteriormente (item 3.2.2), o
link deve abrir na mesma janela.
Figura 4.18 - Exemplo de link externo indicado visualmente.
Sobre usuários impossibilitados de utilizar um dispositivo apontador, Clark (2002c)
alerta a respeito de um cuidado a ser tomado: definir, no CSS, o comportamento de links ao
receberem o foco. Se apenas o efeito hover (acionado quando o usuário repousa o dispositivo
apontador sobre o link) for definido, usuários que navegam pelo teclado não serão capazes de
visualizar este efeito.
a:focus { color: #990000; background-color: white; border:
solid 1px gray; }
Figura 4.19 - Definição do comportamento do link, através de CSS, ao receber o foco.
59
4.2.7 Descrição de imagens
Desenvolvedores web carregam consigo o dever de preparar suas páginas para
diferentes tipos de usuários que enfrentam diferentes situações. Desde a primeira
recomendação das WCAG 1.0, os esforços do grupo de trabalho do W3C estão voltados
àquela que pode ser considerada uma das maiores barreiras a acessibilidade web: imagens sem
alternativas equivalentes.
Os cenários nos quais um usuário pode não ter acesso às imagens são diversos. As
WCAG 1.0 exemplificam: alguns usuários podem não ser capazes de visualizar imagens,
outros podem usar navegadores baseados em texto sem suporte a imagens, enquanto outros
podem simplesmente desativar o suporte a imagens de seu navegador gráfico (devido a uma
conexão lenta com a Internet).
Figura 4.20 - Exemplo de imagens sem acessibilidade.
O gráfico 4.20, um navegador com imagens desabilitadas, demonstra três situações
possíveis para a descrição de imagens: Imagens com descrição textual adequada, imagens
com descrição textual inadequada e imagens sem descrição textual.
60
As imagens com descrição textual adequada, no exemplo anterior, são as imagens de
produtos, ao centro. Mesmo sem as imagens, é possível saber que se trata de um produto – e
qual produto, pois a descrição textual alternativa traz esta informação.
De outro modo, as três imagens à esquerda, cujos equivalentes textuais são “imagem
produto”, apresentam uma informação irrelevante ao usuário. Assim também ocorre com as
imagens, ao centro, de equivalente textual “imagem”, uma informação sem sentido. Um
usuário utilizando-se de um navegador textual jamais saberia que se trata de um botão
indicando “frete grátis”. Há, ainda, imagens sem qualquer descrição textual, completamente
inacessíveis para deficientes sem visão.
O atributo HTML utilizado em imagens para fornecer equivalente textual é o alt.
<img src="images/logoacesso.jpg" alt="Símbolo de acesso à
Web" longdesc="longdesc/logoacesso.html" />
Figura 4.21 - Exemplo do código de uma imagem acessível.
Na figura 4.21 é apresentado um exemplo para o código de uma imagem acessível.
Além do atributo alt, que descreve a imagem, pode ser acrescentado o atributo longdesc, cujo
endereço nele contido levará o usuário a uma página que descreve com riqueza de detalhes a
imagem referida.
A descrição textual alternativa a uma imagem deve ser relevante. Descrições úteis são
aquelas que verbalizam o significado ou papel da imagem no diálogo, e devem responder a
seguinte questão: “O que a imagem pretende comunicar e o que acontecerá se for clicada?”
(NIELSEN, 2000c, p. 305). Por exemplo, a logomarca da empresa no site pode conter a
seguinte descrição: “Empresa ABC”, ou “Logo Empresa ABC”. Caso a logomarca seja
também um link para a página inicial, é possível acrescentar o destino na descrição,
resultando em “Homepage da Empresa ABC”.
A descrição deve ser breve e direta, não mais que 8 a 10 palavras. Muitos navegadores
não realizam a quebra de linha automática de textos alternativos, e sua visualização poderia
estar comprometida caso apresentasse um número maior de palavras.
Embora o padrão predominante seja fornecer descrição textual a todas as imagens,
Nielsen (2002c) defende que as imagens que não apresentem significado, sendo apenas
decorativas, podem conter uma seqüência de caracteres vazia (espaços em “branco”). O
atributo alt seria preenchido desta maneira: alt=“ ”. A seqüência de caracteres vazia como
descrição textual indica ao software leitor de tela que pule a imagem, e faz mais sentido ao
61
usuário que uma descrição, por exemplo, contendo o texto “Grande bola azul” para indicar
um demarcador de uma lista. Se nenhuma descrição fosse fornecida, o usuário saberia que há
uma imagem, mas não seria possível determinar sua relevância para o contexto. A alternativa
que também aborda imagens decorativas diz respeito ao atributo background-image (imagem
de plano de fundo), que pode ser aplicado aos elementos da página através do CSS, sem que
seja lida por navegadores textuais.
Para as chamadas imagens descritivas, cujo equivalente textual busca verbalizar a
forma como um usuário com visão as perceberia, Gameleira (2002d) afirma que pode ser
utilizado o recurso denominado d-link. Este constitui um link logo após a imagem, que levará
o usuário a uma página com descrição detalhada da imagem. O d-link poderá estar visível,
seguindo o padrão “[d]”, ou em uma imagem transparente, quadrada, com cerca de cinco
pixels de largura. Tão logo um usuário sem a visão navegue após a imagem, poderá desfrutar
de descrição textual rica, tal como “Um globo reluzente com um buraco de fechadura ao
centro, simbolizando o acesso a web”.
[d]
Figura 4.22 - Recurso d-link junto à imagem.
O HTML permite que imagens sejam mapeadas em diferentes regiões, e cada região
ativa, quando selecionada, pode conter um link ou promover outra forma de interação com o
usuário. Como ressalva Gameleira (2002d), para que um mapa de imagens seja concebido de
forma acessível, é preciso se certificar de que cada ação pertinente a uma região visual da
imagem possa ser acionada sem o uso de um dispositivo apontador, como o mouse.
Os mapas de imagens são definidos através do elemento MAP, do HTML. Cada área
mapeada deve conter um texto equivalente, fornecido pelos atributos title e alt. Os mapas de
imagens devem ser usados no lado cliente, e não no lado servidor, conforme o exemplo da
figura 4.23, pois “rótulos alternativos não funcionam com mapas de imagens no lado do
servidor” (KRUG, 2008, p. 179).
62
<img usemap="#mapadeimagem"
src="images/imagemapexemplo.jpg" alt="exemplo de IMAGE
MAP" />
<map id="mapadeimagem" name="mapadeimagem">
<area shape="rect" coords="4,8,144,36"
href="#acessibilidade" alt="Acessibilidade"
title="Acessibilidade">
<area shape="rect" coords="356,7,449,36"
href="#diretrizes" alt="Diretrizes " title="Diretrizes">
</map>
Figura 4.23 - Exemplo de um mapa de imagem acessível.
Alguns designers preferem imagens de texto ao invés de texto puro, na tentativa de
causar maior impacto visual. A recomendação 1.4.5 das WCAG 2.0 afirma: “Se as
tecnologias que estiverem sendo utilizadas puderem proporcionar a apresentação visual, é
utilizado texto para transmitir informações em vez de imagens de texto” (W3C, 2008). As
exceções para esta recomendação se aplicam em imagens que sejam personalizáveis pelo
usuário (tamanho da fonte, cor e plano de fundo) ou em imagens consideradas essenciais.
Logotipos são exemplos de imagens essenciais. Neste caso, deve ser fornecido texto
equivalente, com os atributos alt e title, conforme visto anteriormente.
4.2.8 Tabelas e frames
Em conformidade com as WCAG 1.0 (item cinco), tabelas devem ser utilizadas
apenas para marcar informações tabulares genuínas (“tabelas de dados”), e não como recurso
de paginação (“tabelas de disposição”) – a menos que façam sentido quando lidas de modo
linearizado. A informação é considerada tabular quando a estrutura de linhas e colunas é
essencial para seu entendimento. E conteúdo linearizado (lido de forma linear) refere-se a
percorrer o conteúdo de células conjuntas sem respeitar a estrutura de linhas e colunas.
O problema, apontado por Gameleira (2002e), é que alguns softwares leitores de tela
não são capazes de interpretar adequadamente tabelas e frames (quadros), e processam
páginas web de modo horizontal, embaralhando textos, imagens e links. Segundo ele,
portanto, o posicionamento e estruturação das páginas devem ser efetuados através de folhas
63
de estilos (CSS). A alternativa a tabelas para marcação estrutural de páginas faz uso do
elemento DIV, que demarca blocos de conteúdo, e é controlado através do CSS.
Para Clark (2002f), existe um conceito mal compreendido de que tecnologias
adaptativas não podem ler e entender tabelas, e que o uso de tabelas é proibido pela Iniciativa
de Acessibilidade Web (W3C/WAI). Ele defende também que tabelas para layouts contenham
apenas os elementos TABLE, TR e TD, e explica que tabelas aninhadas (nested tables) –
técnica bastante utilizada em tabelas para layouts, onde uma tabela contém outra(s) tabela(s)
dentro de si – resultam em um processamento mais lento em browsers gráficos. A seguir é
feita uma comparação criando-se uma única célula com tabela, e a mesma célula com o
elemento DIV.
Estrutura básica da tabela:
Estrutura básica do DIV
<table>
<tr>
<td>Texto</td>
</tr>
</table>
<div>Texto</div>
Figura 4.24 - Comparação entre célula criada com tabela e com o elemento div.
Tabelas aninhadas, conclui Clark (op. cit.), também confundem usuários de leitores de
tela:
Você pode navegar para uma tabela ou dentro de uma tabela. E é ai que o
problema se inicia. Para tabelas simples de layout não aninhadas dentro de
outras tabelas, não há problemas em se mover de célula em célula. Com
tabelas aninhadas, contudo, um usuário de leitor de tela acaba dentro de um
labirinto formado por uma tabela dentro de outra.
As WGAG, de fato, não proíbem expressamente o uso de tabelas para layouts, mas
afirmam que é apropriado usar tabelas para exibir dados, e que usuários com leitores antigos
podem ter problemas ao processar o conteúdo. Se for utilizada uma tabela para efeitos de
disposição em página (o que é desaconselhado), não deve ser inserida qualquer marcação
estrutural para efeitos de formatação visual. Por exemplo, em HTML, o elemento TH não
deve ser usado para fazer com que o conteúdo de uma célula (que não seja de cabeçalho de
tabela) apareça centralizado e em negrito.
64
Sobre tabelas de dados, alguns cuidados devem ser tomados. Os primeiros elementos
de acessibilidade em uma tabela são legenda e sumário. A legenda é inserida através do
elemento CAPTION do HTML e posicionada logo após o elemento TABLE. O sumário, que
resume o propósito da tabela (conteúdo e/ou a estrutura), é um atributo que acompanha o
elemento TABLE, inserido através do metadado summary. A legenda é visível, porém o
sumário não é exibido na tela, por ser específico para agentes que processam conteúdo não
visual.
Dado o fato que tanto legenda quanto sumário comunicam uma informação resumida
de uma tabela que se segue, é comum encontrar apenas um dos elementos. A figura a 4.25
demonstra o uso de tais propriedades.
<table summary=”Descrição/Resumo da tabela...”>
<caption>Legenda da tabela...</caption>
<tr>
<td>Texto</td>
</tr>
</table>
Figura 4.25 - Exemplo das propriedades legenda e sumário em tabelas.
Toda tabela de dados precisa conter marcações indicando quais células são cabeçalhos
e quais células apresentam dados.
O primeiro nível de um cabeçalho pode ser estabelecido utilizando o elemento TH ao
invés de TD para uma ou mais células que contenham os cabeçalhos. Em um segundo nível, é
possível (e recomendável) delimitar a área de cabeçalho da tabela, através dos elementos
THEAD, rodapé, com o elemento TFOOT e também a área de conteúdo da tabela, com o
elemento TBODY. Células nas áreas de cabeçalho ou rodapé devem conter informações sobre
as colunas da tabela, ao passo que células na área do corpo ou conteúdo (TBODY), as
informações da tabela, conforme exemplificado pela figura 4.26.
65
<table border=”1” summary=”Estados brasileiros com maior
concentração de renda no Brasil em 2009”>
<caption>Concentração de renda no Brasil</caption>
<thead>
<tr>
<th>Estado</th>
<th>Concentração de renda (em %)</th>
</tr>
</thead>
<tbody>
<tr>
<td>São Paulo</td>
<td>40%</td>
</tr>
<tr>
<td>Rio de Janeiro</td>
<td>36%</td>
</tr>
</tbody>
</table>
Figura 4.26 - Exemplo de tabela com áreas de cabeçalho e conteúdo.
A tabela seria exibida em um navegador gráfico da seguinte forma:
Figura 4.27 - Exemplo de exibição de tabela em navegador gráfico.
Toda tabela de dados necessita conter marcações que associem explicitamente as
células de dados com as respectivas células de cabeçalhos, para que usuários de tecnologias
assistivas possam interpretar o conteúdo. Para isto, é imprescindível o uso do atributo “id”
nos cabeçalhos, e do atributo “headers” nas células de dados, apontando para o cabeçalho
adequado. O código da figura a 4.28 exemplifica esta técnica. A visualização em navegadores
gráficos seria a mesma apresentada na figura 4.27.
66
<table border=”1” summary="Estados brasileiros com maior
concentração de renda no Brasil em 2009">
<caption>Concentração de renda no Brasil</caption>
<thead>
<tr>
<th id="estado">Estado</th>
<th id="renda">Concentração de renda (em %)</th>
</tr>
</thead>
<tbody>
<tr>
<td headers="estado">São Paulo</td>
<td headers="renda">40%</td>
</tr>
<tr>
<td headers="estado">Rio de Janeiro</td>
<td headers="renda">36%</td>
</tr>
</tbody>
</table>
Figura 4.28 - Tabela com células de dados associadas aos cabeçalhos correspondentes.
Contudo, os navegadores textuais realizariam a leitura de modo que fizesse sentido
para o usuário. Seria lido no exemplo fornecido pelo gráfico 4.28 (após a legenda): “Estado:
São Paulo. Concentração de renda (em %): 40%. Estado: Rio de Janeiro. Concentração de
renda (em %): 36%”. Caso os cabeçalhos não fossem indicados, a leitura seria: “Estado.
Concentração de renda (em %). São Paulo. 40%. Rio de Janeiro. 36%”, tornando a
compreensão mais difícil, obrigando o usuário a se lembrar dos cabeçalhos a cada nova
célula.
É válido advertir que usuários de leitores de tela não conseguem interpretar facilmente
tabelas com cabeçalhos de linhas e colunas utilizados ao mesmo tempo. Contudo, é possível
criar tabelas de dados acessíveis com cabeçalhos de colunas e linhas. O atributo scope
(escopo) pode receber o valor “col”, indicando que célula é um cabeçalho de coluna, ou o
valor “row”, indicando que a célula é um cabeçalho de linha.
67
<table>
<caption>Legenda da tabela...</caption>
<tr>
<th scope="col">Estado</th>
<th scope="col">Homens 18–25</th>
<th scope="col">Mulheres 18–25</th>
</tr>
<tr>
<td scope="row">Rio de Janeiro</td>
<td>12,4%</td>
<td>14,4%</td>
</tr>
<tr>
<td scope="row">São Paulo</td>
<td>19,9%</td>
<td>17,0%</td>
</tr>
</table>
Figura 4.29 - Tabela com cabeçalhos de linhas e colunas.
Finalmente, conforme Gameleira (2002f), frames (quadros) devem ser evitados.
Páginas com estruturas de frames não são permitidas nas versões mais modernas da
linguagem HTML (ver item 3.2.1). A maior parte dos leitores de tela não são capazes de
identificar a existência de frames e, caso não haja indicação da sua existência, o usuário,
através da tecla TAB, navegaria em ciclos repetidos dentro do mesmo frame, ou alternaria o
foco para um frame incorreto. Caso o objetivo na utilização de frames seja uma suposta
facilidade de manutenção, é recomendado o uso da diretiva “include”, que permite incluir
uma página ou trecho de página HTML dentro de outra página HTML, o uso de modelos
(templates) disponíveis em ferramentas de autoria, ou o uso de sistemas gerenciadores de
conteúdo.
Caso a utilização de frames seja inevitável, sua existência deve ser informada
(inclusive na página sobre a acessibilidade do site), e uma versão alternativa sem frames do
conteúdo fornecida, através do elemento NOFRAME. Cada frame deve conter, em adição, um
título (atributo title) para fornecer um mínimo de informação sobre os quadros utilizados. Um
cuidado extra com a usabilidade do site deve ser adotado.
68
4.2.9 Formulários
Formulários constituem um meio de interação utilizado em larga escala na web.
Contudo, se alguns cuidados não forem tomados, usuários de leitores de tela terão
dificuldades de acesso. Muitos leitores não são capazes de ler o título de um campo de texto
editável e o usuário não consegue discernir qual informação deve fornecer naquele campo. Os
campos de um formulário (menus, botões de seleção, etc.) são denominados controles de
formulário.
Para tornar os campos de formulários acessíveis, de acordo com as WCAG 1.0, item
12.4, deve-se associar explicitamente os rótulos aos respectivos controles, utilizando o
elemento LABEL e o respectivo atributo for, do HTML. O controle do formulário a que o
rótulo diz respeito deve conter o atributo id com o mesmo valor dado ao atributo for deste
rótulo.
<label for="nome">Seu nome<br />
<input id="nome" type="text" name="nome"
size="20"></label>
Figura 4.30 - Associação de um rótulo a um controle de formulário.
As recomendações WCAG 1.0, itens 9.4 e 9.5 indicam respectivamente que
formulários devem oferecer uma seqüência lógica de tabulação e atalhos por teclado. A
seqüência lógica de tabulação (ou seja, navegação através da tecla TAB) é definida pelo
atributo tabindex. Dentre as tags HTML que podem receber este atributo, estão: INPUT
(campo de texto), SELECT (menu de seleção), TEXTAREA (área de texto) E BUTTON
(botão). Já o atributo accesskey permite ao usuário acessar um controle de formulário, a
qualquer momento, através de uma combinação de teclas de atalho e independente de onde
estiver o foco do cursor na tela.
<label for="nome">Seu nome<br />
<input id="nome" type="text" name="nome" size="20"
tabindex="1" accesskey="n"></label>
Figura 4.31 - Seqüência lógica de tabulação e teclas de atalho em formulários.
69
Ademais, Clark (2002g) provê outras técnicas que, aplicadas a formulários, aumentam
a acessibilidade e auxiliam usuários a interagir. Tais técnicas fazem referência a: agrupamento
de conteúdo, botões com imagens, campos de texto pré-preenchidos e tratamento de erros.
Desenvolvedores de conteúdo devem agrupar informações onde for natural e
apropriado. Em formulários, informações afins – como logradouro, endereço, cidade, Estado,
país e código postal – podem ser agrupadas através do elemento FIELDSET. O grupo pode
receber um título, através do elemento legend (que corresponde ao caption, em tabelas).
<fieldset>
<legend>Selecione a faixa etária</legend>
<label for="jovem">
<input id="jovem" type="radio" name="faixa" value="jovem"
tabindex="0" accesskey="j">1. Jovem</label><br />
<label for="adulto">
<input id="adulto" type="radio" name="faixa"
value="adulto" tabindex="1" accesskey="a">2.
Adulto</label>
</fieldset>
Figura 4.32 - Agrupamento de informações em formulários.
No exemplo da figura 4.32, outro detalhe pode ser observado. Para os botões de
seleção (radio), um nível de precisão menor – com o ponteiro do mouse – pode ser exigido de
usuários iniciantes ou com baixa visão. Ao usar o elemento LABEL envolvendo o botão de
seleção, as opções podem ser acionadas passando-se o mouse sobre o texto correspondente, e
não apenas sobre o botão de seleção. Contudo, para que este recurso seja facilmente percebido
pelo usuário, o ponteiro do cursor deve ser alterado quando repousar sobre o texto, através do
CSS.
label { cursor:pointer; }
Figura 4.33 - Botões de seleção podem exigir menor precisão.
70
O uso do FIELDSET, por sua vez, gera automaticamente uma borda que envolve o
conteúdo dentro de si. Se preferir, o desenvolvedor pode desabilitar a borda, atribuindo o
valor none (nenhum) para o atributo border (borda), através do CSS.
fieldset { border: none }
Figura 4.34 - Grupo de controles sem exibição de borda, utilizando CSS.
É comum encontrar na web botões de formulários com visual personalizado,
geralmente pelo uso de imagens. Quando botões de imagens, ou botões gráficos forem
utilizados, além dos atributos value (valor), name (nome) e id (identificador), os atributos alt e
title devem ser fornecidos, para descrição e título, respectivamente. A sintaxe do botão será a
seguinte (exemplo utilizando botão de envio, ou submit):
<input type="image" src="images/botao_enviar.gif"
alt="Enviar" name="Enviar" id="Enviar" value=" Enviar"
title="Enviar informações" />
Figura 4.35 - Botões gráficos acessíveis.
O ponto de verificação 10.4 das WCAG 1.0 adverte sobre a necessidade de se incluir
caracteres predefinidos (place-holders characters) de preenchimento nas caixas de edição e
nas áreas de texto, até que os agentes do usuário (navegadores, por exemplo) tratem
corretamente os controles vazios. O problema em questão resume-se ao fato de que alguns
navegadores antigos não manipulam adequadamente campos vazios, como TEXTAREA e
INPUT, ambos para texto. Campos pré-preenchidos, contudo, podem ser inoportunos ou
causar confusão durante o preenchimento pelo usuário. Para evitar tal situação, é aconselhado
o uso simplório de um script (linguagem de script ou extensão) “para apagar o valor do
atributo value quando este for focado pelo mouse ou pelo teclado e o faz reaparecer quando o
foco sair do campo sem ter sido preenchido” (PORTA; QUEIROZ, 2008).
71
<label for="busca">Pesquisar no site.
<input type="text" name="busca" id="busca"
title="Digite a palavra desejada (Tecla de atalho 0)"
accesskey="0" size="30" maxlenght="40" value="*"
onfocus="if (this.value == '*') {this.value='';}"
onblur="if (this.value == '') {this.value='*';}" />
</label>
Figura 4.36 - Script para evitar erro por campos vazios em navegadores antigos.
O script citado e exemplificado na figura 4.36 faz uso de dois manipuladores de
eventos (handler operators) para garantir que o campo esteja vazio ao receber o foco: onfocus
(em foco) – que apaga o asterisco do campo quando este receber o foco pelo mouse ou
teclado; e onblur (ao desfocar) – que preenche o campo com um asterisco quando o foco lhe é
retirado, e se não estiver preenchido. O uso de scripts, de eventos e seus correspondentes são
abordados no item 3.2.10 – Scripts, applets e plug-ins.
Caso seja necessário alertar usuários sobre um erro, utilizar métodos redundantes é
imprescindível. Ao reapresentar a página indicando os erros (campos preenchidos
incorretamente, ou campos obrigatórios para os quais não foram fornecidos os dados
solicitados), é contra-recomendado simplesmente marcar os campos com erro em vermelho. O
item 3.2.4 explica detalhadamente as razões deste método ser inacessível para usuários com
deficiências visuais relacionadas a cores ou com leitores de tela.
Ao apresentar um erro, deve-se aconselhar em conjunto as ações prováveis para a
correção de tais erros.
Por fim, é válido lembrar que formulários eficazes em acessibilidade não são
arranjados na página com tabelas (table hack). A leitura linearizada de células é mais lenta e
pode confundir ou impedir o acesso a diversos elementos do formulário para certos grupos de
usuários deficientes.
4.2.10 Scripts, applets e plug-ins
Navegadores web processam e exibem facilmente HTML. Contudo, para adicionar
novas funcionalidades aos sites ou apresentar conteúdo especial de mídia rica, muitos
desenvolvedores recorrem a programas adicionais, geralmente de formato proprietário, que,
para serem processados, necessitam de scripts (linguagens extensão), applets (programas
pequenos) e plug-ins ou add-ons (pacotes de expansão).
72
A recomendação 6.3 das WCAG 1.0 ratifica a necessidade de scripts, applets e plugins promoverem a acessibilidade:
Assegurar que todas as páginas possam ser utilizadas mesmo que os
programas interpretáveis, os applets ou outros objetos programados tenham
sido desativados ou não sejam suportados. Se isso não for possível, fornecer
informações equivalentes em uma página alternativa, acessível (W3C, 1999).
O site Acessibilidade Legal32 fornece um exemplo do uso de uma linguagem script em
conjunto com a alternativa noscript. O script, evocado através do arquivo “auxiliar.js”,
desenha da tela as opções para se alternar o tamanho das fontes e o contraste do site. Caso o
navegador não ofereça suporte à linguagem Javascript, será exibido o conteúdo situado entre
as tags noscript.
<script type="text/javascript" src="auxiliar.js"></script>
<noscript>
<ul id="acessibilidade">
<li><a href="#conteudo" title="Ir direto ao
assunto.">Saltar para conteúdo</a></li>
<li><a href="00-acessibilidade.php" title="Conheça os
recursos para acessibilidade deste site.">Acessibilidade
deste site</a></li>
</ul>
</noscript>
Figura 4.37 - Exemplo de uso da tag noscript.
As tags noscript, que devem ser aplicadas em conjunto com um script, são essenciais
para que se garanta a exibição do conteúdo alternativo, mesmo que o agente do usuário não
suporte a linguagem script utilizada.
Em adição, ao serem programados, scripts, applets e plug-ins devem estar em
conformidade com as diretrizes de acessibilidade, seja pela navegação, exibição de conteúdo
ou resposta a eventos. Gameleira (2002g) ensina que, na linguagem interpretada Javascript,
por exemplo, deve-se acrescentar tratamentos redundantes nos eventos do mouse,
beneficiando usuários que navegam pelo teclado. Os eventos que respondem a um dispositivo
apontador podem ser utilizados em conjunto com seus correspondentes para o teclado:

Eventos: onmousedown (ao pressionar o mouse) e onkeydown (ao pressionar o
uma tecla);
32
Acessibilidade Legal - http://www.acessibilidadelegal.com/.
73

Eventos: onmouseup (ao liberar o botão do mouse) e onkeyup (ao liberar uma
tecla);

Eventos: onclick (ocorre após um clique no mouse) e onkeypress (após uma
tecla receber um ciclo completo de toque: após ser pressionada e solta);

Eventos: onmouseover (ao repousar o ponteiro do mouse sobre o objeto) e
onfocus (no momento em que um elemento recebe o foco);

Eventos: onmouseout (ao retirar o ponteiro do mouse de cima do objeto) e
onblur (no momento em que um elemento perde o foco).
Sempre que aplicável, scripts, applets e plug-ins devem estar acompanhados de
atributos descritivos, como title e alt.
4.2.11 Animações - tecnologia flash
Animações constituem uma fonte rica de experiência visual para usuários da web.
Entretanto, uma maioria desmedida de animações encontradas por toda a rede é inacessível.
O software mais popular utilizado na criação de animações e mídia rica para web é o
Flash, da empresa Adobe. Sua plataforma permite o desenvolvimento de animações e
aplicativos com acessibilidade. Para isto, contudo, requer alguns cuidados geralmente
negligenciados por desenvolvedores.
Sempre que uma animação do tipo Flash (ou similar) for utilizada, descrição e
conteúdo alternativos devem ser fornecidos. Gameleira (2002h) evidencia detalhes que devem
ser observados. O primeiro é o software utilizado, que só passou a oferecer recursos de
acessibilidade a partir da versão MX, atendendo aos requisitos mínimos da Seção 508 e da
MSAA (Microsoft Active Accessibility), tecnologia utilizada por alguns leitores de tela. Ao
oferecer tais recursos, o Flash passou a permitir que leitores tenham acesso ao conteúdo de
seus objetos (textos, botões, campos), e que sejam atribuídos foco textos alternativos a estes
objetos. A navegação pelo teclado também passou a ser possível. Porém, para que estas
funcionalidades estejam disponíveis ao usuário, é necessário que este tenha instalado em sua
máquina o Flash Player, que interpreta e executa as animações, na versão seis ou posterior.
74
Figura 4.38 - Iniciativa de acessibilidade em ferramentas de autoria, como Adobe Flash.
A iniciativa de acessibilidade para esta plataforma vem aumentando, contrariando a
opinião generalizada de que Flash não é acessível. Juntamente com a versão mais recente do
software, Adobe Flash CS4 Professional, foram lançadas diretrizes no próprio site da
empresa33, sobre como criar conteúdo rico acessível. De modo geral, algumas regras devem
ser seguidas para assegurar que a animação esteja realmente acessível: Tornar a própria
animação acessível, de forma nativa (navegação pelo teclado, objetos acessíveis e com
descrição); prover sons e leitura do conteúdo, independente de leitores de tela; e, novamente,
fornecer conteúdo alternativo (CREATING, 2009).
É de suma importância que projetistas desenvolvedores recorram a ferramentas de
autoria que fomentem a acessibilidade, pois elas tornam natural a utilização de técnicas que
obedecem as diretrizes de acessibilidade para conteúdo web. O W3C também formalizou
diretrizes de acessibilidade para ferramentas de autoria - Authoring Tool Accessibility
Guidelines (ATAG)34.
4.2.12 Multimídia
A recomendação 1.1 das WCAG 2.0 diz que todo conteúdo não-textual deve
apresentar um equivalente textual. Para as chamadas mídias com base no tempo, a alternativa
em texto precisa fornecer, no mínimo, uma identificação descritiva do conteúdo não textual.
A forma mais ocorrente de mídias com base no tempo, também denominadas como conteúdo
multimídia, é o vídeo. Compreender a barreira para a acessibilidade é fácil: deficientes visuais
que apresentam cegueira não conseguem ver vídeos.
33
34
Iniciativa de acessibilidade no Adobe Flash - http://www.adobe.com/accessibility/products/flash/tutorial/.
Diretrizes W3C para ferramentas de autoria - http://www.w3.org/WAI/intro/atag.php.
75
A recomendação 1.2 das WCAG 2.0 trata com mais clareza das mídias baseadas em
tempo, e determina que, como principais técnicas para vídeo, sejam fornecidas uma faixa de
áudio e audiodescrição (verbalização do conteúdo visual), ou uma mídia alternativa, com
mesmo conteúdo (exceto quando o conteúdo de vídeo já representar uma alternativa ao
conteúdo de texto).
As WCAG 2.0 definem a audiodescrição como uma “narração adicionada à trilha
sonora que descrever detalhes visuais importantes que não podem ser compreendidos a partir
apenas da trilha sonora principal”. Estes detalhes podem ser “sobre ações, personagens,
mudanças de cenário, textos na tela e outro conteúdo visual” (W3C, 2008). Caso o áudio já
revele, por si só, informações sobre o vídeo, a audiodescrição não é requerida.
Para permitir o controle sobre o tempo da mídia, e outros itens de acessibilidade, devese utilizar todos os recursos de acessibilidade disponíveis em ferramentas de autoria, como
Flash, descrita no item 3.2.11. A plataforma Flash também é amplamente utilizado para
exibir vídeos na web.
O site Blindtube35 é um excelente projeto que exemplifica como vídeos online podem
ser acessíveis a deficientes. O projeto se autodenomina o primeiro portal de entretenimento
com acessibilidade, pioneiro no mundo. Similar ao site YouTube, apresenta vídeos adaptados
para surdos e cegos, com legendas e audiodescrição.
35
BlindTube: portal de entretenimento com acessibilidade - http://www.blindtube.com.br/.
76
CAPÍTULO 5
AVALIAÇÃO DA ACESSIBILIDADE
Existem diversos métodos para se avaliar a acessibilidade de um sistema web. A
avaliação é de suma importância, pois a aplicação da acessibilidade ao se desenvolver
projetos web é suscetível a erros (SOARES, 2005). Com testes precoces é possível reduzir a
possibilidade de erros. O W3C, no anexo A das WCAG 1.0, define de que forma os testes
devem ser realizados:
A validação da acessibilidade deve ser feita por meio de ferramentas
automáticas e da revisão direta. Os métodos automáticos são geralmente
rápidos, mas não são capazes de identificar todas as nuances da
acessibilidade. A avaliação humana pode ajudar a garantir a clareza da
linguagem e a facilidade da navegação (W3C, 1999).
As ferramentas automáticas ou semi-automáticas são softwares ou serviços online, e a
avaliação humana é feita de forma manual por especialistas ou usuários.
5.1 Métodos de avaliação
O próprio W3C fornece métodos de avaliação, presente nas Recomendações para
acessibilidade de conteúdo web 1.0, direcionando profissionais a realizarem uma avaliação
abrangente e eficaz das páginas. Os métodos são:
1. Utilizar uma ferramenta de acessibilidade automatizada e uma para validação de
navegadores.
2. Validar a sintaxe do documento, como HTML e XML.
3. Validar as folhas de estilo, como CSS.
4. Testar o documento utilizando um navegador exclusivamente textual ou um emulador.
5. Fazer uso de vários navegadores gráficos, contemplando os seguintes cenários:
o
Som e gráficos ativos;
o
Gráficos desabilitados;
o
Som desabilitado;
o
Sem mouse;
o
Sem carregar frames, programas interpretáveis, folhas de estilo ou applets.
6. Realizar testes em múltiplos navegadores, tanto antigos quanto recentes.
7. Realizar testes utilizando um navegador de emissão automática de fala, um leitor de
tela, software de ampliação, uma tela de pequenas dimensões.
77
8. Utilizar corretores ortográficos e gramaticais para que se aumente o grau de
compreensão de usuários com a necessidade de sintetizadores de voz.
9. Revisar o documento, assegurando que seja claro e simples. A revisão poderá ser feita
através de software específico ou, melhor, por um revisor experiente.
10. Verificar o seu grau de acessibilidade e facilidade de utilização através de testes ou
revisões feitos por pessoas com deficiências, com ou sem experiência (W3C, 1999).
5.1.1 Validação automática
As ferramentas automáticas para validação, gratuitas em sua maioria, analisam o
código das páginas em busca de erros na sintaxe da linguagem utilizada e verificam se alguns
mecanismos de acessibilidade estão presentes. Ao final de uma validação, um relatório é
apresentado, mostrando os erros e sugerindo melhorias, ou um selo de conformidade é
disponibilizado para o documento. Um validador automático é capaz, por exemplo, de
verificar a de presença descrições alternativas equivalentes para imagens, ao encontrar o
atributo alt preenchido.
Apesar disso, é necessário ressaltar que tais ferramentas não abrangem todas as
questões da acessibilidade, sendo incapazes de avaliar a clareza e simplicidade de textos, ou,
ainda, se a descrição textual equivalente fornecida a uma imagem faz sentido para o usuário.
Alguns exemplos de ferramentas automáticas de validação são:
 Validadores W3C - http://validator.w3.org/ e http://jigsaw.w3.org/cssvalidator/, para avaliação do HTML (e outras linguagens de marcação como
XML) e CSS, respectivamente. Não avaliam a acessibilidade, mas sim o
código. “Entretanto, vale lembrar que a validação de código é importante [...],
pois as tecnologias assistivas se baseiam em codificação válida para interpretar
e traduzir corretamente páginas web” (DIAS, 2007, p. 152).
 Hera - http://www.sidar.org/hera/index.php.pt, ferramenta de avaliação
portuguesa que verifica as WCAG 1.0.
 Cynthia Says - http://www.cynthiasays.com/, realiza validação baseando-se
nos padrões da Seção 508 ou WCAG 1.0, e ainda é capaz de emular o uso de
vários navegadores.
 WAVE - http://wave.webaim.org/, fornece um relatório com ícones indicando
erros ou melhorias, entre muitas outras funcionalidades, como ver apenas o
78
texto ou a estrutura da página. Permite interação com outros sites e
ferramentas, e até disponibiliza plug-ins para navegadores, como o Firefox.
 DaSilva - http://www.dasilva.org.br/, valida páginas de acordo com as
diretrizes WCAG 1.0 ou as diretrizes do governo brasileiro, E-GOV. É
também o primeiro validador brasileiro e em português. Mantém no site uma
lista de sites acessíveis e disponibiliza um software para validação off-line com
diversas funcionalidades , compatível com o sistema operacional Windows.
 Juicy Studio - http://juicystudio.com/services/translations/colourcontrast-ptbr.php, avalia o contraste entre duas cores fornecidas, retornando um relatório
simples que diz se a diferença de brilho e a diferença entre as duas cores é
suficiente.
 Vischeck - http://www.vischeck.com/vischeck/vischeckURL.php, permite
simular como seria a visão de um usuário com daltonismo (deficiências visuais
protanopia, deuteranopia e tritanopia, abordadas no item 3.2.4).
O W3C/WAI mantém uma extensa lista36 de ferramentas avaliação, concerto e
transformação (softwares e serviços online) que ajudam a determinar se um site apresenta
conformidade com as diretrizes de acessibilidade. As verificações que estas ferramentas
realizam abrangem desde o código até o contraste de cores. As revisões ortográficas e
gramaticais também podem ser efetuadas de forma automática.
5.1.2 Avaliação humana
A avaliação humana dos requisitos de acessibilidade em páginas web é imprescindível
para abranger pontos os quais a validação automática não é capaz de suprir. Assegurar que o
documento seja claro e simples, por exemplo, é uma tarefa realizada preferencialmente por
pessoas experientes, ao invés de algum programa de computador.
Especialistas, ou seja, profissionais da web, precisam checar manualmente os pontos
de verificação, critérios de sucesso e técnicas apresentados pelas recomendações de
acessibilidade (WCAG) 1.0 e 2.0. Os avaliadores podem determinar quais níveis de
conformidade desejam atingir (A, AA ou AAA), e em sites de grande porte podem, na
concepção de Dias (2007, p. 156), “escolher, além da homepage, amostras representativas de
36
Ferramentas de avaliação - http://www.w3.org/WAI/ER/tools/.
79
páginas web do portal, relacionadas com as tarefas típicas realizadas com ele (identificadas na
análise de seu contexto de uso)”.
Diferentes navegadores (antigos e recentes) devem ser testados, de fabricantes
distintos. Internet Explorer (da Microsoft), Mozilla Firefox (da Fundação Mozilla), Safari
(Apple) e Opera (Opera Software) são os navegadores gráficos mais populares. Outro
navegador popular atualmente é o Chrome (Google), contudo a funcionalidade que permite
teclas de atalhos em sites (atributo accesskey do HTML) está desabilitada neste navegador.
Navegadores devem, em adição, ser testados em diferentes cenários. No escopo da
deficiência visual (cegueira, daltonismo e baixa visão), todos os cenários apontados no quinto
método do W3C são relevantes: navegação com som e gráficos ativos; com gráficos
desabilitados; som desabilitado; sem mouse; sem carregar frames, programas interpretáveis,
folhas de estilo ou applets.
Figura 5.1 - Exemplo de navegador gráfico com imagens desabilitadas.
Avaliações com ampliação de tela podem recorrer aos softwares fornecidos pelos
próprios fabricantes de sistemas operacionais, como o Magnifier, fornecido pela Microsoft.
Um exemplo de navegador com emissão automática de fala que pode ser utilizado em
avaliações é o Easy Web Browsing37, software proprietário fornecido pela IBM, atendendo
também ao sétimo método de avaliação do W3C. Suas funcionalidades vão além de apenas ler
textos: incluem o aumento de tela como um todo ou em porções específicas e a personalização
de cores de fundo e do texto. O navegador da IBM é destinado principalmente a usuários
idosos ou com alguma deficiência visual.
37
Download do Easy Web Browsing - http://www-03.ibm.com/able/dwnlds/index.html.
80
Para testes com navegadores textuais, desenvolvedores podem recorrer ao Lynx38, ou
um simulador online para o mesmo, Lynx Viewer39. Este simulador é destinado apenas a
desenvolvedores. Para testar um site com o Lynx Viewer, é preciso criar e publicar no mesmo
endereço eletrônico um arquivo HTML (com qualquer conteúdo) sob o nome “delorie.htm”.
Com esta política de segurança, o serviço online impede a ação de usuários mal
intencionados. O navegador textual ou seu simulador exibem apenas texto, ignorando
imagens, folhas de estilo e linguagens programadas.
Figura 5.2 - Exemplo de site testado com o simulador Lynx Viewer.
Outra categoria de navegadores são os leitores de tela. Alguns exemplos são: Jaws40,
Virtual Vision41 (em português) e Monitvox (utilitário do sistema DosVox42, gratuito e em
português). A avaliação em leitores de tela pode ser feita em conjunto com usuários
deficientes visuais. Existem diferentes métodos de avaliação de páginas por deficientes
38
O navegador textual Lynx está disponível em - http://lynx.browser.org/.
Simulador do navegador textual Lynx - http://www.delorie.com/web/lynxview.html.
40
Jaws - http://www.freedomscientific.com/fs_downloads/jaws.asp.
41
Virtual Vision - http://www.micropower.com.br/v3/pt/acessibilidade/index.asp.
42
DosVox - http://intervox.nce.ufrj.br/dosvox/.
39
81
visuais, que podem fornecer informações extremamente valiosas para desenvolvedores e
projetistas web.
5.1.3 Testes com usuários
O último método de avaliação da acessibilidade proposto pelo W3C é a revisão das
páginas por deficientes visuais, para que se verifique o grau de acessibilidade e facilidade de
utilização. A importância de testes com usuários é reforçada por Krug (2008, p. 133):
Se você quiser um ótimo site, tem que testar. Após ter trabalhado em um site
por até mesmo algumas semanas, você não consegue mais vê-lo como algo
novo. Você sabe demais. A única forma de descobrir se ele realmente
funciona é testando-o.
Testes com usuários devem incluir diferentes habilidades e deficiências, e podem ser
realizados no próprio ambiente em que estes usuários utilizam seus computadores ou em
laboratórios específicos para testes, que dispõem de câmeras, gravadores de áudio, espelhos
de face única e softwares de monitoramento. Os testes incluem orientações aos usuários, listas
de tarefas a realizar (por exemplo, acessar determinada página e comprar um produto) e
questionários de avaliação que podem ser respondidos pelos participantes (DIAS, 2007).
Seguramente os testes com usuários podem ser simples, não há razões para
superestimar estrutura ou investimentos. Se os testes forem realizados no início do
desenvolvimento, o número de usuários pode ser menor. Em sua coluna Alertbox sobre
usabilidade Nielsen fornece razões pelas quais a maioria dos testes só precisaria de no
máximo cinco usuários. Entre elas: com muitos usuários, se aprende menos. Os avaliadores
começam a ver erros repetidos. O recomendado é testar com poucos usuários, efetuar as
modificações necessárias e realizar novos testes (Nielsen, 2000).
5.2 Modelo proposto de site acessível
Com o objetivo de auxiliar a profissionais que geram conteúdo para a web, um modelo
de site acessível encontra-se disponível no endereço: www.acessibilidadeweb.com.br. O
modelo demonstra, de forma prática, várias técnicas para aplicar a acessibilidade abordadas
durante esta pesquisa. O modelo proposto consiste em um site acessível que pode, portanto,
ser acessado por deficientes visuais e visa despertar o interesse e facilitar o aprendizado de
projetistas e desenvolvedores web sobre a acessibilidade.
82
O modelo passou por todos os métodos de avaliação de acessibilidade recomendados
pelo W3C (especificados no item 5.1 Métodos de avaliação) e incluiu testes dos tipos
automático, manual e com usuários, descritos a seguir.
Figura 5.3 - Modelo proposto de site acessível – www.acessibilidadeweb.com.br.
5.2.1 Avaliação da acessibilidade no modelo proposto
Os testes para assegurar a acessibilidade do modelo proposto de site se iniciaram com
a validação da linguagem de marcação utilizada (XHTML 1.0 Transitional) e da folha de
estilos (CSS) pelos respectivos validadores do W3C. A gramática e a ortografia também
representaram itens passíveis de análise automática, enquanto a clareza e simplicidade foram
analisadas de forma manual.
A avaliação automática de acessibilidade ficou a cargo do serviço online DaSilva, que
garantiu o nível de conformidade mais alto para o modelo (“AAA”). Após a validação do
83
código e de serviços online que avaliam a acessibilidade, os pontos de referência das WCAG
foram verificados, manualmente, seguindo a recomendação do W3C.
O emulador escolhido para a navegação textual foi o Lynx Viewer. O conteúdo foi
apresentado com uma seqüência lógica e clara.
Vários navegadores gráficos serviram de base para os testes: Internet Explorer
(Versão 8), Mozilla Firefox (Versão 3), Safari (Versão 4) e Opera (Versão 9), abrangendo
todos os cenários distintos (apresentados no item 5.1 Métodos de avaliação).
O modelo proposto foi testado com navegadores ajustado aos padrões de fonte
(tipologia) nos tamanhos 10, 12, 14 e 18 pontos – apresentando excelente visibilidade sem
descaracterização do visual. Com o padrão de fonte ajustado para 24 pontos, entretanto, o
design apresentou ligeiro comprometimento na parte inferior, com a sobreposição parcial
(apenas visual) de dois links, o que não afetou a visualização de todo o conteúdo, tampouco a
navegação. É válido ressaltar que os links que se sobrepuseram eram repetições de outros
links já existentes na página. A visualização do modelo através do software ampliador de tela
Magnifier não acarretou em qualquer ônus ao layout e a navegabilidade do site.
Para simular a visão de usuários daltônicos, utilizou-se o simulador Vischeck, que
assegurou uma boa composição de cores e contraste para as seguintes categorias de
deficiências: Deuteranopia (não distinção entre vermelhos e verdes), cujo teste pode ser
conferido no endereço a seguir: http://vischeck.homeip.net/uploads/125961750128328/;
Protanopia
(novamente
a
não
distinção
entre
vermelhos
e
verdes)
-
http://vischeck.homeip.net/uploads/125961756328400/; Tritanopia (insensibilidade de cores
azuis) - http://vischeck.homeip.net/uploads/125961759028472/.
No anexo A são encontrados gráficos comprobatórios de vários testes citados, a fim de
auxiliar a compreensão do processo de avaliação da acessibilidade automática ou por
especialistas.
Os testes abrangeram, ainda, um usuário piloto, deficiente visual com cegueira, que
fez uso de leitores de telas e um navegador alternativo para deficientes visuais. Os leitores de
tela utilizados foram o Jaws e o Monitvox. Este último integra o pacote de softwares do
sistema operacional DosVox, do qual também foi utilizado o programa de navegação
WebVox (sem suporte total a Javascript). Os testes comprovaram um bom nível de acesso e
navegação do conteúdo. Adicionalmente, tarefas específicas de navegação foram realizadas,
como acessar e utilizar o formulário de contato, leitura de conteúdo e a utilização de saltos.
Durante o período de testes com o usuário piloto, algumas modificações foram
sugeridas:
84
 Inserção do título da página atual junto ao título do site (tag title do
documento). Exemplo: Acessibilidade Web – Página de Contato.
 Encurtamento dos títulos que descrevem as funções dos links que possuem
atalhos. Exemplo: de “Pular para o conteúdo – Atalho no 2” para “Conteúdo no 2”.
 Na página inicial, retirar o link dos ícones na área de conteúdo, pois
acarretavam em uma leitura duplicada, visto que os títulos dos quadros
apresentavam os mesmos links.
As necessidades de modificações percebidas através dos testes foram realizadas.
Novos testes deverão ocorrer abrangendo distintos navegadores e mais usurários.
85
CAPÍTULO 6
CONSIDERAÇÕES FINAIS
A web possibilita aos deficientes visuais a inclusão digital, social, o acesso a
informações e serviços que, por outros meios, talvez não sejam fáceis de realizar. Contudo, o
desfrute destes adventos tecnológicos tem esbarrado nas dificuldades de acesso a páginas com
estrutura e conteúdo inadequados, incompreensíveis para estes deficientes.
O estudo de tais barreiras mostrou-se essencial para que profissionais geradores de
conteúdo compreendam as diferentes deficiências visuais existentes, tecnologias de apoio que
oferecem assistência e de que forma o conteúdo deve ser apresentado.
Diretrizes para a acessibilidade na web foram apontadas, objetivando a orientação de
projetistas e desenvolvedores, a fim de que produzam páginas que permitam o acesso e
interação de pessoas desprovidas ou com capacidade limitada de visão. Estes profissionais
muitas vezes ignoram tais diretrizes baseando-se em mitos, desfeitos através desta pesquisa.
Os conceitos, métodos, técnicas e ferramentas demonstrados para o desenvolvimento e
avaliação de sites com acessibilidade comprovam que esta é uma realidade possível de ser
alcançada, sem demandar altos custos ou comprometer a viabilidade dos projetos. Em adição,
foi proposto um modelo de site acessível, que visa ser fonte de interação e pesquisa para
desenvolvedores, contribuindo, assim, para sua conscientização de que uma web acessível é
uma web melhor para todos.
6.1 Conclusão
O principal objetivo deste trabalho fundamentou-se no levantamento de técnicas para a
aplicação das diretrizes de acessibilidade para o conteúdo web. A pesquisa realizada e a
demonstração de tais técnicas são importantes por permitir que profissionais desenvolvam
páginas estruturalmente adequadas, com desempenho melhorado, maior abrangência de
público e, sobretudo, acessíveis aos deficientes visuais.
Além de firmar-se como um manual de desenvolvimento de sistemas web acessíveis,
este trabalho proporciona para a sociedade outras contribuições que se somam à sua
contribuição primária: a inclusão digital e a inclusão social de deficientes visuais.
A inclusão digital permite o acesso pleno e democrático à informação disponibilizada
através da Internet, resultando em maior independência para deficientes visuais.
Por
86
conseguinte, páginas acessíveis alavancam a inclusão social, disponibilizando meios para que
deficientes visuais se comuniquem e se relacionem ampla e eficazmente, obtenham estudo,
trabalho, lazer e melhoria na qualidade de vida.
A acessibilidade torna a web um amplo canal para transpor outras barreiras, ao invés
de apenas mais uma barreira a ser transposta. Um canal para o acesso pleno a informação e a
cidadania.
6.2 Trabalhos futuros
A pesquisa sobre a acessibilidade na web gerou a motivação necessária para a
continuidade dos estudos e a criação de um ambiente colaborativo que, com base no modelo
proposto de um site acessível, deverá transformar-se em fonte de participação, contribuição e
conhecimento para projetistas e desenvolvedores. Serão investigadas, por meio de
questionários, novas necessidades ou dificuldades destes profissionais, para que se identifique
pontos técnicos adicionais a serem explorados no site.
Novas tecnologias e novas versões das tecnologias já existentes surgem com
freqüência na Internet, requerendo a atualização de diretrizes e das técnicas que possibilitam a
acessibilidade. Revisões sistemáticas deverão ser realizadas para assegurar que o conteúdo
disponibilizado esteja sempre atualizado, ainda que se garanta o histórico de técnicas
depreciadas, para fins documentativos.
Mais estudos sobre diretrizes para a acessibilidade web devem ser realizados,
abrangendo as demais categorias de deficiências, como auditivas, motoras, cognitivas,
mentais, de linguagem ou múltiplas. Tais estudos ocasionarão a disponibilização de novas
técnicas no ambiente virtual outrora mencionado.
Deverão ser realizadas pesquisas e atividades de conscientização, como palestras e
seminários, junto a empresas e entidades de ensino relacionadas ao desenvolvimento de
conteúdo para a web, a fim de que as vantagens inerentes a acessibilidade sejam amplamente
difundidas e as técnicas para a aplicação da mesma sejam ensinadas.
87
ANEXO A – EXEMPLOS DE TESTES DE ACESSIBILIDADE
Figura A.1 – Validação automática de sintaxe (HTML).
Figura A.2 – Validação automática de folhas de estilo.
88
Figura A.3 – Avaliação automática de acessibilidade.
Figura A.4 – Teste com emulador de navegador textual - Lynx Viewer.
89
Figura A.5 – Teste com Javasript desabilitado.
Figura A.6 – Teste com página sem folhas de estilo vinculadas.
90
Figura A.7 - Teste com imagens desabilitadas.
Figura A.8 - Simulador Vischeck indicando a visualização de um deficiente com Deuteranopia.
91
Figura A.9 - Simulador Vischeck indicando a visualização de um deficiente com Protanopia.
Figura A.10 - Simulador Vischeck indicando a visualização de um deficiente com Tritanopia.
92
REFERÊNCIAS
508 Law, 1998. Disponível em:
<http://section508.gov/index.cfm?FuseAction=Content&ID=3>. Acesso em: 09 out. 2009.
ACCESSIBILITY. Disponível em: <http://australia.gov.au/about/accessibility>. Acesso em:
09 out. 2009.
ACESSIBILIDADE para todos: uma cartilha de orientação. Rio de Janeiro: Núcleo PróAcesso, UFRJ/FAU/PROARQ, 2004.
BRASIL. Lei nº 7.853, de 24 de outubro de 1989. Dispõe sobre o apoio às pessoas portadoras
de deficiência, sua integração social, sobre a Coordenadoria Nacional para Integração da
Pessoa Portadora de Deficiência - CORDE, institui a tutela jurisdicional de interesses
coletivos ou difusos dessas pessoas, disciplina a atuação do Ministério Público, define crimes,
e dá outras providências. Disponível em
<http://www.planalto.gov.br/ccivil/LEIS/L7853.htm>. Acesso em: 11 out. 2009.
_____. Lei nº 10.098, de 19 de dezembro de 2000. Estabelece normas gerais e critérios
básicos para a promoção da acessibilidade das pessoas portadoras de deficiência ou com
mobilidade reduzida, e dá outras providências. Disponível em
<http://www.planalto.gov.br/ccivil_03/Leis/L10098.htm>. Acesso em: 11 out. 2009.
_____. Lei nº 5.296, de 2 de dezembro de 2004. Regulamenta as Leis nos 10.048, de 8 de
novembro de 2000, que dá prioridade de atendimento às pessoas que especifica, e 10.098, de
19 de dezembro de 2000, que estabelece normas gerais e critérios básicos para a promoção da
acessibilidade das pessoas portadoras de deficiência ou com mobilidade reduzida, e dá outras
providências. Disponível em <http://www.planalto.gov.br/ccivil_03/_Ato20042006/2004/Decreto/D5296.htm>. Acesso em: 11 out. 2009.
BORGES, José Antonio. Projeto Dosvox. <Disponível em
http://intervox.nce.ufrj.br/dosvox/>. Acesso em: 27 nov. 2008.
93
CHAK, Andrew. Como criar sites persuasivos: clique aqui. Tradução: Katia Aparecida
Roque. São Paulo: Pearson Education do Brasil, 2004. 278 p.
CLARK, Joe. Building Accessible Websites – Navigation. 2006a. Disponível em:
<http://joeclark.org/book/sashay/serialization/Chapter08.html>. Acesso em: 08 out. 2009.
_____. Building accessible websites – why bother?. 2006b. Disponível em:
<http://joeclark.org/book/sashay/serialization/Chapter02.html>. Acesso em: 08 out. 2009.
_____. Building accessible websites – types and colour, 2006c. Disponível em:
<http://joeclark.org/book/sashay/serialization/Chapter09.html>. Acesso em: 08 out. 2009.
_____. Building accessible websites – stylesheets 2006d. Disponível em:
<http://joeclark.org/book/sashay/serialization/Chapter11.html>. Acesso em: 08 out. 2009.
_____. Building accessible websites – text and links, 2006e. Disponível em:
<http://joeclark.org/book/sashay/serialization/Chapter07.html>. Acesso em: 08 out. 2009.
_____. Building accessible websites – tables and frames, 2006f. Disponível em:
<http://joeclark.org/book/sashay/serialization/Chapter10.html>. Acesso em: 08 out. 2009.
_____. Building accessible websites – forms and interaction, 2006g. Disponível em:
<http://joeclark.org/book/sashay/serialization/Chapter12.html>. Acesso em: 08 out. 2009.
COMMON Look and Feel for the Internet 2.0, 06 ago. 2006. Disponível em: <http://www.tbssct.gc.ca/clf2-nsi2/index-eng.asp>. Acesso em: 09 out. 2009.
CREATING Accessible Flash Content. Disponível em:
<http://www.webaim.org/techniques/flash/>. Acesso em: 23 nov. 2009.
DIAS, Cláudia. Usabilidade na web: Criando portais mais acessíveis. 2. ed. Rio de Janeiro:
Alta Books, 2007. 296 p.
94
E-MAG - Modelo de acessibilidade de governo eletrônico, 07 mai. 2007. Disponível em:
<http://www.governoeletronico.gov.br/acoes-e-projetos/e-MAG>. Acesso em: 11 out. 2009.
ESTADOS UNIDOS DA AMÉRICA. Departamento de Justiça. Ada standards for accessible
design, 18 dez. 2003. Disponível em: <http://www.ada.gov/stdspdf.htm>. Acesso em: 11 out.
2009.
FERREIRA, Aurélio Buarque de Holanda. O minidicionário da língua portuguesa. 4 ed. Rio
de Janeiro: Nova Fronteira, 2001.
FREIRE, André Pimenta. Acessibilidade no desenvolvimento de sistemas web: um estudo
sobre o cenário brasileiro. Dissertação de mestrado, abril 2008. Instituto de Ciências
Matemáticas e de Computação (ICMC), Universidade de São Paulo. Disponível em:
<http://www.teses.usp.br/teses/disponiveis/55/55134/tde-06052008-101644/>. Acesso em: 14
mai. 2009.
GAMELEIRA, Fábio. A primeira cartilha nacional sobre acessibilidade, 2002a. Disponível
em <http://www.lupadigital.info/4-declaracao-de-documento.html>. Acesso em: 27 nov.
2008.
_____. A primeira cartilha nacional sobre Acessibilidade, 2002b. Disponível em
<http://www.lupadigital.info/5-estrutura-de-paginas.html>. Acesso em: 27 nov. 2008.
_____. A primeira cartilha nacional sobre Acessibilidade, 2002c. Disponível em
<http://www.lupadigital.info/8-textos.html>. Acesso em: 27 nov. 2008.
_____. A primeira cartilha nacional sobre Acessibilidade, 2002d. Disponível em
<http://www.lupadigital.info/7-imagens.html>. Acesso em: 27 nov. 2008.
_____. A primeira cartilha nacional sobre Acessibilidade, 2002e. Disponível em
<http://www.lupadigital.info/9-tabelas.html>. Acesso em: 27 nov. 2008.
_____. A primeira cartilha nacional sobre Acessibilidade, 2002f. Disponível em
<http://www.lupadigital.info/6-frames.html>. Acesso em: 27 nov. 2008.
95
_____. A primeira cartilha nacional sobre Acessibilidade, 2002g. Disponível em
<http://www.lupadigital.info/scripts-e-eventos.html>. Acesso em: 23 nov. 2009.
_____. A primeira cartilha nacional sobre Acessibilidade, 2002h. Disponível em
<http://www.lupadigital.info/tecnologia-flash.html>. Acesso em: 23 nov. 2009.
IBC – Instituto Benjamin Constant, As Diversas Definições. Disponível em:
<http://www.ibc.gov.br/?catid=83&blogid=1&itemid=396>. Acesso em: 16 out. 2009.
IBGE - Instituto Brasileiro de Geografia e Estatística. Censo Demográfico 2000, 27 jun. 2003.
Disponível em: <http://www.ibge.gov.br/home/presidencia/noticias/27062003censo.shtm>.
Acesso em: 09 out. 2009.
KRUG, Steve. Não me faça pensar – Uma abordagem de bom senso à usabilidade na web.
Tradução Acauan Pereira Fernandes. 2. ed. Rio de Janeiro: Alta Books, 2008. 201 p.
NIELSEN, Jakob. Projetando websites. Tradução Ana Gibson. Rio de Janeiro: Elsevier, 2000.
416 p.
NIELSEN, Jakob. Why You Only Need to Test with 5 Users. Alertbox, 19 mar. 2000.
Disponível em: <http://www.useit.com/alertbox/20000319.html>. Acesso em: 25 nov. 2009.
NIELSEN, Jakob. Usability is Three Times Better for Non-Disabled Users. Alertbox, 11 nov.
2001. Disponível em: <http://www.useit.com/alertbox/20011111.html>. Acesso em: 02 abr.
2009.
PORTA, Gilberto; QUEIROZ, Marco Antonio de. Formulários em uma web para todos, 06
out. 2008. Disponível em: <http://www.acessibilidadelegal.com/13-formularios.php>. Acesso
em: 21 nov. 2009.
QUEIROZ, Marco Antonio de. Acessibilidade web - Acessibilidade web: tudo tem sua
primeira vez. 2006a. Disponível em: <http://www.bengalalegal.com/capitulomaq.php>.
Acesso em: 07 out. 2009.
96
_____. Diretrizes irlandesas de acessibilidade na web, 10 jan. 2006b. Disponível em:
<http://www.bengalalegal.com/irlandesas.php>. Acesso em: 07 out. 2009.
RIBEIRO, Leonor. Usabilidade. quem manda no site é o cliente. Locaweb em Revista. Ano 2.
Edição 13.
SERPRO. Acesso à web e tecnologia assistiva. Disponível em:
<http://www.serpro.gov.br/acessibilidade/acesso.php>. Acesso em: 27 nov. 2008.
SERPRO. O que é acessibilidade na web. Disponível em:
<http://www.serpro.gov.br/acessibilidade/oque.php>. Acesso em: 27 nov. 2008.
SILVA, Maurício Samy. Técnicas CSS para acessibilidade a conteúdo web - Diretrizes 1.0,
2003. Disponível em: <http://www.maujor.com/w3c/tec_css_acess.html>. Acesso em: 25
nov. 2009.
SILVA, Maurício Samy. As medidas CSS de comprimento, 2004. Disponível em:
<http://maujor.com/tutorial/medidascss.php>. Acesso em: 25 nov. 2009.
SOARES, Horácio Pastor. Acessibilidade: um rio Amazonas entre a teoria e a prática.
Disponível em <http://internativa.com.br/artigo_acessibilidade_11.html>. Acesso em: 11 out.
2008.
SPELTA, Lêda Lucia. Acessibilidade: esse negócio tem futuro?, abri. 2007a. Disponível em:
< http://acessodigital.net/art_acessibilidade_tem_futuro.html>. Acesso em: 13 out. 2009.
_____. Supermercados: o preço da inacessibilidade. 2007b. Disponível em:
<http://www.acessodigital.net/art_leda_supermercados.html>. Acesso em: 18 abri. 2009.
SPELTA, Lêda Lucia. Acessibilidade web: 7 mitos e um equívoco. Disponível em:
<http://www.acessodigital.net/art_acessibilidade-web-7-mitos-e-um-equivoco.html>. Acesso
em: 18 abri. 2009.
97
TECNOLOGIA Assistiva. Disponível em: <http://www.assistiva.com.br/>. Acesso em: 29
set. 2009.
THE PRINCIPLES of universal design, North Carolina State University, The Center for
Universal Design, 04 jan. 1997. Disponível em:
<http://www.design.ncsu.edu/cud/about_ud/udprinciplestext.htm>. Acesso em: 28 set. 2009.
TORRES, Bruno. Acessibilidade não é altruísmo, mar. 2006. Disponível em:
<http://www.brunotorres.net/acessibilidade-nao-e-altruismo>. Acesso em: 07 out. 2009.
W3C – World Wide Web Consortium. Recomendações para a acessibilidade do conteúdo da
web - 1.0, 1999. Disponível em:
<http://www.geocities.com/claudiaad/acessibilidade_web.html>. Acesso em: 16 out. 2009.
W3C – World Wide Web Consortium. Recomendações de acessibilidade para conteúdo web 2.0, 2008. Disponível em: <http://www.ilearn.com.br/TR/WCAG20/>. Acesso em: 23 nov.
2009.
W3C – World Wide Web Consortium. W3C mission, 2009. Disponível em:
<http://www.w3.org/Consortium/mission>. Acesso em: 26 out. 2009.
WEB. Disponível em: <http://universaldesign.ie/it-accessibility-guidelines/web>. Acesso em:
09 out. 2009.
WHO – Bulletin of the World Health Organization. Global data on visual impairment in the
year 2002, Nov. 2004. Disponível em: <http://whqlibdoc.who.int/bulletin/2004/Vol82No11/bulletin_2004_82(11)_844-851.pdf>. Acesso em: 09 out. 2009.