Monografia Acessibilidade na Web - Valério Farias
-
Upload
valerio-farias -
Category
Education
-
view
11.589 -
download
7
description
Transcript of Monografia Acessibilidade na Web - Valério Farias
UNIVERSIDADE DO ESTADO DO RIO GRANDE DO NORTE
FACULDADE DE CIÊNCIAS EXATAS E NATURAIS
DEPARTAMENTO DE INFORMÁTICA
CURSO DE ESPECIALIZAÇÃO EM INFORMÁTICA APLICADA
ACESSIBILIDADE NA WEB: UM ESTUDO DE CASO NO PORTAL UERN
VALÉRIO FARIAS DE CARVALHO
MOSSORÓ – RN
2008
VALÉRIO FARIAS DE CARVALHO
ACESSIBILIDADE NA WEB: UM ESTUDO DE CASO NO PORTAL UERN
Monografia apresentada ao Departamento de
Informática da Faculdade de Ciências Exatas e
Naturais da Universidade do Estado do Rio
Grande do Norte, como parte dos requisitos
para conclusão do Curso de Especialização em
Informática Aplicada.
Orientador: Prof. Dr. Idalmir de Souza
Queiroz Júnior.
MOSSORÓ-RN
2008
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
VALÉRIO FARIAS DE CARVALHO
ACESSIBILIDADE NA WEB: UM ESTUDO DE CASO NO PORTAL UERN
Monografia apresentada ao Departamento de
Informática da Faculdade de Ciências Exatas
da Universidade do Estado do Rio Grande do
Norte, como parte dos requisitos para
conclusão do Curso de Especialização em
Informática Aplicada.
Orientador: Prof. Dr. Idalmir de Souza
Queiroz Júnior.
BANCA EXAMINADORA
__________________________________________________________________________
Prof. Dr. Idalmir de Souza Queiroz Júnior
__________________________________________________________________________
Prof. Dr. Everton Notreve Rebouças Queiroz Fernandes
__________________________________________________________________________
Prof. M. Sc. Jéssica Neiva de Figueiredo Leite
Data de Aprovação: __/__/__
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.
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*/
}
<!--[if IE]>
<link rel="stylesheet" type="text/css" href="iehacks.css" />
<![endif]-->
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.
<!--[if IE]>
<link rel="stylesheet" type="text/css" href="iehacks.css" />
<![endif]-->
<!--[if IE 5]>
<link rel="stylesheet" type="text/css" href="iehacks-5.css" />
<![endif]-->
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.
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.
<!-- Exemplo 1: caso o swf não funcione é substituído por um texto --> <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>
<!-- Exemplo 2: caso não funcione é substituído por uma imagem --> <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
<!-- A página inicia na língua padrão do país: -->
<html lang="pt">
....
</html>
<!-- No caso de existir parágrafos em outra língua faremos o seguinte: -->
<cite lang="en">any english text</cite>
Código 20: Identificação do idioma do conteúdo
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
<!--acrônimos--> <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>
<!--abreviações--> <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>
<!-- formato 1: utilizando listas não ordenadas -->
<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>
<!-- formato 2: separar os links por colchetes -->
[<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"/> <!-- foto pessoal --> <a class="url fn" href="http://valeriofarias.wordpress.com">Valério Farias</a> <!-- site pessoal --> <div class="org">UERN</div> <!-- empresa --> <div class="adr"> <!-- bloco relativo ao endereço pessoal -->
<div class="street-address">Nome da rua</div> <!-- rua --> <span class="locality">Mossoró</span>, <!-- cidade --> <span class="region">RN</span> <!-- estado/região --> <span class="postal-code">59800XXX</span> <!-- CEP -->
</div> <div class="tel">+31 (84) XXXX-XXXX</div><!-- telefone --></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
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
133
o 1. Visibilidade e reconhecimento do estado ou contexto atual, e condução do
usuário
o 2. Projeto estético e minimalista
o 3. Controle do usuário
o 4. Flexibilidade e eficiência de uso
o 5. Prevenção de erros
o 6. Consistência
o 7. Compatibilidade com o contexto
Glossário
Referências.
1. INTRODUÇÃO
As heurísticas definidas neste documento basearam-se na experiência prática de vários
pesquisadores em testes com usuários. Foram consideradas, em especial, as heurísticas de
usabilidade para web de Nielsen (1994), os critérios ergonômicos de Bastien & Scapin (1993), as
recomendações de Bevan (1998), Instone (1997) e Nielsen (1994-1999), as "regras de ouro" para
o projeto de interfaces de Shneiderman (1998) e o guia de estilos para serviços de informação via
web de Parizotto (1997).
2. ORGANIZAÇÃO DESTAS HEURÍSTICAS
Este documento contém 7 heurísticas, ou princípios gerais, sobre concepção da usabilidade de
portais web. Cada heurística inclui:
Uma descrição resumida.
Detalhamento e justificativas.
Links para navegação. A presença de três links permite passar para a heurística seguinte
(ícone da seta para a direita), para a anterior (ícone da seta para a esquerda), ou para a
posição que, no sumário, é ocupada por essa mesma heurística (ícone da seta para cima).
Uma lista de recomendações.
3. HEURÍSTICAS PARA AVALIAÇÃO DE USABILIDADE DE PORTAIS CORPORATIVOS
Heurística 1 - Visibilidade e reconhecimento do estado ou contexto atual, e condução do
usuário
Esta heurística refere-se aos meios disponíveis para informar, orientar e conduzir o usuário
durante a interação com o portal corporativo.
Em virtude da forma hipertextual, não-linear de interação e da quantidade de páginas disponíveis
na Internet, um dos maiores problemas identificados em testes com usuários é sua desorientação.
Para minimizar os efeitos dessa desorientação, o portal deve sempre manter o usuário informado
134
quanto à página em que ele se encontra, como chegou até essa página e quais são suas opções de
saída, isto é, onde ele se encontra numa seqüência de interações ou na execução de uma tarefa.
Uma boa condução facilita o aprendizado e a utilização do portal, possibilitando um melhor
desempenho e a diminuição do número de erros. Se os usuários puderem reconhecer onde estão
simplesmente olhando para a página em que se encontram, sem a necessidade de relembrarem o
caminho percorrido a partir da página principal, a probabilidade de se perderem ou ficarem
desorientados será menor.
Recomendações:
A página principal do portal deve ser capaz de responder às seguintes perguntas: “Onde
estou?” e “O que este portal faz?”.
Apresentar em destaque o nome da página principal em todas as páginas componentes do
portal, preferencialmente no canto superior esquerdo. Pode-se usar o termo Home ou o
logotipo da empresa/departamento/projeto, por exemplo.
A navegação entre as páginas do portal deve responder às três perguntas: “Onde estou?”,
“Onde estive?” e “Para onde posso ir?”.
Apresentar a estrutura ou mapa de navegação do portal, ressaltando a página atual onde o
usuário se encontra. Por exemplo, o indicativo “Você está aqui!”, como nos mapas
turísticos.
Apresentar, em todas as páginas, os níveis anteriores da estrutura de navegação (em forma
de links) até chegar à página atual (em formato textual, sem link).
Na página principal, incluir um diretório com as principais áreas cobertas pelo portal,
resumo das novidades e caixa do serviço de busca. É recomendável que a caixa do serviço
de busca também apareça em todas as outras páginas do portal.
Em links :
o utilizar textos que sejam auto-explicativos, com informações suficientes sobre o
conteúdo do endereço apontado.
o não usar expressões como “Clique aqui”.
o marcar o texto (nome da empresa, título da página, assunto etc.) e não o endereço
URL.
o apontar exatamente para o conteúdo descrito no link.
o usar títulos de links, fornecendo informações, tais como nome e detalhes
relevantes do endereço apontado, e ainda se é necessário o usuário se registrar
para poder visualizar seu conteúdo.
o identificar de forma diferente links para endereços externos ao portal.
o em listas de links, é recomendável fazer comentários sobre os endereços
apontados.
Usar o atributo ALT , da HyperText Markup Language (HTML), com o significado das
imagens para que o texto apareça enquanto estiver sendo feito o download da figura ou
quando o usuário optar por suprimir figuras na configuração do seu navegador web.
Em mapas de imagem, colocar ALT em todas as posições clicáveis.
Heurística 2 - Projeto estético e minimalista
135
Esta heurística refere-se às características que possam dificultar ou facilitar a leitura e a
compreensão do conteúdo disponível no portal. Dentre essas características, destacam-se a
legibilidade, a estética e a densidade informacional.
Um portal legível e esteticamente agradável facilita a leitura da informação nele apresentada,
melhorando inclusive o desempenho do usuário na realização da tarefa proposta e influenciando
seu nível de satisfação durante a interação com o portal. Além disso, quanto menos o usuário for
distraído por informação desnecessária, maior a probabilidade desse usuário desempenhar suas
tarefas de forma eficiente, e menor a probabilidade de erros. O portal não deve conter
informações irrelevantes ou raramente necessárias, pois cada unidade extra de informação
compete com as unidades relevantes de informação, diminuindo a visibilidade relativa das
informações importantes.
Na maioria das tarefas, o desempenho dos usuários piora quando a densidade de informação é
muito alta ou muito baixa, acarretando a ocorrência mais freqüente de erros. É recomendável
estabelecer níveis de detalhamento, apresentando, em primeiro plano, os aspectos mais
importantes e gerais, deixando os detalhes para outras páginas suplementares que poderão ser
acessadas pelos usuários interessados em mais informações sobre o assunto.
Recomendações:
Ocupar de 50 a 80% da página com conteúdo (preferencialmente, 80%).
Ocupar no máximo 20% da página com informações sobre a navegação.
Evitar frames, pois diminuem o espaço disponível para apresentação de conteúdo.
Usar hipertexto para dividir as informações em várias páginas ou níveis de detalhamento.
Usar pequenos parágrafos, subtítulos e listas.
Agrupar os diferentes tipos de informações disponíveis na página, apresentando as mais
importantes em primeiro lugar.
Usar espaço em branco para separar conteúdos ou assuntos diferentes.
Fornecer apenas informação útil aos usuários.
Remover os elementos não relacionados às tarefas realizadas pelos usuários.
Testar o projeto da página retirando um elemento de cada vez. Após o teste, retirar os
elementos considerados desnecessários.
Não usar propaganda. Se for necessária, utilizar parte do espaço anteriormente destinado à
navegação, e não do espaço destinado ao conteúdo.
Evitar menus pull-down com opções para as outras páginas do portal, pois suas opções
não ficam visíveis aos usuários.
Evitar imagens. Se forem necessárias, optar por múltiplas ocorrências da mesma imagem.
Evitar imagem ou texto animados, pois distraem o usuário e parecem propaganda. Se
forem necessários, devem ser processados apenas algumas vezes.
Não usar imagens tridimensionais.
Evitar desenhos ou texturas no fundo da página. O fundo não deve chamar mais atenção
do que a informação.
Usar um conjunto limitado de cores.
Evitar cores berrantes, caracteres brilhando ou piscando.
Para realçar textos, usar cores ao invés de sublinhado ou elementos piscando. O usuário
pode confundir o termo sublinhado com um link.
136
Contrastar letras com o fundo (melhor utilizar fundo claro, de cor neutra ou branca, com
texto escuro).
Usar no máximo dois tipos de fontes.
Usar tamanho de fonte legível.
Testar vários tamanhos de fonte para ser o padrão. Os tamanhos 10, 12 e 14 são os mais
comuns.
Não utilizar tamanho de fonte absoluto. É recomendável usar % do valor definido como
padrão.
Não usar caixa alta em excesso.
Usar os níveis de cabeçalho H1, H2, H3.
Heurística 3 - Controle do usuário
Esta heurística relaciona-se ao controle que o usuário sempre deve ter sobre o processamento de
suas ações pelo portal.
Os usuários de qualquer sistema interativo esperam deter controle sobre o sistema, fazendo com
que este responda a suas solicitações e expectativas. Ações inesperadas do sistema, infindáveis
seqüências de entrada de dados, incapacidade ou dificuldade em obter a informação necessária e
incapacidade em produzir os resultados desejados contribuem para o aumento da ansiedade e da
insatisfação do usuário.
As ações do portal devem ser reversíveis, isto é, o usuário deve ser capaz de desfazer pelo menos
a última ação realizada. Essa capacidade diminui a ansiedade, pois o usuário sabe, de antemão,
que os erros cometidos podem ser corrigidos, encorajando-o a explorar opções desconhecidas do
portal.
Recomendações:
Possibilitar o retorno à página anterior.
Possibilitar aos usuários interromper ou cancelar o processamento ou transação atual.
Não desviar para outra página, a não ser que o usuário digite Enter ou clique com o
mouse.
Não abrir janelas adicionais.
Apresentar em todas as páginas os níveis anteriores da estrutura de navegação (em forma
de links) até chegar à página atual (em formato textual, sem link). Dessa forma, o usuário
poderá retornar mais facilmente às páginas anteriores.
Apresentar em destaque o nome da página principal em todas as páginas componentes do
portal, preferencialmente no canto superior esquerdo. Pode-se usar o termo Home ou o
logotipo da empresa/departamento/projeto, por exemplo.
Fornecer serviço de busca em todas as páginas do portal.
Restringir a pesquisa dos serviços de busca apenas ao conteúdo do portal.
Não usar plug-ins auto-instaláveis.
Em páginas de entrada de dados, posicionar o cursor no próximo campo a ser preenchido,
porém dando a opção de troca para outro campo.
137
Não apagar ou substituir campo de entrada de dados até que o usuário digite Enter ou
clique com o mouse.
Possibilitar entrada de dados a partir do mouse ou teclado e saída de dados em impressora
selecionada pelo usuário.
Heurística 4 - Flexibilidade e eficiência de uso
Esta heurística diz respeito à capacidade do portal em se adaptar ao contexto e às necessidades
e preferências do usuário, tornando seu uso mais eficiente.
Em função da diversidade de tipos de usuários de um portal, é necessário que sua interface seja
flexível o bastante para realizar a mesma tarefa de diferentes maneiras, de acordo com o contexto
e com as características de cada tipo de usuário. Deve-se fornecer ao usuário procedimentos e
opções diferentes para atingir o mesmo objetivo, da forma que mais lhe convier.
Além da flexibilidade, outros procedimentos podem ser adotados para tornar o uso do portal mais
eficiente, tais como a eliminação de páginas ou passos desnecessários em uma seqüência para a
realização de uma tarefa e o uso de valores padronizados, sem a necessidade de digitação por
parte do usuário.
Recomendações:
Não usar páginas sem conteúdo útil, como por exemplo páginas apenas com mensagens
do tipo "Seja bem-vindo ao portal tal".
Na identificação de links, utilizar termos que exprimam o conteúdo das páginas
correspondentes. Não utilizar números ou cores para isso.
Oferecer serviço de busca para pesquisa das páginas do portal, incluindo a possibilidade
de verificação ortográfica dos termos digitados em sua caixa de entrada de dados.
Nos resultados de pesquisa do serviço de busca, apresentar os melhores em primeiro
lugar, sendo desnecessário o uso de porcentagens ou graus de acerto.
Se não forem encontrados documentos com o termo digitado na caixa de entrada de dados
do serviço de busca, oferecer lista com sugestões de palavras mais próximas.
Usar metatags para facilitar a pesquisa dos serviços de busca.
Projetar a caixa de entrada de dados do serviço de busca para caber duas, três ou mais
palavras.
Ressaltar as palavras encontradas nos documentos da lista de resultados do serviço de
busca.
Evitar rolagem horizontal da tela.
Projetar as páginas de acordo com a resolução dos monitores de vídeo disponíveis aos
usuários.
Usar % ao invés de tamanhos fixos, para a adaptação das páginas a qualquer tipo de
monitor de vídeo.
Usar % no tamanho de fonte.
Projetar a página considerando o tempo de download nos computadores disponíveis aos
usuários:
o menos de um segundo entre páginas.
138
o menos de dez segundos para download de arquivos.
Se o download de arquivos for demorar mais do que dez segundos, informar o tamanho
do arquivo ao usuário.
Evitar elementos gráficos, pois comprometem o tempo de download das páginas. Se
forem necessários, utilizar múltiplas ocorrências do mesmo elemento.
Nos links apontados, colocar / no final do URL, se for um diretório.
Na apresentação de textos, começar sempre pelo mais importante, expondo uma idéia por
parágrafo. Informações adicionais devem ser incluídas em outras páginas acessíveis a
partir de links apresentados na página inicial do texto.
Projetar a página de forma que as informações ou elementos importantes estejam visíveis,
sem a necessidade de rolagem vertical ou horizontal da tela.
Para textos extensos, oferecer a opção de impressão ou download de arquivo. A leitura de
textos muito extensos na tela do computador torna-se cansativa para o usuário.
Minimizar a quantidade de cliques necessários para o usuário conseguir o conteúdo final
ou informação útil. É recomendável não ultrapassar quatro cliques.
Heurística 5 - Prevenção de erros
Esta heurística relaciona-se a todos os mecanismos que permitem evitar ou reduzir a ocorrência
de erros, assim como corrigir os erros que porventura ocorram.
As interrupções provocadas por erros de processamento têm conseqüências negativas sobre a
atividade do usuário com o portal, prolongando e perturbando a realização de suas tarefas.
Quanto menor a probabilidade de erros, menos interrupções ocorrem e melhor o desempenho do
usuário.
Para possibilitar a correção de erros, é importante que as mensagens de erro sejam pertinentes,
legíveis, redigidas em linguagem natural (sem códigos), exatas quanto à natureza do erro
cometido, e sugiram possíveis ações para sua correção. Dessa forma, as mensagens de erro
favorecem o aprendizado do sistema, ao indicar ao usuário a razão do erro e suas possíveis
correções. Entretanto, melhor do que boas mensagens de erro é, em primeiro lugar, prevenir a
ocorrência de erros.
Recomendações:
Não usar páginas com a expressão “em construção”. O portal deve apresentar apenas o
que já está pronto para ser acessado pelo usuário.
Não liberar portal parcialmente pronto.
Remover dados/páginas desatualizados, como por exemplo, páginas convidando os
usuários para participarem de eventos que já ocorreram.
Nos serviços de busca, não usar operadores booleanos nas pesquisas simples. É
recomendável oferecer a possibilidade de operadores booleanos apenas em pesquisas
avançadas, para serem usadas pelos usuários mais experientes.
Se não forem encontrados documentos com o termo digitado na caixa de entrada de dados
do serviço de busca, oferecer lista com sugestões de palavras mais próximas.
Oferecer páginas de ajuda para os usuários inexperientes.
139
Não usar URLs muito extensas ou sem significado.
Evitar hífens ou outros caracteres especiais no endereço das páginas. É preferível justapor
duas ou mais palavras, ou abreviá-las.
Usar apenas letras minúsculas no endereço das páginas.
Evitar usar “O” e “0” no endereço das páginas.
Escolher bem os títulos das páginas, de forma que caracterizem bem seu conteúdo. É
aconselhável escolher títulos com duas a seis palavras.
Não repetir o mesmo título em duas páginas diferentes.
Não utilizar mapas de imagem que exijam muita precisão ao clicar.
Fornecer mensagens de erro orientadas a tarefas, com sugestões ou instruções simples e
construtivas para a correção do erro.
Utilizar mensagens de erro sucintas, precisas, com termos específicos e vocabulário
neutro, não repreensivo.
Evitar páginas órfãs, sem qualquer indicação de opções de navegação possíveis.
Evitar frames, pois podem causar erros na impressão do conteúdo da página ou na
marcação da página como um endereço favorito (bookmark).
Heurística 6 - Consistência
Consistência refere-se à homogeneidade e coerência na escolha de opções durante o projeto da
interface do portal (denominação, localização, formato, cor, linguagem). Contextos ou situações
similares devem ter tratamento e/ou apresentação similares.
Um projeto consistente facilita o reconhecimento, o aprendizado, a localização e, por fim, a
utilização de um portal por seus usuários. A padronização de formatos, localizações e sintaxe
torna o portal mais previsível, diminuindo a incidência de erros e as dificuldades de aprendizado
e compreensão.
É conveniente padronizar tanto quanto possível os elementos do portal quanto a seu formato, cor,
localização e denominação, para que o usuário identifique mais facilmente situações e elementos
similares e realize suas tarefas com maior rapidez. A falta de homogeneidade pode comprometer
tanto o desempenho quanto a satisfação do usuário com o portal.
Recomendações:
Usar sempre a mesma terminologia e a mesma localização de elementos comuns nas
páginas de conteúdo, nas páginas de ajuda ao usuário e nas mensagens de erro.
Incluir a caixa de entrada de dados do serviço de busca logo no início de cada página,
preferencialmente no canto superior direito.
O comportamento do cursor deve ser consistente em todos os campos de entrada de
dados, isto é, o cursor deve saltar automaticamente de um campo a outro ou aguardar
Enter ou Tab do usuário.
Verificar se os títulos ou cabeçalhos das páginas correspondem exatamente aos termos
utilizados nos links que apontam para essas páginas.
Evitar instruções HTML não padronizadas.
140
Usar um estilo padrão para o projeto das páginas (leiaute, cores, fontes, formatos de
campos e mensagens).
Selecionar as cores e o leiaute das páginas dentro de um contexto geral e de forma
consistente em todas as páginas.
Evitar sair do padrão web de cores para links : azul para link não visitado e púrpura para
link já visitado.
Destacar palavras ou trechos importantes, com o cuidado de não sublinhar em azul
trechos ou palavras que não sejam links. É recomendável não sublinhar nada que não
possa ser clicado.
Heurística 7 - Compatibilidade com o contexto
Esta heurística refere-se à correlação direta entre o portal e seu contexto de aplicação. As
características do portal devem ser compatíveis com as características dos usuários e das tarefas
que estes pretendem realizar com o portal.
O desempenho dos usuários de qualquer sistema interativo melhora quando os procedimentos
necessários ao cumprimento da tarefa são compatíveis com as características psicológicas,
culturais e técnicas dos usuários; e quando os procedimentos e as tarefas são organizados de
acordo com as expectativas e costumes dos usuários.
O portal deve "falar" a língua do usuário, com palavras, frases e conceitos familiares, ao invés de
termos técnicos relacionados ao portal ou à tecnologia web. As convenções do mundo real devem
ser seguidas, apresentando informações em uma ordem lógica e natural.
Recomendações:
Planejar a estrutura do portal de acordo com o contexto das tarefas realizadas pelos
usuários e não com a estrutura organizacional ou com as novidades tecnológicas. A
estrutura deve ser determinada pelas tarefas que os usuários pretendem realizar por meio
do portal.
Evitar estrutura linear (ordem numérica ou alfabética). As informações devem ser
apresentadas seguindo uma ordem lógica relacionada à tarefa a realizar.
Verificar erros de grafia, tomando como base a gramática do idioma utilizado e o
glossário de termos técnicos de uso corrente na instituição.
Não usar linguagem de marketing. O enfoque do portal corporativo deve ser o conteúdo e
não a propaganda.
Não usar elementos gráficos metafóricos, a não ser que sejam de uso corrente na
instituição.
Não usar novos termos quando os termos padronizados forem bem conhecidos pelos
usuários.
Utilizar palavras da linguagem natural e/ou técnica corporativa que sejam familiares aos
usuários.
Usar formato de data e unidades de medida de acordo com o padrão normalmente
utilizado na instituição ou país.
141
GLOSSÁRIO
ALT Atributo textual associado a imagens em páginas web. Esse atributo apresenta um texto
alternativo enquanto a imagem está sendo carregada pelo navegador ou quando o usuário
opta por ignorar imagens na sua interação com o portal. ALT pode apresentar
informações adicionais sobre a imagem, antes mesmo que esta seja clicada.
bookmark Os navegadores web fornecem a opção de bookmark para que o usuário armazene, em seu
computador, o endereço de páginas consideradas interessantes para futuras visitas.
caixa alta Letras maiúsculas.
enter Tecla para entrada de dados em teclados de computador.
home Abreviatura do termo em inglês homepage, que significa página principal.
metatags Comandos HTML com metadados sobre uma página web (título, palavras-chave,
descrição do conteúdo, autor). O termo metadados significa dados sobre dados.
nível de cabeçalho Na linguagem HTML, cada nível de cabeçalho Hn corresponde a um tipo e tamanho de
fonte diferente. Quanto menor o número n, maior será o destaque dado ao cabeçalho.
plug-ins Programas que são instalados no computador, sem a anuência do usuário, para que
determinada função possa ser processada.
menus pull-down Menus com opções que só aparecem se o usuário clicar no campo e rolar verticalmente
para baixo o menu, para ver todas as opções disponíveis.
tab Tecla para tabulação em teclados de computador.
REFERÊNCIAS
[BASTIEN & SCAPIN] BASTIEN, C. & SCAPIN, D. Critérios ergonômicos para avaliação de interfaces
homem-computador. 1993. [on-line], setembro 2000.
http://www.labiutil.inf.ufsc.br/indice-1.html.
[BEVAN] BEVAN, N. Usability issues in web site design. In: Proceedings of UPA’98, Washington,
June 1998. 1998. [on-line], agosto 2000.
http://www.usability.serco.com/papers/usweb98.pdf .
[CASTRO] CASTRO, E. HTML para World Wide Web: guia rápido visual. São Paulo: Berkeley
Brasil, 1996. 173p.
[DIAS]
142
DIAS, C. Hipertexto : evolução histórica e efeitos sociais. Ciência da Informação, v. 28,
n. 3, p. 267-275, dez. 1999. [on-line], dezembro 1999.
http://www.ibict.br/cionline/280399/2839905.pdf .
[IBM] IBM. Web design guidelines. 1999. [on-line], outubro 2000. http://www-
3.ibm.com/ibm/easy/eou_ext.nsf/publish/572.
[INSTONE] INSTONE, K. Usability heuristics for the web. Oct. 1997. [on-line], junho 1999.
http://webreview.com/wr/pub/97/10/10/usability/sidebar.html .
[ISO Parte10] ISO 9241 Part 10. Ergonomic requirements for office work with visual display terminals,
Part 10: Dialogue principles. 1996.
[ISO Parte11] ISO 9241 Part 11. Ergonomic requirements for office work with visual display terminals,
Part 11: Guidance on usability. 1998.
[LYNCH & HORTON] LYNCH, P. & HORTON, S. Web style guide: basic design principles for creating web
sites. 1999. 164p. [on-line], outubro 2000. http://info.med.yale.edu/caim/manual/.
[NIELSEN 94] NIELSEN, J. Ten usability heuristics. In: NIELSEN, J. & MACK, R. (eds). Usability
inspection methods. New York: John Wiley & Sons, 1994. [on-line], junho 1999.
http://www.useit.com/papers/heuristic/heuristic_list.html .
[NIELSEN 96] ______. Top ten mistakes in web design. May 1996. [on-line], junho 1999.
http://www.useit.com/alertbox/9605.html .
[NIELSEN 97] ______. Changes in web usability since 1994. Dec. 1997. [on-line], junho 1999.
http://www.useit.com/alertbox/9712.html .
[NIELSEN 99a] ______. ”Top ten mistakes” revisited three years later. May 1999. [on-line], junho 1999.
http://www.useit.com/alertbox/990502.html .
[NIELSEN 99b] ______. The top ten new mistakes in web design. May 1999. [on-line], junho 1999.
http://www.useit.com/alertbox/990530.html .
[NIELSEN 99c] ______. Designing web usability. Indianapolis, IN: New Riders, 1999. 420p.
[PARIZOTTO] PARIZOTTO, R. Elaboração de um guia de estilos para serviços de informação em
ciência e tecnologia via web. Florianópolis: UFSC, 1997. Dissertação de mestrado em
Engenharia da Produção.
[REYNOLDS & KOULOPOULOS] REYNOLDS, H. & KOULOPOULOS, T. Enterprise knowledge has a face. Intelligent
Enterprise , v. 2, n. 5, p. 29-34, Mar. 1999.
[SHNEIDERMAN] SHNEIDERMAN, B. Designing the user interface: strategies for effective human-
computer interaction. 3.ed. Reading, Mass.: Addison-Wesley, 1998. 639p.