Sistemas de Informação Wander Fernandes Rodrigues Júnior...

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.


Profa. MYRNA CECÍLIA MARTINS DOS SANTOS AMORIM.

M.Sc. Sistemas e Computação - IME/RJ.


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 e colegas que

conviveram comigo durante este ciclo de

aprendizagem e contribuíram, direta ou

indiretamente, para minha formação.

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/

3 Acesso Digital - http://www.acessodigital.net/

4 NCE/UFRJ - http://intervox.nce.ufrj.br/

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.

6 IBC - http://www.ibc.gov.br/.

7 SERPRO – Acessibilidade na web: http://www.serpro.gov.br/acessibilidade/.

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

voz

Traduz texto eletrônico, gerado por software leitor de tela ou

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.

10 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

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:

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/. 12

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/.

Figura 4.1 - Selos de níveis de conformidade que podem ser obtidos por uma página web.

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

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.

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.

<!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>

<!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/xhtml1-

transitional.dtd">

Figura 4.2 - Exemplos das principais declarações de tipo de documento – DTD.

Figura 4.3 - Estrutura básica de um documento 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, desobrigando-

se 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/. 19

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/.

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:

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.

<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" />

48

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).

h1 {

voice-family: paul;

stress: 20;

richness: 90;

cue-before: url("ping.au")

}

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).

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

@media print {

body { font-size: 10pt }

}

@media screen {

body { font-size: 13px }

}

@media screen, print {

body { line-height: 1.2 }

}

Figura 4.6 - Diferentes tipos de mídia definidos em um mesmo documento de estilo.

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.

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/working-

examples/G183/link-contrast.html.

Figura 4.7 - A cor não deve ser o único elemento para a transmissão de informações.

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. 26

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.

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.

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

<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.

55

indicada pelo atributo lang. Os elementos podem, ainda, ter o visual controlado por 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).

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...

Tim Berners-Lee afirma que <q cite="

http://www.w3.org/People/Berners-Lee/">a Web é

universal</q>

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.

Figura 4.11 - Exemplo de citação indireta em texto.

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).

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

.

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 “ 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. 30

O W3C fornece detalhes sobre charsets - http://www.w3.org/TR/html401/charset.html. Tradução disponível

em: http://desenaviegas.com/charset.html.

<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.

<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.

57

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.

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.

<a href="acessibilidade.html" title="Página sobre

acessibilidade do site">Acessibilidade</a>

<a href="acessibilidade.html">

<h1>o que é acessibilidade na internet?</h1></a>

Figura 4.16 - Exemplo de link estendido ao contexto.

Figura 4.15 - Meta dados para links através do atributo title.

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.

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.

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.

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>

a:focus { color: #990000; background-color: white; border:

solid 1px gray; }

Figura 4.17 - Links do tipo âncora.

Figura 4.18 - Exemplo de link externo indicado visualmente.

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.

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

<img src="images/logoacesso.jpg" alt="Símbolo de acesso à

Web" longdesc="longdesc/logoacesso.html" />

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”.

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).

[d]

Figura 4.22 - Recurso d-link junto à imagem.

62

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

<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.

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.

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.

Estrutura básica da tabela:

<table>

<tr>

<td>Texto</td>

</tr>

</table>

Estrutura básica do DIV

<div>Texto</div>

Figura 4.24 - Comparação entre célula criada com tabela e com o elemento div.

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.

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.

<table summary=”Descrição/Resumo da tabela...”>

<caption>Legenda da tabela...</caption>

<tr>

<td>Texto</td>

</tr>

</table>

65

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.

<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>

66

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.

<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>

67

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.

<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>

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.

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"></label>

<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.

Figura 4.30 - Associação de um rótulo a um controle de formulário.

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).

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; }

<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.

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.

É 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):

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).

fieldset { border: none }

Figura 4.34 - Grupo de controles sem exibição de borda, utilizando CSS.

<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.

71

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).

<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.

72

A recomendação 6.3 das WCAG 1.0 ratifica a necessidade de scripts, applets e plug-

ins 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.

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/.

<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.

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

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

Iniciativa de acessibilidade no Adobe Flash - http://www.adobe.com/accessibility/products/flash/tutorial/. 34

Diretrizes W3C para ferramentas de autoria - http://www.w3.org/WAI/intro/atag.php.

Figura 4.38 - Iniciativa de acessibilidade em ferramentas de autoria, como Adobe Flash.

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, deve-

se 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/css-

validator/, 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-pt-

br.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.

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.

Figura 5.1 - Exemplo de navegador gráfico com imagens desabilitadas.

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.

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/. 39

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/.

Figura 5.2 - Exemplo de site testado com o simulador Lynx Viewer.

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.

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

Figura 5.3 - Modelo proposto de site acessível – www.acessibilidadeweb.com.br.

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/_Ato2004-

2006/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:


_____. Building accessible websites – types and colour, 2006c. Disponível em:


_____. Building accessible websites – stylesheets 2006d. Disponível em:


_____. Building accessible websites – text and links, 2006e. Disponível em:


_____. Building accessible websites – tables and frames, 2006f. Disponível em:


_____. Building accessible websites – forms and interaction, 2006g. Disponível em:


COMMON Look and Feel for the Internet 2.0, 06 ago. 2006. Disponível em: <http://www.tbs-

sct.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/Vol82-

No11/bulletin_2004_82(11)_844-851.pdf>. Acesso em: 09 out. 2009.

Sistemas de Informação Wander Fernandes Rodrigues Júnior...

Documents

Transcript of Sistemas de Informação Wander Fernandes Rodrigues Júnior...