Estudo de Caso sobre a Adoção de Padrões de Acessibilidade em Aplicações Web

ESTUDO DE CASO SOBRE A ADOÇÃO DE PADRÕES
DE ACESSIBILIDADE EM APLICAÇÕES WEB
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E
TECNOLOGIA DO RIO GRANDE DO NORTE
YSTALLONNE CARLOS DA SILVA ALVES
NATAL/RN
2014

Trabalho de Conclusão de Curso apresentado
ao Curso Superior de Tecnologia em Análise
e Desenvolvimento de Sistemas do Instituto
Federal de Educação, Ciência e Tecnologia
do Rio Grande do Norte, em cumprimento
às exigências legais como requisito parcial à
obtenção do título de Tecnólogo em Análise e
Desenvolvimento de Sistemas.
Orientador: M.e Edmilson Barbalho Campos Neto.
NATAL/RN
2014

Ficha elaborada pela Seção de Processamento Técnico da Biblioteca Sebastião
Fernandes do IFRN
A474e Alves, Ystallonne Carlos da Silva.
Estudo de caso sobre a adoção de padrões de acessibilidade em
aplicações web / Ystallonne Carlos da Silva Alves. – 2014.
xx f. : il.
Orientador: Me. Edmilson Barbalho Campos Neto.
Trabalho de Conclusão de Curso (Tecnologia em Análise e Desen-
volvimento de Sistemas) – Instituto Federal de Educação, Ciência e
Tecnologia do Rio Grande do Norte, 2014.
1. Análise e Desenvolvimento de Sistemas. 2. Padrões em acessi-
bilidade na web. 3. Tecnologias assistivas. 4. World Wide Web Con-
sortium – W3C. I. Campos Neto, Edmilson Barbalho. II. Título.
CDU 004.4

Trabalho de Conclusão de Curso apresentado
ao Curso Superior de Tecnologia em Análise
e Desenvolvimento de Sistemas do Instituto
Federal de Educação, Ciência e Tecnologia
do Rio Grande do Norte, em cumprimento
às exigências legais como requisito parcial à
obtenção do título de Tecnólogo em Análise e
Desenvolvimento de Sistemas.
Trabalho de Conclusão de Curso apresentado e aprovado em 13 de outubro de
2014, pela seguinte Banca Examinadora:
BANCA EXAMINADORA
__________________________________________________
M.e Edmilson Barbalho Campos Neto
Presidente
IFRN Campus Natal-Zona Norte
__________________________________________________
Prof.° Philippi Sedir Grilo De Morais
Examinador
Universidade Federal do Rio Grande do Norte - UFRN
__________________________________________________
Prof.° Ari Barreto de Oliveira
Examinador
IFRN Campus Natal-Central

À minha avó, Maria de Lourdes, pelo incondicional
apoio que sempre me faz perseverar.

AGRADECIMENTOS
Aos meus familiares, por acreditarem.
Aos meus amigos, pela motivação, compreensão e paciência.
Ao meu orientador e amigo, M.e Edmilson Barbalho Campos Neto, pelo
entusiasmo e dicas valiosas durante todo o processo.
Aos integrantes da banca examinadora, pelo tempo e atenção.
Aos que fortificam o IFRN, em especial, os meus professores, pela sabedoria e
dedicação.

A deficiência não precisa ser um
obstáculo para o sucesso.
(Stephen W. Hawking)

As we look ahead into the next century,
leaders will be those who empower others.
(Bill Gates)

Design is not just what it looks like and feels like.
Design is how it works.
(Steve Jobs)

RESUMO
O presente estudo verifica o estado do conhecimento sobre acessibilidade
no desenvolvimento de aplicações para Web. Com o objetivo de compreender
as tecnologias assistivas disponíveis e utilizadas pela maioria dos internautas,
explorando diferentes aspectos acerca de acessibilidade, discute-se a respectiva
utilização e funcionamento daquelas. Examina-se ainda diretivas, legislações
e mecanismos existentes para assegurar a complacência a padrões, além das
convenções ou boas práticas empregadas para um desenvolvimento Web
acessível. Como forma de investigar a conformidade a padrões de acessibilidade
Web de aplicações, o trabalho considera a proposição de um estudo de caso onde
se verifica o nível de conformidade de aplicações em relação às Web Content
Accessibility Guidelines1
2.0 propostas pelo World Wide Web Consortium (W3C).
Assim, valida‑se as diretrizes sugeridas pelo W3C por meio de um estudo de caso
construído de maneira direcionada pela análise da complacência das aplicações
objeto do estudo de caso – empregando técnicas, análise, testes e validações –,
versando sobre a perpectiva de identificação de problemas no desenvolvimento
sem complacência a padrões em acessibilidade na Web.
Palavras-chave: Acessibilidade. Padrão. Tecnologias Assistivas. Web Content
Accessibility Guidelines. World Wide Web Consortium.
1 Em português, Diretivas de Acessibilidade para Conteúdo Web.

ABSTRACT
This study verifies the state of knowledge regarding accessibility in the
development of Web applications. Aiming to understand the assistive technologies
available and used by most netizens, exploring different accessibility’s aspects, it
discusses the use and operation of those technologies. It examines further guidelines,
laws, and existing mechanisms to ensure standard-compliance on the Web as well
as conventions or best practices applied for an accessible Web development. As a
way to investigate applications’ Web accessibility standard-compliance, this paper
considers a case study proposicion in which it is verified the conformity level of
two applications regarding the Web Content Accessibility Guidelines 2.0, which
is recommended by the World Wide Web Consortium (W3C). Therefore, the W3C
suggested guidelines are validated through a case study which was built in order
to analyse the complacency of the applications which were subject of the case
study – applying techniques, examinations, tests, and validations –, considering the
perspective of identifing problems in the development without conformacy to Web
accessibility standards.
Keywords: Accessibility. Assistive Technologies. Standard. Web Development. Web
Content Accessibility Guidelines. World Wide Web Consortium.

LISTA DE ILUSTRAÇÕES
Imagem 1 – Análise utilizando o inspetor de elemento do Mozilla Firefox na página
inicial da aplicação EXPOTEC. 72
Imagem 2 – Análise utilizando o inspetor de elemento do Mozilla Firefox na página
inicial da aplicação Amazing Med. 73
Imagem 3 – Eliminando o áudio do sistema operacional para examinar a página
“Videowall” da aplicação Amazing Med. 76
Imagem 4 – Análise utilizando o leitor de tela NVDA na página “Submissão” da
aplicação EXPOTEC revelou que não existe rótulo de texto associado
aos elementos de entrada do formulário. 79
Imagem 5 – Análise utilizando o leitor de tela NVDA na página de login da
aplicação Amazing Med revelou que existe rótulo de texto associado
aos elementos de entrada do formulário. 81
Imagem 6 – Análise utilizando o leitor de tela NVDA na página de inserção de
um novo registro de paciente na aplicação Amazing Med revelou
que existe rótulo de texto associado aos elementos de entrada do
formulário e que a navegação utilizando a tecla Tab é intuitiva e lógica
também.82
Imagem 7 – As tabelas são usadas apenas para dados tabulados na página de
boletins da aplicação Amazing Med. 83
Imagem 8 – Simulação de deuteranopia (comparação entre o original e a
simulação).85
Imagem 9 – Simulação de protanopia (comparação entre o original e a simulação).
86
Imagem 10 – Simulação de tritanopia (comparação entre o original e a simulação).
86

Imagem 11 – Obtendo a cor do texto utilizando o inspetor de elementos do
navegador Google Chrome na aplicação EXPOTEC. 87
Imagem 12 – Paleta de cor utiliza combinação com grau de contraste de 7:1. 88
Imagem 13 – Apresentação visual poderia ser feita usando apenas texto para o
botão do login. 89
Imagem 14 – Opções de configurações de prova de cores referente às
analomalias deuteranopia e protanopia no Adobe®
Photoshop®
.91
Imagem 15 – Página de cartões (Videowall) relativos às internações sendo
processadas pelo sistema e apresentadas de forma visual por meio
de uma separação utilizando cor como elemento de distinção entre
elementos e que representa o estado de atenção dos respectivos
pacientes internados. 91
Imagem 16 – Página de cartões (Videowall) relativos às internações sendo
processadas pelo sistema e apresentadas de forma visual por meio
de uma separação utilizando cor como elemento de distinção entre
elementos e que representa o estado de atenção dos respectivos
pacientes internados sendo visualizada sob a perspectiva de prova
de cores do Adobe®
Photoshop™ para simular a percepção de cor
de indivíduos acometidos por deuteranopia. 92
Imagem 17 – Página principal de internações do sistema Amazing Med
apresentando as internações e respectivos estados de atenção dos
pacientes internados sendo visualizada sob a perspectiva de prova
de cores do Adobe®
Photoshop™ para simular a percepção de cor
de indivíduos acometidos por protanopia. 93
Imagem 18 – Obtendo cores a partir do Adobe Photoshop para a realização de
testes de contraste mínimo. 94

Imagem 19 – Utilizando a ferramenta Contrast-A para verificar o grau de contraste
mínimo entre as cores do texto e fundo de botões da aplicação
Amazing Med. 95
Imagem 20 – Acesso ao submenu “Cultural” é inviável a partir apenas do teclado
na aplicação Web EXPOTEC. 97
Imagem 21 – Nenhum dos subitens do menu da aplicação pode ser acessado
utilizando apenas o teclado. 98
Imagem 22 – Página de gráficos não fornece controles para gerenciar o tempo de
alternacia da rotatividade dos gráficos apresentados. 102
Imagem 23 – Aplicação EXPOTEC não possui o atributo lang para identificar a
linguagem das páginas na tag HTML. 108
Imagem 24 – Aplicação Amazing Med utiliza a tag lang para identificar a língua
portuguesa como o idioma das páginas. 109
Imagem 25 – Página de gráficos apresenta elemento não previsto em língua
inglesa.110
Imagem 26 – Elementos repetidos são consistentes na navegação entre as
páginas da aplicação EXPOTEC. 112
Imagem 27 – Elementos repetidos têm posicionamento idêntico nas páginas da
aplicação Amazing Med. 114
Imagem 28 – A página “Submissão” da aplicação EXPOTEC não possui elementos
que auxiliem na identificação de campos obrigatórios para o
preeenchimento do formulário. 116
Imagem 29 – Aplicação fornece identificação para campos obrigatórios que
auxiliam no preenchimento do formulário. 118
Imagem 30 – Para auxiliar na resubmissão do formulário, o sistema Amazing Med
provê texto de ajuda que fornece informações para o adequado
preenchimento dos campos. 119

Imagem 31 – Localizando as ferramentas do desenvolvedor no Google Chrome
para auditoria da aplicação. 121
Imagem 32 – Verificando se a extensão do Chrome, a Accessibility Developer
Tools, encontra-se ativada. 121
Imagem 33 – Executando a auditoria de acessibilidade na página. 122
Imagem 34 – Considerando leitores de tela, o formulário não possui tag semântica
ou atributos ARIA que informem que a div representa um formulário
e a tag label não possui identificador sobre qual elemento o texto
com o valor da tag se rotula. 122
Imagem 35 – Enviando os dados de uma página para validação utilizando os
serviços do W3C. 124
Imagem 36 – Resultado da validação utilizando o Adobe®
Dreamweaver®
.124

LISTA DE QUADROS
Quadro 1 – Recursos gerais para acessibilidade. 44
Quadro 2 – Prós e contras do software de reconhecimento de voz Dragon®
NaturallySpeaking®
Premium. 50
Quadro 3 – Auditoria do Accessibility Developers Tools. 52
Quadro 4 – Ferramentas online para teste de acessibilidade. 53
Quadro 5 – Alternativas em texto. 60
Quadro 6 – Mídias com base no tempo. 60
Quadro 7 – Adaptável. 62
Quadro 8 – Discernível. 62
Quadro 9 – Acessível por teclado. 64
Quadro 10 – Tempo suficiente. 65
Quadro 11 – Ataques epilépticos. 66
Quadro 12 – Navegável. 66
Quadro 13 – Legível. 68
Quadro 14 – Previsível. 68
Quadro 15 – Assistência de entrada. 69
Quadro 16 – Compatível. 70
Quadro 17 – Parecer da análise de conformidade referente à diretiva 1.1 para a
aplicação Web EXPOTEC. 72
aplicação Web Amazing Med. 73
aplicação Web Amazing Tech. 76

Quadro 41 – Comparativo da conformidade às WCAG 2.0 entre as aplicações
Web EXPOTEC e Amazing Med. 126

LISTA DE ABREVIATURAS E SIGLAS
ARIA — Accessible Rich Internet Applications (Aplicações Ricas para Internet
Acessíveis).
Art. — Artigo.
ASCII — American Standard Code for Information Interchange.
ASP — Active Server Pages.
ATAG — Authoring Tool Accessibility (Ferramenta de Autoração de Acessibilidade).
AT — Assistive Technology (Tecnologia Assistiva).
CERN — Organisation Européenne pour la Recherche Nucléaire (Organização
Europeia para a Pesquisa Nuclear).
CSS — Cascading Style Sheet (Folhas de Estilo).
Div — Divisão.
HTML — HyperText Markup Language (Linguagem de Marcação de Hipertexto).
Hz — Hertz.
ISO — International Standards Organization.
JAWS — Job Access with Speech (Acesso a Trabalho com Ditado).
NVDA — NonVisual Desktop Access (Acesso Não Visual ao Desktop).
OCDE — Organização de Cooperação e de Desenvolvimento Econômico.
OCR — Optical Character Recognition (Reconhecimento Óptico de Caracteres).
OMS — Organização Mundial da Saúde (World Health Organization).
OS — Operating System (Sistema Operacional).
PC — Personal Computer (Computador Pessoal).
PDF — Portable Document File.
PHP — PHP Hypertext Preprocessor.
Tab — Tabular key (Tecla tabular).
TI — Tecnologia da Informação.
UAAG — User Agent Accessibility Guidelines (Diretivas para Acessibilidade de
Agente de Usuário).

UI — User Interface (Interface do Usuário).
UNESCO — United Nations Educational, Scientific and Cultural Organization
(Organização das Nações Unidas para a Educação, a Ciência e a
Cultura).
URL — Uniform Resource Locator (Localizador Padrão de Recurso).
US$ — United States dollar (Dólar Americano).
UX — User Experience (Experiência do Usuário).
W3C — World Wide Web Consortium (Consórcio da Rede Mundial de
Computadores).
WAI-ARIA — Web Accessibility Initiative - Accessible Rich Internet Applications.
WCAG — Web Content Accessibility Guidelines (Diretivas para Acessibilidade de
Conteúdo da Web).
Web — World Wide Web (Rede Mundical de Computadores).

LISTA DE SÍMBOLOS
@ — Arroba.
© — Copyright.
° — Grau.
— 1. Maior que. 2. Fecha tag.
— 1. Menor que. 2. Abre tag.
® — Registered (Marca registrada).
™ — Trademark (Marca comercial).

SUMÁRIO
1 INTRODUÇÃO 25
1.1 OBJETIVOS 27
1.2 METODOLOGIA 28
2 CONCEITUANDO E CONTEXTUALIZANDO ACESSIBILIDADE WEB 29
3 DIRETIVAS E COMPLACÊNCIA A PADRÕES E CONVENÇÕES 35
3.1 PADRÕES DO W3C 36
3.2 WAI-ARIA 37
3.3 WEB CONTENT ACCESSIBILITY GUIDELINES 38
3.4 BOAS PRÁTICAS PARA PROMOÇÃO DE ACESSIBLIDADE 39
3.5 LEGISLAÇÃO 42
3.6 FONTES DE RECURSOS SOBRE ACESSIBILIDADE 43
4 TECNOLOGIAS ASSISTIVAS 45
4.1 SOFTWARES DE LEITURA DE TELA 47
4.2 DISPLAY BRAILLE 48
4.3 SOFTWARE DE LEGENDAGEM 48
4.4 RECONHECIMENTO DE VOZ 49
5 TESTES E ANÁLISE DE ACESSIBILIDADE WEB 51
5.1 ACCESSIBILITY DEVELOPERS TOOLS 52
5.2 FERRAMENTAS PARA TESTE DE ACESSIBILIDADE 53
6 ESTUDO DE CASO SOBRE A ANÁLISE DA COMPLACÊNCIA ÀS DIRETIVAS
DE ACESSIBILIDADE PARA CONTEÚDO WEB 55
6.1 CONFIGURAÇÃO DO ESTUDO 55
6.2 OBJETIVOS DO ESTUDO 56
6.3 APLICAÇÕES WEB OBJETO DE ANÁLISE 57
6.4 CRITÉRIOS EXAMINADOS E VERIFICAÇÕES 59
7 ANÁLISE DOS RESULTADOS 71
7.1 PRINCÍPIO 1: PERCEPTÍVEL. 71

7.1.1 EXPOTEC 71
7.1.2 Amazing Med 73
7.1.3 EXPOTEC 74
7.1.5 EXPOTEC 77
7.1.7 EXPOTEC 84
7.2 PRINCÍPIO 2: OPERÁVEL. 96
7.2.1 EXPOTEC 97
7.2.3 EXPOTEC 99
7.2.5 EXPOTEC 103
7.2.7 EXPOTEC 105
7.3 PRINCÍPIO 3: INTELIGÍVEL. 108
7.3.1 EXPOTEC 108
7.3.3 EXPOTEC 111
7.3.5 EXPOTEC 115
7.4 PRINCÍPIO 4: ROBUSTO. 120
7.4.1 EXPOTEC 120
8 RESUMO DOS RESULTADOS 126
9 CONSIDERAÇÕES FINAIS 129

REFERÊNCIAS 130
GLOSSÁRIO 133
APÊNDICE A – RESULTADO DE CHECAGEM A PARTIR DA FERRAMENTA
ACHECKER DA PÁGINA PRINCIPAL DE INTERNAÇÕES DA APLICAÇÃO
AMAZING MED APRESENTANDO A AUSÊNCIA DE PROBLEMAS COM A
COMPLACÊNCIA À WCAG 2.0. 137
APÊNDICE B – RESULTADO DA VALIDAÇÃO DA PÁGINA PRINCIPAL DE
INTERNAÇÕES DA APLICAÇÃO AMAZING MED UTILIZANDO O ADOBE®
DREAMWEAVER™ INDICANDO UMA UTILIZAÇÃO ILEGAL DO ELEMENTO
“LEGEND” EM UM FORMULÁRIO, UTILIZAÇÃO DE CÓDIGOS UNICODES
PROIBIDOS, ALERTAS SUGERINDO A INCLUSÃO DE UMA TAG H1 PARA
ELEMENTOS DE CABEÇALHO E QUE A TAG SECTION UTILIZADA NÃO
APRESENTA HEADING OU CABEÇALHO (O QUE NECESSITARIA A INSERÇÃO
DE UMA TAG HTML DO GRUPO H). 138
ANEXO A – NAVEGAÇÃO PELO SITE DO GOOGLE MAPS UTILIZANDO O
DRAGON®
NATURALLYSPEAKING®
. 139
ÍNDICE 140

25
1 INTRODUÇÃO
O computador interligado em rede transformou-se em um dos principais
instrumentos de difusão da informação. Oportunamente, novas tecnologias e
ferramentas a serviço da sociedade surgiram e com elas a exigência para que se
desenvolvam aplicações Web que atinjam padrões de excelência no tocante à
utilização daquelas. Despertou-se então uma preocupação maior, por exemplo, com
a interface e o grau de interatividade proporcionado através da riqueza de recursos e
dinamicidade que as aplicações poderiam empreender.
Porém, verificou-se ainda que a complexidade das soluções resultou em
problemas que prejudicam uma satisfatória utilização das aplicações Web por todos
os indivíduos integrantes de um público-alvo tão diversificado, com tão diferentes
perfis, que utiliza a Internet.
Além disso, as diferenças de implementação das ferramentas de acesso
acarretaram outra problemática, a referente à produção de conteúdo que possa ser
interpretado e transmitido também através de múltiplos dispositivos, plataformas,
sistemas operacionais, navegadores, plug-ins, etc.
Neste contexto, os recursos que permitem amplificação de acesso na Web
representam a principal ferramenta na tentativa para assegurar que isso aconteça da
forma mais satisfatória para o maior público possível.
A construção de uma análise da acessibilidade das aplicações Web denominadas
EXPOTEC e Amazing Med corresponde ao objetivo principal deste trabalho e a
motivação para a produção de um estudo exploratória acerca de acessibilidade na
Web necessário para a realização da respectiva análise.
De acordo com Relatório Mundial da Deficiência (OMS, 2011):
A deficiência faz parte da condição humana. Quase todas as pessoas
terão uma deficiência temporária ou permanente em algum momento de
suas vidas e aqueles que sobreviverem ao envelhecimento enfrentarão
dificuldades cada vez maiores com a funcionalidade de seus corpos. A
maioria das grandes famílias possui um familiar deficiente, e muitas pessoas
não deficientes assumem a responsabilidade de prover suporte e cuidar de
parentes e amigos com deficiências. Todos períodos históricos enfrentaram
a questão moral e política de como melhor incluir e apoiar as pessoas com
deficiência. Essa questão se tornará mais premente conforme a demografia
das sociedades muda e cada vez mais pessoas alcançam a idade avançada.

26
Ainda conforme o relatório, cerca de 10% da população, ou seja, 650 milhões
de pessoas, vivem com uma deficiência. “São a maior minoria do mundo”.
Além disso, constata-se também que nos países onde a esperança de vida é
superior a 70 anos, cada indivíduo viverá com uma deficiência em média 8 anos, isto
corresponde a 11,5% da existência dele (UNRIC, 2013).
Esses dados representam uma perspectiva baseada em números alarmantes
que justificam categoricamente a importância de posicionar acessibilidade como
elemento fundamental para minimizar o impacto negativo dos condicionantes aos
quais ficam passíveis os portadores de deficiência.
Da mesma forma, neste contexto, pode-se inferir que acessibilidade representa
uma solução totalmente factual e favorável ao fortalecimento da produção de
ferramentas que possam atender melhor essas minorias e proporcionar benefícios
salutares para a social em que vivemos.
Assim, considerando múltiplos aspectos de interferentes e facilitadores do
processo de design de interfaces do usuário e objetivando a realização da análise
mencionada, esta obra apresenta conceitos e técnicas as quais intrinsecamente
colaboram para a perspectiva de uma experiência proveitosa e abrangente no campo
da acessibilidade.
Ao longo deste trabalho, como forma de contextualizar a importância também
de se ter conformidade a padrões nas aplicações, apresentam-se ainda algumas
diretivas governamentais/institucionais existentes que tangem a regulamentação de
acessibilidadecomoparteoportunaemesmoobrigatóriaemprojetosdesoftwareepara
a Web desenvolvidos com a finalidade de atingir um público-alvo amplo e democratizar
o acesso à informação. Neste contexto, amplia-se as informações a respeito do Web
Content Accessibility Guidelines (WCAG), o principal padrão empregado para verificar
a aplicação de acessibilidade em conteúdo produzido para a Web.
Além disso, apresenta-se aqui ainda as tecnologias assistivas empregadas por
usuários com diferentes tipos de necessidades especiais como forma de suplantar
barreiras de acesso na Web. Algumas destas tecnologias foram necessárias para a

27
realização da análise objeto do trabalho e o entendimento destas permite clarificar a
utilização na avaliação feita para as aplicações Web citadas anteriormente.
As técnicas, testes e ferramentas de promoção de acessibilidade compõem
também o processo exploratório da construção da análise a que se dedica esta obra
e representa parte fundamental para um direcionamento à complacência a padrões.
Apresentada uma reunião de recomendações para análise da acessibilidade e
levando-se em consideração todos os elementos tratados no decorrer do estudo,
enumera-se e justifica-se os itens identificados como interferentes no campo da
acessibilidade, baseando-se no referencial teórico, nas aplicações Web analisadas.
Portanto, pode-se perceber que o desenvolvimento de aplicações Web a partir
de princípios de acessibilidade permite significativos benefícios e avanços relativos
às áreas, por exemplo, de interação humano-computador, design de interação,
experiência do usuário e design de interfaces, bem como uma prospectiva e desejável
inclusão digital eficaz no momento de uma respectiva incorporação ao projeto que os
utilizam como norte.
1.1 OBJETIVOS
a) Verificar a conformidade de diretivas para amplificação de acesso das apli-
cações Web EXPOTEC e Amazing Med através do mapeamento e análise de técnicas
que permitem identificar, discutir e examinar considerações quanto às dificuldades e
limitações que surgem no desenvolvimento de projetos para a Web.
b) Compreender conceitos relacionados ao desenvolvimento incorporando
ferramentas para produzir Interface do Usuário (UI) e Experência do Usuário (UX) com
amplificações de acesso.
c) Avaliar a eficiência de tecnologias assistivas (AT) disponíveis e popularmen-
te utilizadas por indivíduos com necessidades especiais.
d) Investigar diretivas governamentais/institucionais existentes que tangem a
regulamentação de acessibilidade no campo da Tecnologia da Informação.
e) Examinar técnicas, testes e ferramentas de promoção de acessibilidade que
fundamentam um direcionamento à complacência a padrões.

28
f) Com base em técnicas de design de UI e boas práticas para desenvolvimento
Web acessível, verificar a complacência à diretivas que possibilitem a integração e
utilização de mecanismo de amplificação de acesso nas aplicações Web objeto do
estudo de caso.
g) Observar as vantagens e eventuais entraves que as proposições possam
apresentar e que requeiram melhorias dentro do entendimento da composição e ne-
cessidade de adoção dos conceitos discutidos da análise realizada.
1.2 METODOLOGIA
O desenvolvimento deste trabalho dar-se-á a partir de um estudo exploratório
sobre acessibilidade e da análise e aplicação dos conceitos estudados para a
identificação dos problemas de acessibilidade presentes no estudo de caso; assim,
sobumaperspectivadeproduçãovisualizandoacessibilidade,forneceosmecanismos
para identificar possíveis problemáticas com base no referencial teórico.
Além disso, buscando expandir a análise da acessibilidade nas aplicações
Web objeto do estudo, compreende-se uma investigação pautada na realização
de abordagens que identifiquem elementos os quais possam comprometer a
incorporação de recursos para amplificar acesso. Dessa forma, considerando de
maneira global quais seriam os aspectos que valorizam ou prejudicam a eficiência e
eficácia de processos para ampliar as possibilidades de acessibilidade.
Portanto, após o levantamento e realização de uma devida fundamentação
teórica, estatística e metodológica, necessária para a formulação da análise, o estudo
seguirá com a verificação dos itens desejáveis para a constituição de uma aplicação
Web acessível e validará as proposições utilizando métodos experimentais na análise
construída acerca dos sistemas EXPOTEC e Amazing Med.

29
2 CONCEITUANDO E CONTEXTUALIZANDO ACESSIBILIDADE WEB
Designa-se por acessível (do latim accessibîle) aquilo que se pode atingir,
alcançar ou obter facilmente; inteligível; compreensível.
O conceito de acessibilidade é bastante diversificado, permeia uma variedade de
assuntos e interliga-se com definições, por exemplo, sobre usabilidade, independência
de dispositivos, complacência a padrões, entre outros.
O World Wide Web Consortium (W3C), em sua “Introdução para Acessibilidade
na Web”, define que:
Acessibilidade na Web significa que pessoas com deficiência podem utilizar a
Internet. Mais especificamente, acessibilidade na Web significa que pessoas
com deficiência podem perceber, compreender, navegar e interagir com a
Web e que podem contribuir para a Web. Acessibilidade na Web também
beneficia a outros grupos de indivíduos, incluindo pessoas idosas com
capacidades comprometidas devido ao envelhecimento (W3C, 2005).
Aplicar essa definição para a Web representaria garantir que as interfaces que
criamos possam ser usadas pelo maior público possível e, portanto, garantiria que
não haveria usuário que fosse deixado de fora. Isso soa como um ideal sublime e
pode até parecer difícil, no mínimo, compreensível, mas certamente atingível.
Segundo Rush e Slatin (2002), websites são acessíveis quando os indivíduos
com deficiência podem ter acesso e utilizá-los de forma tão eficaz quanto as pessoas
que não têm deficiência. Neste contexto, uma tecnologia acessível corresponde à
tecnologia que os usuários podem adaptar para atender suas preferências visuais,
auditivas, motoras, cognitivas e de necessidades da fala e interação. Assim, tecnologia
acessível inclui opções de acessibilidade e utilitários que permitem interação
através de Tecnologias Assistivas (AT), as quais ajudam os indivíduos no manejo de
computadores provendo soluções especiais de hardware e software.
Existem essencialmente dois tipos de usuários de tecnologia acessível: (1)
aqueles que dela necessitam, por causa de deficiências ou condições relacionadas
à idade ou condições temporárias (tais como dificuldade de locomoção de um braço
quebrado), e (2) aqueles que usam-na por preferência, para uma experiência mais
confortável ou conveniente (MICROSOFT CORPORATION, 2009).

30
A maioria dos usuários de computador (54%) conhecem alguma forma de
tecnologia acessível e 44% dos usuários de computador usam alguma forma dela, mas
muitos deles não estão usando ATs que iriam beneficiá-los diretamente (FORRESTER
apud MICROSOFT CORPORATION, 2009).
Algo importante a se notar sobre a definição de acessibilidade é que ela é
centrada no usuário, não no documento, no conteúdo. Em outras palavras, isso define
acessibilidade como um aspecto ou a qualidade da experiência individual do usuário
de um site e não como uma propriedade do próprio documento/conteúdo.
Isto tem implicações importantes para Web designers e desenvolvedores: isso
significa que o trabalho, nesse contexto, é produzir uma experiência de acessibilidade.
O que faz com que seja importante ter uma melhor compreensão de como as pessoas
com deficiência experimentam a Web. Assim, estaremos em melhor posição para
pensar em maneiras para utilizar as diretrizes de acessibilidade e padrões existentes
como recursos para melhorar a experiência Web e não como uma infinidade de regras
que devem ser seguidas (RUSH; SLATIN, 2002).
Portanto, amplificar acesso é permitir que indivíduos com deficiência utilizem
aplicações sem interferências devido à respectiva deficiência que possuem, seja
física, auditiva, visual, mental ou múltipla.
Tratando-se de acessibilidade, pode-se dizer que não existe uma aplicação que
seja totalmente inacessível. Toda aplicação tem pelo menos uma forma significante
pela qual se pode ter acesso ao conteúdo sendo transmitido e uma única forma de
acesso pode também atender diferentes necessidades.
O indivíduo com deficiência para ler, por exemplo, “não pode efetivamente ler por
causa de uma deficiência visual, física, perceptual, de desenvolvimento, cognitiva, ou
uma dificuldade de aprendizagem” (DAISY GLOSSARY, 2012 apud GARRISH, 2012).
Isso significa que o melhor método para lidar com qualquer uma dessas áreas não
é necessariamente o melhor método para lidar com qualquer das outras. O áudio é
necessário para os leitores que são cegos, por exemplo, mas um leitor que é disléxico
pode se beneficiar do áudio, ou de mudanças de fontes, ou referências visuais, ou

31
de uma combinação destes elementos. Não há uma resposta universal (GARRISH,
2012).
Por outro lado, pode-se dizer que não existe uma aplicação que seja totalmente
acessível. No momento em que se necessita utilizar áudio e texto, por exemplo, em
uma aplicação só, surdos e cegos podem ser prejudicados sem ter acesso a parte
do conteúdo disponível. Em tese, áudio e texto podem transmitir uma informação
igualmente, mas o modo como o texto será interpretado será diferente da forma
como o conteúdo auditivo pode ser recebido e a experiência de acessibilidade será,
portanto, distinta para os usuários. A informação é acessível a todos os grupos, mas
a experiência que a aplicação fornece é sempre múltipla.
Portanto, como não é factual existir uma aplicação totalmente inacessível ou
totalmente acessível, na verdade, o que se tem é um grau de acessibilidade. Sobre
essa consideração, em suma, três afirmações simples são válidas para compreender
o significado disso:
h) Não é viável fazer tudo acessível para todos;
i) É possível fazer conteúdos mais acessíveis para mais pessoas; e
j) O emprego de diferentes padrões resulta em maior ou menor grau de aces-
sibilidade em uma solução.
Além dessas considerações, outro grande centro de discussão sobre
acessibilidade é que, muitas vezes, tornar uma aplicação de software acessível
pode ser uma tarefa interpretada, erroneamente, como árdua, complexa, tediosa,
desmotivadora, ou ainda, como desnecessária. Outro ponto discutível também é que
ser uma aplicação acessível significa ser uma aplicação estática, lenta e simples.
A este respeito, Cunningham (2012) afirma que
Ser acessível não significa descartar quaisquer funções avançadas de seu
site porque alguém está usando um leitor de tela ou pode ter problemas
usando um mouse. Isso não significa um retorno aos dias de páginas Web
sem estilo ou a contratação de um grupo de pessoas dedicadas a fazer
seus produtos acessíveis. Acessibilidade, se mantida firme na mente durante
o desenvolvimento, pode ser obtida sem aumentar significativamente
a sobrecarga de trabalho e pode até mesmo melhorar o seu site para os
usuários padrões.

32
Para amplificar as formas de acesso ao conteúdo de um site ou software em
geral, por exemplo, o esforço empreendido pode resultar em um retorno significativo
não somente na esfera social. Um conteúdo mais acessível pode atingir uma audiência
massiva, pode-se observar inclusive uma adesão maior no número de usuários até
mesmo sem qualquer necessidade especial, os quais passam a vislumbrar outras
formas de acesso como melhorias para adaptar o modo como consumem informação
no dia a dia. Além de inferir a possibilidade de uma mudança na visão sobre produtos
e serviços oferecidos por uma empresa que atende aos padrões de desenvolvimento
acessível e que, assim, passa a faturar mais com um número significativamente maior
de clientes satisfeitos.
Obviamente, os principais benefeciados com uma boa acessibilidade são
aqueles com problemas de visão, audição ou que têm limitações físicas ou cognitivas.
Tal qual a complexidade dos sites foram crescendo, muitos integrantes desses grupos
foram deixados para trás. Tabelas usadas para layout, por exemplo, fizeram como que
leitores de tela não funcionassem como esperado. Layouts complexos recusaram
um desenvolvimento harmonioso e causaram problemas para indivíduos com baixa
visão. Menus drop-down, por exemplo, abateram então a remota possibilidade dos
sites serem navegáveis sem cursor, tornando a navegação na Web quase uma tarefa
impraticável para indivíduos com deficiência motora (CUNNINGHAM, 2012).
Em linha gerais, pode-se enumerar alguns benefícios trazidos pela adoção de
práticas que incorporam acessibilidade em um sistema como:
a) fornecer oportunidades igualitárias;
b) prover maior acesso a informação;
c) proporcionar novas oportunidades de interação; e
d) prover aplicações considerando a relevância dos olhos, ouvidos, controle
motor, percepção de cor e diferentes dispositivos de entradas e interação, entre ou-
tros elementos, na disponibilização do conteúdo que se objetiva transmitir.
Contudo, algumas desvantagens quando se intenciona incorporar acessibilidade
em sistemas, por sua vez, representam considerações como as seguintes:

33
a) existe uma vasta diferença de implementação, para ilustrar, entre navegado-
res, plataformas e leitores de tela;
b) navegadores antigos e leitores de tela não são manipuladores eficazes de
aplicações Web dinâminas;
c) nenhum navegador ou leitor de tela existente consegue implementar e se-
guir totalmente os padrões aceitos; e
d) não há uma documentação clara a respeito do que é suportado em ferra-
mentas de autoração ou mesmo em navegadores populares.
Após a contextualização acima apresentada, antes de prosseguir para o
entendimento de padrões e diretivas, vale ressaltar a diferença entre conceitos muitas
vezes confudidos sobre acessibilidade, usabilidade e independência de dispositivos.
Segundo Loranger e Nielsen (2006), usabilidade é um atributo de qualidade
relacionado com a forma como algo é fácil de usar. Mais especificamente, refere-se a
rapidez com que as pessoas podem aprender a usar alguma coisa, o quão eficientes
elas são ao utilizá-la, o quão memorável seria isso, o quão passível de erro seria isso
e quantos usuários apreciariam utilizá-la. Se as pessoas não podem ou não utilizam
um recurso, ele poderia muito bem não existir.
Contudo, diferentemente do conceito de acessibilidade, é importante perceber
que usabilidade não é uma propriedade única e unidimensional de uma interface de
usuário. Usabilidade tem vários componentes e é tradicionalmente associada a cinco
atributos de usabilidade (NIELSEN, 1994):
a) Aprendibilidade: o sistema deve ser fácil de aprender, para que o usuário
possa rapidamente começar a conseguir fazer algo com ele.
b) Eficiência: o sistema deve ser eficiente para se usar, de modo que, uma vez
que o usuário tenha aprendido o sistema, um alto nível de produtividade seja possível.
c) Memorabilidade: o sistema deve ser fácil de lembrar, de modo que o usuário
casual seja capaz de retornar ao sistema, após algum período não o tendo utilizado,
sem ter que aprender tudo de novo.
d) Erros: o sistema deve ter uma baixa taxa de erro, de modo que os usuários

34
cometam alguns erros durante a utilização do sistema e, quando os cometerem, pos-
sam facilmente se recuperar deles. Além disso, erros catastróficos não devem ocorrer.
e) Satisfação: o sistema deve ser agradável de usar para que os usuários se-
jam subjetivamente satisfeito quando utilizá-lo; assim, os usuários o apreciam.
Portanto, podemos concluir que usabilidade se destina ao design de aplicações
que sejam, por exemplo, mais efetivas, eficientes, satisfatória para todos e não
necessariamente apenas mais acessíveis.
Por outro lado, independência de dispositivo, tende a significar a simples
adaptação de um layout para atender a diferentes tamanhos, tipos e resoluções de
telas, como mencionando. Corresponde, sim, a uma forma de amplificar acesso, mas
não seria possível afirmar que isso permitiria que um sistema adaptado a uma nova
resolução teria agora um layout que provê formas de ser utilizado por indivíduos com
deficiência de modo tão eficaz quanto pelos que não têm deficiência.
Além disso, a independência de dispositivo pode dizer respeito à tecnologia
envolvida, que permite que uma aplicação esteja disponível em diferentes dispositivos
ou plataformas, enquanto que a aplicação, em essência, pode permanecer inalterada
e, nesse caso, em quase nada, a independência contribuiria para eliminar problemas
enfrentados por indivíduos com deficiência que utilizariam o sistema independente.
Portanto, acessibilidade não é tornar uma aplicação compatível com aparelhos
com resoluções e telas menores ou maiores, com versões antigas de navegadores,
etc. Acessibilidade preocupa-se em eliminar questões que colocam indivíduos com
deficiência em um ponto de desvantagem.

35
3 DIRETIVAS E COMPLACÊNCIA A PADRÕES E CONVENÇÕES
De acordo com Loranger e Nielsen (2006), a definição de padrões e convenções
representa um direcionamento essencial para eliminar elementos ininteligíveis do
design de um site. Assim, incentiva-se o estabelecimento de padrões de design,
se possível, para cada tarefa importante de um website. Uma vez que os padrões
melhoram o senso de domínio dos usuários sobre um site, os auxiliam na conclusão
de tarefas e aumentam a satisfação geral em relação a um site.
Como razões gerais para padrões de elementos de design, tem-se que as
normas asseguram que o usuário (LORANGER e NIELSEN, 2006):
a) Conheça que recursos dispõe;
b) Saiba como esses recursos vão aparecer na interface;
c) Saiba onde encontrar esses recursos no site e na página;
d) Saiba como operar cada recurso para atingir seu objetivo;
e) Não precise ponderar o significado de elementos de design desconhecidos;
f) Não perca características importantes por excessivamente analisarem um
elemento de design que não é padrão;
g) Não tenha surpresas desagradáveis quando algo não funciona como esperado.
Segundo Osborn e Smith (2014), alguns dos benefícios para a criação de páginas
bem estruturadas incluem ainda:
a) Acessibilidade: documentos da Web marcados semanticamente, ou seja,
aqueles que usam a melhor tag HTML para o trabalho, podem ser mais fáceis de
navegar por usuários com deficiência visual e as informações que eles contêm tor-
nam-se mais prováveis de serem encontradas por visitantes do site.
b) Compatibilidade de dispositivos: sites que separam a estrutura do estilo são
mais facilmente reaproveitados por dispositivos móveis e outros navegadores. Para
ilustrar, o CSS também permite que folhas de estilo alternativas otimizem a aparência
de uma página com base no dispositivo que está sendo usado para visualizá-la.
c) Menos código: usando HTML e CSS é possível criar páginas idênticas com
menos linhas de código - menos sobrecarga de trabalho para o desenvolvedor e me-

36
nor tempo de carregamento para o usuário, para ilustrar, criando-se um arquivo CSS
único para reunir códigos que poderiam repetir-se caso fossem inseridos em diferen-
tes páginas HTML considerando resultados idênticos no aspecto visual.
d) Facilidade de manutenção: com menos código, isso significa que o site pode
ser mais fácil de manter, pois, dada a redução na quantidade de código a ser mantido,
colabora-se beneficamente para simplificar a manutenção ou revisão de um site.
e) Search Engine Optimization (Otimização para Motores de Busca): páginas
da Web com seções claras e nomeadas logicamente, tanto dentro do código quanto
também no conteúdo da página, são mais fáceis de serem indexadas e classificadas
pelos motores de busca, porque o conteúdo que é organizado e bem marcado é mais
facilmente avaliado em relação ao conteúdo e à respectiva relevância dele na página.
Nesse contexto, Loranger e Nielsen (2006) relacionam padrões, convenções e
confusões quanto à percepção do usuário:
a) Padrão: 80% ou mais dos sites usam um tipo de concepção igual. Os usuá-
rios esperam fortemente que elementos padrões funcionem de certa maneira quando
eles visitam um novo site, pois é assim que quase sempre tudo funciona.
b) Convenção: cerca de 50 a 79% dos sites utilizam uma abordagem de design
semelhante. Os usuários esperam que elementos convencionais funcionem de certo
modo quando visitam um novo site, porque é assim que tudo funciona normalmente.
c) Confusão: com estes elementos, nenhuma abordagem é dominante e até
mesmo a abordagem mais popular é usada por menos da metade dos sites. Assim,
para tais elementos de design, os usuários não sabem o que esperar quando eles
visitam um novo site.
3.1 PADRÕES DO W3C
O World Wide Web Consortium (W3C), o Consórcio da Rede Mundial de
Computadores, é a principal organização mundial encarregada do desenvolvimento
de padrões para Web.
De acordo com o próprio W3C (2014):
O World Wide Web Consortium é uma comunidade internacional em que
organizações associadas, equipes de profissionais de tempo integral, bem

37
como o público trabalham em conjunto para desenvolver padrões para Web.
Liderada pelo inventor da Web Tim Berners-Lee e o CEO Jeffrey Jaffe, a
missão do W3C é levar a Web ao seu potencial máximo.
Existem vários padrões propostos pelo consórcio com foco em acessibilidade,
dentre os principais estão:
a) Accessible Rich Internet Applications (ARIA): que define tecnologias para
criar aplicações Web dinâmicas e mais acessíveis.
b) Web Content Accessibility Guidelines (WCAG): que apresenta diretivas para
a criação de websites acessíveis.
c) Authoring Tool Accessibility (ATAG): diretivas para o desenvolvimento de fer-
ramentas de autoração que encoragem e apoiem desenvolvedores no fomento da
produção de websites acessíveis.
d) User Agent Accessibility Guidelines (UAAG): diretivas para desenvolvedores
de navegadores, players de mídia, etc, que possam facilitar um uso acessível.
3.2 WAI-ARIA
Para Levinson e Schlatter (2013), enquanto a acessibilidade se concentra
em fornecer recursos para garantir sites e aplicações funcionais utilizáveis para
deficientes, os princípios trabalhados para assegurá-la se aplicam também para
todos os outros usuários.
Segundo Hogan (2013), Web Accessibility Initiative - Accessible Rich Internet
Applications (WAI-ARIA) é uma especificação que fornece formas de melhorar a
acessibilidade de aplicações Web e reduzir o sofrimento com que os usuários de
tecnologia assistiva frequentemente se deparam.
De acordo com o W3C (2013), o WAI-ARIA é uma especificação técnica para
tornar conteúdo dinâmico e interativo da Web acessível a pessoas com deficiência.
Este trabalho não se propõe a abordar os aspectos e benefícios que a WAI-ARIA
fornece em profundidade e, uma vez que ela encontra-se em contínuo processo de
melhorias, a consulta à recomendação apresentada pelo W3C representa a melhor
forma de elucidar com detalhamento todos os elementos pontuados como relevantes
para tornar acessível o conteúdo de páginas da Web.

38
Portanto, o objetivo aqui é entender que todos se beneficiam com a adoção da
especificação durante o processo de desenvolvimento e que, por conseguinte, uma
navegação funciona de forma consistente, por exemplo, onde campos de formulário
se comportam de igual maneira, por se ter incorporado um conjunto reduzido de
ferramentas de interação que agem para garantir que tudo funcione tal qual os
usuários esperam. Assim, seguir diretrizes WAI para previsibilidade e consistência
resulta em uma melhor experiência para cada indivíduo que uma aplicação atende.
O HTML5 e a especificação WAI-ARIA abriram o caminho para uma Web muito
mais acessível. Com a capacidade de identificar regiões que são objeto de mudanças
em uma página, os desenvolvedores podem criar aplicações JavaScript mais ricas
sem se preocuparem tanto com as questões de acessibilidade. Graças à facilidade
de uso, essas novas possibilidades estão sendo incluídas nos frameworks JavaScript
mais populares, como Ember, jQuery Mobile, entre outros, o que significa que os
desenvolvedores que usam esses frameworks estarão automaticamente construindo
aplicações mais acessíveis (HOGAN, 2013).
3.3 WEB CONTENT ACCESSIBILITY GUIDELINES
Em relação à WCAG 1.0, as técnicas recomendadas compreendeem 14 aspectos
que ramificam-se em sub-recomendações, pontos que ressaltam ou esclarecem
como a diretiva pode ser atingida na íntegra.
A segunda versão das Diretivas de Acessibilidade para Conteúdo da Web,
Web Content Accessibility Guidelines (WCAG 2.0), por sua vez, tornou-se uma
recomendação W3C em 2008 e pode ser resumida como doze diretrizes seguindo
quatro princípios – Percepetível, Operável, Inteligível e Robusto (SIKOS, 2011):
a) Princípio 1: Perceptível – Componentes de interface do usuário e informa-
ções publicadas perceptíveis para todos.
1. O texto alternativo deve ser fornecido para conteúdo não textual, tornando
possível transformá-lo em outras formas.
2. Multimídia baseada no tempo deve ter formas alternativas.
3. Conteúdos da Web devem estar disponíveis através de diferentes formas de

39
apresentações sem perder informação ou estrutura.
4. Conteúdos visuais e auditivos devem ser fáceis de distinguir.
b) Princípio 2: Operável – Interface de usuário operável e navegação utilizável.
5. Toda funcionalidade deve estar disponível a partir do teclado.
6. Os usuários não podem ser forçados a realizar ações dentro de prazos.
7. Designs que podem provocar convulsões devem ser evitados.
8. Orientação e ajuda devem ser fornecidos para que os usuários naveguem
através do site.
c) Princípio 3: Inteligível – Conteúdo compreensível e operação da interface do
usuário.
9. Conteúdo textual deve ser conveniente de ler e fácil de entender.
10. Operação e surgimento do conteúdo devem ser previsíveis.
11. Deve ser fornecida assistência para que os usuários evitem, localizem e
corrijam erros.
d) Princípio 4: Robusto – Conteúdo robusto com alta interoperabilidade que
pode ser usado de forma confiável em qualquer tipo de agente de usuário, incluindo
tecnologias assistivas.
12.Acompatibilidadedevesermaximizadacomosagentesdeusuárioetecnologia
assistiva atuais e futuros, incluindo aqueles que funcionam com recursos limitados.
Dada a importância deste padrão para o estudo aqui apresentado, sugere-se a
visita à página da íntegra das WCAG 2.0 para eventual consulta.
3.4 BOAS PRÁTICAS PARA PROMOÇÃO DE ACESSIBLIDADE
De modo prático, essas diretivas podem ser traduzidam na forma de instruções
de boas práticas para o desenvolvimento de páginas da Web.
O seguinte apanhado traz alguns procedimentos que representam o efetivo
emprego da complacência a padrões sob a forma de boas práticas para a promoção
de acessibilidade de acordo com autores como Connor (2012), Cunninghan (2012) e
Nielsen (1999):
a) Atribuir um identificar único title para cada página, assim, os usuários

40
podem localizar-se em relação a que ponto se encontram dentro do site.
b) Criar páginas alternativas que utilizem uma folha de estilo diferente para dar
suporte a recursos adicionais como alto contraste.
c) Não utilizar tabelas para layout de página. Usar CSS para posicionar itens.
Layouts baseados em tabelas não são adequados para usuários com deficiência. A
maioria dos avaliadores de conformidade automatizados os rejeitam, porque não se
consegue diferenciar dados tabelados de layout com tabelas.
d) Organizar as páginas para que elas possam ser lidas em uma sequência ló-
gica, principalmente para quando as folhas de estilos são desabilitadas por usuários
que assim necessitam.
e) Certificar-se de que a tag html contém uma especificação de linguagem
para que o leitor de tela possa interpretar a página corretamente. Por exemplo, html
lang=“pt-br” para português do Brasil.
f) Evitar o uso de arte empregando ASCII, como o uso, por exemplo, dos sím-
bolos “menor que” () e “maior que” () para apontar para algo. Os leitores de tela le-
rão o significado desse símbolos, que é “menor que” ou “maior que”. Ao invés disso,
use uma seta Webding (fonte núcleo para a Web) ou algum texto substitutivo.
g) Não utilizar pop-ups ou janelas modais sem que o usuário seja primeira-
mente alertado sobre isso.
h) Ao fornecer informações em formato PDF (Portable Document File), forne-
cer também informações em uma alternativa e formato acessível (por exemplo, HTML
ou texto) ou fornecer links para as ferramentas fornecidas no site da Adobe. Vale sa-
lientar que a Adobe está continuamente melhorando o formato PDF para que ele seja
cada vez mais acessível através de leitores de tela.
i) Evitar JavaScript para navegação e uso em outros botões que não sejam
“Imprima esta página”, “Favorite esta Página” e funções como “Retorne à página
anterior”, os quais são exemplos aceitáveis apenas porque duplicam funções que
estão disponíveis em todos os navegadores. Todas as imagens que transmitem in-
formações úteis devem conter dicas usando ferramentas como o alt e title. Em se

41
tratando de imagens que são puramente decorativas e que, portanto, não transmitem
qualquer informação útil, o uso correto do alt/title seria um alt vazio (alt = “”) e um
título vazio (title = “”). Uma vez que os leitores de tela não lêm alt ou title vazios.
j) Botões gráficos em menus são acessíveis na medida em que o texto do title/
alt descreva a finalidade de cada um deles.
k) Texto representado por meio de uma imagem é inútil, porque os leitores de
tela não podem lê-lo. Caso seja necessário utilizar uma imagem que contém texto,
certificar-se de incluir uma dica com o atributo “alt” que forneça o texto correspon-
dente para o leitor de tela.
l) Adicionar um menu duplicado, se necessário, e links para “Voltar ao topo”
em intervalos espaçados nas páginas mais longas.
m) Não utilizar em excesso botões de rádio (radio buttons) e caixas de seleção
(checkboxes), pois eles tornam um formulário mais difícil de completar.
n) Para ajudar as pessoas com tremores nas mãos, garantir um espaço ade-
quado entre os campos, caixas de seleção, botões do menu e botões de rádio.
o) Menus drop-down em JavaScript são inacessíveis para os usuários de lei-
tores de tela. Entretanto, os menus drop-down em PHP ou ASP são tradicionalmente
acessíveis para os leitores de tela.
p) Assegurar que links e elementos interativos da página sejam facilmente na-
vegáveis utilizando o teclado, por exemplo, criando uma lógica ordenada para a tecla
Tab. A tecla Tab deve fornecer uma sequência lógica para o benefício dos usuários
com deficiência que não conseguem utilizar um mouse. A ordem de tabulação pa-
drão é lógica, portanto, não a modificar se não for para assegurar essa ordem.
q) Certificar-se de que os vídeos têm legendas para que os surdos possam
entendê-los e também apreciá-los.
r) Ter absoluta certeza de que os clipes de áudio e vídeo não são autostart
(iniciados automaticamente) ou onmouseover (ao passar do mouse). O barulho re-
pentino pode causar trauma aos usuários cegos ou amblíopes. Sempre usar onmou-
sedown (iniciar com o precionamento do mouse) como forma de iniciar a reprodução

42
de um clipe de áudio ou vídeo e fornecer uma explicação e um aviso.
s) Adicionar um link para “Ir para o conteúdo principal” no início de cada pági-
na (excetuando talvez a página inicial) para que o usuário de leitor de tela possa pular
direto para o conteúdo e não ter que se arrastar repetidamente através dos menus
de navegação. Alguns designers fazem isso colocando um link tradicional ou uma
imagem no início de cada página com o texto “Ir para o conteúdo principal”2
. Assim,
fazendo o link saltar para uma âncora (marcador) no início do conteúdo principal.
t) Fornecer prévias de todos os objetos multimídia em páginas HTML simples.
No caso de vídeos, muitas vezes é uma boa idéia incluir uma ou duas fotos que re-
presente o conteúdo. Além disso, tanto para áudio quanto vídeo, disponibilizar um
pequeno resumo do que o usuário vai ouvir ou ver.
u) Por fim, usar sempre linguagem clara e simples.
3.5 LEGISLAÇÃO
Talvez o mais importante instrumento de lei existente em favor da acessibilidade
seja a Seção 508, que se baseia, por exemplo, nas recomendações presentes nas
Web Content Accesbility Guidelines do W3C.
Em 1998, o congresso americano aprovou uma emenda à Lei de Reabilitação
(Rehabilitation Act), exigindo que todos os sites criados para o governo dos Estados
Unidos fossem acessíveis a todos, apesar das limitações individuais. Esta alteração
foi a Seção 508 e, muitas vezes, a acessibilidade na Web nos Estados Unidos pode
inclusive ser referida como “o cumprimento da 508”. Enquanto o ato original (aprovado
em 1973) tinha a própria seção 508 no que diz respeito à tecnologia, ela não tinha
profundidade até 1998, quando foram introduzidas as normas de complacência a
padrões. Determinou-se então que qualquer site pago por fundos federais deveriam
seguir os requisitos estabelecidos naquela alteração (CUNNINGHAM, 2012).
Sob o prisma da acessibilidade, a legislação brasileira apresenta poucos
mecanismos para assegurar acessibilidade na Web.
A Lei n° 10.098, de 19 de dezembro de 2000, iniciou a batalha por uma legislação
2 Certifique-se de que o texto não é “Ir para o conteúdo” e, sim, “Ir para o conteúdo principal”, o que
pode ser considerado um padrão em acessibilidade.

43
que tente incluir medidas para tornar acessibilidade algo a natural e inerentes a todas
as páginas da Web. Neste contexto, o seguinte fragmento traz os artigos que são os
mais significativos para a acessibilidade.
DA ACESSIBILIDADE NOS SISTEMAS DE COMUNICAÇÃO E SINALIZAÇÃO
Art. 17. O Poder Público 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, para garantir-lhes o
direito de acesso à informação, à comunicação, ao trabalho, à educação, ao
transporte, à cultura, ao esporte e ao lazer.
Art. 18. O Poder Público implementará a formação de profissionais intérpretes
de escrita em braile, linguagem de sinais e de guias-intérpretes, para facilitar
qualquer tipo de comunicação direta à pessoa portadora de deficiência
sensorial e com dificuldade de comunicação.
Art. 19. Os serviços de radiodifusão sonora e de sons e imagens adotarão
plano de medidas técnicas com o objetivo de permitir o uso da linguagem de
sinais ou outra subtitulação, para garantir o direito de acesso à informação
às pessoas portadoras de deficiência auditiva, na forma e no prazo previstos
em regulamento.
Comoéimportantenotar,aleinãodeixaclarocomofaráparaimplementaraformação
de profissionais intérpretes ou o que poderia compor o plano de medidas técnicas quanto
aos serviços de radiodifusão sonora e de sons e imagens. Entretanto, representa um
entendimento do significado de medidas para promover a acessibilidade na sociedade
globalizada e envolta em tecnologia contemporânea.
Por fim, analisando o Art. 17, nota‑se que a partir desse momento, inicia-se um
processo da promoção da acessibilidade no que diz respeito ao acesso ao computador
e a acessibilidade ao conteúdo propriamente dito nas páginas Web, quando menciona o
direito de acesso à informação; entretanto, nenhum padrão, por exemplo, é reinforçado
para realizar um coerente direcionamento pela lei para o mercado.
3.6 FONTES DE RECURSOS SOBRE ACESSIBILIDADE
Vale a pena ressaltar ainda algumas fontes de recursos que são amplamente
reconhecidas sobre acessibilidade:

44
Quadro 1 – Recursos gerais para acessibilidade.
SITE URL DESCRIÇÃO
Página oficial
do W3C sobre
acessibilidade
http://www.w3.org/
standards/webdesign/
accessibility
Enumeração de pontos que
justificam a importância de se
empreender acessibilidade.
WebAIM http://webaim.org/
Artigos, ferramentas e
serviços para tornar websites
acessíveis.
Penn State
AccessAbility
http://accessibility.psu.edu/
Acessibilidade e usabilidade
pela Penn State. Inclue artigos
e exemplos práticos para
tornar websites acessíveis.
Ato para a
Comunicação e
Acessibilidade no
Século 21
http://transition.fcc.gov/cgb/
dro/cvaa.html/
Lei norte-americana relativa
à seção 508, que versa
sobre acessibilidade, com
foco em novas tecnologias.
Expande‑se para além do
campo federal, para produtos
de consumo.
Site oficial do
governo americano
para a Seção 508
http://www.section508.gov/
Contém as leis e políticas
em torno da complacência à
Seção 508.
Fonte: Cunningham (2012).

45
4 TECNOLOGIAS ASSISTIVAS
Para a realização da análise da acessibilidade das aplicações conforme a WCAG
2.0, faz-se importante o entendimento sobre as denominadas Tecnologias Assistivas
que aqui são exploradas e esclarecidas.
Acessibilidade afeta a todos. Design de interface pode aleijar ou dar poder aos
usuários. Pessoas com capacidades normais podem ser prejudicadas por interfaces
complicadas tão qual as pessoas com deficiência podem ser liberadas por sites
bem desenhados. Para ser acessível, um site deve ser acessível por públicos com
diferentes níveis de habilidades.
Um site acessível é aquele que remove os obstáculos que ficam no caminho
das pessoas; remover o obstáculo supera a deficiência. Por exemplo, permitir que
as indivíduos com deficiência visual possam redimensionar textos resulta em melhor
legibilidade, eliminando assim a deficiência visual, apesar da capacidade visual do
indivíduo permanecer inalterada.
Loranger e Nielsen (2006) destacam que:
Não devemos assumir que todas as pessoas que são deficientes visuais
usam tecnologia assistiva. Deficiências visuais tratam de uma extensa gama
da cores, da visão reduzida a nenhuma percepção de luz. Os usuários no
extremo mais suave do espectro não podem exigir tecnologia assistiva, mas
precisam da capacidade de poder redimensionar o texto para conseguirem
ler. Mesmo as pessoas com boa visão, por vezes, precisam aumentar o
tamanho do texto, especialmente quando utilizam telas com configurações
de baixa resolução.
A gravidade e grau de deficiência visual geralmente aumentam com a idade.
Uma vez que a população envelhece, isso vai se tornando cada vez mais um problema
notadamente comum em Web design. Segundo o Relatório Mundial da Deficiência
(OMS, 2011), “todos nós em algum momento de nossas vidas teremos algum grau
de deficiência visual”.
Como forma de minimizar os impactos que as condições de deficiência impõem,
surgem as Tecnologias Assistivas ou Tecnologias de Apoio.
A gama de dispositivos e controles de Tecnologia Assistiva (TA) é muito variada,
assim como o número de definições para esse termo. A Sociedade de Esclerose

46
Múltipla Nacional do Estados Unidos (apud CONNOR, 2012) define Tecnologia
Assistiva como “um termo usado para descrever todas as ferramentas, produtos e
dispositivos, desde o mais simples ao mais complexo, que pode fazer uma função
particularmente mais fácil ou possível de se realizar”.
Dentre as principais Tecnologias Assistivas (ATs) amplamente utilizadas ou que
estão facilmente disponíveis para a maioria dos usuários, o conjunto de soluções
que inclui o emprego de recursos de hardware e/ou software indicado abaixo oferece
uma visão geral do que está ao alcance dos indivíduos que necessitam de AT para
interagir com aplicações e, assim, representa a demanda inicial a ser atendida em
projetos de amplificações de acesso:
a) Leitores de tela e lupas ou amplificadores (Para indivíduos com diferentes
graus de deficiência visual ou cegos.);
b) Displays Braille atualizáveis (Para indivíduos com deficiência visual.);
c) Softwares de legendagem (Para indivíduos com deficiência auditiva.);
d) Software de reconhecimento de voz, interruptores, apontadores e telas sen-
síveis ao toque (Para indivíduos com deficiência motora.).
Neste capítulo, será apresentada uma análise mais aprofundada de alguns dos
principais recursos que foram acima mencionados e que abrangem TAs essenciais
para serem conhecidas quando se infere um desenvolvimento que incorpora
acessibilidade como elemento inerente.
Contudo, além dessas ATs, algumas soluções podem compreender adaptações
destinadas a permitir a facilitação do acesso ao conteúdo disponível que são baseadas
em tecnologias corriqueiramente utilizadas, dentre elas estão:
e) Navegação apenas pelo teclado;
f) Navegação apenas empregando o mouse;
g) Alterações nos tamanhos das fontes do sistema operacional, aplicações
(caso a opção seja disponibilizada) e do navegador;
h) Alterações do tamanho de janelas e/ou opções de zoom;
i) Alterações nas configurações de cores;

47
j) Utilização de Cascading Style Sheets (CSS) especial; etc.
4.1 SOFTWARES DE LEITURA DE TELA
Os leitores de tela são uma das mais populares tecnologias de assistência
utilizadas. Quando as pessoas pensam sobre leitores de tela, a deficiência que
primeiro vem à mente é a cegueira.
Uma pesquisa realizada pela WebAIM, em janeiro de 2009, mostra que a
cegueira não é a única deficiência que utiliza leitores de tela (HALL e MCWHERTER,
2009). Dos indivíduos pesquisados as seguintes percentagens retratam a respectiva
utilização dos leitores de tela:
Tabela 1 – Utilização de leitores de tela por grupo de usuário.
GRUPO %
Cegueira total 80,1
Baixa visão / deficiência visual 15,8
Cognitiva 0,7
Surdez / dificuldade de audição 4,2
Deficiência motora 2,1
Ausência de incapacidade 5,4
Fonte: Hall e McWherter (2009).
JAWS®
, acrônimo de Job Access with Speech (‘Acesso a Trabalho com Ditado’,
tradução do autor), é o software leitor de tela líder mundial na plataforma Windows.
Como a ferramenta mais popular desenvolvida para usuários de computador cuja
visão sofre interferência para visualização de conteúdo na tela ou navegação com o
mouse, JAWS®
ainda fornece saídas de voz e Braille para as aplicações mais comuns
no PC (FREEDOM SCIENTIFIC, 2014).
JAWS®
fornece instalação com narração, acesso ao texto presente em qualquer
imagem na tela por meio de Optical Character Recognition (OCR), ou Reconhecimento
Óptico de Caracteres, vozes em 30 línguas diferentes, incluindo português,

48
customização da UX através de linguagem de script que permite programar novas
funcionalidades e integrá-las ao software.
Alguns outros softwares populares de leitura de tela são:
a) NVDA, NonVisual Desktop Access (Windows);
b) Orca (Linux);
c) VoiceOver (Mac OS); e
d) ChromeVox (Chrome OS).
4.2 DISPLAY BRAILLE
Display Braille é um hardware que exibe dinamicamente em Braille a informação
da tela do computador.
De acordo com Sant’Anna apud Queiroz (2008), pode-se definir Display Braille
como um dispositivo de saída tátil para visualização de letras no sistema Braille, onde,
por intermédio de um sistema eletro-mecânico, conjuntos de pontos são levantados
e abaixados, conseguindo-se, assim, uma linha de texto em Braille que transcreve o
documento visualizado.
Em geral, contam com diversas funções para controlar diretamente a navegação
e, em muitos casos, executar comandos do leitor de tela ou do Windows. Além disso,
existem Displays Braille tanto para computadores quanto para dispositivos móveis
que podem ser acopláveis ou embutidos.
Os atuais displays possuem dimensões que vão desde uma única célula (de
seis ou oito pontos) até linhas de 80 células. A maioria comporta entre doze e vinte
células por linha. Sua utilização é feita principalmente por indivíduos surdos-cegos,
que podem superar a ausência ou dificuldade de audição e visão através do tato.
Infelizmente, é um tipo de dispositivo pouco usado no Brasil devido ao seu alto custo
– os mais simples e baratos ultrapassam os cinco mil dólares.
4.3 SOFTWARE DE LEGENDAGEM
Uma excelente opção para quem necessita trabalhar com áudio e/ou
vídeo é fornecer legendas para os conteúdos multimídia. Vale considerar que,
preferencialmente, essas legendas não devem estar embebidas no vídeo, por

49
exemplo, elas devem funcionar como recurso dissociável. Assim, estando disponível
a função para desabilitá-las quando o usuário desejar.
Ao montar legendas para vídeos, nem sempre é fácil adicioná-las de forma
sequencial e, somado a isso, poucos programas possuem esta funcionalidade. Neste
contexto, o Subtitle Workshop é uma das mais completas e eficazes ferramentas de
edição de legendas. Recomendado pelo fórum de ajuda do YouTube, o software
suporta todos os formatos de legenda padrões e com todas as funções para realizar
a tarefa de legendagem. A interface amigável e intuitiva facilita o acesso a vários
menus de configuração com uma metodologia rápida e estável para edição. Além
disso, o Subtitle Workshop permite alterar, por exemplo, a cor de fundo das legendas
e, além disso, inclui verificação gramatical e ortográfica (KIOSKEA, 2014).
4.4 RECONHECIMENTO DE VOZ
Indivíduos com deficiências em mobilidade e destreza utilizam-se de software
de reconhecimento de voz para facilitar o modo como interagem, por exemplo,
com páginas da Web. Ditado e comandos de controle são algumas das operações
fundamentais que ferramentas de reconhecimento de voz oferecem.
Dragon®
NaturallySpeaking®
é o software mais comum de reconhecimento de
voz para desktop em uso pelos consumidores hoje (FEATHERSTONE, 2014).
O software possibilita abrir programas com comandos simples como “open
Firefox” (abrir o Firefox), escolher comandos de menu, clicar em links, mover o
cursor, formatar texto (“highlight ‘The New York Times’”, grifar ‘The New York Times’)
e assim por diante (DUFFY, 2012). Além disso, comandos como “scroll up” (rolar para
cima), “scroll down” (rolar para baixo), “go back” (voltar) ou “reload page” (recarregar
página), por exemplo, facilitam a navegação e a forma como usuários interagem com
as páginas e o browser (Ver “ANEXO A – NAVEGAÇÃO PELO SITE DO GOOGLE
MAPS UTILIZANDO O DRAGON®
NATURALLYSPEAKING®
.” na página 139 para
exemplo de utilização do software).
Para título de análise dessa ferramenta de reconhecimento de voz, em suma,
de acordo com o portal PC Mag.com, os seguintes pontos positivos e negativos são

50
apontados em relação ao software:
Quadro 2 – Prós e contras do software de reconhecimento de voz Dragon®
NaturallySpeaking®
Premium.
PRÓS CONTRAS
Ditado altamente preciso. Rápido.
Ditado e edição intuitivos. Excelente
tutorial de treinamento. [...]
Curva de aprendizagem moderada,
especialmente com comandos de voz.
Atualização das versões 10 ou 11 é
relativamente cara.
Fonte: Duffy (2012).
Os pontos levantados servem para ilustrar que, apesar da existência de softwares
eficientes para proporcionar uma UX significante e inclusiva, fatores como custo3
,
disponibilidade em outros idiomas e processo para aprofundamento na utilização
da solução são requeridos e isso, muitas vezes, torna a ferramenta, infelizmente,
exclusiva e longe do alcance da grande maioria dos usuários com deficiência.
3 Em setembro de 2014, o preço comercial da licença do software Dragon®
NaturallySpeaking®
Premium versão 13 equivalia a US $ 199.99 e, apenas a atualização, a US $ 149.99.

51
5 TESTES E ANÁLISE DE ACESSIBILIDADE WEB
Segundo Hall e McWherter (2009), testes devem estender o modo como os
desenvolvedores produzem código. O desenvolvimento de software requer a
verificação de que o código produzido corresponda ao que se espera que ele
realmente faça. Esta verificação pode ser feita manualmente ou por meio de testes
automatizados. Ao verificar que o código atende às próprias suposições, torna-se
fácil remover ou resolver erros com pouco esforço. Isso resulta em um número de
bugs menor e em um software de alta qualidade para o usuário final .
Ainda que alguns testes possam ser realizados com usuários sendo observados
enquanto utilizam uma aplicação Web, como tradicionais testes de usabilidade,
alguns procedimentos podem ser feitos preditivamente, assim, antes que a aplicação
seja realmente utilizada pelos usuários finais, para assegurar uma amplificação de
acesso ao seguir recomendações básicas e simples (WEST, 2012).
a) Validar o código da página Web no site de validação onlinde da W3C http://
validator.w3.org.
b) Percorrer o conteúdo com o cursor e posicioná-lo em cada imagem e link
para verificar se tool tips, alts e titles são exibidos corretamente.
c) Silenciar o volume e analisar se qualquer conteúdo auditivo tem equivalente
textual facilmente disponível.
d) Ampliar o dimencionamento da janela do navegador, alterar o zoom e au-
mentar as fontes para verificar se a página ainda se mantém viável e compreensível.
e) Redimencionar a janela do navegador para reduzir o tamanho ocupado na
tela como forma de observar se o conteúdo satisfatoriamente pode ser exibido em
dispositivos com resoluções menores.
f) Assegurar que o usuário não necessita rolar horizontalmente uma significante
parcela da página para visualizar o conteúdo em dispositivos com baixas resoluções.
g) Utilizar listas ordenadas e não ordenadas apropriadamente.
h) Checar se os títulos ou texto dos menus e links indicam claramente o res-
pectivo destino que representam.

52
i) Verificar, utilizando a tecla tab se a navegação através dos links pode ser
totalmente realizada com a utilização apenas do teclado.
j) Assegurar o emprego de textos simples, claros e concisos em cabeçalhos
informativos utilizados para fracionar o conteúdo escrito da página.
k) Remover elementos que piscam ou brilham, inclusive marquees.
l) Assegurar que nenhum áudio e vídeo iniciam com o carregamento da página
ou ao se posicionar o mouse sobre o respectivo elemento.
5.1 ACCESSIBILITY DEVELOPERS TOOLS
A ferramenta de auditoria de acessibilidade para desenvolvedores fornecida
pelo Google, Accessibility Developer Tools4
, possui recursos importantíssimos para
identificar rapidamente problemas com uma página da Web. Essa ferramenta faz
parte de um conjunto de teste de acessibilidade para desenvolvedores que inclui
ainda os softwares/extensões disponíveis no navegador Chrome:
a) ChromeVox - leitor de tela;
b) ChromeVis - amplificador para indivíduos com baixa visão;
c) ChromeShades - ferramenta para teste de acessibilidade no navegador.
Por sua vez, a Accessibility Developer Tools realiza uma auditoria simplificada
de páginas sobre a perpectiva de acessibilidade.
Quadro 3 – Auditoria do Accessibility Developers Tools.
Categoria da audição Checam por
Rótulos (labels) e conteúdos alternativos
Imagens e rótulos dos campos de
formulários.
Acessibilidade pelo teclado Controles de foco da UI
ARIA
Validade dos papeis (roles) dos
elementos da aplicação
4 Um exemplo de utilização desta ferramenta será demonstrado na análise do estudo de caso.

53
Categoria da audição Checam por
Acessibilidade para baixa-visão
Grau de contraste entre plano de
frente e plano de fundo (foreground/
background)
Acessibilidade de vídeo Legendas e conteúdo alternativo
Fonte: Elaboração do autor.
5.2 FERRAMENTAS PARA TESTE DE ACESSIBILIDADE
O quadro a seguir apresenta algumas das ferramentas pesquisadas que podem
ser consideradas como referência para testes de acessibilidade em aplicações Web.
Quadro 4 – Ferramentas online para teste de acessibilidade5
.
Ferramenta Descrição
Contrast-A
http://www.dasplankton.de/ContrastA/
O aplicativo permite aos usuários
experimentar combinações de cores,
examiná-las sob o aspecto de diretrizes
de acessibilidade e criar paletas de
cores personalizadas e acessíveis.
Color Filter
http://colorfilter.wickline.org/
A aplicação permite visualizar páginas
utilizando filtros que simulam diferentes
problemas visuais relacionados à
percepção de cores.
Etre
http://www.etre.com/tools/
colourblindsimulator/
Permite simular problemas de
percepção de cor em imagens, sendo
interessante para aplicar testes sob
imagens de protótipos de páginas.
5 Uma lista completa de sugestões da W3C com muitas outras ferramentas pode ser encontrada no
site http://www.w3.org/WAI/ER/tools/complete.

54
Ferramenta Descrição
Sim Daltonism
http://michelf.ca/projects/sim-daltonism/
Simulador de problemas visuais
para ambiente Mac e que permite
uma simulação em tempo real,
enquanto se desenvolve utilizando um
software de autoração por exemplo,
para visualizar a área próxima ao
cursor com diferentes tipos de
resultado de percepção de cores.
AChecker (WCAG 1.0, Section 508,
Stanca Act, BITV)
http://achecker.ca/checker/
Verifica páginas HTML individuais
quanto a conformidade com os padrões
de acessibilidade para garantir que o
conteúdo pode ser acessado por todos.
Wave (WCAG 1.0, Section 508)
http://wave.webaim.org
Ferramenta de análise de complacência
a padrões em páginas da Web.
Fonte: Elaboração do autor.

55
6 ESTUDO DE CASO SOBRE A ANÁLISE DA COMPLACÊNCIA ÀS DIRETIVAS DE
ACESSIBILIDADE PARA CONTEÚDO WEB
Estecapítuloapresentaametodologiadoestudodecasorealizadocomoobjetivo
de analisar a complacência às diretivas do padrão WCAG 2.0 em duas aplicações
desenvolvidas para Web. A Seção 6.1 expõe mais detalhes sobre a configuração do
estudo de caso. A Seção 6.2 apresenta os objetivos gerais que contempla o estudo.
A Seção 6.3 descreve as aplicações Web objeto de análise e enumera as páginas
analisadas. Por fim, a Seção 6.4 define os critérios examinados e verificações a serem
realizadas considerando os aspectos levantados acerca da utilização de ferramentas
de teste, análise e validação, boas práticas, tecnologias assistivas e entendimento
das diretivas do WCAG 2.0.
6.1 CONFIGURAÇÃO DO ESTUDO
Sob a perspectiva de realização de uma análise em estudos de caso, para
tanto, como forma de direcionar para uma abordagem eficiente e eficaz no campo
da promoção da acessibilidade na Web, o experimento verificará a complacência
das aplicações à Diretriz de Acessibilidade de Conteúdo Web 2.0, Web Content
Accessibility Guideline 2.0, WCAG 2.0, disponibilizada pelo W3C, utilizando os
recursos até aqui explorados e discutidos para analisar cada diretiva dentro dos
quatro princípios empregados na WCAG 2.0.
Para que uma página Web esteja em conformidade com a versão WCAG 2.0,
devem ser cumpridos vários requisitos de conformidade na íntegra, vale ressaltar
que este estudo objetiva apenas verificar a complacência ao requisito de nível de
conformidade, tendo em vista que as aplicações Web analisadas são pacíveis de
mudanças profundas considerando o estado atual e que, para tanto, apenas algumas
das páginas das aplicações foram tomadas para análise.
Assim, para esclarecer, o requisito de nível de conformidade da WCAG 2.0,
mecanismo de avaliação no experimento, de acordo com o documento, indica-se que:
a) Nível de Conformidade: Um dos seguintes níveis de conformidade deverá
ser inteiramente cumprido (W3C, 2011).

56
–– Nível A: Para obter conformidade de Nível A (o nível mínimo de
conformidade), a página Web cumpre todos os Critérios de Sucesso de Nível A, ou
então é fornecida uma versão alternativa em conformidade.
–– Nível AA: Para obter conformidade de Nível AA, a página Web cumpre
todos os critérios de Sucesso de Nível A e AA, ou então é fornecida uma versão
alternativa em conformidade de Nível AA.
–– Nível AAA: Para obter conformidade de Nível AAA, a página Web cumpre
todos os Critérios de Sucesso de Nível A, Nível AA e Nível AAA, ou então é fornecida
uma versão alternativa em conformidade de Nível AAA.
–– Nota 1: Embora só se possa obter conformidade com os níveis acima
referidos, os autores são encorajados a comunicar (nas reivindicações) quaisquer
progressos no sentido de cumprir os critérios de sucesso a partir de todos os níveis
para além do nível de conformidade alcançado.
–– Nota 2: Não recomendamos que, como regra geral, seja necessária
conformidade de Nível AAA para sites completos6
, uma vez que não é possível cumprir
todos os Critérios de Sucesso de Nível AAA para alguns conteúdos.
6.2 OBJETIVOS DO ESTUDO
O objetivo do estudo é fornecer um mecanismo de análise baseado em boas
práticas e recomendações para examinar o atendimento das WCAG 2.0 de forma
simplificada, facilitando uma reprodução de um conjunto de técnicas utilizadas no
experimento por desenvolvedores Web durante a construção de apliçações ricas
para Internet que posicionam acessibilidade como exigência fundamental e inerente
ao sucesso de um website.
Por fim, o objetivo principal e final do estudo compreende a verificação do
nível de conformidade em relação à WCAG 2.0 das páginas das aplicações Web
consideradas para análise.
6 Para as aplicações que não tenham desconformidade com a diretiva por não se aplicar a inclusão de
recurso a que esta se refere, será atribuído nível máximo de conformidade para o item.

57
6.3 APLICAÇÕES WEB OBJETO DE ANÁLISE
As aplicações Web analisadas como objeto deste estudo foram escolhidas pelo
fato do autor deste trabalho ter participado do desenvolvimento das aplicações e
isso permitir premiamente uma profundidade no conhecimento do funcionamento
das páginas para realizar a análise. Os dados sobre as aplicações são:
6.3.1 EXPOTEC
Plataforma de eventos utilizada pelo Instituto Federal de Educação, Ciência e
Tecnologia do Rio Grande do Norte, IFRN, para a realização da Exposição Científica,
Tecnológica e Cultural.
Estudantes do Ensino Médio e respectiva comunidade acadêmica responsável
peloprovimentodeatividadesparaessesestudantesduranteaexposiçãocompreedem
o público-alvo do site.
URL base: http://extensao.ifrn.edu.br/expotec/Expotec/?id=9.
URLs incluídas na análise:
a) Login http://extensao.ifrn.edu.br/expotec/Account/Login.aspx.
b) Inicial http://extensao.ifrn.edu.br/expotec/Expotec/?id=9.
c) Sobre http://extensao.ifrn.edu.br/expotec/Expotec/Publico/Sobre.aspx?id=9.
d) Programação Cultural http://extensao.ifrn.edu.br/expotec/Expotec/Publi-
co/ProgramacaoCultural.aspx?id=9#.
e) Submissão de atividades http://extensao.ifrn.edu.br/expotec/Expotec/Pu-
blico/Atividades.aspx?id=9.
f) Cronograma http://extensao.ifrn.edu.br/expotec/Expotec/Publico/Crono-
grama.aspx?id=9.
g) Local http://extensao.ifrn.edu.br/expotec/Expotec/Publico/Local.aspx?id=9.
Principais tecnologias e softwares utilizados no desenvolvimento: ASP.NET,
C#, MySQL, HTML, CSS, JavaScript, Adobe Flash, Adobe Photoshop, Adobe
Dreamweaver, Adobe Illustrator, Visual Studio.
Período de condução da análise: 6 de outubro a 10 de outubro de 2014.
Idioma do site: Português.

58
6.3.2 Amazing Med
O Amazing Med é uma plataforma desenvolvida para gerenciar internações
hospitalares e inclui funcionalidades para gerenciar desde a entrada de um paciente
em um hospital, através do cadastro de um boletim, até a saída deste por meio de
alta, finalização de boletim ou de internação. A ferramenta ainda possui geração de
gráficos e relatórios estatísticos e simplesmente numéricos para efeito de extração
de informação do sistema.
A plataforma é utilizada por usuários (médicos, enfermeiros, recepcionistas, etc)
entre 25 e 65 anos de idade.
URL base: http://www.amazingtecnologia.com.br.
URLs incluídas na análise:
a) Login http://www.amazingtecnologia.com.br/account/login.
b) Inicial http://www.amazingtecnologia.com.br/.
c) Inserir http://www.amazingtecnologia.com.br/pacientes/inserir.
d) Boletins http://www.amazingtecnologia.com.br/boletins.
e) Unidades http://www.amazingtecnologia.com.br/unidades.
f) Situações http://www.amazingtecnologia.com.br/situacoes.
g) Procedimentos http://www.amazingtecnologia.com.br/procedimentos.
h) Internações http://www.amazingtecnologia.com.br/internacoes.
i) Gráficos http://www.amazingtecnologia.com.br/graficos/todos.
j) Videowall http://www.amazingtecnologia.com.br/graficos/videowall.
k) Videoconferência http://www.amazingtecnologia.com.br/graficos/video-
conferencia.
Principais tecnologias e softwares utilizados no desenvolvimento: ASP.NET,
C#, MSSQL, HTML, CSS, JavaScript, JQuery, XML, JSON, Adobe Flash, Adobe
Photoshop, Adobe Dreamweaver, Adobe Illustrator e Visual Studio.
Período de condução da análise: 6 de outubro a 10 de outubro de 2014.
Idioma do site: Português.

59
6.4 CRITÉRIOS EXAMINADOS E VERIFICAÇÕES
Abaixo, enumeram-se, de acordo com os quatro princípios base das WCAG
2.0 - Perceptível, Operável, Inteligível e Robusto -, as diretivas e respectivos critérios
que compõem a WCAG 2.0, bem como o nível correspondente à complacência do
critério e a descrição das verificações sintetizadas a partir do entendimento de boas
práticas em acessibilidade Web e dos aspectos inferidos pelas diretivas para uma
abordagem prática na análise de conformidade das aplicações Web objeto da análise
com a WCAG 2.0.
Princípio 1: Perceptível - A informação e os componentes da interface do usuário
têm que ser apresentados aos usuários em formas que eles possam perceber.
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.

60
Quadro 5 – Alternativas em texto.
Critério de Sucesso Nível Descrição das Verificações
1.1.1 Conteúdo não
textual
A
»» Todas as imagens possuem texto alternativo
apropriado e equivalente.
»» Imagens que não transmitem conteúdo, são
meramente decorativas, ou que contenham conteúdo
já transmitida em texto recebem o atributo alt nulo
(alt = “”) ou são implementadas como plano de fundo
via CSS. Todas as imagens vinculadas têm texto
alternativo descritivo.
»» Alternativas equivalentes para imagens complexas
são fornecidas no contexto ou em uma página
separada (ligada e/ou referenciadas através do
atributo longdesc).
»» Botões de formulário têm um valor descritivo.
»» Entradas (inputs) de formulários têm rótulos (labels)
textuais associados.
»» Multimídia incorporada é facilmente identificada
através de texto acessível.
»» Os quadros (iframes) possuem título apropriado.
Fonte: Elaboração do Autor (2014).
1.2 Mídias com base no tempo: Fornecer alternativas para mídias com base no
tempo.
Quadro 6 – Mídias com base no tempo.
1.2.1 Apenas áudio
e apenas vídeo
(Pré-gravado)
A
»» Uma transcrição textual descritiva (incluindo todas
as pistas e indicadores visuais e auditivos relevantes)
está prevista para áudio sob demanda e baseado na
Web (podcasts de áudio, arquivos MP3, etc).
»» Uma descrição textual ou auditiva é fornecida
para vídeo-apenas (por exemplo, vídeo que não tem
nenhuma faixa de áudio) sob demanda e baseado na
Web.
1.2.2 Legendas
(Pré-gravadas)
A
»» Legendas síncronas estão previstas para vídeo
sob demanda e baseado na Web (vídeos do YouTube,
Vimeo, etc).

61
1.2.3 Descrição
auditiva ou mídia
alternativa (Pré-
gravada)
A
»» Uma transcrição textual ou faixa de áudio
descritiva é fornecida para vídeo baseado na Web e
sob demanda.
1.2.4 Legendas (Ao
vivo)
AA
»» Legendas sincronizadas são fornecidas para toda
multimídia transmitida ao vivo que contém áudio
(transmissões apenas de áudio, conferências de
vídeo, animações em Flash, etc).
1.2.5 Descrição
auditiva (Pré-
gravada)
AA
»» Descrições em áudio são fornecidas para todo
conteúdo de vídeo. NOTA: Somente necessário se o
vídeo transmite conteúdo visualmente que não está
disponível na faixa de áudio padrão.
1.2.6 Línguagem de
sinais (Pré-gravada)
AAA
»» Um vídeo em linguagem de sinais é fornecido para
todo conteúdo multimídia que contém áudio.
1.2.7 Descrição
auditiva estendida
(Pré-gravada)
AAA
»» Quando uma faixa de áudio descritivo não pode
ser adicionada ao vídeo devido à temporização/
sincronização do áudio (por exemplo, ausência de
pausas no áudio), uma versão alternativa do vídeo
com pausas que permitem descrições auditivas é
fornecida.
1.2.8 Mídia
alternativa (Pré-
gravada)
AAA
»» Uma transcrição textual descritiva é fornecida para
todas as mídias pré-gravadas que possuem vídeo.
1.2.9 Apenas áudio
(Ao vivo)
AAA
»» Uma transcrição textual descritiva (por exemplo,
o script do áudio ao vivo) é fornecida para todo o
conteúdo ao vivo que possui áudio.
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.

62
Quadro 7 – Adaptável.
1.3.1 Informações e
relações
A
»» Marcação semântica é usada de forma adequada
para designar títulos (headings) (h1), listas (ul,
ol e dl), texto especial ou realçado (strong,
code, abbr, blockquote, por exemplo), etc.
»» As tabelas são usadas para dados tabulados.
Sempre que necessário, as células de dados estão
associadas com seus cabeçalhos. Legendas para
tabelas são usadas quando necessários.
»» Os rótulos (labels) de texto são associados com
elementos de entrada (inputs) de formulários.
Elementos de formulário relacionados são agrupados
com fieldset/legend.
1.3.2 Sequência
com significado
A
»» A ordem de leitura e navegação (determinada pela
ordem do código) é lógica e intuitiva.
1.3.3
Características
sensoriais
A
»» Instruções não dependem de forma, tamanho,
ou localização visual (por exemplo, “Clique no ícone
quadrado para continuar” ou “As instruções estão na
coluna da direita”).
»» Instruções não dependem de som (por exemplo,
“Um sinal sonoro indicará que você pode continuar”).
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.
Quadro 8 – Discernível.
1.4.1 Utilização da
cor
A
»» A cor não é utilizada como único método para
entendimento de conteúdo ou para distinguir
elementos visuais.
»» A cor não só é usada para distinguir links de texto
próximo, a menos que o contraste de luminância
entre o link e o texto circundante é de pelo menos 3:1
e uma diferenciação adicional (por exemplo, torna-se
sublinhado) é fornecida quando o link recebe foco ou
tem o cursor posicionado sobre ele.

63
1.4.2 Controle de
áudio
A
»» Um mecanismo é fornecido para parar, pausar,
silenciar ou ajustar o volume do áudio que é
reproduzido automaticamente em uma página por
mais de 3 segundos.
1.4.3 Contraste
(Mínimo)
AA
»» Texto e imagens de texto têm uma relação de
contraste de no mínimo 4,5:1.
»» Texto grande (acima de 18 pontos ou 14 pontos
em negrito) tem uma relação de contraste de, no
mínimo, 3:1.
1.4.4
Redimensionar
texto
AA
»» A página é legível e funcional, quando o tamanho
do texto é dobrado.
1.4.5 Imagens de
texto
AA
»» Se a igual apresentação visual pode ser feita
usando o texto apenas, uma imagem não é usada
para apresentar o texto.
1.4.6 Contraste
(Melhorado)
AAA
»» Texto e imagens de texto têm uma relação de
contraste de, no mínimo, 7:1.
»» Texto grande (acima de 18 pontos ou 14 pontos
em negrito) tem uma relação de contraste de, no
mínimo, 4,5:1.
1.4.7 Som baixo ou
sem som de fundo
AAA
»» Discurso em áudio não tem nenhum ruído ou um
ruído muito baixo de fundo e, dessa forma, o discurso
pode ser facilmente entendido.
1.4.8 Apresentação
visual
AAA
»» Em blocos de texto com mais de uma frase de
comprimento:
• Não há mais do que 80 caracteres de largura.
• Não são plenamente justificados (alinhados às
margens esquerda e direita).
• Têm espaçamento entre linhas (pelo menos
a metade da altura do texto) e espaçamento entre
parágrafos (espaçamento entre linhas de 1,5 vezes)
adequado.
• Têm a cor do texto e a cor do plano de fundo
especificadas. Assim, estas podem ser aplicadas a
elementos específicos ou à página como um todo com
CSS (e, portanto, herdadas por outros elementos).
• Não necessitam de rolagem horizontal quando
o tamanho do texto é duplicado.

64
1.4.9 Imagens
de texto (Sem
exceção)
AAA
»» Texto é usado dentro de uma imagem apenas para
fins de decoração (imagem não transmite conteúdo)
ou quando a informação não pode ser apresentada
com texto apenas.
Princípio 2: Operável - Os componentes de interface de usuário e a navegação
têm que ser operáveis.
2.1 Acessível por teclado: Fazer com que toda a funcionalidade fique disponível
a partir do teclado.
Quadro 9 – Acessível por teclado.
2.1.1 Teclado A
»» Todas as funcionalidades da página estão
disponíveis utilizando o teclado, a menos que a
funcionalidade não possa ser realizada em qualquer
forma conhecida através de um teclado (por exemplo,
desenho à mão livre).
»» Teclas de atalho específicas para a página não
entram em conflito com os atalhos do navegador e
dos leitores de tela existentes.
2.1.2 Sem bloqueio
do teclado
A
»» O foco do teclado nunca está bloqueado ou preso
em um elemento particular da página.
»» O usuário pode navegar de e para todos os
elementos navegáveis da página utilizando apenas o
teclado.
2.1.3 Teclado (Sem
exceção)
AAA
»» Todas as funcionalidades da página estão
disponíveis utilizando o teclado.
2.2 Tempo suficiente: Fornecer tempo suficiente aos usuários para lerem e
utilizarem o conteúdo.

65
Quadro 10 – Tempo suficiente.
2.2.1 Ajustável por
temporização
A
»» Se uma página ou aplicativo tem um limite de
tempo definido para a realização de uma tarefa,
o usuário recebe opções para eliminar, ajustar ou
prorrogar esse prazo. Este não é um requisito para
eventos em tempo real (por exemplo, um leilão, onde
o prazo é absolutamente necessário) ou se o limite de
tempo é maior que 20 horas.
2.2.2 Colocar
em pausa, parar,
ocultar
A
»» Conteúdo movendo automaticamente, piscando,
ou rolando por mais de 5 segundos pode ser pausado,
interrompido ou ocultado pelo usuário. Mover, piscar,
ou rolar pode ser um recurso empregado para chamar
a atenção para o conteúdo ou destacá-lo desde que
para isso dure menos de 5 segundos.
»» Atualização automática de conteúdo (por
exemplo, automaticamente redirecionar ou atualizar
uma página, uma listagem de notícias, um campo
via AJAX, gerar um alerta de notificação, etc) pode
ser pausada, interrompida ou ocultada pelo usuário
ou ainda o usuário pode controlar manualmente o
momento das atualizações.
2.2.3 Sem
temporização
AAA
»» O conteúdo e as funcionalidades não têm limites
de tempo ou restrições.
2.2.4 Interrupções AAA
»» Interrupções (alertas, atualizações da página, etc)
podem ser adiadas ou suprimidas pelo usuário.
2.2.5 Nova
autenticação
AAA
»» Se uma sessão autenticada expirar, o usuário
pode autenticar novamente e continuar a atividade
sem perder os dados da página atual.
2.3 Ataques epilépticos: Não criar conteúdo de uma forma conhecida que
possa causar ataques epilépticos.

66
Quadro 11 – Ataques epilépticos.
2.3.1 Três
piscagens (flashes)
ou abaixo do limite
de contraste
A
»» Nenhum conteúdo da página pisca mais de 3 vezes
por segundo, a menos que o conteúdo piscando seja
suficientemente pequeno e as piscagens sejam de
baixo contraste e não contenham muito vermelho.
2.3.2 Três
piscagens (flashes)
AAA
»» Nenhum conteúdo da página pista mais de 3 vezes
por segundo.
2.4 Navegável: Fornecer formas de ajudar os usuários a navegar, localizar
conteúdos e determinar o local onde estão.
Quadro 12 – Navegável.
2.4.1 Ignorar
blocos
A
»» Um link é fornecido para pular a navegação e outros
elementos que se repetem ao longo das páginas.
»» Se uma página tem uma estrutura de cabeçalho
(heading) adequada, essa pode ser considerada
uma técnica suficiente, ao invés da inclusão de um
link do tipo “Ir para o conteúdo principal”. NOTA: a
navegação por cabeçalhos (headings) ainda não é
suportada em todos os navegadores.
»» Se a página usa quadros (iframes) e os quadros
(iframes) são apropriadamente intitulados, esta é uma
técnica suficiente para contornar quadros (iframes)
individuais.
2.4.2 Página com
título
A
»» A página da Web tem um título descritivo e
informativo.
2.4.3 Ordem do
foco
A
»» A ordem de navegação dos links, elementos de
formulário, entre outros, é lógica e intuitiva.

Estudo de Caso sobre a Adoção de Padrões de Acessibilidade em Aplicações Web

Estudo de Caso sobre a Adoção de Padrões de Acessibilidade em Aplicações Web

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Estudo de Caso sobre a Adoção de Padrões de Acessibilidade em Aplicações Web

Semelhante a Estudo de Caso sobre a Adoção de Padrões de Acessibilidade em Aplicações Web (20)

Mais de Ystallonne Alves

Mais de Ystallonne Alves (8)

Estudo de Caso sobre a Adoção de Padrões de Acessibilidade em Aplicações Web