Desenvolvimento Web com o Uso de Padrões: Tecnologias e Tendências

Transcrição

1 Desenvolvimento Web com o Uso de Padrões: Tecnologias e Tendências Renata Tibiriçá dos Reis Universidade Federal de Juiz de Fora Instituto de Ciências Exatas Departamento de Ciência da Computação Bacharelado em Ciência da Computação Orientador: Prof. Tarcísio de Souza Lima Juiz de Fora, MG Julho de 2007

2 Desenvolvimento Web com o Uso de Padrões: Tecnologias e Tendências Renata Tibiriçá dos Reis Monografia submetida ao corpo docente do Departamento de Ciência da Computação do Instituto de Ciências Exatas da Universidade Federal de Juiz de Fora, como parte integrante dos requisitos necessários para a obtenção do grau de Bacharel em Ciência da Computação. Aprovada pela banca constituída pelos seguintes professores: Prof. Tarcísio de Souza Lima orientador MSc. em Informática, PUC/RJ, 1988 Profa. Jesuliana Nascimento Ulysses MSc. em Computação, UFF, 2003 Prof. Leandro Neumann Ciuffo MSc. em Computação, UFF, 2005 Juiz de Fora, MG Julho de 2007

3 Agradecimentos A Deus, Porque dele e por Ele, e para Ele são todas coisas. À Ele a glória. Pra sempre. Amém. - i -

4 Sumário Lista de Reduções... iii Lista de Figuras... iv Lista de Tabelas... v Resumo... vi Capítulo 1 - Introdução O Consórcio e a Guerra dos Navegadores Mudança de paradigma Soluções com padrões Web Organização da monografia... 5 Capítulo 2 - Características dos Padrões Web Definição de padrões Web Por que utilizar padrões Web Dificuldades na utilização de padrões Web Tableless vs. Web Standards... 8 Capítulo 3 - Desenvolvimento com Padrões Web Estrutura, apresentação e comportamento Design e construção HTML semântico XHTML CSS Comportamento Padrões Web e os navegadores Capítulo 4 - Acessibilidade na Web Acessibilidade na Web: o que é Leis e diretrizes Componentes para a acessibilidade na Web A construção de uma Web acessível Avaliando a acessibilidade i -

5 Capítulo 5 Estudo de Caso Sobre o estudo de caso Os objetivos do desenvolvimento Projetando o conteúdo Apresentação visual Comportamento Avaliação dos resultados Capítulo 6 - Conclusão Referências Anexo A Diretrizes WCAG A1 A7 Anexo B Código-fonte da página inicial do protótipo da UFJF...B1 B7 Anexo C Código CSS referente à página inicial do protótipo da UFJF...C1 C8 Anexo D Código CSS para impressão referente à página inicial do protótipo da UFJF...D1 D3 - ii -

6 Lista de Reduções CSS DOM DTD HTML HTTP IE MWI RDF SVG SMIL URL W3C WAI WaSP WWW WYSIWYG XHTML XML Cascading Style Sheets Document Object Model Document Type Definitions HyperText Markup Language HyperText Transfer Protocol Internet Explorer Mobile Web Initiative Resource Description Framework Scalable Vector Graphics Synchronized Multimedia Integration Language Uniform Resource Locator World Wide Web Consortium Web Accessibility Initiative Web Standards Project World Wide Web What You See Is What You Get Extensible HyperText Markup Language Extensible Markup Language - iii -

7 Lista de Figuras Figura 1.1 Exemplo de página com e sem CSS...4 Figura 1.2 Exemplo de código HTML usando padrões W3C...4 Figura 1.3 Exemplo de página com alterações no arquivo CSS...5 Figura 3.1 a Apresentação em todas as páginas HTML...10 Figura 3.1 b Apresentação em arquivos CSS separados...11 Figura 3.2 Exemplo de código CSS externo...17 Figura 3.3 Diferentes tipos de mídias para CSS...17 Figura 4.1 Relacionamento dos componentes de desenvolvimento...23 Figura 4.2 O ciclo de implementação...23 Figura 5.1 Atual website da UFJF...27 Figura 5.2 Protótipo do novo portal da UFJF...28 Figura 5.3 Cabeçalho do documento XHTML...29 Figura 5.4 a Exemplo de uso de imagem no XHTML e subtítulo...30 Figura 5.4 b Exemplo de uso do método de Image-replacement...30 Figura 5.5 a Exemplo de estruturação de menus...30 Figura 5.5 b Exemplo de código CSS para menus...31 Figura 5.6 CSS externos para mídias screen e print...31 Figura 5.7 Visualização do portal através do CSS mídia print...32 Figura 5.8 Exemplo de chamada de scripts para biblioteca Greybox...33 Figura 5.9 Visualização do portal através do navegador textual Lynx...34 Figura 5.10 Exemplo de hack CSS para o atributo margin...34 Figura 5.11 Visualização do portal em navegador sem suporte à CSS iv -

8 Lista de Tabelas Tabela 1.1 Comparativo entre website tradicional e website de acordo com s padrões...3 Tabela 3.1 Suporte dos navegadores atuais aos padrões Web...19 Tabela 5.1 Comparativo de desempenho entre o website atual da UFJF e o novo portal v -

9 Resumo Padrões Web são um conjunto de normas, diretrizes, recomendações, notas, artigos, tutoriais e afins de caráter técnico, produzidos pelo World Wide Web Consortium (W3C) e destinados a orientar fabricantes, desenvolvedores e projetistas para o uso de práticas que possibilitem a criação de uma Web acessível a todos, independentemente dos dispositivos usados ou de suas necessidades especiais. Ao se falar sobre normas para a Web, tratam-se, na prática, de Linguagens Estruturais (HTML, XML e XHTML), Linguagens de apresentação (CSS e XSL), Modelos de objeto (DOM), Scripting (ECMAScript), dentre outras, e, estar em conformidade com os padrões é facilitar o acesso a usuários portadores de necessidades especiais, sejam quais elas forem. Desta forma, o presente trabalho possui como objetivo principal explicar as vantagens e razões práticas para que desenvolvedores Web estejam engajados na utilização destas normas, economizando tempo, dinheiro e proporcionando uma melhor experiência para o usuário. Palavras-Chave Padrões Web, Web Standards, W3C, Acessibilidade, Interoperabilidade. - vi -

10 Capítulo 1 Introdução A World Wide Web foi criada no início da década de 1990, por Tim Berners-Lee, para aperfeiçoar a comunicação no CERN (Centre European pour la Recherche Nucleaire). Berners-Lee criou o HTML (HyperText Markup Language), uma linguagem de marcação baseada na bem-sucedida SGML (Standard Generalized Markup Language), para formatar os documentos que seriam distribuídos em rede e também desenvolveu protocolos de comunicação para tornar viável seu novo sistema de informações em hipertexto (BERNERS-LEE, 1999). Como se tratavam de documentos formais, o HTML não tinha uma preocupação visual, sendo composto exclusivamente por informação. A marcação era utilizada para determinar o que significava cada elemento, sendo, por exemplo, um título de página definido entre elementos <title>, um cabeçalho entre elementos <h1> e números subseqüentes, um parágrafo entre <p> e assim por diante (ANDRADE, 2005). 1.1 O Consórcio e a Guerra dos Navegadores Em 1994, Tim Berners-Lee fundou o W3C (World Wide Web Consortium), uma organização destinada a desenvolver e padronizar tecnologias para a construção de websites, de forma que a comunicação continuasse sendo feita de uma forma compreensível. Porém, diante do problema de falta de suporte por parte dos navegadores, os desenvolvedores foram levados a não seguir os padrões W3C e sim o padrão de renderização do navegador dominante no mercado. Em meados de 1995, foi lançado o navegador Internet Explorer da Microsoft e iniciada a chamada Guerra dos Navegadores. Disposta a conquistar o mercado até então dominado pelo Netscape Navigator, a Microsoft embutiu o navegador em seu sistema operacional Windows e, a partir de então, novas versões de ambos foram lançadas a um ritmo acelerado. A inclusão de novas funcionalidades possuía maior prioridade do que a reparação de erros, acarretando a produção de navegadores instáveis, totalmente em desacordo com os padrões W3C e com enormes falhas de segurança (WIKIPEDIA, 2007). Além disso, os navegadores começaram a criar seus próprios padrões para interpretar o código HTML, obrigando os desenvolvedores web a fazer versões separadas para cada navegador ou, mais comumente, a privilegiar somente um dos programas

11 Em 1998, surgiu o WaSP (Web Standards Project) 1, um movimento para difundir os chamados Web Standards, ou Padrões Web. Este grupo ajudou a terminar com a guerra dos navegadores, persuadindo a Netscape, a Microsoft e outros fabricantes a oferecer suporte preciso e completo às especificações do W3C. Além dos fabricantes de navegadores, hoje o grupo também trabalha com os fabricantes de ferramentas de desenvolvimento, como a Macromedia, e com os proprietários e desenvolvedores de websites (ZELDMAN, 2003). 1.2 Mudança de Paradigma O desenvolvimento de um website de acordo com o método tradicional utilizado na década de 1990, segundo AWAMURA (2004), é uma extensão da mídia impressa, isto é, páginas desenvolvidas para parecerem perfeitas nos navegadores principais da época. Características comuns incluem: Leiautes baseados em tabelas; Camada de apresentação unida ao conteúdo; Código inválido, inacessível e semanticamente incorreto. A partir do surgimento do WaSP e do fim da Guerra dos Navegadores, o desenvolvimento de acordo com os padrões Web se tornou mais difundido. Ainda segundo AWAMURA (2004), utilizar Web Standards significa aceitar a Web como uma ampla ferramenta acessível por um grande número de usuários e uma variedade de aparelhos. Algumas características comuns que podem ser citadas são: Marcação semanticamente correta; Código válido; Código acessível (por humanos e máquinas); Uso de CSS (Cascading Style Sheets) para separação do conteúdo da apresentação (tabela 1.1). Outras características e vantagens de se utilizar os padrões Web serão melhor explicadas no capítulo 2 deste trabalho. 1 Disponível em:

12 Tabela Comparativo entre website tradicional e website de acordo com os padrões Website Tradicional Website em acordo com os Padrões Web Extensão da Mídia Impressa Leiautes baseados em Tabelas Camada de apresentação aninhada ao conteúdo Código inválido Código inacessível Código semanticamente incorreto Acessível por qualquer dispositivo Leiautes baseados em CSS CSS para separação do conteúdo da apresentação Código válido Código acessível (por humanos e máquinas) Marcação semanticamente correta 1.3 Soluções com Padrões Web Uma das principais vantagens do se utilizar os padrões Web para desenvolver um website é a facilidade de manutenção. Através de um único arquivo CSS, toda uma estrutura pode ser alterada sem a mudança de uma linha sequer de HTML. A seguir, é apresentado um exemplo de uma página visualizada sem formatação CSS, em que a acessibilidade se torna evidente, e o mesmo exemplo com a folha de estilo CSS (figura 1.1). Na figura 1.2, nota-se a clareza e a simplicidade da marcação HTML, contudo, sem perder a beleza no design, e, na figura 1.3, observa-se a facilidade de variação de estilo da mesma página, feita sem alteração alguma na marcação HTML, e sim de somente alguns atributos no CSS. Nos próximos capítulos serão abordadas todas as vantagens de se adequar um website aos padrões W3C, técnicas e exemplos práticos de utilização do mesmo

13 Figura 1.1 Exemplo de visualização de uma mesma página sem CSS e com CSS Figura 1.2 Clareza do código HTML ao se usar os padrões W3C - 4 -

14 Figura 1.3 Mesma página com pequenas alterações no arquivo CSS 1.4 Organização da monografia A presente monografia está dividida da seguinte forma: o capítulo 2 aborda a definição, as principais características, as diversas vantagens e as possíveis dificuldades encontradas ao se utilizar os padrões Web, além de fazer um comparativo entre os termos Tableless e Web Standards; o capítulo 3 trata formas de desenvolvimento e tecnologias para construção de websites acessíveis; o capítulo 4 descreve os conceitos, leis e diretrizes de acessibilidade, além de dicas de como tornar um website acessível; o capítulo 5 apresenta efetivamente a aplicação das técnicas descritas nos capítulos anteriores através do estudo de caso do protótipo do novo portal da Universidade Federal de Juiz de Fora; e, finalmente, o capítulo 6 conclui o presente trabalho e apresenta sugestões para trabalhos futuros

15 Capítulo 2 Características dos Padrões Web A idéia original da Web era a existência de um ambiente onde pessoas conseguissem trocar informações livremente, e que essas informações pudessem ser acessadas de diversos dispositivos. Os Padrões Web, ou Web Standards, segundo definição do W3C, são um conjunto de normas, diretrizes, recomendações, notas, artigos, tutoriais e afins, de caráter técnico, produzidos pelo World Wide Web Consortium e destinado a orientar fabricantes, desenvolvedores e projetistas para o uso de práticas que possibilitem a criação de uma web acessível a todos, independentemente dos dispositivos usados ou de suas necessidades especiais. Neste capítulo será apresentada a definição de padrões Web, suas diversas características, vantagens e dificuldades encontradas em sua adoção, além de fazer um paralelo entre os termos Tableless e Web Standards. 2.1 Definição de Padrões Web Quando se fala de normas para a Web, trata-se, na prática, de três componentes independentes: estrutura, apresentação e comportamento, ou ainda de linguagens estruturais (HTML, XML e XHTML), linguagens de apresentação (CSS), modelos de objeto (Document Object Model DOM) e scripting (ECMAScript 2 ), dentre outras. Segundo WYKE (2005), utilizar padrões para a Web é extremamente vantajoso, pois proporciona um maior controle sobre a página. Quando é dito que uma página é compatível com os padrões, significa que o documento consiste de HTML ou XHTML válido, utiliza CSS para leiaute, é bem-estruturado e semanticamente correto. Esses fatores podem garantir que o site seja acessado por qualquer dispositivo, seja ele móvel, tátil, desktop etc. Assim, segundo ZELDMAN (2003), sites construídos de acordo com estes padrões, custam menos, funcionam melhor e são acessíveis a mais pessoas e dispositivos não apenas nos navegadores, leitores de tela e dispositivos sem fio atuais, mas também nos de amanhã. 2 Versão padrão do JavaScript - 6 -

16 2.2 Por que utilizar Padrões Web O desenvolvimento tradicional de websites tem sido empregado com o objetivo de fazê-los parecerem perfeitos em alguns navegadores principais. Desenvolver nos padrões significa utilizar a Web como uma ampla ferramenta acessível por um grande número de usuários e uma variedade de dispositivos, além de diversos outros benefícios, como: Separação de conteúdo e apresentação, para tornar o código limpo e correto; Manutenção e desenvolvimento simplificados: usar HTML semântico e bemestruturado torna mais fácil a compreensão do código e reduz custos e trabalho desnecessário; Compatibilidade com as leis e diretrizes de acessibilidade sem comprometer a beleza, o desempenho ou a sofisticação; Adaptação simplificada: tornam-se funcionais em vários navegadores e plataformas, sem a dificuldade e a despesa de criar versões separadas, suportando dispositivos nãotradicionais - desde acessórios sem fio e telefones celulares, até leitores de Braille e de tela usados por usuários com deficiências físicas - apenas por vincular a um arquivo CSS diferente; Compatibilidade com versões futuras: sites projetados utilizando padrões definidos e código válido, reduzem o risco de novos navegadores serem incapazes de renderizar a codificação utilizada; Maior velocidade no carregamento da página: menos HTML resulta em arquivos de tamanho menor e download mais rápido, fazendo com que os navegadores modernos renderizem as páginas mais rapidamente; Melhor posicionamento em mecanismos de busca. 2.3 Dificuldades na utilização dos padrões Web Mesmo com todas as vantagens enumeradas, a adoção ampla do desenvolvimento baseado nos padrões encontra algumas dificuldades. Diferenças na implementação dos padrões por parte dos navegadores: apesar das recomendações do W3C terem sido criadas com o propósito de padronizar a - 7 -

17 codificação das páginas Web, os navegadores atuais não apresentam completo suporte a estes padrões e não conseguem implementar corretamente todas as recomendações do W3C. Este tópico será abordado com mais detalhes no item 3.2 deste trabalho. Popularidade dos editores visuais WYSIWYG: o termo WYSIWYG é o acrônimo de What You See Is What You Get ( O que você vê é o que você tem ) e refere-se a ferramentas de desenvolvimento que permitem desenvolver websites sem precisar ter conhecimento de tags HTML básicas, ao mesmo tempo em que permite visualizar o site com a mesma aparência que ele terá no navegador depois de pronto. Apesar de alguns destes editores visuais terem evoluído nestes últimos anos e oferecerem um desenvolvimento mais próximo aos padrões (como por exemplo, o software Macromedia/Adobe DreamWeaver, a partir da versão 8), o grande problema está na mentalidade criada com a utilização dos editores WYSIWYG. Estes editores geram comodidade nos desenvolvedores que criam o hábito de confiar apenas na ferramenta, contribuindo com códigos semanticamente incorretos em diversas páginas da internet. Dificuldades de aprendizado: a adoção dos padrões não costuma ser algo simples para desenvolvedores acostumados a leiautes em tabelas, pois envolve o domínio de uma nova linguagem (CSS) e uma mudança de mentalidade na forma de desenvolvimento que passa a ser baseado no conteúdo e não mais no visual. 2.4 Tableless vs Web Standards Em meados da década de 1990, os navegadores ainda não haviam implementado CSS. Desta forma, todo o posicionamento dos elementos e sua aparência eram controlados através de marcação (HTML) e apresentação (CSS) completamente aninhadas e técnicas de spacer (um gif transparente) para empurrar elementos e deixá-los em um local específico. Com o passar dos anos, praticamente todos os navegadores em uso já haviam implementado grande parte de CSS, porém os desenvolvedores continuaram a criar sites de acordo com o método antigo. Assim, surgiu o termo tableless (do inglês sem tabelas ), em oposição a esta visão de desenvolvimento que utiliza tabelas, e não CSS, para controlar o leiaute. Este nome se tornou muito popular no Brasil; no exterior é comumente utilizado o termo CSS Layout. Porém, torna-se importante ressaltar, que ambos não são sinônimos de seguir os padrões Web, isto é, um leiaute feito com CSS não é sinônimo de que o site que segue os padrões

18 Web Standards, segundo PEREIRA (2006), é um termo mais amplo, que se refere aos padrões Web como um todo e não somente às linguagens de marcação e CSS. Tal conceito envolve a utilização das diferentes tecnologias que constituem a Web, de forma que garanta a interoperabilidade da própria Web como um todo, englobando, portanto, um amplo conjunto de boas práticas para o desenvolvimento Web em diversas áreas, tais como linguagens de marcação (XML, HTML, XHTML), linguagens de apresentação (CSS), semântica (RDF), linguagens de comportamento (DOM), acessibilidade (WAI), protocolos (HTTP), mobile (MWI), dentre outras. Em suma, um site que segue os Web Standards preza pelos vários aspectos que o constitui e não somente o aspecto estrutural sobre usar <div> ou <table> para a estruturação das páginas, pois não utilizar tabelas para estruturação e usar algo do tipo <div class="titulo">titulo do artigo aqui</div> no lugar de alguma tag de título (<h1> ou <h2>, por exemplo) é tão contrário aos Web Standards quanto utilizar tabelas. No próximo capítulo serão apresentadas metodologias para o desenvolvimento de websites a partir dos padrões Web

19 Capítulo 3 Desenvolvimento com Padrões Web Neste capítulo será abordado como desenvolver aplicações com padrões Web para a construção de websites de forma a possibilitar economia de tempo e dinheiro para desenvolvedores e uma melhor experiência para os usuários. Também são discutidos alguns métodos, guias e melhores práticas que auxiliam a produzir sites de alta qualidade e acessíveis ao maior público possível. 3.1 Estrutura, apresentação e comportamento Quando se discute padrões Web, uma das características mais relevantes é a importância da separação entre estrutura, apresentação e comportamento, tornando o código limpo e semanticamente correto. Separar estrutura e apresentação não é muito comum nos projetos desenvolvidos no modo tradicional (Figura 3.1a), porém o ideal é que o HTML contenha apenas a estrutura e conteúdo, e o CSS controle inteiramente a apresentação (Figura 3.1b). Figura 3.1 a) Apresentação aninhada em todas as páginas HTML (AWAMURA, 2004) A estrutura engloba as partes principais do documento, a semântica e os elementos que ele contém. Uma linguagem de marcação (HTML ou XHTML, por exemplo) contém dados de texto formatados de acordo com seu significado estrutural: título, parágrafo, lista e assim por diante, além de também conter objetos embutidos, como imagens ou apresentações em Flash. A apresentação é onde são tratados os aspectos visuais de uma página que não podem ser considerados informação textual. As linguagens de apresentação (CSS1, CSS2 e, futuramente, CSS3) formatam a página Web, controlando a tipografia, o posicionamento, a cor, dentre outros. Na maioria dos casos, o CSS pode substituir os antigos leiautes de tabela HTML e elementos de fonte não-padronizados

20 Em relação ao comportamento, um modelo de objeto padrão (DOM) é recomendado pelo W3C e trabalha com CSS, (X)HTML e ECMAScript e permite a criação de comportamentos e efeitos sofisticados que funcionem através de várias plataformas e navegadores. O DOM pode ser entendido como uma organização hierárquica dos elementos de um documento XML e um conjunto de métodos para manipular estes elementos Design e Construção Figura 3.1 b) Apresentação em arquivos CSS separados para navegadores modernos, impressão e navegadores antigos (AWAMURA, 2004) Com a popularização da Web, criou-se a necessidade de tornar as páginas HTML visualmente mais atrativas ao usuário. Gifs de espaçamento, textos em movimento, animações, sons embutidos e efeitos utilizando JavaScript se tornaram comuns em inúmeros websites, aumentando ainda mais o ambiente despadronizado na World Wide Web. Segundo ZELDMAN (2003), 99,9% dos websites são obsoletos, pois, como foram construídos de acordo com este método tradicional, podem ser exibidos e funcionar de forma correta em navegadores antigos (Netscape 4 e Internet Explorer 5, por exemplo), mas, fora desses ambientes tolerantes a falhas, certamente apresentam diversos erros de apresentação e comportamento. À medida que os navegadores modernos evoluem, o desempenho destes websites continua a se deteriorar. Em navegadores menos comuns, como leitores de tela e palmtops, a maioria deles não funciona ou, na melhor das hipóteses, funciona com várias limitações. Um erro comum é a utilização de tabelas para estruturar o leiaute de uma página Web, que traz inúmeras desvantagens, tais como:

21 Excesso de elementos em detrimento do conteúdo real e conseqüente dificuldade de indexação pelos mecanismos de busca; Dificuldade de manutenção; Falta de acessibilidade para usuários com necessidades especiais; Conteúdo e apresentação completamente aninhados, deixando os arquivos do website desnecessariamente grandes e semanticamente incorretos. Desta forma, sendo HTML uma linguagem estrutural, ou seja, usada para estruturar textos através de elementos, a tag <table> deveria ser usada tão somente com a finalidade para a qual foi criada, isto é, exibir conteúdos tabulares. Como alternativa à forma de desenvolvimento baseado em tabelas, em meados de 2000, este novo método que foca o uso dos padrões do W3C, começou a ganhar força, sendo divulgado principalmente pelo WaSP e pelo W3C. Tal solução aborda a utilização dos padrões definidos pelo W3C, acessibilidade e universalidade, separação entre conteúdo, formatação e comportamento e engloba inúmeras vantagens, como já citado no capítulo 2 deste trabalho HTML Semântico Em geral, a semântica refere-se ao estudo do significado, em todos os sentidos do termo (WIKIPEDIA, 2007). Ou seja, consiste no estudo do significado das palavras e de sua relação de significação nos sinais lingüísticos. Relacionando com padrões Web, pode-se explicar o termo semântica como sendo o estudo dos sinais, aqui chamados tags, sua relação uns com os outros e sua aplicabilidade (PEREIRA, 2005). Escrever um código semanticamente correto é utilizar esses sinais (tags) para seu significado real, isto é, para o qual foram criados. Usar código semântico é outro item importante relacionado à separação entre estrutura e apresentação. Em um elemento HTML, o significado estrutural é adequado ao tipo de conteúdo; sendo assim, ao usar HTML semântico, as diferenças de significado ficarão evidentes a qualquer navegador ou mecanismo de busca. Segundo PEREIRA (2005), alguns erros comuns de semântica são: Utilização da tag <table> pra estruturar sites; Usar a tag <br /> para simular parágrafos ao invés da tag <p>; Usar qualquer outra tag que não sejam os headings (títulos), como h1, h2, h3 etc., para declarar títulos;

22 A utilização de qualquer outra tag para estruturar listas, em detrimento das tags <ul> (lista sem ordem) ou <ol> (lista ordenada) juntamente com a tag <li> (lista); A não utilização da tag <label> (rótulo) para declarar o nome do campo em formulários de inserção de dados; A utilização de elementos de estilização como <i> e <b>, ao invés de elementos de expressão como <em> e <strong> para texto enfático (itálico) e texto fortemente enfático (negrito), respectivamente. Embora ambos sejam renderizados pelos navegadores com forma de apresentação idênticas, <i> e <b> não tem qualquer efeito sobre tecnologias assistivas (leitores de tela, por exemplo) XHTML XHTML 1.0 é a reformulação do HTML 4 em XML 1.0, e foi desenvolvido para substituir o HTML (W3C, 2002). São citados pelo W3C alguns benefícios na utilização do XHTML: Por estar em conformidade com XML, pode ser lido, visualizado e editado com ferramentas para XML; Pode ser escrito para operar melhor que aplicações existentes em HTML 4; Foi concebido visando interoperabilidade com todo tipo de aplicações de usuários e não apenas softwares navegadores padrão; É compatível com navegadores para HTML 4 ou anteriores, caso sejam respeitadas as diretrizes de compatibilidade recomendadas pelo W3C; Buscando a interoperabilidade, o XHTML tem como foco principal a marcação apenas do conteúdo, contribuindo para a modularização no desenvolvimento das páginas; A escrita do XHTML é limpa por respeitar as regras do XML, não permitindo tags fora de ordem, por exemplo; O tempo de carregamento é mais rápido, pois os navegadores não têm que decidir sobre renderização de erros de código. Documentos XHTML começam com elementos que informam aos navegadores como interpretá-los e aos serviços de validação como testá-los. Um desses elementos é a declaração DOCTYPE (acrônimo de Document Type e também conhecido como DTD - Document Type Definition), que informa, em linguagem de máquina, a versão do XHTML usado

23 As declarações DOCTYPE são componentes-chave de websites compatíveis. A opção escolhida afeta a maneira como a maioria dos navegadores e serviços de validação exibe o site. O XHTML oferece três declarações de DOCTYPE possíveis (W3C, 2007a): Transitional: opção que está mais próxima do HTML. Utilizado por desenvolvedores que estão fazendo a transição para os padrões Web modernos e/ou que precisam manter atributos e elementos de apresentação unidos à estrutura. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " Strict: DTD que exclui atributos de apresentação e elementos que o W3C pretende remover à medida que o suporte à CSS evolui. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " Frameset: permite a utilização de frames. Não recomendado, uma vez que o uso de frames está em desuso. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" " Outras regras fundamentais presentes no XHTML são: A declaração DOCTYPE é imediatamente seguida por uma declaração de namespace XHTML que destaca o elemento <html> (indica a língua e a versão XML utilizadas no documento) : <html xmlns= xml:lang="pt-br" lang="pt-br"> O tipo de conteúdo do documento deve ser declarado usando a tag META Content: <meta http-equiv="content-type" content="text/html;charset=iso " /> As meta-tags descrevem o conteúdo da página Web para os buscadores e a autoria da mesma, e devem ser incluídas dentro do elemento <head>, após a tag META Content: <meta name="keywords" content="universidade, universidade federal, universidade federal de juiz de fora, juiz de fora, jf, web standards" /> <meta name="description" content="portal da Universidade Federal de Juiz de Fora" /> <meta name="author" content="renata Tibiriçá, Crystiam Pereira, Leandro Neumann, Tarcísio Lima " /> Todas as tags e atributos devem ser escritas em letras minúsculas;

24 Os elementos devem estar convenientemente aninhados. o Errado: <div><strong><p>texto</strong></p></div> o Correto: <div><strong><p>texto</p></strong></div> O uso de tags de fechamento é obrigatório. Elementos vazios devem ser fechados, como a tag <br />, por exemplo. Os valores de atributos devem sempre estar entre "aspas". Exemplo: <input checked="checked" /> Os documentos devem ser bem formados, isto é, devem estar estruturados de acordo com as regras definidas nas Recomendações para XML 1.0. Todos os elementos XHTML devem estar corretamente aninhados dentro do elemento raiz <html>. Codificar caracteres tais como menor (<), maior (>) e & (E comercial) para <, > e &, respectivamente. Para garantir que a marcação esteja correta, é sugerido validar os documentos XHTML. Validação é o processo de verificação de documentos comparando-os com um padrão formal, como os publicados pelo W3C. Um documento que foi checado e aprovado é considerado um documento válido. O W3C disponibiliza um validador gratuito, disponível em para tais documentos, onde um robô o analisa e fornece um relatório completo e detalhado das possíveis não conformidades existentes CSS As folhas de estilo CSS são definidas pelo W3C (1999a) como um mecanismo simples para acrescentar estilo a documentos Web, isto é, CSS é uma linguagem de leiaute padrão para a Web que controla cores, tipografia, tamanho e posicionamento de imagens. Semântica e boa estrutura do XHTML são necessárias para o CSS ser capaz de controlar o leiaute de uma maneira eficiente. Segundo MEYER (2001), as folhas de estilo permitem a especificação do estilo dos elementos da página (espaçamento, margens etc.) separadamente da estrutura do documento (cabeçalhos de seção, corpo de texto, links etc.) e podem ser incluídas ao documento XHTML de quatro formas: CSS Inline: declarações aplicadas a um elemento individual através do atributo style. <div style="background:#fff; color:#000;">exemplo</div>

25 CSS Incorporado: declarações embutidas no conteúdo através do elemento style no cabeçalho (<head>) de um documento XHTML; <head> <style type="text/css"> <!-- div { background: #FFF; color: #000; --> </style> </head> CSS Externo: as declarações são colocadas em um arquivo externo com a extensão.css e incluídos em um ou vários documentos através do elemento <link>. As alterações no arquivo CSS afetam a todos os documentos que referenciarem este arquivo como folha de estilo (Figura 3.2); <head> <link rel="stylesheet" href="estilo_externo.css" type="text/css" /> </head> CSS Importado: as declarações também são chamadas a partir de um arquivo CSS externo, porém, não através do elemento link, mas sim da Esta importação não é bem aceita por navegadores antigos. <style type="text=css"> url(estilo_importado.css); --> </style> Declarações inline e embutidas devem ser evitadas ao máximo, pois retiram as vantagens da flexibilidade do CSS e da separação entre conteúdo e apresentação. Sendo assim, é recomendado que a apresentação visual seja definida via arquivos externos, facilitando a manutenção nas páginas, como já citado anteriormente, além de possibilitar a utilização do mecanismo de cache do navegador, não sendo necessário que sejam requisitadas informações visuais pela rede toda vez que uma página é carregada

26 Figura 3.2 Exemplo de código CSS Externo Através dos CSS media types (figura 3.3) é permitido que seja definido o tipo de mídia onde as regras de formatação serão aplicadas. Assim, é possível fazer estilos específicos para navegadores padrão (mídia screen), para dispositivos com tela pequena como celulares e PDAs (mídia handheld), para impressão (mídia print), para projetos de apresentações estilo PowerPoint (mídia projection), para sintetizadores de tela (mídia aural), para dispositivos táteis (mídia braille), para Web TVs (mídia tv), dentre outros (W3C, 2007b). <link rel="stylesheet" href="nav.css" type="text/css" media="screen" /> <link rel="stylesheet" href="print.css" type="text/css" media="print" /> <link rel="stylesheet" href="handheld.css" type="text/css" media="handheld" /> Figura 3.3 Diferentes tipos de mídias para CSS

27 A partir das diversas características citadas e sendo bem utilizada, a CSS proporciona inúmeros benefícios práticos, como por exemplo: Conservação da largura de banda do usuário, acelerando os tempos de carga da página, especialmente através de uma conexão discada; Redução da sobrecarga do servidor e da largura de banda do proprietário, assim economizando dinheiro; Redução do tempo de design e desenvolvimento; Aumento da interoperabilidade aderindo aos padrões Web; Aumento da acessibilidade removendo alguns, vários ou todos os elementos de apresentação da marcação Comportamento Para padronizar o acesso aos elementos de um documento XML, o W3C criou o DOM, uma interface independente de navegador e plataforma, que permite que programas e scripts acessem e atualizem dinamicamente o conteúdo, a estrutura e o estilo de documentos (HÉGARET, 2005). Apesar de existirem outras linguagens, o W3C recomenda que aspectos de tratamento de eventos e ações automáticas devem ser incluídas em uma página Web através da linguagem JavaScript. O JavaScript é utilizado para ampliar as funcionalidades e facilidades de uma página Web. De forma a seguir o princípio de separação entre conteúdo, apresentação e comportamento e manter a acessibilidade e usabilidade, devem ser observados alguns aspectos na inclusão de scripts em página Web: O JavaScript deve ser tratado como um incremento, não como uma funcionalidade segura. Evitar incluir JavaScript diretamente nas tags do documento XHTML, o mantendo separado em arquivos externos a serem referenciados pela página (scripts nãoobstrutivos). Os principais problemas durante a inserção de scripts em páginas Web costumam vir das diferenças existentes entre os diversos navegadores, principalmente com relação à interpretação correta do modelo DOM. Com a aceitação cada vez maior dos padrões Web, espera-se que estas diferenças reduzam com o passar do tempo

28 3.2 Padrões Web e os navegadores O suporte dos navegadores aos padrões Web sofreu um grande avanço com o fim da Guerra dos Navegadores, apesar de nem todos em uso atualmente possuírem o nível de suporte necessário à CSS para renderizar um site que utilize todos os recursos do mesmo. Atualmente, os navegadores que tem melhor suporte ao CSS são Firefox (e outros baseados em Gecko, como Mozilla, Camino, Netscape6+), Opera e Safari (e outros baseados em WebCore). Na tabela 3.1 são apresentadas estatísticas resumidas do suporte dos navegadores aos padrões HTML, XHTML, CSS, DOM e ECMAScript ( S indica suporte completo ao padrão). A tabela completa pode ser encontrada em (HAMMOND, 2007). Apesar do crescimento visível do suporte por parte dos fabricantes de navegadores, ainda há grande deficiência dos principais navegadores, como, por exemplo, o Internet Explorer, e muito ainda é necessário para a implementação correta de todas as recomendações do W3C. Tabela Suporte dos navegadores atuais aos padrões Web Suporte aos padrões Web Tecnologia IE 6 IE 7 Firefox 2 Opera 9 HTML/XHTML 73% 73% 90% 85% CSS % 56% 91% 94% CSS 3 changes 10% 13% 24% 19% DOM 50% 51% 79% 84% ECMAScript 99% 99% S S No próximo capítulo serão abordados o conceito de acessibilidade na Web, seus componentes, leis e diretrizes, além de dicas e boas práticas sobre como utilizar os padrões Web para tornar uma página acessível

29 Capítulo 4 Acessibilidade na Web A Web exerce um papel crescentemente importante nas áreas de educação, negócios, comércio, governos e recreação. Uma Web acessível e que permita a participação de pessoas portadoras de necessidades especiais na sociedade é fundamental para proporcionar oportunidades iguais para todos nas diversas áreas. Atualmente, o acesso à Internet se dá de maneira precária, pois além da falta de navegadores apropriados, a forma como as páginas são desenvolvidas torna-se uma grande barreira, que muitas vezes impossibilita a interação do deficiente com as informações e os serviços disponíveis na Web. Neste capítulo serão abordados conceitos de acessibilidade na Web, dicas de como utilizar os padrões Web para tornar uma página acessível, além de leis e diretrizes que focam a acessibilidade na Web. 4.1 Acessibilidade na Web: o que é Acessibilidade significa qualidade de ser acessível ou facilidade de interação. Quando focada em tecnologia, tem o objetivo de tornar os computadores e a Web mais acessíveis para portadores de necessidades especiais. Acessibilidade na Web, segundo o W3C (2005), significa uma Web projetada de modo que pessoas portadoras de necessidades especiais possam perceber, entender, navegar e interagir de uma maneira efetiva com a Web, bem como criar e contribuir com conteúdos para a Web. Existem milhões de pessoas portadoras de necessidades especiais que têm o seu acesso a Web restrito. Atualmente, a maioria dos websites possui barreiras de acessibilidade que dificultam, ou mesmo torna impossível, para estas pessoas acessá-los. Contudo, se os websites e os diversos agentes de usuário forem projetados de forma acessível, estas pessoas poderão usá-los efetivamente. Ainda segundo o W3C (2005), a acessibilidade na Web contempla todo tipo de necessidade especial, sejam elas: Deficiências visuais, físicas, auditivas, de fala, cognitivas e neurológicas; Usuários impossibilitados de usar o mouse ou o teclado; Usuários com dificuldades de leitura e interpretação de textos;

30 Navegadores antigos; Navegadores sem suporte a cor; Navegadores de texto; Conexões lentas; Diversidade de sistemas operacionais; Dispositivos de navegação portáteis; Navegadores sem suporte a CSS ou scripts, ou com estes recursos desabilitados; Dispositivos de navegação com limitações de memória e/ou processamento; Diversidade de resoluções de tela. Além disso, os mecanismos de busca são, na verdade, usuários cegos. O Google 3, por exemplo, utiliza um algoritmo que interpreta as páginas Web utilizando diversos critérios, dentre eles destacam-se as técnicas de acessibilidade bem aplicadas, somadas a um código semanticamente correto. Assim, desenvolver um site acessível o torna mais compreensível não só para deficientes visuais, mas também para mecanismos de indexação. 4.2 Leis e diretrizes Segundo ZELDMAN (2003), acessibilidade e padrões têm muita coisa em comum, pois ambos asseguram que o trabalho será útil e disponível ao maior número possível de usuários, seja qual for a necessidade. A acessibilidade está tão vinculada aos padrões Web, que nos anos 1990, o W3C iniciou o chamado WAI (Web Accessibility Initiative) para ajudar os construtores Web em estratégias para alcançar a acessibilidade e que atualmente é considerado um padrão internacional. A WAI aborda dois eixos: assegurar uma transformação harmoniosa e tornar o conteúdo compreensível e navegável, além de oferecer três níveis de prioridade com base no respectivo impacto em termos de acessibilidade, sendo eles (W3C, 1999b): Prioridade 1: pontos que os criadores de conteúdo Web devem absolutamente satisfazer para evitar que usuários fiquem impossibilitados de compreender as informações contidas na página ou site. Prioridade 2: pontos que os criadores de conteúdo para a Web deveriam satisfazer para evitar que os usuários tenham dificuldade de acessar as informações contidas no documento, evitando barreiras significativas a documentos publicados na Web. 3 Disponível em:

31 Prioridade 3: pontos que os criadores de conteúdo na Web podem satisfazer para melhorar o acesso às informações disponibilizadas nas páginas. Na verificação da acessibilidade de um documento são estabelecidos os níveis de conformidade para as páginas Web: Nível de conformidade A : quando satisfeitos todos os pontos de verificação de prioridade 1; Nível de conformidade Duplo A : quando satisfeitos todos os pontos de verificação de prioridade 1 e 2; Nível de conformidade Triplo A : quando satisfeitos todos os pontos de verificação de prioridade 1, 2 e 3. Muitas nações têm leis proibindo a negação de acesso às pessoas portadoras de deficiência ou com mobilidade reduzida, e muitas já aplicaram tais leis à nova mídia por meio de decretos de acessibilidade na Web, como o U.S. Section 508, nos Estados Unidos, e a Lei Federal de Acessibilidade (Lei no , de 19 de dezembro de 2000), no Brasil. Algumas dessas leis nacionais obedecem à Prioridade 1 da WAI. 4.3 Componentes para a acessibilidade na Web A acessibilidade na Web depende do relacionamento entre diferentes componentes, e o aperfeiçoamento de componentes específicos pode melhorá-la substancialmente. É essencial que diferentes componentes do desenvolvimento e da interação Web se relacionem entre si com o objetivo de tornar a Web acessível às pessoas portadoras de necessidades especiais (Figura 4.1). Estes componentes abrangem: Conteúdo: informação contida em uma página ou aplicação Web (textos, imagens e sons); Código ou marcação que define estrutura, apresentação etc; Navegadores Web e agentes de usuário em geral; Tecnologias assistivas; Usuários, conhecimento, experiência e em alguns casos estratégias adaptadas para uso da Web; Desenvolvedores; Ferramentas de criação; Ferramentas de aperfeiçoamento da acessibilidade à Web, validadores de HTML e CSS etc

32 Figura 4.1 Relacionamento dos componentes de desenvolvimento (HENRY, 2005) Ao se implementar efetivamente as facilidades de acessibilidade em um componente, a implementação nos demais se torna mais evidente, formando, assim, um ciclo, onde agentes de usuários, ferramentas de criação, desenvolvedores e usuários são motivados a utilizar e/ou oferecer maior acessibilidade (Figura 4.2). O W3C-WAI desenvolve guias e diretrizes para os diferentes componentes citados: Diretrizes de acessibilidade para ferramentas de criação ATAG (Authoring Tool Accessibility Guidelines): possui como foco principal definir como as ferramentas ajudarão os programadores a produzirem suas aplicações Web contendo as diretrizes de acessibilidade; Figura 4.2 O ciclo de implementação (HENRY, 2006)

33 Diretrizes de Acessibilidade ao Conteúdo da Web WCAG (Web Content Accessibility Guidelines): explicam como produzir conteúdos para a Web que sejam acessíveis às pessoas portadoras de necessidades especiais. O WCAG 1.0 aborda quatorze diretrizes sobre questões de acessibilidade na Web, detalhando os pontos de verificação com as respectivas prioridades, apresentando soluções para projetos acessíveis. Estas quatorze diretrizes podem ser encontradas no anexo A deste trabalho. Uma nova documentação do WCAG, a WCAG 2.0, sofreu duras críticas por meio de alguns importantes desenvolvedores, sendo tachada de simplesmente impossível de se aplicar no mundo real, segundo Joe Clark 4. Diretrizes de acessibilidade para agentes do usuário UAAG (User Agent Accessibility Guidelines): explicam como produzir agentes de usuário acessíveis para pessoas portadoras de necessidades especiais e aumentar a acessibilidade no conteúdo Web; As diretrizes WAI baseiam-se em especificações técnicas fundamentais para a Web e são desenvolvidas em coordenação com as especificações técnicas do W3C (HTML, XML, CSS, SVG, SMIL etc.). 4.4 A construção de uma Web acessível A instrução para deixar uma página Web relevante é saber conceder significado para a informação. Algumas dicas são (W3C, 2001): Imagens: o Sempre utilizar conteúdo alternativo através do atributo alt. Este atributo especifica o texto alternativo que é apresentado quando a imagem não pode ser exibida, conferindo significado à mesma, e permitindo que leitores de tela e mecanismos de busca a identifique. <img src="exemplo.gif" alt="este é um exemplo"> o Para imagens sem significado, utilizar alt= (null alt), ou preferencialmente, colocar por CSS, principalmente imagens pertencentes à estrutura do leiaute. <img src="img_topo.gif" alt=""> 4 Colunista da revista A List A Part. Disponível em:

34 Links textuais: o Alguns mecanismos de busca têm os links como o fator mais importante em seus robôs de indexação. Utilizar links textuais juntamente com o atributo title, pode conceder melhor significado para mecanismos como o Google e para os usuários. <a href="link.htm" title="descrição do Link" >Link</a> Formulários: o Garantir sempre a identificação dos campos dos formulários, através do elemento <label>; <label for="nome">nome: </label><input type="text" name="nome"> Plug-ins, Recursos em Flash e Multimídia: o Onde for necessário um plug-in, deve-se incluir um link para o item requerido. o Incluir legendas e transcrições para áudio, e descrições para vídeos. CSS desabilitado: o Sempre testar as páginas com e sem folhas de estilo para garantir que elas sejam legíveis de qualquer forma. Testar em vários navegadores: o Sempre utilizar CSS válida 5 e testar em diversos navegadores. CSS mal escrita poderá tornar uma página ilegível. Scripts: o Codificar de maneira a garantir que os links funcionem mesmo quando o JavaScript estiver desabilitado. Tabelas: o Como mencionado no capítulo 3 deste trabalho, deve-se substituir as antigas estruturações de leiaute em tabela e gifs espaçadores por leiautes CSS. o Em tabelas para dados, é necessário identificar os cabeçalhos da tabela e usar marcações apropriadas para associar células de dados e células de cabeçalhos que possuem dois ou mais níveis lógicos de linha e coluna. 5 XHTML e CSS podem ser validados em e respectivamente

35 4.5 Avaliando a acessibilidade A validação da acessibilidade pode ser feita por meio de ferramentas automáticas e da revisão direta. Os métodos automáticos são geralmente rápidos, mas não são capazes de identificar todas as diversificações da acessibilidade. A avaliação humana pode ajudar a garantir a clareza da linguagem e a facilidade da navegação. Validadores de acessibilidade como o Cynthia Says 6, Watchfire s Bobby 7 ou DaSilva 8 não ajudam a dar significado ao conteúdo de um website, mas sim a verificar se houve ou não algum erro de sintaxe na codificação. A avaliação e validação da acessibilidade de uma página ou de um site à Web deve estar presente desde as fases iniciais do desenvolvimento do documento. A equipe de pesquisa da W3C-WAI (1999b), aponta como método para validação de uma página os seguintes pontos de verificação: 1. Utilização de uma ferramenta de acessibilidade automática e ferramentas de validação de navegadores. 2. Validação da sintaxe (HTML, XML etc.). 3. Validação das folhas de estilo. 4. Utilização de um navegador somente texto ou emulador. 5. Utilização de vários navegadores gráficos com: som e gráficos ativos, sem gráficos, sem mouse, sem carregar frames, programas interpretáveis, folhas de estilo ou applets. 6. Utilização de vários navegadores, antigos e recentes. 7. Utilização de um navegador de emissão automática de fala, com leitores de tela, com software de ampliação, monitores monocromáticos etc. 8. Utilização de corretores ortográficos e gramaticais, com o intuito de aumentar o grau de compreensão. 9. Revisão do documento, verificando a clareza e a simplicidade. 10. Validação das páginas com usuários reais. As regras de desenvolvimento com padrões e acessibilidade serão mais efetivamente abordadas no próximo capítulo, através do estudo de caso do protótipo do Portal da Universidade Federal de Juiz de Fora MG. 6 Disponível em: 7 Disponível em: 8 Disponível em:

36 Capítulo 5 Estudo de Caso Neste capítulo serão apresentadas efetivamente as aplicações das técnicas de padrões Web e acessibilidade descritas nos capítulos anteriores deste trabalho, através do desenvolvimento do protótipo do Portal da Universidade Federal de Juiz de Fora MG. Também será feita uma comparação entre o website atual 9 (figura 5.1) e o estudo de caso, com ênfase nas vantagens do uso dos padrões W3C. 5.1 Sobre o estudo de caso O estudo de caso descrito teve como objetivo tornar o portal da UFJF não somente mais acessível e vantajoso a todo tipo de usuário, como também mais interativo com o mesmo. Figura 5.1 Atual website da UFJF Embora o design do protótipo esteja seguindo uma linha tradicional de portais institucionais, ou seja, não possua nenhum efeito especial em seu leiaute, os métodos de construção são de extrema importância, pois possibilitam uma melhor experiência ao usuário, quer ele possua, ou não, alguma necessidade especial de acesso (figura 5.2). 9 Disponível em:

37 Figura 5.2 Protótipo do novo portal da UFJF 5.2 Os objetivos do desenvolvimento Focando o desenvolvimento do protótipo do portal no tema deste trabalho, foram listados alguns objetivos principais a serem atingidos: Conteúdo, funções básicas e leiaute devem estar disponíveis para qualquer navegador (IE, Opera, Firefox, entre outros) ou dispositivo (leitores de tela, por exemplo); As marcações devem ser validadas em relação às especificações da XHTML 1.0 Transitional 10 e devem evitar elementos de apresentação, isto é, estrutura e apresentação deverão estar separadas e o XHML deve ser semântico; As folhas de estilo CSS devem ser validadas 11, compactas e logicamente organizadas da melhor forma possível; O website deve ser uniformemente acessível; Para isso, o protótipo será testado em relação à WCAG 1.0 Prioridades 1 e 2, no validador DaSilva 12 ; 10 Disponível em: 11 Disponível em:

38 O website deverá apresentar uma aparência leve e amigável, sem desperdiçar visitantes e largura de banda em marcações grandes, scripts complexos ou imagens desnecessárias. Assim, definidos os objetivos, serão descritas as etapas de desenvolvimento do projeto. 5.3 Projetando o conteúdo O início do desenvolvimento foi feito pela camada de conteúdo, em que o XHTML foi planejado de forma a dar significado e estruturação ao mesmo, permitindo que ele seja visível mesmo em navegadores ou dispositivos sem suporte à CSS. Desta forma, foi definido o cabeçalho do documento, contendo o doctype a ser utilizado, o título e as meta-tags (figura 5.3). Figura 5.3 Cabeçalho do documento Em seguida, divide-se a estrutura do conteúdo em blocos de significância, tais como topo, menu, barra de busca e tempo, barra de acesso aos hotsites da instituição, conteúdo central divido entre coluna de notícias e coluna de destaques e editais - e rodapé (consulte o anexo B para visualizar o código completo da página inicial do protótipo). Durante a estruturação destes elementos, alguns princípios foram seguidos para que não se perdesse a semântica do conteúdo: Imagens relevantes no conteúdo foram colocadas no XHTML através da tag <img> (figura 5.4 a); Imagens que fazem parte da estrutura visual do website foram chamadas via CSS, através da técnica conhecida como Image-replacement 13 (figura 5.4 b); Os títulos e subtítulos presentes foram definidos a partir das tags <h1>, <h2> etc (figura 5.4 a); 12 Disponível em: 13 Termo utilizado para designar a técnica CSS de escrever um texto usando uma imagem

39 Figura 5.4 a) Imagem através do XHTML para um ícone do portal e subtítulo utilizando a tag <h4> Figura 5.4 b) Imagem via CSS, através do método de Image-Replacement Os menus foram estruturados utilizando listas (figura 5.5 a e b), para uma maior clareza no código e facilidade de leitura por dispositivos diferenciados, como leitores de tela e navegadores sem suporte à CSS, por exemplo. A partir disso, já é possível observar as diversas vantagens encontradas com a utilização dos padrões Web, tais como código menor, mais claro e semântico, facilidade de manutenção, melhor posicionamento em mecanismos de busca, maior velocidade no carregamento das páginas, dentre outras. Figura 5.5 a) Estrutura do menu (XHTML)

40 Figura 5.5 b) Apresentação do menu (CSS) 5.4 Apresentação visual A apresentação visual, como já mencionado anteriormente, é desenvolvida utilizando exclusivamente folhas de estilo CSS. Neste protótipo, a CSS utilizada é externa, conforme recomendado no capítulo 3 deste trabalho. Nela foi definida a estrutura do leiaute (dividido em barra institucional do governo, topo, centro com 3 colunas - menu, notícias e barra de hotlinks e rodapé), os posicionamentos (margens, espaçamentos e alinhamentos), a estilização do texto (como fontes, cores, tamanhos, links), além do estilo do painel rotativo de notícias. Procurando tornar a página acessível a diversos dispositivos, foram definidos dois CSS media types (figura 5.6): Screen: para navegadores comuns; Print: para impressão (figura 5.7); Figura 5.6 CSS externo para as mídias screen e print

41 Em cada folha de estilo, foram definidas regras gerais, regras específicas para cada tipo de elemento, regras para elementos com identificação definida (id) e regras comuns através de classes (os arquivos CSS completos estão disponíveis nos anexos C e D). Figura 5.7 Visualização do portal através da CSS mídia print 5.5 Comportamento Como o principal objetivo do desenvolvimento deste portal foi tornar o website da UFJF mais interativo, foi desenvolvido um módulo de avaliação do protótipo, para que profissionais de diferentes áreas pudessem fazer testes, comentar e retornar resultados sobre o mesmo. Para possibilitar esta interação sem perder a acessibilidade e a usabilidade, foi utilizada uma biblioteca em JavaScript chamada Greybox 14, extremamente leve e que utiliza CSS e JavaScript não-obstrutivo. A ligação da biblioteca Greybox com o documento XHTML é feita adicionandose uma chamada a uma nova folha de estilo externa e a tags <script> no cabeçalho do documento (figura 5.8). 14 Disponível em:

42 Figura 5.8 Chamada dos scripts para a biblioteca Greybox 5.6 Avaliação dos resultados Durante o período de desenvolvimento do portal, foram executados testes de resolução de tela (800x600 e 1024x768 pixels) e de compatibilidade com os quatro navegadores principais do mercado (Mozilla Firefox 1.5 e 2.0, Internet Explorer 6 e 7, Safari 3 e Opera 9) e, após o término do desenvolvimento, foram feitos testes de validação de marcação, CSS e acessibilidade, testes de visualização em navegadores sem suporte à CSS e em navegadores textuais, e, por fim, uma comparação de desempenho entre o website atual da instituição e o portal desenvolvido de acordo com os padrões W3C foi realizada. Em relação aos testes de resolução de tela, o padrão definido foi o de 800x600 pixels, sendo que, desta forma, a barra de rolagem horizontal não é exibida, devido ao fato de ter sido adotado como largura padrão do leiaute o tamanho de 780 pixels. Nos testes para diversos navegadores, poucas diferenças foram apresentadas, apesar de, durante o desenvolvimento, problemas de posicionamento com a barra que contém a previsão do tempo terem ocorrido no Internet Explorer 6. Para que o problema fosse resolvido, mudanças no projeto original de leiaute tiveram que ser feitas. No teste para navegadores textuais, o navegador utilizado foi o Lynx Nota-se através da figura 5.9 que a organização da página foi mantida, com todas as suas seções e imagens indicadas de forma acessível, assim como nos testes de visualização sem suporte à CSS (figura 5.11). É interessante observar que testes em navegadores sem suporte à CSS simulam como softwares leitores de tela lêem um website para um deficiente visual, por exemplo. 15 Disponível em:

43 Figura 5.9 Visualização da página através do navegador textual Lynx Em seguida, o portal foi submetido a três testes de validação: marcação (XHTML), CSS e acessibilidade, sendo obtidos os resultados abaixo: Validação de Marcação: o validador do W3C retornou a página como Valid XHTML 1.0 Transitional, isto é, o documento não contém erros de estrutura de acordo com o tipo proposto e está em conformidade com os padrões W3C. Validação de CSS: de acordo com o serviço de validação de CSS do W3C, foram retornados 3 erros. Tais erros somente ocorreram devido à presença de hacks 16 no arquivo CSS para que a estrutura da página funcionasse corretamente no IE 6 (figura 5.10). Validação de acessibilidade: segundo o validador desktop DaSilva, o protótipo do portal está em conformidade com as prioridades 1 e 2 da WCAG. Figura 5.10 Hack CSS para o atributo margin 16 Hacks: formas de contornar problemas de renderização de CSS existentes nas versões 5, 5.5 e 6 do Internet Explorer