Upload
daniel-elektron
View
167
Download
0
Embed Size (px)
Citation preview
PROPOSIÇÃO PARA UM PARADIGMA DE ORIENTAÇÃO A ACESSIBILIDADE
YSTALLONNE CARLOS DA SILVA ALVES
NATAL/RN2014
ii
PROPOSIÇÃO PARA UM PARADIGMA DE ORIENTAÇÃO A ACESSIBILIDADE
YSTALLONNE CARLOS DA SILVA ALVES
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE
DEPARTAMENTO DE GESTÃO EM TECNOLOGIA DA INFORMAÇÃOTECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
NATAL/RN2014
iii
PROPOSIÇÃO PARA UM PARADIGMA DE ORIENTAÇÃO A ACESSIBILIDADE
Trabalho de Conclusão de Curso, sob a orientação do M.e Edmilson Barbalho Campos Neto e Coordenação do M.e Leonardo Ataide Minora, submetido ao Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte para a obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas.
YSTALLONNE CARLOS DA SILVA ALVES
NATAL/RN2014
iv
PROPOSIÇÃO PARA UM PARADIGMA DE ORIENTAÇÃO A ACESSIBILIDADE
YSTALLONNE CARLOS DA SILVA ALVES
Período de realização das atividades: maio/2014 a setembro/2014.Carga horária: 400h.Data de aprovação: 29 de setembro de 2014.
Trabalho de Conclusão de Curso submetido ao Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte para a obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas e aprovado por:
__________________________________________________M.e Edmilson Barbalho Campos Neto
Prof. OrientadorIFRN Campus Natal-Zona Norte
__________________________________________________M.e -
Integrante da Banca ExaminadoraIFRN Campus Natal-Central
__________________________________________________M.e -
Integrante da Banca ExaminadoraIFRN Campus Natal-Central
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE
DEPARTAMENTO DE GESTÃO EM TECNOLOGIA DA INFORMAÇÃOTECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
NATAL/RN2014
v
À minha avó, Maria de Lourdes, pelo incondicional apoio que sempre me faz perseverar.
vi
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 que fortificam o IFRN, em especial, os meus professores, pela sabedoria e
dedicação.
vii
Disability need not be an obstacle to success.
— Stephen W. Hawking
viii
As we look ahead into the next century, leaders will be those who empower others.
— Bill Gates
ix
Design is not just what it looks like and feels like. Design is how it works.
— Steve Jobs
x
There are two ways of constructing a software design: one way is to make it so simple that
there are obviously no deficiencies, and the other way is to make it so complicated
that there are no obvious deficiencies.The first method is far more difficult.
— Sir Tony Hoare
xi
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 necessidade da construção de um novo paradigma
voltado para o desenvolvimento a partir de princípios de acessibilidade, o trabalho
considera a proposição de um Paradigma de Orientação a Acessibilidade e
sugere diretrizes para um ciclo de desenvolvimento com foco em amplificação de
acesso. Baseando-se no paradigma e ciclo acima mencionados, demonstra-se as
possibilidades proporcionadas pelo emprego daquele dentro do contexto do ciclo
de desenvolvimento apresentado e, por fim, valida-se as diretrizes sugeridas por
meio de um estudo de caso construído de maneira direcionada pelo paradigma
objeto deste estudo – empregando técnicas, análise, testes e validações – e também
através de um segundo estudo de caso versado sob a perpectiva de identificação
dos problemas no desenvolvimento sem complacência ao paradigma.
Palavras-chave: Acessibilidade. Desenvolvimento Web. Paradigma. Orientação a Acessibilidade. Tecnologias Assistivas.
xii
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. In
order to investigate the necessity to build a new paradigm which is focused on the
development from accessibility’s principles, this paper considers the proposition
of an Accessibility Oriented Paradigm, and suggests guidelines for a development
cycle focusing on amplification of access. Based on the aforementioned cycle and
paradigm, it demonstrates the possibilities being offered by the use of the paradigm
within the presented development cycle context. Finally, it validates the suggested
guidelines through a case study built so directed by the paradigm – employing
techniques, analysis, testing and validation –, and also through a second case study
developed under the perpective of problem identification for the development without
complacency to the respective paradigm.
Keywords: Accessibility. Accessibility Oriented. Assistive Technologies. Paradigm. Web Development.
xiii
LISTA DE ILUSTRAÇÕES
Imagem 1 – Exemplo hipotético de ciclo de desenvolvimento com acessibilidade. 57Imagem 2 – Exemplificando a seleção de cores para formar uma paleta que atenda a variados problemas de percepção de cor. 60Imagem 3 – Combinações de cores acessíveis. 61Imagem 4 – Protótipo de média fidelidade da página inicial do Konnect Eventos. 62Imagem 5 – Protótipo de alta fidelidade da página inicial da plataforma. 62Imagem 6 – Simulação de deuteranopia. 63Imagem 7 – Simulação de protanopia. 64Imagem 8 – Simulação de tritanopia. 64Imagem 9 – Opções de configurações de prova de cores referente às analomalias deuteranopia e protanopia no Adobe® Photoshop®. 65Imagem 10 – Implementação da funcionalidade “Ir para o conteúdo principal”. 69Imagem 11 – Localizando as ferramentas do desenvolvedor no Google Chrome para auditoria da aplicação. 69Imagem 12 – Verificando se a extensão do Chrome, a Accessibility Developer Tools, encontra-se ativada. 70Imagem 13 – Executando a auditoria de acessibilidade na página. 70Imagem 14 – Página inicial da aplicação exibindo o resultado da auditoria. 71Imagem 15 – Detalhe do resultado da auditoria referente à página inicial. 72Imagem 16 – Enviando os dados de uma página para validação utilizando os serviços do W3C. 72Imagem 17 – Resultado da validação utilizando o Adobe Dreamweaver. 73Imagem 18 – Página inicial da aplicação exibindo resultado da auditoria. 74Imagem 19 – Detalhes da auditoria da aplicação Kanban. 75
xiv
LISTA DE QUADROS
Quadro 1 – Recursos gerais para acessibilidade. 44Quadro 2 – Prós e contras do software de reconhecimento de voz Dragon® NaturallySpeaking® Premium. 50Quadro 3 – Auditoria do Accessibility Developers Tools. 52Quadro 4 – Ferramentas online para teste de acessibilidade. 53Quadro 5 – Definição de plataforma e público-alvo para a aplicação. 59
xv
LISTA DE TABELAS
Tabela 1 – Utilização de leitores de tela por grupo de usuário. 47
xvi
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).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).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).
xvii
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).
xviii
SUMÁRIO
INTRODUÇÃO 201 Introdução 201.1 Objetivos 221.2 Metodologia 23
CAPÍTULO I 242 Conceituando acessibilidade 242.1 Uma visão estatística sobre deficiência 252.2 Tipos de deficiência 272.3 Acessibilidade não é usabilidade 292.4 Acessibilidade não é independência de dispositivo 302.5 Mitos sobre acessibilidade 312.6 Benefícios inerentes à acessibilidade 322.7 Desvantagens inerentes à acessibilidade 33
CAPÍTULO II 343 Diretivas e complacência a padrões e convenções 343.1 Padrões do W3C 353.2 WAI-ARIA 363.3 Web Content Accessibility Guidelines 373.4 Boas práticas para promoção de acessiblidade 393.5 Legislação 423.6 Fontes de recursos sobre acessibilidade 44
CAPÍTULO III 454 Tecnologias Assistivas 454.1 Softwares de leitura de tela 474.2 Display Braille 484.3 Software de legendagem 494.4 Reconhecimento de Voz 49
CAPÍTULO IV 515 Testes e análise de acessibilidade 515.1 Accessibility Developers Tools 525.2 Ferramentas para teste de acessibilidade 53
CAPÍTULO V 556 Proposição para um Paradigma de Orientação a Acessibilidade 55
I. Definição da plataforma e público-alvo 55II. Design de UI considerando resultados de testes e validações 56
xix
III. Transformar o planejamento visual da UI em uma UX 56IV. Executar continuamente melhorias progressivas 56
6.1 Ciclo de desenvolvimento com acessibilidade 57
CAPÍTULO VI 597 Aplicação em estudos de caso 597.1 Estudo de caso — Konnect Eventos 59
V. Definição de plataforma e público-alvo 59VI. Design de UI considerando resultados de testes e validações 60VII. Transformar o planejamento visual da UI em uma UX 66VIII. Executar continuamente melhorias progressivas 72
7.2 Estudo de caso II — Kanban (Amazing Med) 73
CONCLUSÃO 768 Considerações finais 76
REFERÊNCIAS 77
GLOSSÁRIO 81
APÊNDICES 85
ANEXOS 93
ÍNDICE 94
20
INTRODUÇÃO
1 Introdução
O uso do computador interligado em rede transformou-o em instrumento de
difusão da informação. Tecnologia intelectual e ferramentas cognitivas cada vez mais
a serviço da sociedade puderam ser criadas. Com isso, o padrão de satisfação dos
usuários tem exigido o desenvolvimento de tecnologias adequadas, cujas respostas
estão na maior rapidez com que as informações são veiculadas, na preocupação
progressivamente maior com a interface e com o grau de interatividade.
A construção de uma proposta para um novo paradigma voltado para o
desenvolvimento de interfaces do usuário (UI) a partir de princípios de acessibilidade
representa o objetivo principal deste trabalho e a motivação para a produção do
instrumento prospectivamente resultante, um Paradigma Orientado a Acessibilidade,
o qual permitirá significativos benefícios e avanços relativos às áreas 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 aos projetos que o utilizarem como norte.
Assim, objetivando a proposição de um Paradigma de Orientação a
Acessibilidade, esta obra apresenta conceitos e análises, considerando múltiplos
aspectos, de interferentes e facilitadores do processo de design de interfaces do
usuário, as quais intrinsecamente implantam a perspectiva de uma experiência
proveitosa e abrangente no tocante à acessibilidade.
Diante dos desafios encontrados ao se tentar incluir mecanismos de acessibilidade
em projetos de UI focados na Internet e em plataformas que se estendem dos desktops
aos dispositivos móveis, os conceitos abordados possibilitam uma compreensão
expressiva quanto à terminologia e à definição acerca de acessibilidade.
Ao longo desta obra, serão apresentadas algumas diretivas governamentais/
institucionais existentes que tangem a regulamentação de acessibilidade como parte
oportuna e mesmo obrigatória em projetos de software e para a web desenvolvidos
21
por diferentes organizações com a finalidade de atingir um público-alvo amplo e,
dessa forma, democratizar o acesso à informação.
Discutem-se também algumas considerações quanto às dificuldades e limitações
que surgem durante o desenvolvimento de projetos potencialmente escalonáveis e
como estas problemáticas podem ser facilmente eliminadas do processo uma vez que
se tenha uma adequada abordagem pautada em fatores ligados ao comprometimento
da acessibilidade.
Além disso, discute-se a eficiência de tecnologias assistivas sendo empregadas
por usuários com diferentes tipos de necessidades especiais como forma de suplantar
barreiras de acesso.
Dentro da necessidade de se conhecer e explorar mecanismos verdadeiramente
eficazes para serem incorporados ao paradigma desenvolvido, alguns estudos de
caso são analisados sob o ponto de vista de estratégias que comprovadamente
permitiram amplificar as possibilidades de disponibilização de conteúdo a um
número significativo de usuários tão somente a partir do emprego eficiente de
princípios e técnicas de acessibilidade.
A análise de técnicas, testes e ferramentas de promoção de acessibilidade com-
põe ainda o processo de construção do paradigma a que se dedica este trabalho e,
ressaltada a importância para os campos da Tecnologia da Informação anteriormente
mencionados, representa parte fundamental para um direcionamento à complacên-
cia a padrões, que, por conseguinte, também é discutida e diz respeito à observância
de arquétipos que permitem uma rápida adequação e convertimento de um quadro
de inacessibilidade utilizando-se apenas do que seriam consideradas boas práticas.
Por fim, apresentada uma reunião de recomendações para proposição de
um Paradigma de Orientação a Acessibilidade, levando-se em consideração
todos os elementos tratados no decorrer do estudo, enumera-se e justifica-se os
itens incluídos na proposta final. Além disso, versando sobre a aplicação e análise
de estudos de caso que utilizem o paradigma aqui intencionado, observa-se as
vantagens e eventuais entraves que esta proposta possa apresentar e que requeiram
22
as melhorias discutidas dentro do entendimento da necessidade de se estender este
trabalho, dada a impossibilidade de se abarcar todos os aspectos relacionados a
acessibilidade, tendo em vista o foco a que este trabalho se destina.
1.1 Objetivos
Propor recomendações para um Paradigma de Orientação a Acessibilidade
através do mapeamento e análise de técnicas que permitam identificar, discutir e
examinar considerações quanto às dificuldades e limitações que surgem durante o
desenvolvimento de projetos de software para a web e como estas problemáticas
podem ser eliminadas uma vez que se tenha uma adequada abordagem pautada em
fatores que comprometem áreas dependentes de recursos de acessibilidade.
Compreender conceitos e análises no tocante ao desenvolvimento incorporando
ferramentas para produzir Interface do Usuário (UI) e Experência do Usuário (UX) com
amplificações de acesso.
Avaliar a eficiência de tecnologias assistivas (AT) disponíveis e popularmente
utilizadas por indivíduos com necessidades especiais.
Com base em técnicas de arquitetura, modelagem de dados, criação de
interfaces gráficas, modelos de implementação, padrões de projetos, entre outras,
propor um modelo que possibilite a integração e padronização de mecanismo de
desenvolvimento de software em módulos funcionais acessíveis.
Investigar diretivas governamentais/institucionais existentes que tangem a
regulamentação de acessibilidade no campo da Tecnologia da Informação.
Analisar estudos de caso em acessibilidade.
Examinar técnicas, testes e ferramentas de promoção de acessibilidade que
fundamentam um direcionamento à complacência a padrões.
Observar as vantagens e eventuais entraves que as proposições possam
apresentar e que requeiram melhorias dentro do entendimento da composição do
prospectivo paradigma.
23
1.2 Metodologia
O desenvolvimento deste trabalho dar-se-á a partir da análise e aplicação de
conceitos de engenharia de software para a definição de um modelo que proveja a
padronização e integração de sistemas sob uma perspectiva de desenvolvimento
orientado a acessibilidade.
Portanto, buscando definir a composição do paradigma a ser proposto,
compreende uma investigação pautada na realização de abordagens qualitativas
e quantitativas que identifiquem elementos os quais possam justificar a respectiva
incorporação. Portanto, considerando aspectos que valorizam ou prejudicam a
eficiência e eficácia de processos para ampliar as possibilidades de acessibilidade
em aplicações web.
Coerentemente, 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 do paradigma,
o estudo seguirá com a especificação dos itens desejáveis para a constituição do
paradigma e validará as proposições utilizando métodos experimentais. Assim, como
forma de examinar os elementos, a dizer, a serem inseridos na proposta final, uma
oportuna utilização em sistema que pode servir como aplicação exemplo contrastará
dificuldades e benefícios, vantagens e desvantagens e traçará resultados, permitindo
que as informações possam ser processadas e validadas, efetivando a pertinente
integração dos itens que venham a compor o paradigma.
24
CAPÍTULO I
2 Conceituando acessibilidade
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.
A International Standards Organization (ISO) denomina acessibilidade como:
“usabilidade de um produto, serviço, ambiente ou facilidade para pessoas com a
mais ampla gama de capacidades” (ISO apud CONNOR, 2012).
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
Tecnologia Assistiva (AT), as quais ajudam os indivíduos no manejo de computadores
provendo soluções especiais de hardware e software.
25
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).
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 um monte de regras que
devemos seguir (RUSH e 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.
2.1 Uma visão estatística sobre deficiência
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
26
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.
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).
Nos países membros da Organização de Cooperação e de Desenvolvimento
Econômico (OCDE), segundo o secretariado desta organização, a proporção das
pessoas com deficiência é nitidamente mais elevada nos grupos com menos instrução.
Em média, 19% das pessoas menos instruídas têm uma deficiência, em comparação
com 11% das mais instruídas.
O Banco Mundial estima que 20% das pessoas mais pobres tenham uma
deficiência e, em geral, são consideradas como as mais desfavorecidas pelos
membros da sua própria comunidade. Vale ressaltar ainda que estudos comparativos
das leis sobre pessoas com deficiência mostram que apenas 45% dos países têm
uma legislação anti-discriminatória ou que faça referência específica às pessoas com
deficiência (UNRIC, 2013).
Outro fato relevante é que, segundo a UNESCO, nos países em desenvolvimento,
90% das crianças com deficiência não frequentam a escola.
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, nesse 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.
27
2.2 Tipos de deficiência
Em 21 de Dezembro de 1999, o decreto nº. 3.298 regulamentou a Lei nº 7.853
que trata acerca da Política Nacional para a Integração da Pessoa Portadora de
Deficiência, consolidando as normas de proteção e dando outras providências, na
gestão do ex-presidente da República Fernando Henrique Cardoso.
Para os efeitos do decreto citado, considera-se:
• Deficiência – toda perda ou anormalidade de uma estrutura ou função
psicológica, fisiológica ou anatômica que gere incapacidade para o desempenho de
atividade, dentro do padrão considerado normal para o ser humano;
• Deficiência permanente – aquela que ocorreu ou se estabilizou durante um
período de tempo suficiente para não permitir recuperação ou ter probabilidade de
que se altere, apesar de novos tratamentos;
• Incapacidade – uma redução efetiva e acentuada da capacidade de integração
social, com necessidades de equipamentos, adaptações, meios ou recursos
especiais para que a pessoa com deficiência possa receber ou transmitir informações
necessárias ao seu bem-estar pessoal e ao desempenho de função ou atividade a
ser exercida.
Assim, considera-se pessoa com deficiência aquela que se enquadra nas
seguintes categorias:
» Deficiência física;
» Deficiência auditiva;
» Deficiência visual;
» Deficiência mental;
» Deficiência múltipla.
Por conseguinte, de acordo com o decreto 5.296 de 2 de dezembro de 2004,
essas categorias correspondem respectivamente a:
a) deficiência física: alteração completa ou parcial de um ou mais segmentos
do corpo humano, acarretando o comprometimento da função física, apresentando-
-se sob a forma de paraplegia, paraparesia, monoplegia, monoparesia, tetraplegia,
28
tetraparesia, triplegia, triparesia, hemiplegia, hemiparesia, ostomia, amputação ou
ausência de membro, paralisia cerebral, nanismo, membros com deformidade con-
gênita ou adquirida, exceto as deformidades estéticas e as que não produzam dificul-
dades para o desempenho de funções;
b) deficiência auditiva: perda bilateral, parcial ou total, de quarenta e um
decibéis (dB) ou mais, aferida por audiograma nas frequências de 500Hz, 1.000Hz,
2.000Hz e 3.000Hz;
c) 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 acui-
dade 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 for igual ou
menor que 60°; ou a ocorrência simultânea de quaisquer das condições anteriores;
d) deficiência mental: funcionamento intelectual significativamente inferior à
média, com manifestação antes dos dezoito anos e limitações associadas a duas ou
mais áreas de habilidades adaptativas, tais como:
1. comunicação;
2. cuidado pessoal;
3. habilidades sociais;
4. utilização dos recursos da comunidade;
5. saúde e segurança;
6. habilidades acadêmicas;
7. lazer; e
8. trabalho.
e) deficiência múltipla - associação de duas ou mais deficiências.
Simplificadamente, faz-se possível relacionar que, dentre os tipos de deficiência,
estão pontuadas características que incluem um indivíduo em uma das categoria de
incapacidade no tocante à utilização de uma aplicação:
» Visual:
Cegueira, miopia, acuidade visual fraca, visão embaçada.
29
» Auditiva:
Surdez.
» Motora:
A incapacidade de usar um mouse, diminuição do tempo de resposta, controle
motor com limitações.
» Cognitiva:
Incapacidades do aprendizado, distração, incapacidade de memorização ou de
assimilar grandes quantidades de informações.
2.3 Acessibilidade não é usabilidade
Antes de mais nada, embora acessibilidade não seja usabilidade, uma boa
abordagem em acessibilidade é uma boa abordagem em usabilidade.
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.
Em uma visão bastante simplista, de acordo com Krug (2013), usabilidade
significa que “uma pessoa de média (ou mesmo abaixo da média) capacidade e
experiência pode descobrir como usar um coisa para realizar algo, sem que seja mais
problemático do que vale a pena”.
Usabilidade é definida como o grau com que indivíduos (usuários) podem
executar um conjunto de tarefas requeridas. Compreende o produto de, várias vezes,
conflitantes metas de design (BRINCK et al, 2001).
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):
30
» Aprendibilidade: O sistema deve ser fácil de aprender, para que o usuário
possa rapidamente começar a conseguir fazer algo com ele.
» 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.
» 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.
» Erros: O sistema deve ter uma baixa taxa de erro, de modo que os usuários
cometam alguns erros durante a utilização do sistema e, quando cometerem, possam
facilmente se recuperar deles. Além disso, erros catastróficos não devem ocorrer.
» Satisfação: o sistema deve ser agradável de usar para que os usuários sejam
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.
2.4 Acessibilidade não é independência de dispositivo
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.
Independência de dispositivo, por outro lado, 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 as pessoas que não têm deficiência.
Além disso, a independência de dispositivo pode dizer respeito mais à tecnologia
envolvida que permite que uma aplicação esteja disponível em diferentes dispositivos
31
ou plataformas, mas a aplicação em essência pode permanecer inalterada e, em
quase nada, a independência contribuiria para eliminar problemas enfrentados por
indivíduos com deficiência que utilizariam o sistema independente.
2.5 Mitos sobre acessibilidade
Em se tratando 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 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 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:
32
» Não é viável fazer tudo acessível para todos;
» É possível fazer conteúdos mais acessíveis para mais pessoas; e
» O emprego de diferentes padrões resulta em maior ou menor grau de
acessibilidade 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.
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. O 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.
2.6 Benefícios inerentes à acessibilidade
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.
33
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:
» fornecer oportunidades igualitárias;
» prover maior acesso a informação;
» proporcionar novas oportunidades de interação; e
» 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
outros elementos, na disponibilização do conteúdo que se objetiva transmitir.
2.7 Desvantagens inerentes à acessibilidade
Algumas desvantagens quando se intenciona incorporar acessibilidade em
sistemas, por sua vez, representam considerações como as seguintes:
» existe uma vasta diferença de implementação, para ilustrar, entre navegadores,
plataformas e leitores de tela;
» navegadores antigos e leitores de tela não são manipuladores eficazes de
aplicações web dinâminas;
» nenhum navegador ou leitor de tela existente consegue implementar e seguir
totalmente os padrões aceitos; e
» não há uma documentação clara a respeito do que é suportado em ferramentas
de autoração ou mesmo em navegadores populares.
34
CAPÍTULO II
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):
» Conheça que recursos dispõe;
» Saiba como esses recursos vão aparecer na interface;
» Saiba onde encontrar esses recursos no site e na página;
» Saiba como operar cada recurso para atingir seu objetivo;
» Não precise ponderar o significado de elementos de design desconhecidos;
» Não perca características importantes por excessivamente analisarem um
elemento de design que não é padrão;
» 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:
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
tornam-se mais prováveis de serem encontradas por visitantes do site.
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.
35
Facilidade de manutenção: Menos código significa que um site é mais fácil
de manter. Isso colabora positivamente com o autor da página, bem como quaisquer
membro de uma equipe que trabalha na manutenção ou revisão de um site.
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
menor tempo de carregamento para o usuário.
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:
» 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.
» 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.
» 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):
36
O World Wide Web Consortium é uma comunidade internacional em que organizações associadas, equipes de profissionais de tempo integral, bem 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:
Accessible Rich Internet Applications (ARIA): que define tecnologias para
criar aplicações web dinâmicas e mais acessíveis.
Web Content Accessibility Guidelines (WCAG): que apresenta diretivas para a
criação de websites acessíveis.
Authoring Tool Accessibility (ATAG): diretivas para o desenvolvimento de
ferramentas de autoração que encoragem e apoiem desenvolvedores no fomento da
produção de websites acessíveis.
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
37
forma de elucidar com detalhamento todos os elementos pontuados como relevantes
para tornar acessível o conteúdo de páginas da web.
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.
As técnicas empreendidas nas Diretivas de Acessibilidade em Conteúdo da Web
compõem-se pelos pontos a seguir (W3C, 1999):
1. Fornecer alternativas equivalentes ao conteúdo sonoro e visual.
2. Não recorrer apenas à cor.
3. Utilizar corretamente marcações e folhas de estilo.
4. Esclarecer o uso de linguagem natural.
5. Criar tabelas passíveis de transformação harmoniosa.
38
6. Certificar-se de que as páginas dotadas de novas tecnologias possam ser
transformadas harmoniosamente.
7. Certificar-se do controle do usuário sobre as alterações sensivelmente
temporais do conteúdo.
8. Assegurar a acessibilidade direta de interfaces do usuário integradas.
9. Criar para independência de dispositivo.
10. Utilizar soluções provisórias.
11. Usar tecnologias do W3C e orientações.
12. Fornecer contexto e orientação da informação.
13. Fornecer mecanismos claros de navegação.
14. Certificar-se de que os documentos são claros e simples.
A segunda versão do Web Content Accessibility Guidelines (WCAG 2.0), por sua
vez, tornou-se uma recomendação W3C em 2008.
A WCAG 2.0 pode ser resumida como doze diretrizes seguindo quatro princípios
– Percepetível, Operável, Inteligível e Robusto (SIKOS, 2011):
Princípio 1: 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
apresentações sem perder informação ou estrutura.
4. Conteúdos visuais e auditivos devem ser fáceis de distinguir.
Princípio 2: 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.
39
Princípio 3: 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.
Princípio 4: 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. A compatibilidade deve ser maximizada com os agentes de usuário e tecnologia
assistiva atuais e futuros, incluindo aqueles que funcionam com recursos limitados.
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):
» Atribuir um identificar único <title> para cada página, assim, os usuários podem
localizar-se em relação a que ponto se encontram dentro do site.
» Criar páginas alternativas que utilizem uma folha de estilo diferente para dar
suporte a recursos extras como alto contraste.
» 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.
» 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.
40
» 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.
» Ao fornecer informações em formato PDF (Portable Document File), fornecer
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
salientar que a Adobe está continuamente melhorando o formato PDF para que ele
seja cada vez mais acessível através de leitores de tela.
» Não utilizar pop-ups ou janelas modais sem que o usuário seja primeiramente
alertado sobre isso.
» Evitar o uso de arte empregando ASCII, como o uso, por exemplo, dos símbolos
“menor que” (<) e “maior que” (>) para apontar para algo. Os leitores de tela lerã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.
» 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.
» 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 a ferramenta “alt” que forneça o texto
correspondente para o leitor de tela.
» Todas as imagens que transmitem informações úteis devem conter dicas
usando ferramentas como o alt e title. Em se 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.
» 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 browsers.
41
» Adicionar um menu duplicado, se necessário, e links para “Voltar ao topo” em
intervalos espaçados nas páginas mais longas.
» 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.
» Para ajudar as pessoas com tremores nas mãos, garantir um espaço adequado
entre os campos, caixas de seleção, botões do menu e botões de rádio.
» Menus drop-down em JavaScript são inacessíveis para os usuários de leitores
de tela. Entretanto, os menus drop-down em PHP ou ASP são tradicionalmente
acessíveis para os leitores de tela.
» Assegurar que links e elementos interativos da página sejam facilmente
navegá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 padrão
é lógica, portanto, não a modificar se não for para assegurar essa ordem.
» Certificar-se de que os vídeos têm legendas para que os surdos possam
entendê-los e também apreciá-los.
» 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 repentino pode
causar trauma aos usuários cegos ou amblíopes. Sempre usar onmousedown (iniciar
com o precionamento do mouse) como forma de iniciar a reprodução de um clipe de
áudio ou vídeo e fornecer uma explicação e um aviso.
» 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
represente 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.
» Adicionar um link para “Ir para o conteúdo principal” no início de cada página
(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
42
imagem no início de cada página com o texto “Ir para o conteúdo principal”1. Assim,
fazendo o link saltar para uma âncora (marcador) no início do conteúdo principal.
» 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.
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).
Uma brecha foi dada pela seção permitindo que sites pudessem obter uma
renúncia se o público alvo fosse pequeno e se comprovadamente ninguém naquele
grupo tivesse alguma deficiência. Contudo, essas renúncias são cada vez mais raras,
dado o quadro crescente no número de incapacitados em todas as esferas sociais.
Além disso, faz-se difícil provar que o público nunca irá incluir qualquer pessoa
com deficiência, assim, esta renúncia é geralmente limitada a pequenos projetos ou
projetos ultra-secretos com um prazo extremamente limitado (como uma oficina ou
reunião breve de poucos minutos).
O ato abrange qualquer pessoa com deficiência, mas suas interpretações muitas
vezes se concentrar em três grupos principais:
» O deficiente visual; aqueles com deficiência auditiva; e, ainda, aqueles com
deficiência física.
1 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
Cunningham (2012) acrescenta que a Seção 508 assume uma postura ampla,
não bastando considerar, portanto, os dois primeiros grupos, de cegos e surdos,
considerando também aqueles com baixa visão e cegueira de cor, bem como aqueles
que não podem ser completamente surdos.
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
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 é importante notar, a lei não deixa claro como fará para implementar a forma-
çã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.
44
3.6 Fontes de recursos sobre acessibilidade
Vale a pena ressaltar ainda algumas fontes de recursos que são amplamente
reconhecidas sobre acessibilidade:
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
CAPÍTULO III
4 Tecnologias Assistivas
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 pessoas 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
Múltipla Nacional do Estados Unidos (apud CONNOR, 2012) define Tecnologia
46
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:
» Leitores de tela e lupas ou amplificadores;
Para indivíduos com diferentes graus de deficiência visual ou cegos.
» Displays Braille atualizáveis;
Para cegos.
» Softwares de legendagem;
Para surdos.
» Software de reconhecimento de voz, interruptores, apontadores e telas
sensíveis ao toque.
Para indivíduos com deficiências motoras.
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:
» Navegação apenas pelo teclado;
» Navegação apenas empregando o mouse;
» Alterações nos tamanhos das fontes do sistema operacional, aplicações (caso
a opção seja disponibilizada) e do navegador;
47
» Alterações do tamanho de janelas e/ou opções de zoom;
» Alterações nas configurações de cores;
» 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).
48
JAWS® fornece instalação com narração, acesso ao texto presente em qualquer
imagem na tela por meio de OCR, vozes em 30 línguas diferentes, incluindo português,
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:
» NVDA, NonVisual Desktop Access (Windows);
» Orca (Linux);
» VoiceOver (Mac OS); e
» 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.
49
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
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
50
página), por exemplo, facilitam a navegação e a forma como usuários interagem com
as páginas e o browser (Ver “ANEXO I – Navegação pelo site do Google Maps
utilizando o Dragon® NaturallySpeaking®.” na página 93 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
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 da versão 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 custo,
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.
51
CAPÍTULO IV
5 Testes e análise de acessibilidade
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).
» Validar o código da página web no site de validação onlinde da W3C <http://
validator.w3.org>.
» 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.
» Silenciar o volume e analisar se qualquer conteúdo auditivo tem equivalente
textual facilmente disponível.
» Ampliar o dimencionamento da janela do navegador, alterar o zoom e aumentar
as fontes para verificar se a página ainda se mantém viável e compreensível.
» 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.
» 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.
» Utilizar listas ordenadas e não ordenadas apropriadamente.
52
» Checar se os títulos ou texto dos menus e links indicam claramente o respectivo
destino que representam.
» Verificar, utilizando a tecla tab se a navegação através dos links pode ser
totalmente realizada com a utilização apenas do teclado.
» Assegurar o emprego de textos simples, claros e concisos em cabeçalhos
informativos utilizados para fracionar o conteúdo escrito da página.
» Remover elementos que piscam ou brilham, inclusive marquees.
» 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 Tools1, 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:
» ChromeVox - leitor de tela;
» ChromeVis - amplificador para indivíduos com baixa visão;
» ChromeShades - ferramenta para teste de acessibilidade no browser.
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 alternativosImagens e rótulos dos campos de formulários.
Accesibilidade pelo teclado Controles de foco da UI
1 Um exemplo de utilização desta ferramenta será demonstrado na análise de estudos de caso.
53
Categoria da audição Checam por
ARIAValida papeis (roles) dos elementos da aplicação
Acessibilidade para baixa-visãoGrau 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 acessibilidade2.
Ferramenta Descrição
Contrast-Ahttp://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 Filterhttp://colorfilter.wickline.org/
A aplicação permite visualizar páginas utilizando filtros que simulam diferentes problemas visuais relacionados à percepção de cores.
Etrehttp://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.
2 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 Daltonismhttp://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
CAPÍTULO V
6 Proposição para um Paradigma de Orientação a Acessibilidade
Para Preece et al (2007), dentro do design de interação, um paradigma
refere-se a uma abordagem específica que tem sido adotada pela comunidade
de pesquisadores e designers para a realização de seu trabalho, em termos de
pressupostos compartilhados, conceitos, valores e práticas. Isso decorre da forma
como o termo tem sido usado na ciência para se referir a um conjunto de práticas que
a comunidade tenha acordado, incluindo:
» As perguntas a serem feitas e como elas devem ser enquadradas.
» O fenômeno a ser observado.
» A forma como os resultados de experimentos devem ser analisados e
interpretados (KUHN, 1962).
Considerando os aspectos levantados acerca da utilização de ferramentas
de teste, análise e validação, entendimento de diretivas, tecnologias assistivas,
complacência a padrões, tendo verificado benefícios e dificuldades em tornar
uma aplicação acessível e de incorporar esse conceito como paradigma de
desenvolvimento, a seguir, enumera-se os pontos fundamentais para a proposição
de um Paradigma de Orientação a Acessibilidade.
Portanto, consolidando e condensando o estudo aqui apresentado sobre
acessibilidade, como forma de propor uma abordagem eficiente e eficaz no campo
da promoção da acessibilidade, abstrair e incorporar os seguintes passos como
norte para um desenvolvimento paradigmado pela acessibilidade são fundamentais
e inerentes ao sucesso de um projeto com amplificação de acesso:
I. Definição da plataforma e público-alvo
Como não existe aplicação totalmente acessível, faz-se necessário definir qual
a plataforma que se presente focar o desenvolvimento e qual a audiência que se
pretende atingir. Dados adicionais podem ser levantados para compor uma proposição
da justificativa do desenvolvimento mais esclarecedora e limitante.
56
II. Design de UI considerando resultados de testes e validações
O processo de desenvolvimento de UI deve sempre levar em conta os resultados
do processamento de testes, auditorias e saídas de softwares de análise e teste de
acessibilidade. Isso permite a máxima adesão do produto final às diretivas seguidas
para se atender coerentemente a plataforma e o público-alvo objetivados.
O Design de UI pode compreender ainda a prototipação (recomenda-se
uma abordagem de alta fidelidade para o melhor resultado dentro deste aspecto)
da interface do software ou aplicação para web; sob esta perspectiva, os testes
devem ser repetidos sempre que houver novas alterações geradas a partir dos
resultados previamente obtidos. Além disso, deve-se levar em consideração que,
preferencialmente, para se desenvolver páginas acessíveis, é necessário também
utilizar-se de ferramentas conhecidamente acessíveis que estão disponíveis para o
desenvolvimento focado em acessibilidade.
III. Transformar o planejamento visual da UI em uma UX
Deve-se codificar a interface do usuário com a melhor experiência do usuário
sendo considerada. O sucesso de uma UX inclui o sucesso de uma interface de
usuário complacente a padrões e que leva em conta todos os elementos que
podem prejudicar essa experiência. O desenvolvimento com tecnologia compatível
com padrões também se faz importante como forma de assegurar que ocorra
uma minimização de problemas de validação e teste, uma vez que ferramentas de
autoração acessível, por natureza, geram resultados complacente a padrões.
IV. Executar continuamente melhorias progressivas
Todo o ciclo deve progressivamente ser revisitado para assegurar o enfoque
em acessibilidade, assim, as fases devem ser revistas mesmo depois de realizado
o lançamento da página ou ainda quando se processa o acréscimo de nova forma
de suporte, recurso ou serviço. Ainda que seja finalizado o produto e lançado para o
mercado, existem ainda melhorias que podem atender suporte e serviço que atendam
aos usuários da aplicação final. O fornecimento de um suporte acessível, por exemplo,
pode permitir a remoção de falhas que não foram, até então, identificadas.
57
6.1 Ciclo de desenvolvimento com acessibilidade
O diagrama a seguir apresenta um ciclo de desenvolvimento hipotético dentro
da perspectiva de utilização de acessibilidade como norte.
Imagem 1 – Exemplo hipotético de ciclo de desenvolvimento com acessibilidade.
Ciclo de desenvolvimento com acessibilidade
REQUERIMENTOS DESIGN IMPLEMENTAÇÃO VERIFICAÇÃO LANÇAMENTO SUPORTE E SERVIÇO
De�nir Objetivos
Planejar Recursos
Proposição da justi�cativa de desenvolvimento
Avaliação de riscos que comprometam a acessibilidade
Endereçar acessibilidade no design da UI e UX
Empregar especi�cações para acessibilidade
Incorporar padrões e tecnologias acessíveis
Incluir acessibilidade na documentação do produto
Desenvolver código seguindo boas práticas e empregando ferramentas de acessibilidade
Utilizar boas práticas de teste e validação
Realizar teste utilizando ferramentas de acessibilidade
Validar a complacência a padrões
Assegurar a conclusão de todos os processos planejados
Finalizar declaração de conformidade com padrões
Fornecer acesso a suporte acessível
Participar no processo de gestão de incidentes
Atualizar documentação acerca de acessibilidade
Fonte: Elaboração do autor.
O cliclo seria, para tanto, associado ao ciclo utilizado normalmente pela equipe de
desenvolvimento1; assim, haveria uma integração entre ciclos e não uma substituição
por um novo ciclo único de desenvolvimento com foco em amplificação de acesso.
As fases apresentadas também podem ser consideradas meramente ilustrativas.
Nas fases apresentadas, o ciclo é constituído com uma fase de planejamento do
produto, com os requerimentos sendo definidos, com a proposição da justificativa de
desenvolvimento e avaliação dos riscos que possam vir a comprometer os elementos
de acessibilidade que serão incorporados.
Na fase de design, endereça-se acessibilidade do design da interface do
usuário e planeja-se esse endereçamento também quanto à experiência do usuário,
em se tratando de acessibilidade. Neste ponto, empregam-se as especificações
para acessibilidade na medida que forem necessárias, utilizando, por exemplo, o
WAI-ARIA e algumas diretivas, e tomam-se padrões e tecnologia acessíveis como
1 O ciclo de desenvolvimento considerado aqui para objeto de estudo baseia-se no ciclo de desenvolvimento da Microsoft Corporation (2009).
58
pedra ângular para um design em complacência a padrões. Uma prototipação de alta
fidelidade permite, neste estágio, que a UX possa ser implementada mais facilmente
sem que surjam maiores interferentes na experiência acessível.
A fase de implementação e verificação são intimamente relacionadas e
processam-se em conjunto. Inclui-se acessibilidade como parte da documentação
do produto de software sendo gerado, desenvolve-se uma codificação seguindo
boas práticas e empregando-se ferramentas de acessibilidade para assegurar um
desenvolvimento pautado dentro da perspectiva paradigmada.
No lançamento, todo processo planejado deve ser verificado se pode ser
considerado como tendo sido concluído para que seja processado com sucesso
a finalização da declaração de conformidade com padrões, um documento gerado
para comprovar a eficiente validade do emprego de acessibilidade no processo.
Por fim, fornece-se acesso a suporte acessível ao usuário na fase de suporte
e serviço, que inclui a participação no processo de gestão de incidentes para
identificar eventuais problemas que possam ocorrer com o produto no momento
em que o usuário tem acesso a toda plenitude do projeto desenvolvido. Atualiza-se
ainda a documentação acerca de acessibilidade para registrar novos serviços ou
funcionalidade que precisem ser incluídos no produto.
59
CAPÍTULO VI
7 Aplicação em estudos de caso
Para aplicar as proposições para um Paradigma de Orientação a Acessibilidade
no desenvolvimento de um estudo de caso, apresentam-se a seguir os passos do
desenvolvimento de um estudo de caso com enfoque em amplificação de acesso.
7.1 Estudo de caso — Konnect Eventos
V. Definição de plataforma e público-alvo
Neste momento, algumas considerações sobre qual a plataforma atendida, qual
o browser (ou browsers) que se pretente dar suporte, qual a resolução de tela do
usuário que será destina a aplicação em sua forma base, qual o público-alvo que se
almeja e as categorias de incapacidade enquadradas, como as que serão abrangidas
pelo alcance da aplicação, são alguns dos pontos que se pode detalhar.
Quadro 5 – Definição de plataforma e público-alvo para a aplicação.
Item Descrição
Plataforma Web (Ambiente desktop).
Agente de usuário alvoGoogle Chrome, com validação para a versão 37.0.
Resolução de tela 1280 x 1024 (em pixel).
Público-alvoEstudantes do Ensino Médio e respectiva comunidade acadêmica responsável pelo provimento de atividades para esses estudantes.
Categoria(s) de incapacidade enquadrada(s)
Todas (Visual, Auditiva, Motora, Cognitiva e Múltipla).
Fonte: Elaboração do autor.
60
VI. Design de UI considerando resultados de testes e validações
Como primeira consideração, o levantando de opções para a paleta de cores
do site é uma maneira de restringir um dos elementos mais limitantes, assim, para
minimizar interferências na abrangência da aplicação.
Através da ferramenta Contrast-A1, algumas cores são escolhidas e testadas
para compor, portanto, a paleta final.
Imagem 2 – Exemplificando a seleção de cores para formar uma paleta que atenda a variados problemas de percepção de cor.
Fonte: Elaboração do autor.
A paleta abaixo apresenta a seleção realizada da paleta de cores.
As combinações foram geradas de modo a garantir que o contraste apresentado
pelas cores seja suficiente para atingir o nível máximo de atendimento da diretiva 1.4
da WCAG 2.0, a qual requer que haja suficiente contraste entre as cores do texto e
do plano de fundo da página.
1 A ferramenta Contrast-A pode ser encontrada para utilização online a partir da URL <http://www.dasplankton.de/ContrastA/>.
61
Imagem 3 – Combinações de cores acessíveis.
Prosseguindo com a construção da interface do usuário,
Fonte: Elaboração do autor.
um primeiro protótipo
para a aplicação é desenvolvido para definir o endereçamento de especificações
para acessibilidade a serem incorporados.
A figura a seguir apresenta um protótipo de média fidelidade construído para
a página inicial do estudo de caso, uma plataforma para criação e promoção de
eventos, a plataforma fictícia Konnect Eventos.
62
Imagem 4 – Protótipo de média fidelidade da página inicial do Konnect Eventos.
Fonte: Elaboração do autor.
Aplicando algumas cores ao protótipo, temos o resultado abaixo. A título de análise,
vale mencionar que as cores não correspondem precisamente às definidas anteriormente.
Imagem 5 – Protótipo de alta fidelidade da página inicial da plataforma.
Fonte: Elaboração do autor.
63
Com a inclusão de cores no protótipo, alguns testes podem ser feitos a partir
da ferramenta Etre2, a qual permite simular o modo como indivíduos com deficiências
visuais como a deuteranopia (que é uma anomalia da visão que interfere com a
percepção da cor verde3), protanopia (anomalia da visão que interfere com a percepção
da cor vermelha4) e tritanopia (anomalia da visão que interfere com a percepção da
cor azul5) enchegariam a página.
Imagem 6 – Simulação de deuteranopia.
Fonte: Elaboração do autor.
2 A ferramenta Etre pode ser encontrada para utilização online a partir da URL <http://www.etre.com/tools/colourblindsimulator/> .3 “deuteranopia”, in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2013, http://www.priberam.pt/dlpo/deuteranopia [consultado em 26-09-2014].4 “protanopia”, in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2013, http://www.priberam.pt/dlpo/protanopia [consultado em 26-09-2014].5 “tritanopia”, in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2013, http://www.priberam.pt/dlpo/tritanopia [consultado em 26-09-2014].
64
Imagem 7 – Simulação de protanopia.
Imagem 8 –
Fonte: Elaboração do autor.
Simulação de tritanopia.
Fonte: Elaboração do autor.
Observando os resultados do caso apresentado, conclui-se que a utilização
das cores na aplicação não pode ser tomada como uma medida confiável para
distinguir, por exemplo, elementos ou seções do site, como se poderia intencionar.
65
Para indivíduos com impossibilidades relacionadas à percepção de cor, o uso da
cores pode, assim, comprovadamente, até prejudicar o entendimento sobre a relação
entre os elementos de uma página. No exemplo, os botões “Saiba mais” do item
“Eventos”, “Comitês” e “Palestrantes”, em especial o primeiro e o terceiro item, são
inconsistentemente percebidos de forma diferente.
O software Adobe® Photoshop®, uma das ferramentas de edição de imagens
mais utilizadas do mundo, também possui opções para simular os efeitos de diferentes
percepções ópticas das cores. No menu Visualizar (View), com a opção Prova de
cores (Proof colors) habilitada é possível, através do submenu Configurações de prova
(Proof setup) utilizar as opções de simulação referentes às anomalias protanopia e
deuteranopia, como pode ser visto na imagem abaixo.
Imagem 9 – Opções de configurações de prova de cores referente às analomalias deuteranopia e protanopia no Adobe® Photoshop®.
Fonte: Elaboração do autor.
A mérito de esclarecimento, o uso de cores não é proibido em projetos que
endereçam acessibilidade, mas a confiabilidade tão somente baseada na distinção
de elementos através da cor não deve ser empreendida, uma vez consideradas as
ressalvas levantadas.
66
VII. Transformar o planejamento visual da UI em uma UX
Diferentes ferramentas podem ser utilizadas durante as atividades de
transformação do planejamento visual da UI em uma UX. Para o estudo de caso aqui
apresentado, algumas delas, em certo grau incluíram:
Adobe® Dreamweaver® - possibilita que designers e desenvolvedores criem
sites baseados em padrões, desenvolvam páginas com sistemas de gerenciamento
de conteúdo e realizem testes de compatibilidade de navegador com precisão.
Adobe® Illustrator® - permite a criação de arte vetorial única para qualquer
projeto, disponibiliza precisão e potência com sofisticadas ferramentas de desenho.
Adobe® Photoshop® - permite a criação de imagens com padrão profissional
através das poderosas ferramentas de fotografia e recursos incríveis para proporcionar
seleções de imagem complexas, pintura realista, retoque inteligente e redefinição de
imagens digitais.
De maneira correspondente, também foram utilizadas, em diferentes momentos
das atividades desenvolvidas, as linguagens a seguir:
HTML - acrônimo para a expressão HyperText Markup Language, que significa
Linguagem de Marcação de Hipertexto, é uma linguagem de marcação utilizada para
produzir páginas da Web.
CSS - Cascading Style Sheets, Folhas de Estilo em Cascata (ou simplesmente
CSS), é utilizada para definir a apresentação de documentos escritos em uma
linguagem de marcação, como HTML, tendo como principal benefício a promoção
de uma separação entre o formato (estilo) e o conteúdo de um documento.
Dando continuidade ao estudo, iniciando o processo de codificação da UI,
podemos, por exemplo, inserir a funcionalidade de “Ir para o conteúdo principal”
com a inclusão, nas páginas da aplicação, do fragmento abaixo, preferencialmente,
no início de cada corpo dos documentos HTML.
<div id = “irParaConteudoPrincipal” role = “button”>
<a href = “#conteudoPrincipal”>Ir para o conteúdo principal</a>
</div>
67
O fragmento, que deve vir após a tag <body> dos documentos HTML, define um
elemento de divisão, div, e uma ancoragem, a. A div possui o identificador (opcional)
“irParaConteudoPrincipal” e contém um link com destino definido pelo atributo href
e a informação textual “Ir para o conteúdo principal”. O link, assim, apontará para
um elemento que represente uma âncora “conteudoPrincipal”, que, coerentemente,
estará no início da parte referente ao conteúdo principal do arquivo como esperado.
Logo, para o efetivo funcionamento do elemento descrito acima, o seguinte
fragmento apresenta a utilização de um identificador único denominado “conteudo-
Principal” posicionado onde se inicia a parte mais relevante da página.
<div id = “conteudoPrincipal” tabindex = “-1”>
Esse recurso, com importância pontualmente já descrita neste trabalho, tem o
objetivo de permitir que o usuário com esplanados tipos de deficiência possam ter
uma experiência de navegação mais produtiva e que, assim, os levará direto à razão
pela qual visitam a página, o conteúdo.
O controle de visibilidade do primeiro item descrito pode ser obtido através do
código CSS abaixo:
div#irParaConteudoPrincipal a {
position: absolute;
left: auto;
top: -100px;
width: 100%;
height: 30px;
background-color: white;
color: black;
padding: 0.5em;
text-align: center;
font-weight: bold;
display: block;
}
68
div#irParaConteudoPrincipal a:focus {
position: static;
width: 100%;
height: auto;
}
O código posiciona a div com o identificador “irParaConteudoPrincipal” fora
do quadro de visão da página (position: absolute; top: - 100px; left: auto;), define
as dimensões, nesse caso, para que a largura ocupe toda a extensão dentro do
corpo da página, ou seja, a largura do elemento representará a largura interna da
janela do navegador (width: 100%) e para que a altura seja de 30px (height: 30px;).
O plano de fundo do elemento é definido para a cor branca e a cor da fonte para
preta (background-color: white; color: black;). O elemento será rodeado por um
espaço para facilitar a separação visual de outros itens da página (padding: 0.5em6).
O texto será alinhado ao centro (text-align: center;) e a fonte estará em negrito (font-
weight: bold;). Por fim, para que todo o elemento seja interpretado como um bloco
que preenche a largura correspondente a todo o corpo da página, definimos a última
especificação da primeira regra do CSS (display: block;). A segunda regra do código
define o comportamento do elemento de ancoragem quando o foco passa a ser
atribuído a ele (a:focus{}). O fragmento faz com que o elemento oculto para a área de
visualização seja exibido ao ser reposicionado no topo da página (position: static;).
Vale acrescentar que atributos ARIA poderiam também ser incorporados ao
botão/link criado para a página, por exemplo, para facilitar, desse a modo, a respectiva
leitura da página por tecnologias assistivas como o leitor de tela JAWS®. Para ilustrar,
a abertura da tag div poderia ter o atributo role sendo inserido como abaixo.
<div id = “irParaConteudoPrincipal” role = “button”>
A seguir, pode-se observar o resultado da interação através da tecla Tab com a
aplicação; portanto, tornando o elemento visível no topo do site.
6 1 em corresponde ao tamanho da fonte utilizada para o elemento. Assim, se um elemento é exibido com uma fonte de 12 pt, ‘2 em’ corresponderia a um tamanho de 24 pt. O ‘em’ é uma unidade muito útil em CSS, uma vez que pode adaptar-se automaticamente ao tipo de fonte que o agente leitor da página utiliza.
69
Imagem 10 – Implementação da funcionalidade “Ir para o conteúdo principal”.
Fonte: Elaboração do autor.
Concluída a implementação da transformação do protótipo inicial da UI em
UX, o processo pode ser validado quanto à complacência a padrões utilizando, por
exemplo, a ferramenta de auditoria Accessibility Developer Tool, disponível para o
agente de usuário Google Chrome, e que, uma vez instalada, ao pressionar o atalho
Ctrl + Shift + I ou usar a respectiva opção do menu do navegador (para isso, confira
a imagem abaixo), dá acesso a um painel de auditoria.
Imagem 11 – Localizando as ferramentas do desenvolvedor no Google Chrome para auditoria da aplicação.
Fonte: Elaboração do autor.
70
Caso o painel de auditoria não apresente a opção de execução de auditoria em
acessibilidade, certifique-se de que a extensão encontra-se habilitada nas opções de
extensões do navegador.
Imagem 12 – Verificando se a extensão do Chrome, a Accessibility Developer Tools, encontra-se ativada.
Fonte: Elaboração do autor.
Para executar a auditoria na página utilizando a ferramenta, clica-se na aba
“Auditorias” (Audits) e aciona-se a opção “Executar” (Run) para iniciar.
Imagem 13 – Executando a auditoria de acessibilidade na página.
Fonte: Elaboração do autor.
A seguir, pode-se visualizar a página inicial da aplicação que, agora, possui a
barra de ferramentas do desenvolvedor com o resultado da auditoria.
71
Imagem 14 – Página inicial da aplicação exibindo o resultado da auditoria.
Fonte: Elaboração do autor.
Tal qual pode ser observado, a partir da imagem a seguir, os detalhes do
resultados indicam alertas para a presença de vários elementos que deveria ter um
grau de contraste maior para facilitar a visualização desses respectivos elementos
por indivíduos com baixa visão.
Além disso, há elementos invisíveis na página ou que estão sendo ocultados por
outro elemento.
Embora, os alertas não representem totalmente uma infração quanto aos padrões
indicados pela WCAG 2.0, os problemas sinalizados são conhecidos. Correspondem
ao grau de contraste dos botões (plano de fundo e texto deles) que não utilizaram as
cores coletadas e combinadas durante o “Design de UI considerando resultados de
testes e validações”.
O segundo ponto de alerta é um elemento sendo ocultado, este elemento é
a ancoragem implementada para a funcionalidade “Ir para o conteúdo principal” e
que, portanto, não precisa ser exibida para os indivíduos que podem, sem quaisquer
problemas, navegar e ir direto ao conteúdo central da página sem ter que passar por
todos os itens do menu, por exemplo, para chegar até lá utilizando a tecla Tab.
72
Imagem 15 – Detalhe do resultado da auditoria referente à página inicial.
VIII.
Fonte: Elaboração do autor.
Executar continuamente melhorias progressivas
Como forma de identificar fatores que agem negativamente sobre os princípios
base de acessibilidade, o estudo de caso deve passar por uma revista dos passos para
que assegure que os elementos apresentem aspectos que enriquecem e amplificam
o acesso da aplicação para mais indivíduos.
Outro recurso que pode ser utilizado neste momento, seria uma ferramente de
auditoria/validação diferente para tentar identificar eventuais problemas produzidos
durante o desenvolvimento. O Adobe® Dreamweaver®, um dos softwares mais
utilizados mundialmente para o design e desenvolvimento de páginas da web, possui
uma ferramenta de validação que utiliza os serviços de validação do W3C para
analisar o código produzido.
Imagem 16 – Enviando os dados de uma página para validação utilizando os serviços do W3C.
Fonte: Elaboração do autor.
73
Por fim, ao enviar os dados para validação, o resultado, por sua vez, não
apresentou erros ou alertas referentes a problemas encontrados na página inicial da
aplicação, como pode ser observado na imagem abaixo.
Imagem 17 – Resultado da validação utilizando o Adobe Dreamweaver.
Fonte: Elaboração do autor.
7.2 Estudo de caso II — Kanban (Amazing Med)
A análise do estudo de caso, a seguir, constitui-se de uma auditoria simples de
uma aplicação desenvolvida com recursos que atendem parcialmente às espectativas
de acessibilidade.
O Kanban (ou 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 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 e recepcionistas)
entre 25 a 65 anos de idade.
Uma série de procedimentos de teste de acessibilidade foi realizada para
identificar problemas referentes à acessibilidade do site.
Os apêndices I a VIII: apresentam o resultado desses testes automatizados de
forma meramente ilustrativa com base nos detalhados acima realizados em relação
ao estudo de caso I para demonstrar a eficiência de ferramentas teste na identificação
de interferentes para acessibilidade na plataforma em questão.
74
Utilizando ferramentas de validação e acessibilidade, abaixo, é possível
visualizar a página inicial da aplicação que agora possui a barra de ferramentas do
desenvolvedor com o primeiro resultado de auditoria.
Imagem 18 – Página inicial da aplicação exibindo resultado da auditoria.
Fonte: Elaboração do autor.
Tal qual pode ser observado a partir da imagem a seguir, os detalhes do
resultados indicam a presença de imagens sem a utilização do atributo “Alt” para
melhor identificá-las; e que vários elementos deveria ter um grau de contraste maior
para facilitar a visualização desses respectivos elementos por indivíduos com baixa
visão. Além disso, há elementos invisíveis na página ou que estão sendo ocultados
por outro elemento também.
75
Imagem 19 – Detalhes da auditoria da aplicação Kanban.
Fonte: Elaboração do autor.
O exemplo, ilustra a facilidade de se identificar problemas que podem
comprometer a eficiência da página em atender um público amplo. As recomendações
para os problemas apresentados, caso sejam seguidas, podem significar uma
melhoria que torna a página complacente a diversos padrões e que contribuiria para
incluí-la em um conjunto, ainda minoritário, de projetos de sucesso em acessibilidade
disponíveis na Web.
76
CONCLUSÃO
8 Considerações finais
Diante do exposto, faz-se possível concluir que acessibilidade não significa
tornar algo estático, lento ou simples.
Com um pouco de esforço é possível produzir experiências dinâmicas e inclusive
UI visualmente mais atrativas.
Os primeiros passos não requerem ferramentas especiais ou grande expertise.
Experimentos podem ser feitos apenas desplugando o mouse, por exemplo, para se
ter novas alternativas de análise sobre interatividade.
Uma diferença real na maneira como os indivíduos com deficiência experimentam
a Web é feita através da concepção e construção de sites que permitam que indivíduos
com deficiência possam ter acesso e utilizá-los de forma tão eficaz como as sem
deficiência. Ao encontra-se no quadro de responsabilidade por cuidar da contrução
de sites para qualquer organização, o cumprimento de complacência a padrões deve
ser tratado como uma exigência de alta prioridade.
Para tanto, sob a perspectiva do estudo realizado, justificou-se aqui a viabilidade
e a necessidade de se construir um Paradigma Orientado a Acessibilidade que
possa atender às demandas de desenvolvimento que privilegiem a igualdade de
oportunidades na Web.
77
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 10520:2002 - Informação e documentação: Citações em documentos - Apresentação. Rio de Janeiro: ABNT, 2002. 7p.
____. NBR 10719:2011 - Informação e documentação: Relatório técnico e ou científico - Apresentação. Rio de Janeiro: ABNT, 2011. 11p.
____. NBR 12225:2004 - Informação e documentação: Lombada - Apresentação. Rio de Janeiro: ABNT, 2004. 3p.
____. NBR 14724:2011 - Informação e documentação: Trabalhos acadêmicos - Apresentação. Rio de Janeiro: ABNT, 2011. 11p.
____. NBR 5892:1989 - Norma para datar. Rio de Janeiro: ABNT, 1989. 2p.
____. NBR 6023:2002 - Informação e documentação: Numeração progressiva das seções de um documento - Apresentação. Rio de Janeiro: ABNT, 1 de fevereiro de 2012. 4 p.
____. NBR 6023:2002 - Informação e documentação: Referências - Elaboração. Rio de Janeiro: ABNT, 2002. 24p.
____. NBR 6023:2002 - Informação e documentação: Referências - Elaboração. Rio de Janeiro: ABNT, 2012. 24 p.
____. NBR 6024:2012 - Informação e documentação: Numeração progressiva das seções de um documento - Apresentação. Rio de Janeiro: ABNT, 2012. 4p.
____. NBR 6025:2002 - Informação e documentação: Revisão de originais e provas. Rio de Janeiro: ABNT, 2002. 6p.
____. NBR 6027:2013 - Informação e documentação: Sumário - Apresentação. Rio de Janeiro: ABNT, 2013. 3p.
____. NBR 6028:2003 - Informação e documentação: Resumo - Apresentação. Rio de Janeiro: ABNT, 2003. 2p.
____. NBR 6033:1989 - Ordem alfabética. Rio de Janeiro: ABNT, 1989. 5p.
____. NBR 6034:2005 - Informação e documentação: Índice - Apresentação. Rio de Janeiro: ABNT, 2005. 4p.
BITTNER, Kurt; SPENCE, Ian. Managing Iterative Software Development Projects. Addison-Wesley Professional, 27 de jun. de 2006. 672p.
78
BRASIL. 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. Diário Oficial [da] República Federativa do Brasil, Brasília. Disponível em: <https://www.presidencia.gov.br/ccivil_03/Leis/L10098.htm>. Acesso em: 10 setembro de 2014.
BRINCK, Tom; GERGLE, Darren; WOOD, Scott D. Usability for the Web. Morgan Kaufmann, 15 de outubro de 2001.
BUDIU, Raluca; NIELSEN, Jakob. Mobile Usability. Berkeley, CA: New Riders, 10 de outubro de 2012.
COLOR FILTER. Colorblind Web Page Filter. Disponível em: <http://colorfilter.wickline.org/>. Acesso em: 10 setembro de 2014.
CONNOR, Joshue O. Pro HTML5 Accessibility: Building an Inclusive Web. Apress, 21 de março de 2012.
CUNNINGHAM, Katie. Accessibility Handbook. O’Reilly Media, Inc. 4 de set. de 2012.
DUFFY, Jill. Dragon NaturallySpeaking 12 Premium. PC Mag.com. Editor’s Choice. 14 de setembro de 2012. Disponível em: <http://www.pcmag.com/article2/0,2817,2409718,00.asp>. Acesso em: 25 de agosto de 2014.
FEATHERSTONE, Derek. Foundations of UX: Accessibility. Disponível em: <http://www.lynda.com/Web-Accessibility-tutorials/Foundations-UX-Accessibility/156957-2.html>. Acesso em: 17 de agosto de 2014.
FERREIRA, Aurélio B. H. Miniaurélio: o dicionário da língua portuguesa. ANJOS, Margarida; FERREIRA, Marina Baird. (Coord.). 6. ed. Curitiba: Positivo, 2006.FREEDOM SCIENTIFIC. Blindness Solutions: JAWS®. Disponível em: <http://www.freedomscientific.com/Products/Blindness/Jaws>. Acesso em: 11 de setembro de 2014.
GALITZ, O. Wilbert. The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques. 3. ed. John Wiley & Sons, 16 de abril de 2007.
GARRISH, Matt. Accessible EPUB 3. O’Reilly Media, Inc., 10 de fevereiro de 2012.
GOOGLE. Software e serviços de legenda. Disponível em: <https://support.google.com/youtube/answer/100076?hl=pt-BR>. Acesso em: 20 de setembro de 2014.
HALL, Ben; MCWHERTER, Jeff. Testing ASP.NET Web Applications. Wrox, 26 de outubro de 2009.
HAMANN, Annika. Contrast-A: Find acessible color combinations. Disponível em: <http://www.dasplankton.de/ContrastA/>. Acesso em: 10 setembro de 2014.
79
HOGAN, Brian P. HTML5 and CSS3, 2nd Edition - Level Up with Today’s Web Technologies. Pragmatic Bookshelf, 30 de outubro de 2013.
ISKANDAR, Jamil Ibrahim. Normas da ABNT: comentadas para trabalhos científicos. 2. ed. Curitiba: Juruá, 2004.KENDRICK, Tom. Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project. AMACOM, 2003. 362p.
KIOSKEA. Subtitle Workshop. Publicado em: 30 de maio de 2014. Disponível em: <http://pt.kioskea.net/download/baixaki-9815-subtitle-workshop>. Acesso em: 15 de setembro de 2014.
KRUG, Steve. Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability. New Riders, 24 de dezembro de 2013.
LEVINSON, Deborah; SCHLATTER, Tania. Visual Usability. Waltham, MA: Morgan Kaufmann, 21 de março de 2013.
LORANGER, Hoa; Nielsen, Jakob. Prioritizing Web Usability. New Riders. 20 de abril de 2006.
MICROSOFT CORPORATION. Engineering Software for Accessibility. Microsoft Press. 15 de junho de 2009.
NIELSEN, Jakob. Designing Web Usability. Peachpit Press, 20 de dezembro de 1999.
____. Usability Engineering. Morgan Kaufmann. 11 de novembro de 1994.
OSBORN, Jeremy; SMITH, Jennifer. Web Design with HTML and CSS Digital Classroom. John Wiley & Sons, 3 de novembro de 2014.
PETERS, Dorian. Interface Design for Learning: Design Strategies for Learning Experiences. New Riders, 16 de dez. de 2013.
POGUE, David. Reliable Dictation, Down to a ‘T’. The New York Times. 28 de julho 2010. Disponível em: <http://www.nytimes.com/2010/07/29/technology/personaltech/29pogue.html?pagewanted=all&_r=0>. Acesso em: 25 de agosto de 2014.
PORTAL DA ACESSIBILIDADE. Glossário. Disponível em: <http://portaldaacessibilidade.wordpress.com/glossario/>. Acesso em: 25 de setembro de 2014.
PREECE, Jenny; SHARP, Helen; ROGERS, Yvonne. Interaction Design: Beyond Human-Computer Interaction. 2. ed. John Wiley & Sons, 23 de março de 2007.
80
QUEIROZ, Marco Antonio. O que é um Display Braille? Publicado em: 28 de abril de 2008. Disponível em: <http://www.acessibilidadelegal.com/33-display-braille.php>. Acesso em: 20 de setembro de 2014.
RUSH, Sharron; SLATIN, John M. Maximum Accessibility: Making Your Web Site More Usable for Everyone. Boston, MA: Addison-Wesley Professional, 20 de setembro de 2002.
SIKOS, Leslie F. Web Standards: Mastering HTML5, CSS3, and XML. Apress, 18 de novembro de 2011.
THATCHER, Jim et al. Web Accessibility: Web Standards and Regulatory Compliance. friends of ED, 24 de jul. de 2006.
UNRIC. Alguns Factos e Números sobre as Pessoas com Deficiência. Disponível em: <http://www.unric.org/pt/pessoas-com-deficiencia/5459>. Acesso em: 15 de setembro de 2014.
WEBAIM. WAVE - Web acessibility evaluation tool. Disponível em: <http://wave.webaim.org/>. Acesso em: 10 setembro de 2014.
WEST, Adrian W. Practical HTML5 Projects. Apress, 23 de maio de 2012. 482p.
WILSON, Chauncey. User Interface Inspection Methods. Morgan Kaufmann, 15 de nov. de 2013. 146p.
WORLD WIDE WEB CONSORTIUM. About W3C. Disponível em: <http://www.w3.org/Consortium/>. Acesso em: 10 de setembro de 2014.
____. About W3C. Publicado em: 2012. Disponível em: <http://www.w3.org/WAI/highlights/archive#x20140320a>. Acesso em: 10 de setembro de 2014.
____. Accessible Rich Internet Applications (WAI-ARIA) 1.0. Disponível em: <http://www.w3.org/TR/wai-aria/>. Acesso em: 10 de setembro de 2014.
____. Introduction to Web Accessibility. Publicado em fevereiro de 2005, atualizado em setembro de 2005. Disponível em: <http://www.w3.org/WAI/intro/accessibility.php>. Acesso em: 5 de setembro de 2014.
____. WAI-ARIA 1.0 User Agent Implementation Guide. Disponível em: <http://www.w3.org/TR/wai-aria-implementation/>. Acesso em: 10 de setembro de 2014.
____. Web Content Accessibility Guidelines 1.0. 5 de maio de 1999. Disponível em: <http://www.w3.org/TR/WAI-WEBCONTENT/>. Acesso em: 17 de agosto de 2014.
81
GLOSSÁRIO
Acessibilidade: condição para utilização, com segurança e autonomia, total ou assistida, dos espaços, mobiliários e equipamentos urbanos, das edificações, dos serviços de transporte e dos dispositivos, sistemas e meios de comunicação e informação, por pessoa com deficiência ou mobilidade reduzida.
Acessível: diz-se do conteúdo que pode ser acessado por alguém com alguma incapacidade ou deficiência.
Adobe® Dreamweaver®: possibilita que designers e desenvolvedores criem sites baseados em padrões, desenvolvam páginas com sistemas de gerenciamento de conteúdo e realizem testes de compatibilidade de navegador com precisão.
Adobe® Illustrator®: permite a criação de arte vetorial única para qualquer projeto, disponibiliza precisão e potência com sofisticadas ferramentas de desenho.
Adobe® Photoshop®: permite a criação de imagens com padrão profissional através das poderosas ferramentas de fotografia e recursos incríveis para proporcionar seleções de imagem complexas, pintura realista, retoque inteligente e redefinição de imagens digitais.
Agente de usuário: navegador ou browser, é uma aplicação de software que funciona como um cliente em um protocolo de rede; o nome é geralmente aplicado para se referir a aplicativos que acessam a World Wide Web.
Amplificador de tela: programa de computador que amplia uma porção da tela. Os ampliadores de tela são utilizados sobretudo por pessoas com baixa visão.
Arte ASCII: arte ASCII refere-se ao conjunto de caracteres e símbolos combinados para criar uma imagem.
Braille: sistema que adota seis pontos salientes, em disposições diferentes, para representar letras e algarismos, forma um alfabeto convencional cujos caracteres se indicam por pontos em alto relevo para que os cegos possam ler por meio do tato.
CSS: Cascading Style Sheets, Folhas de Estilo em Cascata (ou simplesmente CSS), é uma linguagem de estilo utilizada para definir a apresentação de documentos escritos em uma linguagem de marcação, como HTML ou XML, sendo o principal benefício a promoção da separação entre o formato e o conteúdo de um documento.
Deficiência auditiva: perda bilateral, parcial ou total, de quarenta e um decibéis (dB) ou mais, aferida por audiograma nas frequências de 500Hz, 1.000Hz, 2.000Hz e 3.000Hz.
Deficiência cognitiva: funcionamento intelectual significativamente inferior à média, com manifestação antes dos dezoito anos e limitações associadas a duas ou mais áreas de habilidades adaptativas, tais como: comunicação, cuidado pessoal, habilidades sociais, utilização dos recursos da comunidade, saúde, segurança, habilidades acadêmicas, lazer e trabalho.
82
Deficiência física: alteração completa ou parcial de um ou mais segmentos do corpo humano, acarretando o comprometimento da função física, apresentando-se sob a forma de paraplegia, paraparesia, monoplegia, monoparesia, tetraplegia, tetraparesia, triplegia, triparesia, hemiplegia, hemiparesia, ostomia, amputação ou ausência de membro, paralisia cerebral, nanismo, membros com deformidade congênita ou adquirida, exceto as deformidades estéticas e as que não produzam dificuldades para o desempenho de funções.
Deficiência múltipla: associação de duas ou mais deficiências.
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 for igual ou menor que 60 graus; ou a ocorrência simultânea de quaisquer das condições anteriores.
Deficiência: restrição ou impedimento de longo prazo, de natureza física, mental, intelectual ou sensorial, para desenvolver habilidades consideradas normais para a maioria dos seres humanos.
Design: design, ou desenho ou modelo é a configuração, concepção, elaboração e especificação de um artefato. É uma atividade técnica e criativa, normalmente orientada por uma intenção ou objetivo, ou para a solução de um problema.
Display Braille: é um hardware que exibe dinamicamente em Braille a informação da tela ligado a uma porta de saída do computador. Pode-se definir Display Braille como um dispositivo de saída táctil para visualização das letras no sistema Braille. Por intermédio de um sistema electromecânico, conjuntos de pontos são levantados e abaixados, conseguindo-se assim uma linha de texto em Braille.
Folha de estilo: ima folha de estilo é um conjunto de declarações que especificam a apresentação de um documento. As folhas de estilo podem ter três origens: ter sido escritas por fornecedores de conteúdo Web; criadas por usuários; ou estarem integradas nos agentes de usuário.
Framework: em desenvolvimento de software, é uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica.
Hipertexto: Hipertexto é o termo que remete a um texto em formato digital, ao qual se agregam outros conjuntos de informação na forma de blocos de textos, palavras, imagens ou sons, cujo acesso se dá através de referências específicas denominadas hiperlinks, ou simplesmente links. Esses links ocorrem na forma de termos destacados no corpo de texto principal, ícones gráficos ou imagens e têm a função de interconectar os diversos conjuntos de informação, oferecendo acesso sob demanda as informações que estendem ou complementam o texto principal.
HTML: acrônimo para a expressão HyperText Markup Language, que significa Linguagem de Marcação de Hipertexto, é uma linguagem de marcação utilizada para produzir páginas da Web.
Imagem: descrição armazenada de uma figura gráfica, como um conjunto de valores de brilho e cor de pixels ou como um conjunto de instruções para a reprodução de uma figura.
83
Incapacidade: desvantagem individual, resultante do impedimento ou da deficiência, que limita ou impede o cumprimento ou desempenho de um papel social, dependendo da idade, sexo e fatores socioculturais.
JAWS™: software leitor de tela (ver Leitor de tela).
Leitor de tela: é um software usado para obter resposta do computador por meio sonoro, usado principalmente por deficientes visuais. Também pode ser usado apenas para uma maior eficiência e conforto do usuário.
Multimídia: combinação de som, elementos gráficos, animação e vídeo. No universo dos computadores, multimídia é um subconjunto de hipermídia, que combina os elementos acima mencionados ao hipertexto.
Nanismo ou baixa estatura: condição de tamanho de uma pessoa cuja altura é muito menor (aproximadamente 20%) do que a média de altura das pessoas de mesma idade. Considera-se pessoa de baixa estatura aquela que mede até 1,40m quando adulta.
PHP: um acrônimo recursivo para PHP: Hypertext Preprocessor, é uma linguagem de programação de computadores interpretada, livre e muito utilizada para gerar conteúdo dinâmico na World Wide Web, como por exemplo a Wikipédia.
Pixel: Abreviatura de Picture Element. Um pixel é o menor elemento em um dispositivo de exibição ao qual é possível atribuir uma cor.
Protótipo: na informática, protótipo é um sistema/modelo (pode ser um site web ou um software) normalmente sem as funcionalidades inteligentes (acesso a base de dados, etc), apenas com as funcionalidades gráficas, e algumas funcionalidades básicas para o funcionamento do próprio protótipo. Utilizado geralmente para aprovação de quem vai solicitar o sistema.
Script: código ou programa escrito em uma linguagem de programação de uso especial.
Software: software, ou suporte lógico é uma sequência de instruções a serem seguidas e/ou executadas, na manipulação, redirecionamento ou modificação de um dado/informação ou acontecimento. Software também é o nome dado ao comportamento exibido por essa sequência de instruções quando executada em um computador ou máquina semelhante além de um produto desenvolvido pela Engenharia de software, e inclui não só o programa de computador propriamente dito, mas também manuais e especificações.
Tecnologia Assistiva: todo produto, recurso, metodologia, estratégia, prática ou serviço que vise promover a funcionalidade, relacionada à atividade e participação, de pessoas com deficiência, incapacidades ou mobilidade reduzida, visando sua autonomia, independência, qualidade de vida e inclusão social por meio da ampliação de sua comunicação, mobilidade, controle do ambiente, habilidades de seu aprendizado e trabalho.
Usabilidade: facilidade na utilização de uma ferramenta ou objecto para realizar uma tarefa específica e importante.
84
Usuários: são indivíduos ou organizações que utilizam algum tipo de serviço. Podem ser classificados como usuárioss comuns, aqueles que são agentes externos ao sistema do qual usufruem para realizar determinadas tarefas, ou como administradores, programadores e analistas de sistemas.
W3C: World Wide Web Consortium, é um consórcio internacional com cerca de 300 membros, que agrega empresas, órgãos governamentais e organizações independentes, e que visa desenvolver padrões para a criação e a interpretação de conteúdos para a Web. Foi fundado por Tim Berners-Lee em 1994 para levar a Web ao seu potencial máximo, por meio do desenvolvimento de protocolos comuns e fóruns abertos que promovam a sua evolução e assegurem a sua interoperabilidade.
Web Accessibility Initiative: Iniciativa para Acessibilidade na Web, a WAI é um movimento do W3C que visa melhorar a acessibilidade da World Wide Web (WWW) para pessoas com deficiências.
Web Design: é uma extensão do design, onde se foca a criação de web sites e documentos disponíveis na Internet. O Web design tende à construção de páginas web de diversas áreas técnicas, além do design propriamente dito. Áreas como a arquitetura da informação, programação, usabilidade, acessibilidade, entre outros. A preocupação fundamental do web designer é agregar os conceitos de usabilidade com o planeamento da interface, garantindo que o utilizador final atinja os seus objetivos de forma agradável e intuitiva no site criado.
Web: (ver World Wide Web).
Windows: Um sistema operacional introduzido pela Microsoft Corporation em 1983. O Windows é um ambiente de multitarefa com interface gráfica com o usuário que funciona em computadores baseados no MS-DOS (Windows e Windows for Workgroups) e como um sistema operacional autônomo, estações de trabalho e servidores de rede.
World Wide Web: World Wide Web, ou simplesmente Web, é um sistema de documentos hipertexto ligados entre si e que são acessíveis por via da Internet. Utilizando um web browser, um indivíduo pode ver páginas Web que contêm uma variedade de informação em diversos formatos, incluindo texto, imagem e vídeo. A navegação ente páginas é feita através das chamadas hiperligações. Ao contrário do que é normalmente pensado, Internet e Web não são a mesma coisa. A Internet é o hardware onde executa-se a Web. A Web é o conteúdo, mais precisamente, um serviço (ou aplicação) que está sendo executado nesse hardware. O primeiro protótipo da Web foi revelado ao público em 1990 e foi criado por dois cientistas informáticos do CERN (Organisation Européenne pour la Recherche Nucléaire, Organização Europeia para a Pesquisa Nuclear), o britânico Sir Tim Berners-Lee e o belga Robert Cailliau.
85
APÊNDICES
APÊNDICE I – Resultado de checagem a partir da ferramenta AChecker da página principal de internações da aplicação Kanban apresentando a ausência de problemas com a complacência à WCAG 2.0.
86
APÊNDICE II – Página de gráficos referentes a dados das internações em relação a especialidades, situações e estados de atenção com a inclusão de conteúdo totalmente inacessível.
87
APÊNDICE III – Página de gráficos referentes a dados das internações em relação a especialidades, situações e estados de atenção com a inclusão de conteúdo totalmente inacessível (APÊNDICE II) sendo visualizada a partir da perspectiva gerada pela extensão Chrome Shades disponível no navegador Chrome.
88
APÊNDICE IV – Auditoria utilizando o Accessibility Developer Tools na página de login do sistema Kanban indica que elementos como a div que insere o copyright da página não possui contraste suficiente em relação ao plano de fundo de acordo com a análise realizada.
89
APÊNDICE V – Resultado da validação da página principal de internações da aplicação Kanban 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).
90
APÊNDICE VI – Página de cartões 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
APÊNDICE VII – Página de cartões 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 (APÊNDICE VI) 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
APÊNDICE VIII – Página principal de internações do sistema Kanban 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.
ANEXOS
ANEXO I – Navegação pelo site do Google Maps utilizando o Dragon® NaturallySpeaking®.
Fonte: NUANCE. Disponível em: <http://www.nuance.com/for-individuals/by-product/dragon-for-pc/premium-version/index.htm>. Acesso em: 11 de setembro de 2014.
94
ÍNDICE
AAccessibility Developers Tools 52acessibilidade 20, 21, 22–21, 22, 22, 22, 22, 23, 24, 25, 26, 29, 31, 32, 33, 36, 37, 38, 39, 42, 42–44,
43, 44, 46, 51, 52, 53, 53–54, 54, 55, 56, 57, 58, 61, 65, 70, 72, 73, 75, 76acessível 24, 25, 31, 32, 36, 37–36, 37, 40, 45, 55, 56, 58–57, 58Benefícios 32Boas práticas 39Desvantagens 33Fontes de recursos sobre acessibilidade 44Legislação 42Mitos sobre acessibilidade 31
AChecker 54Adobe® Dreamweaver® 66, 72Adobe® Illustrator® 66Adobe® Photoshop® 65, 66ARIA 36, 37, 53, 57, 68
Accessible Rich Internet Applications 36WAI-ARIA 36, 37, 57
ATAG 36Authoring Tool Accessibility 36
Auditoria 52
BBraille 46, 47, 48
CChromeShades 52ChromeVis 52ChromeVox 48, 52Ciclo de desenvolvimento 57Color Filter 53Compatibilidade de dispositivos 34complacência a padrões 24, 34, 39, 42, 54, 55, 58–57, 69, 76Confusão 35Contrast-A 53, 60Convenção 35CSS 66, 67, 68, 68–75
Cascading Style Sheets 66Folhas de Estilo 66
DDeficiência 27
Deficiência auditiva 27Deficiência física 27Deficiência mental 27Deficiência múltipla 27Deficiência permanente 27Deficiência visual 27
Definição da plataforma e público-alvo 55
95
Design 56, 60, 71Design de UI considerando resultados de testes e validações 56, 60, 71deuteranopia 63, 65Diretivas 34, 37Displays Braille 46Dragon® NaturallySpeaking® 49, 50
EEstudo de caso 59, 73Etre 54, 63Executar continuamente melhorias progressivas 56, 72
FFacilidade de manutenção 35Ferramentas para teste de acessibilidade 53
HHTML 66, 67
HyperText Markup Language 66
IIncapacidade 27
Auditiva 29Cognitiva 29Motora 29Visual 28
independência de dispositivos 24
KKanban 73, 75Konnect Eventos 59, 61, 62
Lleitor de tela 47, 48, 68
Leitores de tela 46leitura de tela 47, 48
MMenos código 35
PPadrão 35Paradigma de Orientação a Acessibilidade 20, 21, 22, 55, 59protanopia 63, 64, 65protótipo 61, 62, 63, 69
96
RReconhecimento de Voz 49
SSearch Engine Optimization 35Seção 508 42, 43, 44Sim Daltonism 54Subtitle Workshop 49
TTecnologia Assistiva 24
AT 24, 46ATs 25, 46tecnologias assistivas 21, 22, 39, 55, 68
Transformar o planejamento visual da UI em uma UX 56, 66tritanopia 63, 64
UUAAG
User Agent Accessibility Guidelines 36UI 20, 22, 53–54, 56, 60, 66, 69, 71, 76
Interface do Usuário 22interfaces do usuário 20
usabilidade 24, 29, 30, 44, 51UX 22, 48, 50, 56, 58–57, 66, 69
Experência do Usuário 22
WWave 54WCAG 36, 37, 38, 54, 60, 71
WCAG 1.0 37, 54WCAG 2.0 38, 60, 71Web Content Accessibility Guidelines 36, 37, 38
World Wide Web Consortium 24, 35W3C 35, 36, 37, 38, 44, 51, 53, 72