Monografia Acessibilidade na Web - Valério Farias

UNIVERSIDADE DO ESTADO DO RIO GRANDE DO NORTE FACULDADE DE CIÊNCIAS EXATAS E NATURAIS DEPARTAMENTO DE INFORMÁTICA CURSO DE ESPECIALIZAÇÃO EM INFORMÁTICA APLICADA ACESSIBILIDADE NA WEB: UM ESTUDO DE CASO NO PORTAL UERN VALÉRIO FARIAS DE CARVALHO MOSSORÓ – RN 2008

VALÉRIO FARIAS DE CARVALHO ACESSIBILIDADE NA WEB: UM ESTUDO DE CASO NO PORTAL UERN Monografia apresentada ao Departamento de Informática da Faculdade de Ciências Exatas e Naturais da Universidade do Estado do Rio Grande do Norte, como parte dos requisitos para conclusão do Curso de Especialização em Informática Aplicada. Orientador: Prof. Dr. Idalmir de Souza Queiroz Júnior. MOSSORÓ-RN 2008

Catalogação da Publicação na Fonte Carvalho, Valério Farias de. Acessibilidade na Web: um estudo de caso no portal UERN. / Valério Farias de Carvalho. - Mossoró, RN, 2008. 39 f. Orientador: Prof. Dr. Idalmir de Souza Queiroz Junior. Monografia (Especialização em Informática Aplicada). Universidade do Estado do Rio Grande do Norte. Faculdade de Ciências Exatas e Naturais. 1. Web - Acessibilidade - Monografia. 2. Padrões Web - Monografia. 3. Arquitetura da informação - Monografia. I. Queiroz Junior, Idalmir de Souza. II. Universidade do Estado do Rio Grande do Norte. III. Título. UERN/ BC CDD 004.6 Bibliotecária: Jocelania Marinho Maia de Oliveira CRB 4 / 1303

VALÉRIO FARIAS DE CARVALHO ACESSIBILIDADE NA WEB: UM ESTUDO DE CASO NO PORTAL UERN Monografia apresentada ao Departamento de Informática da Faculdade de Ciências Exatas da Universidade do Estado do Rio Grande do Norte, como parte dos requisitos para conclusão do Curso de Especialização em Informática Aplicada. Orientador: Prof. Dr. Idalmir de Souza Queiroz Júnior. BANCA EXAMINADORA __________________________________________________________________________ Prof. Dr. Idalmir de Souza Queiroz Júnior __________________________________________________________________________ Prof. Dr. Everton Notreve Rebouças Queiroz Fernandes __________________________________________________________________________ Prof. M. Sc. Jéssica Neiva de Figueiredo Leite Data de Aprovação: __/__/__

Dedico este trabalho à minha mãe, Ana e às minhas irmãs, Patrícia e Isabelli.

AGRADECIMENTOS Agradeço a Deus por colocar no meu caminho pessoas que tomei como referência para chegar onde estou. Agradeço agora a cada uma dessas pessoas pelos seus valores morais e íntegros: Carlinhos, que escolhi para ser meu padrinho, pois eu me identificava com suas qualidades: acessível, simples, competente e comprometido. Ascenção Barbosa, minha madrinha, uma pessoa rara, que faz coisas para o próximo sem querer nada em troca. Idalmir de Souza, além de ser meu orientador e ótimo professor, foi devido às aulas dele de programação no CEFET em 1998 que decidi continuar a me dedicar à área de informática. Haroldo Paulino, pela sua iniciativa, facilidade de tomar decisões, ousadia e persistência. Ernani Junior, pela sua capacidade extraordinária de gerenciar coisas em paralelo além de ser muito persistente. Carlos Moisés, por sua dedicação e bom senso em momentos de pressão que poucos conseguem e também pelo seu esforço por manter a organização. Veras Junior, além de ser uma pessoa competente, aprendi com ele a importância de dar atenção ao lazer. Ricardo Júlio, dedicado, eclético e com ele aprendi as primeiras noções de programação para web. Leonard de Sousa, que me ajudou bastante, concedendo a entrevista e participando do teste de usabilidade. O pouco tempo que passei com ele, já deu para notar sua garra e vontade de vencer. Agradeço também a todos aqueles que tiveram paciência nos momentos que eu precisei estar ausente por está me dedicando a este trabalho.

RESUMO Neste trabalho mostraremos a evolução do Portal UERN entre 2004 e 2007, além das técnicas e tecnologias utilizadas para prover acessibilidade e aprimoramento à interface, baseado em princípios de usabilidade e na utilização adequada dos Padrões Web com objetivo de torná-la enxuta, útil e confortável. Partimos de uma estrutura inicial simples e flexível, que permitiu modificações rápidas. À medida que detectamos as verdadeiras necessidades dos principais usuários, aperfeiçoamos a página para permitir o acesso à informação com o mínimo de dificuldades possível. As impressões dos usuários foram obtidas por meio de um formulário de contato, que apesar de simples, foi muito efetivo para apontar mudanças na interface que fossem realmente úteis para as pessoas que a utilizavam. O trabalho é finalizado com um teste de usabilidade. PALAVRAS-CHAVE: Acessibilidade, Usabilidade, Padrões Web, Arquitetura da informação.

ABSTRACT This work talk about the Portal UERN evolution ( 2004 – 2007 ), beyond the techniques and technologies used to provide accessibility and utilized to upgrading the interface, based in principles of usability and in the appropriate application of Web Standards, with objective of become the page clean, helpful and comfortable. We started with a inicial, simple and flexible structure. This factor was very important because we could change the page faster. At the moment that we detect the truth user’s necessities, we improve the page to allow the access to information with least possible dificulty. The users’s feedback was by contact form, despite simple way, was effetive to appoint helpful changes in the interface. We concluded with a usability test. KEYWORDS: Accessibility, Usability, Web Standards, Information Arquitecture

SUMÁRIO 1. INTRODUÇÃO ....................................................................................................................... 13 1.2 OBJETIVOS ........................................................................................................................ 14 1.2.1 Geral ............................................................................................................................. 14 1.2.2 Específicos .................................................................................................................... 15 1.3 METODOLOGIA ................................................................................................................ 15 1.3.1 Tipo de Pesquisa ........................................................................................................... 15 1.3.2 Universo/Amostra......................................................................................................... 15 1.3.3 Coleta de Dados ............................................................................................................ 16 1.3.4 Analise de Dados .......................................................................................................... 16 1.4 ORGANIZAÇÃO ................................................................................................................ 17 2. REFERENCIAL TEÓRICO .................................................................................................. 18 2.1 REALIDADE DAS PÁGINAS WEB ................................................................................. 18 2.2 ÁREAS DO CONHECIMENTO E TECNOLOGIAS ENVOLVIDAS ............................. 19 2.2.1 Tecnologias utilizadas .................................................................................................. 19 2.2.2 Áreas do conhecimento para embasamento.................................................................. 20 2.2.3 Metodologia “Acessibilidade de Verdade” .................................................................. 23 2.2.4 Detalhamento da Metodologia “Acessibilidade de Verdade” ...................................... 23 2.3 ORGANIZAÇÃO DO CONTEÚDO .................................................................................. 27 2.3.1 Sistema de Organização................................................................................................ 29 2.3.2 Sistema de Navegação .................................................................................................. 31 2.3.3 Sistema de rotulação ..................................................................................................... 36 2.3.4 Sistema de Busca .......................................................................................................... 38 2.4 UTILIZAÇÃO DOS PADRÕES WEB ............................................................................... 39 2.4.1 A importância da padronização .................................................................................... 39 2.4.2 Padrões Web: Definição e Vantagens .......................................................................... 41 2.4.3 Marcação Válida e Marcação Semântica: evitando distorções .................................... 44 2.4.4 Principais tags do XHTML .......................................................................................... 48 2.4.5 Exemplo de utilização de marcação semântica ............................................................ 49 2.4.6 Entendendo o box model............................................................................................... 50 2.4.7 Centralizando elementos na tela com CSS ................................................................... 52 2.4.8 Quirks Mode, Strict Mode, hacks e Comentários Condicionais ................................... 54 2.4.9 Exemplo de Página com Layout 3 colunas ................................................................... 57 2.4.9.1 Criação do código XHTML da página .................................................................. 57 2.4.9.2 Usando a propriedade float para criação do layout ............................................. 59 2.4.9.3 Usando a técnica de Image Replacement .............................................................. 61 2.4.9.4 Tratamento de listas .............................................................................................. 63 2.4.9.5 Código CSS completo ............................................................................................ 64 2.4.9.6 Resultado final: interface do Blog Now ................................................................ 65 2.5 DIRETIVAS DE ACESSIBILIDADE ................................................................................ 67 2.5.1 Fornecer alternativas ao conteúdo sonoro e visual ....................................................... 68 2.5.2 Não recorrer apenas à cor ............................................................................................. 72 2.5.3 Utilizar corretamente marcações e folhas de estilo ..................................................... 72

2.5.4 Indicar claramente qual o idioma utilizado .................................................................. 73 2.5.5 Criar tabelas passíveis de transformação harmoniosa .................................................. 74 2.5.6 Assegurar que as páginas dotadas de novas tecnologias sejam transformadas harmoniosamente ................................................................................................................... 75 2.5.7 Assegurar o controle do usuário sobre as alterações temporais do conteúdo ............... 76 2.5.8 Assegurar a acessibilidade direta de interfaces do usuário integradas ......................... 76 2.5.9 Projetar páginas considerando a independência de dispositivos .................................. 76 2.5.10 Utilizar soluções de transição ..................................................................................... 77 2.5.11 Utilizar tecnologias e recomendações do W3C .......................................................... 79 2.5.12 Fornecer informações de contexto e orientações. ....................................................... 79 2.5.13 Fornecer mecanismos de navegação claros ................................................................ 80 2.5.14 Assegurar a clareza e a simplicidade dos documentos. .............................................. 82 2.6 TÉCNICAS DE USABILIDADE ....................................................................................... 83 2.6.1 Avaliação Heurística..................................................................................................... 83 2.6.2 Padrões de Design (design patterns) ............................................................................ 84 2.6.3 Testes de Usabilidade ................................................................................................... 86 2.7 ACOMPANHANDO AS TENDÊNCIAS .......................................................................... 90 2.7.1 Microformatos .............................................................................................................. 90 2.7.1.1 Microformato hcard .............................................................................................. 90 2.7.1.2 Microformato hcalendar ....................................................................................... 91 2.7.1.3 Microformato Geo ................................................................................................. 92 2.7.1.4 Outros Microformatos .......................................................................................... 92 3. A EVOLUÇÃO DO PORTAL UERN 2004 a 2007 .............................................................. 94 3.1 METODOLOGIA ................................................................................................................ 94 3.2 A ESTRUTURA DO ANTIGO PORTAL E PROPÓSITO INICIAL ................................ 95 3.2 DESENVOLVIMENTO DA 1ª VERSÃO DO PORTAL UERN - 2005 ........................... 98 3.3 DESENVOLVIMENTO DA 2ª VERSÃO DO PORTAL UERN - 2006 ......................... 102 3.4 DESENVOLVIMENTO DA 3ª VERSÃO DO PORTAL UERN – 04/07/2007 .............. 106 3.4.1 Preparado para o futuro com Microformatos ............................................................. 108 3.5 RESULTADOS ................................................................................................................. 110 4. ENTREVISTA E TESTE COM USUÁRIO ....................................................................... 112 4.1 METODOLOGIA .............................................................................................................. 112 4.2 ENTREVISTA .................................................................................................................. 113 4.3 TESTE DE USABILIDADE ............................................................................................. 118 4.4 RESULTADOS ................................................................................................................. 119 5. CONSIDERAÇÕES FINAIS ................................................................................................ 121 5.1 COMO NÃO DEVEMOS INTERPRETAR ESSE TRABALHO .................................... 121 5.2 COMO DEVEMOS INTERPRETAR ESSE TRABALHO.............................................. 124 5.3 CONCLUSÕES ................................................................................................................. 125 5.4 TRABALHOS FUTUROS ................................................................................................ 128 6. REFERÊNCIAS .................................................................................................................... 130 ANEXOS .................................................................................................................................... 132 Heurísticas para avaliação de usabilidade de portais corporativos ...................................... 132

LISTA DE ILUSTRAÇÕES Figura 1: Elementos presentes nas páginas no mundo dos padrões web ...................................... 19 Figura 2: Àreas do conhecimento que dão suporte ao desenvolvimento web ............................... 20 Figura 3: CSS específico para cada contexto (tela, dispositivo móvel, impressora) ..................... 22 Figura 4: Metodologia Acessibilidade de Verdade ....................................................................... 24 Figura 5: Ambiente de informação planejado e não planejado. Fonte: REIS, 2007b, p. 03 ......... 27 Figura 6: Equilíbrio entre conteúdo, contexto e público alvo. Fonte: REIS, 2007b, p. 04 ........... 28 Figura 8: Exemplos de esquema de organização ambígua ............................................................ 29 Figura 7: Esquemas de organização da informação. Fonte: REIS, 2007b, p. 13 .......................... 29 Figura 9: Esquema de organização exata: ordem alfabética. Fonte: cifraclub.com.br .................. 30 Figura 10: Esquema de organização exata: seqüência. Fonte: clifraclub.com.br .......................... 31 Figura 11: As perguntas de básicas que um site deve responder .................................................. 32 Figura 12: Elementos do sistema de navegação embutido ............................................................ 34 Figura 13: Mapa do site - Elemento de navegação remoto ........................................................... 35 Figura 14: Índice remissivo - Elemento de navegação remoto ..................................................... 36 Figura 15: Wireframe. Fonte: fatorw.com ..................................................................................... 38 Figura 16: Sitegrama. Fonte: Reis, 2007c ..................................................................................... 39 Figura 17: plugs e tomadas variadas e padrão ABNT. (fonte: Inmetro) ....................................... 40 Figura 18: Processo de desenvolvimento de sites comumente utilizado ....................................... 42 Figura 19: Processo que utiliza os padrões web de forma adequada............................................. 43 Figura 20: Página do acesso digital que utiliza marcação semântica ............................................ 50 Figura 21: Blog Now: Renderização do código no navegador ...................................................... 59 Figura 22: Blog Now - renderização do CSS – parte 01 ............................................................... 61 Figura 23: Blog Now - Renderização da imagem no lugar do texto ............................................. 62 Figura 24: Blog Now - renderização de uma lista de links ........................................................... 63 Figura 25: Blog Now - Renderização Final ................................................................................... 66 Figura 26: Exemplo vídeo com legendas. Fonte: charges.com.br ................................................. 71 Figura 27: Padrão de design - busca no site. ................................................................................. 84 Figura 28: Formato padrão para menu horizontal. ........................................................................ 84 Figura 29: Formato padrão para menu vertical. ............................................................................ 85 Figura 30: Formato padrão para menu L invertido....................................................................... 85 Figura 31: Antigo portal UERN - 2004 ......................................................................................... 96 Figura 32: Análise de Acessibilidade do antigo portal UERN ...................................................... 99 Figura 33: 1ª versão do Portal UERN 2006 ................................................................................. 100 Figura 34: Comparando Portal 2004 e o Novo Portal (1ª versão - topo e navegação principal) . 101 Figura 35: Comparando Portal 2004 e o Novo Portal (1ª versão - navegação secundária) ......... 101 Figura 36: Análise de acessibilidade da 1ª versão do Portal UERN ........................................... 102 Figura 37: Análise de Usabilidade da 1ª versão do Portal UERN – parte 1 ................................ 103 Figura 38: Análise de Usabilidade da 1ª versão do portal UERN – parte 2 ................................ 104 Figura 39: Análise de Usabilidade da 1ª versão do portal UERN – parte 3 ................................ 104 Figura 40: 2ª versão do Portal UERN - 2006 .............................................................................. 105 Figura 41: 3ª versão do Portal UERN – Julho de 2007 ............................................................... 107 Figura 42: Análise de Acessibilidade do Portal UERN – Julho de 2007 .................................... 108 Figura 43: Plugin operator localizando as coordenadas geográficas da UERN .......................... 110 Figura 44: Vista do Campus Central - UERN – Mossoró-RN – Google maps .......................... 110

LISTA DE CÓDIGOS-FONTE Código 1: Renderização inicial das tags de título h1 a h6 no navegador ...................................... 45 Código 2: Renderização das tags de título h1 a h6 modificadas pelo CSS ................................... 46 Código 3: Renderização das tags de título h1 a h6 com posicionamento aleatório....................... 47 Código 4: Detalhamento do box model junto com exemplo de borda diagonal ........................... 52 Código 5: Centralização de elementos com CSS – parte 01 ......................................................... 53 Código 6: Centralização de elementos com CSS – parte 02 ......................................................... 53 Código 7: Centralização de elementos com CSS – final ............................................................... 54 Código 8: Renderização em Quirks e em Strict Mode. ................................................................. 55 Código 9: Resolvendo o problema do box model – parte 01 ........................................................ 56 Código 10: Resolvendo o problema do box model – parte 02 ...................................................... 57 Código 11: Blog now: código XHTML ........................................................................................ 58 Código 12: Blog Now: CSS parte 01 ............................................................................................ 60 Código 13: Blog Now: aplicando Image Replacement ................................................................. 62 Código 14: Blog Now: CSS de tratamento de listas..................................................................... 63 Código 15: Blog Now: CSS completo – Parte 1 .......................................................................... 64 Código 16: CSS completo – Parte 2 .............................................................................................. 65 Código 17: Descrição redundante com imagem transparente. ...................................................... 69 Código 18: Descrição redundante sem imagem transparente. ....................................................... 69 Código 19: Descrição redundante com imagem transparente. ...................................................... 70 Código 20: Identificação do idioma do conteúdo .......................................................................... 73 Código 21: Utilização do atributo title em abreviações e acrônimos. ........................................... 74 Código 22: Utilização correta de labels em formulários. .............................................................. 78 Código 23: Separando links por listas não ordenadas ou colchetes. ............................................. 78 Código 24: Lista separada por optiongroup. ................................................................................. 79 Código 25: Descrição da seção de sucos utilizando a tag de título h3. ......................................... 80 Código 26: Exemplo de RDF ....................................................................................................... 81 Código 27: Exemplo de meta tags. ................................................................................................ 81 Código 28: Microformato hcard. ................................................................................................... 91 Código 29: Microformato hcalendar. ............................................................................................ 91 Código 30: Microformato geo. ...................................................................................................... 92 Código 31: Microformato rel-licence. ........................................................................................... 92 Código 32: Microformato hcard implementado no Portal UERN ............................................... 109 Código 33: Microformato Geo implementado no Portal UERN ................................................. 109

LISTA DE TABELAS Tabela 1: Tabela que facilita a manipulação de softwares leitores de tela .................................... 74 Tabela 2: Tabela que prejudica a manipulação de softwares leitores de tela ................................ 75 Tabela 3: Comparando Teste de Usabilidade tradicional e simplificado. Fonte: Krug, 2000. ...... 88

13 1. INTRODUÇÃO O conceito de deficiência relacionado à web refere-se ao usuário portador de um ou mais problemas: visual, auditivo, motor ou cognitivo, dificultando o uso dos dispositivos de entrada e saída tradicionais. No Decreto Lei nº 5.296 de 02/12/2004 em seu artigo 8º prevê acessibilidade nos sistemas de comunicação, contextualizando-se com o ambiente da web. Esse decreto prevê que em Instituições Públicas seja obrigatório pelo menos o nível básico de acessibilidade em suas páginas web. As Recomendações para a acessibilidade do conteúdo da Web versão 1.0, produzida pelo WAI (Web Accessibility Initiative), organização ligada ao consórcio W3C (World Wide Web Consortium), responsável pelo desenvolvimento de estratégias, recursos e guias de orientações para a acessibilidade na Web para auxiliar pessoas com deficiência, baseiam-se em duas diretivas:  Assegurar uma transformação harmoniosa e;  Tornar o conteúdo compreensível e navegável. Dentro dessas duas diretivas existem vários requisitos a serem cumpridos, entre eles temos:  Separação entre conteúdo e formatação visual;  Utilização da linguagem de hipertexto de forma que fique semanticamente harmônica com o tipo informação que está querendo divulgar na página, utilizando a tag apropriada em cada caso. Esta especificação de acessibilidade nos obriga a facilitar o acesso para deficientes e também a tornar uma página acessível com diversas outras vantagens, como por exemplo, o acesso através de dispositivos móveis. Neste trabalho faremos uma pesquisa mostrando como está o nível de acessibilidade atual da página principal do Portal UERN, que estão disponíveis para o público externo, além de mostrar algumas falhas encontradas e sugestões de

14 aprimoramento, quando for necessário. Sabendo que, no desenvolvimento das interfaces com o usuário, as especificações de acessibilidade não são o bastante para garantir a qualidade, mostraremos também técnicas das áreas de usabilidade e de arquitetura de informação para ampliar sempre que possível o conforto do usuário e melhorar sua experiência ao procurar por um recurso na página. Essa metodologia que engloba áreas distintas de desenvolvimento será denominada para esse trabalho de “Acessibilidade de Verdade”, que segundo a equipe do acesso digital significa Acessibilidade + Usabilidade + Padrões Web. Nesse trabalho essa metodologia é ampliada pois passa a fazer parte dela a Arquitetura da informação e o Acompanhamento de Tendências tornando-a dinâmica. Ela será explicada no item 2.2.3 e detalhada no item 2.2.4. Toda essa metodologia não teria utilidade se também não tivéssemos mecanismo para detectar a satisfação do usuário. Escolhemos uma forma simples que estivesse dentro da nossa realidade e tempo disponível para execução. Decidimos adotar um formulário de contato onde os usuários podem colocar suas sugestões, críticas, elogios, dúvidas e o que desejar. Essas mensagens servirão de termômetro para orientar nas tomadas de decisões no caso de futuras mudanças. 1.2 OBJETIVOS 1.2.1 Geral Mostrar a evolução que sofreu o Portal UERN entre 2004 e 2007, em termos de acessibilidade, usabilidade e arquitetura da informação, além de mostrar um pouco das tecnologias utilizadas nesse processo: XHTML semântico para estruturação e CSS para formatação. Mostrar também que técnicas simples como um formulário de contato já traz resultado bastante satisfatório para tomada de decisões nas mudanças de interface. Todo esses objetivos serão agrupados em uma metodologia inovadora chamada Acessibilidade de Verdade que será explicada no decorrer do texto.

15 1.2.2 Específicos  Colher informações acerca do tema acessibilidade, arquitetura da Informação, Usabilidade e das tecnologias criadas pelo W3C que são conhecidas como padrões web;  Avaliar o nível de acessibilidade do Portal da UERN comparando com informações retiradas do W3C.  Analisar as opiniões dos usuários com relação à interface do portal da UERN através de formulário de contato, para a partir daí efetuar mudanças mais coerentes; Esse é o ponto mais importante desse trabalho, em que mostraremos a importância de prestar atenção nas mensagens dos usuários. Uma tarefa simples que pode dar bons resultados.  Como complemento, mostrar os procedimentos para fazer um teste de usabilidade com custos reduzidos, aplicando também um teste para tirar impressões a respeito da interface. Esse teste tem caráter demonstrativo, não será feito para tirar conclusões minuciosas sobre a interface. 1.3 METODOLOGIA 1.3.1 Tipo de Pesquisa A pesquisa que se deseja realizar qualifica-se quanto aos fins como descritiva e qualitativa; quanto aos meios será documental, bibliográfica e explorativa “in loco” como forma de levantar todas as informações necessárias para a produção das argumentações. 1.3.2 Universo/Amostra O universo da pesquisa será a página principal do Portal da UERN que é acessível ao público externo. As mensagens recebidas pelo formulário de contato localizado no Portal UERN que servirá de auxílio para tomada de decisões. Não menos importante, porém de forma complementar, os usuários com necessidades especiais, para aplicação de questionários,

16 entrevistas ou testes de usabilidade com a finalidade de ilustrar um pouco esse universo e se possível detectar problemas na interface. 1.3.3 Coleta de Dados A coleta de dados deu-se da seguinte forma: primeiramente foi feito uma pesquisa bibliográfica para dar embasamento teórico a partir alguns autores que tratam deste tema e também sites especializados em acessibilidade na web, arquitetura da informação, usabilidade e padrões web. As impressões dos usuários forma obtidas através das mensagens enviadas pelo formulário de contato do Portal UERN, que serviram como referência para as principais mudanças de todas as versões do portal UERN entre 2004 e 2007. Por fim, de forma complementar e com finalidade ilustrativa foram colhidos dados através de entrevista e teste de usabilidade com um usuário com necessidade especial. 1.3.4 Analise de Dados A principal análise realizada foi baseada nas mensagens obtidas pelo formulário de contato em que os usuários compartilharam suas impressões a respeito da interface, a partir dessas mensagens é que decidimos o que precisava ser modificado com maior urgência para resolver os problemas. Essa análise não precisou ser detalhada e as mensagens não precisaram ser relidas constantemente pois utilizamos uma técnica que será mostrada no item Evolução do Portal UERN. A partir dessas necessidades dos usuários utilizamos diversas técnicas e tecnologias para que o problema da interface fosse resolvido de forma efetiva e que proporcionasse maior conforto na utilização. Como complemento é mostrado uma entrevista com um usuário que tenha necessidade especial para que os leitores conheçam um pouco esse universo e suas particularidades. Também é mostrado a descrição e as considerações sobre o teste de usabilidade aplicado com esse mesmo participante da entrevista.

17 1.4 ORGANIZAÇÃO Para um melhor entendimento de onde queremos chegar, iniciaremos mostrando o nível das páginas web atualmente. Depois seguiremos com os seguintes tópicos: arquitetura da informação, utilização adequada dos padrões web, acessibilidade, usabilidade e finalmente a complementação com o acompanhamento de tendências. Mostraremos em seguida a evolução da interface do Portal UERN nos últimos anos, além de apresentarmos as técnicas utilizadas nesse processo e as considerações sobre os resultados. Realizaremos finalmente um teste de usabilidade simplificado focado no perfil de usuário com deficiência visual para termos uma impressão complementar sobre a interface. Terminando conseqüentemente com as considerações sobre o trabalho e a detecção da importância de ficar atento as opiniões dos usuários, mesmo que seja de uma forma indireta, como é o caso do formulário de contato.

18 2. REFERENCIAL TEÓRICO Nesse momento iremos explanar sobre as técnicas e metodologias que servirão de embasamento para o sucesso desse trabalho. 2.1 REALIDADE DAS PÁGINAS WEB Segundo Jefrey Zeldman (2007), 99% das páginas web são obsoletas. O interessante nessa afirmação é que ele já havia dito isso em 2004, ano da primeira edição do seu livro Design with Webstandards e, três anos depois, na segunda edição, ele ainda insiste que o problema ainda permanece. O fato é que apesar da criação das tecnologias dos padrões web e das renovações e adequações dos navegadores atuais, muitos desenvolvedores ainda persistem com práticas ultrapassadas, seja por falta de conhecimento, acomodação, entre outros motivos. Paralelo a isso tem várias iniciativas de mudanças estruturais nos sites, tomadas por grandes empresas no Brasil: UOL, Terra, Caixa Econômica, Banco do Brasil. A utilização dos Padrões Web1 já faz parte da realidade brasileira, já está deixando de ser um diferencial e se tornando cada vez mais algo imprescindível para um produto de qualidade (site) que possa ser facilmente adaptado para as novas tecnologias, com facilidade de manutenção, facilidade de indexação pelos sites de busca, economia de banda devido à ausência de tags desnecessárias, entre outras vantagens. Nesse trabalho, a utilização consciente dos Padrões Web, principalmente XHTML (eXtensible HiperText Markup Language) e CSS (Cascading Style Sheets) serão essenciais para criação de sites com acessibilidade. Quando necessário, complementaremos com técnicas de usabilidade para ampliar o conforto dos usuários, porém as ferramentas para criar a interface com conteúdo voltado para determinados tipos de usuários serão essas duas já citadas, cada uma com sua especificidade e objetivo. A primeira para organizar, tipificar e hierarquizar o conteúdo, a segunda para formatar o conteúdo e posicioná-lo de forma que facilite a utilização do usuário. 1 Tecnologias desenvolvidas pelo consórcio W3C ( XHTML, CSS, XML, entre outras)

19 2.2 ÁREAS DO CONHECIMENTO E TECNOLOGIAS ENVOLVIDAS Para termos uma noção da complexidade desse trabalho é muito importante iniciarmos com uma visão geral que englobe as áreas e tecnologias envolvidas para a concretização do mesmo. 2.2.1 Tecnologias utilizadas Começaremos pelas tecnologias disponíveis, que podemos identificar na figura abaixo: Figura 1: Elementos presentes nas páginas no mundo dos padrões web Podemos perceber a clara separação das tecnologias de acordo com suas funções, temos, por exemplo, o XHTML para estruturar o conteúdo, o CSS para formatá-lo e o DOM (Document Object Model) manipulado através do javascript para permitir certo nível de dinamismo na página do lado do cliente. Há uma divisão dos papéis; cada qual fazendo sua parte, o todo fica simples e organizado.

20 2.2.2 Áreas do conhecimento para embasamento Na figura abaixo podemos identificar as principais áreas do conhecimento envolvidas nas boas práticas de desenvolvimento web: Figura 2: Àreas do conhecimento que dão suporte ao desenvolvimento web Não existe ordem de importância entre as áreas e por diversas vezes são utilizadas as técnicas de áreas diferentes em conjunto. O triângulo da imagem é somente para dar uma idéia de sustentação e equilíbrio. As tecnologias web criadas pelo W3C utilizaram muitos princípios dessas áreas do conhecimento para que seus produtos fossem realmente úteis (ZELDMAN, 2007). A arquitetura da Informação, segundo Holzschlag (2005), tem o objetivo de organizar, mesclar e combinar tópicos em grupos lógicos para facilitar a vida do visitante e também de otimizar o espaço limitado da tela com a maior quantidade de informações relevantes possível. Comumente essa atividade de criação da taxonomia do site é feita no começo do desenvolvimento, depois que se tem o inventário de conteúdo do mesmo. Porém, durante o

21 desenvolvimento também se percebe melhorias e é possível efetuar modificações até que se tenha um produto coerente com o grupo de usuários que se deseja alcançar. Usabilidade refere-se à tentativa, a partir da utilização da página pelo usuário, de aprimorá-la para que proporcione o máximo possível de conforto e facilidade de uso. É um passo a mais a partir da acessibilidade. Podemos ver uma definição mais intuitiva citada por Amstel (2008): Usabilidade é sinônimo de facilidade de uso. Se um produto é fácil de usar, o usuário tem maior produtividade: aprende mais rápido a usar, memoriza as operações e comete menos erros. Andrade (2008) nos diz que as diretrizes de usabilidade se baseiam em como os usuários se comportam de maneira geral, na maioria dos sites e como se comportam, em casos específicos, como em um site de comércio eletrônico por exemplo. Fala também que a quantidade enorme de pesquisas feitas sobre usabilidade resultou nas chamadas heurísticas que são tidas como base para garantir conforto ao usuário; porém, como não são tão precisas, é indicada como complemento, a utilização de testes de usabilidade. Outro item importante são os padrões de design que junto com as heurísticas2 servirão de apoio nos diversos projetos de desenvolvimento de sites. Andrade (2008), também sugere que um projeto com usabilidade em um nível ideal passe pelas seguintes etapas: 1. Os desenvolvedores se colocando no lugar dos usuários para executar o projeto; 2. A realização de uma avaliação heurística3 e 3. Complementação com testes de usabilidade. Acessibilidade significa ausência de barreiras. O objetivo da acessibilidade na web é eliminar o máximo possível, os obstáculos que existam entre determinado conteúdo e determinado grupo de usuários. É essencial que o desenvolvimento web tenha o foco em acessibilidade pois deixa a página muito flexível para mudanças rápidas e efetivas. 2 Heurísticas são parâmetros para o desenvolvimento criados através do consenso entre a experiência prática de vários pesquisadores em testes com usuários. Os resultados que se repetem, podem utilizados para avaliação de novos projetos. 3 Avaliação heurística é a verificação se o projeto segue os princípios testados e aprovados anteriormente.

22 É bom lembrar também que o conceito de acessibilidade é bem mais amplo que somente fabricar páginas voltadas para usuários com determinados tipos de deficiência (EIS, 2008). A acessibilidade envolve também a fabricação de produtos (sites) que possuam conteúdos que possam ser acessados de diferentes navegadores, em diferentes sistemas operacionais e para os diferentes dispositivos que existem hoje ou que ainda venham a ser criados. Uma página acessível acaba sendo boa para todos, pois facilita a vida de usuários que dependem de leitores de tela e também de outros que acessam as notícias do portal via celular ou computador de bolso. Determinadas empresas utilizavam a estratégias de fazer páginas web alternativas apropriadas para dispositivos móveis, ou apropriadas para usuários cegos, por exemplo. Essa estratégia é em certo ponto falha, pois gera duplicação de conteúdo e também desperta a sensação de que as páginas específicas não têm todo o conteúdo da página principal. Podemos ver na imagem a seguir que com a utilização dos Padrões Web resolvemos esse problema. Pois teremos um único conteúdo que será formatado de maneira adequada para os respectivos dispositivos usando a folha de estilo compatível com cada interface. Figura 3: CSS específico para cada contexto (tela, dispositivo móvel, impressora)

23 Torres (2008) afirmou que acessibilidade não é altruísmo e sim uma ótima estratégia de ganhar novos clientes, que as empresas podem adotar, já que seus produtos poderão ser comprados de diferentes dispositivos, e também por usuários que tenham algum tipo de deficiência. Uma pessoa cega pode comprar, por exemplo, um livro em uma loja virtual para presentear um amigo. Trata-se de clientes em potencial para os diversos produtos que podem ser vendidos pela web caso a página esteja acessível e seja fácil de usar. Acessibilidade é muito importante no desenvolvimento web, porém somente acessibilidade não é suficiente para o aprimoramento efetivo das páginas. Para isso incluiremos nesse trabalho o auxílio de outras técnicas. A utilização de todas as técnicas e tecnologias com bom senso, e focadas nos usuários é o que chamaremos nesse trabalho de Metodologia “Acessibilidade de Verdade”. Logo a seguir ela será explicada e detalhada. 2.2.3 Metodologia “Acessibilidade de Verdade” A equipe do Acesso Digital (www.acessodigital.net) propõe uma metodologia relevante utilizando o slogan “Acessibilidade de verdade”, que é a soma de Acessibilidade + web Standards + Usabilidade. Essa metodologia leva em conta o contexto social e o resultado é uma visibilidade muito maior para o produto ou serviço. Para facilitar a compreensão desse trabalho iremos utilizar esse slogan denominando realmente a metodologia. 2.2.4 Detalhamento da Metodologia “Acessibilidade de Verdade” Detalhando um pouco mais essa metodologia do Acesso Digital para termos uma noção das etapas do desenvolvimento. O resultado foi a seguinte seqüência: 1. A organização adequada do conteúdo focada no público alvo do site (Arquitetura da Informação); 2. A utilização adequada das tags para cada tipo de conteúdo que for mostrado e também a utilização de cada tecnologia para a qual ela realmente se propõe (Padrões Web de forma correta);

24 3. A utilização e adequação desse conteúdo bem selecionado e bem demarcado às diretrizes de acessibilidade do WCAG (Web Content Accessibility Guidelines); 4. A complementação com alterações que facilitem o uso como, por exemplo, a utilização de um link que sirva de atalho direto para o conteúdo principal; (Usabilidade) e; 5. O acompanhamento das evoluções das tecnologias e tendências que estão aparecendo, além da utilização das mesmas com bom senso. Como exemplo, temos os microformatos que expandem a representação do HTML (Hiper Text Markup Language). Vamos agora chamar esses 5 passos anteriores de recursos. Em seguida colocamos todos esses recursos disponíveis focados nos usuários. Teremos dessa forma o detalhamento da metodologia Acessibilidade de Verdade que pode ser visto na figura abaixo: Recursos = ( Arquitetura da Informação + Padrões Web + Acessibilidade + Usabilidade + Acompanhamento de Tendências ) Acessibilidade de Verdade = Recursos + Foco no Usuário + Bom Senso Figura 4: Metodologia Acessibilidade de Verdade Devemos entender o termo recurso como o conjunto que inclui técnicas, áreas do conhecimento e tecnologias utilizadas no desenvolvimento web. O conjunto citado acima é uma base inicial, um alicerce para que o desenvolvedor possa seguir por um caminho melhor estruturado. Para esse trabalho resolvemos delimitar os recursos nesses cinco. Eles devem pela definição ser direcionados para problemas reais (foco no usuário). A afirmação de que os recursos citados são apenas uma estrutura inicial é feita baseando-se na natureza dinâmica do conhecimento. O que é útil hoje poderá não ser mais útil no futuro, então é preciso visualizar essa metodologia e aos poucos ir aprimorando e modificando, adicionando ou eliminando itens. Pela seqüência da metodologia, já dá para perceber que somente a utilização dos padrões web, apesar de servir de base, não garante a acessibilidade do site. Portanto, esse trabalho se propõe a utilizar as etapas mostradas na lista anterior (recursos) utilizados de para facilitar a vida

25 do usuário. A seqüência acima está disposta de forma didática, na criação do produto (site) podemos estar focados em um ou mais dos itens quase que simultaneamente. Outro quesito importante é o item cinco que mostra que se seguirmos até o item quatro o site estará acessível no contexto atual. Mas como garantir a acessibilidade daqui a cinco anos, se terá um novo contexto de inovações tecnológicas? A resposta é simples: Somente com acompanhamento e aprimoramento. Sem isso, o site corre o risco de no futuro se tornar parcialmente obsoleto ou criar barreiras em determinados contextos. É preciso entender que somente os recursos não surtiriam o efeito esperado se o desenvolvimento não for bem direcionado para os usuários. Aqui é quando percebemos a importância de termos alguma forma de captar as impressões dos usuários para podermos direcionar o conjunto de técnicas (recursos) para solucionar problemas reais (foco no usuário). Outro ponto que precisa ser esclarecido, ainda sobre o foco no usuário é que ele será abordado de forma indireta na seqüência dos capítulos. No item Arquitetura da informação será mostrado uma figura que representa uma tentativa de equilibrar usuário, contexto e conteúdo. No item de Usabilidade será mostrado os testes de usabilidade. Um dos itens mais importantes da metodologia é o “Bom senso”. Ele foi colocado com a mesma intensidade dos demais, mas é um elemento que tem que ser sempre levado em conta. O bom senso para esse trabalho significa aplicar somente o esforço suficiente para resolver determinado problema, nem demais, nem de menos. Para facilitar a compreensão Allen (2001) mostra uma comparação da “mente como água”. Quando um objeto cai sobre a água, ela responde apropriadamente de acordo com a força e a massa do objeto e logo em seguida retorna ao repouso. Algo semelhante ocorre com a mente quando a mente faz somente o que for preciso, nada a mais nem a menos. Quando o desenvolvedor reage exageradamente ou é impedido de agir adequadamente indica que ele está sendo controlado por algo. Isso acaba prejudicando a qualidade do produto. A solução é a procura pelo equilíbrio. Seguindo esse princípio do bom senso o desenvolvedor tende a chegar a um meio-termo entre técnicas, tecnologias e usuários. Quando se tratar de um site simples, não é preciso utilizar todos os recursos apresentados, pois seria desperdício de tempo e energia para algo que não trará diferenças substanciais. Portanto nesse caso é suficiente que o site seja estruturado com os Padrões Web, sem preocupações maiores. É através do bom senso também que o desenvolvedor percebe que não deve levar muito a sério as entrevistas com usuários com relação a sugestões para modificação, porque o usuário

26 tende a ser exagerado em suas declarações, mas também não devemos desprezar totalmente, pois quando determinada sensação se repetir para outros usuários poderá ser um sinal para analisar mais detalhadamente. De forma resumida podemos dizer que bom senso nunca é demais, pois é o item da fórmula responsável pela harmonia do conjunto, pelo balanceamento das tarefas executadas pelo desenvolvedor. Talvez a grande diferença entre os desenvolvedores mais experientes e os iniciantes seja a facilidade em lidar com as situações diversas usando o bom senso, é algo que não vem do dia para a noite, nem cai do céu, mas é algo que tem que ser buscado, pois realmente faz a diferença. Um complemento a esse elemento bom senso será mostrado nas considerações finais no item “como não devemos compreender esse trabalho”. Em seu conteúdo serão ilustrados os paradigmas que foram tomados como referência para o desenvolvimento do Portal UERN. Explicada a metodologia já é possível compará-la com os objetivos: mostrar a evolução do portal UERN entre 2004 e 2007 e a utilização dos Recursos (técnicas e tecnologias) no decorrer das versões para aprimorar a interface, junto com um feedback simples com um formulário de contato (foco no usuário). Finalmente, o bom senso é o que vai fazer todas essas técnicas tenderem ao equilíbrio. É possível detectar também que todos aqueles pontos que pareciam soltos nos objetivos na verdade estão integrados, são peças que interagem entre si para que algo seja construído de forma estruturada. A partir daqui detalharemos cada um dos cinco tópicos da metodologia “Acessibilidade de Verdade” equivalente aos Recursos na fórmula, que são essenciais para construção de sites que realmente facilitam a vida do usuário, eliminado as barreiras e colocando informações relevantes em locais estratégicos.

27 2.3 ORGANIZAÇÃO DO CONTEÚDO A partir do momento que dispomos de um inventário do que conterá o site no caso do desenvolvimento de um primeiro site, ou então para fazer modificações em um site que já existe é preciso entrar numa etapa de seleção, organização e hierarquização das informações. As técnicas necessárias abordadas nesse problema pertencem à área de Arquitetura da Informação que segundo Toub (apud por REIS 2007a): “é a arte e a ciência de estruturar e organizar ambientes de informação para ajudar as pessoas a satisfazerem suas necessidades de informação de forma efetiva.” Para entendermos um pouco vamos ver na figura abaixo a diferença entre ambientes com conteúdo planejados e os que não deram importância suficiente a esse quesito: Figura 5: Ambiente de informação planejado e não planejado. Fonte: REIS, 2007b, p. 03 Para conseguirmos um resultado mais próximo possível do segundo quadro é necessário balancear as características e necessidades dos usuários, do conteúdo e do contexto. Podemos ter uma noção mais detalhada com a próxima imagem:

28 Figura 6: Equilíbrio entre conteúdo, contexto e público alvo. Fonte: REIS, 2007b, p. 04 Rosenfeld e Morvile (apud REIS 2007a) dividem a arquitetura da informação de web sites em quatro etapas: 1. Sistema de Organização: composto pelo agrupamento e categorização do conteúdo informacional; 2. Sistema de Navegação: Especifica as maneiras de navegar, de se mover pelo espaço informacional e hipertextual; 3. Sistema de rotulação: Estabelece as formas de representação, de apresentação, da informação definindo signos para cada elemento informativo e 4. Sistemas de busca: Determina perguntas que o usuário pode fazer e o conjunto de respostas que irá obter.

29 2.3.1 Sistema de Organização Para entendermos o sistema de organização precisamos ter noção de qual contexto deveremos utilizar as seguintes estratégias: Figura 7: Esquemas de organização da informação. Fonte: REIS, 2007b, p. 13 Alguns exemplos de esquemas organização: Figura 8: Exemplos de esquema de organização ambígua Esse exemplo do magazineluiza.com é interessante, pois apesar de reunir formas diferentes de organização ele ainda consegue ser bem consistente. Ele usa a metáfora do carrinho

30 de compras que já é bem consolidada. A separação por categoria de produtos representando assuntos diferentes está inclusive realçada por cores distintas. O item de público alvo “bebê”, apesar de se configurar numa organização por assunto, está bem colocado, pois se trata de um tipo de produto bem definido, organizado sobre o formato de abas que sugere ao usuário percorrê-las até encontrar o produto desejado. O problema de siglas foi bem resolvido, como no caso do link de “Utilidades domésticas”, já que em outros sites como submarino.com utiliza a sigla UD que pode deixar os usuários confusos. A parte superior do topo está “recheada” das diversas tarefas de prontidão para os usuários resolverem suas necessidades, complementada com o telefone de vendas em local estratégico. O que não ficou tão claro são os itens – “Vendas corporativas” e “lista de casamento” - orientados à público alvo, mas apresentado de uma forma que não se diferencia dos outros itens orientados a tarefas, podendo confundir os usuários. Uma olhada rápida no “fale conosco”, pode dar a entender que as demais opções tratam da resolução de problemas, e no caso do usuário não estar interessado nisso, é possível que os itens orientados para “vendas corporativas” e para “noivos” passem despercebidos. Portanto, a estética, o jogo de cores, os formatos e posicionamentos podem ajudar ou prejudicar a consistência da página, vai depender da maneira que foi colocada. A utilização de abas foi o exemplo de sucesso, enquanto que a mistura de itens de propósitos diferente, com uma mesma estética, não foi tão adequada para os usuários. Esses equívocos no design podem levar à diminuição de vendas, já que existem outros concorrentes que possivelmente mostram essas informações de forma mais clara, a somente um endereço ou clique de distância. Veremos agora alguns exemplos de esquemas de organização exatos: Figura 9: Esquema de organização exata: ordem alfabética. Fonte: cifraclub.com.br

31 Figura 10: Esquema de organização exata: seqüência. Fonte: clifraclub.com.br As figuras 8 e 9 foram retiradas do cifraclub.com.br que nos dá ótimos exemplos de organização exata, no caso da escolha de músicas por ordem alfabética e também no quadro do top cifras representando a organização em seqüência. Esse é também uma ótima utilização do conceito de Faced Classification que se trata de organizar um mesmo conjunto de informações de formas diferentes otimizando a área útil da tela no sentido de possibilitar mais recursos e facilidades para os usuários. No caso do cifra club podemos tentar achar uma música que comece com a letra “a” (ordem alfabética), ou podemos fazer a busca pelo nome da música, artista e ainda no caso de esquecimento do nome da música é possível fazer a busca por trechos da música. E o top 10 não deixa de ser outra forma de chegar a determinadas músicas que são mais procuradas. 2.3.2 Sistema de Navegação Para se ter um bom sistema de navegação, segundo Nielsen (2000), é preciso que a interface responda a três perguntas básicas: 1. Onde estive? 2. Onde estou? 3. Onde posso ir? Na figura a seguir, mostraremos em que locais de uma página são encontradas as respostas para as perguntas acima.

32 Figura 11: As perguntas de básicas que um site deve responder A resposta “Para onde posso ir?” são todos os links de navegação da página. Decidimos colocar somente um trecho para destacar melhor sem confundir com as outras respostas. Como podemos perceber, trata-se de uma área limitada (tela) onde teremos que colocar informações de forma organizada para que o usuário não se perca. Portanto, uma forma que serve de base para construção da interface é deixar o máximo possível flexível, desde que não se torne confuso.

33 Para tornar flexível temos os dilemas: 1. É permitido ir para qualquer lugar? 2. É permitido ir rapidamente de um ponto a outro? 3. Fornece muitos atalhos? Para evitar que a página se torne confusa temos que agir de bom senso, pois informação demais poderá prejudicar o usuário. Ele pode demorar a decidir em que link clicar ou até desistir de utilizar a página. Os sistemas de navegação podem ser divididos em: Sistema de navegação embutido É onde se encontra os links que são mostrados juntos com o conteúdo que tem a função de criar um contexto e flexibilizar o movimento. São formados por: Logotipo, Barra de navegação global, Navegação local, Bread Crumb, Cross Content. Sendo que Bread Crumb é uma lista de elementos geralmente na horizontal que indica de forma hierárquica o caminho da estrutura raiz do site até a página atual, permitindo facilmente que o usuário mude para outro nível através dos links disponíveis. O Cross Content trata-se de links localizados próximos ao texto no qual tem o objetivo de complementar o conteúdo da página atual com informações relacionadas para o usuário se aprofundar no assunto em questão. Esses dois sistemas serão ilustrados nas figuras a seguir.

34 Figura 12: Elementos do sistema de navegação embutido Sistema de navegação remoto É independente da hierarquia do site e serve como um caminho complementar para se chegar a determinados conteúdos ou tarefas. São formados por mapa do site e índice remissivo. O mapa do site tenta mostrar toda a estrutura do site possibilitando acesso rápido a qualquer página. O índice remissivo é equivalente aos que são encontrados no final de livros. Trata-se de listas de palavras chaves organizadas em ordem alfabética que são relacionadas ao conteúdo do website.

35 Figura 13: Mapa do site - Elemento de navegação remoto

36 Figura 14: Índice remissivo - Elemento de navegação remoto 2.3.3 Sistema de rotulação Segundo Rosenfeld e Morville (apud REIS 2007a) o objetivo do rótulo é comunicar o conceito de forma eficiente. De maneira que não precise muito esforço cognitivo para a compreensão. Eles são empregados principalmente nos títulos de páginas, nos links do sistema de navegação e nos links contextualizados. Os rótulos podem ser textuais, formados por uma ou mais palavras ou não-verbais como os ícones. A criação do projeto de rotulação do site pode passar por algumas dificuldades, como a de conseguir falar a linguagem do usuário. O usuário comum vive em um ambiente distinto do que o desenvolvedor está acostumado. O ambiente do usuário pode está repleto de gírias ou dialetos diferentes e é difícil compreender essa linguagem para deixar o texto do site amigável. O outro ponto é que empresas gostam de interferir nessa nomenclatura querendo deixá-la de acordo com a estrutura interna, suas linguagens técnicas e suas gírias. Isso é um problema e é preciso fazer com

37 que quem contratou o serviço compreenda que a estrutura e rotulação do site não devem ser orientadas para os integrantes nem para o dono da empresa e sim para os clientes da empresa. Outro dilema é a dificuldade de obter feedback já que ele vem através de medição de acesso às páginas, e-mails no formulário de contato, e do log de busca que não ocorrem em tempo real, então é preciso paciência, pois não tem como saber se a interface está sendo compreendida de forma satisfatória pelos usuários. O outro problema é evitar ambigüidade nos rótulos o que é difícil, porém quando for inviável é interessante que os links sejam duplicados, ou seja, repete o link em todas as categorias que geram dúvidas. Por último o desenvolvedor precisa manter a consistência dos rótulos e segundo Rosenfeld e Morvile (apud REIS, 2007a), ela é dividida nos seguintes níveis:  Estilo: manter o mesmo formato de caixa-alta, caixa baixa e pontuação em todo o site.  Apresentação: é preciso uma boa escolha das fontes, tamanho da fonte, cores da letra e background e espaços em branco que auxiliam no agrupamento dos rótulos de mesma orientação;  Sintaxe: é preciso manter a sintaxe uniforme (grau, número, gênero, tempo verbal, etc.). Quando iniciar um padrão deve mantê-lo como, por exemplo, usar somente verbos no infinitivo.  Granularidade: agrupar somente rótulos de abrangência semelhante. Evitar que fiquem no mesmo nível rótulos com o significado mais geral (ex: automóveis) com rótulos mais específicos (ex: carros europeus).  Completude: mostrar todo o escopo de rótulos, para evitar que o usuário sinta falta de algum produto ou assunto.  Audiência: não misturar rótulos de públicos diferentes, não misturar linguagens técnicas com linguagem popular. Para sites com mais de uma audiência é importante a criação de um sistema de rótulos diferentes.

38 2.3.4 Sistema de Busca Rosenfeld e Morvile (citado por REIS, 2007a) mostram que o sistema de busca está meio que consolidado e padronizado, ou seja, é algo a parte que pode ser encaixado a qualquer momento no site sem precisar de esforço maior como os sistemas anteriores. Sites como Google.com e Yahoo.com possuem tutoriais demonstrando como adicionar os respectivos sistemas de busca nos sites. Portanto é uma tarefa que não requer maior esforço de análise. 2.3.5 Principais Documentos O Wireframe tem o objetivo de estruturar o conteúdo das principais interfaces do site, geralmente página principal e página interna. Nele são organizados os elementos que devem compor a interface, a hierarquia entre eles e os agrupamentos. Figura 15: Wireframe. Fonte: fatorw.com

39 O sitegrama é uma forma gráfica de representar toda a estrutura hierárquica do site, o formato é de uma arvore em que existe um nó inicial que representa a home-page e a partir dele são criadas ramificações equivalentes aos diversos níveis de conteúdo do site. Figura 16: Sitegrama. Fonte: Reis, 2007c 2.4 UTILIZAÇÃO DOS PADRÕES WEB Antes de entrarmos especificamente nas tecnologias conhecidas por Padrões Web iniciaremos com uma breve explicação sobre a importância da padronização. 2.4.1 A importância da padronização Começaremos mostrando um caso real e os problemas que causa a falta de padronização. É sobre as tomadas elétricas. Não existe um padrão internacional para plugs elétricos. Cada país desenvolveu seu próprio padrão. Na parte A da figura 17 podemos perceber a variedade de adaptadores elétricos, que as pessoas que viajam com freqüência para outros países, têm que se preocupar em levar, para poder utilizar o laptop, recarregar um celular ou mp3 player. Na parte B podemos notar a variedade de plugs disponíveis no Brasil, são mais de 10 tipos no total. Tudo isso causa problemas, pois geralmente tentamos forçar determinados plugs em tomadas que não foram feitos para eles, gerando desperdício de energia e risco de choque elétrico. Pensando nesses problemas a ABNT criou o padrão nacional para plugs e tomadas. Que pode ser visto no item C. Esse modelo padrão é compatível com 80% dos aparelhos elétricos atuais e está sendo implementado de forma gradativa.

40 Figura 17: plugs e tomadas variadas e padrão ABNT. (fonte: Inmetro) Ficou muito claro, com o exemplo dos plugs e tomadas, que a padronização diminui a complexidade, elimina diversas barreiras, aperfeiçoa os serviços ou produtos e garante a segurança. Ficou evidente também que a falta de padronização gera problemas complexos muito mais difíceis de serem revertidos. Podemos notar também que a padronização está muito ligada às áreas dos conhecimentos citadas nesse trabalho, já que ela permite uma organização melhor, pois os componentes são bem conhecidos e não há mudança neles. Permite um conforto maior do usuário final, pois ele não precisa se preocupar se o aparelho irá ou não encaixar na tomada, nem vai se preocupar com os riscos do choque elétrico. Conseqüentemente também elimina as barreiras já que o aparelho elétrico que seguir o padrão funcionará corretamente em qualquer tomada que também siga o padrão. É importante ter ciência também que o processo de criação do padrão é árduo, pois são pensadas todas as variáveis envolvidas em determinado produto, incluindo economia na sua criação, produtividade no processo, preocupações com o tipo de material que não pode ser tóxico

41 ao ser humano por exemplo, e atualmente a preocupação com o meio ambiente. Dependendo do tipo do produto a equipe de padronização precisará de uma ou mais dessas variáveis citadas. 2.4.2 Padrões Web: Definição e Vantagens Existe um consórcio de empresas (W3C) que ano após ano estão trabalhando arduamente para garantir que suas tecnologias sejam desenvolvidas de forma que quando forem utilizadas pelos desenvolvedores, fique bem clara a utilidade e o ganho com organização e produtividade que eles possam ter. O termo Padrões Web é justamente o nome que se dá a essas tecnologias criadas pelo W3C. As principais tecnologias são utilizadas nesse trabalho é a linguagem de marcação XHTML e a linguagem de formatação CSS, cada uma criada para uma finalidade específica. Mostraremos agora as vantagens de utilizar os Padrões Web. Começaremos identificando na próxima figura as metodologias comumente usadas em equipes de desenvolvimento de sistemas web.

42 Figura 18: Processo de desenvolvimento de sites comumente utilizado O processo que comumente se encontra em equipes de desenvolvimento de sites é principalmente o caminho do lado esquerdo começando pelo design, depois inserindo a programação. Porém em equipes de desenvolvimento de sistemas pode-se encontrar o processo representado pelo caminho da direita onde começa a programação dos formulários de cadastro, consulta, alteração e, só depois a aparência é aperfeiçoada por um Designer. Podemos detectar que, independente do caminho que a equipe seguir (esquerdo ou direito), o processo anterior se caracteriza por ser seqüencial em que o programador só dará continuidade quando o design estiver pronto e vice-versa. A outra questão é o alto nível de dependência de ambos profissionais quando for necessária alguma modificação. Já que é provável que o código por trás do design não esteja muito organizado, complicando a vida do programador e por outro lado a codificação avançada poderá deixar o designer perdido gerando dessa forma uma crise no desenvolvimento

43 por se tratar de etapas distintas feitas de formatos e focos diferentes. Em algumas equipes é possível verificar conflitos maiores inclusive de um profissional jogando a culpa para o outro, pois não falam a mesma língua, não tem um ponto em comum para unir seus pontos de vista. Conseqüentemente a equipe pode se desgastar e perder um pouco a motivação e é bem claro que o produto final (site) poderá ficar comprometido com relação à qualidade técnica. Vejamos agora outra forma de processo quando utilizamos os Padrões Web para os propósitos que foram concebidos: Figura 19: Processo que utiliza os padrões web de forma adequada Depois de concluído o levantamento de conteúdo o primeiro passo é a criação da Página em XHTML. Essa página é criada em conjunto entre o designer e o programador, nessa etapa haverá a utilização adequada das tags de acordo com o tipo de conteúdo que se deseja mostrar além da hierarquização da página com os títulos (h1 a h6), para que facilmente diversos tipos de usuários, inclusive robôs de busca, possam localizar o conteúdo mais importante da página e conseqüentemente seus respectivos subordinados em ordem descendente.

44 Depois de concluído o código do XHTML simplificado, ele é repassado tanto para o designer quanto para o programador que em paralelo irão desempenhar suas respectivas funções: O designer depois de criar o layout baseado no conteúdo irá formatar o código XHTML através das folhas de Estilo (CSS) que no final do projeto ficará em um arquivo a parte. Já o programador irá disponibilizar as rotinas de consulta a banco de dados buscando o conteúdo que será mostrado naquela estrutura XHTML criada inicialmente. Outro ponto interessante para se notar é que o trabalho do programador e do designer nesse modelo é independente, portanto com um pedido de modificação do layout, o designer fica livre para fazer a modificação. O programador também se sentirá à vontade para inserir novas funcionalidades, pois existe uma linguagem universal entre eles que é o XHTML utilizado da maneira para a qual realmente foi feita que é representar conteúdo. Nesse modelo acabaram os conflitos entre programador e designer e os dois passaram a se entender melhor. É perceptível o ganho em consistência e qualidade. 2.4.3 Marcação Válida e Marcação Semântica: evitando distorções Vamos agora tentar entender a diferença entre dois conceitos básicos: Marcação válida e marcação semântica. Zeldman (2007) mostra que marcação válida é quando não contém erros de sintaxe (ex: esquecer de fechar tags) e não contém tags ou atributos ilegais (ex: o atributo height que não é permitido em tabelas). Em seguida afirma que marcação semântica é quando as tags representam o tipo de conteúdo para qual foram projetadas, por exemplo, quando colocamos a tag de título h1 marcando o trecho de conteúdo mais importante da página é uma prática de marcação semântica. Colocando o h1 para um trecho somente para deixá-lo um pouco maior visualmente sem ter a certeza de que o trecho é realmente mais relevante não é uma prática de marcação semântica. Uma página web pode ser válida sem ser semanticamente estruturada que é o caso dos layouts de tabela em que as marcações das células da tabela são usadas para criar uma aparência visual e não para representar o conteúdo, porém elas não apresentam nenhum erro de sintaxe ou de atributos ilegais e, portanto são válidas. O inverso também é possível como uma tabela representando um calendário (marcação semântica) só que com algumas tags sem fechar (não válido). Os profissionais que tentam criar páginas baseadas nas boas práticas dos Padrões Web

45 se preocupam tanto em deixar a página válida quanto em escolher as tags apropriadas para cada trecho de conteúdo conseguindo também uma marcação semântica. O que ainda muitos desenvolvedores confundem e inclusive instrutores que repassam de forma distorcida é com relação ao conceito do código HTML voltado para a sensação visual, provavelmente devido à herança das práticas do layout de tabela que era utilizada quando o código CSS ainda não era suportado nos principais navegadores. Outro complicador é o fato da percepção do ser humano ser voltada de forma muito intensa para o sentido da visão. Então poderá acontecer que alguns profissionais falarão que é melhor usar a tag h3 já que a tag h1 fica grande demais no navegador e a tag h6 ficar quase ilegível (concepção presa na formatação). Só que o pensamento correto é: podemos usar h1 para o título que realmente for o mais importante da página e sucessivamente nos demais quando forem menos relevantes que o principal. Na figura 12 podemos notar uma renderização dos títulos disponíveis variando de h1 a h6 e podemos perceber que há uma formatação prévia com mudanças significativas de tamanho entre eles. Só que essa renderização no navegador é só uma intenção de mostrar a relevância de cada um. Eles podem e devem ser modificados pelo CSS em tamanho, cor e efeitos dependendo da necessidade. Código 1: Renderização inicial das tags de título h1 a h6 no navegador

46 Fazendo pequenas modificações no CSS no mesmo arquivo temos o resultado abaixo: Código 2: Renderização das tags de título h1 a h6 modificadas pelo CSS Como podemos perceber na figura acima, uma simples inclusão no arquivo com um bloco de formatação em CSS, já serviu para inverter visualmente o Código 1, deixando dessa vez o título h1 com o menor tamanho e o h6 com tamanho maior. Esse exemplo simples já derruba qualquer argumento superficial de explicação de tags de representação de conteúdo com conceitos de formatação. Fica bem claro a partir de agora o papel do XHTML e que, quando o desenvolvedor estiver criando, deve pensar no arquivo independente de como ele ficará depois com o CSS. Para termos uma noção de como fica uma página construída sem essa prática de deixar o XHTML semanticamente e hierarquicamente organizado, construímos uma nova versão do arquivo de títulos agora com localizações aleatórias, sendo do mesmo tamanho:

47 Código 3: Renderização das tags de título h1 a h6 com posicionamento aleatório Podemos notar no resultado da renderização da figura anterior que falta uma seqüência lógica entre os títulos, provocando uma sensação de desorganização, de falta de ordem. Não existe começo, meio e fim. Todos os títulos estão em um mesmo nível e aleatoriamente espalhados. Não tem como saber qual o mais importante visualmente. Essa é uma tentativa de criar uma analogia aos problemas que robôs de busca, dispositivos móveis e usuários com deficiência visual passam para poder captar, entender ou indexar o conteúdo de páginas que não seguem a linha dos padrões web de separação entre conteúdo e formatação. Essas páginas são popularmente chamadas de “sopa de tags”, por se tratar de uma mistura de vários tipos de conteúdo onde não conseguimos ver as partes se encaixando ou se diferenciando. Não conseguimos separar o essencial do supérfluo. Quando temos uma estrutura que não se consegue obter a informação prioritária, devido ela estar perdida entre diversas outras, podemos dizer que é uma estrutura pobre com relação aos requisitos de acessibilidade que estamos buscando. O trabalho da acessibilidade visa fugir desses paradigmas superficiais que podem causar problemas no produto final. A página poderá, ao ser finalizada, já ser considerada obsoleta, caso seja feita sem preocupação com a marcação semântica. Uma empresa pode querer uma expansão do site para que usuários com necessidades especiais

48 consigam acessar e comprar os produtos sem problemas. Pode também querer ampliar o alcance da página para que possa ser acessada via dispositivos móveis. Nesses dois casos, se a página for feita baseando nas técnicas e conceitos e tecnologias envolvidas nos Padrões Web, essa expansão será uma etapa simples de ser realizada. Por outro lado ser for utilizada técnicas que não tenham preocupação maior com a organização e hierarquização do conteúdo, é muito provável que seja preciso criar uma nova página para poder expandir o site conquistando o objetivo desejado. Só que outra página significa mais tempo e dinheiro, no caso do cliente. No caso do desenvolvedor, ter que fazer um novo site devido o primeiro não se adequar às diretivas de acessibilidade, mostra que ele está precisando se atualizar para as necessidades do mercado, pois, atualmente desenvolvimento de páginas utilizando Padrões Web já não é mais visto, nos principais centros como diferencial e sim algo que já espera ser feito. 2.4.4 Principais tags do XHTML É importante começarmos diferenciando os elementos em bloco dos elementos inline: 1. Em bloco: podem conter elementos inline e outros elementos de bloco 2. Inline: devem conter apenas dados (textos) e outros elementos inline. A diferença é que elementos de bloco criam uma estrutura maior que os elementos inline. Para blocos de conteúdo div e span - essas duas marcações são utilizadas em conjunto com os atributos id e class oferecendo um mecanismo genérico de adicionar estruturas ao documento. O span define conteúdo do tipo inline, enquanto o div define conteúdo em bloco. O div (divisão) será bastante utilizado para separar a página em seções de conteúdos definidos por ids (atributo id) como: cabeçalho, menu, conteúdo, rodapé, etc. Já o span servirá para demarcar trechos do texto. p - parágrafos. Listas – serão muito utilizadas para os menus de links (lista de links)

49 ul, ol, li – listas enumeradas e não enumeradas. dl, dd, dt - listas de definição (representar por exemplo um dicionário) Tags com significado específico h1, h2, h3, h4, h5, h6 – títulos que podem ser classificados em seis níveis de importância, quanto menor o número que acompanha o h, maior a relevância na página. strong – texto forte, usado quando se quer destacar determinados trechos de palavras como mais relevantes que os demais, a formatação padrão é deixar em negrito. em – texto enfatizado, a formatação padrão é em itálico acronym - acrônimo abbr - abreviatura q – citação curta, utilizada em uma mesma linha blockquote – citação longa, um bloco. pre – texto pre-formatado, é mostrado o texto do jeito que foi digitado no código. code - para mostrar código de computador 2.4.5 Exemplo de utilização de marcação semântica Na figura a seguir é possível notar as diversas tags do XHTML sendo utilizadas no contexto ao qual foram criadas. Com esse exercício fica fácil para o desenvolvedor seguir o princípio da marcação semântica que é de escolher a tag apropriada para cada trecho de conteúdo. Lista ul para links. Hieraquizar o conteúdo com tags de títulos h1-h6, entre outras.

50 Figura 20: Página do acesso digital que utiliza marcação semântica 2.4.6 Entendendo o box model Toda marcação HTML é apresentada no navegador com o formato de uma “caixa” retangular cuja formatação pode ser modificada pelo CSS. Essas caixas são colocadas em seqüência uma após a outra. Elas são formadas por margens, bordas, espaçamentos e o conteúdo propriamente dito. Uma divisão <div>, um título <h1>...<h6> ou um parágrafo <p> criam uma caixa quando são exibidos. Se uma marcação for colocada no interior de outra marcação, então sua caixa será exibida dentro da caixa do elemento em que está contida. Por exemplo, um parágrafo <p> se for codificado dentro de uma divisão <div> visualmente pertencerá a esse bloco div e não a outro.

51 No exemplo seguinte será possível compreender as noções de espaçamento e já aprender uma técnica de borda, com um efeito na diagonal, que poderá utilizar no dia-a-dia do desenvolvimento. Nele teremos como resultado visual duas caixas: a) div geral e a b) título h1. sendo que o título está contido dentro do div. Vamos agora a definições importantes:  Espaçamento (padding): é o espaço entre a borda do elemento e o conteúdo (interno).  Margem (margin): espaço externo a partir da borda A técnica consiste em utilizar a borda inferior com contraste relevante com relação ao plano de fundo, nesse caso optamos pela cor preta e a borda lateral utilizará a mesma cor do fundo, deixando-a imperceptível e criando uma curva diagonal na extremidade da borda inferior. Nesse caso, para dar o espaçamento do elemento interno com relação ao externo, ao invés de criar uma margem interna, utilizamos um padding externo. As bordas podem variar nas seguintes formas:  border - coloca a borda circundando completamente o elemento  border-top, border-right, border-bottom, border-left - respectivamente as bordas no topo, direita, em baixo e na esquerda independentes uma da outra. Utilizamos também um recurso de redução de código para o espaçamento que segue o padrão - padding: topo direita baixo esquerda;

52 </html> Código 4: Detalhamento do box model junto com exemplo de borda diagonal Por mais que o desenvolvimento dos navegadores seja baseado nas especificações do W3C, ainda existem algumas diferenças de renderização entre, por exemplo, o Firefox e o Internet Explorer. 2.4.7 Centralizando elementos na tela com CSS Na seqüência de imagens abaixo mostraremos uma técnica para conseguir o mesmo efeito de centralização em ambos os navegadores. Na primeira figura notaremos que o Internet Explorer quando utilizamos a propriedade text-align:center ele centraliza todos os elementos dentro do div. E não somente o texto como ocorre no Firefox.

53 Código 5: Centralização de elementos com CSS – parte 01 Nessa segunda figura veremos uma forma de centralização no Firefox utilizando o margin:0 auto. O Zero anula a margem superior e a inferior. O auto indica que a margem esquerda será do mesmo tamanho que a margem direita, centralizando, portanto o div interno. Só que esse valor auto não funciona no Internet Explorer. Código 6: Centralização de elementos com CSS – parte 02 Finalmente na próxima figura conseguiremos o resultado desejado de centralizar os elementos em ambos os navegadores. Utilizando as duas técnicas anteriores com o text- align:center no div mais externo e complementa com margin:0 auto; no div mais interno.

54 Código 7: Centralização de elementos com CSS – final 2.4.8 Quirks Mode, Strict Mode, hacks e Comentários Condicionais Quirks Mode e Stric Mode são as formas que os browsers podem usar para interpretar o CSS. O Netscape 4 e o Explorer 4 implementaram CSS de forma particular sem seguir as especificações do W3C. O IE5 eliminou muitos bugs, porém ainda permaneceu o problema do box model que renderizava de forma diferente. Com o passar do tempo os padrões foram ficando importantes e essa renderização dentro da especificação ficou conhecida como Strict Mode (modo estrito) diferente do Quirks Mode (modo peculiar). Como os navegadores não podiam simplesmente deixar de lado o Quirks Mode então desenvolveram técnicas que ativariam um ou outro modo para manter compatibilidade com as páginas antigas. A solução foi o uso de ativação de modo strict por doctype. Caso a página possua o doctype correto o navegador irá interpretar o CSS no modo strict. Caso contrário eles vão trabalhar Quirks Mode, que é o caso do Internet Explorer e do Ópera. A exceção dessa regra vai para o Mozilla Firefox e o Safari que sempre trabalham em Strict Mode. Para a versão 6 do Internet Explorer, a Microsoft implementou uma forma de a página ser validada pelo W3C e ao mesmo tempo trabalhar em Quirks Mode. A solução era utilizar um prólogo XML antes do Doctype. (<?xml version="1.0" encoding="iso-8859-1"?>).

55 Para resolver esse problema, nos exemplos seguintes não será permitida a utilização do Prolog XML no início do documento, ele deve ser deixado de lado. Além disso, deveremos colocar o doctype para que os navegadores modernos renderizem todos em Strict Mode. Atualmente, dependendo do público alvo do site, o desenvolvedor poderá tomar a decisão de se preocupar somente com a renderização da página em Strict Mode. O site ficaria bem renderizado no Firefox, Opera, Internet Explorer 6 e 7, mas teria problemas para Internet explorer 5 ou menor. Na figura abaixo será mostrada a diferença entre a renderização do CSS no Quirks Mode e no Strict Mode. Código 8: Renderização em Quirks e em Strict Mode.

56 Porém, caso seja necessário, podemos utilizar o seguinte hack em um arquivo isolado. Uma vez retirado o hack da folha de estilos principal ele será colocado em iehacks.css e deverá ser chamado através de um link utilizando Comentários Condicionais CCs conforme mostrado abaixo (JOHN, 2005): iehacks.css #topo { width: 770px; width: 750px; /* hack: essa linha é ignorada no IE5 e IE5.5*/ }  Código 9: Resolvendo o problema do box model – parte 01 A segunda propriedade com o caractere de "escape" dentro dela faz com que os navegadores IE5 e IE5.5 para windows ignorem a letra "t", dessa forma a propriedade é ignorada e a renderização ocorre com o width de 770px. Já os navegadores IE6 e IE7 não desprezam a segunda propriedade e conseqüentemente renderizam a página com o width de 750px. É possível também deixar de lado o uso de hacks e colocar as formatações específicas do IE5 em um arquivo e as formatações para IE6 e IE7 em outro arquivo e utilizar uma especificidade dos Comentários Condicionais indicando o tipo de navegador que irá renderizar determinado arquivo como segue na figura a seguir.

57   Código 10: Resolvendo o problema do box model – parte 02 Na figura anterior teremos o primeiro arquivo que será universal para todos os navegadores IE e no segundo arquivo teremos a formatação que será renderizada somente para os IE que iniciam com o número 5, ou seja, vale para o 5.0 e o 5.5. 2.4.9 Exemplo de Página com Layout 3 colunas A partir de agora mostraremos uma seqüência de criação de uma página simples junto com as principais técnicas e recursos. O nome do site será Blog now, a idéia é de uma estrutura simples para se criar um blog. 2.4.9.1 Criação do código XHTML da página A seguir será mostrado o código XHTML da página limpo sem formatação alguma e logo em seguida será mostrado sua renderização.

58 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <title>Layout 3 colunas</title> </head> <body> <div id="geral"> <div id="topo"> <h1>Blog Now</h1> <h2>Faça <span class="enfase">Seu Próprio Site</span>, de forma automatizada simples, além de contar com suporte técnico de alta qualidade! </h2> </div> <div id="menu"> <h3>Menu</h3> <ul> <li><a href="#">Cadastre agora</a></li> <li><a href="#">Perguntas Freqüentes</a></li> <li><a href="#">Fale Conosco</a></li> </ul> </div> <div id="propaganda"> <h3>Publicidade</h3> <p>Lorem ipsum dolor...</p> </div> <div id="conteudo"> <h3>Conteúdo</h3> <p>Suspendisse convallis pellentesque mi...</p> </div> <div id="rodape"> <p>Copyright - todos os direitos reservados.</p> </div> </div> </body> </html> Código 11: Blog now: código XHTML Podemos perceber que no código teremos 5 divs principais: topo, menu, conteúdo, propaganda e rodapé com o objetivo final é de criar um layout 3 colunas. Para facilitar a centralização do layout, iremos colocar um div adicional com id = “geral” que agrupará todo o conteúdo internamente. Para esse exemplo o div central deve ser colocado após os divs da esquerda e direita.

59 Figura 21: Blog Now: Renderização do código no navegador 2.4.9.2 Usando a propriedade float para criação do layout O float possui é uma propriedade essencial na criação de um layout, pois ele faz o elemento “flutuar” (posicionar) à direita ou à esquerda. Em conjunto será utilizada a propriedade clear que poderá cancelar o efeito de uma renderização de um elemento anterior pelo float em um elemento atual. Ele pode ter os valores: left, right, both (desabilita o float: left e o float: right).

60 div { border:1px solid black; } body { text-align:center; font:13px Arial, "Trebuchet MS", Tahoma, Helvetica, sans- serif; } #geral{ text-align:left; width:770px; margin:0 auto; } #topo { height:120px; } #rodape { height:120px; clear:both; } #menu, #propaganda{ height:412px; } #menu { float:left; width:225px; } #propaganda{ float:right; width:269px; } #conteudo{ margin:0 245px; border:0;} Código 12: Blog Now: CSS parte 01

61 Figura 22: Blog Now - renderização do CSS – parte 01 2.4.9.3 Usando a técnica de Image Replacement Image Replacement é o nome dado à técnica de substituição de texto por imagem de fundo. Existem diversos modos e o modo escolhido para esse trabalho utilizará o seguinte método:

62  Na tag escolhida colocamos a imagem de fundo usando background: url(logomarca.jpg) no-repeat;  Usamos depois atributo text-indent:-5000. Um valor alto que vai fazer com que o texto se desloque para além da área visual do monitor.  Para garantir que mesmo em monitores grandes o texto não poderá ser visualizado finalizamos com a propriedade overflow:hidden; que apaga todo o conteúdo que ultrapassar a área da caixa. #topo h1 { font-size:32px; color:white; margin:0; /*image replacement*/ height: 52px; background: url(logomarca.jpg) no-repeat; text-indent: -5000px; overflow: hidden; } Código 13: Blog Now: aplicando Image Replacement O exemplo acima poderia ser feito utilizando imagens também (<img>). A técnica Image- replacement é indicada mais para elementos que não fazem parte do conteúdo da página como bordas, sombras. Porém ela permite ampliar as possibilidades visuais como substituir uma lista de tarefas em texto por uma imagem bem mais amigável. Figura 23: Blog Now - Renderização da imagem no lugar do texto

63 2.4.9.4 Tratamento de listas Para garantir uma renderização adequada de listas nos diversos navegadores eliminamos a renderização default zerando as margens e os espaçamentos e eliminamos o estilo das bullets, depois disso é só complementar com a formatação desejada. ul { margin:0; padding:0; } ul li { list-style-type:none; } ul li a { color:#22568F; text-decoration: none; display: block; height: 16px; width: 180px; font-size:18px; margin-bottom:15px; } /* quando o mouse passa por cima muda a cor */ ul li a:hover{ color:orange; } Código 14: Blog Now: CSS de tratamento de listas Figura 24: Blog Now - renderização de uma lista de links

64 2.4.9.5 Código CSS completo O CSS completo, com os demais retoques e efeitos podem ser observados nos códigos abaixo: body { text-align:center; margin:0; padding:0; background:url(back2.jpg) repeat; font:13px Arial, "Trebuchet MS", Tahoma, Helvetica, sans- serif; } #geral{ text-align:left; width:770px; margin:0 auto; background:#fff; } #topo { border:4px solid #FF8E08; background:#FF6600; padding-left:20px; } #topo, { height:120px; } #rodape { height:120px; clear:both; border-top:1px solid #E4E4E4; padding-left:20px; color:gray; background:#E4E4E4; } #menu, #propaganda{ height:412px; } #menu { float:left; background:#fff url(coluna.jpg) -10px repeat-y; padding:5px 0 0 20px; width:225px; } Código 15: Blog Now: CSS completo – Parte 1

65 #propaganda{ float:right; width:269px; background:#fff; } #conteudo{ margin:0 245px; padding:2px 20px 10px 0; background:#fff url(coluna.jpg) repeat-y; width:230px; height:405px; } #topo h1 { font-size:32px; color:white; /*image replacement*/ background: url(logomarca.jpg) no-repeat; height: 52px; text-indent: -5000px; overflow: hidden; margin:0; } #topo h2 { width:600px; height:60px; font-size:22px; color:white; margin-bottom:40px; } .enfase { color:#FFFFCC; font-size:25px; } ul { margin:0; padding:0; } ul li { list-style-type:none; } ul li a { color:#22568F; text-decoration: none; display: block; height: 16px; width: 180px; font-size:18px; margin-bottom:15px; } ul li a:hover{ color:orange; } Código 16: CSS completo – Parte 2 2.4.9.6 Resultado final: interface do Blog Now

66 O resultado pode ser visto na figura abaixo. Esse é apenas um exemplo simples para aprender os conceitos. Para um código que vá ser usado para um site em produção é preciso um maior aperfeiçoamento através de pesquisas nas marcações CSS de outras páginas. Um ótimo exercício para aprimoramento é olhar o código CSS de interfaces padronizadas como as de blogs feito em WordPress ( Sistema de gerenciamento de conteúdo focado em blogs). Figura 25: Blog Now - Renderização Final

67 2.5 DIRETIVAS DE ACESSIBILIDADE As tecnologias e metodologias utilizadas para prover acessibilidade, desenvolvidas e recomendadas pelo consórcio W3C, tornam possível a detecção do nível de acessibilidade de um site. Elas baseiam-se nos seguintes parâmetros:  1° nível (A) - É preciso ser feito. Se não fizer, algumas pessoas não vão conseguir acessar o site;  2° nível (AA) - Deve ser feito. Se não fizer, algumas pessoas vão ter dificuldades em acessar o site;  3° nível (AAA) - Pode ser feito. Se fizer, vai melhorar muito a experiência de algumas pessoas. Outro ponto importante é que existem alguns sites que detectam níveis de acessibilidade no quesito da sintaxe. Por exemplo, se está faltando o atributo alt em uma imagem. Para isso é possível acessar os seguintes links:  Da Silva: http://www.dasilva.org.br/ - verificador de acessibilidade em português.  Lista completa de ferramentas de acessibilidade: http://www.w3.org/WAI/ER/tools/complete Na acessibilidade tem muitos aspectos que somente o validador sintático não poderá dar conta. Uma verdadeira acessibilidade só é possível com desenvolvedores que conheçam e que estejam comprometidos com as recomendações de acessibilidade e que não se contentam somente com a validação sintática e sim com uma página que seja realmente útil para seus usuários. O propósito dessa monografia não é detalhar os três níveis e sim dar uma explanação geral em cima das 14 recomendações de acessibilidade que acabam principalmente dando conta do nível A e em parte dos demais níveis.

68 2.5.1 Fornecer alternativas ao conteúdo sonoro e visual Essa recomendação é para que as imagens que represente conteúdo sejam publicadas junto com um texto alternativo. Por exemplo, <img src="logomarca.gif" alt="UERN" />. Com relação ao texto alternativo, é muito importante ter bom senso na hora de colocar. Não é adequada descrição minuciosa de detalhes visuais, pois serão irrelevantes. É importante que a descrição seja pequena e que sirva para designar funções. Tudo que for escrito no alt será lido pelo leitor de tela, por isso, além do bom senso da descrição ser breve e coerente com o tipo de imagem e da página onde ela se encontra, é preciso usar técnicas para que os leitores de tela desconsiderem aquelas imagens que só servem para decorar a página, como bolinhas e linhas horizontais. É possível fazer isso utilizando o atributo "ALT vazio", que significa colocar um espaço em branco entre as duas aspas. Ex: <img src="linha-horizontal.gif" alt=" " />. Lembrando de não confundir com "ALT nulo", que seria com as aspas juntas, sem o espaço em branco separando. Ex: <img src="linha-horizontal.gif" alt="" />. Segundo (Queiroz, 2003) esse último exemplo de "ALT nulo" deve ser evitado porque alguns softwares leitores de tela não o entenderão como um “ALT vazio” e conseqüentemente tentarão ler o conteúdo do atributo src. Na imagem anterior ele seria "linha-horizontal.gif". Isso pode prejudicar bastante a usabilidade da página, já que toda vez que o software leitor passar sobre a imagem, pronunciará o texto dentro do atributo src. É possível fornecer descrições mais detalhadas através do atributo longdesc cujo valor recebe o caminho para uma página que terá a descrição detalhada. Segundo (Queiroz, 2003) somente leitores de tela como "JAWS" conseguem absorver esse recurso através da sonorização "press enter for long description". Os testes4 feitos com Jaws 7.10 mostraram que no IE7 funcionou corretamente, porém no Firefox sonorizava a instrução de apertar Enter, mas não funcionava depois que o Enter era apertado, permanecendo a mesma página ativa. Outra técnica mostrada por (Queiroz, 2003) é o "d.link", que é um link criado com uma imagem transparente onde o ALT possui o valor "D" em maiúsculo. Esse link leva para uma página com a descrição mais detalhada a respeito da imagem, para garantir que somente quem estiver realmente interessado, acesse essa página de detalhamento. O exemplo com "d.link" 4 Os teste foram realizados pelo autor desse trabalho utilizando Jaws 7.10, instalado no Windows XP.

69 funcionou tanto no IE7 como no Firefox. Podemos usar a seguinte redundância para garantir a acessibilidade: <div> <img src="logouern.jpg" longdesc="descricao.htm" alt="logo da UERN" /></br> <a href="descricao.htm"><img src="img_transparente.jpg" alt="D"></a> </div> Código 17: Descrição redundante com imagem transparente. Uma alternativa que evita a utilização da imagem transparente é simplesmente adicionar um link descritivo, para a página de descrição detalhada, logo após a imagem. Podemos ver isso no exemplo abaixo: <div> <img src="logouern.jpg" longdesc="descricao.htm" alt="logo da UERN" /></br> <a href="descricao.htm">detalhamento da logomarca UERN</a> </div> Código 18: Descrição redundante sem imagem transparente. Para colocar conteúdo embutido no site como arquivos swf (flash), applets Java ou vídeos, utilizaremos a tag object. No exemplo abaixo caso o navegador não tenha suporte a flash aparecerá o texto no parágrafo logo após a tag que importa o swf como podemos ver no caso 1. No caso 2 é equivalente ao anterior só que substitui por uma imagem ou em última instância pelo texto alternativo da imagem.

70  <object type="application/x-shockwave-flash" data="patrocinadores.swf" width="200" height="150"> <param name="movie" value="patrocinadores.swf" /> <p>Patrocinadores do evento: ...</p> </object>  <object type="application/x-shockwave-flash" data="patrocinadores.swf" width="300" height="90"> <param name="movie" value="patrocinadores.swf" /> <img src="xis.gif" width="300" height="90" alt="Patrocinadores do evento: ..." /> </object> Código 19: Descrição redundante com imagem transparente. Caso o exemplo anterior seja carregado com sucesso é muito provável que não seja acessível aos leitores de tela. Acessibilidade em flash não faz parte do escopo desse trabalho, porém caso o arquivo swf rode normalmente no navegador é possível tomar três caminhos para deixá-lo acessível para os softwares leitores de tela. Segundo um artigo do WebAIM (Web Accessibility in Mind): 1. Tornar o conteúdo flash nativamente acessível ao leitor de tela; 2. Criar o arquivo flash com áudio embutido nele, eliminando a necessidade de ter o leitor de tela; 3. Prover acessibilidade alternativa ao conteúdo flash.

71 Com o áudio embutido no próprio arquivo flash, o leitor de tela deve ser avisado que o arquivo contém áudio embutido para poder ser pausado, enquanto o flash apresenta o conteúdo de áudio. O vídeo também deve ser acessível através do teclado. É importante também fornecer uma alternativa ao flash. O ideal é fazer essa página alternativa o máximo possível equivalente, não necessariamente em formato de somente texto. Ao invés de fornecer páginas longas de texto puro, é preferível uma página que seja bem formatada e acessível com imagens, ícones, parágrafos e cores, já que essa página poderá ser acessada por qualquer usuário, com necessidade especial ou não. Essa página alternativa poderá estar na mesma página que o conteúdo flash. É possível colocar também uma opção de desabilitar ou habilitar o flash. Outra opção é fornecer uma versão do arquivo com legendas ou um arquivo com a descrição dos diálogos semelhante ao que é feito com o site charges.com.br (ver figura 26). Essa técnica é útil para pessoas que tem problemas com audição. Figura 26: Exemplo vídeo com legendas. Fonte: charges.com.br Para finalizar essa recomendação 1, é muito importante também fornecer redundância textual aos mapas de imagens existentes na página, que poderá ficar em um local mais discreto da página como o rodapé ou simplesmente escondido utilizando CSS. Isso é necessário devido aos navegadores terem dificuldades de trabalhar com os mapas de imagem de cliente e de servidor.

72 2.5.2 Não recorrer apenas à cor Existem fatores como monitores monocromáticos e pessoas que não conseguem diferenciar certas cores (cromodeficiência). Para adaptar a interface aos dois casos é muito importante garantir os seguintes itens: 1. Fornecer contraste suficiente entre texto e fundo, para evitar desconforto na leitura e garantir legibilidade do texto. 2. Garantir uma alternativa a todas as informações veiculadas com cor. Procurando fazer com que elas fiquem compreensíveis sem cor. Pode por exemplo modificar o formato do link para negrito ou itálico quando for clicado ou mesmo ampliar o tamanho da fonte via CSS. Outra possibilidade é inserir um caractere sugestivo no início o no final do link, para que o diferencie do texto comum. 2.5.3 Utilizar corretamente marcações e folhas de estilo Nesse ponto será essencial que a página XHTML final seja válida e também tenha marcação semântica. Válida porque a sintaxe deve estar correta para que seja adequadamente manipulada por parsers ou indexadores e semântica porque cada conteúdo na página deve ter sido marcado com a tag apropriada para ele. Além de haver uma hierarquia de títulos (hx) para que os leitores de tela e os robôs de busca consigam agrupar o conteúdo em níveis de relevância. Lembrando que h2 deve ser colocado em um conteúdo que representa uma subseção de h1 e assim sucessivamente. Além disso, veja os seguintes pontos:  Garantir que foi colocado o doctype adequado no inicio do documento;  Garantir que não está sendo mais utilizado tags font no HTML pois a formatação deve ser completamente realizada pelo CSS;  É importante que priorize a utilização de medidas de tamanho relativo ("em" ou "percentagens") ao invés de absoluto (px) para dar mais flexibilidade a página;  Garantir que as listas ol, ul, dl estão sendo utilizadas corretamente;

73  Garantir a utilização de citações adequadamente q e blockquote, respectivamente para citações curtas e extensas. Em todos os casos mostrados é preciso que evite utilizar essas tags para efeitos de formatação devemos seguir estritamente as regras semânticas de representação de cada tag, deixando a formatação para o CSS. 2.5.4 Indicar claramente qual o idioma utilizado Isso é muito importante para que robôs de busca possam identificar o idioma de determinado documento. Outra importância é que isso permitirá que sintetizadores de voz consigam detectar que o trecho de conteúdo está em um idioma diferente do restante da página e conseqüentemente emitirá a pronúncia equivalente à língua. O padrão é começar a página na língua nativa do conteúdo como no exemplo a seguir:  <html lang="pt"> .... </html>  <cite lang="en">any english text</cite> Código 20: Identificação do idioma do conteúdo Uma lista de códigos que poderão ser usados pode ser encontrada no seguinte endereço: http://www.loc.gov/standards/iso639-2/php/code_list.php. É preferível que se use o código de duas letras como pt, en, caso a linguagem também possua o código de três letras. Outra questão que precisamos saber é que muitos usuários não conhecem as siglas e jargões institucionais. Por isso, é muito importante utilizar o atributo "title" com a descrição correta junto com as tags acronym ou abbr, na primeira vez que determinada abreviação ou acrônimo for usado no documento. O acrônimo é uma palavra que é formada pelas iniciais das

74 palavras constituintes. Ex: ONU – Organização das Nações Unidas. A abreviação é quando uma palavra ou frase é reduzida em um formato mais curto: Ex: BR – Brasil.  <acronym title="Universidade do Estado do RN">UERN</acronym> <acronym title="Comissão Permanente de Vestibular">COMPERVE</acronym> <acronym title="Plano de Desenvolvimento Institucional">PDI</acronym>  <abbr title="World Wide Web">www</abbr> <abbr title="HyperText Markup Language">HTML</abbr> <abbr title="Cascade Style Sheets">CSS</abbr> Código 21: Utilização do atributo title em abreviações e acrônimos. 2.5.5 Criar tabelas passíveis de transformação harmoniosa Tabela aqui deve ser usado para mostrar dados cuja estrutura seja coerente com a natureza de colunas e linhas (informações tabulares). Ex: calendário, resultado de uma consulta em um banco de dados, estrutura de dados estatísticos comparando duas ou mais variáveis. É muito importante não utilizar tabelas com objetivo estético de posicionar elementos na página (formatação). Caso ainda utilize tabela para formatação, evite pelo menos que a leitura linear dela perca o sentido, como, por exemplo, evite utilizar tabelas aninhadas (tabelas dentro de tabelas). Leitores de tela como JAWS possui leitura linear então a organização poderá seguir uma estrutura linear para ficar mais intuitiva. Ex. Na tabela seguinte que representa um comparativo fictício de valores exportados nos anos entre 2004 e 2007: Ano 2005 2006 2007 Brasil 1 milhão 2 milhões 3 milhões Argentina 5 milhões 3 milhões 2,5 milhões China 5 milhões 10 milhões 15 milhões Tabela 1: Tabela que facilita a manipulação de softwares leitores de tela

75 A leitura da tabela anterior é muito intuitiva, pois o leitor de tela capta as opções de forma linear e facilmente é possível entender que o Brasil ampliou as exportações no decorrer dos anos e a Argentina diminuiu. Outra possibilidade um pouco menos intuitiva seria o exemplo abaixo: Ano Brasil Argentina China 2005 1 milhão 5 milhões 5 milhões 2006 2 milhões 3 milhões 10 milhões 2007 3 milhões 2,5 milhões 15 milhões Tabela 2: Tabela que prejudica a manipulação de softwares leitores de tela Nesse exemplo para sabermos detalhes sobre um único país através de um leitor de tela é preciso passar por dados de outros países, o que acaba confundindo um pouco. Nas células que identificam os cabeçalhos de cada coluna, e interessante a troca do td comum pela tag th, pois dessa forma fica fácil diferenciar o cabeçalho do conteúdo. Para tabelas com dados que não são tão intuitivos de compreender é interessante a utilização do atributo summary com um resumo da tabela para um esclarecimento efetivo. 2.5.6 Assegurar que as páginas dotadas de novas tecnologias sejam transformadas harmoniosamente É essencial que a página esteja acessível mesmo que o uso de tecnologias extra Padrões Web como Applets, Flash, Media Player, etc, não funcionem adequadamente, como no caso de navegadores antigos que não possuem suporte a essas tecnologias. É muito importante que a página permaneça compreensível no caso de navegadores estarem com o CSS desabilitados. As funcionalidades também não devem ser perdidas caso o javascript esteja desabilitado no navegador. É necessário também que efeitos criados por tecnologias como flash, no caso dos menus ou também os recursos utilizando DHTML sejam acessíveis também pelo teclado.

76 2.5.7 Assegurar o controle do usuário sobre as alterações temporais do conteúdo Esse ponto de verificação é essencial principalmente para deficientes cognitivos e visuais. Mas é essencial para garantir conforto e consistência para os demais usuários. Evite colocar objetos se mexendo na tela. Caso coloque sempre ofereça um controle, como, por exemplo, nos banners de propaganda que caminham pela página, sempre colocar um link para desativá-lo, mas só deve usá-lo se o propósito da página permitir. Um exemplo seria uma loja virtual que queira anunciar uma promoção. Evite que objetos pisquem na tela, se for realmente necessário, garanta transições suaves, pois quando o objeto pisca na faixa de 4 a 59 pulsos por segundo (Hz), pode desencadear ataques ou ausências nas pessoas com epilepsia fotossensível. Evite ao máximo a utilização do refresh automático e do redirecionamento automático de páginas. É desaconselhada também a utilização das tags Blink e Marquee, pois não estão definidos em nenhuma especificação HTML do W3C. 2.5.8 Assegurar a acessibilidade direta de interfaces do usuário integradas No caso de um objeto integrado possuir uma interface própria, como arquivos flash e applets que não utilizam as marcações HTML, essa interface deverá ser acessível através do navegador. Caso não seja acessível, é preciso disponibilizar uma página alternativa. É importante também que essas páginas em flash ou applets possam ser operadas via teclado. 2.5.9 Projetar páginas considerando a independência de dispositivos Ao elabora uma interface devemos imaginar que ela poderá ser manipulada ou acessada por diversos dispositivos de entrada e de saída, que também são muito diferentes dos desktops convencionais:  Dispositivos de entrada: PCs que não possui mouse, dispositivos móveis que não possuem teclado, Dispositivo que use um apontador diferente do mouse, entre outros.

77  Dispositivos de saída: monitores monocromáticos ou de tamanho muito reduzido, leitores de tela, entre outros. Se for realmente necessário usar mapas de imagem, prefira os mapas de cliente ao invés dos mapas de servidor. Para fornecer uma interação com os links mais lógica, é possível forçar a ordem de navegação pela tecla TAB utilizando a propriedade tabindex. Outra opção muito útil é inserir atalhos de teclado para os links mais importantes da página que podem ser disponibilizados através da propriedade accesskey. 2.5.10 Utilizar soluções de transição Esse ponto é preciso sempre está acompanhando as novas implementações de recursos nos navegadores, leitores de tela e demais softwares envolvidos na acessibilidade. O princípio aqui é que os softwares não têm um alcance absoluto e que aos poucos e de forma incremental esse alcance vai sendo ampliado, só que é possível que muitos usuários permaneçam utilizando softwares antigos que ainda não possui os últimos recursos de acessibilidade. Aqui o mais importante é bom senso e dependendo do caso utilizar soluções de transição, enquanto o acesso não for coberto pelos softwares disponíveis: Um dos mais polêmicos é o problema de acesso em alguns navegadores antigos e leitores de tela a campos de formulário vazios. No caso de equipes gerenciando intranets esse quesito já pode ser desconsiderado, pois nesse caso os navegadores estão constantemente sendo atualizados. No caso de páginas externas até certo ponto também pode ser desconsiderado, porém caso seja necessário manter compatibilidade com versões antigas de software uma opção é colocar algum texto dentro dos campos do formulário. Ex: "digite aqui seu email". Evite o uso de popups, devido alguns leitores de tela não avisar a abertura dela. Testando com o Jaws 7.1.0 no Firefox e ele avisa da nova janela que está sendo aberta, porém mesmo assim, incomoda muito mais do que ajuda, pois muda o foco para uma janela que não foi requisitada. Com a chegada dos bloqueadores de popups nativos no próprio navegador esse item agora é controlado totalmente pelo usuário, a ponto de simplesmente desconsiderar todos os

78 popups das páginas onde navegam, nesse caso é de bom senso que informações importantes não sejam colocadas em popups com o risco de passar despercebidas. É importante também utilizar a tag label ao lado do respectivo campo no formulário: <form> <label for="nome" >Nome:</label> <input name="nome" type="text" /> <br /> <label for="email">E-mail:</label> <input name="email" type="text" /> <br /> <input type="submit" value="Enviar" /> </form> Código 22: Utilização correta de labels em formulários. Outro ponto que ainda é muito importante é com relação aos links. Eles não podem estar separados somente por espaço em branco. Testamos com Jaws 7.1.0 no Firefox e não houve nenhum problema para links separados por espaço em branco ou por parágrafos ou por listas li. Porém o indicado para garantir acessibilidade para outros softwares ou versões antigas desses softwares é utilizar os seguintes formatos:  <ul> <li><a href="http://www.uern.br">UERN</a></li> <li><a href="http://www.ufersa.br">UFERSA</a></li> <li><a href="http://www.ufrn.br">UFRN</a></li> <li><a href="http://www.ufc.br">UFC</a></li> </ul>  [<a href="#">UERN</a> ] , [<a href="#">UFERSA</a> ] Código 23: Separando links por listas não ordenadas ou colchetes.

79 2.5.11 Utilizar tecnologias e recomendações do W3C O que há de mais atual e funcional no quesito acessibilidade está integrado nas tecnologias criadas pelo W3C de uma forma que possa ser utilizado com facilidade desde o início do projeto. Somente a separação entre conteúdo e formatação, cada qual usando a tecnologia apropriada para a tarefa, além de o conteúdo ser construído com as marcações semânticas, já garante um nível muito bom de acessibilidade. Além disso, é preciso deixar de lado todas as tags em desuso e obsoletas como, por exemplo, a tag FONT e evitar também a utilização de tabelas com objetivo estético. Claro que em projetos reais é muito provável que se utilize tecnologias que não foram criadas pelo W3C como Flash, applets ou PDF. Se realmente for imprescindível, é necessário que os conteúdos mais importantes tenham fontes alternativas e acessíveis. 2.5.12 Fornecer informações de contexto e orientações. A estratégia desse item é criar pontos de apoio para o usuário se situar na página. É preciso hierarquizar o conteúdo corretamente usando os títulos h1 a h6. Para estruturas mais complexas como frames e iframes é interessante que seja descrito com o atributo title. Para formulários extensos é interessante agrupar campos com a tag fieldset. Em caso de listas grandes do tipo option utilizar a tag optgroup para separá-las: <optgroup label="sucos"> <option value="uva">uva</option> <option value="morango">morango</option> </optgroup> <optgroup label="sanduiche"> <option value="torrada">torrada</option> <option value="x-tudo">x-tudo</option> </optgroup> Código 24: Lista separada por optiongroup.

80 2.5.13 Fornecer mecanismos de navegação claros O sistema de navegação é o principal ponto de apoio do site. Ele deve ser elaborado de forma que facilite a vida do usuário, dê alternativas que evite a sensação que a informação não existe na página. Além dos menus de navegação, é possível complementar com mapa do site e informações de orientação. É interessante que links relacionados sejam agrupados, e suas descrições sejam claras. Evite termos como "clique aqui", já que ele também poderá ser acessado via teclado, além de ficar vago, pois não identifica a funcionalidade que o usuário terá ao acessar. Dependendo do site, é interessante também utilizar estruturas de navegação criadas pelos próprios usuários (folksonomia), como é o caso das palavras-chave utilizadas no site http://del.icio.us ou no site http://www.flickr.com, que geram no final uma lista ou uma nuvem de tags que tende a ser, no caso dos sites citados, um complemento às taxonomias (navegação criada pelo desenvolvedor) já prontas. Em uma explicação genérica poderíamos dizer que em sites institucionais é importante ter uma navegação pré-definida (taxonomia), enquanto sites com serviços que serão utilizados por pessoas (Ex: sites armazenadores de fotos), é interessante que permita que o próprio usuário classifique seus arquivos com as tags apropriadas. A folksonomia vem para ampliar as possibilidades de interação com a página, ela não veio para substituir a taxonomia. Se possível colocar informações descritivas antes de cada seção da página para facilitar a compreensão dos usuários de leitores de tela que exibem o documento de forma seqüencial. Esse ponto já é muito bem resolvido quando utilizamos agrupamentos de links antecedido de um título descrevendo o grupo: <h3>sucos</h3> <ul> <li><a href="">acerola</a></li> <li><a href="">laranja</a></li> </ul> Código 25: Descrição da seção de sucos utilizando a tag de título h3.

81 Para quem já quer antecipar um pouco o futuro também é possível disponibilizar um arquivo RDF (Resource Description Framework). É um formato de definição de recurso que foi desenvolvido pelo W3C. Ele é um dos pilares para a Web Semântica, onde será possível efetuar buscas muito mais específicas e com menor probabilidade de falha. É um adicional para a web atual, não foi criado para substituir e sim para complementar e é um formato para ser utilizado principalmente por máquinas. podemos ver um exemplo simples abaixo, seguindo o padrão da notação N3 (Notation 3) que é equivalente ao formato XML em funcionalidade só que é bem mais simples de implementar. O RDF é uma forma de representar interligações de conteúdo seguindo o padrão: Objeto/Recurso - Propriedade - Valor. No exemplo podemos ver a representação da família de Paulo5: @prefix : <http://www.exemplo.org/>. :paulo :temMae :maria . :paulo :temPai :joao . Código 26: Exemplo de RDF Esse conjunto de triplas poderão ser lidas por parsers, juntos com outras triplas para gerar consultas mais aprimoradas, já que estão semanticamente estruturadas. É importante também utilizar as tags meta. Meta tags são responsáveis por descrever o conteúdo do seu site para os buscadores. É possível, por exemplo, declarar o autor do texto e as palavras-chave que facilitam para o usuário encontrar determinada página. Ex: <meta name="author" content="Valério Farias" > <meta name="description" content="Monografia – A evolução do Portal UERN" > <meta name="keywords" content="Acessibilidade, Padrões Web, Usabilidade, Arquitetura da Informação" > Código 27: Exemplo de meta tags. 5 Outros exemplos poderão ser encontrados no artigo “What is RDF” de Joshua Tauberer disponível em: http://www.xml.com/pub/a/2001/01/24/rdf.html?page=1

82 Lembramos que a meta tag tem uma importância secundária. O ponto principal é deixar o conteúdo bem representado com as marcações apropriadas. Como complemento, o uso de meta tags é muito bem vindo. 2.5.14 Assegurar a clareza e a simplicidade dos documentos. O foco aqui é que o conteúdo seja repassado de uma forma clara e simples para que garanta uma comunicação eficaz para diversos tipos de usuários, entre os quais podemos citar:  Aqueles que têm problemas de cognição ou dificuldade de aprendizagem, onde texto em excesso irá prejudicar sua interação.  Aquelas pessoas que não estão com tempo de ler textos infindáveis para saber do que se trata o site.  Aqueles usuários que ainda estão aprendendo a língua nativa do site. Ex. Um brasileiro que não é fluente em inglês acessando um site americano. O texto simples será muito mais amigável para esses tipos de usuários. No final acaba sendo bom para todos os tipos de usuários, já que uma página enxuta, tende a ser mais fácil encontrar o que se procura.

83 2.6 TÉCNICAS DE USABILIDADE De acordo com Dias (2007): um problema de usabilidade pode ser definido como qualquer característica, observada em determinada situação, que possa retardar, prejudicar ou inviabilizar a realização de uma tarefa, aborrecendo, constrangendo ou traumatizando o usuário. Os problemas com relação às conseqüências na interação do usuário com os sistemas:  Barreira: quando o usuário não consegue resolver o problema nas diversas tentativas.  Obstáculo: quando o usuário aprende a resolver o problema durante as tentativas.  Ruído: problema mais brando, pois a diminuição do desempenho não é tão significativa como nos anteriores. Os ruídos no geral diminuem a satisfação dos usuários ao invés de seu desempenho. Banners em popup e objetos piscantes podem ser considerados ruídos por distraírem o usuário em um momento que ele não deseja. Problemas relacionados ao tipo de usuário:  Geral: afeta qualquer tipo de usuário;  Inicial: afeta somente usuários inexperientes;  Avançado: compromete a realização de tarefas executadas por usuários experientes. 2.6.1 Avaliação Heurística Dias (2007) comenta sobre as principais abordagens para avaliação de usabilidade: Métodos de inspeção - não há participação direta dos usuários. Um dos subtipos desse método é a avaliação heurística. A avaliação heurística tem como objetivo, identificar problemas de usabilidade que, posteriormente, serão analisados e corrigidos ao longo do processo de desenvolvimento do sistema. A avaliação heurística é bem empregada para fazer "redesigns" de sites, em que é possível detectar pontos que podem ser melhorados na versão futura do site. É um método barato, simples, rápido e não tem a pretensão de prover resultados perfeitos.

84 Uma heurística disponível em português é a Heurísticas para avaliação de usabilidade de portais corporativos onde ela cita 7 itens de verificação da usabilidade de portais (DIAS, 2008). Essa heurística foi utilizada para esse trabalho e se encontra disponível na seção de anexos. 2.6.2 Padrões de Design (design patterns) Outra técnica que utilizamos nesse trabalho foi os padrões de design para web. (design patterns). A sua utilidade é tornar a página bem mais intuitiva, já que se trata de um formato já conhecido e largamente utilizado por usuários. Um dos padrões de design mais conhecido é o da busca: Figura 27: Padrão de design - busca no site. No formulário anterior não é preciso maiores explicações. Está muito claro o propósito. Um campo que coloca a palavra-chave depois clica no botão para obter o resultado. Essa é a função de um padrão, deixar a interface simples e clara. Para entendermos um pouco melhor os padrões vamos descrever um dos exemplos retirado da coleção de padrões de desing do Welie.com (2008). Falaremos sobre um tipo indispensável nas páginas, o menu principal: Problema: Os usuários precisam saber como encontrar o que estão procurando. Solução: Colocar um menu que fique sempre visível em uma posição fixa na tela. Complementar esse menu principal com listas adicionais de navegação. Usar quando: todos os sites precisam de alguma forma de navegação principal. Como: há dezenas de maneiras. Entre os mais comuns temos o menu horizontal, o vertical e o menu em forma de L invertido. Figura 28: Formato padrão para menu horizontal.

85 Fica claro nesse item que devido à limitação da tela o menu horizontal deve ter também poucos elementos. No máximo 6 ou 8, dependendo do comprimento das palavras. Na próxima figura veremos as possibilidades mais comuns de menu vertical e para melhor compreensão acompanharemos com a seguinte legenda: (A) mostrando somente itens de nível 1, (B) mostrando itens de nível 1 que se expandem quando selecionados, e (C) mostrar links de nível 2 agrupados por um cabeçalho de nível 1 não clicável. Figura 29: Formato padrão para menu vertical. Quando estamos lidando com muitos níveis de informação, um boa solução é o menu de L invertido que é uma mistura do menu horizontal com o vertical: Figura 30: Formato padrão para menu L invertido. Tendo as imagens anteriores como referência. A idéia principal é que quanto mais próximo o menu da página estiver do padrão acima, ele será mais simples de usar. Por outro lado, quanto mais se distanciar do padrão, será preciso adicionar informações e serviços extras na interface como ajuda, e formulário de tira-dúvidas, FAQ (perguntas freqüentes), devido à

86 dificuldade de achar a informação ou a tarefa que pretendiam. Os diversos outros padrões podem ser encontrados no site Welie.com. Para a utilização dos padrões de design vale também o bom senso. Dependendo do tipo de site é importante que tente seguir o máximo possível o padrão. Os sites de instituições públicas entram nesse formato, pois é preciso interfaces simples, práticas e funcionais para facilitar a vida de diversos tipos de usuários, que inclusive não tem paciência de ficar muito tempo olhando a página. Eles querem resolver o problema o mais rápido possível e sair do site em seguida. Mas, no caso de campanhas inovadoras de marketing de produtos que envolvam moda, tecnologia, produtos voltados para o público jovem, entretenimento, entre outros, a interface pode fugir um pouco dos padrões, pois os usuários já esperam que a página espelhe um pouco a atitude de inovação e de mudança da empresa em questão. Nesse caso, os usuários já vão com interesse na página para encontrar o que querem, pois é algo que eles se identificam. 2.6.3 Testes de Usabilidade De acordo com Krug (2000), teste de usabilidade é feito colocando uma pessoa em contato com algo (web site, protótipo de um site, rascunhos de páginas individuais) e (a) é perguntado se ela compreendeu do que se trata ou (b) se pede para ela utilizar a página para realizar uma tarefa típica. O primeiro teste (a) serve para verificar se a página apresentada faz sentido para o usuário, ver se ele entendeu o propósito do site, como é sua organização, como ele trabalha, etc. Uma variação desse tipo de teste é um teste informal onde você imprime a página em questão e pergunta para uma pessoa próxima se a página faz sentido, por exemplo, um formulário, isso ajuda a eliminar diversos problemas. No outro tipo de teste (b) pedimos ao usuário que execute uma tarefa enquanto acompanhamos e detectamos os pontos de dificuldade que ele teve para depois diagnosticar se realmente é importante mudar ou não. Um mito que é muito importante esclarecer é sobre o propósito deste teste. As pessoas costumam pensar que um teste servirá para dizer se o posicionamento de um produto no formato “a” será melhor que no formato “b”. Mas, o propósito deste teste não é aprovar ou desaprovar algo. O que o teste pode fornecer são determinadas informações que junto com a experiência do

87 desenvolvedor, julgamento profissional e senso comum, tornarão mais fácil escolher entre "a" e "b" (KRUG, 2000). Outro mito é sobre a obrigatoriedade de um custo alto com laboratórios, câmeras sofisticadas e profissionais muito especializados para realizar um teste de usabilidade de qualidade. Nielsen (1989 apud Krug, 2000) escreveu em seu artigo “Usability Engineering at a Discount”, que não é preciso toda essa complexidade para conseguir resultados satisfatórios. Fala que não é necessário ter laboratórios de usabilidade e que é possível chegar a resultados equivalentes com bem menos usuários. O que Krug (2000) nos mostra sobre testes de usabilidade é que: 1. Economiza tempo do desenvolvimento, pois evita discussões incessantes sobre a necessidade de determinadas funcionalidades e também evita que determinadas coisas tenham que ser refeitas quando o site está terminado. 2. Não é tão caro quanto aparenta. Ele sugere um orçamento de U$300,00 por teste ao invés dos U$15.000,00 nos tradicionais (ver tabela 3). 3. Não são necessários especialistas, já que um teste de usabilidade é incrivelmente fácil de ser executado. Sempre é possível obter resultados satisfatórios. 4. Para realizar o teste, só são necessários uma mesa com computador e duas cadeiras em um local onde não haja interferência. A tabela a seguir mostra as principais diferenças entre teste de usabilidade tradicional e o formato simplificado que estamos sugerindo:

88 Teste simplificado (sem Teste Tradicional desperdício) Número de usuários por teste Geralmente oito ou mais Três ou quatro. Seleção cuidadosa compatível com o Chame algumas pessoas. Quase Seleção dos candidatos público alvo do site. todas as pessoas que usam a web poderão fazer. Um laboratório de usabilidade, com Qualquer escritório ou sala de Onde testar um quarto de observação e um conferência. espelho falso entre a sala e o laboratório. Quem realiza o teste Um profissional de usabilidade Qualquer ser humano experiente. razoavelmente paciente. Testes têm que ser agendado com Testes podem ser feitos em quase semanas de antecedência para qualquer momento. Quase não é Planejamento reservar um laboratório de necessário agendar. usabilidade e permitir tempo para fazer a seleção. Preparação Rascunho, discussão e revisar o Decida o que você vai mostrar. protocolo de teste. A menos que você tenha um grande Execute pequenos testes O que/Quando fazer o teste? orçamento, teste uma vez quando o continuamente por todo o site estiver perto de ser finalizado. processo de desenvolvimento U$5.000 a U$15.000 (ou mais). Cerca de U$300 dólares (U$50 a Custo U$100 para pagar cada usuário e U$20 para 3 horas de gravação de vídeo). Um relatório de 20 páginas escritas é Cada observador escreve uma disponibilizado uma semana depois, página de notas do dia do teste. A O que acontece depois a equipe de desenvolvimento se equipe de desenvolvimento pode reuni para decidir que mudanças discutir no mesmo dia. fazer. Tabela 3: Comparando Teste de Usabilidade tradicional e simplificado. Fonte: Krug, 2000. Apesar dos custos mostrados serem em dólar (U$), é fácil adaptar o teste simplificado para Reais ou qualquer outra moeda. O gasto com a gravação pode ser eliminado caso a pessoa que quer aplicar o teste já possua uma câmera ou também caso seja utilizado um programa de gravação de tela durante o teste. Quanto ao gasto com os usuários pode ser diminuído ou até eliminado convidando voluntários. Para realização do teste é preciso pessoas que execute duas tarefas distintas: Facilitador – responsável pela condução do teste. É preciso ser paciente, deixar bem claro que o que está sendo testado é a interface e não o usuário. Se o teste for filmado é preciso que a

89 pessoa esteja ciente e concorde também. Explicar também que o teste é uma simulação de como o usuário utilizaria o computador em casa e que o facilitador não pode interferir respondendo perguntas durante o processo. É como se o usuário estivesse sozinho usando o computador. Para iniciar é possível fazer algumas perguntas relacionadas à utilização de computador, internet, email, se já fez compras online. As instruções devem ser mantidas simples: “Olhe ao redor da página e me diga o que acha dela e o que você gostaria de clicar?” “O que você espera ver nessa página?” “Tente pensar em voz alta sempre que possível.” No final do teste o facilitador deve fazer suas anotações sobre o que descobriu. Observador – o observador tem que ouvir e assistir atentamente, para fazer anotações que possa passar despercebido pelo facilitador. Prestar atenção nos momentos em que os usuários ficarem confusos, pois ali pode ter uma futura modificação na página. No decorrer do processo é possível que encontre coisas que não funcionem como links quebrados ou gráficos ausentes, são coisas secundárias e não é preciso perder muito tempo com isso. É importante se prender somente às ações e às explanações do usuário e deixar suas opiniões de lado, já que ele tende a exagerar um pouco, seja de forma negativa ou positiva. No final do teste é preciso que o observador também faça uma pequena lista com os principais problemas que ele viu e algumas sugestões de como resolvê-los. Para tomar a decisão de efetuar mudanças é preciso fazer uma triagem dos principais problemas descobertos analisando as anotações de cada um dos participantes e decidir quais precisam ser resolvidos. Depois é preciso descobrir uma forma de resolvê-lo. O diferencial dessa seção é que eles vão constatar que os itens que precisam ser mudados geralmente fazem sentido. Eles tendem a ser óbvios para qualquer um que assista a seção. Abaixo temos algumas dicas para triagem:  Desconsiderar problemas momentâneos em que os usuários logo que compreendem voltam para o curso normal;  Resistir ao impulso de adicionar itens;  Ter sempre o cuidado de evitar que o concerto de determinado problema influencie outras partes que funcionam bem. Como a interface tem muitos pontos em conjunto, é possível que determinadas mudanças gerem outros problemas.

90 2.7 ACOMPANHANDO AS TENDÊNCIAS Essa seção é uma proposta de enfatizar que o processo de desenvolvimento continua após o site ser lançado. Uma página em produção não quer dizer que ela está terminada. Devemos ficar atentos a tendências que vem surgindo e implementá-las de acordo com as necessidades ou para fazer experimentações que serão muito úteis no futuro. O que vamos comentar aqui é sobre os Microformatos. 2.7.1 Microformatos Eles são um conjunto de formatos padronizados, simples e abertos, construídos com as tecnologias existentes para divulgação de conteúdos muito específicos na web, de forma que fiquem semanticamente organizados e facilmente recuperados por robôs de busca. Os microformatos utilizam nomes de classes padronizados para dar sentido ao conteúdo. A idéia principal é que esses formatos sejam desenvolvidos primeiro para a utilização de humanos e depois para máquinas. É uma forma simples de estender a abrangência de representação do HTML. Os microformatos são de domínio público e foram criados por Tantek Çelik que é membro do Web Standard Project6. Existem diversos tipos de microformatos. Citaremos aqui três tipos. O hcard, hcalendar e o geo. 2.7.1.1 Microformato hcard O hcard é o microformato indicado para publicar informações de contato de pessoas ou empresas (como um cartão de visitas). 6 Projeto cujo objetivo é lutar por padrões que assegure simplicidade, acessibilidade nas tecnologias web para todos. Disponível em http://www.webstandards.org/

91 <div class="vcard"> <img src="foto.jpg" alt="foto" class="photo"/>  <a class="url fn" href="http://valeriofarias.wordpress.com">Valério Farias</a>  <div class="org">UERN</div>  <div class="adr">  <div class="street-address">Nome da rua</div>  <span class="locality">Mossoró</span>,  <span class="region">RN</span>  <span class="postal-code">59800XXX</span>  </div> <div class="tel">+31 (84) XXXX-XXXX</div></div> </div> Código 28: Microformato hcard. Podemos perceber que os nomes de classes são bem intuitivos. Usamos a classe url para indicar que o link dessa linha é para uma página e a classe fn (full name), indicando que o conteúdo da tag terá o nome completo. 2.7.1.2 Microformato hcalendar <div class="vevent"> <h3 class="summary">Mossoró Cidade Junina</h3> <p class="description">O Mossoró Cidade Junina é uma Festa Junina do O outro microformato que falaremos é sobre o hcalendar, ele é utilizado para divulgação estado do Rio Grande do Norte. O evento ocorre todo ano na cidade de de eventos. Vejamosas atrações do evento, estão shows com grandes artistas Mossoró. Entre um exemplo: nacionais, festivais de humor, quadrilha, comidas típicas e etc. Em comemoração aos 80 anos da história dos mossoroenses e o bando de lampião, é apresentado todo ano no adro da capela de São Vicente, a história de como os mossoroenses expulsaram o bando de lampião. O espetáculo é nomeado Chuva de Bala no País de Mossoró. </p> <p>Será realizado de <abbr class="dtstart" title="2008-06-01">01</abbr> a <abbr class="dtend" title="2008-06-30">30 de junho de 2008</abbr></p> <p>Local: <span class="location">Estação das Artes Eliseu Ventania, Mossoró, RN</span></p> <a class="url" href="http://www.prefeiturademossoro.com.br/cidade_junina/index.php">site do evento</a> </div> Código 29: Microformato hcalendar.

92 Uma observação que temos que fazer é que a data nos microformatos segue o padrão ISO 7 8601 que indica o formato: AAAA-MM-DD. Esse formato só fica disponível para indexação por robôs. O que vemos no navegador é a frase: Será realizado de 01 a 30 de julho de 2008. Portanto não teremos problemas no Brasil, pois podemos colocar o conteúdo no formato que utilizamos: DD-MM-AAAA e utilizar o padrão internacional no atributo title das classes dtstart e dtend. 2.7.1.3 Microformato Geo O terceiro microformato que mostraremos é o Geo. Esse é o microformato para adicionar coordenadas geográficas do local que deseja. <div class="geo">Cordenadas Geográficas: <span class="latitude" >37.386013</span>, <span class="longitude">-122.082932</span> </div> Código 30: Microformato geo. Esse geo será mostrado da seguinte forma : Coordenadas Geográficas: 37.386013, - 122.082932. 2.7.1.4 Outros Microformatos Existe também o hreview8 para mostrar análises de livros, filmes, serviços. O rel-licence para associar o conteúdo à determinada licença e diversos outros microformatos9 disponíveis que podem ser consultados quando desejar. <a href="http://creativecommons.org/licenses/by/2.0" class="licence" >cc by 2.0</a> Código 31: Microformato rel-licence. 7 Especificação para representação numérica de data e tempo. Disponível em http://www.cl.cam.ac.uk/~mgk25/iso- time.html 8 Para entender o hreview é só acessar: http://microformats.org/wiki/hreview 9 Lista completa de microformatos: http://microformats.org/wiki/Main_Page

93 É muito provável que num futuro próximo os Microformatos já não estejam mais em fase experimental e passem a ser algo indispensável para ampliar as possibilidades de interação na web. Uma das possibilidades futuras é obter, por exemplo, eventos que ocorreram entre determinadas datas específicas em locais específicos, através de um robô que indexe hcalendar (eventos) e geo (localização geográfica).

94 3. A EVOLUÇÃO DO PORTAL UERN 2004 a 2007 Nesse capítulo mostraremos a evolução que sofreu o Portal UERN tomando como base didática a metodologia Acessibilidade de Verdade. 3.1 METODOLOGIA Só para relembrar a formula: Acessibilidade de Verdade = Recursos + Foco no Usuário + Bom senso. Toda essa evolução segue a metodologia citada, mostrando os recursos: uma organização inicial, estruturação com padrões web, verificação de acessibilidade, complementação com usabilidade e de vez em quando a implementação de uma solução adicional, resultado do acompanhamento de tendências nas tecnologias para desenvolvimento web, claro que seguimos todos os pontos com bom senso, já que só foi implementado o que consideramos realmente útil. O propósito criar uma estrutura inicial simples e flexível para modificações rápidas e à medida que detectamos as verdadeiras necessidades dos principais usuários fomos modificando e aprimorando a interface para permitir o acesso à informação com o mínimo de dificuldades possível. Outro ponto da metodologia Acessibilidade de Verdade é o foco no usuário. Para preencher esse requisito passamos a obter necessidades, como já foi falado nos objetivos, por meio de um formulário de contato no qual acessamos pela caixa de email. Não fizemos gráficos estatísticos detalhados para priorizar esses pedidos e sugestões. Também não ficamos relendo extensivamente emails anteriores. Usamos uma técnica semelhante à usada pela 37 Signals que é mostrada no livro Getting Real (2008). A equipe da 37 Signals quando estavam projetando o Basecamp (Sistema gerenciador de projetos ), juntavam os pedidos de funcionalidades feitos pelos clientes em uma lista de tarefas. A cada repetição do pedido adicionavam um marcador indicando a quantidade. A intenção era de que em determinado momento eles iriam revisar a lista iniciando pelas sugestões que mais fossem pedidas. Só que eles nunca mais olharam essa lista novamente, pois já sabiam o que precisava ser feito, já que os clientes lembravam constantemente. Tem um trecho em Getting

95 Real (2008) que representa bem essa técnica: "Você não pode esquecer o que é importante quando você é lembrado todos os dias". A partir daí eles deixaram de tentar gerenciar lista de sugestões. Eles liam as sugestões e as deixavam de lado, sem se preocupar mais com elas, já que se fosse algo de maior relevância, com certeza, apareceria novamente. As principais modificações que deveríamos fazer eram óbvias, pois acompanhávamos os emails no decorrer dos meses e já sabíamos o que era mais importante sem precisar efetuar uma análise mais detalhada nas mensagens para decidir que modificações seriam priorizadas. Os usuários repetiam sempre o que era imprescindível e, a partir daí decidíamos o que fazer primeiro. Por motivos didáticos, para facilitar a compreensão da evolução do Portal UERN, ao invés de seguirmos o padrão: Problema -> Resultados, que é o formato para trabalhos de conclusão de curso, toda a evolução será mostrada em ciclos contendo a repetição dos itens: a) Falhas na interface a ser modificada; b) Nova versão c) Palavras-chave que representam a versão. E por fim serão mostrados os resultados. Queremos esclarecer que a equipe10 da Unidade de Processamento de Dados da UERN é responsável pela implementação de todas as versões do Portal UERN. 3.2 A ESTRUTURA DO ANTIGO PORTAL E PROPÓSITO INICIAL O antigo portal 2004-2005 foi produzido por um desenvolvedor externo à instituição e devido às necessidades de integração com os sistemas internos, assumimos a tarefa de produzir um novo portal totalmente remodelado para suprir diversas necessidades que o outro portal não poderia devido sua arquitetura fechada e independente. A seguir, temos a imagem referente ao antigo portal da instituição. 10 Carlos Moisés, Ricardo Júlio, Veras Junior, Valério Farias

96 Figura 31: Antigo portal UERN - 2004

97 Para facilitar a nossa tomada de decisões na hora de priorizar determinadas informações para os tipos de usuários que mais utilizam a página web, antes de iniciar o desenvolvimento do novo portal resolvemos adotar como referência os seguintes públicos alvos: Alunos Acessam o website com o principal objetivo de realizar atividades burocráticas, como matrícula e consulta ao histórico escolar, solicitação de diploma, arquivos que o professor disponibilizará para aula, informações sobre eventos. Professores Procuram no website informações de contato com outros professores e departamentos dentro da Universidade. Desejam também disponibilizar sua produção científica e pesquisar nas dos colegas. Dão atenção para avisos, eventos e notícias que afetem seu trabalho. Técnico-administrativos Precisam menos do website do que as demais faixas de público, mas se interessam pelas notícias que afetem seu trabalho. Também podem usá-lo como referência para procedimentos burocráticos. Aspirantes aos cursos Buscam saber o que a Universidade tem a oferecer para eles. Os principais assuntos que procuram é cursos de graduação disponíveis e concurso do vestibular. Acessam com grande freqüência quando estão acompanhando um concurso de interesse. Jornalistas Buscam informações de contato com professores e órgãos da Instituição. Porém, caso esteja disponível, material para a redação de suas reportagens. Estão particularmente interessados em descobertas científicas que interessam a toda a sociedade.

98 Professores que procuram por concursos (futuros professores da UERN) Buscam informações sobre editais dos concursos, endereços, telefones e fax da instituição, notícias sobre o concurso. Tendo o público alvo hipotético definido fizemos uma análise de usabilidade na interface do portal antigo cujos resultados podem ser vistos no próximo tópico. 3.2 DESENVOLVIMENTO DA 1ª VERSÃO DO PORTAL UERN - 2005 Após um ano de utilização do portal UERN, ilustrado na figura 31, notamos vários pontos falhos11 (do ponto de vista da Usabilidade), entre eles podemos citar: menu no topo que dificulta a utilização (o usuário tem que mover o menu para achar o item desejado); poluição visual na página principal, banners em excesso, cores berrantes (cores muito fortes, como a cor laranja do menu principal); o espaço para texto de notícias é muito reduzido (aproximadamente 45% da página, enquanto o recomendado é que seja de pelo menos 50%, podendo variar até 80% do tamanho da página) causando desconforto visual; O espaço para navegação ocupa cerca de 27% da página enquanto o recomendado é que não ultrapasse 20%; não houve uma preocupação em classificar o menu por ordem de importância que fica bem mais funcional para os usuários (está em ordem alfabética), entre outros fatores técnicos. Com relação à tecnologia a ser empregada, o Portal nesse formato antigo não segue a linha dos Padrões Web (Web Standards) que são especificados e recomendados pela equipe do W3C, como uma forma de manter a página portável, acessível e enxuta. Por não seguir as especificações de acessibilidade nem as indicações voltadas para os Padrões Web do W3C, o antigo portal tinha muitas barreiras que dificultava o acesso a portadores de deficiência visual, além de demorar bastante a carregar por causa do tamanho exagerado do total de download necessário para a página principal ser carregada, como se pode identificar na figura a seguir. 11 Afirmação baseada nas especificações do seguinte documento: DIAS, Cláudia. Heurísticas para avaliação de usabilidade de portais corporativos. Disponível em http://www.geocities.com/claudiaad/heuristicas_web.html> Acessado em 26/03/2008

99 Figura 32: Análise de Acessibilidade do antigo portal UERN Além dessas questões relacionadas com a interface do usuário e acessibilidade, havia também uma necessidade de integração com os demais sistemas da UERN, como o Sistema de Administração Escolar – SAE, que teria muitas funcionalidades a serem acessadas via Portal UERN, como por exemplo, as páginas do professor, as grades dos cursos de graduação, entre outras. A arquitetura do antigo portal tornava inviável essa integração com esses sistemas. Baseado nos argumentos anteriormente citados, que retrata a situação do antigo Portal, colocamos como principais objetivos para o desenvolvimento de um novo Portal UERN:  Interface mais amigável e simples para utilização dos usuários;  Padrões Web, para prover portabilidade, acessibilidade e velocidade de acesso;  Integração total com o Sistema Acadêmico e demais sistemas da UERN;  Vários serviços da UERN acessíveis logo na página inicial;  As faculdades estarão também mais acessíveis (links na página inicial e endereços web disponíveis para acesso direto).

100 O resultado pode ser visto na figura abaixo, que será complementado com algumas comparações com o antigo portal e em seguida será mostrado uma análise de acessibilidade da interface: Figura 33: 1ª versão do Portal UERN 2006

101 Figura 34: Comparando Portal 2004 e o Novo Portal (1ª versão - topo e navegação principal) Figura 35: Comparando Portal 2004 e o Novo Portal (1ª versão - navegação secundária)

102 Como pode ser visto na figura abaixo, o nível de acessibilidade já ampliou bastante e em paralelo o tamanho final da página diminuiu consideravelmente aumentando a rapidez de acesso às informações. Figura 36: Análise de acessibilidade da 1ª versão do Portal UERN Palavras-chave que identificam essa primeira versão: acessibilidade, enxuto, flexível. 3.3 DESENVOLVIMENTO DA 2ª VERSÃO DO PORTAL UERN - 2006 Depois de um ano de implantação da primeira versão, fomos acompanhando as mensagens que os usuários enviavam via formulário de contato e detectamos a dificuldade que determinados usuários tinham de localizar os cursos de graduação, ou seja, o principal recurso que a universidade oferece para a comunidade. Para chegar aos cursos de graduação era necessário clicar no link Graduação no menu principal e depois escolher os cursos ou então clicar em algum link de faculdade no respectivo quadro e depois escolher o curso desejado.

103 Fizemos uma pesquisa em uma página sobre padrões de interface da welie.com e detectamos que o menu principal do portal estava muito diferente do modelo mais utilizado nas páginas (padrão) e que estava chamando menos atenção do que o menu secundário. Isso poderia em alguns casos dificultar a percepção do mesmo. Resolvemos então colocar o comprimento, posicionamento e formato semelhante ao do padrão de interface para melhorar a consistência. Detectamos também que tinha áreas na página subutilizada como o formulário de login na intranet que só era utilizado pelos funcionários, baseado nisso colocamos um link cursos de graduação direto na primeira página nessa região onde era o login da intranet. Outra preocupação da equipe foi aprimorar o visual do site escolhendo cores e contrastes mais agradáveis para tentar repassar uma sensação de conforto para os usuários. Segue abaixo as imagens com as análises de usabilidade na interface que possibilitaram o aprimoramento da mesma. Figura 37: Análise de Usabilidade da 1ª versão do Portal UERN – parte 1

104 possuem menor quantidade Figura 38: Análise de Usabilidade da 1ª versão do portal UERN – parte 2 4 Figura 39: Análise de Usabilidade da 1ª versão do portal UERN – parte 3

105 Nessa nova versão solucionamos os problemas de usabilidade citados anteriormente, como também a questão da divulgação dos cursos de graduação que estava mais escondida, passando a ficar em local estratégico (inicio do menu esquerdo). Essa nova proposta veio também com um visual mais aprimorado, com uma escolha de contrastes de cores mais agradáveis. Criamos também nas laterais uma margem de 10px para dar uma sensação de leveza e maior consistência na interface. O resultado pode ser visto na figura abaixo: Figura 40: 2ª versão do Portal UERN - 2006

106 Palavras-chaves que representam essa 2ª versão do site: conforto, beleza, priorizar informações relevantes, melhorar a organização. 3.4 DESENVOLVIMENTO DA 3ª VERSÃO DO PORTAL UERN – 04/07/2007 Detectamos que a versão de 2006 (figura 40) ainda estava ocupando muito espaço com os quadros das faculdades e campi avançados enquanto tinha um constante pedido por divulgações de eventos, cursos, etc, que acabavam sem um espaço bem definido e sem a relevância devida. Partindo desse princípio otimizamos o espaço criando um novo quadro para divulgações genéricas, mantendo o quadro de eventos com dimensões maiores, ampliando a área de notícias para 10 ao invés de somente 4, e conseqüentemente diminuindo um pouco o espaço ocupado pelos demais quadros. Procuramos também aprimorar um pouco o visual eliminando partes que achamos desnecessárias como o título “outros eventos” no quadro de eventos e os selos de validação do rodapé que ficavam competindo com o link de RSS e também refinando as cores das barras de menus para que ficassem mais consistentes e menos agressivas.

107 Figura 41: 3ª versão do Portal UERN – Julho de 2007 É possível detectar na figura a seguir que o nível de acessibilidade do Portal está adequado segundo a análise do site. Porém sabemos que esse resultado é somente uma das referências e que o aprimoramento deve ser buscado a cada versão utilizando como base à especificação de acessibilidade do WCAG. Como diferencial dessa versão, disponibilizamos um link no topo da página apontando diretamente para a seção de conteúdo facilitando o acesso para deficientes visuais. Esse link só é detectado por softwares leitores de tela como o JAWS, atualmente não está visível, mas nada impede que com futuros testes modifiquemos para que fique visível auxiliando, dessa forma, pessoas com outros tipos de problemas como o cognitivo.

108 A foto abaixo foi o resultado do teste com a última versão do Portal, porém desde a segunda versão de 2006 já apresentava esses resultados de qualidade. Figura 42: Análise de Acessibilidade do Portal UERN – Julho de 2007 3.4.1 Preparado para o futuro com Microformatos Os Microformatos já foram explicados no capítulo anterior, são utilizados para ampliar a capacidade de representação de conteúdo além do que o HTML já consegue e que a intenção dele é que seja muito simples das pessoas utilizarem através dos nomes de classe padronizados. Os tipos que já incluímos no portal são: Hcard – microformato recomendado para divulgação de agenda pessoal ou profissional na web. Foi construído a partir do Vcard, que é um padrão internacional para cartões eletrônicos de negócios.

109 Código 32: Microformato hcard implementado no Portal UERN Código 33: Microformato Geo implementado no Portal UERN Geo – microformato indicado para adicionar coordenadas geográficas na página que no caso do campus central pode ser identificado na imagem abaixo: Reparem nos nomes de classe padronizados. Isso possibilita a indexação por motores de buscas específicos que venham a surgir. No momento já é possível “brincar” um pouco com esses formatos no caso de usuários mais avançados. No exemplo abaixo utilizamos o plugin operator do Firefox que localizou as coordenadas do campus central e quando clicamos no item “Find with Google Maps” (figura 43) ele nos leva para uma vista aérea dessa localização que equivale ao Campus central da UERN (figura 44).

110 Figura 43: Plugin operator localizando as coordenadas geográficas da UERN Figura 44: Vista do Campus Central - UERN – Mossoró-RN – Google maps palavras-chave que representam essa 3ª versão: mais conforto, mais acessível, reorganizar, otimizar espaços, mais beleza, olhar no futuro. 3.5 RESULTADOS Os resultados serão mostrados na seguinte seqüência: a) resultados obtidos com relação ao item foco no usuário da metodologia; b) algumas considerações a respeito das técnicas (recursos). Com relação ao item bom senso ele acaba estando presente na maioria das decisões. O grande

111 exemplo do bom senso nesse trabalho foi a decisão de usar uma estratégia que requer pouco esforço para obter o feedback dos usuários. Agora seguiremos com os comentários. É evidente a simplicidade da técnica utilizada (mensagens via formulário de contato) e também a simplicidade do acompanhamento (ausência de análise detalhada das mensagem). O mais importante é que essa técnica se demonstrou eficaz, já que a cada mudança do portal deixávamos de receber mensagens das sugestões que foram resolvidas e passávamos a receber novos tipos de mensagens. O processo se repetia, só que com outros problemas. Outro fato a se mostrar é a eficiência dessa técnica, pois além de gerar resultados satisfatórios, foi possível otimizar o tempo de trabalho da equipe que não precisaria se preocupar mais em fazer uma análise detalhada das mensagens, que realmente é desnecessário para esse propósito de detectar mudanças importantes. Portanto, esse formato adotado para efetuar as modificações, trouxe resultados satisfatórios, resolvendo o problema e evitando esforços desnecessários. Com relação aos Recursos utilizados, no começo utilizamos técnicas de análise métricas que apesar de serem mais passíveis de distorção, foi nosso alicerce nesse momento que não tínhamos impressões mais detalhadas de usuários reais. Nesse primeiro momento também utilizamos um pouco das técnicas da área de arquitetura da informação para criar a estrutura inicial enxuta e amigável. Da segunda versão em diante já tínhamos as mensagens. O que fizemos foi escolher as melhores soluções e utilizamos como base técnicas de usabilidade como a comparação da interface com os padrões de design. Esse conjunto se mostrou muito equilibrado, pois nos permitiu resolver os problemas com efetividade, evitando retrabalho. Conseguimos também diminuir bastante o esforço devido a nossa escolha de feedback ser indireta através das mensagens.

112 4. ENTREVISTA E TESTE COM USUÁRIO Com propósito de complementar o item foco no usuário, será mostrado nesse capítulo uma entrevista e um teste com um usuário que possui necessidade especial 4.1 METODOLOGIA Apesar de nosso principal mecanismo para obter as necessidades dos usuários ter sido por meio da análise de mensagens enviadas pelo formulário de contato, que comprovamos eficiência e eficácia, é interessante demonstrar a técnica e utilidade dos testes com usuários, como uma forma de complementar a busca pelo aprimoramento da interface. Esse teste é um pouco diferente do anunciado no capítulo 2. O propósito é de dar somente uma amostra de um teste. Ao invés dos 3 usuários como foi recomendado, faremos somente com um usuário. Ao invés do teste ser visual e filmar a seqüência dos passos, esse teste será auditivo, gravando o áudio obtido da seqüência de passos usando o leitor de tela JAWS 7.0.1. O usuário iniciará respondendo algumas perguntas e logo em seguida executará as tarefas criadas para os testes, utilizando um software leitor de tela. Quanto à entrevista, não houve a preocupação de ser extremamente focada na detecção de falhas na interface. Ela está mais focada no perfil, nos trabalhos, nos objetivos futuros do entrevistado escolhido, bem como no tema da Acessibilidade na Web. O entrevistado é Francisco Leonard e está concluindo o curso de Ciência da Computação na Universidade do Estado do Rio Grande do Norte. Ele representa o tipo de usuário aluno e mais especificamente trata-se de uma pessoa que utiliza o computador exclusivamente através da audição (usando o JAWS) por não poder enxergar. Segue agora a entrevista:

113 4.2 ENTREVISTA 1. Qual foi o seu histórico de utilização de softwares e de linguagens de programação desde quando você iniciou na área de informática até os dias atuais? Quando comprei meu primeiro computador a primeira dificuldade foi utilizar o leitor de tela e toda aquela interface que quando se usa pela primeira vez é bastante chato. Outra dificuldade inicial foi aprender a utilizar os menus do Windows. O primeiro software a utilizar foi o Virtual Vision. Depois tive contato com o DOSVOX, que muitas pessoas confundem com leitor de tela, mas na verdade é um sistema operacional. A partir daí, passei por alguns aplicativos de escritório como Word e Excel. Logo em seguida comecei a acessar a Internet e fiquei por um tempo me aperfeiçoando na utilização dos aplicativos, nos acessos aos menus do Windows e acesso a sites. Quando entrei para o curso de Ciência da Computação, a primeira linguagem que aprendi foi o Pascal, depois C e Java. Sendo a que mais me identifiquei foi Java, além de Delphi que a gente não vê na faculdade, mas aprendi por fora. Então as duas linguagens que acho melhor para cego é o Java e o Delphi. Em C é possível programar normalmente, só que é um pouco mais complicado. 1.2 A questão de Preferir o Java e Delphi é graças ao IDE (Ambiente Integrado de Desenvolvimento) ou graças a linguagem de programação em si? Graças ao IDE e também porque a equipe se preocupa com acessibilidade. Na API do Java existem classes que são voltadas para acessibilidade, ampliadores de tela e leitores de tela. Nas quais tem métodos voltados para deixar as interfaces mais acessíveis. 2. Entre os softwares leitores de tela disponíveis no mercado, quais você já utilizou? Qual o que você decidiu utilizar diariamente? E por qual motivo? Virtual Vision, JAWS, NVDA que é do Windows, mas possui código aberto e é atualizado com freqüência além do OSCAR, que é o leitor de tela que vem junto com o Ubuntu.

114 O incrível é que no Linux o cego pode formatar o computador devido ao OSCAR já vir integrado ao Sistema Operacional (Ubuntu). O software que uso com maior freqüência é o JAWS, e esse é o que mais se adapta aos softwares da área de informática profissional. 3. Sobre a iniciativa brasileira do DOSVOX? Você acha que eles precisam evoluir muito para chegar a concorrer com o nível de qualidade dos softwares proprietários? Você o indicaria para utilizar no dia-a-dia ou já indicaria um mais robusto? Para um deficiente visual que está iniciando no mundo da informática o sistema operacional DOSVOX é interessante, pois ele irá ter uma idéia de todos os conceitos básicos ligados ao computador: aplicativo, pasta, arquivos. Ele funciona tanto no Windows como no Linux na distribuição Kurumin. É bastante indicado também para crianças por ter jogos educativos. Depois de certo nível de experiência indico o Virtual Vision, para um contato melhor com o sistema Windows devido a voz ser de melhor qualidade. Para um nível mais alto de experiência, sugiro o JAWS que é o software leitor de tela mais robusto atualmente. Após adquirir a experiência com o ambiente Windows migre para o Linux para ter uma idéia de como é navegar nesse sistema mais complexo. 4. Com relação à sua experiência na web, Já aconteceu de você desistir de tentar achar algum conteúdo em determinados sites por a página está muito desorganizada? Com certeza, várias vezes. Porque não achei o conteúdo, por desorganização da página. Eu estava assistindo recentemente uma reportagem sobre Oscar Niemayer e quando ela terminou, a repórter avisou que os vídeos estavam disponíveis no site da Globo. Quando tento acessar o conteúdo, não acho simplesmente nada! Com certeza eram arquivos em flash. Quer dizer, não tive êxito na minha tentativa de assistir os vídeos.

115 5. Quais os atalhos do Jaws que você utiliza com maior freqüência? São vários atalhos, mas os que utilizo com mais freqüência são: Insert + T – ler o título da janela. A forma mais rápida de saber o tipo de conteúdo da página que está acessando. No exemplo da página que estou vendo, ele indica que estou no gmail, indica a quantidade de emails na caixa de entrada, e o nome do navegador, no caso o Mozila Firefox. Insert + F10, para saber as listas de janelas (aplicativos) que estão em execução naquele momento. Insert + F11, para saber quais os programas que estão executando na barra de sistemas. Insert + F12 para saber a hora. 6. Soube que você ainda não acessou o site Acesso Digital que tem uma equipe de divulgadores da acessibilidade que estão propondo uma nova abordagem, na qual é preciso também melhorar a usabilidade. Então gostaria de saber qual sua expectativa em relação a essa página do Acesso Digital? A minha expectativa é que eles mostrem didaticamente a necessidade de criar sites acessíveis não somente para deficientes visuais, mas para qualquer tipo de usuário no intuito que não haja dificuldades em acessar o conteúdo que se deseja. 7. Você já chegou a fazer alguma página web? Como foi sua experiência no desenvolvimento dela? Ela está no ar? Em que momento teve maior dificuldade? Já tentei e cheguei a fazer alguns códigos, mas não cheguei a publicar. A minha dificuldade foi com relação ao visual da página, sempre eu tinha que perguntar a alguma pessoa como estava a organização do menu e fica complicado para um cego detectar a estrutura de menus pois para gente, consiste em itens que são lidos seqüencialmente, que é um pouco diferente da percepção visual, que não se dá de forma seqüencial. Para produzir uma página para quem enxerga o mais importante será o posicionamento adequado dos elementos e a nossa dificuldade principal é nesse quesito.

116 8. Que páginas você me diria que são ótimas no quesito acessibilidade e que página você acha que precisa melhorar muito? As páginas do governo, IBGE, ministério do trabalho são muito boas. Exemplo local: a página do ENCOPE que estava muito bem organizada, além da página da UERN que está cada vez mais sendo utilizada. Outra página que posso citar é a “ler para ver” - uma página de Portugal. A página do gmail precisa melhorar. Apesar de eles terem colocado uma versão só com HTML puro, sem AJAX. Quando eu vou configurar, tem coisas que não consigo acessar, como a configuração para o protocolo pop. 9. Durante o curso de graduação você viu diversas disciplinas e viu que a área de informática é bem diversificada (banco de dados, redes de computadores, otimização e inteligência artificial), Qual dessas áreas você mais se identificou e por quê? O que mais me identifiquei foi com as áreas de análise de sistemas, banco de dados e a de engenharia de software. Essas 3 foram as que mais me chamaram a atenção. Pela organização que elas impõem que não é só a programação. Na disciplina de Banco de dados, me identifiquei muito com Mineração de dados que é uma tecnologia que visa descobrir conhecimentos no banco de dados. Aplicando essa técnica em um banco de dados é possível descobrir coisas que são muito difíceis de serem detectadas somente por pessoas, devido à extrema complexidade dos dados. 10. Quais são seus planos quando concluir a graduação. Concurso, Mestrado, outros? Estou pensando em entrar no mercado de trabalho, na área de computação, seja concurso ou emprego. Mas vou visar concurso e vou estudar para isso. Minha meta é concurso, mas eu quero trabalhar na área de informática sendo profissional de informática. O mestrado tenho interesse também, mas quando eu já estiver trabalhando.

117 11. Soube que você fez o trabalho: Mineração de dados da Indústria petrolífera. Fale um pouco sobre ele. Era para conseguir o melhor caminho para os poços de petróleo? Qual era o problema e o que você procurava obter? O problema era avaliar a base de dados da Petrobrás no intuito de descobrir padrões para conseqüentemente chegar a novas descobertas e até novos conhecimentos. Poderiam ser dados relacionados a poços petrolíferos, como qualquer outro tipo de dados. A idéia é que se fosse detectado algum conhecimento, que fosse implantado com o objetivo de gerar lucro para a empresa. Tentamos fazer esse trabalho, mas não foi bem sucedido porque não tivemos acesso a dados sigilosos, devido à política de segurança interna da empresa não permitir. 12. Gostaria de saber o seu perfil: Você se identifica mais com o dia-a-dia do mercado de trabalho ou prefere se envolver em projetos de pesquisa em busca de inovações tecnológicas? Ou ainda um pouco de cada? Um pouco de cada, sendo que meu foco atualmente está para o mercado. 13. Agora voltando o foco para o site da UERN. Quando você acessa o Portal UERN, qual a seção que você utiliza mais? A seção do site que mais utilizei foi a COMPERVE e ENCOPE. 14. Você sentiu dificuldade em encontrar determinado tipo de conteúdo? Tive problemas. Às vezes não consegui achar o link referente à COMPERVE. Não estava bem claro. Ficava muito longe, lá no meio da página e eu precisava navegar por muita informação para poder chegar lá, então isso dificultava muito. E na página do ENCOPE tive certa dificuldade com os formulários, mas aos poucos foi melhorando. 15. Fique a vontade para dizer suas considerações e repassar alguma mensagem para os leitores?

118 As tecnologias estão cada vez mais se aprimorando, inclusive aqui no Brasil estamos tendo um avanço muito grande. O Brasil é um dos países no mundo que tem mais acesso a internet. Vem crescendo também o acesso a computador e isso possibilita que esta tecnologia seja bem aproveitada. Outro fato interessante é que as tecnologias voltadas para os portadores de necessidades especiais estão melhorando significativamente. Uma iniciativa boa vem dos softwares livres que possibilitam também a inclusão digital. Não só do usuário leigo mais também do usuário cego. Quando iniciei a faculdade jamais imaginei que poderia utilizar o Linux e agora estou terminando e sei que é totalmente possível. Houve um avanço enorme da tecnologia assistiva nos últimos quatro anos. Isso comprova realmente que a informática é muito dinâmica. Então é interessante que as pessoas possam ter acesso a essas tecnologias e também possam criar novos produtos, pois nosso mundo é feito de idéias e quem conseguir vender uma idéia inovadora, poderá ser reconhecido e também ser bem sucedido financeiramente. 4.3 TESTE DE USABILIDADE O teste que faremos aqui é um pouco diferente do sugerido na seção de teste de usabilidade. Por termos um aluno então decidimos utilizar tarefas mais específicas para deixar o teste um pouco mais minucioso. Tentamos colocar um clima de imediatismo nas tarefas para tentar aproximar um pouco de uma situação real. Segue abaixo as tarefas: Tarefa 01 Você está tendo a chance de conseguir uma vaga em um mestrado na UFRN ou UFC, então eles pedem uma recomendação de professores daí você precisa urgentemente procurar pelo e-mail de 2 professores de computação. Para depois entrar em contato. Só que esse contato tem que ser efetuado o mais rápido possível, não pode deixar para depois.

119 Tarefa 02 Você tem uma prima que está tentando saber novidades sobre a data do vestibular. Só que ela falou que está nervosa, pois não tem lan house perto da casa dela e quer que você consiga o telefone do setor de vestibular da UERN urgentemente para tirar uma dúvida mais específica. Tarefa 03 Um professor de outra universidade está interessado em acessar suas produções e pede o endereço da página em que elas estão hospedadas. Então você precisa acessar a página do ENCOPE através do portal, depois copiar o endereço da página especifica do ENCOPE para enviar para o professor o quanto antes. 4.4 RESULTADOS O primeiro teste foi finalizado em 6min. O segundo terminou em 2:20. O terceiro em apenas 50 segundos. Trata-se de um usuário avançado e experiente na utilização de interfaces e de softwares de leitura de tela. A demora maior do primeiro teste não implica em reformulação. Apesar do caminho até a lista de professor ser um pouco distante, já existe um link que leva direto para o professor online, que é um ambiente onde é possível achar o professor com mais facilidade. A demora resultante é que o processo de leitura da página pelo JAWS é seqüencial, mesmo com os atalhos para determinados links, ele precisou um pouco de paciência para achar os professores na lista. O agrupamento dos menus está de forma intuitiva, tanto que nos testes em seguida ele conseguiu com rapidez encontrar o que queria. Teve também que ter um pouco de paciência para encontrar o telefone da COMPERVE, pois não estava no início da página, mas conseguiu completar com sucesso. Visualmente o telefone está em um lugar facilmente encontrado. No decorrer dos testes enquanto ele passava pelas páginas da UERN, ia para o email e voltava, ele nos falou que não conseguia identificar se estava na página principal ou não. Esse ponto é algo que vai facilitar para os usuários leitores de tela. A página já foi modificada e na página principal já consta no título a descrição “Página principal”, quando o usuário estiver na respectiva página. Esse teste foi muito interessante, pois verificamos ao mesmo tempo dois itens: a

120 acessibilidade e a usabilidade. O primeiro detecta se existe alguma barreira que empeça o usuário de chegar até o conteúdo que deseja, que constatamos que não houve já que os três testes foram finalizados com sucesso. O segundo detecta o nível de conforto com que o usuário conseguiu finalizar a tarefa. O primeiro teste foi o que exigiu mais esforço, mas como já foi dito, não implica em mudanças, pois já foi colocada redundância de um link direto para um ambiente de busca de professores.

121 5. CONSIDERAÇÕES FINAIS Esse trabalho retrata somente um ponto de vista possível no desenvolvimento web, não pretende, não pode, nem deve ser tomado como solução para todos os problemas. Porém como todo ponto de vista, pode e deve ser utilizado para comparações e possivelmente incrementar algum procedimento por constatação de melhorias, e também descartar o que não for contextualmente adequado. Como sabemos que um universo amplo como o de desenvolvimento web pode ser passível de diversas interpretações, resolvemos adicionar duas breves seções que servirão para evitar distorções com relação aos paradigmas adotados. Essas seções servirão também como um reforço para o item bom senso da metodologia Acessibilidade de Verdade. Em nenhum momento iremos comparar nosso ponto de vista com outros em termos de valor (melhor ou pior), nosso objetivo é somente de descrever esse ponto de vista para que o leitor passe a conhecer o contexto e o paradigma e então, a partir daí tire suas próprias conclusões. 5.1 COMO NÃO DEVEMOS INTERPRETAR ESSE TRABALHO Apesar de termos uma divisão seqüencial entre as principais etapas que colocamos como relevante - Arquitetura da Informação, Padrões Web, Acessibilidade, Usabilidade, acompanhamento de tendências - o processo real não foi seqüencial. Foi colocado dessa forma no texto por fins didáticos para facilitar a compreensão. Em determinados momentos, podemos estar resolvendo um problema que envolve uma ou mais das áreas citadas. Podemos colocar um div de notícias (Padrões Web) em um local adequado (arquitetura informação) e com tamanho e contrastes relevantes para que se consiga um conforto na utilização (usabilidade) e na imagem ilustrativa da notícia, colocar o texto alternativo no atributo alt (acessibilidade). Outro ponto que poderia gerar confusão com relação às áreas distintas é a possível interpretação de separação de atividades como Arquiteto da Informação, Engenheiro de Usabilidade, Analista de Sistema e Programador. Apesar de isso ser possível e termos casos de sucesso no Brasil, como por exemplo, a “globo.com” que tem funcionários específicos para a área de usabilidade. Porém, a nossa proposta é exatamente a inversa. O nosso objetivo é que todos os envolvidos no desenvolvimento consigam uma visão geral de todo o processo, pois

122 acreditamos que uma separação por áreas gera alienação do processo que pode trazer conseqüências negativas para qualidade, além de gerar burocracia (excesso de documentos passando entre os profissionais das áreas distintas) que acreditamos ser desnecessárias por não contribuir efetivamente para a qualidade do produto final (satisfação do usuário), funcionando "aparentemente" mais como um pretexto para garantir a separação de funções entre os funcionários dos diversos cargos e garantir o processo burocrático, do que mesmo um propósito mais nobre que seria um processo produtivo que gere sites úteis e de qualidade. Uma conseqüência dessa divisão é a interpretação duvidosa que pode ser gerada com relação ao desenvolvimento web, no qual se cria um cargo tido como "mais nobre" (Analista, Arquiteto da Informação) que só cria a especificação que será lida e "traduzida", "codificada" para gerar o software por pessoas que possuem outro cargo tido como "menos nobre". Esse ponto de vista se assemelha ao processo de linha de produção de Henry Ford, no qual cada profissional tinha uma tarefa específica e se especializaria somente nela para otimizar o processo. Esse processo foi um marco na fabricação de carros e se adaptou bem a tarefas de natureza mecânica. Na década de 40, a Toyota buscou formas para criar um sistema de produção de automóveis enxuto e ágil, que utilizasse somente o indispensável para cada tarefa. Esse processo foi aperfeiçoado no decorrer dos anos e ficou conhecido como "Just in Time". Nele tudo só deve ser produzido, transportado ou comprado na hora que realmente for necessário, reduzindo dessa forma o estoque e os custos associado ao mesmo. Além desse ponto essencial da metodologia que é o de evitar desperdício existem outros princípios que a complementam. Um desses princípios complementares do modelo da Toyota mostra que cada funcionário terá a visão geral do processo (POPPENDIECK & POPPENDIECK, 2003 apud TELES 2005) e é considerado o funcionário mais importante o que realmente está com a "mão na massa", literalmente falando, o que se "suja de graxa". Podemos notar claramente, a inversão de papéis entre uma metodologia e outra. Nossa forma de trabalho se assemelha bastante a esse princípio da Toyota, em que as áreas de conhecimento (usabilidade, acessibilidade, etc.) são recursos que devem estar à disposição do programador, o profissional que consideramos o mais relevante no processo. É um equívoco utilizar termos como codificador, tradutor, pois diferente da linha de montagem de Henry Ford que era utilizada com sucesso em atividades mecânicas, a atividade do programador é intelectual, criativa, até intuitiva e em alguns pontos comparados com uma arte. É uma atividade dinâmica de constante inovação, à procura do formato mais legível e otimizado de

123 fazer o computador auxiliar o ser humano de uma forma confortável. Nesse ponto de vista, a atividade de análise deve ser utilizada e aprimorada pelo próprio programador; ele é responsável para, de acordo com a necessidade, ir para um nível mais geral de planejamento e depois voltar para o nível mais específico de construção do produto (software), além de ficar “antenado” com relação às dificuldades do usuário para continuar aprimorando o software em um processo incremental. As mudanças já são esperadas. Elas são efetuadas com muita rapidez por não haver burocracia, uma vez que não existe divisão do processo em cargos. Outro equívoco dos processos tradicionais de software é imaginar que o processo de desenvolvimento de software deve ser semelhante ao da Engenharia Civil, com seus projetos minuciosos, validados e aprovados antes de iniciar a construção de um prédio. Esse é um ponto de vista muito ingênuo e é preciso ser detalhado. Para que fique bem claro o equivoco, vamos comparar a natureza das duas atividades para ver se estão em harmonia. A natureza de uma construção é concreta e está sobre influência de variáveis concretas como: gravidade, tipo de solo, velocidade dos ventos, entre outros. Por outro lado, a natureza do software vem a partir de uma representação abstrata de seqüência de bits, que é uma convenção de dois estados: desligado e ligado. Gravidade aqui não existe, nem existe nenhuma outra variável que influencia em um prédio. Devido à natureza de dígitos, o software é altamente flexível, adaptável, facilmente modificável. Na construção não podemos começar um prédio pelo telhado, devido ao limite imposto pela gravidade. Porém, em um software, podemos começar o design do prédio literalmente pelo teto ou podemos criar uma classe Casa e executar primeiramente o método criarTelhado( ); a ordem não importa. Depois que um prédio está pronto, fica inviável uma mudança de 20 metros para esquerda. Já no software, depois de pronto, ele pode ser facilmente modificado para atender às novas necessidades; é altamente flexível. Como podemos comprovar, são de naturezas completamente distintas. Utilizar a abordagem minimalista de reutilizar processos de um no outro poderá trazer problemas como excesso de burocracia e documentação e demora nas atualizações, além de correr o risco de não ser atualizado de uma forma que fique mais confortável para o usuário. Claro que existem exceções. Uma delas seria para os sistemas que vão atuar em atividades onde o risco é alto, como sistemas em tempo real. Nesses casos, deve ter uma especificação bem detalhada antes de produzir, pois a falha no software pode gerar até risco para a vida humana.

124 Mas no nosso caso, que se trata de um sistema web de médio porte, no qual é admissível a falha do sistema por certos períodos, não é de bom senso exagerar nas especificações antes de começar a desenvolvê-lo. O programador pode iniciar com poucas telas e em um processo incremental de análises e programação ir dando seqüência até obter um produto final. A burocracia nesse caso atrapalha, pois tenta acrescentar algo que não é preciso, já que o sistema é produzido no intuito de ser modificado e aprimorado continuamente. Quando a complexidade for grande, o programador pode utilizar-se de recursos para planejamento como Diagramas Entidade Relacionamento, Diagrama de Classes ou Wireframes, por exemplo. A documentação utilizada é a mínima possível. O intuito maior é de planejar e implementar de forma eficiente. 5.2 COMO DEVEMOS INTERPRETAR ESSE TRABALHO Este trabalho pode ser visto como um arcabouço de princípios e técnicas que foram aprimoradas de forma incremental, sempre com a visão do todo, nunca com separação de funções (não existe o arquiteto da informação). Existiu um compromisso de procurar fazer o melhor dentro dos limites, em benefício do usuário. Pode ser interpretado também como um histórico de problemas que enfrentamos e procuramos resolver a cada versão. A primeira preocupação foi criar uma estrutura flexível e acessível. Conseguimos isso com as tecnologias e metodologias indicadas pelo W3C, utilizando separação entre conteúdo (HTML) e formatação (CSS). Tendo a base inicial consolidada, a cada ano fomos analisando as principais necessidades dos usuários e aprimoramos em termos de acessibilidade, usabilidade e conforto visual, para permitir simplificação da utilização da interface. Esse trabalho foi também uma tentativa de unir conhecimentos, técnicas e formalismos do mundo acadêmico ao dinamismo da resolução de problemas e tomadas de decisões de um projeto real de desenvolvimento web. São mundos que em certos momentos não se conversam muito bem, mas tentamos dar uma tonalidade de complementação. Apesar do mercado e academia seguirem caminhos divergentes, de vez em quando, é interessante um olhar onde inclua uma tonalidade dos dois mundos, para que a academia possa de repente rever alguns conceitos e procurar, na medida do possível, contextualizá-los com necessidades do mercado e o mercado

125 também possa “dar o braço a torcer” e ficar atualizado com as inovações tecnológicas que a academia possa oferecer para otimizar seu ambiente. 5.3 CONCLUSÕES O esforço didático de detalhar a metodologia Acessibilidade de Verdade, proposta pelo acessodigital.com foi muito proveitoso. Conseguimos englobar o universo do desenvolvimento web em uma fórmula simples de entender e lembrar. Essa fórmula permitiu que fosse mostrada uma variedade de informações, tanto gerais como pontuais e ainda assim manter uma unidade coerente e bem estruturada. A escolha do feedback, formulário de contato, foi um mecanismo essencial para as tomadas de decisões nas modificações que foram efetuadas no Portal UERN. Outro ponto que contribuiu bastante para os resultados efetivos foi a decisão de realizar mudanças graduais, sem pressa. O complemento imprescindível da estratégia foi a criação de uma base inicial flexível devido a utilização adequada dos Padrões Web e as diversas técnicas abordadas nesse trabalho. Essa base flexível permitiu que as mudanças fossem efetuadas com muita rapidez e sem prejudicar a qualidade do site em termos de usabilidade e acessibilidade. Apesar do feedback ser lento e passível de distorções, dado a natureza indireta do mecanismo, ele foi satisfatório, como confirmou-se nos resultados na seção Evolução do Portal UERN. Deixamos de receber as mensagens dos problemas resolvidos e também não nos preocupamos em analisar detalhadamente as mensagens recebidas, pois as mais importantes eram coincidentemente as que mais se repetiam e isso tornava óbvia a tarefa de decidir o que seria modificado. Como estamos sempre acompanhando tendências e até aplicando algumas como os Microformatos, também somos flexíveis para na medida da nossa necessidade aplicarmos outros tipos de métodos para tomar decisões de mudanças como no caso de efetuar mais testes com usuários. A idéia é que essa evolução seja gradual, sem pressa e que seja bem pensada e analisada. Focar-se somente em um dos pontos abordados (técnicas explicitadas no referencial teórico) não dá garantia de que uma página seja realmente acessível e confortável. A utilização

126 dos diversos pontos em conjunto, o acompanhamento de tendências tecnológicas e das necessidades dos usuários, a utilização correta dos padrões web, complementada com uma validação mais detalhada das recomendações de acessibilidade e refinada com princípios e técnicas de usabilidade é que fará a diferença na qualidade e conforto da página. É preciso exercitar entre os integrantes de equipes de desenvolvimento web, técnicas que façam com que todos consigam ter uma visão geral do processo de desenvolvimento, pois isso evita desentendimentos de opiniões, evita falha de implementar visões diferentes, agiliza o processo, pois todos tendem a “falar a mesma língua”, além de conseguir uma equipe mais preparada para futuros incrementos, modificações, manutenções, que tendem a ser implementadas com o mínimo de esforço. Visão de todo o processo é mais empolgante, reduz falhas e deixa a equipe muito mais preparada para o futuro! As novidades e recursos tecnológicos que estão sendo criados devem ser analisados com bom senso para só depois chegar à conclusão se deve ou não ser colocado no site ou sistema; devemos tomar como base se o recurso será realmente útil para os usuários do site. Alguns desses recursos já estão consagrados como é o caso do RSS (Really Simple Syndication), porém outros recursos devem passar por uma avaliação mais detalhada para detectar se são acessíveis, evitando dessa forma, exageros como disponibilizar um site inteiro feito em flash que não possa ser lido por leitores de tela, o que faz com que o site perca uma parcela de usuários que possam ser importantes. Bom senso nunca é demais! Não se faz acessibilidade por caridade. Faz-se acessibilidade porque a acessibilidade é algo que valoriza o desenvolvedor no mercado, além de também facilitar a vida dele em futuras manutenções. Valoriza a instituição. Nas instituições públicas do Brasil é obrigatório que suas páginas sejam acessíveis. As empresas que utilizam páginas acessíveis atingem um número maior de clientes proporcionando expectativa para aumentar cada vez mais esse número. O usuário cego pode comprar um livro para um parente, mas também a interface poderá estar sendo utilizada através de dispositivos móveis, por exemplo. Portanto se faz acessibilidade porque acessibilidade é bom para todo mundo, e a falta dela poderá deixar a página obsoleta em pouco tempo. Isso significa problemas para os usuários, para o desenvolvedor, para o dono da empresa e para a instituição pública responsável pela página. Então a acessibilidade é essencial porque além de ser algo bom para todo mundo, já no presente, evita muita “dor de cabeça” no futuro!

127 A acessibilidade deve ser pensada tanto em algo que já pode ser útil hoje como em algo que possa vir a ser mais útil ainda, no futuro, graças a inovações tecnológicas que venham a aparecer. Uma possibilidade seria um sintetizador de voz embutido em um automóvel onde ele leria as principais notícias dos sites escolhidos pelo dono do automóvel. Já pensou se o motorista encontra um site com problemas graves de acessibilidade e se esse site era essencial para tirar a dúvida dele naquele momento? Um site acessível é algo que já é muito bom hoje e poderá ser melhor ainda no futuro, devido a sua flexibilidade e fácil adaptação a novos dispositivos e aplicativos que tendem a surgir. É resolver bem o agora já se preparando para o amanhã! Além dos argumentos citados acima, colocamos outro citado por Zeldman (2007): usar Padrões Web e focar na acessibilidade ajuda o seu site a tornar-se amigável perante as leis de acessibilidade vigentes. No caso do Brasil, como foi apontado no inicio, essa lei já existe e já está em vigor focando os sites de instituições públicas. Apesar de o trabalho ter uma ênfase muito grande na acessibilidade, consideramos um item essencial para quem está iniciando o que fala sobre os Padrões Web, pois quando o desenvolvedor domina esse item ele já estará praticando muitos princípios de acessibilidade e até de usabilidade sem nem perceber. Isso fará com que ele se interesse pelos demais tópicos e se aprimore na atividade complexa do desenvolvimento web. Portanto, quem quer dar um passo de cada vez, recomendamos que leia primeiro sobre Padrões Web. É como começar o desenvolvimento com o “pé direito”. Os demais assuntos irão se encaixando harmonicamente quando esse ponto for dominado. Apesar de o trabalho ser bem abrangente, no título foi colocado somente o termo chave Acessibilidade. Essa escolha foi feita baseando-se nos seguinte parâmetros: a) Como já foi dito acessibilidade na web é um termo amplo que indica que o software deve funcionar independente de dispositivo, de sistema operacional, de navegador e inclusive para usuários com necessidades especiais. b) Com objetivos didáticos foi detalhada a metodologia Acessibilidade de Verdade que engloba um universo muito abrangente de técnicas de desenvolvimento web, o que justificaria a utilização desse termo para representar um universo maior. c) Apesar de ser indispensável a utilização dos padrões web na criação da página, é preciso que eles sejam utilizados de uma forma que priorizem a acessibilidade. Um

128 desenvolvimento focado na acessibilidade torna o site mais flexível e facilita muito as mudanças. d) Está claro que focar na acessibilidade fará com que todas as mudanças e adaptações futuras sejam realizadas com naturalidade e o termo Acessibilidade foi escolhido para o título por ser capaz de representar bem a abrangência desse trabalho. Esse argumento não elimina a nossa sugestão do iniciante começar lendo a seção sobre Padrões Web, já que suas tecnologias já seguem muitos princípios de acessibilidade e à medida que ele for construindo o produto real (site), aprenderá conseqüentemente os demais princípios com facilidade. O bom senso que tanto é falado no decorrer do texto, que também é um dos pontos essenciais na metodologia Acessibilidade de Verdade, só se consegue com o tempo e com muita dedicação. O que ajuda a encurtar a distância é estar sempre próximo de profissionais mais experientes e também ficar atento ao comportamento dos usuários. Não existe solução que resolva todos os problemas. Esse trabalho teve como objetivo abordar diversos conceitos que podem auxiliar no desenvolvimento web. Provavelmente, existem outras maneiras de resolver esses problemas. Esse trabalho deve ser visto como um recurso que pode ser utilizado, interpretado, questionado, adaptado e aprimorado quando necessário. 5.4 TRABALHOS FUTUROS Como sugestões para outros trabalhos que venham tomar com base esse tema podemos colocar:  Utilizar as técnicas abordadas nesse trabalho em outros sites: de instituições públicas ou privadas.  Aprimorar o teste com usuário para deixá-lo em um formato que possamos tirar mais inferências, já que nesse trabalho só colocamos uma demonstração simplificada.  Como o foco foi mais nas páginas principais em trabalhos futuros podemos mudar um pouco o foco para páginas internas mais específicas e contextualizadas.

129  Podemos aprimorar também o item que fala sobre o acompanhamento das tendências, incluindo novas soluções tecnológicas que melhorem a experiência dos usuários e também adicionando novas técnicas de acompanhamento do comportamento do usuário.  Outra atividade interessante seria criar um gráfico de representação dessa metodologia utilizada nesse trabalho: Acessibilidade de Verdade. Que é dividida nas cinco etapas representando os recursos: Organização da informação, utilização adequada dos Padrões Web, validação da Acessibilidade, complementação com Usabilidade e acompanhamento de tendências. Todas essas etapas devem ser executadas tomando como base o público alvo e também todas as informações devem ser filtradas e utilizadas com bom senso, quando realmente forem necessárias.

130 6. REFERÊNCIAS Acesso Digital. Disponível em http://acessodigital.net/. Acessado em março de 2008. ALLEN, David. Getting Things Done: The Art of Stress-Free Productivity. New York: Peguin Books, 2001. AMSTEL, Frederick Van. Afinal o que é Usabilidade? Disponível em http://www.usabilidoido.com.br/afinal_o_que_e_usabilidade.html. Acessado em março de 2008. ANDRADE, Walmar. Testar é Preciso Heurística não é Preciso? Disponível em http://fatorw.com/2007/07/18/testar-e-preciso-heuristica-nao-e-preciso/. Acessado em março de 2008. BRASIL, Decreto nº 5.296, de 02 de dezembro de 2004. Disponível em: http://www.trt02.gov.br/geral/tribunal2/Legis/Decreto/5296_04.html. Acessado em março de 2008. DIAS, Cláudia. Usabilidade na WEB. Criando Portais mais Acessíveis. 2 ed. Rio de Janeiro: Alta Books, 2007. DIAS, Cláudia. Heurísticas para Avaliação de Usabilidade de Portais Corporativos, disponível em http://www.geocities.com/claudiaad/heuristicas_web.html. Acessado em março de 2008. EIS, Diego. Acessibilidade e os Padrões Web. Disponível em http://www.tableless.com.br/acessibilidade_e_padroes. Acessado em Março de 2008. Getting Real. Disponível em http://gettingreal.37signals.com/GR_por.php. Acessado em março de 2008. HOLZSCHLAG, Molly E. 250 Segredos para Web Designers. Tradução de Marcos Vieira. Rio de Janeiro: Elsevier, 2005. Inmetro. Padronização de Plugues e Tomadas no Mercado Brasileiro. Disponível em http://www.inmetro.gov.br/qualidade/pluguestomadas/index.asp. Acessado em março de 2008 JOHN, Big. BERGEVIN, Holly. CSS Hacks and IE7, 2005. Disponível em http://www.positioniseverything.net/articles/ie7-dehacker.html. Acessado em março de 2008 KRUG, Steve. Don’t Make Me Think! A Common Sense Approach to Web Usability. New Riders: Indianapolis, 2000. NIELSEN, Jakob. Projetando Websites. Tradução de Ana Gibson. Rio de Janeiro: Elsevier, 2000.

131 QUEIROZ, Marco Antonio. Como Fazer Acessibilidade nas Páginas da WEB. 2003. Disponível em http://www.bengalalegal.com/acesso.php. Acessado em março de 2008. REIS, Guilhermo Almeida dos. Centrando a Arquitetura de Informação no Usuário. São Paulo, 2007a. Dissertação (Mestrado) - Escola de Comunicação e Artes, Universidade de São Paulo. REIS, G. Arquitetura da Informação, Guilhermo.com. Disponível em: http://www.g. Acesso em: 27 ago 2007b. REIS, G. Aula de AI na ECA: Documentação. Disponível em: http://www.guilhermo.com/ai/apresentacoes/04-11-08_Aula_AI_ECA_Documentacao.pdf. Acessado em: março de 2007c. TAUBERER, Joshua, What is RDF. Disponível em http://www.xml.com/pub/a/2001/01/24/rdf.html?page=1 TELES, Vinícius Manhães. Um Estudo de Caso da Adoção das Práticas e Valores do Extreme Programming. Rio de Janeiro, 2005. Dissertação (Mestrado) – Núcleo de Computação Eletrônica, Universidade Federal do Rio de Janeiro. TORRES, Bruno. Acessibilidade não é altruísmo. Disponível em http://acessodigital.net/art_aces_nao_e_altruismo.html. Acessado em Março de 2008. Web Accessibility Initiative (WAI), disponível em http://www.w3.org/WAI/. Acessado em março de 2008. WebAIM. Creating Accessible Macromedia Flash Content. Disponível em http://www.webaim.org/techniques/flash/. Acessado em março de 2008. Web Standards Project. Disponível em http://www.webstandards.org/ Acessado em março de 2008. Welie.com. Patterns in Interaction Design. Disponível em http://www.welie.com/index.php. Acessado em março de 2008. W3C. Recomendações para a acessibilidade do conteúdo da Web - 1.0, Disponível em http://www.geocities.com/claudiaad/acessibilidade_web.html. Acessado em março de 2008 W3C. Primer: Getting into RDF & Semantic Web using N3. Disponível em http://www.w3.org/2000/10/swap/Primer. Acessado em março de 2008. World Wide Web Consortium (W3C), disponível em http://www.w3.org/. Acessado em março de 2008. ZELDMAN, Jeffrey, Designing with Web Standards. 2 ed. Berkeley: New Riders, 2007.

132 ANEXOS Heurísticas para avaliação de usabilidade de portais corporativos GUIA ELABORADO EM 10 DE MAIO DE 2001 Este documento foi elaborado por Cláudia Dias, MSc em Ciência da Informação (Universidade de Brasília), e extraído de sua dissertação de Mestrado - Referência: DIAS, Cláudia. Métodos de avaliação de usabilidade no contexto de portais corporativos: um estudo de caso no Senado Federal. Brasília: Universidade de Brasília, 2001. 229p. Este documento encontra-se no endereço: http://www.geocities.com/claudiaad/heuristicas_web.html. Autor: mailto:claudiaad@yahoo.com A manutenção e revisão deste documento é da responsabilidade de Cláudia Dias, auditora da tecnologia da informação do Tribunal de Contas da União (TCU). A reprodução e distribuição deste documento é livre, desde que citada a fonte (referência mencionada acima). [sumário] SINOPSE As presentes heurísticas explicam como melhorar a usabilidade de portais corporativos web, e se destinam a todos os criadores de conteúdo Web (autores de páginas e projetistas de sites). O principal objetivo destas recomendações é orientar a avaliação de sites web e promover sua usabilidade, tornando mais fácil e rápido o acesso a informações disponíveis em portais web institucionais. Por favor envie comentários sobre este documento para o endereço claudiaad@yahoo.com. SUMÁRIO  Sinopse  1. Introdução  2. Organização destas heurísticas  3. Heurísticas para avaliação de usabilidade de portais corporativos

133 o 1. Visibilidade e reconhecimento do estado ou contexto atual, e condução do usuário o 2. Projeto estético e minimalista o 3. Controle do usuário o 4. Flexibilidade e eficiência de uso o 5. Prevenção de erros o 6. Consistência o 7. Compatibilidade com o contexto  Glossário  Referências. 1. INTRODUÇÃO As heurísticas definidas neste documento basearam-se na experiência prática de vários pesquisadores em testes com usuários. Foram consideradas, em especial, as heurísticas de usabilidade para web de Nielsen (1994), os critérios ergonômicos de Bastien & Scapin (1993), as recomendações de Bevan (1998), Instone (1997) e Nielsen (1994-1999), as "regras de ouro" para o projeto de interfaces de Shneiderman (1998) e o guia de estilos para serviços de informação via web de Parizotto (1997). 2. ORGANIZAÇÃO DESTAS HEURÍSTICAS Este documento contém 7 heurísticas, ou princípios gerais, sobre concepção da usabilidade de portais web. Cada heurística inclui:  Uma descrição resumida.  Detalhamento e justificativas.  Links para navegação. A presença de três links permite passar para a heurística seguinte (ícone da seta para a direita), para a anterior (ícone da seta para a esquerda), ou para a posição que, no sumário, é ocupada por essa mesma heurística (ícone da seta para cima).  Uma lista de recomendações. 3. HEURÍSTICAS PARA AVALIAÇÃO DE USABILIDADE DE PORTAIS CORPORATIVOS Heurística 1 - Visibilidade e reconhecimento do estado ou contexto atual, e condução do usuário Esta heurística refere-se aos meios disponíveis para informar, orientar e conduzir o usuário durante a interação com o portal corporativo. Em virtude da forma hipertextual, não-linear de interação e da quantidade de páginas disponíveis na Internet, um dos maiores problemas identificados em testes com usuários é sua desorientação. Para minimizar os efeitos dessa desorientação, o portal deve sempre manter o usuário informado

134 quanto à página em que ele se encontra, como chegou até essa página e quais são suas opções de saída, isto é, onde ele se encontra numa seqüência de interações ou na execução de uma tarefa. Uma boa condução facilita o aprendizado e a utilização do portal, possibilitando um melhor desempenho e a diminuição do número de erros. Se os usuários puderem reconhecer onde estão simplesmente olhando para a página em que se encontram, sem a necessidade de relembrarem o caminho percorrido a partir da página principal, a probabilidade de se perderem ou ficarem desorientados será menor. Recomendações:  A página principal do portal deve ser capaz de responder às seguintes perguntas: “Onde estou?” e “O que este portal faz?”.  Apresentar em destaque o nome da página principal em todas as páginas componentes do portal, preferencialmente no canto superior esquerdo. Pode-se usar o termo Home ou o logotipo da empresa/departamento/projeto, por exemplo.  A navegação entre as páginas do portal deve responder às três perguntas: “Onde estou?”, “Onde estive?” e “Para onde posso ir?”.  Apresentar a estrutura ou mapa de navegação do portal, ressaltando a página atual onde o usuário se encontra. Por exemplo, o indicativo “Você está aqui!”, como nos mapas turísticos.  Apresentar, em todas as páginas, os níveis anteriores da estrutura de navegação (em forma de links) até chegar à página atual (em formato textual, sem link).  Na página principal, incluir um diretório com as principais áreas cobertas pelo portal, resumo das novidades e caixa do serviço de busca. É recomendável que a caixa do serviço de busca também apareça em todas as outras páginas do portal.  Em links : o utilizar textos que sejam auto-explicativos, com informações suficientes sobre o conteúdo do endereço apontado. o não usar expressões como “Clique aqui”. o marcar o texto (nome da empresa, título da página, assunto etc.) e não o endereço URL. o apontar exatamente para o conteúdo descrito no link. o usar títulos de links, fornecendo informações, tais como nome e detalhes relevantes do endereço apontado, e ainda se é necessário o usuário se registrar para poder visualizar seu conteúdo. o identificar de forma diferente links para endereços externos ao portal. o em listas de links, é recomendável fazer comentários sobre os endereços apontados.  Usar o atributo ALT , da HyperText Markup Language (HTML), com o significado das imagens para que o texto apareça enquanto estiver sendo feito o download da figura ou quando o usuário optar por suprimir figuras na configuração do seu navegador web.  Em mapas de imagem, colocar ALT em todas as posições clicáveis. Heurística 2 - Projeto estético e minimalista

135 Esta heurística refere-se às características que possam dificultar ou facilitar a leitura e a compreensão do conteúdo disponível no portal. Dentre essas características, destacam-se a legibilidade, a estética e a densidade informacional. Um portal legível e esteticamente agradável facilita a leitura da informação nele apresentada, melhorando inclusive o desempenho do usuário na realização da tarefa proposta e influenciando seu nível de satisfação durante a interação com o portal. Além disso, quanto menos o usuário for distraído por informação desnecessária, maior a probabilidade desse usuário desempenhar suas tarefas de forma eficiente, e menor a probabilidade de erros. O portal não deve conter informações irrelevantes ou raramente necessárias, pois cada unidade extra de informação compete com as unidades relevantes de informação, diminuindo a visibilidade relativa das informações importantes. Na maioria das tarefas, o desempenho dos usuários piora quando a densidade de informação é muito alta ou muito baixa, acarretando a ocorrência mais freqüente de erros. É recomendável estabelecer níveis de detalhamento, apresentando, em primeiro plano, os aspectos mais importantes e gerais, deixando os detalhes para outras páginas suplementares que poderão ser acessadas pelos usuários interessados em mais informações sobre o assunto. Recomendações:  Ocupar de 50 a 80% da página com conteúdo (preferencialmente, 80%).  Ocupar no máximo 20% da página com informações sobre a navegação.  Evitar frames, pois diminuem o espaço disponível para apresentação de conteúdo.  Usar hipertexto para dividir as informações em várias páginas ou níveis de detalhamento.  Usar pequenos parágrafos, subtítulos e listas.  Agrupar os diferentes tipos de informações disponíveis na página, apresentando as mais importantes em primeiro lugar.  Usar espaço em branco para separar conteúdos ou assuntos diferentes.  Fornecer apenas informação útil aos usuários.  Remover os elementos não relacionados às tarefas realizadas pelos usuários.  Testar o projeto da página retirando um elemento de cada vez. Após o teste, retirar os elementos considerados desnecessários.  Não usar propaganda. Se for necessária, utilizar parte do espaço anteriormente destinado à navegação, e não do espaço destinado ao conteúdo.  Evitar menus pull-down com opções para as outras páginas do portal, pois suas opções não ficam visíveis aos usuários.  Evitar imagens. Se forem necessárias, optar por múltiplas ocorrências da mesma imagem.  Evitar imagem ou texto animados, pois distraem o usuário e parecem propaganda. Se forem necessários, devem ser processados apenas algumas vezes.  Não usar imagens tridimensionais.  Evitar desenhos ou texturas no fundo da página. O fundo não deve chamar mais atenção do que a informação.  Usar um conjunto limitado de cores.  Evitar cores berrantes, caracteres brilhando ou piscando.  Para realçar textos, usar cores ao invés de sublinhado ou elementos piscando. O usuário pode confundir o termo sublinhado com um link.

136  Contrastar letras com o fundo (melhor utilizar fundo claro, de cor neutra ou branca, com texto escuro).  Usar no máximo dois tipos de fontes.  Usar tamanho de fonte legível.  Testar vários tamanhos de fonte para ser o padrão. Os tamanhos 10, 12 e 14 são os mais comuns.  Não utilizar tamanho de fonte absoluto. É recomendável usar % do valor definido como padrão.  Não usar caixa alta em excesso.  Usar os níveis de cabeçalho H1, H2, H3. Heurística 3 - Controle do usuário Esta heurística relaciona-se ao controle que o usuário sempre deve ter sobre o processamento de suas ações pelo portal. Os usuários de qualquer sistema interativo esperam deter controle sobre o sistema, fazendo com que este responda a suas solicitações e expectativas. Ações inesperadas do sistema, infindáveis seqüências de entrada de dados, incapacidade ou dificuldade em obter a informação necessária e incapacidade em produzir os resultados desejados contribuem para o aumento da ansiedade e da insatisfação do usuário. As ações do portal devem ser reversíveis, isto é, o usuário deve ser capaz de desfazer pelo menos a última ação realizada. Essa capacidade diminui a ansiedade, pois o usuário sabe, de antemão, que os erros cometidos podem ser corrigidos, encorajando-o a explorar opções desconhecidas do portal. Recomendações:  Possibilitar o retorno à página anterior.  Possibilitar aos usuários interromper ou cancelar o processamento ou transação atual.  Não desviar para outra página, a não ser que o usuário digite Enter ou clique com o mouse.  Não abrir janelas adicionais.  Apresentar em todas as páginas os níveis anteriores da estrutura de navegação (em forma de links) até chegar à página atual (em formato textual, sem link). Dessa forma, o usuário poderá retornar mais facilmente às páginas anteriores.  Apresentar em destaque o nome da página principal em todas as páginas componentes do portal, preferencialmente no canto superior esquerdo. Pode-se usar o termo Home ou o logotipo da empresa/departamento/projeto, por exemplo.  Fornecer serviço de busca em todas as páginas do portal.  Restringir a pesquisa dos serviços de busca apenas ao conteúdo do portal.  Não usar plug-ins auto-instaláveis.  Em páginas de entrada de dados, posicionar o cursor no próximo campo a ser preenchido, porém dando a opção de troca para outro campo.

137  Não apagar ou substituir campo de entrada de dados até que o usuário digite Enter ou clique com o mouse.  Possibilitar entrada de dados a partir do mouse ou teclado e saída de dados em impressora selecionada pelo usuário. Heurística 4 - Flexibilidade e eficiência de uso Esta heurística diz respeito à capacidade do portal em se adaptar ao contexto e às necessidades e preferências do usuário, tornando seu uso mais eficiente. Em função da diversidade de tipos de usuários de um portal, é necessário que sua interface seja flexível o bastante para realizar a mesma tarefa de diferentes maneiras, de acordo com o contexto e com as características de cada tipo de usuário. Deve-se fornecer ao usuário procedimentos e opções diferentes para atingir o mesmo objetivo, da forma que mais lhe convier. Além da flexibilidade, outros procedimentos podem ser adotados para tornar o uso do portal mais eficiente, tais como a eliminação de páginas ou passos desnecessários em uma seqüência para a realização de uma tarefa e o uso de valores padronizados, sem a necessidade de digitação por parte do usuário. Recomendações:  Não usar páginas sem conteúdo útil, como por exemplo páginas apenas com mensagens do tipo "Seja bem-vindo ao portal tal".  Na identificação de links, utilizar termos que exprimam o conteúdo das páginas correspondentes. Não utilizar números ou cores para isso.  Oferecer serviço de busca para pesquisa das páginas do portal, incluindo a possibilidade de verificação ortográfica dos termos digitados em sua caixa de entrada de dados.  Nos resultados de pesquisa do serviço de busca, apresentar os melhores em primeiro lugar, sendo desnecessário o uso de porcentagens ou graus de acerto.  Se não forem encontrados documentos com o termo digitado na caixa de entrada de dados do serviço de busca, oferecer lista com sugestões de palavras mais próximas.  Usar metatags para facilitar a pesquisa dos serviços de busca.  Projetar a caixa de entrada de dados do serviço de busca para caber duas, três ou mais palavras.  Ressaltar as palavras encontradas nos documentos da lista de resultados do serviço de busca.  Evitar rolagem horizontal da tela.  Projetar as páginas de acordo com a resolução dos monitores de vídeo disponíveis aos usuários.  Usar % ao invés de tamanhos fixos, para a adaptação das páginas a qualquer tipo de monitor de vídeo.  Usar % no tamanho de fonte.  Projetar a página considerando o tempo de download nos computadores disponíveis aos usuários: o menos de um segundo entre páginas.

138 o menos de dez segundos para download de arquivos.  Se o download de arquivos for demorar mais do que dez segundos, informar o tamanho do arquivo ao usuário.  Evitar elementos gráficos, pois comprometem o tempo de download das páginas. Se forem necessários, utilizar múltiplas ocorrências do mesmo elemento.  Nos links apontados, colocar / no final do URL, se for um diretório.  Na apresentação de textos, começar sempre pelo mais importante, expondo uma idéia por parágrafo. Informações adicionais devem ser incluídas em outras páginas acessíveis a partir de links apresentados na página inicial do texto.  Projetar a página de forma que as informações ou elementos importantes estejam visíveis, sem a necessidade de rolagem vertical ou horizontal da tela.  Para textos extensos, oferecer a opção de impressão ou download de arquivo. A leitura de textos muito extensos na tela do computador torna-se cansativa para o usuário.  Minimizar a quantidade de cliques necessários para o usuário conseguir o conteúdo final ou informação útil. É recomendável não ultrapassar quatro cliques. Heurística 5 - Prevenção de erros Esta heurística relaciona-se a todos os mecanismos que permitem evitar ou reduzir a ocorrência de erros, assim como corrigir os erros que porventura ocorram. As interrupções provocadas por erros de processamento têm conseqüências negativas sobre a atividade do usuário com o portal, prolongando e perturbando a realização de suas tarefas. Quanto menor a probabilidade de erros, menos interrupções ocorrem e melhor o desempenho do usuário. Para possibilitar a correção de erros, é importante que as mensagens de erro sejam pertinentes, legíveis, redigidas em linguagem natural (sem códigos), exatas quanto à natureza do erro cometido, e sugiram possíveis ações para sua correção. Dessa forma, as mensagens de erro favorecem o aprendizado do sistema, ao indicar ao usuário a razão do erro e suas possíveis correções. Entretanto, melhor do que boas mensagens de erro é, em primeiro lugar, prevenir a ocorrência de erros. Recomendações:  Não usar páginas com a expressão “em construção”. O portal deve apresentar apenas o que já está pronto para ser acessado pelo usuário.  Não liberar portal parcialmente pronto.  Remover dados/páginas desatualizados, como por exemplo, páginas convidando os usuários para participarem de eventos que já ocorreram.  Nos serviços de busca, não usar operadores booleanos nas pesquisas simples. É recomendável oferecer a possibilidade de operadores booleanos apenas em pesquisas avançadas, para serem usadas pelos usuários mais experientes.  Se não forem encontrados documentos com o termo digitado na caixa de entrada de dados do serviço de busca, oferecer lista com sugestões de palavras mais próximas.  Oferecer páginas de ajuda para os usuários inexperientes.

139  Não usar URLs muito extensas ou sem significado.  Evitar hífens ou outros caracteres especiais no endereço das páginas. É preferível justapor duas ou mais palavras, ou abreviá-las.  Usar apenas letras minúsculas no endereço das páginas.  Evitar usar “O” e “0” no endereço das páginas.  Escolher bem os títulos das páginas, de forma que caracterizem bem seu conteúdo. É aconselhável escolher títulos com duas a seis palavras.  Não repetir o mesmo título em duas páginas diferentes.  Não utilizar mapas de imagem que exijam muita precisão ao clicar.  Fornecer mensagens de erro orientadas a tarefas, com sugestões ou instruções simples e construtivas para a correção do erro.  Utilizar mensagens de erro sucintas, precisas, com termos específicos e vocabulário neutro, não repreensivo.  Evitar páginas órfãs, sem qualquer indicação de opções de navegação possíveis.  Evitar frames, pois podem causar erros na impressão do conteúdo da página ou na marcação da página como um endereço favorito (bookmark). Heurística 6 - Consistência Consistência refere-se à homogeneidade e coerência na escolha de opções durante o projeto da interface do portal (denominação, localização, formato, cor, linguagem). Contextos ou situações similares devem ter tratamento e/ou apresentação similares. Um projeto consistente facilita o reconhecimento, o aprendizado, a localização e, por fim, a utilização de um portal por seus usuários. A padronização de formatos, localizações e sintaxe torna o portal mais previsível, diminuindo a incidência de erros e as dificuldades de aprendizado e compreensão. É conveniente padronizar tanto quanto possível os elementos do portal quanto a seu formato, cor, localização e denominação, para que o usuário identifique mais facilmente situações e elementos similares e realize suas tarefas com maior rapidez. A falta de homogeneidade pode comprometer tanto o desempenho quanto a satisfação do usuário com o portal. Recomendações:  Usar sempre a mesma terminologia e a mesma localização de elementos comuns nas páginas de conteúdo, nas páginas de ajuda ao usuário e nas mensagens de erro.  Incluir a caixa de entrada de dados do serviço de busca logo no início de cada página, preferencialmente no canto superior direito.  O comportamento do cursor deve ser consistente em todos os campos de entrada de dados, isto é, o cursor deve saltar automaticamente de um campo a outro ou aguardar Enter ou Tab do usuário.  Verificar se os títulos ou cabeçalhos das páginas correspondem exatamente aos termos utilizados nos links que apontam para essas páginas.  Evitar instruções HTML não padronizadas.

140  Usar um estilo padrão para o projeto das páginas (leiaute, cores, fontes, formatos de campos e mensagens).  Selecionar as cores e o leiaute das páginas dentro de um contexto geral e de forma consistente em todas as páginas.  Evitar sair do padrão web de cores para links : azul para link não visitado e púrpura para link já visitado.  Destacar palavras ou trechos importantes, com o cuidado de não sublinhar em azul trechos ou palavras que não sejam links. É recomendável não sublinhar nada que não possa ser clicado. Heurística 7 - Compatibilidade com o contexto Esta heurística refere-se à correlação direta entre o portal e seu contexto de aplicação. As características do portal devem ser compatíveis com as características dos usuários e das tarefas que estes pretendem realizar com o portal. O desempenho dos usuários de qualquer sistema interativo melhora quando os procedimentos necessários ao cumprimento da tarefa são compatíveis com as características psicológicas, culturais e técnicas dos usuários; e quando os procedimentos e as tarefas são organizados de acordo com as expectativas e costumes dos usuários. O portal deve "falar" a língua do usuário, com palavras, frases e conceitos familiares, ao invés de termos técnicos relacionados ao portal ou à tecnologia web. As convenções do mundo real devem ser seguidas, apresentando informações em uma ordem lógica e natural. Recomendações:  Planejar a estrutura do portal de acordo com o contexto das tarefas realizadas pelos usuários e não com a estrutura organizacional ou com as novidades tecnológicas. A estrutura deve ser determinada pelas tarefas que os usuários pretendem realizar por meio do portal.  Evitar estrutura linear (ordem numérica ou alfabética). As informações devem ser apresentadas seguindo uma ordem lógica relacionada à tarefa a realizar.  Verificar erros de grafia, tomando como base a gramática do idioma utilizado e o glossário de termos técnicos de uso corrente na instituição.  Não usar linguagem de marketing. O enfoque do portal corporativo deve ser o conteúdo e não a propaganda.  Não usar elementos gráficos metafóricos, a não ser que sejam de uso corrente na instituição.  Não usar novos termos quando os termos padronizados forem bem conhecidos pelos usuários.  Utilizar palavras da linguagem natural e/ou técnica corporativa que sejam familiares aos usuários.  Usar formato de data e unidades de medida de acordo com o padrão normalmente utilizado na instituição ou país.

141 GLOSSÁRIO ALT Atributo textual associado a imagens em páginas web. Esse atributo apresenta um texto alternativo enquanto a imagem está sendo carregada pelo navegador ou quando o usuário opta por ignorar imagens na sua interação com o portal. ALT pode apresentar informações adicionais sobre a imagem, antes mesmo que esta seja clicada. bookmark Os navegadores web fornecem a opção de bookmark para que o usuário armazene, em seu computador, o endereço de páginas consideradas interessantes para futuras visitas. caixa alta Letras maiúsculas. enter Tecla para entrada de dados em teclados de computador. home Abreviatura do termo em inglês homepage, que significa página principal. metatags Comandos HTML com metadados sobre uma página web (título, palavras-chave, descrição do conteúdo, autor). O termo metadados significa dados sobre dados. nível de cabeçalho Na linguagem HTML, cada nível de cabeçalho Hn corresponde a um tipo e tamanho de fonte diferente. Quanto menor o número n, maior será o destaque dado ao cabeçalho. plug-ins Programas que são instalados no computador, sem a anuência do usuário, para que determinada função possa ser processada. menus pull-down Menus com opções que só aparecem se o usuário clicar no campo e rolar verticalmente para baixo o menu, para ver todas as opções disponíveis. tab Tecla para tabulação em teclados de computador. REFERÊNCIAS [BASTIEN & SCAPIN] BASTIEN, C. & SCAPIN, D. Critérios ergonômicos para avaliação de interfaces homem-computador. 1993. [on-line], setembro 2000. http://www.labiutil.inf.ufsc.br/indice-1.html. [BEVAN] BEVAN, N. Usability issues in web site design. In: Proceedings of UPA’98, Washington, June 1998. 1998. [on-line], agosto 2000. http://www.usability.serco.com/papers/usweb98.pdf . [CASTRO] CASTRO, E. HTML para World Wide Web: guia rápido visual. São Paulo: Berkeley Brasil, 1996. 173p. [DIAS]

142 DIAS, C. Hipertexto : evolução histórica e efeitos sociais. Ciência da Informação, v. 28, n. 3, p. 267-275, dez. 1999. [on-line], dezembro 1999. http://www.ibict.br/cionline/280399/2839905.pdf . [IBM] IBM. Web design guidelines. 1999. [on-line], outubro 2000. http://www- 3.ibm.com/ibm/easy/eou_ext.nsf/publish/572. [INSTONE] INSTONE, K. Usability heuristics for the web. Oct. 1997. [on-line], junho 1999. http://webreview.com/wr/pub/97/10/10/usability/sidebar.html . [ISO Parte10] ISO 9241 Part 10. Ergonomic requirements for office work with visual display terminals, Part 10: Dialogue principles. 1996. [ISO Parte11] ISO 9241 Part 11. Ergonomic requirements for office work with visual display terminals, Part 11: Guidance on usability. 1998. [LYNCH & HORTON] LYNCH, P. & HORTON, S. Web style guide: basic design principles for creating web sites. 1999. 164p. [on-line], outubro 2000. http://info.med.yale.edu/caim/manual/. [NIELSEN 94] NIELSEN, J. Ten usability heuristics. In: NIELSEN, J. & MACK, R. (eds). Usability inspection methods. New York: John Wiley & Sons, 1994. [on-line], junho 1999. http://www.useit.com/papers/heuristic/heuristic_list.html . [NIELSEN 96] ______. Top ten mistakes in web design. May 1996. [on-line], junho 1999. http://www.useit.com/alertbox/9605.html . [NIELSEN 97] ______. Changes in web usability since 1994. Dec. 1997. [on-line], junho 1999. http://www.useit.com/alertbox/9712.html . [NIELSEN 99a] ______. ”Top ten mistakes” revisited three years later. May 1999. [on-line], junho 1999. http://www.useit.com/alertbox/990502.html . [NIELSEN 99b] ______. The top ten new mistakes in web design. May 1999. [on-line], junho 1999. http://www.useit.com/alertbox/990530.html . [NIELSEN 99c] ______. Designing web usability. Indianapolis, IN: New Riders, 1999. 420p. [PARIZOTTO] PARIZOTTO, R. Elaboração de um guia de estilos para serviços de informação em ciência e tecnologia via web. Florianópolis: UFSC, 1997. Dissertação de mestrado em Engenharia da Produção. [REYNOLDS & KOULOPOULOS] REYNOLDS, H. & KOULOPOULOS, T. Enterprise knowledge has a face. Intelligent Enterprise , v. 2, n. 5, p. 29-34, Mar. 1999. [SHNEIDERMAN] SHNEIDERMAN, B. Designing the user interface: strategies for effective human- computer interaction. 3.ed. Reading, Mass.: Addison-Wesley, 1998. 639p.

http://valeriofarias.com	114
http://find.localstrike.net	3
http://static.slidesharecdn.com	1

Monografia Acessibilidade na Web - Valério Farias

by Valério Farias

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 118

Statistics

Monografia Acessibilidade na Web - Valério Farias Document Transcript