UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ CÂMPUS CORNÉLIO PROCÓPIO
DIRETORIA DE GRADUAÇÃO E EDUCAÇÃO PROFISSIONAL
CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
ALLAN ASLLEY KREPSKY
EVOLUÇÃO DA ACESSIBILIDADE NA WEB: um levantamento da
implementação de requisitos de acessibilidade em aplicações web
TRABALHO DE CONCLUSÃO DE CURSO
CORNÉLIO PROCÓPIO 2015
ALLAN ASLLEY KREPSKY
EVOLUÇÃO DA ACESSIBILIDADE NA WEB: um levantamento da
implementação de requisitos de acessibilidade em aplicações Web
Trabalho de Conclusão de Curso de graduação, apresentado à disciplina de Trabalho de Conclusão de Curso II, do curso de Tecnologia e Análise e Desenvolvimento de Sistemas da Coordenação de Informática – COINF - da Universidade Tecnológica Federal do Paraná – UTFPR, como requisito parcial para a obtenção do título de Tecnólogo.
Orientador: Prof. Dr. Willian Massami Watanabe
CORNÉLIO PROCÓPIO 2015
Dedico este trabalho a todos que de forma indireta ou direta contribuíram para a execução do mesmo.
AGRADECIMENTOS
Certamente estes parágrafos não irão atender a todas as pessoas que fizeram parte dessa importante fase da minha vida. Portanto, desde já peço desculpas àqueles que não estão presentes entre essas palavras, mas elas podem estar certas que fazem parte do meu pensamento e da minha gratidão.
Reverencio o Prof. Dr. Willian Massami Watanabe, pela sua dedicação, paciência e pela orientação, e por meio dele, eu me reporto a toda a comunidade da Universidade Tecnológica Federal do Paraná (UTFPR) pelo apoio incondicional.
Aos meus colegas de sala gostaria de externar minha satisfação de poder conviver com eles durante a realização deste estudo.
A Secretaria do Curso, pela cooperação.
Agradeço aos especialistas e professores da banca examinadora pela atenção e contribuição dedicadas a este estudo.
Gostaria de deixar registrado também, o meu reconhecimento à minha família, pois acredito que sem o apoio deles seria muito difícil vencer esse desafio.
Enfim, a todos os que por algum motivo contribuíram para a realização desta pesquisa.
“Só se pode alcançar um grande êxito quando nos mantemos fiéis a nós mesmos”. (NIETZSCHE, Friedrich).
RESUMO
KREPSKY, Allan. EVOLUÇÃO DA ACESSIBILIDADE NA WEB: um levantamento
da implementação de requisitos de acessibilidade em aplicações web. 2015. 79
f. Trabalho de Conclusão de Curso (Graduação) – Tecnologia em Análise e Desenvolvimento de Sistemas. Universidade Tecnológica Federal do Paraná. Cornélio Procópio, 2015.
A comunidade Web tem se esforçado cada vez mais para permitir o acesso de informações a pessoas portadoras de deficiência. Contudo, a implementação de tecnologias que promovem a acessibilidade da forma correta requer o conhecimento de uma série de diretrizes e especificações elaboradas pelo W3C (World Wide Web Consortium). Essas informações em conjunto com a conscientização de acessibilidade na Web encontram como obstáculo a ausência de interesse de desenvolvedores sobre o tema. Esse fato é agravado quando levado em consideração aplicações ricas de Internet, as chamadas RIAs (Rich Internet Applications), que possibilitam a implementação de mecanismos sofisticados de interação do usuário com a interface. Buscando auxiliar o desenvolvimento de conteúdo Web acessível para RIAs, a WAI (Web Accessibility Initiative) elaborou a especificação ARIA (Accessible Rich Internet Applications). Este trabalho tem por objetivo investigar a evolução da disponibilidade de conteúdo acessível, segundo a especificação ARIA. Para tal, foi desenvolvido um script de monitoramento da evolução da utilização de alguns elementos e atributos HTML (HyperText Markup Language), de acordo com as especificações ARIA e WCAG 2.0 (Web Content Accessibility Guidelines). Assim, foi realizado o monitoramento em uma amostra de websites, durante um determinado período de tempo. De acordo com os dados obtidos, foi observado que, apesar da disponibilidade dos documentos ARIA e WCAG 2.0, notou-se um avanço pequeno, porém significativo de sua utilização.
ABSTRACT
KREPSKY, Allan. EVOLUTION OF ACCESSIBILITY IN THE WEB: a survey of the
implementation of accessibility requirements in web applications. 2015. 79 f.
Trabalho de Conclusão de Curso (Graduação) – Tecnologia em Análise e Desenvolvimento de Sistemas. Universidade Tecnológica Federal do Paraná. Cornélio Procópio, 2015.
The Web community has struggled more and more to allow the access for digital information to people with disabilities. However, the correct implementation of technologies that promote accessibility requires that Web developers have the knowledge of a serie of guidelines and specifications elaborated by the W3C (World Wide Web Consortium). This information, together with the Web Accessibility culture, encounter as an obstacle the lack of interest from developers on the subject. This fact is compounded when taken into account the rich Internet applications, RIAs (Rich Internet Applications), which enable user interaction with the interface. In order to assist the implementation of accessible Web content in RIAs, the WAI (Web Accessibility Initiative) elaborated the specification ARIA (Accessible Rich Internet Applications). This study has the objective of investigating the evolution of the Web accessibility, according to the ARIA specification. To this end, a script was developed to monitor the evolution of the use of some elements and attributes HTML (HyperText Markup Language), according to the ARIA specifications and WCAG 2.0 (Web Content Accessibility Guidelines). The script was executed to monitor a sample websites for a certain period of time. According to the data obtained, it was observed that, despite the availability of ARIA and WCAG 2.0 documents, there were small improvements in accessibility requirements in Web applications
LISTA DE FIGURAS
FIGURA 1 – REPRESENTAÇÃO DO MODELO DA WAI... 21 FIGURA 2 – INTERAÇÃO DE AMBIENTES ATRAVÉS DO MÉTODO
LISTA DE GRÁFICOS
GRÁFICO 1 – ELEMENTOS DE CABEÇALHO DO GOOGLE... 48
GRÁFICO 2 – ELEMENTOS DE CABEÇALHO DO FACEBOOK... 48
GRÁFICO 3 – ELEMENTOS DE CABEÇALHO DO YOUTUBE... 49
GRÁFICO 4 – ELEMENTOS DE CABEÇALHO DO YAHOO... 49
GRÁFICO 5 – ELEMENTOS DE CABEÇALHO DO WIKIPÉDIA... 50
GRÁFICO 6 – ELEMENTOS DE CABEÇALHO DO TWITTER... 50
GRÁFICO 7 – ELEMENTOS DE CABEÇALHO DO LIVE... 51
GRÁFICO 8 – ELEMENTOS DE CABEÇALHO DO SINA... 51
GRÁFICO 9 – ELEMENTOS DE CABEÇALHO DO EBAY... 52
GRÁFICO 10 – ELEMENTOS DE CABEÇALHO DO YANDEX... 52
GRÁFICO 11 – ELEMENTOS DE IMAGEM DO GOOGLE... 54
GRÁFICO 12 – ELEMENTOS DE IMAGEM DO FACEBOOK... 54
GRÁFICO 13 – ELEMENTOS DE IMAGEM DO YOUTUBE... 55
GRÁFICO 14 – ELEMENTOS DE IMAGEM DO YAHOO... 55
GRÁFICO 15 – ELEMENTOS DE IMAGEM DO WIKIPÉDIA... 56
GRÁFICO 16 – ELEMENTOS DE IMAGEM DO TWITTER... 56
GRÁFICO 17 – ELEMENTOS DE IMAGEM DO LIVE... 57
GRÁFICO 18 – ELEMENTOS DE IMAGEM DO SINA... 57
GRÁFICO 19 – ELEMENTOS DE IMAGEM DO EBAY... 58
GRÁFICO 20 – ELEMENTOS DE IMAGEM DO YANDEX... 58
GRÁFICO 21 – ELEMENTOS DE FORMULÁRIO DO GOOGLE... 60
GRÁFICO 22 – ELEMENTOS DE FORMULARIODO FACEBOOK... 60
GRÁFICO 23 – ELEMENTOS DE FORMULARIO DO YOUTUBE... 61
GRÁFICO 24 – ELEMENTOS DE FORMULARIO DO YAHOO... 61
GRÁFICO 25 – ELEMENTOS DE FORMULARIO DO WIKIPEDIA... 62
GRÁFICO 26 – ELEMENTOS DE FORMULARIO DO TWITTER... 62
GRÁFICO 27 – ELEMENTOS DE FORMULARIO DO LIVE... 63
GRÁFICO 28 – ELEMENTOS DE FORMULARIO DO SINA... 63
GRÁFICO 29 – ELEMENTOS DE FORMULARIO DO EBAY... 64
GRÁFICO 30 – ELEMENTOS DE FORMULARIO DO YANDEX... 64
GRÁFICO 31 – ELEMENTOS SCRIPT DO 1º AO 5º TOPSITES... 66
GRÁFICO 32 – ELEMENTOS SCRIPT DO 6º AO 10º TOPSITES... 66
GRÁFICO 34 – ATRIBUTOS ARIA DO FACEBOOK... 68
GRÁFICO 35 – ATRIBUTOS ARIA DO YOUTUBE... 69
GRÁFICO 36 – ATRIBUTOS ARIA DO YAHOO... 69
GRÁFICO 37 – ATRIBUTOS ARIA DO WIKIPÉDIA... 70
GRÁFICO 38 – ATRIBUTOS ARIA DO TWITTER... 70
GRÁFICO 39 – ATRIBUTOS ARIA DO LIVE... 71
GRÁFICO 40 – ATRIBUTOS ARIA DO SINA... 71
GRÁFICO 41 – ATRIBUTOS ARIA DO EBAY... 72
GRÁFICO 42 – ATRIBUTOS ARIA DO YANDEX... 72
GRÁFICO 43 – ATRIBUTOS ROLES DO GOOGLE... 73
GRÁFICO 44 – ATRIBUTOS ROLES DO FACEBOOK... 73
GRÁFICO 45 – ATRIBUTOS ROLES DO YOUTUBE... 74
GRÁFICO 46 – ATRIBUTOS ROLES DO YAHOO... 74
GRÁFICO 47 – ATRIBUTOS ROLES DO WIKIPÉDIA... 75
GRÁFICO 48 – ATRIBUTOS ROLES DO TWITTER... 75
GRÁFICO 49 – ATRIBUTOS ROLES DO LIVE... 76
GRÁFICO 50 – ATRIBUTOS ROLES DO SINA... 76
GRÁFICO 51 – ATRIBUTOS ROLES DO EBAY... 77
GRÁFICO 52 – ATRIBUTOS ROLES DO YANDEX... 77
GRÁFICO 53 – ELEMENTOS DE TABELA E CSS DO GOOGLE... 79
GRÁFICO 54 – ELEMENTOS DE TABELA E CSS DO FACEBOOK... 79
GRÁFICO 55 – ELEMENTOS DE TABELA E CSS DO YOUTUBE... 80
GRÁFICO 56 – ELEMENTOS DE TABELA E CSS DO YAHOO... 80
GRÁFICO 57 – ELEMENTOS DE TABELA E CSS DO WIKIPÉDIA... 81
GRÁFICO 57 – ELEMENTOS DE TABELA E CSS DO TWITTER ... 81
GRÁFICO 59 – ELEMENTOS DE TABELA E CSS DO LIVE... 82
GRÁFICO 60 – ELEMENTOS DE TABELA E CSS DO SINA... 82
GRÁFICO 61 – ELEMENTOS DE TABELA E CSS DO EBAY... 83
LISTA DE TABELAS
TABELA 1 – QUADRO COMPARATIVO DE TRABALHOS CORRELATOS... 27 TABELA 2 – LISTA DOS 10 TOPSITES... 31
LISTA DE SIGLAS
API Interface de Programação de Aplicativo (do original Application Programming Interface)
CSS Folhas de Estilo em Cascata (do original Cascading Style Sheets) HTML Linguagem de Marcação de Hipertexto (do original HyperText Markup
Language)
IBGE Instituto Brasileiro de Geografia e Estatística TA Tecnologia Assistiva
UAAG Diretrizes de Acessibilidade de Agente de Usuário (do original User Agent Acessibility Guidelines)
UTFPR Universidade Tecnológica Federal do Paraná
XHTML Linguagem de Marcação de Hipertexto Extensível (do original Extensible Hypertext Markup Language)
WCAG Diretrizes de Acessibilidade de Conteúdo Web (do original Web Content Accessibility Guidelines)
LISTA DE ACRÔNIMOS
AJAX JavaScript e XHTML Assíncronos (do original Asynchronous JavaScript and XML)
ATAG Diretrizes de Acessibilidade de Ferramentas de Autoria (do original Authoring Tool Accessbility Guidelines)
ARIA Aplicações Ricas de Internet Acessíveis (do original Accessible Rich Internet Applications)
DOM Modelo de Objetos do Documento (do original Document Object Model)
WAI Iniciativa de Acessibilidade Web (do orginal Web Accessibility Initiative)
WEB Rede Mundial de Computadores (do original World Wide Web) W3C Consórcio da Rede Mundial de computadores (do original World
SUMÁRIO 1 INTRODUÇÃO... 15 1.1 PROBLEMAS E PREMISSAS... 16 1.2 JUSTIFICATIVA... 16 1.3 OBJETIVOS... 17 1.3.1 Objetivo geral... 17 1.3.2 Objetivos específicos... 17 1.4 ORGANIZAÇÃO DO TEXTO... 18 2 FUNDAMENTAÇÃO TEÓRICA... 19
2.1 CONCEITOS DE ACESSIBILIDADE NA WEB... 19
2.2 TECNOLOGIAS ASSISTIVAS... 19 2.3 MODELO DA WAI... 20 2.4 WCAG 2.0... 22 2.5 RIAs e ARIA... 23 2.6 TRABALHOS CORRELATOS... 24 3 DESENVOLVIMENTO DO PROJETO... 29 3.1 RECURSOS UTILIZADOS... 29 3.2 MATERIAIS E MÉTODOS... 30 3.3 ANÁLISE E IMPLEMENTAÇÃO... 32
3.4 ANÁLISE DOS DADOS... 33
3.4.1 Elementos de Cabeçalho... 33
3.4.2 Elementos de Imagem... 34
3.4.3 Elementos de Formulário... 35
3.4.4 Elementos Script... 37
3.4.5 Atributos Aria e Roles... 37
3.4.6 Elementos de Tabela e CSS... 39
4 CONSIDERAÇÕES FINAIS... 41
4.1 LIMITAÇÕES E RESTRIÇÕES... 41
4.2 TRABALHOS FUTUROS... 42
REFERÊNCIAS... 43
APÊNDICE A – Gráficos dos Elementos de Cabeçalho... 47
APÊNDICE B – Gráficos de Elementos de Imagem... 53
APÊNDICE D – Gráficos dos Elementos Script... 65 APÊNDICE E – Gráficos dos Atributos ARIAs e Roles... 67 APÊNDICE F – Gráficos do Elementos de Tabela e CSS... 78
1 INTRODUÇÃO
A inclusão social propõe a integração de indivíduos excluídos da sociedade, seja por possuir alguma deficiência, provir de uma classe social inferior, por sua raça, cor ou religião, impossibilitando que esses indivíduos possam usufruir de serviços e acessos ofertados a sociedade.
Segundo o Senso Demográfico do Instituto Brasileiro de Geografia e Estatística (IBGE, 2010), 23,9% da população brasileira se declara portadora de alguma deficiência, seja ela visual, motora ou mental. O que corresponde a mais de 40 milhões de brasileiros privados do acesso a serviços oferecidos a comunidade. Dentre as deficiências pesquisadas a deficiência visual é a que mais afeta os brasileiros. Pelo estudo 18,8% dos entrevistados alegam ter dificuldade em enxergar, mesmo com óculos ou lentes.
O governo brasileiro constituiu leis almejando permitir o acesso desse grupo de indivíduos a seus direitos, como por exemplo, a lei das calçadas, rebaixadas em São Paulo pelo Decreto municipal 45.904/2005, onde o padrão arquitetônico dos passeios ou praças públicas deve assegurar a acessibilidade a pessoas com deficiência ou mobilidade reduzida. Entre as exigências do decreto, está a necessidade de instalação de piso tátil de alerta ou direcional, que “devem ter cor contrastante com o resto do pavimento” (ROSALI FIGUEIREDO, 2011).
Assim como a lei das calçadas, que fornece um conjunto de exigências para a padronização da instalação de piso tátil, a Web possui documentos para auxiliar desenvolvedores a implementar conteúdo acessível, como por exemplo, as especificações Accessible Rich internet Applications (ARIA) e Web Content Accessibility Guidelines (WCAG) desenvolvidas pela World Wide Web Consortium (W3C)1. Todos os padrões desenvolvidos pelo W3C são gratuitos e abertos, visando
garantir a evolução da Web e o crescimento de interfaces de aplicações Web garantindo interoperabilidade das mesmas (W3C, 2013).
Tim Berners-Lee, inventor da Web e um dos fundadores da W3C, tem como missão conduzir a Web para que a mesma atinja todo seu potencial, desenvolvendo protocolos e diretrizes que garantam seu crescimento a longo prazo (W3C, 2013).
1 World Wide Web Consortium (W3C) é um consórcio internacional no qual organizações filiadas, uma equipe em tempo integral e o público trabalham juntos para desenvolver padrões para a Web.
Visando potencializar o acesso à Web para portadores de deficiências, a W3C desenvolveu as diretrizes e especificações internacionais WCAG e ARIA para tornar a Web acessível.
1.1 PROBLEMAS E PREMISSAS
O rápido crescimento de páginas web presentes na Internet, atualmente superior a 45 bilhões de páginas2, traz como efeito colateral a ausência da
implementação dos critérios de acessibilidade. No estudo apresentado a seguir, que investigou websites governamentais, nota-se esse efeito.
Em Spelta et al. (2010) foi realizado um estudo de acessibilidade dos websites de 3 candidatos a presidente do Brasil com uma metodologia própria quantitativa e qualitativa. As conclusões da pesquisa foram: as barreiras identificadas são graves e não são exclusividade de um ou outro website de candidato, mas sim de todos os três. Pela análise, pode-se garantir que não houve preocupação com acessibilidade na concepção e construção dos websites e, se houve alguma, certamente não foi implementada.
Todos os websites apresentam barreiras primárias de acessibilidade, ou seja, nem mesmo o mínimo necessário de acessibilidade para ofertar a facilidade de uso aos grupos de usuários que possuem algum tipo de limitação física ou mental foi implementado.
1.2 JUSTIFICATIVA
Assim a inclusão social tem o objetivo de proporcionar a integração de indivíduos a sociedade, a inclusão digital busca democratizar o acesso a informação a todos. Para que esta democratização ocorra, o governo instaura leis e decretos, visando possibilitar a integração do maior número de pessoas.
2 http://www.worldwidewebsize.com/
Desde 2004, um Decreto Federal (nº 5.296) torna obrigatório que todos os portais e websites dos órgãos da administração pública atendam aos padrões de acessibilidade digital. Além do Decreto Federal (nº 5.296), o governo vem institucionalizando outras formas de auxiliar na inclusão digital. Em 2007, o governo brasileiro, por meio da Portaria nº 3, de 7 de maio, institucionalizou o Modelo de Acessibilidade em Governo Eletrônico (eMAG), tornando sua observância obrigatória nos sítios e portais do governo brasileiro.
Além dos decretos, portarias e até uma lei, a Lei de Acesso à Informação Nº 12.527, de novembro de 2011, que trataram do tema, abrangendo todos os websites e não apenas os governamentais. Essas iniciativas não foram suficientes para garantir que a situação tenha sido resolvida, pois falta fiscalização na construção dos websites para verificar se as normas estão sendo cumpridas.
1.3 OBJETIVOS
1.3.1 Objetivo Geral
Este trabalho tem como objetivo realizar o monitoramento da evolução da implementação de um grupo de elementos e atributos HTML, para avaliar a implementação de requisitos associados as especificações ARIA e WCAG 2.0 em uma amostra do disponível pelo websites Alexa.com contendo os 10 topsites: Google, Facebook, Youtube, Yahoo, Wikipédia, Twitter, Live, Sina, Ebay e Yandex.
Desenvolver uma ferramenta capaz de monitorar e identificar elementos e atributos do HTML em uma página Web.
Investigar a implementação de elementos HTML5 em um conjunto de websites.
Investigar a implementação semântica dos elementos de acordo com as especificações ARIA.
Investigar a implementação dos elementos de acordo com as diretrizes da WCAG 2.0.
Automatizar o processo de quantificação de elementos e atributos que implementem as especificações ARIA e WCAG 2.0.
1.4 ORGANIZAÇÃO DO TEXTO
Este texto está organizado em 4 capítulos, distribuídos da seguinte maneira: este capítulo apresenta uma breve introdução do trabalho a ser desenvolvido, seguido da motivação e objetivos.
No Capítulo 2 é apresentada a revisão bibliográfica sobre todo o embasamento deste trabalho. São apresentados conceitos relacionados a acessibilidade Web, tecnologia assistiva, o modelo da Web Accessibility Initiative (WAI), Rich Internet Applications (RIAs) e ARIA, seguida de especificações técnicas de avalição de acessibilidade do documento WCAG 2.0, além de trabalhos correlatos com o tema aqui abordado.
No Capítulo 3, é apresentada a definição da proposta do trabalho, além de algumas tecnologias e ferramentas utilizadas para o seu desenvolvimento. Além disso, é apresentada uma revisão sobre as figuras utilizadas para simplificar o entendimento da construção do sistema.
No Capítulo 4 são apresentadas as considerações finais, seguidas das limitações encontradas durante o seu desenvolvimento e, finalizando o capitulo, os trabalhos futuros.
2 FUNDAMENTAÇÃO TEÓRICA
2.1 CONCEITOS DE ACESSIBILIDADE NA WEB
A World Wide Web (ou simplesmente Web) foi concebida com o intuído de promover o acesso de todos a seus conteúdos. Para isso ocorrer é necessário que haja uma padronização de inserção de informações, para essa finalidade foi utilizado o Hyper Text Markup Language (HTML) (W3C, 1999).
A Web, além de ser uma tecnologia de disponibilização de conteúdo é também uma tecnologia auxiliadora na universalização do acesso a informação. A essa outra vertente denomina-se acessibilidade, que consiste em promover o acesso a todos independe de suas limitações.
A acessibilidade na Web tem como objetivo possibilitar a todos a sua utilização. Especificamente, pessoas com necessidades especiais, permitindo a elas compreender, entender, navegar, interagir e contribuir com a Web. A acessibilidade na Web permite, entre outros benefícios, a inclusão de idosos e indivíduos não familiarizados com tecnologia, os chamados analfabetos digitais (HENRY, 2005).
Considerando uma Web colaborativa, é essencial conscientizar usuários e desenvolvedores de conteúdo Web sobre a importância da acessibilidade. A W3C estima que 90% dos websites presentes na Web são inacessíveis a portadores de deficiência, porém, com as novas tecnologias é bem provável que esse problema diminua ao longo do tempo (BOLDYREFF, 2002).
2.2 TECNOLOGIAS ASSISTIVAS
O termo Tecnologia Assistiva é traduzido do inglês Assistive Technology, que nada mais é do que recursos que auxiliam pessoas com deficiência no acesso a informação. Estes recursos podem ser apresentados na forma de serviços, equipamento, estratégias e práticas, se adequando de acordo com a necessidade do deficiente (COOK ; HUSSEY, 1995).
Na Internet, os sistemas são os responsáveis por ampliar as habilidades funcionais de pessoas com necessidades especiais, promovendo a disseminação da inclusão social e digital.
Para cada deficiência é utilizada uma TA (tecnologia assistiva) diferente. Portadores de deficiência visual utilizam-se da tecnologia como os leitores de tela, navegador textual e navegador com voz. A seguir, são apresentadas algumas características de tecnologias utilizadas por deficientes visuais:
Leitor de tela: é um sistema que navega através da estrutura HTML dos websites “lendo” para os usuários as informações neles contidos. O conteúdo também pode ser apresentado em braile, para isso é necessário que o usuário utilize de um dispositivo que realize a conversão de texto para braile (FORTES et al., 2005)
Navegador Textual: esse browser exibe somente texto, diferente dos navegadores convencionais que apresentam mídias temporais. Geralmente, pessoas com deficiência visual utilizam o navegador textual com o leitor de tela (FORTES et al., 2005).
Navegador com voz: é um navegador que possibilita a navegação através da fala, ele interpreta um comando e executa (FORTES et al., 2005).
Ampliador de tela: tecnologia essa que permite o aumento do tamanho do conteúdo de acordo com o nível de dificuldade de visualização do usuário
Além das tecnologias utilizadas por deficientes visuais acima apresentada, há outros métodos que possibilitam a acessibilidade de portadores de outras limitações, por exemplo, deficientes físicos utilizam da tecnologia de teclado alternativo, seja através de software ou hardware, que fornece um método alternativo de disposição das teclas ou travas que permita somente pressionar uma tecla por vez.
2.3 MODELO DA WAI
O modelo da WAI consiste em três conjuntos de diretrizes agregadas, sendo elas: Web Content Accessibility Guidelines (WCAG), User Agent Accessibility
Guidelines (UAAG) e Authoring Tool Accessibility Guidelines (ATAG), onde cada documento é direcionado a um determinado público alvo. A seguir é apresentada uma breve descrição de cada documento:
ATAG: Essa especificação fornece diretrizes para desenvolvedores de ferramentas de autoria Web. Seu objetivo é duplo: para ajudar os profissionais na criação de ferramentas que produzem conteúdo Web acessível e para auxiliar os desenvolvedores na criação de interfaces de autoria acessíveis (W3C, 2010).
UAAG: Esse documento fornece diretrizes para a implementação de agentes de usuário para pessoas com deficiência (visual, auditiva, física, cognitiva e neurológica). Os agentes de usuário incluem navegadores HTML e outros tipos de softwares que renderizam conteúdo (W3C, 2002).
WCAG 1.0: Essas diretrizes explicam como implementar conteúdo acessível a pessoas com deficiência, independente do agente de usuário que esteja sendo utilizado ou dos ambientes em que estão, sejam eles barulhentos, sub ou super iluminados, entre outras (W3C, 1999).
Na Figura 1, é apresentada a representação do Modelo da WAI associados aos documentos acima referidos.
Figura 1 - Modelo da WAI
A representação da Figura 1 dispõe o conteúdo na cor azul e na cor laranja. Os conteúdos presentes na cor laranja da imagem representam o documento UAAG, que contém as diretrizes para o desenvolvimento de Tecnologias Assistivas (TA), como navegadores e players de mídia. Para sua concepção são utilizadas algumas especificações técnicas como SVG, SMIL, entre outras. Estas tecnologias assistivas tem como público alvo usuários com de alguma deficiência.
Os conteúdos presentes do lado azul da representação são destinados a desenvolvedores. Para os desenvolvedores de conteúdos Web acessível as diretrizes de acessibilidade WCAG são disponibilizadas e para desenvolvedores de ferramentas de autoria, como ferramentas de aperfeiçoamento e ferramentas de criação, o documento ATAG é disponibilizado. Para a construção destas ferramentas e conteúdos algumas especificações técnicas devem ser empregadas, como por exemplo, as especificações HTML, Extensible Markup Language (XML) e Cascading Style Sheets (CSS).
2.4 A WCAG 2.0
As diretrizes presentes no documento WCAG 2.0 são uma nova versão das diretrizes da WCAG 1.0. Suas diretrizes são divididas em quatro princípios, que servem como características necessárias ao conteúdo Web, para que o mesmo seja apresentado ao usuário de forma rápida e eficaz (W3C, 2013a).
1) Perceptível – A informação e os componentes de interface devem ser apresentados de forma que aos usuários possam perceber (W3C, 2008). Suas diretrizes são citadas abaixo:
a) Alternativas textuais: disponibilizar alternativas textuais para conteúdo não textuais como imagens.
b) Mídias temporais: disponibilizar alternativas para mídias temporais (vídeos, áudios, animações).
c) Adaptabilidade: criar conteúdo que possa ser disponibilizado de diferentes maneiras sem perder a informação ou estrutura.
d) Distinguíveis: facilitar aos usuários ver e ouvir o conteúdo, apresentando foco ao conteúdo principal sendo disponibilizado.
2) Operáveis – Componentes de interface do usuário e navegação tem de ser operáveis (W3C, 2008). Diretrizes operáveis:
a) Acessível pelo teclado: tornar todas as funcionalidades acessíveis pelo teclado.
b) Tempo suficiente: disponibilizar tempo suficiente para leitura e utilização do conteúdo.
c) Apreensibilidade: não estruturar o website com conteúdo que possam causar apreensão nos usuários, como por exemplo: flash de frequência superior a três vezes por segundo.
d) Navegabilidade: disponibilizar meios que auxiliem a navegação do usuário, busca por conteúdo e localização.
3) Compreensível – A informação e a operação de interface deve ser compreensível (W3C, 2008). Diretrizes compreensíveis:
a) Legível e compreensível: disponibilizar o conteúdo de forma legível e compreensível aos usuários.
b) Previsibilidade: os websites devem aparecer e operar por meios previsíveis. c) Assistência de entrada: auxiliar os usuários, evitar e corrigir erros.
4) Robusto – O conteúdo tem de ser robusto o suficiente para ser interpretado de forma confiável por uma ampla variedade de agentes de utilizador, incluindo tecnologias de apoio (W3C, 2008). Diretriz de robustez:
a) Compatibilidade: maximizar a compatibilidade com agentes de usuário e tecnologias disponibilizadas atualmente ou no futuro.
Além da evolução no desenvolvimento de disponibilização de conteúdo Web acessível, houve também uma evolução no desenvolvimento de componentes de interface (Widgets), que possibilitam melhor interatividade do usuário com sua interface gráfica, nas denominadas RIAs.
2.5 RIAs e ARIA
O aumento das complexidades das interações nas aplicações Web 2.0 fez com que as interfaces do usuário se tornassem mais ricas e interativas (GIBSON, 2007), em outras palavras, tornou a aplicação Web uma Rich Internet Application
(RIA), aplicações essas que possuem algumas características e funcionalidades das aplicações tradicionais desktop.
As RIAs tipicamente proporcionam um visual onde não há necessidade de atualizar (no-refresh) a página Web como um todo, proporcionando algo que atualmente é chamado de (HduX - High Definition User eXperience) alta definição da experiência do usuário.
Aplicações ricas implicam em maiores complexidades de acessibilidade. Tradicionalmente, as tecnologias assistivas, como leitores de telas, apresentam informações considerando que a página Web possui uma estrutura linearizada de conteúdo, porém RIAs muitas vezes não possuem tal estrutura, sendo possível que a mesma seja modificada durante a interação, dificultando as TA a apresentação de seus conteúdos (WATANABE et al., 2014).
Para lidar com o aumento de complexidade das interfaces de usuário na Web introduzidas pelas RIAs, a WAI, organização criada pela W3C que tem como missão definir princípios e regras de design e desenvolvimento de websites que sejam acessíveis a pessoas com deficiência, elaborou as diretrizes ARIA (LUCCA et al., 2005).
ARIA é um conjunto de especificações técnicas que fornece conhecimento para melhorar a acessibilidade e interoperabilidade dos conteúdos Web e aplicações. Esse documento é usado principalmente por desenvolvedores de Widgets personalizados e outros componentes de aplicação Web (W3C, 2014).
O objetivo da especificação ARIA é incluir dados semânticos nos elementos HTML para informar aos mecanismos de tecnologias assistivas sobre como cada componente de interface deve ser apresentado, considerando possíveis mudanças e atualizações da sua estrutura HTML (GIBSON, 2007).
No capítulo a seguir são apresentados os trabalhos relacionados.
2.6 TRABALHOS CORRELATOS
Neste capítulo será apresentado todos os trabalhos que possuem características semelhantes a esse trabalho. Todas as informações resumidas
referentes aos trabalhos correlatos se encontram na Tabela 1 ao final desse capítulo.
Watanabe et al. (2014) realizaram um estudo relacionado a acessibilidade de websites. O estudo consistiu em analisar 32 websites de maior fluxo na internet, segundo o Ranking da Alexa. No estudo foram avaliados os mecanismos de navegação por teclado por meio de Tab Widgets. Dos 32 websites analisados, 9 foram classificados como não acessíveis e apenas 1 website seguia parcialmente as recomendações ARIA, sendo nulo o número de websites em totalmente conformidade com as especificações ARIA.
O que difere este trabalho do estudo acima apresentado é a codificação de uma ferramenta que automaticamente monitore a evolução dos 10 websites com maior fluxo de acesso segundo o Ranking Alexa’s. Ao invés de avaliar a navegação por Tab Widgets, foi avaliado a evolução da codificação da especificação ARIA nestes websites durante os últimos 10 anos.
Em Fernandes et al., (2013), utiliza-se a avaliação automática de acessibilidade realizada no navegador, para analisar a estrutura Document Object Model (DOM) de uma página Web, dadas as interações dos usuários. Foram consideradas as diretrizes presentes nas especificações da WCAG 2.0 para avaliar o comportamento dinâmico de páginas Web. Ressaltando que não foram utilizadas as especificações ARIA.
O estudo conduzido por Fernandes et al. 2013 é o que mais se aproxima deste trabalho. O que difere este trabalho é que foi levado em consideração algumas diretrizes da WCAG 2.0, além de considerar as especificações ARIA, o que não foi realizado no estudo anterior.
Tangarife et al., (2005) apresentam a questão da acessibilidade Web para o Governo Eletrônico Brasileiro e uma ferramenta brasileira de validação de acessibilidade. Foi realizada uma pesquisa exploratória, tomando por base a homepage de um website governamental, mostrando que existe uma diferença nos resultados obtidos seguindo as recomendações da W3C e do Governo Eletrônico. Mostra-se a necessidade de ter uma harmonização dos padrões de acessibilidade Web para criar uma demanda unificada do mercado para softwares que suportem acessibilidade.
O trabalho anteriormente apresentado avaliou as diferenças entre a W3C e o Governo Brasileiro, almejando promover a homogeneização da definição dos padrões
de acessibilidade. Apesar deste trabalho avaliar a acessibilidade, não foi levado em consideração as especificações de acessibilidade do governo brasileiro, somente os da W3C disponibilizadas no documento ARIA e WCAG 2.0.
Santana et al., 2013 conduziram um estudo comparando os snapshots3 de
dois grupos de websites, sendo o primeiro grupo composto com os 1.000 websites mais populares segundo Alexa.com e o segundo grupo de 1.000 websites selecionados aleatoriamente. Essa pesquisa foi baseada na WCAG 2.0. O nível de conformidade analisado foi Nível A, que é o mínimo que uma página Web deve possui de conformidade. No trabalho foram considerados somente os relatórios de problemas conhecidos, fornecidos pela ferramenta AChecker4, ou seja, barreiras primárias de
acessibilidade que devem ser corrigidas pelos seus desenvolvedores. Os resultados do estudo mostram que a quantidade de problemas conhecidos de acessibilidades nos websites mais populares é maior do que a quantidade encontrada nos websites aleatórios. Isto pode ocorrer devido a vários fatores, por exemplo, os websites mais populares possuírem mais conteúdo, consequentemente eles possuem mais componentes de interface. Outro fator é que essas páginas são constantemente atualizadas, o que pode resultar em problemas de codificação, entre outros.
Há algumas similaridades entre o estudo conduzido por Santana et al., (2013) com este trabalho. Por exemplo, a utilização de snapshots de uma determinada amostra de websites para avaliar a implementação da acessibilidade destes, baseando-se nas especificações WCAG 2.0. Porém, este trabalho se diferencia baseando-se também no documento ARIA.
Hanson et al., 2013 conduziram um estudo realizando a comparação de dois grupos de websites, sendo o primeiro grupo de websites governamentais e o segundo de grupo de websites mais acessados dos Estados Unidos e do Reino Unido. O intuito do trabalho foi examinar alterações nos indicadores de acessibilidade durante os últimos 12 anos desses grupos, segundo os critérios de Sucesso Nível A da WCAG 2.0. Os resultados obtidos mostram que esses websites exibiram melhorias durante os anos em uma série de indicadores, sendo estas mais perceptíveis em websites governamentais que em websites com maior tráfego de acessos. Estas mudanças podem ser atribuídas às tecnologias para o desenvolvimento de websites e a práticas de codificação com foco na acessibilidade.
3 Snapshot é uma expressão em inglês que significa "foto instantânea" ou "registro instantâneo". 4 Ferramenta de avaliação de marcação disponível na Web
Apesar da semelhança entre o último trabalho apresentado com este, alguns fatores os diferenciam, por exemplo, no estudo levou-se em consideração somente websites governamentais e não governamentais dos Estados Unidos e do Reino Unido, enquanto neste foi analisado todas as áreas de websites, e-commerce, notícias, redes sociais entre outros. Outro fator que os deferem é a utilização dos critérios de Sucesso Nível A presentes na WCAG 2.0 no último trabalho, enquanto neste, algumas diretrizes foram selecionadas alternadas entre os documentos WCAG 2.0 e ARIA.
Segue abaixo a Tabela 1, contendo de forma resumida das características dos trabalhos correlatos.
Tabela 1 – Quadro comparativo de Trabalhos Correlatos
Título Autor(es) Características Diferenças
Keyboard Navigation Mechanisms in Tab Widgets: na 27nvestigation on ARIA’s Conformace Willian Massami Watanabe, Rafael José Geraldo e Renata Pontin de M. Fortes Avaliação da navegação por teclado por meio de Tab Widgets dos 32 sites com maior fluxo de acesso segundo Alexa.com Avaliação da evolução da implementação de requisitos de acessibilidade na web em conformidade com as especificações ARIA e WCAG Three Web Accessibility Evaluation Perspectives for RIA Nádia Fernandes, Ana Sofia Batista, Daniel Costa, Carlos Duarte, Luís Carriço Avaliação automática da estrutura DOM HTML de acordo com as especificações WCAG 2.0
Além das diretrizes da WCAG 2.0 este trabalho analisa a implementação de algumas especificações ARIA Estudo Comparativo Utilizando uma Ferramenta de Avaliação de Timóteo Tangarife e Cláudio Mont’Alvão Avaliação da acessibilidade da página inicial de portais governamentais através de uma Avaliação de acessibilidade de uma amostra de páginas iniciais dos 10 websites com maior fluxo de
Acessibilidade para Web ferramenta, com a finalidade de comprar as recomendações do modelo do Governo Eletrônico com as da W3C acesso através de um script verificando a implementação das diretrizes WCAG 2.0 e ARIA. Web Accessibility Snapshot: Na Effort to Reveal Coding Guidelines Conformance Vagner Figueiredo de Santana e Rogério Abreu de Paula Comparação da implementação de acessibilidade dos snapshots de dois grupos de websites: os 1.000 topsites com 1.000 sites aleatórios. Monitoramento da evolução da implementação de acessibilidade dos 10 topsites durante o período de 10 anos. Progress on Websites Acess? Vicki L. Hanson e John T. Richards Estudo comparativo entre a evolução da implementação de acessibilidade entre sites governamentais e os sites de maior fluxo de acesso do Reino Unido e nos Estados Unidos Avaliação e comparação da implementação de acessibilidade dos websites independe de sua área de mercado: compra, venda, jornalístico, governamental entre outros.
3 DESENVOLVIMENTO DO PROJETO
Pretende-se, neste trabalho, realizar o monitoramento da implementação de requisitos de acessibilidade em aplicações Web, buscando promover o desenvolvimento de conteúdo acessível e redução do tempo gasto para análise de acessibilidade em websites.
No próximo capítulo serão apresentadas as tecnologias e ferramentas utilizadas na construção deste trabalho.
3.1 RECURSOS UTILIZADOS
Para tornar possível o desenvolvimento da proposta, algumas tecnologias e ferramentas foram utilizadas. A seguir serão apresentadas as características de cada tecnologia:
GitHub: É uma ferramenta de gerenciamento de código em aplicações open source. É um serviço que permite controlar um projeto a partir de repositórios criados na Web. Funciona como uma “rede social” para desenvolvedores, onde é possível compartilhar os repositórios criados para os projetos, promovendo a participação de outros interessados, seja no desenvolvimento do código ou no aperfeiçoamento de códigos já existentes.
PhantomJS: Ferramenta para automatizar testes para sistemas Web, que fornece uma API completa que permite interagir com uma instância de browser apontada para a aplicação, ou seja, acessar e manipular a estrutura DOM da página.
CasperJS: é um utilitário de linha de comando que executa o código JavaScript no ambiente de execução PhantomJS, também fornece a capacidade de executar JavaScript no contexto WebKit headless, além de fornecer um conjunto de funções para realização de tarefas comuns, como por exemplo, preenchimento e entrega de formulários, download de recursos, captação de imagens da página entre outras.
No capítulo a seguir, será apresentada a metodologia do desenvolvimento do trabalho.
3.2 MATERIAIS E MÉTODOS
Na primeira etapa, para a seleção da lista de websites, foi utilizado o recurso presente no website Alexa.com desenvolvido pela companhia Alexa Internet Inc. Este serviço mede por amostragem e aproximação quantos usuários de Internet visitam um determinado websites. Após a análise dos dados, o website fornece a ranking mundial de websites com maior quantidade de acessos. Para este trabalho foi utilizado apenas os 20 primeiros Topsites.
Após a definição da lista com os 20 Topsites, foi utilizado o serviço de Internet Wayback Machine para acessar a Homepage de cada website presente na lista.
A máquina Wayback é um acervo digital desenvolvido pela organização Internet Archive que emprega Web crawlers5 para captação de seus dados,
fornecendo acesso a coleções de materiais digitalizados, incluído websites, aplicações, jogos, filmes entre outros. Através da máquina Wayback foi realizada a tentativa de acesso a Homepage de cada website semestralmente entre os anos de 2005 a 2015.
A seguir, na Tabela 2 é apresentada a lista contendo os 10 Topsites em ordem decrescente de acesso, segundo Alexa Internet Inc. acesso na data de 16 de julho de 2015. Está presente também, o período de tempo (mês/ano) de início e término de análise das páginas, além da classificação ou desclassificação do website, de acordo com os critérios mencionados.
5 Crawler é um robô usado pelos buscadores para encontrar e indexar páginas de um website. Ele captura informações das páginas e cadastra os links encontrados, possibilitando encontrar outras páginas e mantendo sua base de dados atualizada.
Tabela 2 – Lista dos 10 Topsites
Posição no
Ranking
Websites Mês/Ano de início - Mês/Ano de término 01º Google.com Jun/2005 – Jun/2015 02º Facebook.com Ago/2005 – Fev/2015 03º Youtube.com Jun/2005 – Jun-2015 05º Yahoo.com Jun/2005 – Jun/2015 07º Wikipedia.org Jun/2005 – Jun/2015 09º Twitter.com Nov/2006 – Mar/2015 12º Live.com Dez/2006 – Abr/2015 13º Sina.com.cn Jun/2005 – Jun/2015 17º Ebay.com Jun/2005 – Jun/2015 19º Yandex.ru Jun/2005 – Jun/105
Fonte: Autoria Própria
Dentre os websites contidos na lista, apenas 10 estavam totalmente habilitados e poderiam ser utilizados na ferramenta. Entre os critérios de desclassificação dos websites encontram-se:
1º Critério: Não disponibilização da página (Page cannot be crawled or displayed due to bots.txt). Este problema ocorre quando o crawler do Internet Archive tenta processar ou digitalizar áreas da página que estão sendo protegidas por um bots.txt6.
2º Critério: Redirecionamento a outro website que não possui relação com a página Web informada.
3º Critério: Possuir a estruturação dos conteúdos idênticos ou bastante similar a outro website contido na lista.
4º Critério: Carregamento parcial ou incompleto dos conteúdos da página.
5º Critério: Atualização automática da página de tempo em tempo, impedindo ao script realizar a captura dos dados.
Para o acesso ás Homepages de cada website especificado na Tabela 2 foi utilizado um computador contendo o Sistema Operacional Windows 8.
6 Bots.txt é um padrão utilizado para comunicação com o crawlers e outros robôs Web. Este padrão informa quais áreas do website não devem ser processadas e digitalizadas.
Para codificação da ferramenta foi utilizado o editor de código fonte Sublime Text 2 (versão 2.0.2), que possui uma interface agradável e de fácil uso, além de seus recursos de edição e flexibilidade.
Para criar o ambiente que irá simular automaticamente as ações do usuário e os testes, foram utilizadas as tecnologias PhantomJS (versão 1.9.8) e o CaperJS (versão 1.1-beta3).
O método evaluate do CasperJS foi utilizado e funciona como uma ponte entre o ambiente PhantomJS e CasperJS e o ambiente DOM da página a ser acessada, isto equivale a executar uma instrução de código dentro do console de um navegador Web convencional. Na Figura 2 é apresentado o esquema de interação do ambiente PhantomJS e CasperJS com o ambiente DOM da página.
Figura 2 - Interação dos ambientes através do método evaluate().
(Fonte: CasperJS, 2011)
Simplificando, o script desenvolvido em JavaScript será executado pelo CasperJS que irá interagir através do método evaluate com o ambiente DOM de uma página Web simulando interações do usuário de forma automática através do PhantomJS, para os 10 websites selecionados.
Dentro do script foi criado um vetor que recebeu todos os links da Homepage de cada um dos websites da lista. Para cada link o método evaluate foi invocado, permitindo acessar a estrutura DOM do website, como parâmetro do método foi passada uma função.
Essa função realiza uma busca na estrutura HTML do website e recebe o nome de um elemento como parâmetro. Os seguintes elementos foram passados como parâmetros para a função: div, (h1 – h6), img, form, fieldset, legend, label, input, script, table, caption, style e link. Por outro lado, para a captação dos atributos foi utilizada uma função que recebe como parâmetros o nome do elemento e o nome do atributo a ser procurado. A esta função foi passada como parâmetro os seguintes atributos: alt do elemento img e o role de todos os elementos. Para a captura dos atributos aria-label, aria-labelledby e aria-describedby foi utilizada uma função sem passagem de parâmetros.
Foi declarado um objeto que armazenou todo os objetos JavaScript Object Notation (JSON) retornados pelas funções. Para cada link compilado foi criado uma nova linha em arquivo de extensão Comma-Separated Values (CSV) que armazenou os dados presentes no objeto.
3.4 ANÁLISE DOS DADOS
Para cada um dos 10 websites classificados na Tabela 2 foi executado o script, possibilitando a extração dos resultados descritos nas seções a seguir.
3.4.1 Elementos de Cabeçalho
São elementos de cabeçalho: os elementos h1 até h6, que são títulos para as seções com as quais estão associados (W3C, 2013). Esses elementos têm uma classificação dada pelo número em seu nome. O elemento h1 possui o posto mais alto, o elemento h6 tem o menor grau, e dois elementos com o mesmo nome têm o mesmo valor de relevância (W3C, 2011).
De acordo com a WCAG 2.0 a Técnica H42: Utilizar h1 – h6 para identificar cabeçalhos tem como objetivo a marcação de cabeçalhos HTML e XHTML para transmitir a estrutura do conteúdo (W3C, 2008).
A implementação de cabeçalhos simplesmente para alterar o aspecto do texto não transmite a organização do conteúdo e pode confundir os usuários que utilizam cabeçalhos para compreender a estrutura ou que se baseiam nos mesmos para a navegação. Contrariamente, enquanto aplicar o formato negrito, ou mesmo "categoria=cabeçalho", pode resultar na apresentação visual de um header, as tecnologias de apoio não irão reconhecer esses textos como cabeçalhos (W3C, 2008). Essa técnica tem como objetivo satisfazer o Critério de Sucesso 1.3.1 Informações e relações. Informação, estrutura e relações transmitidas através de apresentação pode ser determinada de forma pragmática ou estão disponíveis no texto. (Nível A) (W3C, 2015).
O Gráfico 3, Gráfico 4, Gráfico 6 e Gráfico 9 (apêndice A) apresentaram a maior concentração de elementos de cabeçalho em sua Homepage, apontando um grande interesse dos desenvolvedores na estruturação dos conteúdos em suas páginas. Diferente do Gráfico 2, Gráfico 3 e Gráfico 10 (apêndice A) que expuseram uma menor importância na execução da Técnica H42, que possibilita a melhor navegação de portadores de deficiência em seus conteúdos. O Gráfico 1, Gráfico 7 e Gráfico 8 (apêndice A) representam não serem aderentes na codificação de elementos headers na construção de sua página inicial, denotando a falta de acessibilidade presente nos conteúdos Web.
3.4.2 Elementos de Imagem
Para inserir uma imagem em websites é necessário a declaração do elemento img do HTML. Através dela é possível inserir informações acerca da imagem a ser exibida. Para isso é necessário adicionar atributos ao elemento.
A Técnica H37: Utilizar atributos alt em elementos img presente na documentação WCAG 2.0 especifica: ao utilizar o elemento img, especifique uma alternativa em texto abreviado com o atributo alt (W3C, 2008).
Quando uma imagem inclui palavras importantes para compreender o conteúdo, o texto alt deve incluir essas palavras. Isto irá permitir que o texto alt tenha a mesma função na página que a imagem. O atributo alt não descreve necessariamente as características visuais da própria imagem, mas tem de transmitir o mesmo significado (W3C, 2008).
A utilização adequada da Técnica H37 atende ao Critério de Sucesso 1.1.1 Conteúdo Não Textual: Todo o conteúdo não textual que é apresentado ao utilizador tem uma alternativa em texto que serve ao propósito equivalente (Nível A) (W3C, 2008).
O cumprimento das orientações acima possibilita as tecnologias assistivas apresente as informações de conteúdo não textual (imagem) ao usuário em forma de texto.
Nota-se a maior utilização de elementos de imagem e atributos alt nos Gráfico 13, Gráfico 14, Gráfico 16, Gráfico 18 e Gráfico 19 (apêndice B). O Gráfico 11, Gráfico 12, Gráfico 15, Gráfico 17 e Gráfico 20 (apêndice B) empregam em menor quantidade o uso do elemento img na concepção de sua página Home (inicial). A parte desta análise mais relevante foi a observação de que todos os websites possuem seus elementos img associados a um atributo alt. Denotando assim um maior conhecimento técnico por parte dos desenvolvedores na exibição dos conteúdos não textuais de seus websites.
3.4.3 Elementos de Formulário
Em HTML é utilizado o elemento form para indicar que um formulário está sendo construído. Há diversos elementos que podem ser especificados dentro de um formulário, como o campo de entrada de dados input, label que fornece uma etiqueta ao elemento, fieldset para agrupamento de campos, elemento legend, que fornece um título para o grupo de campos dentro de um fieldset entre outros elementos.
A Técnica H44: Utilizar elementos label para associar etiquetas de texto a elementos de formulário. Tem como objetivo utilizar o elemento label para associar explicitamente uma etiqueta a um campo de formulário. O elemento label é associado
a outro elemento de formulários através do atributo for que recebe como valor do atributo o id do elemento de formulário (W3C, 2008).
O cumprimento da Técnica H44 atende aos seguintes critérios de sucesso:
1.1.1 Conteúdo Não Textual: Todo o conteúdo não textual que é apresentado ao utilizador deve ter uma alternativa em texto equivalente (W3C, 2008).
1.3.1 Informações e Relações: Informação, estrutura e relações transmitidas através de apresentação pode ser determinada de forma programática ou estão disponíveis no texto (W3C, 2008).
3.3.2 Etiquetas ou Instruções: As etiquetas ou instruções são fornecidas quando o conteúdo exigir a entrada do usuário (W3C, 2008).
4.1.2 Nome, Função Valor: Este critério de sucesso é principalmente para autores da Web que desenvolvem ou criam os seus próprios componentes da Interface de usuário. Geralmente, os controles HTML normais já cumprem este critério de sucesso quando utilizados de acordo com a especificação (W3C, 2008).
A Técnica H71: Fornece uma descrição para grupos de controle de formulário utilizando elementos fieldset e legend. O objetivo desta técnica é fornecer um agrupamento semântico para controles de formulário relacionados. Isto permite aos utilizadores compreender a relação dos controles e interagir com o formulário de forma mais rápida e eficaz (W3C, 2008).
Os elementos form do Gráfico 21, Gráfico 22, Gráfico 23, Gráfico 24, Gráfico 25, Gráfico 26, Gráfico 27, Gráfico 28, Gráfico 29 e Gráfico 30 (apêndice C) oscilaram pouco, além de não estarem declarados em grande quantidade na Homepage (página inicial) dos seus websites.
Todos os gráficos apresentaram baixa concentração do elemento fieldset, isso caracteriza maior dificuldade dos utilizadores em compreender e interagir com os controles de formulário.
Em consequência do pouco uso do elemento fieldset, todos os websites apresentaram baixa presença da tag legend, uma vez que declarado um fieldset em seguida deve ser declarado um legend.
Os websites Google.com, Youtube.com, Wikipedia.org, Twitter.com, Live.com, Ebay.com e Yandex.ru apresentaram baixa presença do elemento input em suas páginas, dos websites mencionados apenas o Google.com, Wikipedia.com e
Live.com mantem baixa a taxa de oscilação na utilização da tag os outros websites utilizam cada vez menos o elemento. Em contrapartida os websites Facebook.com, Yahoo.com e Sina.cn concentram grandes quantidades de inputs em sua estrutura HTML.
Quando analisado o elemento label, apenas o website Facebook.com apresentou grande número de declarações. Todos os outros websites continham pequenas quantidades do elemento declarada.
O ápice da análise deste grupo de gráficos está nas observações obtidas a respeito da associação entre os elementos input e label. Os gráficos que continham maior incidência de associação entre os elementos foi o Gráfico 22, Gráfico 24 e Gráfico 26 (apêndice C), apontando maior interesse em permitir ao usuário a rápida compreensão do campo de formulário que irá interagir. O oposto pode ser observado no Gráfico 21, Gráfico 23, Gráfico 25, Gráfico 27, Gráfico 28, Gráfico 29 e Gráfico 30 (apêndice C), que se possuem algum interesse na acessibilidade de sua página não foi concebida.
3.4.4 Elementos Script
O elemento script é utilizada para definir uma ligação á um script externo ou limita um script interno. A linguagem de programação JavaScript é empregada no desenvolvimento de scripts, que geralmente contém as funções e métodos que o website irá executar.
Pode-se observar que Gráfico 39 (apêndice D) exibe o decremento da utilização dos elementos script em seu website. Inversamente o website Ebay.com o Gráfico 31, Gráfico 32, Gráfico 33, Gráfico 34, Gráfico 35, Gráfico 36, Gráfico 37, Gráfico 38 e Gráfico 40 (apêndice D) apresentam um crescimento ascende e baixa oscilação do uso do elemento. Este fenômeno pode ser ocasionado devido ao Movimento AJAX permitindo aos desenvolvedores importarem arquivos contendo códigos JavaScript contendo uma série de métodos e funções já prontos para serem empregados em seu website.
3.4.5 Atributos ARIA e Roles
Os atributos aria-label, aria-labelledby e aria-describedby são rotuladores de elementos que funcionam como uma etiqueta. De acordo com a seção 6.6 ARIA, o atributo aria-label deve ser empregado em elementos não visíveis na tela pelo usuário, caso contrário deve ser utilizado o aria-labelledby. O atributo aria-describedby é utilizado para identificar o elemento que descreve o objeto.
Conforme o Gráfico 41 e Gráfico 48 (apêndice E) a implementação dos atributos em sua estrutura HTML não se fez presente, sendo nulo a quantidade de qualquer elemento aria mencionados no início deste capítulo. Este comportamento denota desinteresse ou falta de conhecimento técnico dos desenvolvedores dos websites em fornecer acessibilidade a aplicações ricas de Internet. Em via contraria, o Gráfico 41, Gráfico 42, Gráfico 43, Gráfico 44, Gráfico 45, Gráfico 46, Gráfico 47, Gráfico 49 e Gráfico 50 (apêndice E), exibiram uma pequena, porém significativa implementação dos atributos a fim de fornecer melhor acessibilidade a sua Homepage.
Os atributos roles são responsáveis por definir que tipo de elemento o usuário está interagindo. A cada tipo de role é atribuída a responsabilidade de definir o gênero do elemento. A seguir é apresentada a classificação dos roles segundo a seção 5.3 do documento WAI-ARIA:
5.3.1 Roles Abstract são utilizados para definição de conceitos gerais. Não deve ser utilizado para marcar conteúdo.
5.3.2 Roles Widgets determinam elementos de interface soltos, como caixas de alerta, botões, checkbox, links, entre outros. Este role possui uma extensão, os Act Roles que atuam como um complemento de alguns roles Widgets declarados.
5.3.3 Roles Document Structure definem organizações da estrutura da página. Estruturas que não são interativas, como header, footer, sidebar entre outros.
5.3.4 Roles Landmarks devem ser adicionados para regiões importantes da página, para auxiliar na navegação do usuário, por exemplo, conteúdo principal, busca, formulários entre outros.
A pequena quantidade de atributos roles presentes no Gráfico 51, Gráfico 55, Gráfico 60 (apêndice e), indica que estão pouco preocupados com a acessibilidade de sua página, visto que o emprego destes atributos ocasiona a acessibilidade a RIAs. Este fato se torna mais evidente no Gráfico 57 e Gráfico 58 (apêndice e) que não implementaram nenhum role em seu website. Inversamente a estes resultados negativos o Gráfico 52, Gráfico 53, Gráfico 54, Gráfico 56 e Gráfico 59 (apêndice e) que concentram um aumento significativo da utilização dos atributos.
3.4.6 Elementos de Tabela e CSS
A tag table é utilizada para declarar a criação de tabela em website. Durante o período de abertura até o fechamento da tag é definida uma série de outros elementos para a estruturação da tabela. Para realizar a divisão de conteúdo é utilizado o elemento div sem adicionar qualquer significado especial aos dados no elemento contido.
Os elementos style são utilizados para escrever CSS dentro do código HTML. São eles que possibilitam a alteração da cor do fundo da tela, ou dimensionar uma imagem, mudar o tamanho da fonte do texto entre outras funcionalidades.
Usado para ligar arquivos JavaScript e CSS externo ao documento HTML, a tag link, possibilita a utilização de códigos já existentes para definir um estilo a um elemento ou utilizar uma função já desenvolvida.
Em concordância com o Gráfico 61, Gráfico 62, Gráfico 63, Gráfico 64, Gráfico 65, Gráfico 66, Gráfico 67, Gráfico 68, Gráfico 69 e Gráfico 70 (apêndice F) cujo o crescimento ascendente de elementos div é notório, denotando melhor divisão dos seus conteúdos.
Os websites Google.com, Facebook.com, Wikipedia.org, Twitter.com e Yandex.ru, apresentaram pequenas oscilações de implementação do elemento table. Em aversão a estes os websites Youtube.com, Yahoo.com, Live.com, Sina.cn e Ebay.com exibiram uma queda brusca da utilização da etiqueta table, este fenômeno deve ter sido ocasionado pelo Movimento Tableless, movimento este que não se utiliza do elemento table para definir o layout de página e sim os novos recursos disponíveis como o elemento style.
A quantia de elemento de estilo é bem próxima em todos os websites e quase não oscilaram em sua estrutura, com exceção do website Sina.cn (apêndice F), que fez uso maior do elemento style, provavelmente devido o layout de sua página ser mais complexo.
Os websites Google.com, Live.com e Sina.cn (apêndice F) foram os que menos empregaram o elemento link, diferentemente dos websites Facebook.com, Youtube.com, Yahoo.com, Wikipedia.com, Twitter.com, Ebay.com e Yandex.ru (apêndice F) que apresentaram maior índices de incidência de elementos link em sua estrutura HTML. A maior utilização deste elemento caracteriza que os websites estão cada vez mais importando arquivos para dentro de suas estruturas, sejam estes para alterar o layout existente da página ou disponibilizar uma interação ao usuário.
4 CONSIDERAÇÕES FINAIS
Neste trabalho foi apresentada uma abordagem para monitorar a evolução da implementação de acessibilidade em aplicações web de acordo com uma lista contendo os 10 sites com maior tráfego de acessos na Internet. A utilização de eventos associados a interação dos usuários com as RIAs de forma automática tem potencial para obter resultados para reduzir o esforço do avaliador e o tempo de duração do processo.
A abordagem proposta neste trabalho foi o desenvolvimento de um script, que simulou a interação do usuário com a página DOM do HTML capturando dados referentes a acessibilidade durante o período de 2005 a 2015 dos websites da lista.
Os indicadores obtidos na avaliação automática foram transformados em gráficos para comparação de implementação de acessibilidade entre cada um dos websites. Foram observados os problemas primários de acessibilidade de cada um dos websites, como elementos img associados aos atributos alt, implementação dos atributos roles e aria, elementos input associados aos elementos label, entre outros obstáculos de acessibilidade.
Os resultados permitiram avaliar que todos os websites possuem limitações de acessibilidade em sua Homepage. Apesar das barreiras de acessibilidade encontradas, através dos gráficos notou-se o crescimento pequeno, porém significativo na elaboração de acessibilidade nos websites. Esta preocupação na construção de websites acessíveis, possibilita a inclusão digital de pessoas deficientes.
4.1 LIMITAÇÕES E RESTRIÇÕES
As principais limitações e restrições deste trabalho podem ser destacadas de acordo com os seguintes itens:
A ferramenta ficou limitada a uma amostra dos elementos da documentação ARIA.
Restrição de elementos HTML que estão presentes nas especiações WCAG 2.0.
Alguns websites presentes no acervo do Internet Archive encontravam-se indisponíveis ou com problemas no carregamento do encontravam-seu conteúdo, além da restrição dos bots.txt na data da elaboração do trabalho.
4.2 TRABALHOS FUTUROS
Alguns dos trabalhos futuros que podem dar continuidade às contribuições apresentadas são resumidos a seguir:
Realizar o aprimoramento da ferramenta no intuído de reduzir o tempo consumido para coleta dos dados.
Após a coleta dos dados desenvolver um método para que seja realizado automaticamente a geração dos gráficos.
Aprimorar as funcionalidades da ferramenta, para que o monitoramento possa se estender a outros elementos que não foram levados em consideração nesta pesquisa.
A comparação dos indicadores obtidos antes e após alterações na Homepage de cada website. Assim, seria possível verificar se realmente houve melhoria depois da execução do script.
REFERÊNCIAS
BOLDYREFF, C. Determination and Evaluation of Web Accessibility. In: PROCEEDINGS OF THE 11TH IEEE INTERNATIONAL WORKSHOPS ON ENABLING TECHNOLOGIES: Infrastructure for Collaborative Enterprises. Washington: IEEE, jun. 2002. p. 35–40.
BRASIL. Decreto nº 5.296, de 2 de dezembro de 2004. Casa Civil, Brasília, DF, 2 dez.2004. Disponível em:
<http://www.planalto.gov.br/ccivil_03/_ato2004-2006/2004/decreto/d5296.htm>. Acesso em: 3 de out. 2014.
BRASIL. Modelo de Acessibilidade em Governo Eletrônico. Departamento de
Governo Eletrônico. Brasília, DF, v. 3.1, abr. 2014.
COOK, A. M.; HUSSEY, S. M. Assistive Technologies: Principles and Practice. St. Loius: Mosby Inc, 1995. 571 p. 3 v
FERNANDES, N. et al. Three Web Accessibility Evaluation Perspectives for RIA. In: PROCEEDINGS OF THE 10TH INTERNATIONAL CROSS-DISCIPLINARY
CONFERENCE ON WEB ACCESSIBILITY (W4A '13). New York: ACM, mai. 2013. p. 9.
FERNANDES, N. et al. Evaluating the accessibility of Rich Internet Applications. In: PROCEEDINGS OF THE INTERNATIONAL CROSS-DISCIPLINARY
CONFERENCE ON WEB ACCESSIBILITY (W4A '12). New York: ACM, abr. 2012. p. 4.
FIGUEIREDO, R. Acessibilidade: Dever social, legal e moral. In: Revista Direcional
Condomínios, São Paulo, ed.161. p. 46-53. set. 2011.
FORTES, R. P. et al. Acessibilidade no Projeto de Aplicações Web. In: Web e
Multimídia: Desafios e Soluções. 1.ed. Poços de Caldas: PUC-Minas, 2005. cap.
7, p. 197-225.
GIBSON, B.; SCHWERDTFEGER, R. DHTML accessbility: solving the javascript accessibility problem. In: PROCEEDINGS OF THE 7TH INTERNACONAL ACM SIGACCESS CONFERENCE ON COMPUTERS AND ACCESSIBILITY (ASSETS '05). New York: ACM, out. 2005. p. 202-203.
