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



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

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

Catalogação da Publicação na Fonte

Bibliotecária: Jocelania Marinho Maia de Oliveira CRB 4 / 1303



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:

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.

Figura 1: Elementos presentes nas páginas no mundo dos padrões web

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:

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

Figura 2: Àreas do conhecimento que dão suporte ao desenvolvimento web

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:

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

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

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:

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:

Figura 5: Ambiente de informação planejado e não planejado. Fonte: REIS, 2007b, p. 03

28

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.

Figura 6: Equilíbrio entre conteúdo, contexto e público alvo. Fonte: REIS, 2007b, p. 04

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:

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

Figura 7: Esquemas de organização da informação. Fonte: REIS, 2007b, p. 13

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

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.

Figura 11: As perguntas de básicas que um site deve responder

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

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

Figura 17: plugs e tomadas variadas e padrão ABNT. (fonte: Inmetro)

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

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

Figura 18: Processo de desenvolvimento de sites comumente utilizado

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:

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:

Código 2: Renderização das tags de título h1 a h6 modificadas pelo CSS

47

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

Código 3: Renderização das tags de título h1 a h6 com posicionamento aleatório

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

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.

Figura 20: Página do acesso digital que utiliza marcação semântica

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

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.

</html>

Código 4: Detalhamento do box model junto com exemplo de borda diagonal

53

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.

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.

Código 5: Centralização de elementos com CSS – parte 01

Código 6: Centralização de elementos com CSS – parte 02

54

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"?>).

Código 7: Centralização de elementos com CSS – final

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):

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.

iehacks.css

#topo {

width: 770px;

wid\th: 750px; /* hack: essa linha é ignorada no IE5 e IE5.5*/

}



Código 9: Resolvendo o problema do box model – parte 01

57

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.





Código 10: Resolvendo o problema do box model – parte 02

58

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.

<!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

59

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).

Figura 21: Blog Now: Renderização do código no navegador

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

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:

Figura 22: Blog Now - renderização do CSS – parte 01

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.

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.

#topo h1 { font-size:32px; color:white; margin:0; /*image replacement*/

height: 52px;

background: url(logomarca.jpg) no-repeat; text-indent: -5000px; overflow: hidden; }

Figura 23: Blog Now - Renderização da imagem no lugar do texto

Código 13: Blog Now: aplicando Image Replacement

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; }

Figura 24: Blog Now - renderização de uma lista de links

Código 14: Blog Now: CSS de tratamento de listas

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

2.4.9.6 Resultado final: interface do Blog Now

#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

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.

http://www.dasilva.org.br/

http://www.w3.org/WAI/ER/tools/complete

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:

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:

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.

<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>

<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 17: Descrição redundante com imagem transparente.

Código 18: Descrição redundante sem imagem transparente.

70

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.

 <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.

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:

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



<html lang="pt">

....

</html>



<cite lang="en">any english text</cite>

Código 20: Identificação do idioma do conteúdo

http://www.loc.gov/standards/iso639-2/php/code_list.php

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.

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

 <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.

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:

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:

<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>



<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 22: Utilização correta de labels em formulários.

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:

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:

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

@prefix : <http://www.exemplo.org/>.

:paulo :temMae :maria .

:paulo :temPai :joao .

<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 26: Exemplo de RDF

Código 27: Exemplo de meta tags.

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 Tradicional

Teste simplificado (sem

desperdício)

Número de usuários por teste Geralmente oito ou mais Três ou quatro.

Seleção dos candidatos Seleção cuidadosa compatível com o

público alvo do site.

Chame algumas pessoas. Quase

todas as pessoas que usam a web

poderão fazer.

Onde testar

Um laboratório de usabilidade, com

um quarto de observação e um

espelho falso entre a sala e o

laboratório.

Qualquer escritório ou sala de

conferência.

Quem realiza o teste Um profissional de usabilidade

experiente.

Qualquer ser humano

razoavelmente paciente.

Planejamento

Testes têm que ser agendado com

semanas de antecedência para

reservar um laboratório de

usabilidade e permitir tempo para

fazer a seleção.

Testes podem ser feitos em quase

qualquer momento. Quase não é

necessário agendar.

Preparação Rascunho, discussão e revisar o

protocolo de teste.

Decida o que você vai mostrar.

O que/Quando fazer o teste? A menos que você tenha um grande

orçamento, teste uma vez quando o

site estiver perto de ser finalizado.

Execute pequenos testes

continuamente por todo o

processo de desenvolvimento

Custo

U$5.000 a U$15.000 (ou mais). Cerca de U$300 dólares (U$50 a

U$100 para pagar cada usuário e

U$20 para 3 horas de gravação de

vídeo).

O que acontece depois

Um relatório de 20 páginas escritas é

disponibilizado uma semana depois,

a equipe de desenvolvimento se

reuni para decidir que mudanças

fazer.

Cada observador escreve uma

página de notas do dia do teste. A

equipe de desenvolvimento pode

discutir no mesmo dia.

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

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

O outro microformato que falaremos é sobre o hcalendar, ele é utilizado para divulgação

de eventos. Vejamos um exemplo:

<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>

<div class="vevent">

<h3 class="summary">Mossoró Cidade Junina</h3>

<p class="description">O Mossoró Cidade Junina é uma Festa Junina do estado do Rio Grande do Norte. O evento ocorre todo ano na cidade de Mossoró. Entre as atrações do evento, estão shows com grandes artistas 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 28: Microformato hcard.

Código 29: Microformato hcalendar.

92

Uma observação que temos que fazer é que a data nos microformatos segue o padrão ISO

86017 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.

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.

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

<div class="geo">Cordenadas Geográficas: <span class="latitude" >37.386013</span>, <span class="longitude">-122.082932</span>

</div>

<a href="http://creativecommons.org/licenses/by/2.0" class="licence" >cc by 2.0</a>

Código 30: Microformato geo.

Código 31: Microformato rel-licence.

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

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).

Figura 32: Análise de Acessibilidade do antigo portal UERN

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.

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.

Figura 36: Análise de acessibilidade da 1ª versão do Portal UERN

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

4

possuem menor quantidade

Figura 38: Análise de Usabilidade da 1ª versão do portal UERN – parte 2

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

É 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.

Figura 41: 3ª versão do Portal UERN – Julho de 2007

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.

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.

Figura 42: Análise de Acessibilidade do Portal UERN – Julho de 2007

109

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).

Código 33: Microformato Geo implementado no Portal UERN

Código 32: Microformato hcard implementado no Portal UERN

110

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

Figura 43: Plugin operator localizando as coordenadas geográficas da UERN

Figura 44: Vista do Campus Central - UERN – Mossoró-RN – Google maps

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:[email protected]

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 [email protected].

SUMÁRIO

Sinopse

1. Introdução

2. Organização destas heurísticas

3. Heurísticas para avaliação de usabilidade de portais corporativos

http://www.geocities.com/claudiaad/heuristicas_web.html


http://www.tcu.gov.br/

http://www.geocities.com/claudiaad/heuristicas_web.html#toc


http://www.geocities.com/claudiaad/heuristicas_web.html#Abstract

http://www.geocities.com/claudiaad/heuristicas_web.html#Introduction

http://www.geocities.com/claudiaad/heuristicas_web.html#organization

http://www.geocities.com/claudiaad/heuristicas_web.html#Guidelines

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

http://www.geocities.com/claudiaad/heuristicas_web.html#gl-visibilidade

http://www.geocities.com/claudiaad/heuristicas_web.html#gl-visibilidade

http://www.geocities.com/claudiaad/heuristicas_web.html#gl-estetica

http://www.geocities.com/claudiaad/heuristicas_web.html#gl-controle-usuario

http://www.geocities.com/claudiaad/heuristicas_web.html#gl-flexibilidade-eficiencia

http://www.geocities.com/claudiaad/heuristicas_web.html#gl-prevencao-erros

http://www.geocities.com/claudiaad/heuristicas_web.html#gl-consistencia

http://www.geocities.com/claudiaad/heuristicas_web.html#gl-compatibilidade-contexto

http://www.geocities.com/claudiaad/heuristicas_web.html#glossary

http://www.geocities.com/claudiaad/heuristicas_web.html#References

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

http://www.geocities.com/claudiaad/heuristicas_web.html#home

http://www.geocities.com/claudiaad/heuristicas_web.html#alt

http://www.geocities.com/claudiaad/heuristicas_web.html#alt

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.

http://www.geocities.com/claudiaad/heuristicas_web.html#menus-pull-down

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.

http://www.geocities.com/claudiaad/heuristicas_web.html#caixa-alta

http://www.geocities.com/claudiaad/heuristicas_web.html#nivel-de-cabecalho

http://www.geocities.com/claudiaad/heuristicas_web.html#enter

http://www.geocities.com/claudiaad/heuristicas_web.html#home

http://www.geocities.com/claudiaad/heuristicas_web.html#plug-ins

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.


http://www.geocities.com/claudiaad/heuristicas_web.html#metatags

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.

http://www.geocities.com/claudiaad/heuristicas_web.html#bookmark


http://www.geocities.com/claudiaad/heuristicas_web.html#tab

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]

http://www.labiutil.inf.ufsc.br/indice-1.html

http://www.usability.serco.com/papers/usweb98.pdf

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.


[NIELSEN 99a] ______. ”Top ten mistakes” revisited three years later. May 1999. [on-line], junho 1999.


[NIELSEN 99b] ______. The top ten new mistakes in web design. May 1999. [on-line], junho 1999.


[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://www.ibict.br/cionline/280399/2839905.pdf

http://www-3.ibm.com/ibm/easy/eou_ext.nsf/publish/572

http://www-3.ibm.com/ibm/easy/eou_ext.nsf/publish/572

http://webreview.com/wr/pub/97/10/10/usability/sidebar.html

http://info.med.yale.edu/caim/manual/

http://www.useit.com/papers/heuristic/heuristic_list.html

http://www.useit.com/alertbox/9605.html

http://www.useit.com/alertbox/9712a.html



Monografia Acessibilidade na Web - Valério Farias

Education

Transcript of Monografia Acessibilidade na Web - Valério Farias