Migração do Observatório Português de Acessibilidade Web

(1)

2018

UNIVERSIDADE DE LISBOA FACULDADE DE CIÊNCIAS DEPARTAMENTO DE INFORMÁTICA

Migração do Observatório Português de Acessibilidade Web

João Afonso Leal dos Santos Vicente

Mestrado em Informática

Dissertação orientada por:

Luís Manuel Pinto da Rocha Afonso Carriço

Carlos Alberto Pacheco dos Anjos Duarte

(2)

(3)

Agradecimentos

Esta dissertação marca o fim de uma etapa importante na minha vida. Foram 6 anos que contribuíram para a minha evolução tanto pessoal, como profissional, e nos quais adquiri variadíssimos conhecimentos. Tal deve-se em geral aos professores do Departamento de Informática da Faculdade de Ciências, mas em especial a todos os que me ajudaram do LASIGE.

Em particular, quero agradecer aos meus orientadores, o professor Luís Carriço e o professor Carlos Duarte, por todo o conhecimento transmitido e ajuda disponibilizada.

Aos meus pais, quero agradecer profundamente pela educação que me deram, por todos os valores transmitidos, pela oportunidade de tirar um curso superior e também pela paciência que tiveram no decorrer destes anos mais difíceis. Agradeço também por me terem ajudado com os recursos para realizar esta dissertação.

A todos os meus amigos e colegas que me apoiaram durante este época de grande stress, e nunca me deixaram desistir, um especial obrigado a Teddy Santos, Mafalda Santos, Patrícia Costa, Gonçalo Oliveira, Pedro Castro, Carlos Duarte, Tiago Moucho, Inês de Matos, Ana "totó"Salvado.

Muito obrigado a todos.

(4)

(5)

(6)

(7)

Resumo

Atualmente a web faz parte do dia a dia de todas as pessoas e a sua utilização tem vindo a aumentar. No entanto, nem todas as pessoas conseguem experienciar a web da melhor maneira, principalmente pessoas com problemas visuais que não conseguem “ver” a web. Para se criar uma página web é necessário utilizar linguagens de programação apropriadas para tal, e de forma a abranger o máximo de pessoas possível foram criadas guias de acessibilidade para os programadores seguirem quando estiverem a desenvolver os seus websites. Devido as estas guias serem complexas e difíceis de interpretar e implementar, grande parte dos programadores acaba por excluir este ponto do seu desenvolvimento. Para facilitar o trabalho dos programadores foram criadas ferramentas de avaliação automática de acessibilidade. Estes avaliadores têm várias vantagens e desvantagens. A principal vantagem é a rapidez com que conseguem apresentar um relatório de acessibilidade, e a principal desvantagem é a dificuldade da implementação das regras de acessibilidade no avaliador. Estas ferramentas são principalmente úteis para entidades que têm como missão verificar a acessibilidade web. Sendo a FCT uma dessas entidades, esta possui uma conjunto de ferramentas (websites) de monitorização de acessibilidade web que pretende melhorar. Este trabalho tem o objetivo de melhorar os serviços prestados por essas ferramentas denominadas Access Monitor Plus, Study Monitor, My Monitor e Observatório. Em relação a cada ferramenta foi feita uma análise completa de forma a se reformular cada uma para um estado mais atual. A análise compreendeu a arquitetura, o modelo de dados, a estrutura interna de ficheiros e o código no seu geral. Após a análise estar completa decidiu-se que o sistema precisava de um novo desenho, e para tal vários aspetos teriam de ser modificados. Os pontos principais desta reformulação foram a arquitetura global e interna dos vários websites, juntamente com o modelo de dados, que foi totalmente refeito. Após se ter desenhado o novo sistema, passou-se à sua implementação, tendo-se atualizado as tecnologias e metodologias de desenvolvimento. Por fim, após a reformulação bem sucedida de cada website, começou-se o processo da possível substituição do avaliador de acessibilidade, tendo-se planeado uma arquitetura para um middleware de conversão de dados entre as aplicações e o possível novo avaliador.

Palavras-chave: acessibilidade na web, ferramentas de avaliação automática, regras de acessibilidade, páginas web

(8)

(9)

Abstract

Nowadays, the web is part of everyday life for everybody and its use has been increasing. However, not all people can experience the web in the best way. Especially people who are visually impaired, since they cannot “see” the web. In order to create a webpage it is necessary to use programming languages designed to do so, and in order to cover as many people as possible, accessibility guides have been created for developers to follow when developing their websites. Because these guides are complex to interpret and implement, most programmers end up excluding this point in their developments. To facilitate the work of programmers, tools supporting the automatic assessment of accessibility were created. However, these evaluators have several advantages and disadvantages. The main advantage is the speed with which they can present an accessibility report, and the main disadvantage is the difficulty of implementing the accessibility rules in the evaluator. These tools are very useful for entities whose mission is to check web accessibility. Since FCT is one of these entities, it contains a set of web accessibility monitoring tools (websites) that they want to improve. This work has the objective of improving the services provided by these tools called Access Monitor Plus, Study Monitor, My Monitor and Observatory. A complete analysis of the tools has been done in order to update each one to a more current state. The analysis comprised the architecture, the data model, the internal file structure, and the code as a whole. After the analysis was completed it was determined that the system needed a new design, and for this several aspects would have to be modified. The main points of this reformulation were the internal global architecture of the various websites, along with the data model, which was completely reformulated. After the re-design, the new system was implemented and the technologies and methodologies of development were updated. Finally, after successfully reformulating each website, the process of replacement of the accessibility evaluator begun, and an architecture for a data-conversion middleware between the applications and the possible new evaluator was planned.

Keywords: web accessibility, automated evaluation tools, accessibility guidelines, web pages

(10)

(11)

Conteúdo

Lista de Figuras xiii

Lista de Tabelas xv 1 Introdução 1 1.1 Contexto . . . 2 1.2 Objetivos . . . 2 1.3 Metodologia . . . 3 1.4 Estrutura do documento . . . 3 2 Trabalho relacionado 5 2.1 Avaliação de acessibilidade web . . . 5

2.1.1 WAI (Web Accessibility Initiative) . . . 6

2.1.2 Avaliação de peritos . . . 6

2.1.3 Avaliadores automáticos . . . 7

2.1.4 Ajuda de utilizadores . . . 8

2.1.5 Comparação . . . 9

2.2 Análise de avaliadores automáticos . . . 9

2.2.1 Características dos avaliadores . . . 10

2.2.2 Resultados . . . 11

2.2.3 Diferenças encontradas . . . 12

2.3 Análise de observatórios de acessibilidade . . . 14

2.4 Sumário . . . 15 3 Análise 17 3.1 Análise de requisitos . . . 17 3.1.1 Observatório . . . 17 3.1.2 My Monitor . . . 18 3.1.3 Study Monitor . . . 19

3.1.4 Access Monitor Plus . . . 21

3.1.5 Admin Monitor Suite . . . 22

3.2 Estado inicial . . . 24

(12)

3.2.1 Arquitetura e aplicações . . . 24

3.2.2 Examinator . . . 26

3.2.3 Estrutura de dados do Examinator . . . 28

3.2.4 Modelo de dados . . . 29 3.2.5 Diagramas de ficheiros . . . 40 3.2.6 Diagramas de navegação . . . 43 3.2.7 Discussão . . . 46 3.3 Sumário . . . 53 4 Desenho 55 4.1 Limitações e requisitos . . . 55 4.2 Arquitetura . . . 55 4.2.1 Avaliador de Acessibilidade . . . 56 4.3 Modelo de dados . . . 56 4.3.1 Tabela “User” . . . 58 4.3.2 Tabela “Tag” . . . 60 4.3.3 Tabela “Entity” . . . 60 4.3.4 Tabela “Website” . . . 61 4.3.5 Tabela “Domain” . . . 61 4.3.6 Tabela “Page” . . . 62 4.3.7 Tabela “Evaluation” . . . 63 4.4 Tecnologias usadas . . . 64 4.4.1 Aplicações web . . . 64 4.4.2 Servidor . . . 68 4.5 Sumário . . . 71 5 Implementação 73 5.1 Aplicações web . . . 73 5.1.1 Bibliotecas externas . . . 73 5.1.2 Modo de produção . . . 75 5.1.3 Dificuldades encontradas . . . 76 5.2 Servidor . . . 79 5.2.1 Sessão do utilizador . . . 79 5.2.2 Bibliotecas externas . . . 79 5.2.3 Middleware . . . 80 5.2.4 Web services . . . 81 5.2.5 Modo de produção . . . 84 5.2.6 Dificuldades encontradas . . . 85 5.3 Admin script. . . 85 5.4 Avaliação . . . 85 x

(13)

5.4.1 Utilizadores . . . 85

5.4.2 FCT . . . 86

5.5 Sumário . . . 86

6 Arquitetura normalizada para observatórios 87 6.1 Projeto WAI-Tools . . . 87

6.2 Estrutura de dados normalizada . . . 88

6.2.1 Assertion . . . 88 6.2.2 Assertor . . . 88 6.2.3 Test Subject . . . 89 6.2.4 Test Criterion . . . 90 6.2.5 Test Result . . . 90 6.2.6 Test Mode . . . 91

6.3 Alterações necessárias ao sistema . . . 92

6.3.1 Pontuação . . . 92

6.3.2 Níveis de conformidade . . . 93

6.3.3 Dados estatísticos . . . 93

6.3.4 Elementos com erro . . . 93

6.3.5 Relatório de acessibilidade no geral . . . 93

6.4 Nova arquitetura . . . 94

6.4.1 Módulo de mapeamento das regras . . . 94

6.4.2 Módulo de geração de pontuações . . . 94

6.4.3 Módulo de metadados . . . 94

6.5 Sumário . . . 95

7 Conclusão 97 7.1 Access Monitor Suite . . . 97

7.2 Projeto WAI-Tools . . . 98

7.3 Contratempos . . . 98

7.4 Trabalho futuro . . . 99

Bibliografia 102

(14)

(15)

Lista de Figuras

2.1 Relação entre os técnicas de teste de acessibilidade. Nota: As áreas do

diagrama não representam uma escala ou medida. . . 10

3.1 Arquitetura analisada. . . 24

3.3 Bases de dados, SQLite, da aplicação Access Monitor. . . 30

3.2 Tabelas, MySQL, da aplicação Access Monitor. . . 31

3.4 Tabela, SQLite, da aplicação Access Monitor Plus. . . 32

3.5 Tabelas da aplicação My Monitor. . . 33

3.6 Tabelas da aplicação Observatório. . . 37

3.7 Diagrama de ficheiros das aplicações AMP, MM e AML. . . 41

3.8 Diagrama de ficheiros da aplicação Observatório. . . 44

3.9 Legenda dos diagramas de navegação. . . 45

3.10 Mapa de navegação da aplicação Access Monitor Plus. . . 45

3.11 Mapa de navegação da aplicação My Monitor. . . 47

3.12 Mapa de navegação da aplicação Observatório. . . 48

4.1 Arquitetura do novo desenho do sistema. . . 57

4.2 Modelo de dados do novo desenho do sistema. . . 59

4.3 Exemplo de um componente. . . 65

4.4 Ciclo de vida de um componente. . . 66

4.5 TagHTML do exemplo do componente acima mencionado. . . 66

4.6 Uso de guards no routing da aplicação. . . 67

4.7 Exemplo do código de um pipe. . . 68

4.8 Exemplo da utilização de um pipe. . . 68

4.9 Estrutura detalhada do servidor . . . 70

5.1 Exemplos de traduções para duas línguas. . . 75

5.2 Tamanho da aplicação AMP em modo de desenvolvimento . . . 76

5.3 Tamanho da aplicação AMP em modo de produção . . . 76

5.4 Ficheiro main.js da aplicação AMP em modo desenvolvimento (lado direito) 77 5.5 Ficheiro main.js da aplicação AMP em modo produção (lado direito) . . 78

6.1 Exemplo da estrutura de uma assertion. . . 89

(16)

6.2 Exemplo da estrutura de um assertor. . . 89

6.3 Exemplo da estrutura de um test subject. . . 90

6.4 Exemplo da estrutura de um test case - test criteria. . . 90

6.5 Exemplo da estrutura de um test requirement - test criteria. . . 90

6.6 Exemplo da estrutura de um test result. . . 91

(17)

Lista de Tabelas

2.1 Comparação das técnicas de avaliação de acessibilidade . . . 9

3.1 Técnicas testadas pelo Examinator da aplicação AML . . . 27 3.2 Diferenças no código entre os dois ficheiros dbase.php. . . 51

(18)

(19)

Capítulo 1

Introdução

Hoje em dia a web é utilizada pelas mais diversas razões e faz parte do dia-a-dia das pessoas no geral. Mundialmente, a sua utilização tem vindo a crescer devido a várias razões como por exemplo, o fácil acesso, a quantidade de informação que esta apresenta e a sua versatilidade em contribuir com soluções para problemas. Muitos programas que antigamente eram desenvolvidos para se instalarem no computador, têm vindo a migrar para a web devido ao avanço da tecnologia. Com esta migração vem a mudança das ferramentas utilizadas para implementar as aplicações. No entanto, apesar da mudança mantém-se a responsabilidade de disponibilizar aplicações acessíveis a todos. Muitos websites e aplicações web não são acessíveis, bloqueando o acesso a uma parte da população, seja com problemas motores, cognitivos ou visuais.

A World Wide Web Consortium (W3C) desenvolveu as Web Content Accessibility Guidelines (WCAG) de forma a ajudar os programadores a incorporar acessibilidade nos seus websites. No entanto, estas diretrizes ainda não são totalmente usadas por várias razões, ora porque são difíceis de entender, complicadas de implementar, os programadores não têm conhecimento da sua existência, podem não ter interesse na acessibilidade, ou simplesmente não é o foco do website/aplicação.

Estes pontos levam a um sério problema pondo em causa o acesso a uma parte da população. Atualmente, por questões legais, websites dos governos ou de instituições e serviços públicos têm de ser acessíveis até um certo nível, permitindo a toda a população aceder e utilizar sem problemas esses websites. Normalmente encontrar problemas de acessibilidade num website já existente de forma manual é bastante demorado. Por isso, foram criadas ferramentas de avaliação automática e semi-automática que avaliam páginas e devolvem os problemas encontrados. A Fundação para a Ciência e a Tecnologia (FCT) tem websites de avaliação automática de acessibilidade e é neles que nos vamos focar neste projeto.

(20)

Capítulo 1. Introdução 2

1.1 Contexto

A web está em constante mudança e evolução, novas tecnologias vão sendo desenvolvidas e é necessária manter a acessibilidade presente nos websites. O website da Unidade ACESSO da FCT1fornece várias funcionalidades como a avaliação de acessibilidade de páginas web, estudos de acessibilidade de grupos de páginas ou websites e a observação da acessibilidade no geral dos sites do governo, instituições e serviços públicos. Quando comparados aos websitesda atualidade, constata-se que os websites da FCT estão um pouco desatualizados a nível de design e funcionalidades. Consciente desta situação, a própria FCT começou um processo interno de melhorar cada website para uma versão mais recente e adequada. No entanto, devido a circunstâncias internas da própria FCT esse processo foi interrompido e mantido em espera. De forma a continuar o processo de melhoria dos websites a Faculdade de Ciências da Universidade de Lisboa (FCUL) foi contactada para ajudar no processo.

Em paralelo a este processo de melhoria dos websites, está a decorrer um outro projeto financiado por fundos Europeus, denominado WAI-Tools2, no qual tanto a FCT como a FCUL estão envolvidas. Devido à envolvência neste projeto por parte das duas entidades, estabeleceu-se um novo objetivo que consiste em preparar os websites da FCT para uma fase futura do projeto WAI-Tools.

1.2 Objetivos

Este projeto está dividido em duas fases, sendo a primeira fase mais importante a curto prazo e considerada o objetivo principal, e a segunda fase mais importante a longo prazo, mas dependente da primeira fase, e considerada o objetivo secundário.

O objetivo principal baseia-se em continuar o processo de melhoria dos websites da FCT. Esta melhoria consiste em conseguir replicar todas as funcionalidades existentes em cada um dos websites para uma interface mais recente e adequada à atualidade, e caso necessário refazer as funcionalidades de forma a serem mais intuitivas e percetíveis. Durante este processo, irá-se atualizar tanto o frontend como o backend.

O objetivo secundário passa por preparar os novos websites para o projeto WAI-Tools. Esta preparação passa por modificar ou substituir o avaliador de acessibilidade usado pela FCT, de forma a que este cumpra as normas do projeto. No contexto deste trabalho ir-se-á estudar o avaliador e preparar o processo de modificação. Por fim, caso haja tempo, ir-se-á iniciar o processo de modificação ou transição.

1_{http://www.acessibilidade.gov.pt/index.htm}

(21)

1.3 Metodologia

De forma a conseguir alcançar os objetivos dividiu-se o projeto em várias etapas. Inicial-mente começou-se por entender o verdadeiro âmbito do projeto, ou seja, quantos websites existiam, o que faziam e como estavam organizados. Após ter-se uma noção geral do sistema passou-se a uma fase de análise detalhada, cujo foco foi entender o desenho dos websites, das funcionalidades implementadas, arquitetura, modelo de dados, limitações, segurança e tecnologias. O resultado desta análise permitiu planear a etapa seguinte, que se focou em estruturar o desenho da reformulação. Este novo desenho envolveu modificar a arquitetura, modelo de dados e as tecnologias, de forma a resolver muitos dos problemas encontrados. Depois de concluído o desenho passou-se à sua implementação.

Após terminada a implementação, na posse do conhecimento total das aplicações web que substituem os antigos websites, é possível dar início ao trabalho no objetivo secundário. Neste fase, analisa-se o sistema com o propósito de entender o que terá de ser modificado para permitir substituir o avaliador de usabilidade utilizado, um cenário que poderá resultar da participação no projeto WAI-Tools.

1.4 Estrutura do documento

Este documento está dividido num total de 7 capítulos estruturados da seguinte forma:

Capítulo 2: Trabalho relacionado

Este capítulo irá apresentar um breve estudo sobre acessibilidade web, com a descrição de alguns avaliadores automáticos e semi-automáticos e do processo de avaliação manual por peritos. Por fim também será apresentada uma análise de alguns observatórios de acessibilidade.

Capítulo 3: Análise

Neste capítulo são caracterizados os serviços da Unidade ACESSO, seguido da análise detalhada do sistema atual focando os websites, arquitetura e modelo de dados.

Capítulo 4: Desenho

Este capítulo foca-se no desenho e abordagens do novo sistema, incluindo nova arquitetura, novo modelo de dados, tecnologias e decisões tomadas até ao estado final.

Capítulo 5: Implementação

Este capítulo foca-se em seguir o novo desenho e explicar a implementação do novo sistema, abordando as várias aplicações e o novo servidor dando alguma ênfase às dificuldades

(22)

encontradas.

Capítulo 6: Arquitetura normalizada para observatórios

Neste capítulo é discutido o impacto que poderá resultar da adoção de uma estrutura de dados normalizada para reportar resultados de avaliação de acessibilidade. Esse impacto poderá advir da modificação do avaliador de acessibilidade da FCT, ou por via da inclusão de outro avaliador. São explicadas que modificações terão de ser feitas às aplicações de forma a serem compatíveis com essa nova estrutura de dados.

Capítulo 7: Conclusão

Neste capítulo é feita uma breve conclusão, resumindo o projeto, as abordagens e imple-mentações do sistema, problemas ocorridos e trabalho futuro.

(23)

Capítulo 2

Trabalho relacionado

Desde sempre que a acessibilidade é um fator importante na comunidade. Ao analisarmos o mundo físico encontramos vários instrumentos e técnicas de forma a tornar todo o tipo de interação possível para pessoas com necessidades especiais como por exemplo rampas de acesso aos edifícios em vez de escadas para pessoas em cadeiras de rodas, e textos escritos em braille para invisuais. Este esforço tem também vindo a acontecer no mundo digital. A melhoria da acessibilidade de websites é uma necessidade, pois estes, cada vez mais, fazem parte da vida de toda a gente.

2.1 Avaliação de acessibilidade web

A acessibilidade de um website é muito importante e é um fator que se deve ter em conta se queremos satisfazer todas as pessoas independentemente das suas capacidades [1]. Muitas vezes este fator é descartado, por ser complicado, ou porque os webmasters não acham necessário ou não têm conhecimento que lhes permita fazer os desenvolvimentos necessários.

Essa falta de conhecimento revela-se também na dificuldade em avaliar a acessibilidade de um website. Isto é particularmente importante quando o objetivo for construir um websiteacessível (o que deveria ser sempre o objetivo). Neste caso, várias avaliações terão de ser feitas de forma a garantir que se alcança esse objetivo.

As orientações WAI foram criadas de forma a ajudar os webmasters a criar websites acessíveis. Estes deviam utilizar as orientações sempre que possível, e em qualquer parte do processo de desenvolvimento de forma a suavizar próprio processo. No fim ou durante o processo de desenvolvimento, para garantir que o website é acessível podem-se usar várias técnicas de avaliação, sendo essas [1]: ferramentas automáticas, peritos em acessibilidade, ou ajuda de utilizadores. Estas tecnicas têm as suas vantagens e desvantagens e devem ser consideradas consoante o objetivo e importância do website.

Para tornar o processo ainda mais complexo, verifica-se que a web é muito heterogénea e imprevisível [2], ou seja, a qualquer momento pode ser necessário fazer alterações no

(24)

Capítulo 2. Trabalho relacionado 6

websitede forma a satisfazer novos requisitos ou até orientações, visto que estas também vão sendo atualizadas. A utilização de tecnologias de implementação diferentes pode também ter impacto na acessibilidade. Certas tecnologias como frameworks, padrões e linguagens de programação podem facilitar a implementação da acessibilidade [3].

2.1.1 WAI (Web Accessibility Initiative)

A WAI [4] é uma iniciativa criada pelo W3C de forma a introduzir normas e orientações [5] de acessibilidade para os websites. Desta forma os webmasters podem ter uma ideia de como preparar os seus websites, de modo a conseguir fazê-los chegar a toda a gente independentemente das suas capacidades.

Estas normas têm sofrido alterações ao longo do tempo. Como visto em [5], as orientações atuais estão na versão 2.1. Isto acontece porque a web é muito imprevisível [2], em particular no que se refere às tecnologias utilizadas. Como consequência, ideias novas vão surgindo sobre como melhorar as orientações e reformulações vão sendo feitas.

As Web Content Accessibility Guidelines (WCAG) 2.1 são orientações para quem quer desenvolver conteúdo para a web. Existem três níveis de conformidade no WCAG 2.1: A, AA e AAA. Estes níveis estabelecem objetivos e focos diferentes. Pelo menos o nível básico (A) deveria estar presente em todos os websites para garantir o mínimo de acessibilidade. Na realidade, aplicar as orientações do WCAG 2.1 pode não ser uma tarefa simples [2]. Cada vez mais temos websites maiores e mais dinâmicos, o que exige um maior esforço na implementação da acessibilidade, pois existem várias técnicas e aspetos para lidar com este tipo de conteúdo.

Como visto, aplicar estas orientações pode não ser tarefa fácil, e por isso, pode-se apenas fazer uma avaliação e implementação parcial destas orientações, tendo em mente que não se vai resolver todos os problemas. Pode ser que esta implementação parcial consiga abranger as limitações mais comuns, que correspondem a uma grande percentagem da população. Mesmo com todas as orientações implementadas, um website pode não ser acessível para toda a gente, pois podem existir casos extremos, ou a interação com o websitepode não ser compatível com o utilizador [2].

2.1.2 Avaliação de peritos

Uma das formas de avaliação é a avaliação de peritos. Peritos, neste contexto, são pessoas, não necessariamente webmasters, que conhecem e percebem bem as orientações da WAI. Estas pessoas avaliam os websites manualmente, ou recorrendo a ferramentas que os auxiliem, apontando os problemas que vão encontrando para no futuro serem corrigidos. Nem sempre é necessário um perito nesta área, mas consoante a dificuldade ou a importância do website, a avaliação pode ser feita por um novato [1].

(25)

No entanto, mesmo tendo esta grande vantagem, existem várias desvantagens. Uma das maiores desvantagens é o tempo gasto nestas avaliações. Em [6], três peritos avaliaram três páginas de três websites num total de nove páginas. Cada perito levou cerca de trinta minutos para avaliar uma página com poucos problemas, e uma hora para uma página com muitos problemas. Com estes resultados percebe-se que a avaliação manual é um processo demorado e com custos elevados. No entanto, permite descobrir uma percentagem elevada dos problemas. Não existe grande solução para este problema: se queremos uma avaliação mais rápida iremos precisar de mais peritos, mas se queremos minimizar os custos iremos gastar mais tempo. Uma solução parcial pode consistir em avaliar apenas até um certo nível de conformidade. Assim, um perito estaria focado apenas nalguns problemas, fazendo com que a avaliação seja mais rápida. Deste modo, consegue-se minimizar os custos e o tempo gasto. No entanto, apenas uma parte das orientações de acessibilidade seriam verificadas.

2.1.3 Avaliadores automáticos

Outra forma de avaliar é usando avaliadores automáticos de acessibilidade. Esta forma envolve ferramentas online ou programas para o computador em que se insere um url do websitee a ferramenta devolve o resultado da avaliação. Esta avaliação utiliza como base as orientações WCAG, de forma a apresentar resultados ao utilizador. Dependendo das orientações implementadas a avaliação pode consistir na análise de código HTML, CSS e JavaScript.

Esta forma, comparativamente à forma anterior, é extremamente mais rápida, conse-guindo oferecer um resultado num espaço de segundos. No entanto, também relativamente à forma anterior, o número de problemas de acessibilidade encontrados é muito pequeno comparado com o número real. Como foi apresentado em [6], os resultados dos avaliadores automáticos eram muito inferiores aos encontrados pelos peritos. As nove páginas dos três websites foram testadas em seis avaliadores diferentes, e cada um dos avaliadores apresentou resultados distintos para os três websites. Os resultados foram distribuídos por quatro áreas, e apenas uma dessas quatro áreas era consistente por todos os avaliadores. Visto que os vários avaliadores têm implementações diferentes, detetou-se que apenas estavam implementados 42% dos critérios de sucesso existentes nas orientações WCAG, e mesmo dentro destes 42%, no máximo foram detetados 38% dos problemas. Com estes resultados conseguimos perceber que os avaliadores automáticos por mais rápidos que sejam não substituem um perito, e não devem ser usados sozinhos numa avaliação. Para além da baixa percentagem de problemas encontrados, os avaliadores que mostraram detetar mais problemas, também apresentaram a maior taxa de falsos positivos, ou seja, muitos dos problemas encontrados não são realmente problemas.

Como visto em [1, 7] a semântica do conteúdo é um dos maiores problemas dos avaliadores. O fato de estes não conseguirem detetar este tipo de problemas faz com que o número de resultados seja bastante reduzido. Conteúdo semântico, consiste num

(26)

tipo de conteúdo que fornece contexto por si só, como por exemplo um frase descrever uma imagem, é considerado conteúdo semântico, e este tipo de conteúdo não pode ser facilmente verificado por um avaliador automático.

Outro problema mencionado em [7], que contribui para o fraco desempenho, é o fato destes avaliadores não testarem os vários estados das páginas. Estados são eventos ou alterações que ocorrem nos websites resultantes da interação do utilizador. Um exemplo de um estado pode ser uma caixa de diálogo que aparece após se carregar num botão de uma página. Este estado, onde aparece essa caixa de diálogo, não é testada pela avaliador, pois a caixa não existe em código durante a obtenção do código HTML. Estes podem gerar mais problemas de acessibilidade, mas visto que avaliadores automáticos não avaliam esses estados, dificulta a deteção de problemas.

A utilização de apenas avaliadores automáticos não é aconselhada para encontrar problemas de acessibilidade. No entanto, para tentar abranger uma grande quantidade de problemas pode-se utilizar vários avaliadores ao mesmo tempo e analisar os vários resultados. Mesmo desta forma, há que se perceber que mesmo usando todos os avaliadores, eles não irão substituir um perito na avaliação. Mas para uma breve análise e noção dos problemas, os avaliadores automáticos são mais baratos com uma maior rapidez.

2.1.4 Ajuda de utilizadores

Uma forma de obter resultados mais fidedignos é executando testes com utilizadores com deficiência [1]. Se o objetivo dos webmasters é tornar acessível um website para um público específico, ou seja, com um certo nível de capacidade, então executar testes com esse tipo de utilizadores pode ajudar mais do que simplesmente guiar-se pelas normas da WAI. Desta forma, resultados mais fidedignos podem ser conseguidos. Esta possibilidade não significa que se devam descartar as normas WAI. Estas devem ser sempre aplicadas de forma a manter a acessibilidade para o máximo possível de pessoas. No entanto, a avaliação com a ajuda de utilizadores serve para melhorar significativamente a acessibilidade para um público alvo.

Ainda assim, não se pode esperar que todos os problemas sejam detetados com estes testes. Como visto em [1], em média estes utilizadores detetam apenas 35% dos problemas. Esta percentagem depende do tipo utilizador, se este é novato ou um perito e este fator é importante para perceber os problemas que estes encontram e para filtrar os problemas reais a partir da forma de interagir no website durante a avaliação. Um dos problemas desta forma de avaliação é a dificuldade em encontrar representantes da população alvo que estejam dispostos a ajudar. Normalmente já é complicado fazer testes com utilizadores comuns, sendo ainda mais complicado encontrar este tipo de utilizadores. Ainda assim, é sempre melhor poucos que nenhuns, uma vez que qualquer ajuda é útil e não deverá ser descartada. Esta forma não deve ser posta de parte só porque existe maior dificuldade em encontrar utilizadores para testes.

(27)

2.1.5 Comparação

Tabela 2.1: Comparação das técnicas de avaliação de acessibilidade

Vantagens Desvantagens

Peritos _{Deteção elevada de problemas} Elevado custo

Demasiado tempo gasto na avaliação Avaliadores automáticos Rapidez na entrega do resultado

Baixo custo

Resultados pouco fiáveis

Os resultados podem ser difíceis de interpretar

Utilizadores Melhoria significativa do website Deteção de problemas significativos

Dificuldade de encontrar pessoas para fazer os testes Pouco económico em termos de tempo Dificuldade na interpretação das respostas

Vistas as vantagens e desvantagens destas três formas de avaliar, tabela 2.1, podemos perceber que estas se podem complementar umas às outras. Dependendo do objetivo de cada webmaster, este pode decidir usar a forma ou formas que lhe é/são mais conveniente/s. Por exemplo, fazendo combinações das três formas [1] para conseguir criar um website extremamente acessível, assumindo que os problemas são corretamente corrigidos. A união destas formas de avaliação pode ser vista na figura 2.1, retirada de [1]. Se o objetivo do website é ser acessível, então o webmaster não se pode focar apenas em avaliadores automáticos. No entanto pode usá-los numa fase inicial de forma a entender como pode avançar daí em diante. As orientações WCAG são uma base fundamental para se construir um website acessível, no entanto há que ver que os websites são criados para serem utilizados por humanos, e por isso a opinião de utilizadores deve ser bastante considerada. Das três formas apresentadas, ambas contêm os seus pontos fortes e fracos, mas cabe ao webmasterdecidir o que melhor se adequa à situação.

2.2 Análise de avaliadores automáticos

Avaliadores automáticos de acessibilidade são ferramentas utilizadas para melhorar os websites, para fazer estudos sobre a acessibilidade web, e para monitorizar a acessibilidade webno geral. No entanto, por razões previamente explicadas devem ser usados com atenção. Por questões legais, os websites de governos, instituições e serviços públicos têm de cumprir um mínimo de acessibilidade, sendo esse mínimo o nível de conformidade AA [8]. Devido a estas obrigações legais, foi necessário melhorar os avaliadores automáticos de forma a ajudar os webmasters a cumprir as orientações existentes (WCAG).

Nesta secção faz-se uma pequena comparação entre vários avaliadores de acessibilidade de forma a demonstrar alguns dos problemas inerentes. Os avaliadores analisados foram:

(28)

Figura 2.1: Relação entre os técnicas de teste de acessibilidade. Nota: As áreas do diagrama não representam uma escala ou medida.

QualWeb [9], Access Monitor [10], Axe [11], AChecker [12], WAVE [13], Siteimprove Accessibility Checker [14].

Para ilustrar esta comparação fez-se uma avaliação com a página principal da Faculdade de Ciências da Universidade de Lisboa1 _{usando o browser Chrome versão 70. Foram}

comparados os vários avaliadores, mesmo tendo características diferentes. Os pontos de comparação focaram-se nas técnicas/regras usadas, quantidade de informação apresentada, percetibilidade da informação e qualidade dos resultados.

2.2.1 Características dos avaliadores

Todos os avaliadores apresentados são diferentes. Não só as suas interfaces são diferentes, como o método de avaliação, as técnicas/regras usadas, os resultados e funcionalidades extras. Escolheram-se os avaliadores QualWeb, Access Monitor, Axe e Siteimprove pois são os que estão presentes no projeto WAI-Tools. O AChecker por ser conhecido e ser bastante simples e o WAVE por ter uma apresentação de resultados bastante particular.

Todos estes avaliadores são usados num browser. Todos exceto o Axe e o Siteimprove, podem ser usados a partir dos websites respetivos sem qualquer tipo de instalação, enquanto que o Axe e o Siteimprove requerem a instalação de um plugin para o Chrome de forma a se poder executar avaliações.

Alguns dos avaliadores disponibilizam opções de avaliação, onde se pode selecionar que versão do WCAG se quer utilizar (1 ou 2), e também disponibilizam que nível de conformidade se quer avaliar (A, AA ou AAA). Para esta avaliação utilizou-se sempre que possível as WCAG 2 com o nível AAA.

(29)

2.2.2 Resultados

Como era expectável os resultados de cada avaliador foram diferentes. Nesta subsecção faz-se uma pequena análise de cada um.

QualWeb

O QualWeb, dentro dos testados, é o único que permite escolher o contexto da página web, seja versão desktop ou mobile. Nesta avaliação usou-se a versão desktop. O avaliador executou a avaliação com sucesso, tendo encontrado um total de 806 elementos na página e feito um total de 1178 testes, dos quais 334 passaram, 252 deram erro e 592 deram warning. É possível escolher o método de apresentação por critérios ou por técnicas, e também é possível filtrar os resultados pelos que passaram, deram erro ou warning. Dentro da secção dos resultados, é possível ver os elementos de cada critério/técnica que apresentam erros, warningsou que estão bem, tudo isto acompanhado por descrições referentes ao problema em questão.

AChecker

O AChecker executou a avaliação com sucesso, tendo encontrado 17 problemas e 454 potenciais problemas. Dentro da secção dos resultados podemos ver que estão ordenados por critérios e em cada critério são apresentados os elementos com erro. Junto a cada elemento é mostrada a linha do elemento e a coluna onde começa. Para cada critério encontrado com erros é apresentada uma nota sobre como reparar o problema presente.

WAVE

O WAVE executou a avaliação com sucesso, tendo encontrado 17 erros, 33 alertas, 6 features, 39 elementos estruturais, 10 HTML5 e ARIA e 0 erros de contraste. É possível filtrar os resultados por cada um dos pontos apresentados e até por cada tipo de teste dentro de cada ponto. A secção de resultados é diferente da habitual. Este avaliador foca em apresentar a página avaliada, adicionando ícones, com cada ícone representando um teste feito aos elementos da página. Desta forma é possível visualizar o erro diretamente na página ao carregar no ícone do teste. A informação apresentada reflete o problema. O avaliador disponibiliza documentação sobre o que significa cada ícone apresentado.

Access Monitor

O Access Monitor, dentro dos testados, é o único avaliador que apresenta uma pontuação de acessibilidade, sendo esta entre 1 e 10. O avaliador executou a avaliação com sucesso, tenda a página alcançado uma pontuação de 8.1. Foram encontrados um total de 563 elementos na página e é apresentado um sumário da avaliação com os seguintes dados: 1 prática com sucesso (1 nível A, 0 nível AA, 0 nível AAA), 2 práticas com erro (1 nível A,

(30)

0 nível AA, 1 nível AAA) e 13 práticas com avisos (9 nível A, 2 nível AA, 2 nível AAA). É possível ver os resultados apresentados de duas formas, sendo a principal o modo tabela, onde se apresentam as práticas avaliadas com uma descrição sobre as mesmas, ou o modo linear onde se apresentam todos elementos numa lista juntamente com informação sobre os mesmos. Em cada prática encontrada é mostrada a descrição da mesma, com links para as técnicas (ou critérios) associadas e três botões para ver os elementos associados à prática, seja em separado, ver no DOM, ou ver na página.

Axe

O Axe executou a avaliação com sucesso, tendo encontrado um total de 49 problemas (34 violações, 4 para rever manualmente, 0 rejeições e 11 de boas práticas). Este avaliador, sendo um plugin, apresenta os seus resultados numa tab própria na consola de desenvolvi-mento do Chrome. Desta forma, é possível visualizar a página avaliada ao mesmo tempo que os resultados de acessibilidade. Estas duas interfaces funcionam em sintonia, pois ao selecionar o teste executado é possível visualizar os elementos com erro na página. Cada teste fornece informação sobre o elemento, sobre a localização no código, sobre informação do critério e de como o resolver.

Siteimprove Accessbility Checker

O Siteimprove Accessibility Checker executou a avaliação com sucesso, tendo encontrado um total de 89 problemas por várias categorias e critérios. Este avaliador, sendo um plugin, apresenta os seus resultados numa coluna criada na página após a conclusão da avaliação. Desta forma é possível ver a coluna de resultados mais a página web avaliada. O avaliador permite filtrar os resultados por níveis de conformidade, por severidade (erro, aviso ou rever manualmente), ou por responsabilidade de quem o deve resolver (editor, webmaster ou programador). Na secção de resultados pode ver-se a lista de critérios avaliados com problemas, e para cada critério os testes executados. Ao carregar em cada teste são mostrados os elementos que obtiveram aquele problema específico, sendo possível visualizar esses elementos diretamente na consola de desenvolvimento. Juntamente com os elementos é mostrada informação relevante sobre o teste em questão e de como o resolver.

2.2.3 Diferenças encontradas

Após explicados os resultados de cada avaliador é fácil observar que são bastantes dis-tintos. Todos os avaliadores apresentaram problemas, uns mais que outros, e apresentam informação extra, algo que também foi diferente entre alguns avaliadores.

(31)

Número de elementos da página

Os avaliadores QualWeb e Access Monitor apresentam o número de elementos da página, que, no entanto, mostraram ser diferentes. Esta diferença advém de no QualWeb a avaliação ser feita sobre o resultado do pós-processamento da página enquanto que o Access Monitor avalia a source da página (pré-processamento). Esta diferença pode resultar em avaliações diferentes pois o código a ser avaliado é diferente. De forma a se ter resultados mais corretos deve avaliar-se a página como ela é apresentada ao utilizador. Neste caso tanto o Access Monitor como o AChecker irão induzir falsos positivos e falsos negativos pois apenas fazem pré-processamento das páginas que avaliam.

Resultados

Tal como explicado, fazer pré e pós-processamento das páginas pode afetar os resultados obtidos. No entanto, não só apenas esse fator está em questão. Todos os avaliadores encontraram erros que são comuns uns aos outros, e outros que são específicos a cada avaliador. Isto advém da implementação de cada avaliador, do número de regras/técnicas implementadas e da interpretação das regras/técnicas por parte dos programadores dos avaliadores. Esta interpretação, sendo subjetiva, leva a que cada avaliador com as mesmas regras implementadas apresente resultados diferentes. Isto pode dificultar a vida de uma pessoa que esteja a usar vários avaliadores para corrigir a acessibilidade do seu website, deixando-os confusos sobre o que esta correto ou errado. Face à qualidade dos resultados e da interface, é fácil entender que avaliadores mais recentes sejam mais intuitivos e corretos. Os avaliadores Axe e Siteimprove, sendo plugins, oferecem uma vantagem face à sua utilização e apresentação de resultados, visto que executam avaliações exatamente na página que se pretende, facilitando a apresentação de resultados mais próximos dos reais, visto que a página a ser avaliada é exatamente a que está visível ao utilizador. Ao analisar o número de testes executados pelos vários avaliadores podemos reparar que o QualWeb se sobressai com um número bem maior que os restantes. Com base no estudo realizado, esta diferença é alcançada por apresentar possíveis problemas de semântica como um warning, algo que não foi encontrado nos outros avaliadores, sendo apenas apresentados testes com erros e sucessos. No geral, tirando a menção anterior, não foram identificados problemas face às avaliações. Cada avaliador conseguiu identificar corretamente os problemas presentes na página, significando que apesar de não terem sido encontrados falsos positivos ou falsos negativos, cada avaliador está longe de estar completo.

(32)

2.3 Análise de observatórios de acessibilidade

Observatórios de acessibilidade web são, principalmente websites ou programas, onde se pode ver a acessibilidade da web. Estes observatórios podem pertencer a uma instituição pública, ou a uma empresa privada, podendo então os resultados ser públicos ou privados. Estes observatórios têm como objetivo analisar a acessibilidade web de forma a permitir à instituição/empresa que os mantém fazer estudos sobre a mesma, dar a noção da aces-sibilidade às pessoas, e ao mesmo tempo forçar os programadores a melhorarem os seus websitescaso tenham acesso à informação.

Cada observatório pode funcionar de forma diferente, não havendo um padrão para a metodologia a usar durante a análise da acessibilidade web. Nesta secção ir-se-á falar de alguns observatórios de acessibilidade web encontrados, sendo o foco a metodologia utilizada para a avaliação da web e a apresentação dos dados.

Observatório português da acessibilidade web

Este observatório [15], consiste num website e é de acesso público. No entanto, o público alvo é a equipa interna da organização, para a realização de estudos sobre a acessibilidade web. O website permite a visualização da acessibilidade de algumas entidades, em que cada entidade contém vários websites, e cada website contém uma certa amostra de páginas avaliadas. Não é possível observar os detalhes das avaliações das páginas dos websites, sendo apenas apresentados dados gerais da acessibilidade de cada website. A metodologia utilizada consiste na utilização de um avaliador automático para a avaliação das várias páginas. As entidades/websites/páginas são apresentados consoante os estudos a serem realizados pela organização.

Observatório espanhol da acessibilidade web

Este observatório [16], à semelhança do observatório português, também utiliza uma ferramenta de avaliação automática para proceder à avaliação dos websites pretendidos. A ferramenta compreende um total de vinte verificações de acessibilidade, em que cada veri-ficação pode corresponder a vários testes automáticos. O observatório realiza avaliações, principalmente, aos websites do governo de vários países, e no final dessas avaliações são gerados dois tipos de resultados: agregados e individuais. Os resultados agregados são utilizados para realizar estudos e comparações entre a acessibilidade dos vários países, sendo esta informação disponível ao público, podendo-se fazer download em formato PDF. Os resultados individuais são bastante mais detalhados em relação aos problemas encontrados, sendo então enviados ao responsável do website de forma a este melhorar o mesmo.

(33)

Observatório norueguês da acessibilidade web

Este observatório [17], ao contrário dos dois apresentados acima, utiliza profissionais em acessibilidade (peritos) para realizar as avaliações dos websites. O processo de avaliação passa por dois profissionais verificarem 33 critérios, atribuindo uma pontuação, no final da verificação, entre 1 e 6, sendo 1 considerado muito mau e 6 considerado muito bom. Cada profissional testa os critérios individualmente, e depois em conjunto. Durante os testes, cada profissional verifica todo o percurso da experiência de utilização de um utilizador, desde encontrar o website, encontrar informação pretendida para o objetivo em questão, conseguir completar esse objetivo, etc. No processo são testadas a usabilidade e a acessibilidade. Após completos os testes, os resultados são enviados ao responsável do websitede forma a este ter uma noção do que foi avaliado, podendo comentar em relação a problemas que ache relevante, de forma a haver uma segunda avaliação. Os resultados são privados, sendo apenas enviados aos respetivos responsáveis dos websites para poderem melhorar os mesmos.

2.4 Sumário

Neste capítulo fez-se uma pequena análise sobre a acessibilidade web. Começou-se por abordar o que é acessibilidade web, explicando a existência das orientações WCAG e da sua influência na implementação da acessibilidade. Foram apresentadas três técnicas de avaliação, sendo elas a avaliação manual de peritos em acessibilidade, a avaliação automática usando ferramentas de software e a avaliação manual de utilizadores com incapacidades. De seguida fez-se uma análise de vários avaliadores automáticos de acessi-bilidade, tendo-se apresentado as diferenças na metodologia de avaliação, dos problemas inerentes e na apresentação de resultados. Dos problemas presentes atualmente neste tipo de ferramentas, um deles pode ser facilmente resolvido, que consiste em algumas das fer-ramentas não avaliarem a página web em pós-processamento, ou seja, não avalia o código final que é apresentado aos utilizadores. O outro problema consiste em conseguir avaliar conteúdo semântico, algo que requer interpretação humana. Por fim, analisaram-se alguns observatórios de acessibilidade web, tendo-se apresentado as metodologias utilizadas e a apresentação de resultados.

(34)

(35)

Capítulo 3

Análise

Neste capítulo será descrita a análise total do sistema da FCT, que consta num conjunto de websitesde análise da acessibilidade web. Cada um dos websites tem um propósito dife-rente, sendo necessário analisar o sistema como um todo e cada website individualmente. Para esta análise foi-nos disponibilizado o código das várias aplicações do sistema. No entanto, o levantamento de requisitos apresentados na secção de análise de requisitos foi realizado em conjunto com o pessoal da Unidade de ACESSO da FCT, não tendo apenas resultado da análise do código disponibilizado. Esta fase inicial constitui então uma análise de requisitos e uma análise do estado inicial do sistema.

3.1 Análise de requisitos

No sistema atual da FCT existem várias aplicações, cada uma com um foco e público-alvo diferente. Após uma análise inicial identificaram-se quatro aplicações, cada uma com um grande número de funcionalidades. Após a reunião com a Unidade de ACESSO da FCT chegou-se à conclusão de todos os requisitos do sistema. Com base na análise e na reunião apercebeu-se que algumas funcionalidades de cada aplicação estavam fora do contexto das aplicações. Com base nesta análise decidiu-se migrar essas funcionalidades para uma nova aplicação, ficando com um total de cinco aplicações.

De seguida descreve-se o objetivo de cada aplicação bem como as funcionalidades que devem estar implementadas no final da reformulação. Estes requisitos dizem, então, respeito às aplicações que se irão desenvolver.

3.1.1 Observatório

A aplicação Observatório tem como objetivo fornecer estatísticas, padrões e ordenações de qualidade de acessibilidade da presença de setores relevantes na web, que porventura serão tornadas públicas. Esta aplicação tem como utilizadores a equipa da Unidade ACESSO da FCT, responsável pela observação das políticas de acessibilidade web na administração pública Portuguesa. No entanto, a informação também está disponível ao público em

(36)

Capítulo 3. Análise 18

geral. A aplicação tem os seus dados divididos em três hierarquias, sendo a primeira hierarquia equivalente aos dados de todas as categorias. Um categoria corresponde a um grupo/conjunto de vários websites que tenham alguma relação entre si. Os requisitos desta aplicação são os seguintes:

• Deve ser possível ver as categorias a serem observadas;

• Deve ser possível ver os websites de cada categoria;

• Deve ser possível ver informação geral e estatísticas gerais sobre a acessibilidade de cada website:

– Pontuação média;

– Datas das avaliações mais recente e mais antiga das páginas; – Número de páginas com erros por nível de conformidade; – Distribuição de pontuações;

– Dez erros mais comuns;

– Cinco erros mais comuns por nível de conformidade; – Mancha de pontuações;

– Distribuição detalhada dos erros pelas páginas;

• Deve ser possível ver a distribuição de pontuações e os erros mais comuns de cada categoria;

• Deve ser possível ver a distribuição de pontuações e os erros mais comuns do conjunto de categorias (primeiro nível da hierarquia de dados);

3.1.2 My Monitor

A aplicação My Monitor (MM) tem como objetivo permitir aos utilizadores analisar os problemas de acessibilidade e usabilidade dos seus próprios websites. Para poder utilizar esta aplicação, um webmaster deve solicitar a criação de uma conta junto da Unidade ACESSO, indicando qual o website que pretende monitorizar. Essa conta deve depois ser usada para se autenticar na aplicação. Nesta aplicação um utilizador pode adicionar páginas aos websites, de forma a obter uma análise mais completa. Para cada página avaliada é gerado um relatório de acessibilidade. Este relatório contém informação sobre as boas e más práticas encontradas. Os requisitos desta aplicação são os seguintes:

• Deve ser possível um utilizador, com conta já criada, conseguir iniciar sessão;

(37)

• Deve ser possível um utilizador ver as páginas de um website;

• Deve ser possível um utilizador adicionar novas páginas a um website;

• Deve ser possível um utilizador ver o relatório de acessibilidade de cada página do website;

• Deve ser possível o utilizador realizar uma nova avaliação a cada página do website;

• Deve ser possível ver os elementos HTML/CSS que foram identificados com erros ou warnings a partir do relatório de acessibilidade;

• Deve ser possível ver os elementos que foram identificados com erros ou warnings realçados na página web a partir do relatório de acessibilidade;

• Deve ser possível ver o código HTML da página que foi avaliada;

• Deve ser possível fazer download do relatório de acessibilidade num formato CSV;

3.1.3 Study Monitor

A aplicação Study Monitor (SM) tem como objetivo permitir aos seus utilizadores con-duzirem estudos de acessibilidade de grupos de websites através de análises estatísticas dos resultados da sua avaliação de usabilidade. Quem quiser utilizar esta aplicação deve solicitar a criação de uma conta à Unidade ACESSO. Com esses dados pode autenticar-se na aplicação e criar categorias para fazer estudos sobre o estado de acessibilidade da web. Um utilizador ao criar um estudo pode adicionar websites a esse estudo e páginas aos web-sites. O utilizador pode criar um estudo completamente novo e atribuir-lhe um nome, ou então pode usar como base para o estudo um categoria existente na aplicação Observatório. Neste segundo caso é criada uma cópia dessa categoria e atribuída ao utilizador como um estudo com dados já existentes. Os requisitos desta aplicação são os seguintes:

• Deve ser possível um utilizador, com conta já criada, conseguir iniciar sessão;

• Deve ser possível um utilizador ver todos os seus estudos;

• Deve ser possível um utilizador criar um estudo:

– A partir de categorias já existentes da aplicação Observatório; – Novo estudo disponível somente para o próprio utilizador;

• Deve ser possível um utilizador ver as estatísticas gerais de um estudo;

– Pontuação média do estudo; – Mediana;

(38)

– Variância; – Desvio padrão; – Número de websites; – Número de páginas;

• Deve ser possível um utilizador ver as estatísticas detalhadas de um estudo;

– Tudo o incluído nas estatísticas gerais do estudo;

– Número de páginas que passam em cada nível de conformidade; – Número de páginas com erros por nível de conformidade; – Número de websites com erros por nível de conformidade; – Distribuição de pontuações por páginas;

– Distribuição de pontuações por websites;

– Agregação dos erros encontrados pelas várias páginas; – Agregação dos erros encontrados pelos vários websites;

• Deve ser possível um utilizador a partir das estatísticas detalhadas de um estudo, ver que websites e páginas têm que erros específicos;

• Deve ser possível um utilizador ver os websites de um estudo;

• Deve ser possível um utilizador adicionar novos websites a um estudo:

– Adicionar um website existente de outro estudo do utilizador ao estudo em questão;

– Adicionar um website completamente novo;

• Deve ser possível um utilizador ver as estatísticas gerais de um website;

– Pontuação média; – Mediana;

– Varância amostral; – Amplitude amostral; – Número de páginas;

• Deve ser possível um utilizador ver as estatísticas detalhadas de um website;

– Tudo o incluído nas estatísticas gerais do website;

(39)

– Número de páginas com erros por nível de conformidade; – Distribuição de pontuações por páginas;

– Agregação dos erros encontrados pelas várias páginas;

• Deve ser possível um utilizador a partir das estatísticas detalhadas de um website, ver que páginas têm que erros específicos;

• Deve ser possível um utilizador ver as páginas de um website;

• Deve ser possível um utilizador adicionar novas páginas a um website;

• Deve ser possível um utilizador ver o relatório de acessibilidade de cada página do website;

• Deve ser possível o utilizador realizar uma nova avaliação a cada página do website;

3.1.4 Access Monitor Plus

O Access Monitor Plus (AMP) tem como objetivo mostrar relatórios de acessibilidade de páginas web. Neste aplicação um utilizador insere o URL de uma página web e recebe o relatório gerado pelo avaliador. Este avaliador, denominado Examinator, está presente no servidor, não sendo exclusivo a esta aplicação. O relatório de avaliação apresenta informação detalhada sobre pontos que estão bem implementados e os pontos que estejam mal implementados. As avaliações são baseados nas regras do WCAG (Web Content Accessibility Guidelines) 2.0. Nem todas as regras estão implementadas, pelo que qualquer avaliação é necessariamente incompleta, o que não invalida a sua utilização como base para a correção de um número elevado de problemas de acessibilidade. Os requisitos desta aplicação são os seguintes:

• Deve ser possível o utilizador introduzir um URL da página web que quer avaliar;

• Deve ser apresentado um relatório de acessibilidade da página introduzida;

(40)

• Ao se efetuar uma avaliação de uma página:

– Caso a página avaliada seja uma das páginas monitorizadas numa das outras aplicações esta avaliação é mantida no histórico de avaliações da página; – Caso a página avaliada não seja uma das páginas monitorizadas numa das

outras aplicações mas o website a que pertence esteja a ser monitorizado, então essa página é associada ao website existente e a avaliação é guardada;

3.1.5 Admin Monitor Suite

A aplicação Admin Monitor Suite (AMS) foi criada com o propósito de gerir os dados existentes nas aplicações previamente apresentadas. Esta aplicação é para uso exclusivo do administrador do sistema. Este pode criar novos utilizadores, categorias, entidades, websites, domínios e páginas. Resumidamente, pode manipular todos os dados existentes na base de dados. Por questões de segurança, nesta aplicação não deve ser possível criar novos administradores. Os requisitos desta aplicação são os seguintes:

• Deve ser possível o administrador criar utilizadores para as aplicações SM e MM;

• Deve ser possível o administrador criar entidades;

• Deve ser possível o administrador criar categorias;

• Deve ser possível o administrador criar websites;

• Deve ser possível o administrador criar um novo domínio para um website;

• Deve ser possível o administrador criar novas páginas para um domínio de um website;

• Deve ser possível o administrador editar utilizadores/entidades/categorias/websites;

• Deve ser possível o administrador apagar utilizadores/entidades/categorias/websites/ domínios/páginas/avaliações;

• Deve ser possível o administrador indicar que categorias e páginas são apresentadas na aplicação Observatório;

(41)

• Deve ser possível o administrador ver todos os utilizadores existentes;

• Deve ser possível o administrador ver todas as categorias existentes;

• Deve ser possível o administrador ver todas as entidades existentes;

• Deve ser possível o administrador ver todos os websites existentes;

• Deve ser possível o administrador ver todos os domínios existentes;

• Deve ser possível o administrador ver todas as páginas existentes;

• Deve ser possível o administrador ver que websites existem em cada categoria;

• Deve ser possível o administrador ver que websites pertencem a cada utilizador;

• Deve ser possível o administrador ver que domínios pertencem a cada website;

• Deve ser possível o administrador ver que páginas pertencem a que domínio;

• Deve ser possível o administrador ver todas as avaliações de cada página;

• Deve ser possível um utilizador ver o relatório de acessibilidade de cada avaliação;

• Deve ser possível o utilizador realizar uma nova avaliação a cada página;

(42)

3.2 Estado inicial

Após terem sido definidos os requisitos do sistema foi necessário fazer uma análise ao estado inicial das aplicações. Esta análise tem o foco de perceber o que está desenvolvido e como está desenvolvido. Um dos objetivos consiste em perceber se é possível reaproveitar o código existente.

3.2.1 Arquitetura e aplicações

A principal tarefa da análise consistiu em identificar a arquitetura do sistema, os padrões usados e as linguagens de programação. Numa primeira instância detetou-se a utilização de HTML, CSS e JavaScript como linguagens de programação para a camada de apresentação (frontend) e PHP para a camada de negócio (backend). No entanto não foram encontrados padrões implementados. Na figura 3.1 podemos ver a arquitetura do sistema. Esta é composta por cinco aplicações e duas bases de dados diferentes. Detetou-se também que cada aplicação tem o seu próprio modelo de dados (que será apresentado mais à frente no documento). De seguida é apresentada uma análise a cada aplicação.

Figura 3.1: Arquitetura analisada.

3.2.1.1 Observatório

Durante a análise descobriu-se que a aplicação Observatório é constituída por um grande conjunto de ficheiros e devido à desorganização encontrada, houve alguma dificuldade em perceber a função de cada ficheiro. A camada de apresentação e de negócio encontram-se misturadas, por isso foi recorrente encontrar ficheiros com código HTML, JavaScript e PHP misturados. Uma versão do avaliador de acessibilidade (Examinator) foi encontrada dentro desta aplicação. Todas as funcionalidades encontradas durante a análise, estão presentes na análise de requisitos descrita na secção anterior. No entanto, foram também

(43)

encontradas funcionalidades de administração da própria aplicação. Com todas estas componentes percebeu-se que esta aplicação funciona de forma isolada das restantes.

3.2.1.2 Access Monitor Plus

Durante a análise da aplicação AMP verificou-se que é constituída por poucos ficheiros. No entanto, a análise aos mesmos não ficou facilitada. Tal como observado na aplicação Observatório, existe uma mistura das camadas de apresentação e negócio. Grande parte do código HTML, que representa cada página da aplicação, é escrito dentro de funções PHP, sendo bastante difícil entender o fluxo de dados. Durante a tentativa de entender as ligações entre os vários ficheiros percebeu-se que a aplicação AMP usa outra aplicação como suporte de processamento de dados, Access Monitor Lib (explicada mais à frente), o que dificultou bastante a análise do fluxo de dados. Ao analisar as várias funcionalidades percebeu-se que os dados gerados pela aplicação são guardados numa base de dados, independentemente da importância desses dados. Quase todas as funcionalidades descobertas encontram-se presentes na análise de requisitos, sendo as exceções, a possibilidade de efetuar o download do relatório de acessibilidade, e da própria aplicação guardar os dados da avaliação caso a página avaliada esteja a ser monitorizada por uma das outras aplicações. Foram também encontradas funcionalidades de administração para os dados da própria aplicação.

3.2.1.3 My Monitor

A análise da aplicação MM foi semelhante à da aplicação AMP. Foram encontrados poucos ficheiros, no entanto com a mesma desorganização. Esta aplicação também usa a aplicação Access Monitor Lib como suporte para o processamento de dados, aumentando conside-ravelmente a dificuldade da análise do fluxo de dados. As funcionalidades encontradas encontram-se descritas na análise de requisitos, com a exceção da possibilidade de efetuar o download do relatório de acessibilidade. Foram também encontradas funcionalidades de administração para os dados da própria aplicação.

3.2.1.4 Access Monitor Lib

Esta aplicação, como mencionado nas duas aplicações acima descritas, é usada como suporte ao processamento de dados. Ao analisar os ficheiros existentes descobriu-se que é nesta aplicação que está presente o avaliador de acessibilidade (Examinator), ou seja, o objetivo desta aplicação consiste em processar (avaliar a acessibilidade) os dados referentes às avaliações das várias páginas enviadas pelas duas aplicações. Esta aplicação também comunica com a base de dados para guardar os dados necessários somente da aplicação MM. Um dos aspetos que dificultou a análise desta e das outras duas aplicações foi a desorganização dos ficheiros e dos seus propósitos. Seria de esperar as aplicações AMP e MM tratarem da camada de apresentação, enquanto que utilizavam esta como suporte ao

(44)

processamento de dados. No entanto, este aspeto não se verificou. Para além de processar dados, esta aplicação trata também de gerar a página de resultados das duas aplicações, deixando então a camada de apresentação dividida entre as várias aplicações.

3.2.1.5 Access Monitor e Study Monitor

A aplicação Access Monitor consiste na versão anterior da aplicação Access Monitor Plus e está presente na figura 3.1 apenas para esclarecer a relação com as outras aplicações. Embora também tenha sido analisada, a análise teve menos detalhe pois esta aplicação não faz parte do conjunto de aplicações a serem trabalhadas.

Outro aspeto a ser mencionado é referente a aplicação Study Monitor. A aplicação Study Monitor não existe como aplicação separada. Ela existe como uma componente dentro da aplicação Access Monitor com o nome de Access Studies. Visto que não existe análise detalhada da aplicação Access Monitor, também não existe análise detalhada desta aplicação. Foram discutidos os requisitos da aplicação Access Studies com o cliente de forma a ser implementada como uma aplicação separada, que recebeu o nome de Study Monitor.

3.2.2 Examinator

O Examinator é o avaliador automático de acessibilidade presente nas aplicações acima referidas e tem como função avaliar o nível de acessibilidade do código HTML recebido. O avaliador baseia-se nas regras do WCAG para gerar o relatório de acessibilidade. No entanto, nem todas as regras estão implementadas fazendo com que este relatório fique incompleto.

As regras do WCAG são compostas por vários success criteria (SC) que, por sua vez, possuem várias técnicas para garantir a conformidade. Esta versão do Examinator apenas avalia técnicas do WCAG 2.0 das seguintes categorias: General, HTML, CSS, Client-side scriptinge Failure. As técnicas implementadas podem ser vistas na tabela 3.1. No total existem 14 técnicas G, 24 H, 6 C, 1 SCR e 20 F, somando um total de 65 técnicas

(45)

Tabela 3.1: Técnicas testadas pelo Examinator da aplicação AML

General (G) HTML e XHTML (H) CSS (C) Client-side scripting (SCR) Failure (F)

G1 H2 C9 SCR20 F4 G88 H24 C12 - F16 G90 H25 C19 - F17 G102 H27 C21 - F24 G115 H32 C22 - F25 G123 H33 C24 - F30 G125 H35 - - F40 G130 H36 - - F41 G134 H37 - - F46 G140 H39 - - F47 G141 H43 - - F49 G145 H44 - - F52 G146 H45 - - F54 G162 H46 - - F55 - H48 - - F59 - H52 - - F65 - H57 - - F77 - H59 - - F84 - H63 - - F88 - H64 - - F89 - H65 - - -- H71 - - -- H73 - - -- H88 - -

(46)

-Capítulo 3. Análise 28

3.2.3 Estrutura de dados do Examinator

O Examinator ao executar a avaliação de uma página devolve uma estrutura de dados com os seguintes campos:

• title: Título da página, caso exista;

• score: Pontuação (entre 1 e 10) do grau de acessibilidade;

• rawUrl: URL inserido para avaliar;

• tot: Informação total da avaliação. Este campo contém todos os dados da avaliação;

• nodes: Caminhos para os elementos que deram erro por cada teste efetuado;

• conform: Número de erros por nível de conformidade (A, AA e AAA), representado no formato A@AA@AAA;

• elems: Número de elementos com erros por teste feito;

• date: Data da avaliação.

O campo tot apresentado acima contém os resultados completos da avaliação à exceção do campo nodes, sendo alguns desses dados repetidos pela estrutura apresentada. Esses dados são:

• info

– url: Url da página avaliada; – hash: Hash da avaliação;

– encoding: Codificação da página (exemplo: UTF-8);

– content: Tipo de conteúdo da página (exemplo: “text/html”); – size: Tamanho em bytes da página;

– date: Data da avaliação;

– htmlTags: Número de tags HTML da página; – lang: Linguagem da página caso haja;

– title: Título da página caso haja; – cssRules: Número de regras CSS;

– score: Pontuação de acessibilidade da página; – tests: Número de testes feitos;