proposiÇÃo para um paradigma de orientaÇÃo a acessibilidade

PROPOSIÇÃO PARA UM PARADIGMA DE ORIENTAÇÃO A ACESSIBILIDADE

YSTALLONNE CARLOS DA SILVA ALVES

NATAL/RN2014

ii



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


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.


NATAL/RN2014

iv



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.


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


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


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.


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,


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.


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.


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.


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 –


Simulação de tritanopia.


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


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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