HATEMILE: A biblioteca para gerar páginas web mais
acessíveis
Carlson Santana Cruz, Carlos A. Estombelo-Montesco Departamento de Computação (DCOMP)
Universidade Federal de Sergipe (UFS) – São Cristóvão, SE – Brasil Abstract. The number of users, services and informations available on web is increasing every day, for many users it improves the way to search and select information and do activities, for disabled people these services represent an opportunity to autonomy. But often the disabled are faced with resources on web that due to their disability prevents or hinders their use, making their frustrated and limited, as it are broken down by their disability. So this paper show a library able to make it accessible web pages, mainly based on the WCAG 2.0 and e-MAG 3.1 guidelines, for developers and end users can use it. Resumo. O número de usuários, serviços e informações disponibilizadas na web cresce a cada dia, para muitos usuários isso melhora a forma de pesquisar e selecionar informações e de fazer atividades, para os deficientes esses serviços representam uma oportunidade de autonomia. Porém muitas vezes os deficientes deparam-se com recursos na web que impede ou dificulta seu uso, fazendo-os sentirem frustrados e limitados, por serem discriminados por sua deficiência. Por isso o presente trabalho apresenta uma biblioteca capaz de tornar páginas web mais acessíveis, baseado principalmente nas recomendações do WCAG 2.0 e do e-MAG 3.1, para que os desenvolvedores e usuários finais possam utilizá-la.
1. Introdução
A web se torna um meio de comunicação cada vez mais importante, principalmente para os deficientes visuais que a utilizam para realizar compras, ler o jornal, realizar operações bancarias, entre outras atividades sem depender da ajuda de outras pessoas para isso [TAKAGI et al. 2007].
Para navegar na web, os deficientes visuais podem utilizar as tecnologias assistivas, que os auxiliam a utilizar o computador. Exemplos dessas tecnologias são os leitores de tela, que convertem texto em voz; ampliadores de tela, que ampliam áreas da tela; reconhecedores de comandos por voz, que interagem com o computador através de comandos por voz; entre outros [CHALEGRE 2011]. Essas tecnologias possuem limitações, que a depender do código HyperText Markup Language (HTML) da página, podem omitir informações ou não dar suporte a funcionalidades para o usuário [BRASIL 2009]. Por isso é importante desenvolver sites considerando as limitações dessas tecnologias, assim como perceber fatores subjetivos dessas pessoas que diferem sua forma de navegação das pessoas sem deficiência [ROCHA e DUARTE 2013b].
No intuito de promover uma web acessível o World Wide Web Consortium (W3C) criou a Web Accessibility Initiative (WAI), que elabora documentos com recomendações de acessibilidade, como a Web Content Accessibility Guidelines
(WCAG). Também no intuito de promover a acessibilidade, muitos países como Estados Unidos da América, Canadá, Portugal, Espanha, Inglaterra, entre outros, possuem legislações sobre a acessibilidade na web. No Brasil o decreto nº 5.296 de 2 de dezembro de 2004 determina que os sites mantidos por órgãos do governo federal sejam obrigados a utilizar as recomendações do Modelo de Acessibilidade do Governo Eletrônico (e-MAG), infelizmente a iniciativa privada esta isenta dessa obrigação [ROCHA e DUARTE 2012].
E apesar dessas e de outras iniciativas, os desenvolvedores geralmente ignoram o fator da acessibilidade em seus projetos ou mesmo desconhecem métodos para melhorá-la [GUERCIO et al. 2011], o que faz com que 98% dos sites brasileiros não sejam acessíveis, ainda que o número de pessoas com deficiência cresça a cada ano, principalmente devido ao aumento da perspectiva de vida da população [CHALEGRE 2011], essa falta de acessibilidade acaba frustrando os deficientes por fazer se sentirem limitados e dependentes [ROCHA e DUARTE 2013a]. Por isso o presente trabalho propõe a criação de uma biblioteca capaz de automatizar parte da tarefa de tornar um site acessível convertendo o seu código HTML em outro mais acessível, podendo ser utilizado pelos desenvolvedores para manterem seus sites mais acessíveis ou pelos usuários finais para que não dependam dos desenvolvedores para terem acessibilidade.
2. Desenvolvimento do HaTeMiLe
HTML Accessible (HaTeMiLe) é o nome da biblioteca de código-fonte aberto desenvolvida neste trabalho que procura melhorar a acessibilidade dos sites, convertendo um código HTML em outro mais acessível.
2.1. Linguagens de Programação
O HaTeMiLe foi desenvolvido em diversas linguagens de programação com as mesmas funcionalidades para garantir que ele possa ser utilizado, no server-side (aplicações que são executadas pelo servidor) e no client-side (aplicações que são executadas pelo cliente). Abaixo é listado as linguagens de programação em que o HaTeMiLe foi desenvolvido e os motivos da escolha de cada uma:
• A linguagem JavaScript foi escolhida por ser a padrão utilizada para os scripts executados no client-side dos documentos HTML [W3C 2014a];
• A linguagem CoffeeScript foi escolhida para ser convertida em códigos JavaScript eficientes e compatíveis com diversos navegadores [COFFEESCRIPT];
• A linguagem PHP Hypertext Preprocessor (PHP) foi escolhida por ser a mais utilizada no mundo para se desenvolver sites no server-side [W3TECHS]; • A linguagem Java foi escolhida por ser a linguagem de programação mais
utilizada no mundo [CASS 2014];
• As linguagens Ruby e Python foram escolhidas por serem as mais utilizadas entre os usuários do GitHub [FINLEY 2012].
2.2. Programação Orientada a Objetos
O HaTeMiLe foi desenvolvido utilizando o paradigma da Orientação a Objetos (OO), pois todas as linguagens de programação em que o HaTeMiLe foi desenvolvido possui suporte, a manutenção do código-fonte se torna mais simples e permite que classes e métodos possam ser reaproveitados [HOCK-CHUAN 2013].
O HaTeMiLe utiliza recursos para gerar e manipular o Document Object Model (DOM) do código HTML, essa manipulação ocorre através de recursos como os seletores Cascading Style Sheet (CSS) para encontrar os elementos no DOM. Para facilitar no desenvolvimento do HaTeMiLe se optou por utilizar bibliotecas de terceiros para cada linguagem de programação, sendo necessário definir interfaces para a manipulação do elemento e parser. Também foram projetadas interfaces para as soluções, para permitir que os desenvolvedores possam implementar novas classes de soluções para os problemas de acessibilidade que o HaTeMiLe procura resolver. As demais classes são auxiliares, como a classe de configuração, de funções comuns a todas as soluções e as classes para armazenar os dados.
2.3. Documentação
Como o código-fonte do HaTeMiLe é aberto, para que ele possa ser melhor compreendido por outros desenvolvedores, o código-fonte foi documentado, afim de explicar a finalidade de suas classes, seus métodos e seus parâmetros. Essa documentação foi escrita em inglês para que desenvolvedores do mundo todo possam contribuir com o desenvolvimento do HaTeMiLe.
3. Soluções de acessibilidade do HaTeMiLe
O HaTeMiLe modifica o código HTML passado, procurando retornar um código HTML mais acessível para o software que o implementa. Para fazer isso foram utilizadas como base de conhecimento os documentos WCAG 2.0 e o e-MAG 3.1, algumas funcionalidades do Job Access With Speech (JAWS), Opera e Mozilla Firefox.
3.1. Disponibilizar todas as funções da página via teclado
Essa solução corresponde a recomendação 2.1 do e-MAG 3.1 e as recomendações 2.1.1 e 2.1.3 do WCAG 2.0. Ambos os documentos citam os eventos JavaScript específicos para o mouse, como sendo os responsáveis pela inacessibilidade via teclado. Na versão do HaTeMiLe que executa no server-side, os elementos são encontrados por seus atributos dos eventos inacessíveis via teclado. Já a versão client-side do HaTeMiLe, é verificado diretamente se o elemento possui os eventos ou a lista de funções dos eventos inacessíveis via teclado, porém nativamente não é possível saber se nessa lista há algum evento, por isso é necessário incluir um script na página, que deverá ser o primeiro a ser executado, onde é modificada a forma como as funções são adicionadas e removidas da lista de funções dos eventos, por isso o próprio desenvolvedor deve incluí-lo no código HTML. Essa diferença faz com que a versão client-side encontre mais elementos que a versão server-side.
3.2. Fornecer descrições para os campos
O e-MAG recomenda a associação entre o campo e o seu rótulo através do atributo for. Por isso o HaTeMiLe se encarrega de tentar resolver esse tipo de problema, pois os leitores de tela podem possuir algum problema na leitura do rótulo do campo quando não são associados através do atributo for [BRASIL 2009].
3.3. Fornecer instruções para a entrada de dados
O HTML5 nativamente possui atributos para os elementos que podem ser utilizados para fornecer mais informações de entrada de dados para o usuário, porém navegadores como o Internet Explorer 8 não fornecem essas informações para o leitor de tela, que por sua vez consequentemente não fornecem ao usuário. Por isso o HaTeMiLe utiliza os estados e propriedades do Accessible Rich Internet Applications Suite (WAI-ARIA) para fornecer mais informações sobre o preenchimento de formulários para o usuário. O desenvolvedor pode utilizar o HaTeMiLe em conjunto com o CSS para fornecer essas informações, caso o agente de usuário não possua suporte ao WAI-ARIA.
3.4. Web Semântica e WAI-ARIA
Os leitores de tela utilizam as informações semânticas e os atributos do WAI-ARIA para disponibilizar mais informações para as tecnologias assistivas. Porém modificar a tag dos elementos pode causar diferenças visuais e comportamentais indesejáveis na página, por isso o HaTeMiLe disponibiliza a possibilidade de adicionar ou alterar os atributos dos elementos, sendo necessário o desenvolvedor informar quais serão os seletores CSS que serão modificados e quais serão essas modificações.
3.5. Fornecer âncoras para ir direto a um bloco de conteúdo
Essa solução corresponde as recomendações 1.5 do e-MAG 3.1 e 2.4.1 do WCAG 2.0. Utilizar âncoras para ir diretamente para um bloco de conteúdo pode diminuir o tempo de navegação do usuário com deficiência visual, isso porque a navegação dos deficientes visuais geralmente é linear e esses links dispostos no início da página oferecem um acesso rápido as partes de interesse do usuário [TAKAGI et al 2007]. 3.6. Associar células de dados às células de cabeçalho
Essa solução corresponde as recomendações 3.10 do e-MAG 3.1 e 1.3.1 do WCAG 2.0. Ela ajuda a melhorar a acessibilidade quando a tabela é utilizada para apresentar dados tabulares, porém utilizá-la em tabelas para layout pode piorar a acessibilidade da página, por isso o HaTeMiLe realiza esse tratamento apenas em tabelas que estão sintaticamente e semanticamente correta, e com cabeçalho e corpo definidos.
3.7. Exibir a lista de atalhos da página
Quando um elemento possui uma tecla de atalho definida, os navegadores Mozilla Firefox, Google Chrome, Safari e Internet Explorer não possuem um recurso nativo para informar ao usuário da existência dessas teclas de atalho, apesar de poder utilizá-las, entretanto o Opera ao pressionar as teclas ALT + Escape, exibe a lista de teclas de atalhos da página para o usuário ou então exibe uma mensagem informando que a página não possui teclas de atalhos. O HaTeMiLe procura proporcionar uma funcionalidade semelhante ao do Opera em todos os navegadores, utilizando os atributos ou o próprio conteúdo do elemento em último caso, para descrever o atalho, em contrapartida do Opera que utiliza o atributo de título do elemento para descrever o atalho. No intuito de melhorar o próprio recurso do Opera, caso o elemento não possua um atributo de título o mesmo será definido pelo HaTeMiLe, o que faz com que o usuário que utilize o recurso nativo do Opera possa se beneficiar do uso do HaTeMiLe. 3.8. Prover uma forma de navegação para a descrição longa de uma imagem Apesar de existir na especificação do elemento IMG o atributo de descrição longa da
imagem [W3C, 2014b], foi percebido que os navegadores Google Chrome, Safari, Internet Explorer, Lynx e WebVox não possuem uma forma de navegar para a descrição longa das imagens, entretanto o Mozilla Firefox e o Opera oferecem no menu quando o elemento está focado a possibilidade de navegar para a descrição longa da imagem. Devido a isso o HaTeMiLe procura dar acesso a esse recurso em todos os navegadores. 3.9. Promover a navegação entre os cabeçalhos da página
O JAWS possibilita a mudança na forma de navegação do usuário disponibilizando a possibilidade de navegação entre os cabeçalhos da página. Quando a página utiliza os cabeçalhos da página para separar as seções da página, possibilita que o usuário possa navegar de forma mais eficiente, isso é muito útil para os usuários com deficiência visual que navegam de forma linear [TAKAGI et al. 2007]. Baseado no JAWS, o HaTeMiLe disponibiliza uma forma de navegação entre os cabeçalhos da página, tendo como exigência a sintaxe correta dos cabeçalhos.
4. Conclusão
A web possibilita que os usuários com deficiência visual possam interagir com ela com autonomia, porém a falta de acessibilidade nos sites, acaba fazendo com que os deficientes visuais continuem enfrentando barreiras e dependentes de outras pessoas.
Por isso o presente trabalho buscou mostrar uma forma de resolver esse problema, fornecendo uma ferramenta capaz de converter o código HTML de uma página em outro mais acessível, apesar de que a maioria dos problemas de acessibilidade listados no e-MAG 3.1 e WCAG 2.0 não foram resolvidos pelo HaTeMiLe. Também está sendo desenvolvido um plugin para o WordPress, para que os desenvolvedores utilizem, e extensões para o Mozilla Firefox e Google Chrome, para que os usuários finais utilizem, que implementam o HaTeMiLe.
Se espera que este trabalho possa incentivar o desenvolvimento de novas tecnologias capazes de melhorar a acessibilidade na web.
Referências
BRASIL. Modelo de acessibilidade de governo eletrônico (e-MAG). Brasília, DF, 2014. ______. Leitores de Tela: Pontos de Fragilidade. Brasília, DF, 2009.
CASS, Stephen. Top 10 Programming Languages. IEEE Spectrum. 2014. Disponível em: <http://spectrum.ieee.org/computing/software/top-10-programming-languages>. Acessado em 01/01/2015.
CHALEGRE, Virgínia Carvalho. Uma metodologia de testes de acessibilidade para usuários cegos em ambientes web. Dissertação (Mestrado em Ciência da Computação) – Centro de Informática da Universidade Federal de Pernambuco. Recife: Universidade Federal de Pernambuco, 2011.
COFFEESCRIPT. CoffeeScript. Disponível em: <http://coffeescript.org/>. Acesso em: 10/02/2015.
HOCK-CHUAN, Chua. Object-Oriented Programming (OOP) in C++. 2013. Disponível em: <https://www3.ntu.edu.sg/home/ehchua/programming/cpp/cp3_OOP.html>. Acesso em: 10/02/2015.
ReadWrite. 2012. Disponível em: <http://readwrite.com/2012/06/05/5-ways-to-tell-which-programming-lanugages-are-most-popular>. Acessado em: 09/01/2015.
ROCHA, Janicy Aparecida Pereira; DUARTE, Adriana Bogliolo Sirihal. (In)Acessibilidade na web para pessoas com deficiência visual: Um estudo de usuários à luz da cognição situada. In: XIV Encontro Nacional de Pesquisa em Ciência da Informação. 2013a.
______. O comportamento de usuários cegos durante o acesso mediado por leitores de tela: Um estudo sob o enfoque da cognição situada. Perspectivas em Gestão & Conhecimento, v. 3, n. 3, p. 173-196, 2013b.
______. Diretrizes de acessibilidade web: um estudo comparativo entre as WCAG 2.0 e o e-MAG 3.0. In: Inc. Soc., Brasília, DF, v. 5 n. 2, p.73-86, jan./jun. 2012.
TAKAGI, Hironobu et al. Analysis of navigability of Web applications for improving blind usability. ACM Transactions on Computer-Human Interaction (TOCHI), v. 14, n. 3, p. 13, 2007.
W3C. Scripting – HTML5. 2014a. Disponível em: <http://www.w3.org/TR/2014/REC-html5-20141028/scripting-1.html>. Acesso em: 10/02/2015.
______. HTML5 Image Description Extension (longdesc). 2014b. Disponível em: <http://www.w3.org/TR/2014/PR-html-longdesc-20141204/>. Acesso em: 10/02/2015.
W3TECHS. Usage of server-side programming languages for websites. Disponível em: <http://w3techs.com/technologies/overview/programming_language/all>. Acessado em 01/01/2015.
GUERCIO, Angela et al. Addressing challenges in web accessibility for the blind and visually impaired. System and Technology Advancements in Distance Learning, p. 249, 2012.
