universidade estadual de santa cruz victor …vajoliveira/documents/tcc_escanner.pdf · victor...
TRANSCRIPT
UNIVERSIDADE ESTADUAL DE SANTA CRUZ
VICTOR ADRIEL DE JESUS OLIVEIRA
ACESSIBILIDADE EM SITES E SISTEMAS WEB: criação de uma ferramenta
para validação de páginas Web segundo o e-MAG - Modelo de Acessibilidade
de Governo Eletrônico.
ILHÉUS – BA
2012
VICTOR ADRIEL DE JESUS OLIVEIRA
ACESSIBILIDADE EM SITES E SISTEMAS WEB: criação de uma ferramenta
para validação de páginas Web segundo o e-MAG - Modelo de Acessibilidade
de Governo Eletrônico.
ILHÉUS – BA
2012
Trabalho de Conclusão de Curso apresentado, para obtenção do título de Bacharel em Ciência da Computação, à Universidade Estadual de Santa Cruz. Área de concentração: Interação Humano-Computador Orientadora: Prof.ª Dr.ª Vânia Cordeiro da Silva
VICTOR ADRIEL DE JESUS OLIVEIRA
ACESSIBILIDADE EM SITES E SISTEMAS WEB: criação de uma ferramenta
para validação de páginas Web segundo o e-MAG - Modelo de Acessibilidade
de Governo Eletrônico.
Ilhéus-BA, 12/01/2012.
________________________________________________________ Prof.ª Dr.ª Vânia Cordeiro da Silva
UESC (Orientadora)
________________________________________________________ Prof. Dr. Paulo Eduardo Ambrósio
UESC
________________________________________________________ Prof. Dr. Francisco Bruno Souza Oliveira
UESC
"A acessibilidade é sempre desejável porque expande seu mercado, e para
muitos sites do governo e educacionais, o design acessível é um requisito."
(Jakob Nielsen)
iv
ACESSIBILIDADE EM SITES E SISTEMAS WEB: criação de uma ferramenta
para validação de páginas Web segundo o e-MAG - Modelo de Acessibilidade
de Governo Eletrônico.
RESUMO
Uma das fases na construção de Web sites acessíveis consiste da validação automática do seu conteúdo. Para isso existem várias ferramentas que detectam e analisam o código HTML, verificando se este está ou não em acordo com um conjunto de regras de acessibilidade. Para utilizar muitas dessas ferramentas é necessário que o Web site esteja hospedado em uma máquina servidora que possa ser acessada através da Internet. O foco deste trabalho está no desenvolvimento de um programa para validação automática de páginas Web segundo o Modelo de Acessibilidade de Governo Eletrônico – e-MAG. Esse programa foi construído como uma extensão do navegador Google Chrome a fim de facilitar sua utilização integrando-o ao ambiente de desenvolvimento do usuário e possibilitando sua utilização em modo off-line. Quando ativado, o programa avalia o código do documento aberto e mostra erros, avisos e sugestões com base nas recomendações de acessibilidade do governo brasileiro. Palavras-chave: Interação Humano–Computador; e-Acessibilidade; Validação automática de acessibilidade; e-MAG; Chrome Extensions.
v
LISTA DE FIGURAS
1 Gráfico da StatCounter mostra que navegador Chrome ultrapassou o IE em novembro de 2011 ..................................................................................
25
2 Tela da versão gratuita do Scrumy feita para melhor visualização do cronograma do projeto ..................................................................................
26
3.1 Arquitetura da extensão desenvolvida para o navegador Google Chrome .. 30
3.2 Diagrama de sequência do processo de validação da página aberta .......... 31
4 Resultado da análise do código fonte da página aberta no navegador ........ 35
5 Mensagem exibida quando código fonte não é capturado pelo programa ... 35
6 Mensagem indicando que não foi possível realizar a análise da página ...... 36
7 Extensão sendo instalada no navegador Google Chrome ............................ 37
8 Em destaque, menu de skip links mostra quantidade de erros e alertas ...... 40
9 Relação de erros encontrados (a) e relação de alertas emitidos (b) de acordo às recomendações do e-MAG v3.0 ...................................................
42
10 Tela contendo links e descrição do e-MAG .................................................. 43
11 Tela contendo links para tutoriais e outras ferramentas ............................... 43
12 Tela de ajuda quanto à utilização da extensão ............................................. 44
13 Comparação entre resultados da avaliação do sítio da Universidade Estadual de Santa Cruz pelo daSilva e pelo eScanner ................................
46
vi
LISTA DE SIGLAS
AJAX Asynchronous Javascript and XML
API Application Programming Interface
ASES Avaliador e Simulador de Acessibilidade de Sítios
BSD Berkeley Software Distribution
CSS Cascading Style Sheets
DGE Departamento de Governo Eletrônico
e-MAG Modelo de Acessibilidade de Governo Eletrônico
GPL GNU General Public License
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IBGE Instituto Brasileiro de Geografia e Estatística
IE Internet Explorer
ONG Organização Não Governamental
ONU Organização das Nações Unidas
RENAPI Rede de Pesquisa e Inovação em Tecnologias Digitais
SLTI Secretaria de Logística e Tecnologia da Informação
STL Standard Template Library
URL Uniform Resource Locator
W3C World Wide Web Consortium
WAI Web Accessibility Initiative
WCAG Web Content Accessibility Guidelines
XML Extensible Markup Language
vii
SUMÁRIO
Resumo .............................................................................................. iv
Lista de figuras .................................................................................. v
Lista de siglas .................................................................................... vi
1 INTRODUÇÃO .................................................................................... 9
1.1 Identificação do problema ................................................................... 10
1.2 Objetivo ............................................................................................... 11
1.3 Organização do trabalho ..................................................................... 11
2 REVISÃO DE LITERATURA .............................................................. 13
2.1 Acessibilidade à Web .......................................................................... 13
2.2 As leis inclusivas ................................................................................. 15
2.3 Diretrizes de acessibilidade ................................................................. 17
2.3.1 e-MAG ................................................................................................. 18
2.4 Ferramentas de validação ................................................................... 20
2.5 Analisadores sintáticos ........................................................................ 22
2.5.1 Análise ascendente e handles ............................................................. 23
3 MATERIAIS E MÉTODOS .................................................................. 24
3.1 Notepad++ ........................................................................................... 24
3.2 Google Chrome ................................................................................... 25
3.3 Scrumy ................................................................................................ 26
3.4 HTML Parser ....................................................................................... 27
4 DESENVOLVIMENTO DA EXTENSÃO ............................................. 28
4.1 Adaptação do HTML Parser ................................................................ 28
4.2 Arquitetura da extensão ...................................................................... 30
4.2.1 Arquivo Manifest .................................................................................. 31
4.2.2 Popup .................................................................................................. 32
4.2.2.1 Chrome-only APIs .............................................................................. 33
4.2.2.2 XMLHttpRequest ................................................................................. 33
4.2.2.2.1 Quando é possível analisar a página .................................................. 34
4.2.2.2.2 Quando não é possível capturar o código fonte da página ................. 34
4.2.2.2.3 Quando não é possível realizar a análise ........................................... 36
4.3 Como utilizar a extensão ..................................................................... 37
4.3.1 Executando o programa ...................................................................... 37
4.3.2 Identificação de erros .......................................................................... 38
4.3.3 Emissão de alertas .............................................................................. 39
viii
4.3.4 Elementos da página de exibição dos resultados ............................... 39
4.3.4.1 Menu com as quantidades de erros e alertas ..................................... 40
4.3.4.2 Box principal ........................................................................................ 41
4.3.4.3 Lista de erros e lista de alertas ............................................................ 41
4.3.5 Demais telas ........................................................................................ 41
4.3.5.1 Sobre o e-MAG .................................................................................... 42
4.3.5.2 Tutoriais ............................................................................................... 42
4.3.5.3 Ajuda ................................................................................................... 44
5 RESULTADOS E DISCUSSÃO .......................................................... 45
5.1 Comparação com outros validadores automáticos ............................. 45
6 CONCLUSÃO E TRABALHOS FUTUROS ........................................ 47
7 REFERÊNCIAS ................................................................................... 48
9
1 INTRODUÇÃO
Existem leis que garantem a deficientes e outras pessoas com algum tipo de
limitação, direitos que incluem o acesso, em igualdade de oportunidades com as
demais pessoas, à informação e comunicação, inclusive aos sistemas e tecnologias
da informação e comunicação. Essas medidas que devem incluir a identificação e a
eliminação de obstáculos e barreiras à acessibilidade, devem ser aplicadas, entre
outros, para promover o acesso de pessoas com deficiência a novos sistemas e
tecnologias da informação e comunicação, inclusive à Internet (BRASIL, 2008).
Uma fatia da acessibilidade requerida por lei com relação a sistemas de
informação computadorizados diz respeito à acessibilidade à Web, também
conhecida por e-Acessibilidade. Esta depende do trabalho conjunto dos vários
setores de desenvolvimento e de interação, mas, sobretudo do pessoal envolvido
com desenvolvimento. Aparentemente, um dos motivos da ocorrência de tantos sites
não acessíveis é a existência de desenvolvedores sem o conhecimento dos itens
básicos de acessibilidade ou mesmo sem maiores preocupações com ela e também
devido à política interna das empresas. Quaisquer ferramentas que facilitem o
processo de criação de sites seguindo esses padrões contribuem fortemente para a
adoção de uma cultura de desenvolvimento voltada para a acessibilidade.
Esse trabalho apresenta o processo de desenvolvimento de uma ferramenta
para validação de páginas Web segundo o modelo de acessibilidade nacional que
facilite sua adoção e aprendizado pelos desenvolvedores de conteúdo para a Web.
10
1.1 Identificação do problema
Segundo Nielsen (2007), o design de interface pode aleijar ou conferir
grandes poderes aos usuários. Ele ainda afirma que um bom site deve ser acessível
a todos os públicos com diferentes níveis de capacidades. No entanto, essa
acessibilidade é de responsabilidade de todos aqueles que produzem conteúdo para
a Web. Esse conteúdo deve ser sempre analisado e avaliado segundo normas
técnicas de acessibilidade e essa avaliação pode ser realizada em grande parte por
ferramentas automáticas.
Existem várias ferramentas automáticas para validação de acessibilidade em
páginas Web, no entanto só duas delas se baseiam no Modelo de Governo
Eletrônico – e-MAG – em sua versão 2.0, a ferramenta on-line daSilva, mantida pelo
grupo Acessibilidade Brasil, e o software ASES - Avaliador e Simulador de
Acessibilidade de Sítios (NICÁCIO, 2010). Na utilização de ambos é necessário
acessar a ferramenta e colocar o endereço URL da página que se deseja avaliar.
Além disso, essa página deverá estar disponível em uma máquina servidora que
possa ser acessada através da Internet.
Esse trabalho diz respeito à criação de mais uma opção de ferramenta de
avaliação baseada no modelo de acessibilidade nacional, que, no entanto, seja mais
prática em sua utilização e esteja fundamentada na terceira e mais recente versão
do e-MAG. A avaliação do conteúdo por parte de uma ferramenta de validação
automática que funcione acoplada ao navegador aparenta ser mais prática do que
através de outros programas e de ferramentas on-line, pois um software navegador
faz parte do ambiente de desenvolvimento de qualquer desenvolvedor de conteúdos
para a Web. Além disso, a ferramenta proposta deverá avaliar páginas localizadas
11
na própria máquina do usuário, por exemplo, em um servidor Apache. Para a
promoção do e-MAG, cuja adoção é fortemente recomendada, sobretudo no
desenvolvimento dos sites públicos, a ferramenta também deverá concentrar
tutoriais e outras referências sobre o modelo, servindo de fonte para consulta e
aprimoramento dos seus usuários.
1.2 Objetivo
Construção de uma extensão para o navegador Google Chrome para
validação automática de páginas Web segundo o e-MAG - Modelo de Acessibilidade
de Governo Eletrônico.
1.3 Organização do trabalho
Este trabalho de conclusão de curso está organizado em seis capítulos, cujos
conteúdos estão descritos a seguir:
a) O Capítulo 1 apresenta a introdução, identificação do problema, objetivo e
organização do trabalho;
b) O Capítulo 2 apresenta a revisão de literatura tratando de tópicos
relacionados diretamente ao tema do trabalho. São eles: Acessibilidade à
Web, leis inclusivas, diretrizes de acessibilidade, o e-MAG e ferramentas
de validação;
c) O Capítulo 3 apresenta materiais e métodos utilizados no desenvolvimento
da ferramenta proposta;
d) O Capítulo 4 apresenta o processo de desenvolvimento da ferramenta;
12
e) O Capítulo 5 apresenta resultados e discussão. Nesta seção os resultados
da ferramenta desenvolvida serão comparados com os de outras
ferramentas e serão feitas observações pelo autor;
f) O Capítulo 6 apresenta a conclusão deste trabalho e trabalhos futuros;
g) E por fim, o Capítulo 7 apresenta as referências utilizadas.
13
2 REVISÃO DE LITERATURA
2.1 Acessibilidade à Web
O termo acessibilidade surgiu na França como a necessidade de transposição
dos obstáculos arquitetônicos que impedem o acesso de pessoas com deficiência a
lugares de uso comum e público (QUEIROZ, 2005). Não obstante, o termo
acessibilidade hoje é empregado como a possibilidade de qualquer pessoa usufruir
dos benefícios gerados pela vida em sociedade (FERREIRA; NUNES, 2008).
No tocante a sistemas digitais, como a Web, definida como um conjunto de
páginas HTML interligadas por links de hipertexto, são quatro as situações com as
quais seus usuários geralmente se deparam e que podem caracterizar-se como
barreiras no acesso à informação (BRASIL, 2011; FERREIRA; NUNES, 2008):
a) Conteúdo dependente da utilização do mouse: pessoas com dificuldades
motoras, portadoras de deficiência física ou visual podem ter dificuldade
em utilizar o mouse ou mesmo serem incapazes de utilizá-lo. Nesses
casos, todo conteúdo acessível apenas através da utilização do mouse se
tornará inacessível a esses usuários;
b) Conteúdo dependente da utilização do teclado: assim como na restrição
do acesso ao conteúdo à utilização do mouse, muitos usuários têm
dificuldade em utilizar o teclado comum. Seja essa limitação causada por
dificuldades motoras ou qualquer outro tipo de limitação, esse conteúdo
14
deverá ser acessível por meio da utilização de outros recursos ou
periféricos;
c) Conteúdo puramente visual: esse conteúdo precisará ser tratado para que
seu acesso através de programas ledores de tela seja possível e facilitado.
É importante lembrar que as deficiências visuais variam muito e nem todos
os usuários com algum nível de deficiência visual requerem a utilização de
tecnologias assistenciais (NIELSEN, LORANGER; 2007). Esses usuários
também precisarão ter seu acesso facilitado a esse tipo de conteúdo;
d) Conteúdo aural: conteúdos dependentes da audição podem se tornar
inacessíveis para pessoas com algum tipo de deficiência ou pela
indisponibilidade de dispositivos de áudio.
Segundo Nielsen (2007), um site acessível é aquele que remove os
obstáculos do caminho das pessoas. Possibilitar o redimensionamento de texto
numa página, por exemplo, resulta numa melhor legibilidade permitindo que a
deficiência visual seja superada (NIELSEN, LORANGER; 2007).
Segundo a Organização das Nações Unidas – ONU (BRASIL, 2008), 10% da
população dos países desenvolvidos possui algum tipo de deficiência, permanente
ou temporária. Este número sobe para 25% da população de países em
desenvolvimento ou subdesenvolvidos. Já no Brasil, segundo o Instituto Brasileiro de
Geografia e Estatística – IBGE (IBGE, 2000), o censo demográfico de 2000
identificou 34.580.721 pessoas com alguma deficiência. Contudo, é importante
ressaltar que a acessibilidade não diz respeito apenas a pessoas portadoras de
deficiência, e deve envolver as diversas situações e características que o usuário
pode apresentar (FERREIRA; NUNES, 2008). Logo podemos definir a acessibilidade
à Web, ou e-Acessibilidade, como a remoção das barreiras que impedem o acesso à
15
Web tanto por deficientes visuais (cegueira, daltonismo, baixa visão), deficientes
auditivos e deficientes físicos, sendo essa deficiência temporária ou permanente,
como também por usuários de dispositivos móveis, usuários de mídias com
diferentes resoluções de tela, usuários de diferentes faixas etárias e usuários com
conexão à Internet de baixa velocidade, por exemplo.
2.2 As leis inclusivas
A Lei Federal n°. 8.112/90 estabelece a reserva de vagas no percentual de
20% para concursos federais e o Decreto 3.298 baliza, para os demais níveis da
Federação, o percentual mínimo de 5% das vagas para pessoas portadoras de
necessidades especiais. A Lei n°. 8.213 fixa cotas para trabalhadores com
deficiências, habilitados ou reabilitados, nas empresas particulares, nos percentual
de 2% para empresas que possuam de 100 a 200 empregados, 3% para aquelas
que possuam de 201 a 500 trabalhadores, 4% onde houver de 501 a 1000
empregados e 5% para empresas com número de empregados superior a 1001
(BRASIL, 1991). Essa reserva de mercado gerou muitas oportunidades de emprego
para as pessoas com deficiência, permitindo a inclusão destes nas atividades
comuns de toda a sociedade, retirando-os da dependência familiar.
Esse público, composto por cidadãos e profissionais, muitas vezes ativos no
mercado de trabalho, precisa ter acesso pleno às informações e à comunicação a
fim de que possa desempenhar bem seu papel no contexto social. Além disso,
também fazem parte do mercado consumidor e devem poder usufruir de sua renda
como preferirem e isso inclui o acesso a sistemas que disponibilizam seus serviços
na rede mundial de computadores. Portanto pensar em acessibilidade não se trata
16
apenas de altruísmo, trata-se também de enxergar o público não-padrão e com
necessidades especiais como potenciais consumidores. Segundo Nielsen (2007), “a
acessibilidade é sempre desejável porque expande seu mercado, e para muitos sites
do governo e educacionais, o design acessível é um requisito”.
É possível realizar várias operações através da rede mundial de
computadores e algumas atividades só podem ser realizadas através da Internet.
Mesmo tendo um computador com acesso a Internet disponível, nem todas as
pessoas conseguem realizar tais atividades. A tecnologia da Web não deveria ser
mais uma barreira a ser transposta por estas pessoas, mas, ao contrário, um veículo
de transposição de barreiras e melhora da qualidade de vida. A Internet facilita a
vida de pessoas portadoras de necessidades especiais, pois possibilita que elas
criem novas formas de relacionamento e desempenhem atividades antes inviáveis
(FERREIRA; NUNES, 2008).
Hoje o termo acessibilidade é reconhecido por lei como “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 portadora
de deficiência ou com mobilidade reduzida;” (BRASIL, 2004). Iniciativas que facilitem
o acesso à comunicação e informação por quem possui qualquer tipo de limitação,
ainda que temporária, são respaldadas e reclamadas por lei.
As leis inclusivas, entre outros incentivos a práticas que visam acessibilidade,
promoveram a pesquisa, desenvolvimento e emprego de tecnologias acessivas, que
são as tecnologias concebidas para ajudar pessoas com incapacidades ou
deficiências a executarem atividades do cotidiano. Para auxiliar a utilização de
computadores e a navegação na Web por pessoas com deficiência, existem
17
equipamentos e programas especiais, como programas ledores de tela,
sintetizadores de voz, displays em Braille, ampliadores de tela (para pessoas de
baixa visão), programas de comando de voz para cegos e pessoas com dificuldades
na digitação; teclados e mouses especiais controlados por um joystick ou pelos
movimentos da cabeça, por exemplo, para pessoas com dificuldades motoras.
2.3 Diretrizes de acessibilidade
É necessário notar que um ledor de tela, por exemplo, utilizado em programas
navegadores gráficos, tem a função não somente de fazer a leitura dos conteúdos
puramente textuais existentes em uma página web, mas também de descrever a
estrutura dessa página (QUEIROZ, 2005). Ele tem que informar ao seu usuário
quando encontra um menu, uma imagem, um hiperlink, entre outros. Para que isso
aconteça corretamente, páginas Web devem ser desenvolvidas de forma apropriada
para poderem ser interpretadas adequadamente por estes programas. Por isso, um
dos cuidados fundamentais que os desenvolvedores de conteúdo para a Web
devem ter é desenvolver seu código fonte dentro dos padrões de acessibilidade
(acessibility web standards). É o que a ferramenta desenvolvida buscará possibilitar,
através da avaliação do código fonte da página e da emissão de alertas e erros
segundo o e-MAG.
Existem atualmente vários documentos internacionais que propõem regras de
e-Acessibilidade com o propósito de orientar desenvolvedores de ferramentas de
criação, ferramentas de avaliação e desenvolvedores de conteúdo. Todos, no
entanto, baseiam-se em diretrizes do World Wide Web Consortium – W3C
(NICÁCIO, 2010).
18
O W3C é uma organização mundialmente conhecida por elaborar
documentos de especificação de tecnologias especialmente criadas para a Web. Por
intermédio da iniciativa WAI (Web Accessibility Initiative), o W3C desenvolve
diretrizes para acessibilidade Web. Existem diretrizes específicas para diferentes
grupos de componentes e a WCAG (Web Content Accessibility Guidelines),
destinada para conteúdo das páginas Web, compõe um desses grupos (W3C,
2011).
Além da WCAG, uma errata da WCAG conhecida como WCAG Samurai e o
conjunto de diretrizes nacional, o Modelo de Acessibilidade do Governo Brasileiro (e-
MAG), são os documentos mais populares e ainda assim alguns profissionais as
desconhecem. Já outros coletam aquelas que consideram as melhores práticas
sugeridas por cada documento para conferir acessibilidade aos seus projetos e
acabam por não atender completamente aos requisitos por esquecerem ou
desconhecerem alguma necessidade específica.
2.3.1 e-MAG
O Decreto nº 5.296, assinado em dezembro de 2004, regulamentou leis
anteriores e estabeleceu um prazo de doze meses, prorrogáveis por mais doze, para
que todos os sites públicos, de interesse público ou financiados pelo governo fossem
remodelados visando sua acessibilidade (BRASIL, 2004; FERREIRA; NUNES,
2008). Para se fazer cumprir as normas de acessibilidade, criou-se um Comitê da
ABNT incumbido de comparar normas de acessibilidade de outros países, bem
como as diretrizes propostas pela W3C e compilar um documento que mais tarde foi
19
utilizado como base para a criação do e-MAG, o Modelo de Acessibilidade de
Governo Eletrônico (NICÁCIO, 2010).
Ficou sob responsabilidade do Departamento de Governo Eletrônico (DGE)
da Secretaria de Logística e Tecnologia da Informação (SLTI) do Ministério do
Planejamento, Orçamento e Gestão a elaboração desse modelo brasileiro de
acessibilidade a partir da comparação com documentos internacionais e de acordo
às necessidades nacionais. Em 18 de Janeiro de 2005 a primeira versão do e-MAG
foi disponibilizada para consulta pública e a versão 2.0 em 14 de dezembro do
mesmo ano.
O modelo de acessibilidade brasileiro foi elaborado pelo Departamento de
Governo Eletrônico em parceria com a ONG Acessibilidade Brasil em dois
documentos (FERREIRA; NUNES, 2008):
a) A Visão Técnica: lançada em formato de cartilha e destinada aos
projetistas e aos desenvolvedores de sites. A Visão Técnica apresenta
detalhadamente a proposta de implementação das recomendações de
acessibilidade em sítios do governo;
b) A Visão do Cidadão: voltada a todos os cidadãos brasileiros. A Visão do
Cidadão é uma abstração da Visão Técnica criada para apresentar o
modelo de acessibilidade de forma simples para sua fácil compreensão.
Nicácio (2010) afirma que, para quem nunca chegou a ler um documento de
orientação de acessibilidade, o e-MAG é um bom começo devido à sua organização
facilitar a compreensão de suas recomendações. No entanto, durante a
disseminação do e-MAG foi notado que essa divisão na verdade pareceu dificultar a
compreensão do modelo.
20
A nova versão foi desenvolvida através da parceria entre o Departamento de
Governo Eletrônico e o Projeto de Acessibilidade Virtual da RENAPI (Rede de
Pesquisa e Inovação em Tecnologias Digitais), baseada na versão 2.0 do e-MAG e
na versão 2.0 da WCAG, lançada em dezembro de 2008. A versão 3.0 do e-MAG foi
elaborada em um único documento, sem a antiga divisão entre Visão Técnica e
Visão do Cidadão. Outra decisão foi o abandono dos níveis de prioridade A, AA e
AAA, presentes também nas diretrizes da W3C e nas versões anteriores do e-MAG.
Além disso, foi incluída a seção chamada “Padronização de acessibilidade nas
páginas do Governo Federal”, a fim de padronizar elementos de acessibilidade
requeridos em todos os sítios e portais do governo (BRASIL, 2011).
2.4 Ferramentas de validação
Ferramentas de validação são ferramentas semi-automáticas que analisam se
o código HTML está de acordo com as recomendações de acessibilidade (NICÁCIO,
2010).
Ferreira (2008) descreve cinco fases seguidas no desenvolvimento de sites
acessíveis e as ferramentas de avaliação e validação de acessibilidade se fazem
presentes em grande parte do processo de desenvolvimento:
a) Fase 1 – Verificação da Necessidade de Acessibilidade do Conteúdo: essa
etapa consiste em identificar a necessidade de adaptação de algum dos
elementos ou conteúdos da página segundo as exigências de
acessibilidade estabelecidas por diretrizes como a WCAG e o e-MAG.
Essa verificação pode ser auxiliada pela utilização de um software
avaliador de acessibilidade;
21
b) Fase 2 – Acessibilização do Conteúdo: é o processo de adequação de
todo o conteúdo identificado na etapa anterior como carente de adaptação
segundo normas de acessibilidade. Alguns programas validadores já
fornecem sugestões sobre como “acessibilizar” esse conteúdo;
c) Fase 3 – Validação da Acessibilidade do Conteúdo: consiste em verificar
se o site atende às exigências de acessibilidade. Nessa fase novamente
se faz necessária a utilização de ferramentas automáticas de validação;
d) Fase 4 – Promoção da Acessibilidade Conquistada: depois de verificada a
conformidade com as normas de acessibilidade é possível receber um
selo segundo o nível de acessibilidade alcançado. Este selo pode ser
colocado no site para que seus usuários saibam que a página foi
desenvolvida visando sua acessibilidade;
e) Fase 5 – Garantia Contínua da Acessibilidade: consiste na repetição das
fases anteriores sempre que o site for atualizado a fim de que se
mantenha sempre acessível.
Sempre que a acessibilidade do projeto for testada, essa validação deve ser
feita por meio de ferramentas automáticas e também da revisão direta. Os métodos
automáticos são geralmente rápidos, mas não são capazes de identificar todas as
vertentes da acessibilidade. A avaliação humana pode ajudar a garantir a clareza da
linguagem e a facilidade da navegação.
Para realizar os testes podem ser utilizadas ferramentas automatizadas,
validadores de sintaxe (HTML, XML, CSS, etc.) da W3C, navegadores em modo
texto (ou mesmo desabilitar a folha de estilos da página no browser) para averiguar
a integridade das informações sem a presença da apresentação, fazer testes sem a
utilização do mouse, do monitor e de dispositivos de áudio simulando diferentes
22
necessidades do usuário, usar ledores de tela, testar em navegadores e resoluções
diferentes, e mesmo submeter às páginas desenvolvidas a aprovação de usuários
diferentes com necessidades específicas.
2.5 Analisadores sintáticos
Análise Sintática ou parsing é o processo de análise de um texto a fim de
determinar se sua estrutura gramatical respeita uma determinada gramática. Em um
programa tradutor ou compilador, o analisador sintático trabalha em conjunto com o
analisador léxico, recebendo deste uma cadeia de tokens para verificar se a mesma
pode ser gerada pela gramática formal da linguagem (AHO et al., 1995).
Para o reconhecimento de tokens o analisador léxico pode utilizar expressões
regulares, as quais também podem ser descritas por gramáticas. Já na análise
sintática é mais comum a utilização de gramáticas livres de contexto, por serem
notações mais poderosas que expressões regulares. Expressões regulares são mais
úteis para descrever a estrutura de construções léxicas mais simples como
identificadores, enquanto que gramáticas podem ser recursivas tornando-se mais
úteis na descrição de estruturas aninhadas, tais como os elementos de marcação da
linguagem HTML.
Há duas estratégias básicas para a análise sintática:
a) Estratégia Top-Down (ou descendente): a árvore de derivação é
construída partindo da raiz da árvore (símbolo inicial da gramática) até as
folhas (cadeia de entrada);
b) Estratégia Bottom-Up (ou ascendente): a árvore de derivação é construída
a partir das folhas até a raiz.
23
2.5.1 Análise ascendente e handles
Afirmar que na abordagem Bottom-Up a árvore de derivação é construída a
partir das folhas até a raiz significa dizer que esta estratégia de análise sintática
constrói sua árvore a partir da cadeia de entrada, composta pelos tokens recebidos
do analisador léxico, empilhando esses tokens até que componham uma sequência
reconhecida por uma gramática formal. O processo de redução consiste da
substituição de cada subcadeia que reconheça o lado direito de uma produção na
gramática pelo símbolo à esquerda da produção. Esse processo de redução se
repete até que a entrada seja completamente lida. Se a entrada for válida a pilha
deverá ter sido reduzida ao símbolo inicial da gramática (PRICE; TOSCANI, 2005).
Um handle é uma subcadeia que reconhece o lado direito de uma produção.
E no processo de análise sintática ascendente, um handle é sempre substituído pelo
símbolo não-terminal do lado esquerdo da produção que lhe corresponde. O uso da
sequência correta de handles no processo de redução é o que deverá levar ao
símbolo inicial da gramática.
24
3 MATERIAIS E MÉTODOS
Esta seção faz menção às ferramentas utilizadas para o desenvolvimento da
extensão. Além do navegador Google Chrome, para o qual a extensão foi produzida,
foi utilizado o editor de texto Notepad++, o Scrummy, que funciona como um kaban
virtual, e um parser de código HTML, escrito em JavaScript e desenvolvido por John
Resig.
3.1 Notepad++
O Notepad++ (Copyright © Don Ho 2011) é uma ferramenta livre e gratuita
para edição de código fonte com suporte a várias linguagens de programação. Em
execução no ambiente MS Windows, sua utilização é regida pela licença GPL
(NOTEPAD++, 2011). Foi escolhido por ser uma ferramenta simples e que contém
muitas funcionalidades que auxiliam a escrita do código fonte.
Baseada no componente de edição Scintilla, o Notepad++ foi desenvolvido
em C++ e utiliza a API Win32 e a STL – Standard Template Library, que garantem
uma execução mais veloz e um tamanho menor ao programa. O Notepad++, através
de sua consciência ambiental, busca reduzir o consumo de energia por meio de
otimização de rotinas sempre que possível para se utilizar menos da capacidade do
CPU.
25
3.2 Google Chrome
A aplicação foi desenvolvida para o navegador Google Chrome (Copyright ©
2006-2011) devido à facilidade no desenvolvimento e instalação de suas extensões
bem como pela clareza da documentação disponível. Além disso, algumas
estatísticas mostram que a utilização deste navegador tem subido. Enquanto a
Netmarketshare apresenta um crescimento de 7,03% do Google Chrome no
mercado de Janeiro a Novembro de 2011, no cenário internacional, a empresa
StatCounter (Figura 1) apresenta algumas estatísticas que mostram que o browser
do Google atingiu 39,81% de participação no mercado brasileiro
(NETMARKETSHARE, 2011).
Figura 1 – Gráfico da StatCounter mostra que navegador Chrome ultrapassou o IE
em novembro de 2011
Fonte: http://g1.globo.com/tecnologia/noticia/2011/12/chrome-passa-ie-e-se-torna-browser-
mais-popular-do-brasil-diz-pesquisa.html (2011).
26
O código fonte do Google Chrome está disponível gratuitamente conforme os
acordos de licença de software de código aberto BSD. Durante o desenvolvimento
da extensão foi utilizada a versão 16.0.912.63 do navegador Google Chrome.
3.3 Scrumy
Durante o processo de planejamento e desenvolvimento do projeto foi
utilizada a ferramenta on-line Scrumy (Copyright © 2012) para facilitar a visualização
dos prazos estabelecidos no cronograma. O Scrumy é um projeto baseado na
metodologia ágil de desenvolvimento de software Scrum, que visa substituir os
quadros com etiquetas adesivas utilizados por equipes Scrum. Foi utilizada a versão
original do Scrumy que pode ser utilizada gratuitamente (Figura 2), mas também é
possível optar pelo pagamento de uma pequena taxa para que sejam acrescentadas
outras funcionalidades.
Figura 2 – Tela da versão gratuita do Scrumy feita para melhor visualização do
cronograma do projeto.
Fonte: http://scrumy.com/commas54cornets (2011).
27
3.4 HTML Parser
O programa proposto foi desenvolvido a partir do parser de código HTML
produzido por John Resig e escrito em JavaScript. Este por sua vez é uma
adaptação de outro parser do mesmo tipo produzido por Erik Arvidsson (Copyright ©
2004 Erik Arvidsson), cuja utilização é regida pela licença pública da Mozilla (Mozilla
Public License). Segundo Resig, o programa de Arvidsson era simples e não
contemplava a lógica complicada do HTML (Resig, 2011). Apesar da adaptação feita
por Resig não conseguir cobrir todas as aberrações possíveis de um código HTML,
ela certamente consegue cobrir as mais óbvias, como:
a) Elementos sem correspondente de fechamento:
Exemplo: HTMLtoXML("<p><b>Hello") == '<p><b>Hello</b></p>'
b) Elementos vazios:
HTMLtoXML("<img src=test.jpg>") == '<img src="test.jpg"/>'
c) Elementos de bloco vs. elementos inline:
HTMLtoXML("<b>Hello <p>John") == '<b>Hello </b><p>John</p>'
d) Elementos fechados por si mesmos:
HTMLtoXML("<p>Hello<p>World") == '<p>Hello</p><p>World</p>'
e) Atributos sem valores:
HTMLtoXML("<input disabled>") == '<input disabled="disabled"/>'
O algoritmo de Resig analisa a sintaxe de um documento HTML de forma
ascendente e procura corrigir as anomalias citadas anteriormente. O programa
proposto neste trabalho analisa cada token à medida que este é processado a partir
da cadeia de entrada, verificando a existência de formações não recomendadas pelo
Modelo de Acessibilidade de Governo Eletrônico.
28
4 DESENVOLVIMENTO DA EXTENSÃO
Esta seção apresenta o processo de desenvolvimento da extensão. São
descritas a adaptação feita no analisador sintático, componentes da arquitetura da
extensão e detalhes do seu funcionamento.
4.1 Adaptação do HTML Parser
O HTML Parser feito por Resig basicamente recebe uma cadeia de código
HTML e um objeto handler no formato:
handler = {
start: function(tag, attrs, unary) { },
end: function(tag) { },
chars: function(text) { },
comment: function(text) { }
}
A função HTMLParser percorre a cadeia de código HTML como em uma pilha.
Quando uma sequência de caracteres no topo da pilha é reconhecida pela função
como um comentário, uma etiqueta de abertura ou uma etiqueta de fechamento,
essa sequência é retirada da pilha e remontada no objeto handler. Neste momento,
é verificada se a etiqueta faz parte do conjunto de elementos vazios, elementos de
bloco, elementos inline ou de elementos parecidos com seus correspondentes de
fechamento. Também é verificado se existem atributos sem valor nas etiquetas e se
29
elementos de bloco não foram fechados adequadamente para que cada elemento
seja remontado de forma adequada pelo handler.
Para a criação do validador de acessibilidade foi necessário identificar as
situações em que a cadeia recebida pela função HTMLParser não se encontrava de
acordo às normas de acessibilidade especificadas no e-MAG. Por isso foram criadas
novas estruturas de dados e funções no corpo da função principal do HTML Parser
de Resig, entre elas:
a) Array de mensagens: para armazenar detalhes dos erros encontrados na
cadeia de código HTML e detalhes sobre as mensagens emitidas como
alertas;
b) Flag arrays: foram utilizados arrays para substituir as diversas variáveis
que se fizeram necessárias na sinalização da ocorrência ou ausência de
determinados elementos na cadeia;
c) Função parseStartTag: já existente no algoritmo de Resig, foi adaptada
para detectar erros a medida que cada etiqueta de abertura fosse
processada pela função;
d) Função mensDetail: construída para inicialização do array de mensagens
com o tipo de mensagem (se erro ou alerta), quantidade de ocorrências no
código, descrição da mensagem e linhas onde ocorreram;
e) Função errorRow: para identificar a linha onde um erro foi interceptado;
f) Função errorWithoutRow: para erros detectados em uma região do código
e não necessariamente em uma linha;
g) Função detectaErroAttr: para identificar erros causados pela existência
imprópria ou ausência de atributos e/ou valores de atributos segundo o e-
MAG v3.0.
30
h) Função detectaErroElem: para identificar erros causados pela existência
imprópria ou ausência de elementos segundo o e-MAG v3.0.
Além dessas modificações, o elemento handler utilizado pelo validador de
acessibilidade foi modificado para reconhecer também o elemento Doctype, antes
não reconhecido pelo analisador sintático.
4.2 Arquitetura da extensão
A extensão proposta foi desenvolvida como um browser action, isso significa
que quando instalada seu ícone fará parte da barra de tarefas principal do
navegador. Como só se faz necessária sua execução quando o usuário desejar
avaliar uma página, a extensão foi desenvolvida para funcionar apenas quando o
usuário clicar no ícone correspondente. Ao clicar no ícone da extensão, é aberta
uma popup que carrega a página popup.html a qual se comunica com o script
htmlparser.js que faz a análise do código fonte da página aberta (Figura 3).
Figura 3.1 – Arquitetura da extensão desenvolvida para o navegador Google
Chrome.
31
Em termos gerais, quando ativada, a extensão solicita a URL da página
aberta ao navegador Google Chrome através de uma API especifica, depois envia
uma requisição AJAX ao servidor da página aberta contendo a URL recebida. Se a
comunicação for bem sucedida, a resposta do servidor é o código fonte da página.
Depois de recebido o código fonte é usado como parâmetro da função ValidaHTML
que utiliza o htmlparser. Depois do htmlparser analisar a cadeia de entrada ele
retorna uma lista contendo erros e/ou mensagens quanto à acessibilidade da página
(Figura 3.2).
Figura 3.2 – Diagrama de sequência do processo de validação da página aberta.
4.2.1 Arquivo Manifest
O arquivo manifest.json é padrão para qualquer extensão, aplicativo ou tema
desenvolvido para o navegador Google Chrome. Esse arquivo fornece informações
32
sobre a extensão, como seus arquivos mais importantes e as permissões da
extensão. No caso da extensão desenvolvida, ela só pode ter acesso ao código
fonte da página aberta se em seu arquivo manifest for acrescentada a permissão
para tal:
"permissions": [
"http://*/",
"https://*/",
"tabs"
]
Adicionando as expressões regulares “http://*/” e “https://*/”, a extensão passa
a ter permissão para acessar itens cujas URLs atendam essa sintaxe. E adicionando
“tabs” à lista de permissões é possível manipular abas no navegador.
4.2.2 Popup
Se um browser action possue uma popup, ela aparecerá quando o usuário
clicar no ícone da extensão. Para adicionar uma popup à extensão é necessário
especificar o arquivo HTML no campo default_popup do arquivo manifest da
extensão.
Quando a aplicação é ativada a página popup.html é aberta. Nesta página é
capturada a URL da aba ativa no navegador, por meio das APIs exclusivas do
Chrome, que é utilizada para capturar o código fonte da mesma aba através de uma
requisição AJAX. Esse código fonte é analisado pelo parser e os erros são exibidos
posteriormente na mesma página.
33
4.2.2.1 Chrome-only APIs
Extensões desenvolvidas para o navegador Web Google Chrome podem usar
APIs dedicadas chamadas Chrome-only APIs (ou chrome.* APIs) que permitem uma
integração mais rente entre a extensão e o navegador. Por exemplo, qualquer
extensão ou aplicativo Web pode usar o método padrão window.open( ) para abrir
uma URL. Mas se for necessário especificar qual janela deverá exibir esta URL, a
extensão deverá utilizar o método chrome.tabs.create( ), exclusivo do Chrome.
Para capturar a URL da aba ativa no navegador, é usado o método exclusivo
do Chrome: chrome.tabs.getSelected( ). Esse método recebe um objeto relacionado
à aba que tem, entre outras propriedades, o valor da sua URL.
4.2.2.2 XMLHttpRequest
O XMLHttpRequest é o objeto responsável pelo funcionamento do AJAX.
Segundo Silva (2009), pode-se traduzir XMLHttpRequest como requisição XML com
o uso do protocolo HTTP para transferência de arquivos. Na janela popup.html, logo
após o objeto XMLHttpRequest ser instanciado, é utilizado o método open desse
objeto para informar ao servidor o endereço do arquivo que está sendo requisitado,
nesse caso, a URL da aba vigente.
O objeto XMLHttpRequest possui também a propriedade readyState que
retorna um valor numérico indicativo do status da comunicação. Sempre que esta
propriedade sofre alguma mudança a ação onreadystatechange é disparada. Logo,
na popup.html podem aparecer três respostas diferentes:
a) Análise da página: há sucesso na requisição e a página pode ser avaliada;
34
b) Não foi possível capturar o código fonte da página: a requisição ocorre,
mas não retorna o código fonte da página;
c) Não foi possível realizar a análise: há falha na requisição.
4.2.2.2.1 Quando é possível analisar a página
Quando a propriedade readyState do XMLHttpRequest assume o valor 4
significa que o servidor acabou de enviar a resposta à requisição. Quando isso
ocorre os dados da resposta se encontram armazenados na propriedade
responseText do XMLHttpRequest em formato de string, que nesse caso é o código
HTML da página na aba ativa do navegador. Essa string é usada como parâmetro
na função HTMLParser e o resultado é exibido na página popup.html (Figura 4).
4.2.2.2.2 Quando não é possível capturar o código fonte da página
Caso a propriedade responseText contenha uma string vazia, ou seja, sem o
código fonte da página requisitada, não é possível avaliar a página. Logo, uma
mensagem de que não foi possível capturar o código fonte aparece na popup.html
(Figura 5).
35
Figura 4 – Resultado da análise do código fonte da página aberta no navegador.
Figura 5 – Mensagem exibida quando código fonte não é capturado pelo programa.
36
4.2.2.2.3 Quando não é possível realizar a análise
Caso a propriedade readyState do XMLHttpRequest não assuma o valor 4,
significa que o servidor não conseguiu realizar a requisição. Ocorrem várias
tentativas de completar a requisição, por isso na aplicação é determinado um tempo
de 3000 milissegundos para que se tente completar a requisição. Nesse caso outra
tela é exibida indicando a impossibilidade em realizar a análise da página (Figura 6).
Figura 6 – Mensagem indicando que não foi possível realizar a análise da página.
37
4.3 Como utilizar a extensão
As extensões do navegador Chrome são geralmente de fácil instalação e,
como costumam ter uma interface minimalista, são de fácil utilização também.
Depois de prontas as extensões produzidas para o navegador Google Chrome
podem ser compactadas em um arquivo de extensão .crx. Ao abrir esse arquivo no
navegador inicia-se a instalação da extensão (Figura 7).
Figura 7 – Extensão sendo instalada no navegador Google Chrome.
4.3.1 Executando o programa
Para iniciar a análise de uma página basta-se clicar no ícone referente à
extensão no navegador.
38
A popup aberta inicia a análise da página automaticamente (como discutido
na Seção 4.2.2). Logo depois aparecerá o resultado, que pode ser o sucesso da
análise apresentando a relação de erros e alertas ou a informação de que não foram
encontrados erros no código fonte ou, ainda, a impossibilidade de realizar a análise.
4.3.2 Identificação de erros
Como já foi discutido na Seção 2.3.1, o e-MAG em sua versão 3.0 aboliu a
divisão das suas recomendações de acessibilidade em níveis de prioridade, pois o
padrão é voltado às páginas do Governo, não sendo permitidas então exceções com
relação ao cumprimento das recomendações. Logo, a divisão entre erros e alertas
não diz respeito ao grau de relevância das recomendações do e-MAG, mas em
como essas recomendações podem ser identificadas na página.
Todas as recomendações que dependem da avaliação manual do usuário da
extensão são emitidas como alertas. Já todas as recomendações que podem ser
verificadas apenas a partir da análise automática do código fonte são classificadas
como erros. Por exemplo, todas as imagens no código HTML, segundo as
especificações do e-MAG, precisam ter uma descrição através do atributo alt. A
ausência ou ocorrência deste atributo nos elementos imagem pode ser facilmente
detectada no código fonte, logo essa recomendação é classificada como um erro na
abordagem utilizada.
39
4.3.3 Emissão de alertas
Apesar dos alertas serem, no programa todas as recomendações que não
são detectáveis automaticamente, sua emissão nem sempre ocorre. Das 54
(cinqüenta e quatro) mensagens exibidas, 32 (trinta e duas) são emitidas como
alertas e delas só 15 (quinze) sempre são exibidas independente da página
avaliada. Os outros alertas dependem da ocorrência de outros elementos para
serem exibidos na tela.
Por exemplo, a recomendação nº 42 do e-MAG pede que sejam fornecidas
instruções para entrada de dados em campos de formulário. Esse tipo de
recomendação depende de quem está escrevendo o código fonte, pois não existe
um elemento HTML dedicado a fornecer dicas de preenchimento em formulários e
que possa ser identificado pelo programa, logo essa recomendação é exibida como
um alerta. No entanto, essa recomendação só se aplica a uma página se houver
qualquer elemento de formulário nela, portanto quando um elemento de formulário é
encontrado na página esse alerta será exibido.
4.3.4 Elementos da página de exibição dos resultados
A página de exibição dos resultados é a tela principal do programa e é
composta pelos seguintes elementos:
a) Menu com as quantidades de erros e alertas: composto por âncoras de
atalho direto para a lista de erros e para a lista de alertas;
b) Box principal: apresenta mensagens sobre o status do processo de
análise;
40
c) Lista de erros: descrição dos erros detectados na página;
d) Lista de alertas: descrição das recomendações que podem se aplicar à
página;
4.3.4.1 Menu com as quantidades de erros e alertas
Além da quantidade de alertas e da quantidade de erros detectados na
análise da página, o menu também serve como atalho para avançar direto às listas
de erros e tarefas (Figura 8).
Figura 8 – Em destaque, menu de skip links mostra quantidade de erros e alertas.
41
4.3.4.2 Box principal
São cinco as possíveis mensagens que podem aparecer nessa área:
a) A mensagem de que não foi possível capturar o código fonte da página;
b) A mensagem de que não foi possível realizar a análise da página;
c) A mensagem sobre a quantidade de erros e sobre a importância de
observar os alertas emitidos, ou;
d) A mensagem sobre a não existência de erros e sobre a importância de
observar os alertas emitidos.
4.3.4.3 Lista de erros e lista de alertas
A relação de erros contém uma descrição sintética do erro e a recomendação
do e-MAG em que o erro se aplica. Da mesma forma, a relação dos alertas contém
uma descrição sintética do alerta e a recomendação do e-MAG em que este se
aplica (Figura 9).
4.3.5 Demais telas
As outras telas do programa são simples, pois o foco da extensão é a
avaliação de páginas Web a partir das especificações do e-MAG. A ferramenta traz
uma área para referências sobre o e-MAG, uma área com referências a tutoriais e
outras ferramentas de avaliação de acessibilidade e uma área de ajuda quanto à
utilização do programa.
42
(a) (b)
Figura 9 – Relação de erros encontrados (a) e relação de alertas emitidos (b) de
acordo às recomendações do e-MAG v3.0.
4.3.5.1 Sobre o e-MAG
Nesta tela há uma breve descrição sobre o Modelo de Acessibilidade de
Governo Eletrônico, e links para o download da versão 3.0 do e-MAG e para o site
do Departamento de Governo Eletrônico (Figura 10).
4.3.5.2 Tutoriais
Nesta tela há links para tutoriais disponibilizados pelo Departamento de
Governo Eletrônico e uma relação de outros softwares para avaliação e validação de
acessibilidade de páginas Web (Figura 11).
43
Figura 10 – Tela contendo links e descrição do e-MAG.
Figura 11 – Tela contendo links para tutoriais e outras ferramentas.
44
4.3.5.3 Ajuda
Nesta tela constam informações sobre a extensão e sobre sua utilização
(Figura 12).
Figura 12 – Tela de ajuda quanto à utilização da extensão.
45
5 RESULTADOS E DISCUSSÃO
Por não ser uma ferramenta oficial, como o ASES e o daSilva, uma página
não pode receber um selo atestando seu nível de acessibilidade apenas sendo
avaliada pela extensão. Por isso, quando nenhum erro é encontrado pelo programa,
uma mensagem é exibida indicando que o usuário ainda deve submeter seu código
à análise pelo daSilva. Logo, a extensão já pode ser usada como uma análise rápida
de acessibilidade e é por isso que foi nomeada como eScanner.
5.1 Comparação com outros validadores automáticos
Como já foi citado, os dois softwares que avaliam páginas Web segundo o
Modelo de Acessibilidade de Governo Eletrônico, o ASES e o daSilva, se baseiam
na versão 2.0 do e-MAG. A versão 3.0 do e-MAG foi lançada muito recentemente,
mas o eScanner já foi desenvolvido utilizando essa versão como base. Ao comparar
os resultados da análise feita pelo eScanner com os resultados do daSilva, por
exemplo, percebe-se que todos os erros encontrados na extensão são listados
também pelo daSilva, mas este último costuma identificar mais alguns erros e alertas
especificados apenas na versão 2.0. O daSilva apresenta o número da
recomendação do e-MAG que respalda o erro ou alerta emitido, sua descrição, a
quantidade de ocorrências e as linhas onde ocorrem, tudo isso em uma estrutura
tabular, como mostrado na Figura 13. Já os resultados emitidos pelo eScanner são
mais condensados permitindo uma visualização mais rápida.
46
Figura 13 – Comparação entre resultados da avaliação do sítio da Universidade
Estadual de Santa Cruz pelo daSilva e pelo eScanner.
A Figura 13 mostra a comparação dos componentes da tela de visualização
de erros e alertas nas duas ferramentas e não da semelhança dos resultados, pois a
ordem em que os erros são listados no eScanner não é semelhante à ordem em que
aparecem no daSilva.
Existem ainda outras extensões que se propõem a avaliar a acessibilidade de
páginas Web, mas estas se baseiam no WCAG. A maioria dessas extensões apenas
envia a URL ou o código fonte da página atual via método GET para a ferramenta
online da W3C. Uma vantagem do eScanner em relação a essas ferramentas é a
disponibilidade, pois ferramentas online podem estar indisponíveis devido a uma
queda no servidor, por exemplo.
47
6 CONCLUSÃO E TRABALHOS FUTUROS
As ferramentas de avaliação e validação de acessibilidade são muito
importantes para garantir o cumprimento das diretrizes de acessibilidade, pois
ajudam a identificar problemas no código fonte de forma automática e a maioria
delas apresenta seus resultados de forma tão detalhada que não se faz necessário
conhecer a fundo as diretrizes em que se baseiam para entender as correções
solicitadas. No entanto é fundamental a avaliação manual por parte dos
programadores e por usuários diversos com diferentes capacidades para garantir
que uma página Web seja de fato acessível. Por isso a extensão construída dedica
um espaço para a promoção do e-MAG, de tutoriais e outras ferramentas
relacionadas à acessibilidade, para facilitar o acesso dos seus usuários a esse
material a fim de que conheçam o modelo de acessibilidade nacional.
A ferramenta construída caracteriza-se como uma extensão para o navegador
Google Chrome apta a analisar de forma rápida o código fonte de uma página Web,
escrita em HTML 4 ou XHTML, apresentando erros e alertas de acordo
recomendações de acessibilidade do e-MAG em sua terceira versão. Essa extensão
deverá ser disponibilizada gratuitamente através do portal Web Chrome Store, que
concentra diversas aplicações e extensões desenvolvidas para o navegador da
Google. Também deverão ser acrescentadas à extensão funcionalidades tais como
visualização do código fonte e informações sobre o nível de acessibilidade
alcançado pela página. Pretende-se ainda encaminhar a ferramenta ao
Departamento de Governo Eletrônico para sua apreciação.
48
7 REFERÊNCIAS
AHO, A. V.; SETHI, R.; ULLMAN, J. D. Compiladores: princípios, técnicas e ferramentas. Tradução: Daniel de Ariosto Pinto. Rio de Janeiro: LTC, 1995.
BRASIL. Decreto Legislativo nº 186, de 9 julho de 2008. Brasília, DF, 10 jul. 2008. Diário Oficial da União, Seção 1, Edição 131, p. 1.
BRASIL. Decreto nº 5296, de 2 de dezembro de 2004. Brasília, DF, 03 dez. 2004. Diário Oficial da União, Seção 1, p. 5, capítulo III, artigo 80.
BRASIL. e-MAG Modelo de Acessibilidade em Governo Eletrônico. Brasília, 2011. Disponível em: <http://www.governoeletronico.gov.br/biblioteca/arquivos/e-mag-3.0/download>. Acesso em: 1 jan. 2012
BRASIL. Lei nº 8.213, de 24 de Julho de 1991. Brasília, DF, 07 jul. 1991. Diário Oficial da União.
BRASIL. Projeto de Decreto Legislativo n° 563, de 2008: Convenção da ONU sobre os direitos da pessoa com deficiência. Brasília, DF, 28 mai. 2008. Disponível em: <http://www.swbrasil.org.br/uploads/download/f2433247cb5c50d8a43 8bf59c783db9a582f3518.pdf>. Acesso em: 2 jan. 2012.
FERREIRA, S. B. L.; NUNES, R. R. e-Usabilidade. Rio de Janeiro: LTC, 2008.
IBGE. Censo Demográfico 2000. Disponível em: <http://www.ibge.gov.br/home/estatistica/populacao/censo2000/populacao/ deficiencia_Censo2000.pdf>. Acesso em: 2 jan. 2012.
NETMARKETSHARE. Disponível em: <http://www.netmarketshare.com/browser-market-share.aspx?qprid=1&qpcustomb=0>. Acesso em: 31 dez. 2011.
NICÁCIO, J. M. Técnicas de acessibilidade: criando uma Web para todos. Maceió: EDUFAL, 2010.
49
NIELSEN, J.; LORANGER, H. Usabilidade na web: projetando websites com qualidade. Tradução: Edson Furmankiewicz e Carlos Schafranski. Rio de Janeiro: Elsevier, 2007.
NOTEPAD++. Disponível em: <http://notepad-plus-plus.org/>. Acesso em: 31 dez. 2011.
PRICE, A. M. A.; TOSCANI, S. S. Implementação de linguagens de programação: compiladores. Porto Alegre: Editora Sagra Luzzato, 2005.
QUEIROZ, M. A. Acessibilidade web: tudo tem sua primeira vez. Disponível em: <http://www.bengalalegal.com/capitulomaq.php>. Acesso em: 2 jan. 2012.
RESIG, J. Pure JavaScript HTML Parser. Disponível em: <http://ejohn.org/blog/pure-javascript-html-parser/>. Acesso em: 31 dez. 2011.
SILVA, M. S. Ajax com jQuery: requisições AJAX com a simplicidade de jQuery. São Paulo: Novatec Editora, 2009.
W3C. World Wide Web Consortium. Disponível em: <http://www.w3.org/>. Acesso em: 2 jan. 2012.