AVALIANDO E PROPONDO AMPLIAÇÃO DE ACESSIBILIDADE EM SISTEMA WEB

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS DOUGLAS SEVERO SILVEIRA AVALIANDO E PROPONDO AMPLIAÇÃO DE ACESSIBILIDADE EM SISTEMA WEB Trabalho de Conclusão apresentado como requisito parcial para a obtenção do grau de Tecnólogo em Análise e Desenvolvimento de Sistemas Prof. Msc. Luciano Vargas Gonçalves Orientador Prof. Msc. Carlos Alberto Barros Cruz Westhead Madsen Co-orientador Rio Grande, janeiro de 2014

2 CIP CATALOGAÇÃO NA PUBLICAÇÃO Severo Silveira, Douglas AVALIANDO E PROPONDO AMPLIAÇÃO DE ACESSI- BILIDADE EM SISTEMA WEB / Douglas Severo Silveira. Rio Grande: TADS/FURG, f.: il. Trabalho de Conclusão de Curso (tecnólogo) Universidade Federal do Rio Grande. Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas, Rio Grande, BR RS, Orientador: Luciano Vargas Gonçalves; Co-orientador: Carlos Alberto Barros Cruz Westhead Madsen. 1. Acessibilidade, Sistema, Web, Inclusão. I. Vargas Gonçalves, Luciano. II. Alberto Barros Cruz Westhead Madsen, Carlos. III. Título. UNIVERSIDADE FEDERAL DO RIO GRANDE Reitora: Prof a. Cleuza Maria Sobral Dias Pró-Reitora de Graduação: Denise Maria Varella Martinez Coordenador do curso: Prof. Dr. Tiago Lopes Telecken

3 7 SUMÁRIO 1 AGRADECIMENTOS LISTA DE ABREVIATURAS E SIGLAS LISTA DE FIGURAS LISTA DE TABELAS RESUMO INTRODUÇÃO REVISÃO BIBLIOGRÁFICA Padrão W3C Usabilidade em Interfaces na Web Interoperabilidade na Web Acessibilidade na Web Tecnologia Assistiva O Framework CASCA e o Sistema Acadêmico da FURG Legislação Sobre Conteúdo Acessível Deficientes Visuais e a Internet Avaliação de Grau de Acessibilidade de Sistema Web METODOLOGIA Estrutura do Sistema da FURG Avaliação de Acessibilidade Validação Automática Checklist Teste Simulado Teste com um Usuário Real Avaliação de Acessibilidade das Interfaces Atuais Ambiente de Testes do Sistema Atual Validação Automática Checklist Testes Simulados Teste com um Usuário Real Diretrizes para Proposta de Interface Diretrizes Estruturais Diretrizes Visuais

4 8 5 DESENVOLVIMENTO DA PROPOSTA DE INTERFACE Proposta de Layout Material Utilizado Proposta de Interface Características Estruturais Interface de Login Interface Inicial e Estrutura do CASCA Interface de Informações Acadêmicas RESULTADOS Avaliação de Acessibilidade das Interfaces Propostas Ambiente de Testes da Proposta Validação Automática Checklist Testes Simulados Teste com um Usuário Real DISCUSSÃO DOS RESULTADOS CONCLUSÃO Desempenho Expectativas Futuras Considerações Finais REFERÊNCIAS GLOSSÁRIO APÊNDICE A Avaliação de Acessibilidade - Questionário

5 9 LISTA DE ABREVIATURAS E SIGLAS ARGO Sistema de Administração de Bibliotecas CAPTCHA. Completely Automated Public Turing CSS Cascading Style Sheets E-MAG Modelo de Acessibilidade de Governo Eletrônico HTML NTI PNEE PHP SIA WAI HyperText Markup Language Núcleo de Tecnologia da Informação Pessoa com Necessidades Especiais Específicas PHP: Hypertext Preprocessor Sistema Acadêmico Web Acessibility Inititive WCAG Web Content Accessibility Guidelines Web@x Web Accessibility at Examinator W3C World Wide Web Consortium XHTML Extensible Hipertext Markup Language XML Extensible Markup Language

6 11 LISTA DE FIGURAS Figura 3.1: Ilustração de fluxo de comunicação entre Navegador Web e Sistemas FURG Figura 4.1: Gráfico de Gantt Cronograma realizado Figura 4.2: Interface de login do sistema atual Figura 4.3: Interface inicial do sistema atual Figura 4.4: Ilustração com divisão da interface em frames Figura 4.5: Interface de informações acadêmicas do sistema atual Figura 4.6: Destaque menu horizontal de interface do sistema atual Figura 4.7: Caso de uso da proposta de interface Figura 5.1: Projeto de interface Figura 5.2: Projeto de interface com alto contraste Figura 5.3: Exemplo de cógido HTML para iframe Figura 5.4: Exemplo de código HTML associação campo de inserção com label. 43 Figura 5.5: Trecho de código que atua sob recurso CAPTCHA Figura 5.6: Interface de login proposta Figura 5.7: Proposta de interface inicial Figura 5.8: Destaque de barra de acessibilidade Figura 5.9: Função JavaScript que altera o contraste da página Figura 5.10: Configuração CSS para alteração de layout de contraste Figura 5.11: Proposta de interface inicial com alto contraste Figura 5.12: Função JavaScript que altera tamanho de fonte Figura 5.13: Alteração em tamanho de fonte de informações importantes Figura 5.14: Função JavaScript de busca nos sistemas Figura 5.15: Função JavaScript de atalho de teclado para mover o foco ao frame de conteúdo Figura 5.16: Função JavaScript com evento de teclado Figura 5.17: Destaque de funcionalidade Breadcrumbs Figura 5.18: Destaque de ressalte do submenu sob o ponteiro do mouse e código CSS correspondente Figura 5.19: Proposta de interface de informações acadêmicas com alto contraste. 51 Figura 5.20: Trecho de código com associação de informação de linha com coluna 52 Figura 7.1: Gráfico de índice de acessibilidade entre interfaces atuais e propostas 58

7 13 LISTA DE TABELAS Tabela 4.1: Tabela comparativa entre pontos importantes de validadores automáticos 34

8 15 RESUMO O presente trabalho tem como objetivo promover maior grau de acessibilidade no Sistema Acadêmico (SIA) da Universidade Federal do Rio Grande (FURG). Essa instituição disponibiliza aos seus alunos informações de sua vida acadêmica através de um sistema Web. Todavia, este sistema possui baixo grau de acessibilidade, podendo ser inviável que Pessoas com Necessidades Especiais Específicas (PNEE s) o acessem sem o auxílio de terceiros. Visando superar essa limitação, buscou-se, através da utilização de técnicas HTML (HyperText Markup Language), CSS (Cascading Style Sheets), JavaScript e PHP, deixar as interfaces utilizadas pelos alunos em conformidade com padrões da World Wide Web Consortium (W3C) e legislação brasileira, aumentando, assim, seu grau de acessibilidade. A coleta de dados foi realizada no início e ao final do projeto através de validação automática, checklist da Web Content Accessibility Guidelines (WCAG), testes com especialistas simulando usuários com deficiências e aplicação de questionário em PNEE s. Como resultado do estudo, são apresentadas, através de análise desses dados, melhorias significativas quanto a acessibilidade para novas interfaces do sistema. Palavras-chave: Acessibilidade, Sistema, Web, Inclusão.

9 17 2 INTRODUÇÃO Na década de noventa a organização World Wide Web Consortium (W3C) direcionou a produção de conteúdo e de sistemas relacionados à Internet ao regulamentar estruturas, linguagens e metodologias a serem utilizados na Web. Porém, essas convenções estipuladas a cerca da estrutura dos documentos não garantem que a produção deles seja padronizada. Por conta disso, surge a preocupação com os resultados apresentados no que diz respeito a sua usabilidade e acessibilidade. É imprescindível observar que uma fatia significativa da população que tem a intenção de consumir materiais que estão na Web, possui algum tipo de deficiência, o que significa perda ou limitação de oportunidades de participar da vida comunitária em condições de igualdade com as demais pessoas. Quando conteúdos, principalmente os educativos, possuem alto grau de acessibilidade, trazem um benefício enorme à pessoas com deficiências. Para Kane (KANE et al., 2007), páginas Web inacessíveis podem promover um educational divide no qual pessoas com algum tipo de deficiência são alijadas do acesso à educação e consequentemente a outros aspectos da vida em sociedade. Esses mesmos autores mostraram que a acessibilidade ainda é um problema para a maioria das 100 melhores universidades do mundo. A adoção da acessibilidade na confecção das páginas e aplicações para Internet não se caracteriza como limitação, ao contrário, as regras de acessibilidade tornam os documentos mais flexíveis, abrangentes, rápidos e fáceis de utilizar (GODINHO, 1999). A tecnologia da informática disponibiliza vários recursos que contribuem para que pessoas com deficiência tenham melhores condições de acesso à educação - a chamada tecnologia assistiva a que proporciona uma melhora na qualidade de vida, tanto com o crescimento intelectual, quanto pessoal e profissional. Muitos softwares de tecnologia assistiva são desenvolvidos visando possibilitar o consumo do conteúdo existente na Internet, como leitores de tela para pessoas com deficiência visual. Os leitores de tela são softwares usados para obter resposta do computador por meio sonoro, através de sintetizadores de voz, usado principalmente por deficientes visuais. Porém, não é qualquer tipo de conteúdo que esses softwares estão preparados para interpretar. Páginas que não possuem um código de acordo com os padrões do World Wide Web Consortium (W3C) apresentam comportamento imprevisível, e na maioria das vezes impedem ou pelo menos dificultam o acesso às pessoas com algum tipo de deficiência, em especial visual (BORGES; RODRIGUES; SOUZA FILHO, 2006). Esses mesmos autores apontam que os deficientes visuais no Brasil são em sua maioria pessoas semi-analfabetas ou possuem somente a educação básica, com extrema dificuldade de acesso a educação. Um deficiente visual, ao usar a Internet, costuma enfrentar algumas dificuldades na obtenção de informações apresentadas em formato visual, com funcionalidades desenvol-

10 18 vidas para serem acessadas por meios diferentes do teclado, em distinguir links e, também, para compreender a estrutura de um documento. Neste contexto, as tecnologias assistivas aliadas ao conteúdo educacional acessível disponível na Web são de extrema importância no crescimento pessoal e intelectual dos deficientes visuais. O Brasil possui regulamentação que exige a adoção de regras de acessibilidade na concepção da informação disponibilizada na Internet pela administração pública, expressada na cartilha e-mag. Publicada em janeiro de 2005, atualmente na versão 3.0, disponibilizada em agosto de 2011, essa cartilha segundo o Ministério do Planejamento, Orçamento e Gestão através da Secretaria de Logística e Tecnologia da informação, é um conjunto de recomendações a ser considerado para que o processo de acessibilidade dos websites e portais do governo brasileiro seja conduzido de forma padronizada e de fácil implementação (E-MAG MODELO DE ACESSIBILIDADE DE GOVERNO ELETRÔNICO, 2011). Para tornar efetiva a observação da e-mag, o governo brasileiro promulgou o decreto número 7.724, de 16 de maio de 2012 que regulamenta no âmbito do Poder Executivo Federal, conforme o disposto na Lei n o , de 18 de novembro de que dispõe sobre o acesso a informações - os procedimentos para a garantia do acesso à informação e para a classificação de informações sob restrição de acesso (BRASIL, LEI N o , DE 18 DE OUTUBRO DE 2011, 2011). O foco de estudo e análise deste trabalho é o framework CASCA, da FURG, utilizado para o desenvolvimento das principais aplicações da Instituição. Esse possui estrutura para o desenvolvimento baseado em componentes, o sistema está organizado em camadas de componentes e de controle. A vantagem deste padrão de desenvolvimento é que a divisão em camadas permite organizar melhor o código da aplicação e facilita sua manutenção, uma vez que cada camada pode ser modificada individualmente (CARLI, 2008). Essa característica é facilitadora para a abordagem deste projeto, pois, grande parte dos guidelines de acessibilidade diz respeito apenas à forma de apresentação dos componentes na interface, ou seja, quase que exclusivamente à camada de apresentação do framework e suas aplicações. O projeto baseia-se na análise do grau de acessibilidade do CASCA e do sistema acadêmico da FURG (SIA). O SIA é um sistema desenvolvido através do CASCA e amplamente utilizada pela comunidade acadêmica da FURG. Atualmente, em torno de (nove mil) alunos, sendo destes, por volta de 38 (trinta e oito) com algum tipo de deficiência, que utilizam o sistema para realizar procedimentos como rematrícula ou consulta de notas de avaliações. É escopo do projeto, mais especificamente, o caminho percorrido pelo usuário desde o login no CASCA, até a interface que possui informações acadêmicas. Esse caminho possui três interfaces principais: interface de login, interface inicial, que apresenta mensagens do sistema, e interface de informações acadêmicas. Os objetivos do trabalho são avaliar o grau de acessibilidade dessas interfaces, propor alterações e adequar conforme legislação e orientações governamentais vigentes no que diz respeito à acessibilidade. Por fim, realizar comparação entre as interfaces utilizadas atualmente e as desenvolvidas no projeto. Para alcançar os objetivos se faz necessário identificar as interfaces que fazem parte do escopo do projeto e criar um ambiente de testes, realizar análise de acessibilidade dessas interfaces, pesquisar tecnologias, guidelines e legislação para implementação de interfaces amplamente acessíveis, implementar e analisar nível de acessibilidade das propostas de interface e realizar análise comparativa dos resultados. O projeto trata primeiramente da análise do sistema atual, seguido pelo projeto de

11 19 novas interfaces e, por fim, análise das propostas e comparação de resultados. Para avaliação da acessibilidade foram realizados testes, seguindo orientações de Soares (SO- ARES, 2006), de validação automática através de sistemas disponibilizados em websites, teste de verificação de cheklist recomendado pela Web Content Accessibility Guidelines (WCAG), teste de especialistas simulando usuários com deficiências e teste com usuário real. Para realização deste último tipo de teste, foi aplicado um questionário semiestruturado em uma deficiente visual congênita, aluna da FURG cursando o quarto ano de pedagogia. Para o desenvolvimento da proposta foi realizada pesquisa sobre a estrutura e funcionamento do CASCA, seguido de pesquisa de técnicas HTML (HyperText Markup Language), CSS (Cascading Style Sheets), JavaScript e PHP (PHP Hypertext Preprocessor) para implementação de uma camada de apresentação para o SIA em conformidade com padrões da World Wide Web Consortium (W3C) e legislação brasileira. A fim de que a proposta possuísse um conjunto de componentes com alto grau de acessibilidade. E, em um último momento, após avaliação de acessibilidade das interfaces propostas, realizar análise comparativa entre os dados coletados durante o projeto para comprovar que as interfaces propostas ofereceram melhorias, não só aos Pessoas com Necessidades Especiais Específicas (PNEEs), mas também aos demais, cerca de 9.000, alunos da universidade, trouxe benefícios ainda maiores aos cerca de 38 alunos com algum tipo de deficiência e possibilitou que, por exemplo, um deficiente visual, conseguisse obter suas informações acadêmicas sem o auxílio de terceiros. Como proposta para trabalhos futuros, é deixado à universidade legado de como seus sistemas podem ser adequados aos padrões de acessibilidade. Isso possibilita que, não só a aplicação SIA, como as demais aplicações utilizadas possam, através de reuso dos componentes desenvolvidos no projeto e novos desenvolvimentos baseados neste estudo, se adequarem com a legislação e proverem alto grau de acessibilidade para seus servidores e a comunidade acadêmica.

12 21 3 REVISÃO BIBLIOGRÁFICA Como embasamento deste trabalho, foram estudados os assuntos explanados nos subcapítulos seguintes. 3.1 Padrão W3C Atualmente, com a existência da rede mundial de computadores, todo material que tiver a pretensão de ser consumido por grandes massas deve, por ser um meio de amplo alcance e rápida disseminação, considerar a disponibilização dele na Web. O alcance que a grande rede possibilita ocorre por conta de diversas iniciativas que objetivaram a padronização desses conteúdos para que pudessem ser interpretados entre diversas plataformas e sistemas. Uma delas é a criação, em outubro de 2004, do World Wide Web Consortium (W3C), um consórcio de empresas de tecnologia que desenvolve padrões, como XML (extensible Markup Language), HTML (HyperText Markup Language), XHTML (extensible Hypertext Markup Language) e CSS (Cascading Style Sheets), para a criação e a interpretação dos conteúdos para a Web que teve como objetivo garantir que qualquer aplicativo desenvolvido segundo esses padrões possa ser acessado e visualizado por outro criado nos mesmos moldes. Ainda é possível citar outras iniciativas desta natureza, tanto nacionais, quanto internacionais, como algumas normas NBR ISO/IEC, padrões ANSI, padrões de protocolos e outros. A observância desses padrões, além de ser uma necessidade tecnológica, é, também, uma demanda política e social, pois pessoas conseguem se comunicar através dos sistemas que reconhecem esses padrões, muitas vezes, extrapolando fronteiras. 3.2 Usabilidade em Interfaces na Web A usabilidade visa garantir que o usuário realizará de forma mais eficiente e eficaz suas tarefas, aproveitando integralmente os recursos disponíveis. O Brasil demonstra sua preocupação com usabilidade na Web através da norma técnica ISO/IEC 25010:2011 sobre engenharia de software no modelo de qualidade do produto. Para Nielsen (NIELSEN, 1993), são cinco os componentes de qualidade da usabilidade: apreensibilidade, eficiência e simplicidade, memorização, erros e satisfação. Contudo, páginas e sistemas Web devem ter suas informações dispostas de forma a facilitar a leitura e entendimento dos usuários. Pois, caso isso não ocorra, a maioria deles provavelmente não conseguirão alcançar seus objetivos e deixarão a página ou, até mesmo os que conseguirem, não retornarão.

13 Interoperabilidade na Web A adesão de um conjunto de padrões existentes estende a possibilidade de acesso ao conteúdo disponível na Web. Esses, que já possuem importante facilidade para o usuário ao possibilitar acesso a qualquer tempo, quando de acordo com as especificações existentes passam a tratar a existência de um legado de sistemas, de plataformas de hardware e softwares instalados - geralmente fabricados por vários fornecedores. Com isso, as oportunidades de troca e reuso de informações são maximizadas, pois o conteúdo passa a ser interoperável não só entre sistemas, mas sim entre diferentes dispositivos como, por exemplo, o mesmo conteúdo podendo ser acessado por navegador Web e dispositivos móveis. Esta prática promove a inclusão nos conteúdos digitais, a importância disso vem sendo reconhecida, inclusive por governos no mundo inteiro, como, por exemplo, o governo brasileiro que vem se preocupando em prover interoperabilidade entre seus sistemas de administração desde 2003, quando passou a esforçar-se na construção do que chamou de marco brasileiro de interoperabilidade: a e-ping. Essa prática ganha ainda mais valor quando os conteúdos gerados objetivam o ensino e aprendizado. A abrangência desse tipo de conteúdo aos dispositivos móveis promove o chamado m-leaning (Educação móvel ubíqua). Reforçando a importância de dispositivos móveis para a educação, Keegan (KEE- GAND, 2002) diz que esse está se transformando em um dispositivo para aprendizagem pessoal. Oferecendo uma ampla gama de possibilidades para manter o estudante, mesmo à distância, em contato com a instituição, seus serviços, materiais e colegas de aprendizagem, tanto no ambiente de aprendizagem propriamente dito como no trabalho, ou em viagens. Proporcionando, através da inclusão digital, uma nova possibilidade além da sala de aula física e dos meios tradicionais de educação formal ao maior número de pessoas. 3.4 Acessibilidade na Web Com a exposta grande abrangência dos conteúdos disponibilizados na Web é imprescindível para nosso estudo observar que grande parte das pessoas que tem a intenção de consumir esses materiais possui algum tipo de incapacidade. Deficiência significa perda ou limitação de oportunidades de participar da vida comunitária em condições de igualdade com as demais pessoas. É possível ter uma dimensão quantitativa global através de estimativas que apontam 15% da população mundial vivem com algum tipo de deficiência, essas pessoas estão em todos os níveis da sociedade. Qualquer conteúdo que esteja disponível na Web e tenha alto grau de acessibilidade traz benefício às pessoas com deficiências, se esse conteúdo for educativo a disso importância é potencializada. Apesar do alto grau de acessibilidade em conteúdos educativos evitar a promoção de educational divide, a acessibilidade ainda não é presente na maioria das 100 melhores universidades do mundo. Caso os conteúdos educativos disponíveis na Web tivessem algo grau de acessibilidade, possibilitariam a uma parcela maior de pessoas o acesso à educação e a outros aspectos da vida em sociedade (KANE et al., 2007). Um dos motivos que fazem com que o conteúdo disponibilizado na Web atualmente não seja em grande maioria acessível é o desconhecimento por parte dos envolvidos no processo de planejamento e execução da importância e das técnicas que devem ser utilizadas. A maioria das campanhas em prol da criação de conteúdos acessíveis, é realizada pelos governos e focam apenas seus próprios serviços não ganhando força no âmbito

14 23 comercial. O desconhecimento pode ser consequência de preconceito por parte dos desenvolvedores ao imaginar que as diretrizes que tornam o conteúdo acessível possam impactar no desempenho ou limitar seus websites. Porém, não é isso que ocorre na prática, a adoção da acessibilidade na confecção das páginas e aplicações para Internet não se caracteriza como limitação, ao contrário, as regras de acessibilidade tornam os documentos mais flexíveis, abrangentes, rápidos e fáceis de utilizar (GODINHO, 1999). 3.5 Tecnologia Assistiva Hoje em dia, a tecnologia da informática disponibiliza vários recursos que contribuem para que pessoas com deficiência tenham melhores condições de acesso à educação - a chamada tecnologia assistiva a que proporciona uma melhora na qualidade de vida, tanto com o crescimento intelectual, quanto pessoal e profissional. Muitos softwares de tecnologia assistiva são desenvolvidos visando possibilitar o consumo do conteúdo existente na Internet, como leitores de tela para pessoas com deficiência visual. Leitores de tela são softwares usados para obter resposta do computador por meio sonoro, através de sintetizadores de voz, usado principalmente por deficientes visuais. Porém, não é qualquer tipo de conteúdo que esses softwares estão preparados para interpretar. Páginas que não possuem um código de acordo com os padrões do W3C apresentam comportamento imprevisível, e na maioria das vezes impedem ou pelo menos dificultam o acesso. A conformidade com esses padrões permite que qualquer sistema de acesso à informação interprete a mesma adequadamente e da mesma forma, seja por meio de navegadores, agentes de software (mecanismos de busca ou ferramentas de captura de conteúdo) ou os próprios leitores de tela (BORGES; RODRIGUES; SOUZA FILHO, 2006). 3.6 O Framework CASCA e o Sistema Acadêmico da FURG O Framework CASCA possui essa denominação por ser uma aplicação semicompleta e reutilizável utilizada para a criação de aplicações personalizadas com uma estrutura padronizada. Além da criação, este framework disponibiliza um ambiente que controla perfis, unifica o acesso e agrupa os sistemas nele desenvolvidos. Ele começou a ser desenvolvido no Núcleo de Tecnologia da Informação da Universidade Federal do Rio Grande em 2005, tendo como objetivo principal a padronização de componentes de interface dos sistemas Web da FURG e da unificação da forma e local de acesso aos softwares desenvolvido (CARLI, 2008). Entretanto, a estrutura do CASCA não foi projetada de forma para que os sistemas gerados na utilização dele possuíssem características que os provessem alto grau de acessibilidade. Atualmente o CASCA é o padrão no desenvolvimento de sistemas no NTI/FURG e com ele já foram desenvolvidos muitos sistemas, havendo, em utilização pelos servidores e comunidade acadêmica da universidade, em torno de 30 (trinta) sistemas somando cerca de 100 (cem) aplicações. Entre esses, apenas para citar alguns, estão os maduros e estáveis sistemas: Acadêmico (Sistema de Informações Acadêmicas - SIA) - que é objeto de estudo deste projeto - e o ARGO (Sistema de Administração de Bibliotecas). Para padronização em relação à forma de acesso aos sistemas gerados pelo CASCA foi estabelecido um único endereço onde o usuário se identifica e posteriormente lhe são apresentados, de acordo com seu perfil de acesso, todos os sistemas e respectivas aplicações aos quais ele tem acesso. Para viabilizar isso, este framework adota uma perspectiva mo-

15 24 dular, onde os módulos são os diferentes sistemas que o usuário pode, de acordo com seu perfil, ter acesso. Esses módulos são o conjunto de aplicações que formam tais sistemas. Assim, um perfil de aluno de graduação acessará sistemas diferentes dos acessados por um perfil de uma secretaria de biblioteca e, por sua vez, esta secretaria poderá acessar o mesmo sistema, porém, não os mesmos módulos que um perfil bibliotecário. Já para padronização da forma de desenvolvimento de novos sistemas foram criados componentes de interface, esses com o intuito de que todos os sistemas compartilhassem os mesmos elementos atribuindo comportamento igual ou similar a eles em todos os sistemas. Nessa reutilização de componentes, a centralização de código propiciou aos sistemas ter visual similar e manutenção mais rápida e confiável com códigos mais legíveis e a diminuição da necessidade de capacitação do usuário final para cada novo sistema (CARLI, 2008). Com a estrutura para desenvolvimento baseado em componentes, está organizado em camadas de componentes e controle. Nessa estrutura, a camada de controle contém a codificação lógica específica da aplicação e manipulação de dados e na camada de componentes encontra-se o código de componentes com suas características e comportamentos, assim como seu código de apresentação na interface. A vantagem deste padrão de desenvolvimento é que a divisão em camadas que permite organizar melhor o código da aplicação e facilita sua manutenção, uma vez que cada camada pode ser modificada individualmente (CARLI, 2008). Esta estrutura em camadas é facilitadora para a abordagem deste projeto, pois, grande parte dos guidelines de acessibilidade diz respeito apenas à forma de apresentação dos componentes na interface. Isso ocorre, pois os navegadores Web ao tentar acessar uma página fazem uma requisição HTTP ao servidor Web, neste caso o CASCA, que, por sua vez, faz determinado processamento e retorna um conjunto de dados XML. Quando o navegador recebe a resposta do servidor, ele o processa e disponibiliza em formato HTML e CSS à sua camada de apresentação, que configura a tela em sua forma de apresentação ao usuário, (Figura 3.1). Como possui acesso apenas aos dados finais, já processados pelo servidor e navegador, ao usuário são importantes, quase que exclusivamente, as codificações que formam a camada de apresentação do framework e suas aplicações. Figura 3.1: Ilustração de fluxo de comunicação entre Navegador Web e Sistemas FURG O projeto propõe alterações à estrutura do framework abrangendo, principalmente, seus componentes - como menus e cabeçalhos - que são utilizados nos demais sistemas

16 25 atualmente disponibilizados pela Universidade. Para obtenção dos resultados esperados, este estudo se detém a realizar análise e propostas apenas na aplicação SIA, desenvolvida através do CASCA e amplamente utilizada pela comunidade acadêmica da FURG. O escopo concentra-se, mais especificamente, no caminho a ser percorrido pelo usuário desde o login até a interface de suas informações acadêmicas. Esse caminho é composto por três interfaces principais: interface de login, onde os alunos informam seu número de matrícula e senha para acessar aos sistemas, interface inicial, que apresenta mensagens inseridas pela administração direcionadas aos usuários dos sistemas, e interface de informações acadêmicas, onde são disponibilizadas informações sobre a vida acadêmica dos alunos. Mais informações referentes ao framework CASCA podem ser encontradas em (CARLI, 2008). 3.7 Legislação Sobre Conteúdo Acessível A preocupação com a disponibilização de conteúdo acessível teve início com a W3C através da iniciativa chamada Web Acessibility Initiative (WAI), em 1999, que elaborou o primeiro documento criado para auxiliar os desenvolvedores de páginas Web que objetiva propor sugestões de como tornar o conteúdo de documentos Web acessível, o Web Content Acessibility Guidelines. O WAI, por exemplo, concentra seus esforços em três linhas: Navegadores Web, players multimídia e tecnologias assistivas. Oferece o conjunto de diretrizes User Agent Accessibility Guidelines; Ferramentas de Autoria de conteúdos Web e ambientes de desenvolvimento que produzem conteúdo Web acessível e têm interfaces acessíveis. Oferece o conjunto de diretrizes Authoring Tool Accessibility Guidelines; Conteúdo Web concebido para ser acessível. Oferece o conjunto de diretrizes Web Content Accessibility. Atualmente, existem diversas outras iniciativas visando à acessibilidade, onde destacamse, além do WAI - mais amplamente adotada - o Stanca Act Itales 1, o Section e, no contexto brasileiro, o e-mag. Ainda, diversos países como Portugal, Estados Unidos, Canadá e Austrália possuem regulamentação que exige a adoção de regras de acessibilidade na concepção da informação disponibilizada na Internet pela administração pública. No Brasil, esse tipo de regulamentação é expresso na cartilha e-mag. O e-mag é coerente com as necessidades brasileiras e em conformidade com os padrões internacionais. Foi formulado, a partir de estudo das regras de acessibilidade através de um método comparativo entre as normas adotadas por diversos países, para orientar profissionais que tenham contato com publicação de informações ou serviços na Internet a desenvolver, alterar e/ou adequar páginas, websites e portais, tornando-os acessíveis ao maior número de pessoas possível. Publicada em janeiro de 2005, atualmente na versão 3.0, disponibilizada em agosto de 2011, essa cartilha segundo o Ministério do Planejamento, Orçamento e Gestão brasileiro, através da Secretaria de Logística e Tecnologia da informação, é um conjunto 1 Legilação Italiana sobre Acessibilidade, publicado em: Guia de boas práticas para desenvolvimento Web dos Estados Unidos da América, publicado em: 2012.

17 26 de recomendações a ser considerado para que o processo de acessibilidade dos websites e portais do governo brasileiro seja conduzido de forma padronizada e de fácil implementação. Portanto, a observação dessa cartilha, torna os websites em conformidade com padrões internacionais, como a WAI, e nacionais, como as normas NBR ISO/IEC, (E-MAG MODELO DE ACESSIBILIDADE DE GOVERNO ELETRÔNICO, 2011). Para tornar efetiva a observação da e-mag, o governo brasileiro promulgou o decreto número 7.724, de 16 de maio de 2012 (BRASIL, LEI N o , DE 18 DE OU- TUBRO DE 2011, 2011) que regulamenta no âmbito do Poder Executivo Federal, conforme o disposto na Lei n o , de 18 de novembro de que dispõe sobre o acesso a informações - os procedimentos para a garantia do acesso à informação e para a classificação de informações sob-restrição de acesso. Tendo, em seu artigo oitavo, expresso que Os sítios na Internet dos órgãos e entidades deverão, em cumprimento às normas estabelecidas pelo Ministério do Planejamento, Orçamento e Gestão, atender aos seguintes requisitos, entre outros: (...) VIII - garantir a acessibilidade de conteúdo para pessoas com deficiência. (BRASIL, DECRETO N o 7.724, DE 16 DE MAIO DE 2012, 2012). Com isso, o governo torna obrigatória aos seus desenvolvedores de websites e portais a observação daquela cartilha. 3.8 Deficientes Visuais e a Internet Borges, Rodrigues e Souza Filho (BORGES; RODRIGUES; SOUZA FILHO, 2006) apontaram em 2006 que os deficientes visuais chegam a cerca de , dos quais cerca de tem acesso ao computador e a Internet. Visto que de 2006 até a atualidade o computador e a Internet foram amplamente disseminados, é possível projetar que esse número de deficientes visuais com acesso a Internet é proporcionalmente muito maior. Junto a essa informação, vale salientar que esses mesmos autores expuseram no mesmo estudo que, os deficientes visuais no Brasil são em sua maioria pessoas semianalfabetas ou possuem somente a educação básica, com extrema dificuldade de acesso a educação. Um deficiente visual, ao usar a Internet, costuma enfrentar algumas dificuldades como na obtenção de informações apresentadas em formato visual, com funcionalidades desenvolvidas para serem acessadas por meios diferentes do teclado, em distinguir links e, também, para compreender a estrutura de um documento. Neste contexto, as tecnologias assistivas aliadas ao conteúdo educacional acessível disponível na Web são de extrema importância no crescimento pessoal e intelectual dos deficientes visuais. 3.9 Avaliação de Grau de Acessibilidade de Sistema Web Para avaliação do grau de acessibilidade de um sistema na Web é necessário considerar, segundo apontamento do Grupo GUIA (GODINHO, 1999), para alguns dos problemas enfrentados pelos usuários com vários tipos de limitações, como: Acesso ao computador sem mouse: Pessoas com deficiência visual; Dificuldade de controle dos movimentos; Paralisia ou amputação de um membro superior. Acesso ao computador sem teclado:

18 27 Pessoas com amputações; Grandes limitações de movimentos; Falta de força nos membros superiores. Acesso ao computador sem monitor: Pessoas com cegueira. Acesso ao computador sem áudio: Pessoas com deficiência auditiva. Com o intuito de garantir a observância da maioria dos casos de dificuldades que podem ser apresentadas pelos conteúdos a avaliação pode ser, segundo Soares (SOARES, 2006), definida em quatro etapas: testes de validação automática através de sistemas disponibilizados em websites, de verificação de cheklist recomendado pela Web Content Accessibility Guidelines (WCAG), de especialistas simulando usuários com deficiências e demais testes que se julgue necessário.

19 29 4 METODOLOGIA O projeto tem como metodologia de trabalho as 5 (cinco) etapas seguintes: (i) estudo; (ii) especificações; (iii) implementação; (iv) testes e avaliação; e (v) documentação. Essas etapas são descritas abaixo. Na primeira etapa pesquisou-se o estado da arte em relação a acessibilidade na Web, avaliou-se o sistema atual, com foco em conhecer sua estrutura, identificar ausência de recursos de acessibilidade e visíveis recursos com baixo grau de acessibilidade. Foi definido o escopo de desenvolvimento do projeto e criado um ambiente de testes em um servidor Web com visibilidade na Internet hospedado na própria FURG, contendo as interfaces relacionadas. Ao final da etapa, realizou-se avaliações do nível de acessibilidade dessas interfaces. Já na segunda etapa, analisou-se a estrutura das interfaces presentes no escopo do projeto e de codificações internas do framework CASCA que se relacionam com essas interfaces. Foram realizadas análise nos resultados obtidos nas avaliações do nível de acessibilidade das interfaces. Elaborou-se o projeto de layout de novas telas, o qual foi baseado nos guidelines da e-mag e na legislação vigente. O próximo passo tratou do estudo de viabilidade do projeto, foram pesquisadas quais tecnologias possibilitariam seu desenvolvimento, identificou-se técnicas a serem utilizadas no desenvolvimento - como a definição do padrão de desenvolvimento e ferramentas de apoio - e foram especificadas normas e guidelines que ditariam as características que o sistema deveria possuir. A penúltima etapa foi a de testes e avaliação de acessibilidade. A proposta foi disponibilizada em um servidor Web com visibilidade na Internet hospedado na FURG e foram realizados testes, validações e avaliações de acessibilidade. Ao final da etapa, avaliou-se o nível de acessibilidade dessas interfaces propostas. Por fim, na etapa de documentação, realizou-se ajustes na codificação da proposta, análise dos resultados obtidos, documentação através do trabalho de conclusão de curso (TCC), além de produções científicas. A execução do projeto ocorreu conforme cronograma de atividades, (Figura 4.1), e foram utilizados 2 (dois) computadores com acesso à Internet, 1 (um) servidor Web com visibilidade na Internet e softwares e tecnologias livres, sem custo, como linguagens de programação PHP 5, JavaScript 1.8.5, de marcação, HTML 4 e CSS 3; software de tecnologia assistiva, leitor de tela NVDA ; e softwares verificadores de acessibilidade Examinator, Hera e dasilva.

20 30 Figura 4.1: Gráfico de Gantt Cronograma realizado 4.1 Estrutura do Sistema da FURG O Framework CASCA possui mecanismo de controle de segurança e configuração que unifica a forma de acesso à todos os seus sistemas através de uma interface de login. Essa interface é acessada através do endereço < porém, a primeira mensagem apresentada pelo navegador ao usuário é referente ao certificado de segurança não ser confiável. Não está no escopo deste projeto tratar esse comportamento do sistema e considera como interface de login o apresentado após confirmação do usuário de confiabilidade nesse certificado. A interface de login apresenta como layout uma imagem de fundo relacionada à FURG, com sua descrição e possibilidade de alteração desta. Há nela um quadro sobre quais informações devem ser inseridas nos campos, usuário e senha, assim como seus labels. Ainda, há o recurso CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart), um recurso de segurança que protege a página de ataque de robôs. Neste caso, o CAPTCHA da interface de login requere que o usuário identifique e informe os números contidos em uma imagem, que foi projetada com a intenção de que apenas humanos conseguissem resolvê-lo, (Figura 4.2). Por fim, a página apresenta um botão para efetuar o login, a informação de IP do local onde está sendo realizado o acesso, links; Como acessar? e Esqueci minha senha e informações sobre a universidade. Após a interface de login, é apresentado ao usuário a interface do sistemas do CASCA, (Figura 4.3). Essa interface é dividida em região de cabeçalho, no topo, logo abaixo a região de painel de controle, à esquerda a região de menu e ainda outra região, abrangendo o restante e maior parte da página, de conteúdo. Essa última parte é a região de cabeçalho são dinâmicas. Na região de conteúdo são apresentadas qualquer interface selecionada a partir dos submenus do menu de sistemas. A região de cabeçalho informa a qual sistema essa interface pertence. Sobre as informações mostradas aos usuários, na interface inicial é apresentada a aplicação de mensagens do sistema, que contém algumas informações sobre o último login do usuário e mensagens da administração direcionadas aos usuários dos sistemas.

21 31 Figura 4.2: Interface de login do sistema atual Figura 4.3: Interface inicial do sistema atual A estrutura lógica do CASCA utiliza de cinco frames 1, determinando as subdivisões e sua distribuição na interface. Cada uma destas subdivisões é ocupada por um arquivo diferente. Estes frames, estão dispostos da seguinte maneira: um frame no topo, compondo a região de cabeçalho da interface; abaixo, frame para o menu vertical que compõe a região de menu; abaixo da região de cabeçalho está disposto o frame central da interface, que compõe as regiões de painel de controle e de conteúdo; o quarto frame desta interface é 1 O frame é um componente HTML que permite que diferentes arquivos HTML componham a mesma página. É uma forma de manter certas informações visíveis, enquanto outras visões são rolados ou substituídas. Fonte: <

22 32 do painel de controle, que compõe a região de painel de controle e está contido no frame central; e, por último, está o frame de conteúdo, que compõe a região de conteúdo da interface e possui a maior área visível das subdivisões, (Figura 4.4). Figura 4.4: Ilustração com divisão da interface em frames A próxima interface a ser acessada é a Aluno - Informações Acadêmicas, (Figura 4.5), no submenu do menu ACADÊMICO. Essa interface, apresentada na região de conteúdo dos sistemas, possibilita ao aluno selecionar o ciclo letivo que deseja consultar, visualizar e gerar alguns documentos através de operações acessadas via botões, informações sobre aluno e curso atual e, como parte relevante para este estudo, uma tabela contendo as informações acadêmicas. Figura 4.5: Interface de informações acadêmicas do sistema atual O sistema ainda oferece ao usuário a possibilidade alteração da disposição do menu.

23 33 Podendo esse passar da configuração de menu vertical, forma adotada como padrão no primeiro acesso, à menu horizontal. Na configuração de menu horizontal, os submenus são mostrados apenas quando há respectivo menu sob o ponteiro do mouse. Este estilo passa da região à esquerda da tela, na configuração vertical, para a mesma região de painel de controle, (Figura 4.6). Figura 4.6: Destaque menu horizontal de interface do sistema atual 4.2 Avaliação de Acessibilidade Como metodologia de coleta de dados foram desenvolvidos quatro tipos de testes para todas as interfaces: validações automáticas, que tem intuito de garantir a observância da maioria dos casos de dificuldades que podem ser apresentadas pelos conteúdos para diversos tipos de deficiências que poderiam não ser contempladas com testes manuais; testes de checklist, utilizado nas interfaces mais importantes dos sistemas para identificar manualmente algum ponto que os validadores automatizados podem não ter analisado; testes simulados, que colocam os desenvolvedores em situação de simulação de deficiência, podendo identificar alguma melhoria que poderia ser realizada para facilitar a utilização por parte desses usuários; e entrevista relizada com usuário real do sistema, que é bastante provável que sejam identificados alguns pontos ainda não percebidos nos testes anteriores, (SOARES, 2006) Validação Automática Existem pelo mundo diversas ferramentas de validação e simulação de acessibilidade para apoiar o processo de criação e verificação de conformidade de conteúdo acessível. Essas ferramentas recomendadas a serem utilizadas após validação do conteúdo HTML e CSS das páginas, são um importante recurso na criação de código acessível. Oferecem facilidade em realizar uma varredura no código e superam dificuldades que pequenas equipes encontram em ter contato com toda a diversidade de usuários existentes em cenários como o brasileiro. Nesse trabalho foram utilizadas 3 (três) ferramentas de avaliação disponíveis na Web. Optou-se por utilizar mais de uma ferramenta, pois cada uma delas possuía determinadas características que se fizeram importantes ao projeto. Com isso, os testes foram realizados

24 34 através de ferramentas amplamente utilizadas, como a Examinator 2, a Hera 3 e a DaSilva 4. Como características importantes, foi identificado através de inúmeros estudos de outros pesquisadores que a ferramenta DaSilva é referência em avaliação automática no contexto brasileiro, onde o próprio governo, através de sua ferramenta chamada ASES(possível de ser utilizada fora da Web) utiliza a máquina deste avaliador, porém, ele não avalia estruturas como os frames que são utilizados nas interfaces analisadas. Já a ferramenta Examinator, além de possuir observações explicativas sobre as críticas e exemplos de resolução, possui o Web@x (Web Accessibility at examinator) 5. Esse índice pode dar informação sintética sobre uma dada página na Internet, ou sobre o conjunto de todas as páginas de um dado domínio na Internet, classificando numericamente, de 0,0 (zero) a 10,0 (dez) o grau de satisfação dos guidelines de acessibilidade de um website conforme metodologia de pontuação elaboração deste índice expressa em seu website, um importante instrumento para este estudo na comparação dos índices atuais com os das interfaces propostas. Por fim, a terceira ferramenta de avaliação utilizada foi a Hera que, apesar de, como o Examinator, não ser muito disseminada no contexto brasileiro, retornou o maior número de críticas na maioria dos testes e, com isso, interpretamos que o avaliador conseguiu analisar o maior número de componentes das interfaces, (Tabela 4.1). Tabela 4.1: Tabela comparativa entre pontos importantes de validadores automáticos Avaliador Ponto Positivo Ponto Negativo Examinator Índice numérico Pouco conhecido no cenário brasileiro Hera Maior número de críticas Pouco conhecido no cenário brasileiro DaSilva Referência do governo brasileiro Não avalia interior de frames Checklist Outro procedimento a ser adotado é a realização do checklist da WCAG 6, para apurar se o website contempla todos os itens de acessibilidade. Esse instrumento trata-se de uma listagem de pontos importantes que devem ser avaliados manualmente nas interfaces desejadas. Apesar dos avaliadores automáticos teoricamente contemplarem o checklist, é sugerido que ele seja incluído na lista de testes, principalmente nas páginas mais importantes e críticas do projeto Teste Simulado Um teste a ser realizado é de especialistas, desenvolvedores de sistemas Web, simulando usuários com deficiências. Esse teste é dividido em três tipos de testes, consistindo em desenvolvedores navegando nas páginas implementadas testando suas funcionalidades primeiramente sem a utilização do mouse, depois sem mouse e com leitor de tela e, por último, sem mouse e sem monitor, utilizando apenas o leitor de tela para a navegação. 2 Validador de Acessibilidade Web, disponível em: < 3 Validador de Acessibilidade Web, disponível em: < 4 Validador de Acessibilidade Web, disponível em: < 5 Índice numérico de 0,0 a 10,0 que sintetiza num só valor o grau de satisfação das diretrizes de acessibilidade para o Conteúdo da Web (WCAG 1.0) do W3C verificado pelo validador Examinator. Mais informações sobre o Web@x disponíveis em: < tecnica webax.html>. 6 O modelo de cheklist utilizado encontra-se em: <

25 35 Esse é o primeiro teste de simulação real. Nele é possível que se perceba alguma falha no desenvolvimento das interfaces que não tenham sido percebidas nos códigos Teste com um Usuário Real Outro teste a ser aplicado neste estudo para verificação do nível de acessibilidade é o teste com um usuário real. Esse teste, geralmente, aponta erros imperceptíveis aos sistemas autônomos. A realização pode ocorrer por meio de entrevista ou outro instrumento que possibilite e melhor atenda à necessidade do desenvolvedor. Nesse estudo foi desenvolvido um questionário semiestruturado para aplicação com um deficiente visual (Apêndice A). Optou-se por aplicar o teste com um usuário real e que apresentasse este tipo de deficiência visual, pois, concluímos ser uma das deficiências que acarreta maior dificuldade em consumir os conteúdos do sistema avaliado. 4.3 Avaliação de Acessibilidade das Interfaces Atuais Nos seguintes subcapítulos, são mostrados os resultados das avaliações realizadas nas interfaces atualmente utilizadas para realização de login de acesso aos sistemas, interface inicial dos sistemas e interface do sistema SIA que apresenta as informações acadêmicas do aluno Ambiente de Testes do Sistema Atual Necessitou-se da criação de um ambiente de testes, porque, por conta da segurança de acesso aos sistemas disponibilizados no CASCA, não seria possível realizar testes de validação automática em todas as interfaces desejadas. Os testes automatizados são projetados para avaliarem páginas disponíveis na Internet e não conseguiriam visualizar a codificação das interfaces apresentadas devido a autenticação de usuário e senha. Conforme exposto neste trabalho, a avaliação de acessibilidade diz respeito à forma de apresentação das interfaces, ou seja, quase que exclusivamente aos códigos finais HTML gerados pelo servidor Web ao serem acessados por um navegador Web. Com isso, para contornar o impedimento de acesso às interfaces, as codificações finais delas foram extraídas e disponibilizadas com informações estáticas, isolando-as do CASCA e seu banco de dados, em um servidor de testes visível na Internet. Dessa forma, tornou-se possível o acesso sem a necessidade de autenticação nos servidores da universidade Validação Automática No primeiro da avaliação automática momento utilizou-se o avaliador de maior reconhecimento no cenário brasileiro, DaSilva. Esse avaliador retornou poucos problemas nas interfaces avaliadas, logo, percebemos que ele não estava avaliando o conteúdo disponível dentro de frames das interfaces informadas. Então, as mesmas interfaces foram submetidas a um segundo avaliador, o Examinator. Esse segundo avaliador apresentou resultados muito superiores na quantidade de críticas, isso ocorreu muito por conta da ferramenta ter realizado avaliação de alguns frames das páginas, não avaliados pelo Da- Silva. Percebendo a diferença entre os avaliadores, as interfaces foram submetidas a um terceiro avaliador, o Hera. Este último avaliador resultou algumas informações diferentes dos anteriores. Após a coleta das informações dos avaliadores, realizou-se realizada uma síntese dos dados que possibilitou a conclusão de que as 3 (três) interfaces analisadas retornaram um