Usabilidade e Acessibilidade No Design para A Web

Usabilidade e Acessibilidade no design para a Web i
Usabilidade e Acessibilidade
no design para a Web
Ana Ferreira
2008. Faculdade de Belas Artes Universidade do Porto

Dissertao para obteno do grau de Mestre
orientador: Heitor Alvelos

ii Ana Ferreira
Usabilidade e Acessibilidade no design para a Web iii
Abstract
The World Wide Web has a relevant role in the daily life of todays western societies,
becoming gradually omnipresent and, in many cases, almost indispensable. Despite
the standards and the many legislatives efforts that emerged in different contexts, in
last resource, the responsibility of assuring that everyone can use and benefit from
the same opportunities belongs to the designers and developers. This project propo-
ses a reflection about the Usabilitys and Accessibilitys themes and the advantages
resulting of its implementation, proposing the development of a designs process
in which the user is the central object and trying to deduct and systematize a good
practices set that can be employed in the effective conception, implementation and
maintenance of Web projects.
Keywords: Usability, Accessibility, Webdesign, Interaction, User Centered Design,

UX, UI
iv Ana Ferreira
Usabilidade e Acessibilidade no design para a Web v
Resumo
A World Wide Web cumpre um papel muito relevante no quotidiano das sociedades
ocidentais actuais, tornando-se gradualmente omnipresente e, em muitos casos,
quase indispensvel. Apesar dos vrios esforos legislativos que emergiram em dife-
rentes contextos e das normalizaes criadas , em ltima instncia aos designers e
programadores dos stios Web que cabe a responsabilidade de assegurar que todos a
possam utilizar correctamente e beneficiar das mesmas oportunidades. Este projecto
prope uma reflexo sobre os temas da Usabilidade e da Acessibilidade na Web e das
vantagens resultantes da sua implementao, propondo o desenvolvimento de um
processo de design em que o utilizador seja o ponto central e procurando deduzir e
sistematizar um conjunto de boas prticas que possam ser empregues na concepo,
implementao e manuteno eficaz de projectos Web.
Palavras-Chave: Usabilidade, Acessibilidade, Webdesign, Interaco, Design Centra-

do no Utilizador, UX, UI
vi Ana Ferreira
ndice vii
ndice
Introduo 1
1 Conceitos e Contextos 3
1.1 A Usabilidade 3
1.2 A Acessibilidade 5
1.3 A importncia da preocupao
com a Usabilidade e a Acessibilidade 6
1.4 Problemticas do Design para a World Wide Web 8
1.5 Filosofias do Design: Design Centrado no Utilizador 9
1.6 Normas e Legislao para a construo de contedos Web 10
1.6.1 World Wide Web Consortium 10
1.6.2 As normas de HTML, XHTML e CSS 11
1.6.2.1 Validao das normas estabelecidas 11
1.6.3 Porqu respeitar as normas? 12
1.6.4 Construo de stios acessveis 13
1.6.4.1 Web Content Accessibility Guidelines 14
1.6.5 Legislao 15
1.6.5.1 O caso portugus 15
1.6.4.2 Na Unio Europeia 16
1.7 Heurstica do Design de Interfaces 16
1.8 Os principais problemas referenciados 18
1.8.1 Inexistncia de simetria entre os contedos 18
1.8.2 Formulao dos contedos 19
1.8.3 Falta de legibilidade 20
1.8.4 Elementos visuais ou sonoros 20
viii Usabilidade e Acessibilidade no design para a Web
1.8.5 Navegao ineficiente 20

1.8.6 Falta de compatibilidade entre
os diferentes programas de navegao 21
1.8.7 Plug-ins no instalados no computador do utilizador 21
1.8.8 Estruturao dos contedos 21
1.8.8.1 Inviabilizao do boto de Retroceder 22
1.8.8.2 Violao de convenes da Web 22
1.8.9 Pginas de entrada 22
1.8.10 Hiperligaes que no alteram o seu estado 23
1.8.11 Abertura de novas janelas 23
1.8.12 Janelas de pop-up 23
1.8.13 Elementos de design que parecem publicidade 24
1.8.14 Opinio directa de um grupo de utilizadores 24
1.9 Sntese 25
2 Avaliao da Usabilidade e da Acessibilidade 27

2.1 Porqu avaliar plataformas em desenvolvimento? 27
2.2 Testes com utilizadores 28
2.2.1 Porqu realizar testes com utilizadores? 28
2.2.2 Tipos de testes de usabilidade com utilizadores 30
2.2.3 Realizao de testes 31
2.2.3.1 Como? 31
2.2.3.2 O que necessrio? 32
2.2.3.3 Quem pode realizar testes? 33
2.2.3.4 Quantos utilizadores? 33
2.2.3.5 Quem devem ser os utilizadores? 34
2.2.4 Depois da realizao dos testes 35
2.2.5 Testes de acessibilidade com utilizadores 35
2.2.6 Prototipagem em papel 36
2.2.7 Sugestes para a realizao de testes com utilizadores 37
2.3 Testes automticos 38
2.4 Sntese 39
ndice ix
3 Caso de Estudo 41
3.1 Introduo ferramenta escolhida: tv.up.pt 41
3.2 Calendrio do projecto 42
3.3 Fases do Projecto de Design 42
3.3.1 Anteprojecto 42
3.3.1.1 Anlise dos requisitos e funcionalidades exigidas 42
3.3.1.2 Anlise comparativa 43
3.3.2 Projecto 43
3.3.2.1 Escolha da tecnologia a utilizar 44
3.3.2.2 Padres do design ou boas prticas pr-estabelecidas 45
3.3.2.3 Testes informais e prototipagem em papel 46
3.3.2.4 Prottipo funcional 47
3.3.3 Implementao 47
3.3.3.1 Alguns testes simples 48
3.3.3.2 Testes de Usabilidade 50
3.3.4 Ps-implementao 50
3.3.5 Concluso 51
3.4 Realizao de testes 52
3.4.1 Definio dos testes 52
3.4.1.1 Objectivos 52
3.4.1.2 Fase de realizao 52
3.4.1.3 Processo utilizado na realizao 52
3.4.1.4 Caracterizao do utilizador 53
3.4.2 Anlise e concluses 53
3.5 Sntese 55
x Usabilidade e Acessibilidade no design para a Web
4 Boas Prticas 57
4.1 Forma 58
4.2 Estrutura 58
4.3 Universo de validade 60
4.4 Linguagem de Padres 61
4.4.1 Escolha dos termos a utilizar 61
4.4.2 Escalabilidade 63
4.4.3 Traduo/simetria dos contedos 64
4.4.4 Assinalar as opes do utilizador 66
4.4.5 reas clicveis 67
4.4.6 Escolhas tecnolgicas 69
4.4.7 Saltar para o contedo 70
4.4.8 Manter o utilizador informado 71
4.4.9 Mltiplas formas de disponibilizar a mesma informao 72
4.4.10 Codificao cromtica 73
4.4.11 Ttulos HTML descritivos 74
4.4.12 Input previsto 75
4.4.13 Visibilidade inicial 76
4.4.14 Minimizar os erros 77
4.4.15 S teclado 78
4.4.16 Escrever para a Web 80
4.4.17 Diviso dos contedos 82
4.4.18 Legibilidade 83
4.4.19 Tag Clouds 85
4.4.20 Seleco de lngua 87
4.4.21 Estruturao dos contedos 88
4.4.22 Drag-and-Drop 89
4.4.23 Definies cromticas 90
ndice xi
4.4.24 Mensagens de erro 92

4.4.25 Layout flexvel 93
4.4.26 Insero de Contedos Audiovisuais 95
4.4.27 Simplificar Formulrios 96
Concluso 99
Referncias Bibliogrficas 103
Glossrio 111
xii Usabilidade e Acessibilidade no design para a Web
Introduo 1
Introduo
A tecnologia e a Internet adquirem uma importncia cada vez maior na sociedade,

estando presentes em quase todos os aspectos e momentos da vida quotidiana. Ac-
tualmente 21,9% da populao mundial dispe de uma ligao Internet (internet
world stats, 2008), em Portugal a percentagem ascende aos 72.9% (internet
world stats, 2008) (valores em constante crescimento), e existem cada vez mais
dispositivos que nos permitem utiliz-la, nas mais variadas situaescomputado-
res, telefones mveis, GPS, automveis, etc. No entanto a maioria dos servios no
concebida tendo em conta o conceito de universalidade de utilizao e acesso, no
podendo ser correctamente utilizado por todos.
Apesar da usabilidade e da acessibilidade para a Web serem temas que tm vin-
do a ganhar importncia na comunidade, muitos stios levantam um grande nmero
de questes a estes nveis. Todos os utilizadores j se depararam com obstculos ao
interagir com um stio, desconhecendo a forma como ele podia ser operado, no
percebendo qual o seu objectivo ou no conseguindo extrair dele a informao que
procuravam. Estes obstculos tornam-se ainda maiores para pessoas que sofram de
limitaes funcionais ou situacionais, e que no tenham ao seu dispor todas as facili-
dades de um utilizador dito normal ou maioritrio. Mas este utilizador normal
na verdade o utilizador ideal, que apenas existe para o designerque sabe a resposta
a todas as perguntas, que acede aos stios nas condies ideais, com velocidades de na-
vegao acima da mdia, com computadores topo de gama e com todas as tecnologias
e informaes necessrias para desempenhar as funes com o maior sucesso. O uti-
lizador real o oposto do utilizador ideal, e apenas sabe o que lhe dito, transmitido
ou ensinado, ou seja aquilo que intui, uma palavra enganadora1 (tidwell) porque,
como aponta Jeff Raskin, no contexto do design de interfaces significa aquilo que
1 [] the word intuitive is a little bit deceptive. (tidwell, 2005)

2 Usabilidade e Acessibilidade no design para a Web
familiar ou aprendido anteriormente pelo utilizador2. Com todas as suas limita-

es e problemas, ser este o utilizador real da Web; e ele tem o direito e a necessidade
de o conseguir fazer com todo o sucesso. Como refere Andy Clarke os profissionais de
design devem desenhar os contedos de forma a que eles sejam acessveis globalmente
e que correspondam s necessidades do maior nmero possvel de pessoas, indepen-
dentemente das suas habilitaes ou do tipo de dispositivos que utilizem para aceder
Web3 (2007).
Muitas vezes o design para a Web ainda pensado como sendo semelhante que-
le que praticado para meios impressos. Essa equiparao leva criao de stios que
no so funcionais e que no permitem uma utilizao universal, valorizando acima
de tudo a beleza esttica, mas a beleza esttica apenas poder ajudar at certo ponto o
sucesso de um stio e nunca ser suficiente para compensar a inexistncia de conte-
dos4 (vella, 2008).
Uma reflexo sobre a usabilidade e a acessibilidade no design Web torna-se essen-
cial num contexto em que o designer desconhece a totalidade dos dispositivosactuais
e futurose as preferncias e necessidades do utilizador. Este projecto pretende, em
primeiro lugar, realizar um estudo terico sobre o que j foi dito e pensado sobre os
temas referidos, aplicando, numa fase posterior, o conhecimento adquirido ao estudo
de um caso especfico. O portal tv.up.pt foi o projecto escolhido, um stio que pretende
disponibilizar comunidade da Universidade do Porto um conjunto variado de ser-
vios como a publicao de vdeos, ou a criao de canais e blogues, numa tentativa
de estimular a produo de contedos audiovisuais. Numa fase seguinte, ir inferir e
enumerar um conjunto de boas prticas que podem ser tidas em conta aquando de um
trabalho de design para a Web, possibilitando que o designer possa reutilizar experi-
ncias e dessa forma simplificar o seu trabalho.
2 When users say an interface is intuitive, they mean that it operates just like some other software or me-
thod which they are familiar. Sometimes, the word is used to mean habitual, as the editing tools become
increasingly intuitive over time. Or it can mean already learned, as was said of a new aircraft navigation
device: Like anything, it can be learned, but it would take a lot of experience to do it intuitively. (raskin,
2000)
3 As design professionals, we should be designing our content so it is globally accessible and meets the
needs of as many people as possible and practical given our specific circumstances, regardless of their abi-
lities or the type of device they choose to access the Web. (clarke, 2007)
4 Aesthetic design can only go so far in making a site successful. Beautiful cant make up for empty.
(vella, 2008)
1 Conceitos e Contextos
1.1 A Usabilidade
Usability really just means that making sure that something works well: that a
person of average (or even below average) ability and experience can use
the thingwhether its a Web site, a fighter jet, or a revolving doorfor its
intended purpose without getting hopelessly frustrated.
Steve Krug, Dont Make Me Think! A Common Sense Approach to Web Usability, 2000
A usabilidade estuda a relao entre as ferramentas e os seus utilizadores. Para que

uma ferramenta seja eficaz, ela deve permitir que os utilizadores realizem as tarefas
desejadas e necessrias da melhor forma possvel. O estudo da usabilidade procura
a utilizao fcil e o mapeamento claro das funcionalidades e dos contedos de um
sistema interactivo.
Jakob Nielsen (2003b) refere cinco componentes principais da usabilidade: (1) a
Capacidade de aprendizagem, (2) a Eficincia, (3) a Capacidade para ser memorizado,
(4) a Segurana e (5) a Satisfao.
A Capacidade de aprendizagem a facilidade com que um iniciante pode ope-
rar o sistema, ou poder vir a tornar-se num utilizador experiente. importante que
qualquer utilizador possa compreender rapidamente como interagir com o sistema e
de que formas pode melhorar essa interaco.
A Eficincia relaciona-se com a rapidez e o grau de sucesso com que os utilizado-

res conseguem alcanar os seus objectivos. Paul Safto diz-nos que o ser humano usa
as ferramentas para realizar tarefas5, ideia que Jenifer Tidwell completa dizendo que
para o utilizador as ferramentas so apenas um meio para atingir um fim6. Torna-se,
por isso, essencial que os sistemas permitam a execuo eficaz das tarefas para evitar
que o utilizador se sinta frustrado.
A Capacidade para ser memorizado diz respeito facilidade com que um utili-
zador se recorda de como pode interagir com um sistema, ou parte dele, aps algum
tempo, porque um utilizador pode precisar de voltar a utilizar uma ferramenta passa-
do bastante tempo e importante que o consiga fazer com base no que se recorda, sem
ser obrigado a reaprender tudo.
A Segurana remete para raridade com que so experienciados erros e para a
facilidade com que estes podem ser resolvidos. A segurana com que um utilizador
usa um sistema ir influenciar o grau de confiana da interaco, porque importante
que as pessoas sintam que podem experimentar livremente o sistema sem o danificar,
ou colocar em risco a informao7.
A Satisfao dos utilizadores com a experincia ser de extrema importncia,
porque a qualidade da experincia dos utilizadores na interaco com um sistema
ser determinante para que pretendam reutiliza-lo e, consequentemente, ser a satis-
fao do utilizador que determinar o sucesso ou fracasso da aplicao. Devido sua
importncia no futuro do stio ela deve estar no centro das decises de design8.
Cada um destes pontos assume um papel essencial na procura de uma interface
usvel, mas o design no os beneficia a todos simultaneamente. Melhorar alguns pode
significar que outros sairo enfraquecidos, por isso a correcta articulao destes cinco
pontos ser essencial para uma interface funcional.
5 We use tools to accomplish tasks. (citado em van duyne [et al.], 2007)
6 Merely a means to an end for the people who use it. (tidwell, 2005)
7 People need to feel that they can try things without damaging the system or jeopardizing their data.
(apple, 2008)
8 Because user satisfaction ultimately determines the success or failure of your application, it should be at
the heart of your design decisions.(apple, 2008)
1.2 A Acessibilidade
In a broad sense, accessibility simply means ensuring that a given page

on the Web is able to be accessed.
Molly E. Holzchlag, prefcio de Web Accessibility: Web Standards and Regulatory Compliance, 2006
A acessibilidade uma subclasse da usabilidade. Enquanto a usabilidade se preocupa

com o universo de todos os potenciais utilizadores de um sistema, a acessibilidade
procura que todas e quaisquer pessoas, independentemente de eventuais limitaes
sensoriais ou motoras, o possam utilizar. Relaciona-se com a traduo da informao
porque implica, grande parte das vezes, que a informao que existe num meio seja
traduzida ou transformada para ser comunicada noutro meioimagens e vdeos para
texto, sons para texto, texto para voz, texto grfico para braille, mas tem implica-
es noutros domnios que em muito ultrapassam a simples traduo.
A principal preocupao em desenhar produtos acessveis assegurar a sua uni-
versalidade, tornando o produto mais flexvel e completo. A acessibilidade pretende,
por isso, tornar as interfaces perceptveis e compreensveis por pessoas em vrias cir-
cunstncias, ambientes e condies9. Uma preocupao a este nvel ir beneficiar no
s pessoas com limitaes funcionais mas tambm pessoas com limitaes situacio-
nais10, que se relacionam com as circunstncias, o ambiente ou o dispositivo utilizado
para operar o sistema, por exemplo, a utilizao de dispositivos mveis como uma
PSP (PlayStation Portable) ou um telefone, que no permitem o uso de rato.
A acessibilidade pode ser comparada ao conceito matemtico de simetria, se-
gundo o qual algo mantm as suas caractersticas principais depois de submetido a
um conjunto de transformaes, visto que essas transformaes no alteram o objec-
to ou a sua aparncia. A acessibilidade promove o acesso aos contedos para qualquer
pessoa independentemente de eventuais limitaes, por isso o contedo dever ser
simtrico (igual ou pelo menos equivalente) para qualquer utilizador. A acessibilida-
de apresenta-se como um eixo de simetria para as vrias formas do mesmo contedo.
Como refere Jeffrey Zeldman, a acessibilidade trata o contedo e a informao, ela pre-
tende tornar os contedostexto, imagem, multimdiadisponveis ao utilizador11.
9 Accessibility makes user interfaces perceivable, operable, and understandable by people with a wide
range of abilities, and people in a wide range of circumstances, environments, and conditions. (henry,
2007)
10 [] features and functionality for people with disabilities benefit people without disabilities because of
situational limitations. (henry, 2007)
11 Accessibility is about content and information. It is about making all content (text, images, and multi-
media) available to the user. (zeldman, 2007)
1.3 A importncia da preocupao com a Usabilidade e

com a Acessibilidade
Somehow, when a device as simple as a door has to come with an instruction

manualeven a one-word manualthen it is a failure, poorly designed.
Donald A. Norman, The Design of Everyday Things, 1998
A usabilidade e a acessibilidade so importantes quer do ponto de vista do utiliza-

doravaliando a eficcia e a facilidade do sistema, quer do ponto de vista do
criadoravaliando o sucesso ou fracasso do produto criado. Uma falha a estes nveis
prejudica todos e produz efeitos negativos na utilizao e, consequentemente, nos
custos e ganhos do sistema. A usabilidade determinante para o xito de um produ-
to porque, podendo escolher, o utilizador escolher aquele que mais lhe facilitar o
desempenho das tarefas e que melhor comunique consigo. Se um stio no for fcil
de ser utilizado ele ser abandonado pelo utilizador, que procurar outro (nielsen,
2006) e na Web existe quase sempre uma outra escolha.
A acessibilidade no deve ser esquecida porque, alm das vantagens econmi-
cas previamente referidas, ela possibilitar que todos possam aceder aos mesmos
contedos, independentemente de eventuais limitaes funcionais ou situacionais.
E numa poca em que a Web tem um papel cada vez maior na vida das pessoas, esta
universalidade torna-se essencial para que todos possam beneficiar das mesmas
oportunidades.
preciso considerar que actualmente uma grande percentagem da populao
sofre de algum tipo de limitao funcional que pode afectar a sua habilidade para usar
produtos tecnolgicos12 (henry, 2002). Ao mesmo tempo a mdia etria e a esperana
mdia de vida esto a aumentar13 (norman, 1998) e com o avanar da idade as capaci-
dades do ser humano vo diminuindo defrontando-se com problemas como a leitura
no ecr quando a viso se deteriora ou a utilizao de um rato quando a destreza dimi-
nui (comisso europeia, 2008). Alm disso, como foi referido, a preocupao com
a acessibilidade ir melhorar tambm a usabilidade, tornando o sistema mais flexvel
s necessidades do ser humano, facilitando a apreenso dos contedos de uma forma
no visual e, por isso, favorecendo qualquer utilizador que use um dispositivo no
12 [] between 15% and 30% of the general population have functional limitations that can affect their
ability to use technology products. (henry, 2002)
13 [] in a world where the average age is increasing, sixty is still relatively young: most sixty year-olds
have another twenty years to live, many have forty. (norman, 1998)
visual para aceder aos stios. Tambm ir facilitar o acesso por pessoas com limitaes
temporriascomo um simples brao partidoou que utilize uma ligao lenta In-
ternetfornecendo, por exemplo, descries das imagens enquanto estas no tiverem
acabado de descarregar. A facilitao dos processos constituir tambm uma facilita-
o da interaco para pessoas com baixa literacia, no fluentes na lngua utilizada,
ou que sejam inexperientes no uso de tecnologias Web. Por ltimo, uma preocupao
a este nvel ir ajudar a que o stio seja correctamente indexado pelos motores de pes-
quisa, talvez os maiores utilizadores no visuais de qualquer stioos motores de
busca processam cada pgina individualmente para compilar um ndice de todas as
palavras encontradas, incluindo a informao das tags e atributos (como o elemento
title e o atributo alt)14, e posteriormente arquivam as pginas com base na infor-
mao que adquiriram previamente.
Podemos concluir dizendo que a acessibilidade no deve ser relegada para se-
gundo plano porque moralmente esta a aco mais correctapermitir um acesso
aos contedos igual para todos, j que o acesso aos benefcios da Sociedade da Infor-
mao deve ser assegurado sem discriminao ou excluso15.
Romper com o passado

Clarke refere que apesar da arquitectura de informao, da usabilidade e da acessi-
bilidade se terem tornado reas de preocupao para os designers e criadores, eles
erradamente limitaram as suas conversas, referindo a acessibilidade como se esta
apenas servisse as necessidades das pessoas com limitaes16. Actualmente preciso
romper com esta conveno.
tambm necessrio compreender que alguns mitos do design para a Web no
so verdadeiros, como referem por exemplo Shawn Lawton Henry, Liam Quinn, Kynn
Bartlett (1999). Melhorar o grau de usabilidade e acessibilidade de um stio (1) no im-
plica necessariamente a existncia de duas ou mais verses do mesmo stio, o que alis
desaconselhado porque dificilmente as diferentes verses sero actualizadas com a
14 Googlebot processes each of the pages [] in order to compile a massive index of all the words it sees
and their location on each page. In addition, [] process information included in key content tags and
attributes, such as Title tags and ALT attributes. (google)
15 Access to the benefits of the Information Society should [] be assured without discrimination or ex-
clusions. (the council of ministers, 1999)
16 [] good information architecture, usability, and accessibility have rightly become areas of concern for
professional designers and developers. [] However many designers, developers, and other specialists in
the accessibility realm have wrongly limited conversations about accessibility to merely serving the needs
of people with disabilities. (clarke, 2007)
mesma frequncia; (2) no obriga criao de um design desinteressante ou mera-

mente textualse no passado as tecnologias de assistncia no eram capazes de lidar
com layouts complexos, hoje em dia j o conseguem fazer desde que o stio cumpra as
normas estabelecidas; (3) no torna o produto mais caro, pelo contrrio torna-o mais
barato porque no obriga a um redesign para tornar o stio mais fcil e porque fideli-
za clientes, que ficam satisfeitos com a eficincia e facilidade com que o conseguem
utilizar; (4) os stios no tm que ser iguais em todos os navegadores, devem sim fun-
cionar em todos e possibilitar o acesso aos mesmos contedos, por isso podem existir
algumas diferenas, se necessrio, na adaptao dos contedos aos vrios navegado-
res para que possam ser acedidos com a mxima eficcia.
1.4 Problemticas do Design para a World Wide Web
The dream behind the Web is of a common information space in which we

communicate by sharing information.
Tim Berners-Lee, The World Wide Web: A very short personal story, 1998
O desejo de Berners-Lee, ao criar a World Wide Web, era criar uma ferramenta para
comunicar, para ajudar as pessoas a compreendem-se umas s outras17. No entanto
a sua ferramenta, apesar tornar os contedos acessveis em qualquer parte do mun-
do, tornou-os tambm eminentemente visuais e difceis de serem compreendidos de
outra forma. Apesar destes serem essencialmente informao textual, grande parte
dessa informao apenas pode ser lida e apreendida pelos utilizadores de uma forma
visual. Este foco na forma visual, sob a qual os contedos so apresentados torna-se
um obstculo prpria noo de universalidade proposta pela WWW.
O design para a Web comeou por ser desenvolvido por designers educados na
tradio impressa e sem formao especfica para este meio. Na maior parte das vezes,
estes aplicavam o que tinham aprendido para outro meio Web, um meio to dife-
rente e com caractersticas to especficas. A Web no tem, nem pode ter, um meio
fsico inaltervel ou um pblico com caractersticas pr-definidas. Pelo contrrio ela
caracterizada por um acesso livre e globalizado, e pela fcil criao e publicao de
contedos. ento necessrio compreender que o processo de criao de contedos
deve ser pensado de forma a permitir o seu acesso real por todos os interessados, o
que requer a aceitao de que quer os contedos, quer a interaco, so completa-
17 [] a tool for communicating [] to help people understand each other (berners-lee)

mente diferentes para material impresso ou para material na Web; Se o primeiro tem
uma forma nica de apresentao, o segundo v (potencialmente) essa forma altera-
da de utilizador para utilizador, e cada utilizador ser nico nas suas necessidades e
preferncias.
1.5 Filosofias do Design: Design Centrado no Utilizador
User-Centered Design (UCD) is a user interface design process that focuses on

usability goals, user characteristics, environment, tasks, and workflow in the
design of an interface.
Shawn Lawton Henry, Just Ask: Integrating Accessibility Throughout Design, 2007
Existem vrias filosofias do design, cada uma delas defendendo um elemento diferente
como tendo o papel central do processo de design: Design Centrado no Utilizador
o utilizador assume o papel principal e a interface desenhada tendo em conta as
suas necessidades, Design Centrado no Designer, tambm conhecido como Design
Centrado no Egoem que o designer se tem a si mesmo como centro do processo,
acreditando que sabe o que melhor para o stio, Design Centrado na Empresaa
organizao da empresa ser transposta para o design, e o stio ser organizado segun-
do uma estrutura que pode no fazer sentido para os utilizadores, Design Centrado
no Contedoem que um corpo de informao j existente, e no adaptado Web,
ir assumir o papel organizacional do stio, Design Centrado na Tecnologiaa tec-
nologia torna-se o foco do projecto, grande parte das vezes atravs do uso excessivo de
animao, udio e vdeo.
Das vrias filosofias de design, a mais relevante nesta dissertaoporque se re-
laciona directamente com o tema de estudoser aquela em que o utilizador assume
o papel central. Esta aproximao deve-se ao facto desta filosofia descrever um proces-
so focado no design de ferramentas ou de informao, que servem o utilizador e que
procuram maximizar a utilizao eficiente18. Um processo de design que se preocupa
em primeiro lugar com o utilizador ser aquele que melhor poder criar um objecto
final que responda s necessidades e exigncias do utilizador. Esta filosofia est em
tudo relacionada com a experincia que o utilizador tem do produto e com o grau de
satisfao e eficincia com que o usa para alcanar os seus objectivos.
18 A process focused on the design of information/tools that cater to the end user for the purposes of the
most effective and efficient way of maximizing usage. (battiana, 2008)
O objectivo do Design Centrado no Utilizador dar a conhecer os utilizadores e

as suas necessidades, permitindo s empresas adequar as ofertas e identificar novas
formas de ajudar o utilizador19. Esta filosofia exige que o designer consiga aproximar
ao mximo o utilizador da aplicao, por isso ela deve seguir o processo mental do
utilizador e no, como acontece noutras abordagens, do cliente, do designer ou do
programador. Um sistema realizado a pensar no utilizador e na sua forma de interagir
servir melhor as suas necessidades, aumentando a compreenso, eficincia e eficcia
e diminuindo a possibilidade de frustrao.
necessrio, como refere Jenifer Tidwell, conhecer os utilizadores porque eles
so diferentes de ns [designer, empresa, patro, etc]20. Mas preciso salientar que
esta filosofia no pretende criar a interface como um reflexo do modelo mental do uti-
lizador, antes compreender como que a interface poder funcionar melhor nas mos
do utilizador; o objectivo no desenhar o que o utilizador aparenta querer, mas sim
desenhar algo que o utilizador consiga utilizar com a maior eficcia.
1.6 Normas e Legislao para a construo de contedos

Web
Without these standards, there can be no true usability and no coherent

approach to design.
Jeffrey Zeldman, Designing with Web Standards, 2007
1.6.1 World Wide Web Consortium
Numa tentativa de criar especificaes e normas para promover a evoluo da Web

e assegurar que as suas tecnologias funcionavam bem em articulao umas com as
outras, foi fundado, em 1994, o World Wide Web ConsortiumW3C.
Durante algum tempo as especificaes criadas por este grupo receberam o
nome de recomendaes e por isso no foram rigorosamente seguidas. Em 1998 fo-
ram renomeadas pelo The Web Standards Project para Web StandardsNormas para a
19 The goal of UCD [User-Centered Design] is to establish a thorough understanding of users and their
needs, allowing companies to fine tune current offerings and identify emerging opportunities to truly su-
pport users lives. (kalbach, 2007)
20 [] know thy users, for they are not you [designer, company, boss, etc]. (tidwell, 2005)
Webe devido aos esforos deste projecto, os criadores de navegadores comearam

progressivamente a suportar as especificaes, facilitando o trabalho dos designers e
possibilitando uma maior compatibilidade entre navegadores.
1.6.2 As normas de HTML, XHTML e CSS
A W3C especifica a utilizao das normas de HiperText Markup Language 4.1HTML

4.1ou eXtensible HiperText Markup Languague 1.0XHTML 1.0 enquanto linguagem
de marcao para a construo de stios Web, porque quando usadas correctamen-
te elas funcionam perfeitamente na generalidade dos navegadores, leitores de ecr,
navegadores de texto, dispositivos sem fios, etc. Aconselha, tambm, a utilizao de
Cascading Style Sheets 2.1CSS 2.1enquanto linguagem de formatao visual de con-
tedos, porque esta permite uma maior flexibilidade dos contedos em relao aos
meios utilizados. Como Thatcher aponta, as folhas de estilo facilitam a acessibilidade
porque so transparentes para esta21, uma vez que permitem uma separao completa
entre estrutura e apresentao.
A especificao pelas verses HTML 4.1 e XHTML 1.0 deve-se ao facto de nas ver-
ses anteriores haver uma certa confuso entre a marcao estrutural dos contedos e a
sua formatao visual. Estas verses, pelo contrrio, primam pela separao de ambas,
atravs da utilizao distinta de duas linguagensHTML 4.1 ou XHTML 1.0 e CSS.
1.6.2.1 Validao das normas estabelecidas

As linguagens devem ser usadas correctamente e segundo as regras disponibilizadas
para a sua construo. Para isso, a W3C fornece um conjunto de servios de validao
que permite verificar a (in)existncia de erros nos documentos. Estes servios so gra-
tuitos e so normalmente realizados via Web, apesar de alguns poderem ser instalados
localmente, como o caso do validador de markup.
A validao das linguagens utilizadas no deve ser esquecida ou tida como algo
irrelevante porque, apesar de uma pgina com erros poder (aparentemente) funcio-
nar correctamente no navegador utilizado, ela poder no ser compatvel com outros
navegadores ou com verses futurasdos navegadores, poder no ser acessvel atra-
vs de navegadores no visuais e poder ser um grave obstculo utilizao do stio.
21 CSS is regarded as supporting accessibility, but another way of looking at it is that CSS is transparent to
accessibility. (thatcher [et al.], 2006)
Isto acontece porque normalmente os navegadores so tolerantes em relao a erros,

mas apesar de visualmente o resultado parecer correcto, um erro no cdigo poder
levantar problemas na traduo dos contedos para uma forma no visual.
1.6.3 Porqu respeitar as normas?
O respeito e o uso pelas normas propostas pelo W3C ir reflectir-se favoravelmente no

processo de Design das seguintes formas:
1) Compatibilidade: no s com os vrios navegadores que existem mas tambm

com os que existiro no futuro e com os vrios dispositivos de acesso Inter-
net. Esta compatibilidade poder nunca atingir o nvel ideal, porque os prprios
navegadores e dispositivos podem no cumprir integralmente as normas. No
entanto, o respeito pelos utilizadores e pelas tecnologias de acesso deve enco-
rajar os criadores a formatar os seus contedos ao mximo segundo as normas,
para assim possibilitarem que todos possam aceder aos contedos independen-
temente do navegador ou do sistema operativo.
2) Controlo: para os designers, porque o layout das pginas ser (mais) correcta-
mente interpretado pelos navegadores, funcionando igualmente em todos; e
para os utilizadores, que podem facilmente alterar alguns aspectos do layout
segundo as suas necessidadescomo o corpo do texto ou cores, utilizando as
funcionalidades disponibilizadas para isso.
3) Rapidez: fornece uma separao clara entre estruturamarcao semntica
dos contedose aparnciaformatao do layout, o que permitir desen-
volver stios mais leves e consequentemente mais rpidos.
4) Flexibilidade: reduz a necessidade de criar verses diferentes para os diferentes
tipos de dispositivos, porque permite criar folhas de estilo distintas e adaptadas
aos vrios meios de acesso e visualizao.
5) Autonomia: permite que os contedos possam ser lidos, indexados e sumariza-
dos por qualquer mquina, contribuindo para que eles se tornem universais.
6) Custos: torna a realizao de stios mais barata quer na produo, porque sim-
plifica o trabalho, quer na manuteno, porque possibilita um redesign mais
rpido, reduzindo o trabalho exigido.
1.6.4 Construo de stios acessveis
A procura de criar uma Web coerente e acessvel a todos leva a W3C a criar, nos
anos 90, a Web Accessiblity InitiativeWAI22, cuja principal funo era aconse-
lhar os criadores de contedos para a Web nas estratgias mais eficazes para tornar
os stios acessveis. Para isso o grupo publicou, em 5 de Maio de 1999, as Web Content
Accessibility Guidelines 1.0WCAG 1.0um conjunto de 14 recomendaes para o de-
sign acessvel. Estas normas esto actualmente a ser revistas para a verso 2.0, que
ser aplicvel a tecnologias mais avanadas e que pretende ser mais fcil de compre-
ender e testar. Estas recomendaes apenas explicam uma srie de problemas comuns
e sugerem solues para a sua resoluo, sendo cada soluo apresentada como uma
das solues possveis, no pretendendo ser nica. As recomendaes so apenas uma
orientao possvel23.
Nos ltimos anos a acessibilidade comeou a tornar-se uma preocupao geral
e algumas naes adoptaram as WCAG 1.0 como norma legal para implementar stios
acessveis. Outros pases preferiram criar regras especficas, como os Estados Unidos
da Amrica com a Section 508 (ver mais em thatcher [et al.], 2006, w3c). A preocu-
pao crescente com estes problemas levou a Comisso Europeia a lanar no dia 2 de
Julho de 2008 um novo apelo, pedindo um maior empenho em tornar a Web acessvel
a todos e salientando a importncia para que tal acontea j que 15% dos europeus
sofrem de algum tipo de deficincia (comisso europeia, 2008). A Comisso eu-
ropeia salienta ainda que o acesso aos stios Web da Internet essencial para muitos
cidados na Europa, que, no entanto, em muitos casos, no podem beneficiar dele
por serem deficientes. Enquanto a acessibilidade da Internet para todos no for uma
realidade, muitas pessoas ficaro excludas dos seus benefcios. [] No entanto, em
2007, s 5% dos stios Web pblicos e menos de 3% dos stios privados na Unio Euro-
peia foram considerados plenamente acessveis de acordo com aquelas orientaes
[WCAG 1.0] (comisso europeia, 2008). A Unio Europeia rege actualmente os
seus contedos pelas WCAG 1.0.
22 http://www.w3.org/WAI
23 Guidelines, such as WCAG, are literally guidance. (thatcher [et al.], 2006)
1.6.4.1 Web Content Accessibility Guidelines

As WCAG 1.024 estabelecem 14 normas ou princpios para design acessvel. Cada nor-
ma inclu um conjunto de pontos especficos que explicam como que ela se aplica
criao de contedos para a Web. Estes pontos esto organizados segundo prioridades
que devem ser tidas em conta por qualquer criador de contedos para a Web:
Prioridade 1: um criador de contedos para a Web dever satisfazer esta priori-

dade. Se no o fizer um ou mais grupos de utilizadores ficar impossibilitado de
aceder s informaes contidas no documento. Satisfazer esta prioridade um
requisito bsico para que alguns grupos sejam capazes de utilizar documentos
Web;
Prioridade 2: um criador de contedos para a Web deveria satisfazer esta prio-
ridade. Se no o fizer um ou mais grupos de utilizadores tero dificuldades em
aceder s informaes contidas no documento. Satisfazer esta prioridade ir re-
mover barreiras significativas no acesso aos documentos;
Prioridade 3: um criador de contedos para a Web poder satisfazer esta priori-
dade. Se no o fizer um ou mais grupos de utilizadores podero ter dificuldades
em aceder s informaes contidas no documento. Satisfazer esta prioridade ir
melhorar o acesso aos documentos.
Num nvel mais bsico de acessibilidade deve ser satisfeita a prioridade 1, num
nvel ideal as trs prioridades devem ser satisfeitas, garantindo a acessibilidade para
qualquer pessoa que utilize a Web. Ao todo existem 65 pontos, 16 so essenciais para
cumprir a prioridade 1, 30 para cumprir a prioridade 2 e 19 para cumprir a prioridade
3. Assim tornar um stio acessvel a alguns grupos de utilizadores que de outra forma
estariam excludos apenas exige o cumprimento de 16 pontos.
Os 16 pontos que cumprem o nvel mais bsico de acessibilidade dizem respeito
utilizao de: Contedo sonoro e visual, Cores, Lngua, Tabelas, Novas tecnologias,
Controlo por parte utilizador, Interfaces integradas, Independncia de dispositivos,
Tecnologias do W3C, Frames, Clareza e simplicidade,
Uma das maiores diferenas entre estas normas e as que tomaro o seu lugar
que as WCAG 2.025 no so organizadas segundo prioridades mas sim segundo nveis
de sucesso.
24 http://www.w3.org/TR/WCAG10
25 http://www.w3.org/TR/WCAG20
Critrios de sucesso do nvel 1

1. Atingir um nvel mnimo de acessibilidade
2. Pode ser aplicado a todos os recursos Web
1. Atingir um nvel melhorado de acessibilidade
2. Pode ser aplicado a todos os recursos Web
1. Atingir melhoramentos de acessibilidade adicionais
2. No pode, necessariamente, ser aplicado a todos os recursos Web
Ao contrrio das WCAG 1.0 estas normas procuram dirigir-se a mais do que
problemas que envolvem as linguagens de markup, como o HTML ou o XHTML; elas
procuram ser independentes das tecnologias, j que estas evoluem rapidamente. As
WCAG 2.0 so mais gerais e incorporam problemas relacionados com a usabilidade em
geral, mas muitas das WCAG 2.0 contm medidas subjectivas em vez de objectivas26
(thatcher [et al.]), o que pode criar problemas aquando da criao de contedos
acessveis.
No entanto preciso considerar que apenas cumprir as normas de acessibilidade
propostas pela WCAG no nos garante que um stio seja usvel. E se um stio no for
usvel ele no ser realmente acessvel, apesar de poder cumprir todas as normas.
1.6.5 Legislao
1.6.5.1 O caso portugus

Portugal foi pioneiro numa legislao nacional para uma Web acessvel. A 17 de Fe-
vereiro de 1999 um Conselho Internacional de Acessibilidade, formado a pedido da
Iniciativa Nacional para os Cidados com Necessidades Especiais, submeteu ao Go-
verno Portugus um conjunto de normas para tornar a Web acessvel. Essa petio,
que pretendia garantir a igualdade de acesso informao que hoje disponibilizada
atravs da Internet a todas as pessoas com necessidades especiais, com particular n-
fase nas pessoas com deficincia e nos idosos (assembleia da repblica, 1999),
recebeu o aval da Assembleia da Repblica que considerou que a plena acessibilidade
da informao produzida e disponibilizada pelo Governo e demais servios pblicos
na Internet uma condio indispensvel promoo da universalidade e igualdade
no exerccio dos direitos fundamentais dos cidados, designadamente os relativos
26 [] much of WCAG 2.0 contains subjective, rather objective, measurements. (thatcher [et al.],
2006)
sua participao na vida pblica (assembleia da repblica, 1999). Assim a pe-

tio resultou na Resoluo do Conselho de Ministros 97/99, uma lei nacional que
requer stios Web acessveis.
Em Outubro de 2007 e dado que a Resoluo do Conselho de Ministros n. 97/99,
de 26 de Agosto, no logrou satisfazer integralmente o seu escopo (assembleia da
repblica, 2008) a lei foi revista com a publicao da Resoluo do Conselho de
Ministros n.155/2007 que procurou definir os requisitos mnimos nas solues tc-
nicas adoptadas, estabelecendo nveis diferentes de conformidade com as normas do
WAIos stios de carcter informativo devem apresentar conformidade de nvel A,
ou seja, satisfazer as prioridades de nvel 1, e os stios que incluem a prestao de ser-
vios transaccionais devem apresentar conformidade de nvel AA, isto , satisfazer as
prioridades de nvel 1 e 2.
1.6.4.2 Na Unio Europeia

No dia 13 de Junho de 2002 o Parlamento Europeu tomou a resoluoCouncil Reso-
lution of 25 March 2002 (2002/C 86/02)de adoptar as WCAG 1.0 (Prioridades 1 e 2), e
verses futuras das mesmas, como normas que devem ser implementadas na constru-
o de stios pblicos. Tambm obrigava as instituies da Unio Europeia e dos seus
estados membros a cumprirem as normas at ao ano de 2003.
Nota: Apesar dos inmeros esforos das naes na criao de legislao para uma
Web acessvel, a maior parte dos stios no o . Em ltima instncia, ainda depende
dos designers e programadores a realizao de stios acessveis e universais, porque o
cumprimento da legislao no visto como obrigatrio.
1.7 Heurstica do Design de Interfaces
Alm de normas para a construo de stios existem alguns princpios que devem ser
usados pelos criadores, de forma a melhorar a prpria interface. Jakob Nielsen (2005)
refere-nos dez princpios gerais para o design de Interfaces:
1) Visibilidade do estado do sistema: O sistema deve manter sempre os utiliza-

dores informados sobre o que se est a passar, reagindo em tempo razovel, por
exemplo num processo longo e demorado o utilizador deve ser informado do
tempo estimado para a sua concluso ou, se isso no for possvel, apenas que o
processo est a decorrer. Se tal no acontecer o utilizador poder pensar que o

sistema est parado ou que ocorreu algum erro. Uma reaco adequada poder
fazer a diferena entre um sistema agradvel e bem sucedido, e um que frustra e
confunde o utilizador27.
2) Semelhanas entre o sistema e o mundo real: O sistema deve utilizar a lin-
guagem do utilizador recorrendo a palavras, frases e conceitos familiares, em
vez de termos dirigidos ao sistema ou aos seus programadores. Seguir conven-
es do mundo real fazendo a informao surgir duma forma natural e lgica
importante para que o sistema seja compreendido pelo utilizador.
3) Controlo e liberdade: Os utilizadores por vezes escolhem funes do sistema
por engano e nesses casos eles iro procurar uma sada de emergncia, por
isso, deve ser dada ao utilizador a possibilidade de Desfazer ou Refazer um
engano, por exemplo num editor de texto. Este processo pode tambm ser equi-
parado aos botes de Retroceder e Avanar do navegador, porque sempre que
um utilizador escolhe a hiperligao errada ele pretender retroceder para o lo-
cal onde se encontrava previamente.
4) Consistncia e normalizaes: Os utilizadores no devem ter que se preocu-
par se palavras, situaes ou aces diferentes significam o mesmo, assim, as
convenes da plataforma devem ser seguidas ao mximo. Estas convenes so
o conjunto de regras ou normas, que rege cada plataforma, disso exemplo a
utilizao de ctrl+s ou cmd+s, em PC ou Mac respectivamente, para guardar
documentos em todas as aplicaes; na Web podemos referir que os elementos
devem ser o que aparentam, por exemplo, a barra de scroll e os elementos dos
formulrios devem ser facilmente reconhecidos enquanto tal.
5) Preveno de erros: Melhor que boas mensagens de erro um design pensado
cuidadosamente e que previne a ocorrncia de erros, disponibilizando ajudas
locais e globais e introduzindo exemplos.
6) Reconhecer em vez de relembrar: O esforo exigido memria do utilizador
deve ser minimizado, tornando objectos, aces e opes visveis; o utilizador
no deve ser obrigado a lembrar-se de tudo e por isso instrues sobre como in-
teragir com o sistema devem ser visveis e de fcil acesso.
7) Uso flexvel e eficiente: A existncia de aceleradoresno visveis a utilizadores
no experientespode facilitar em larga medida a interaco para utilizado-
res experientes. Exemplos deste aceleradores so, por exemplo, os atalhos por
27 Proper feedback can make the difference between a pleasurable, successful system and one that frustra-
tes and confuses. (norman, 2007)
teclado, ou a utilizao de macros, que permitem ao utilizador gerar determina-

das aces ser ter que mover o rato, procurar a opo e carregar.
8) Design esttico e minimalista: As pginas no devem conter informaes no
relevantes ou raramente usadas, porque a informao desnecessria ir com-
petir com a informao relevante pela ateno do utilizador, diminuindo a sua
visibilidade e tornando o processo de compreenso do utilizador mais lento e
complexo; quanto mais informao for disponibilizada mais difcil ser a sua
leitura.
9) Ajudar os utilizadores a reconhecer e recuperar dos erros: As mensagens de
erro devem ser apresentadas em linguagem simples, sem recorrer a cdigos e de-
vem indicar o erro com preciso sugerindo uma soluo para o problema porque
como refere Jeff Raskin mesmo que nada possa correr mal, existe sempre algo
que ir correr28.
10) Ajuda e documentao: Apesar de idealmente o sistema dever ser usado sem
documentao ela pode ser necessria para ajudar o utilizador. A documentao
deve, por isso, ser fcil de aceder e pesquisar, focada nas tarefas do utilizador,
mostrando exemplos e listando passos concretos sobre como terminar a tarefa;
os termos ou conceitos utilizados que possam no ser do conhecimento dos uti-
lizadores devem estar ligados a um glossrio; alm disso, e como tudo na Web, a
ajuda e a documentao devem ser sucintas.
1.8 Os principais problemas referenciados
Almost three-quarters of the usability issues that people encounter have to do

with basic user goals: finding, reading, and understanding information.
Jakob Nielsen & Hoa Loranger, Prioritizing Web Usability, 2006
1.8.1 Inexistncia de simetria entre os contedos
A afirmao de Nielsen remete-nos para a importncia que a apresentao dos con-

tedos adquire aquando da tarefa do utilizador de encontrar informao relevante,
no entanto, um dos maiores problemas referentes usabilidade e acessibilidade pas-
sa pela estrutura deficiente dos contedos, e pela impossibilidade de aceder a esses
contedos atravs de um navegador no visual. Provavelmente o problema mais im-
28 Murphys Law: If anything can go wrong, it will. The first corollary is, if nothing can go wrong, it will
anyway. (jeff raskin, 2000)
portante da acessibilidade fornecer informao textual para o contedo que no o

imagens, botes de imagens, ficheiros udio ou multimdia. Esta transformao
dos contedos assume este papel de destaque porque atravs dela as pessoas com li-
mitaes sensoriais passam a dispor de uma forma de aceder informao, mesmo
que no consigam aceder aos contedos propriamente ditos29 (thatcher [et al.]).
Mas esta impossibilidade de aceder aos contedos no se prende apenas com a
falta de tradues para outros meios que no sejam estritamente visuais mas, tam-
bm, com a utilizao da cor como nico elementos identificador ou hierarquizador
nas pginas, com a impossibilidade de navegar sem utilizar um dispositivo apontador
como o rato ou atravs de um dispositivo que no seja um computador pessoal, por
exemplo, um telemvel.
Em 2000 Nielsen afirmava que, dado o estado da Web nesse ano, os problemas
mais srios de acessibilidade se relacionavam com utilizadores invisuais ou possui-
dores de limitaes visuais, porque a maior parte das pginas era altamente visual30.
Passado 8 anos, numa poca em que os contedos audiovisuais na Web esto proli-
ferao, essa afirmao ganhou uma maior abrangncia, j que tanto os utilizadores
com problemas de viso, como os utilizadores com problemas de audio, esto pri-
vados de cada vez mais informao.
1.8.2 Formulao dos contedos
Outro problema comum com os contedos prende-se com a forma como estes so
formulados, utilizando, por vezes, uma linguagem demasiado complexa que se tor-
na incompreensvel para o utilizador, sendo, outras vezes, cpias de longos textos
impressos e esquecendo que a leitura em ecr sensivelmente 25% mais lenta que a
leitura de contedos impressos31 (nielsen), que a maior parte dos leitores no est
predisposta a ler textos longos e que, muitas vezes, necessria rapidez na procura de
informao. A maior parte dos utilizadores passa grande parte do tempo a pesquisar
29 The one accessibility issue that is probably more important than all others is providing text informa-
tion for web content that is nontextual. Nontext items include images, image maps, image buttons, audio
files, and multimedia files that provide both audio and video. [] The reason text is so important is that
people with sensory disabilities have ways of accessing text even if they are unable to access the nontext
content. (thatcher [et al.] 2006).
30 [] the most serious accessibility problems, given the current state of the Web, relate to blind users and
users with other visual disabilities because most web pages are highly visual. (nielsen, 2000a)
31 [] reading from computer screens is about 25 percent slower than reading from paper. (nielsen,
2000a)
rapidamente o ecr, em vez de ler linearmente a informao32 (u.s. department of

health and human services), por isso a utilizao de longos e densos blocos de
texto apenas ir dificultar a tarefa do utilizador.
1.8.3 Falta de legibilidade
A legibilidade outro factor que prejudica a apreenso dos contedos pelo utilizador,
sendo, muitas vezes, utilizado um contraste cromtico reduzido, um corpo de texto
demasiado pequeno e impossvel de redimensionar, linhas de textos demasiado lon-
gas ou entrelinhamento insuficiente.
1.8.4 Elementos visuais ou sonoros
A utilizao de elementos visuais ou sonoros que no podem ser desligados tambm

pode ser uma fonte de distraco e de frustrao para os utilizadores e pode mesmo,
dependendo das frequncias utilizadas, provocar ataques epilpticos, j que rpidas
alteraes visuais rpidas ou objectos a piscar podem ser a causa de crises epilpticas
fotossensveis em indivduos susceptveis33 (thatcher [et al.]) e, por isso, a sua uti-
lizao deve ser evitada.
1.8.5 Navegao ineficiente
A falta de consistncia na navegao ou no layout ao longo do stio tambm apon-

tada como um entrave usabilidade, porque ir dificultar a navegao e a orientao
do utilizador aumentando, consequentemente, o nmero de possveis erros, uma vez
que este nmero ser agravado com a utilizao de layouts inconsistentes34 (u.s. de-
partment of health and human services).
Outro problema grave para uma navegao usvel a utilizao de botes de
navegao de tamanho reduzido, dificultando o seu manuseamento atravs de dispo-
sitivos apontadores, porque o tempo necessrio para que um dispositivo atinja o alvo
32 Most users spend a considerable amount of time scanning rather than reading information on Web
sites (u.s. department of health and human services)
33 Rapid visual changes, flashes, or blinking objects on a web page can cause photosensitive epileptic
seizures in susceptible individuals (thatcher [et al.], 2006)
34 The number of errors made using visually inconsistent displays is reliably higher than when using
visually consistent displays. (u.s. department of health and human services)
ser reduzido se o alvo for maior, j que o utilizador no se sentir obrigado a abran-
dar, com medo de no conseguir acertar35 (ask tog). Este o principio da Lei de Fitts
que nos diz que o tempo necessrio para atingir um alvo inversamente proporcional
ao tamanho do alvo e distncia a que este se encontra.
1.8.6 Falta de compatibilidade entre os diferentes programas de

navegao
A no compatibilidade com os diferentes navegadores ou com os diferentes sistemas

operativos tambm levanta problemas, tornando, em alguns casos, os stios inope-
rveis por algumas pessoas. Muitos stios foram desenhados e testados apenas num
navegador e no podem ser utilizados noutro, uma vez que no cumprem as normas
de construo de contedos para a Web propostas pelo W3C.
1.8.7 Plug-ins no instalados no computador do utilizador
A utilizao de plug-insaplicaes que expandem o navegadorque podem no es-

tar instalados no dispositivo utilizado tambm levanta problemas graves, porque os
utilizadores tm alguma relutncia em instalar programas, ou plug-ins, descarrega-
dos da Internet, podem no o saber fazer ou podem mesmo estar impossibilitados
de o fazer, dependendo do dispositivo que utilizem para aceder Web. No entanto os
designers utilizam normalmente a ltima verso disponibilizada ao pblico dos plug-
-ins, obrigando a que os utilizadores faam a actualizao ou impossibilitando-os de
ter acesso aos contedos.
1.8.8 Estruturao dos contedos
Outra questo que levanta graves problemas de usabilidade a forma como os conte-
dos so estruturados na pgina, por vezes utilizando tabelas para a formatao do
layout, o que altera a estrutura lgica da pgina quando lida por um leitor de ecr,
outras vezes utilizando frameselemento HTML, quebrando funcionalidades es-
peradas como a possibilidade de adicionar a pgina aos marcadores. Isto cria dois
problemas:
35 If the target size is larger, then the time is reduced. It is reduced for a simple reason: the user need not
slow down when approaching the target for fear of overshooting. (ask tog, 1999)
1.8.8.1 Inviabilizao do boto de Retroceder

Quebra do boto de Retroceder do navegador quer atravs do uso de frames, Flash
ou JavaScript. A quebra desta funcionalidade ir defraudar expectativas criadas pelo
utilizador que est espera que esse boto o permita voltar (sempre) atrs na navega-
o. A no existncia dessa possibilidade ir prejudicar a sua experincia, porque no
o permitir voltar a um local seguro e poder leva-lo a sentir-se frustrado e induzido
em erro.
1.8.8.2 Violao de convenes da Web

A violao de convenes da Web prejudicial para o stio porque os utilizadores ajus-
tam as suas expectativas para um stio pelo que aprenderam a esperar noutros locais36
(nielsen [et al.]), por isso importante que as coisas paream aquilo que so. O de-
sign deve ajudar a que objectos que parecem iguais de facto o sejam37 (raskin)Uma
aparncia diferente, por si s, no prejudica a usabilidade, mas os elementos indivi-
duais devem ser facilmente reconhecveis e o seu comportamento deve corresponder
quele que o utilizador espera que seja38 (mathis).
1.8.9 Pginas de entrada
A existncia de Splash screensou pginas de entradatambm um problema

recorrente na Web, porque obriga os utilizadores a um passo desnecessrio e, conse-
quentemente, a uma perda de tempo. Normalmente estas pginas so usadas apenas
com uma animao de entradaonde a maior parte dos utilizadores ir utilizar a
opo de Skip Intro, um boto para entrar e, eventualmente, a possibilidade de
escolher qual a lngua em que pretende aceder ao stio. As duas primeiras opes se-
ro desnecessrias e a terceira pode ser dispensada, se a pgina for fornecida de acordo
com as preferncias lingusticas do navegador do utilizador e se for disponibilizado,
em todas as pginas, um boto para alterar a lngua. Nielsen defende que estas pgi-
nas devem deixar de existir, porque a impresso que elas transmitem ao utilizador
que o stio se preocupa mais com a imagem, do que com a resoluo dos problemas
do utilizador39.
36 [] users gear their expectations for your site by what they have learned to expect elsewhere. (nielsen
[et al.], 2006)
37 [] should be such that any objects that looks the same are the same. (raskin, 2000)
38 [] a different look doesnt harm usability, as long as the individual widgets are easily recognizable, and
as long as they behave the way the user expects them to. (mathis, 2008a)
39 Splash screens must die. They give users the first impression that a site cares more about its image than
about solving their problems. (nielsen [et al.], 2006)
1.8.10 Hiperligaes que no alteram o seu estado
Hiperligaes que no mudam de cor quando visitadas e que no permitem aos utili-
zadores perceber onde j estiveramuma das principais perguntas a que a navegao
deve respondersero muito prejudicuais para a usabilidade geral do stio. A utiliza-
o de CSS poder facilitar esse processo de identificao, permitindo criar diferentes
configuraes para os diferentes estados das hiperligaes:link (ainda no foi visi-
tada), :hover (o rato encontra-se sobre a ligao), :focus (o foco do teclado est sobre a
ligao) :active (quando est a ser accionada) e :visited (j foi visitada).
1.8.11 Abertura de novas janelas
A abertura de novas janelas sem o utilizador expressamente o pedir, prejudica a orien-

tao e navegao. Esta aco torna-se ainda mais prejudicial se o utilizador tiver
problemas de viso e estiver a utilizar um ampliador de ecrporque mais dificil-
mente se aperceber que surgiu uma nova janela, se estiver a utilizar um leitor de
ecrporque ter que se lembrar qual a informao que leu em cada janela, ou se
utilizar um dispositivo porttil que amplie os ecrs, por exemplo o IPhone. Grande
parte dos designers justifica esta opo com a vontade de manter os utilizadores no
stio, esquecendo-se que se um utilizador quiser abandonar um stio ele ir faze-lo
independentemente dos obstculos que forem colocados entre ele e o boto de sada,
e quanto mais obstculos existirem mais negativa ser a experincia por parte do uti-
lizador40 (smashing magazine).
O designer tambm deve lembrar-se que o utilizador poder, se assim o desejar,
abrir a hiperligao numa nova janela ou aba, utilizando as opes disponibilizadas
pelo navegador.
1.8.12 Janelas de pop-up
A utilizao de janelas de pop-up tambm uma fonte de problemas, por todas as ra-
zes acima mencionadas como sendo desfavorveis abertura de novas janelas, e pelo
facto destas abrirem automaticamente, sem ser necessria qualquer aco explcita
por parte do utilizador. tambm de salientar que estas tm conotaes negativas
40 [] often tend to forget a simple, almost elementary fact: if users want to close the application or leave
a site, they willdoesnt matter which obstacles are placed on their path to the exit-button. The more obs-
tacles there are the more negative the user experience will be. (smashing magazine, 2008a)
porque normalmente abrem em stios de jogos ou de pornografia41 (nielsen [et al.]),

levando a que a maioria dos utilizadores os fechem, muitas vezes antes mesmo do
contedo ter acabado de carregar, ou os bloquem, quando as preferncias do navega-
dor o permitem.
1.8.13 Elementos de design que parecem publicidade
A utilizao de elementos de design que parecem publicidade tambm surge como

um problema, porque os utilizadores desenvolveram algo que foi chamado de banner-
blindness e que os ajuda a ignorar qualquer elemento presente na pgina que parea
publicidade. Nielsen refere mesmo que qualquer elemento que seja grande e colorido
corre o risco de ser ignorado, principalmente se incluir animao, tornando irrelevan-
te se o elemento realmente um anncio, porque como as pessoas no o lem nunca
chegaro a saber42.
1.8.14 Opinio directa de um grupo de utilizadores
Aquando de um estudo realizado em 2005 (out-law) um grupo de utilizadores com

limitaes referiu que os maiores problemas que encontravam em stios eram: a no
existncia de uma pesquisa local ou mapa do stio; a no existncia de navegao in-
terna na pgina, como ligaes para saltar para os contedos ou que permitissem
regressar ao topo; a existncia de janelas de pop-up; e a impossibilidade de alterar o
corpo do texto ou o contraste das cores.
Estas dificuldades vm comprovar alguns dos problemas mencionados anterior-
mente e, ao mesmo tempo, chamar a ateno para outros problemas, que no podem
ser esquecidos pelo designer.
41 [] pop-ups have seedy connotations because they most often appear on gambling and porn sites.
(nielsen [et al.], 2006)
42 Anything thats overly large or colorful risks being ignored, particularly if it includes animation. [] It
is irrelevant whether the design element actually is an ad. Since people dont read it, they wont ever know.
(nielsen [et al.], 2006)
1.9 Sntese
Ao longo deste captulo foram introduzidos os conceitos da usabilidade e acessibi-

lidade e foi demonstrada a sua importncia para os utilizadores, que podero no
aceder Web em circunstncias perfeitas. Nesse contexto, e para que a Interaco Ho-
mem-Mquima seja bem sucedida, defendida a utilizao de um Design Centrado
no Utilizador numa tentativa de reduzir o nmero de potenciais problemas.
As normas de construo de contedos acessveis, as legislaes nacionais, e a
heurstica do design para a Web devem ser pensadas com o primeiro passo na cons-
truo de uma Web acessvel e usvel por todos, mas sero insuficientes para atestar a
usabilidade e acessibilidade de um stio.
No captulo seguinte ser abordada a questo avaliao da usabilidade e da
acessibilidade na Web, estudando de que forma que ela pode ser desenvolvida, por
qualquer equipa que faa projectos para a Web.
2 Avaliao da Usabilidade e da
Acessibilidade
2.1 Porqu avaliar plataformas em desenvolvimento?
If you want to know whether your software or your Web site or your VCR remote
control is easy enough to use, watch some people while they try to use it and note
where they run into trouble. Then x it, and test it again.
Como vimos anteriormente os problemas de usabilidade e/ou acessibilidade de um

sistema podero produzir efeitos negativos no nmero de utilizadores, na imagem,
na credibilidade e nos ganhos do promotor do stio. Corrigir um stio depois deste
ter sido lanado poder tambm ser prejudicial porque obrigar os utilizadores a
adaptarem-se a outro modelo e layout, por isso, antes de abrir um stio ao pblico,
aconselhvel fazer testes que permitam perceber eventuais problemas e procurar
solues. No entanto, se no for possvel realizar estes testes antes de data de abertu-
ra, eles podem (e devem) ser realizados posteriormente, porque representaro sempre
uma mais valia e uma possvel forma de melhorar a satisfao e eficincia dos utiliza-
dores. A realizao de testes potenciar o desenvolvimento de uma plataforma mais
coerente, forte, funcional e correcta, o que ser vantajoso para todos.
Existem vrios tipos de testes que podem ser realizados para avaliar o nvel de
usabilidade e acessibilidade de um stio. Testar a usabilidade do stio requer a utiliza-
o de pessoas dispostas a usar o sistemapara avaliar com que eficincia o podem
utilizar e quais as dificuldades com que se deparam, mas para testar a acessibilida-
de, o primeiro passo deve ser submeter o stio s ferramentas automticas de validao
e, posteriormente, desenvolver testes com utilizadores que tenham vrios tipos de

limitao. Nenhum teste automtico poder, s por si, atestar a acessibilidade de um
stio, uma vez que apenas faz uma verificao a nvel tcnico e no a nvel funcional.
Os testes de acessibilidade devem, por isso, combinar processos automticos de
validao e testes com utilizadores que possam avaliar o stio. Embora reconhea a
importncia dos testes de acessibilidade com utilizadores, essa questo no ser abor-
dada uma vez que est fora do mbito desta dissertao. O meu objectivo focar-me
em meios de verificao da usabilidade e acessibilidade que possam ser utilizados por
qualquer pessoa e em qualquer circunstncia. A dificuldade de recrutar sujeitos com
limitaes dispostos a participar em experincias deste tipo levanta problemas reais
aquando da realizao de testes, por isso deixarei o seu estudo para outra ocasio.
2.2 Testes com utilizadores
Never assume mistakes are the users fault!

Just dont forget that its always your fault.
Never blame the user.
Lukas Mathis, You really, really need to do Usability Tests, 2008
2.2.1 Porqu realizar testes com utilizadores?
A realizao de testes de usabilidade importante porque as pessoas directamente

envolvidas no projecto deixam de o ver objectivamente, elas sabem demasiado sobre
o seu funcionamento. O criador de uma plataforma e dos seus processos sabe como
cada um se desenvolve e o que deve fazer para que esses processos se desenrolem sem
percalos. Adicionalmente no ter qualquer dificuldade em interagir com a platafor-
ma e, consequentemente, no encontrar nenhum problema que deva ser corrigido
ou qualquer elemento que deva ser repensado; a interface ter sido usada to extensa-
mente que o designer se ter habituado s suas falhas.
Os testes iro ajudar a perceber que diferentes pessoas pensam de forma diferen-
te, sabem coisas diferentes e usam a Web de formas diferentes.
Os testes de usabilidade devem ser realizados o mais cedo possvel, porque os
seus resultados iro permitir o melhoramento do produto. Tambm importante sa-
lientar que quanto mais avanado estiver o projecto mais complicado ser altera-lo e
mais caras iro ser essas alteraes. O utilizador, por sua vez, tambm poder resistir a
qualquer mudana porque ter que se habituar a outra interface e, por isso, as mudan-
as numa fase posterior abertura do stio devem ser reduzidas ao mnimo43 (krug).
O processo de testagem deve ser realizado com antecedncia suficiente para se
conseguir tirar concluses reais sobre a interaco, e para que a equipa tenha tempo
para corrigir os erros e problemas encontrados. O processo no deve ser realizado na
semana anterior ao lanamento do stio e no deve ter como finalidade decidir qual a
cor que fica melhor. Krug sublinha que, infelizmente e na maior parte das vezes, os
testes so realizados demasiado tarde e pelas razes erradas44.
Segundo Alan Cooper (2007) este tipo de testes ser particularmente eficaz
para determinar se os termos empregues em seces e botes fazem sentido para os
utilizadores, se a informao est organizada em grupos lgicos, e se estes esto po-
sicionados em locais onde os utilizadores os procuram; se as aces e/ou elementos
so facilmente encontrados pelos novos utilizadores; e se as instrues so claras ou
necessrias. Alm disso os testes permitiro avaliar a eficcia com que os utilizadores
conseguem completar tarefas especficas, se cometem erros, onde o fazem e com que
regularidade o fazem.
43 Some percentage of users will resist almost any kind of change, and even apparently simple changes
often turn out to have far-reaching effects, so anything you can keep from building wrong in the rst place
is gravy. (krug, 2000b)
44 Sadly, this is how most usability testing gets done: too little, too late, and for all the wrong reasons.
(krug, 2000b)
2.2.2 Tipos de testes de usabilidade com utilizadores
Existem vrios tipos de testes que podem ser desenvolvidos com os utilizadores de-
pendendo do oramento disponibilizado para tal.
Um teste tradicional, encomendado a uma empresa que faa um Estudo de Usa-
bilidade, exigir um oramento vrias vezes superior a um estudo que seja realizado
de uma forma mais livre. Steve Krug (2000) faz um estudo comparativo entre ambos:
Testes tradicionais Testes mais livres
Nmero de Normalmente oito ou mais Trs ou quatro.

utilizadores para justificar os custos.
Esforos de Seleccionados Qualquer pessoa que use a

recrutamento cuidadosamente para fazerem Web.
parte da audincia alvo.
Onde testar? Um laboratrio de usabilidade, Qualquer escritrio ou sala de

com uma sala de observao e conferncias.
um espelho falso.
Quem faz o Um profissional da Qualquer ser humano

teste? usabilidade com experincia. paciente.
Planeamento Os testes tm que ser Podem ser executados quase

antecipado marcados com duas semanas em qualquer altura e com
de antecedncia, para reservar pouca antecedncia de
o laboratrio de usabilidade marcao.
e para haver tempo para o
recrutamento.
Preparao Esboo, discusso e reviso do Deciso do que mostrar e
exigida protocolo do teste. testar.
O que testar? Testar quando o stio est Desenvolver testes
Quando perto da conclusopara que continuamente ao longo do
testar? os custos sejam mais contidos. processo de desenvolvimento.
Testes tradicionais Testes mais livres
Custo Entre 5000 e 15000 dlares Cerca de 300 dlares (entre 30

(por vezes mais). e 100 para cada utilizador e
20 para 3 horas de cassete de
vdeo).
O que Um relatrio escrito de 20 Cada observador escreve uma
acontece pginas que s chegar uma pgina de notas no dia do teste.
depois? semana depois, e que a equipa A equipa de desenvolvimento
de desenvolvimento ir pode reunir no mesmo dia e
analisar para decidir o que tirar concluses imediatas.
alterar.
Este projecto ir centrar-se essencialmente na abordagem mais informal aos tes-

tes, uma vez que esta ir permitir que eles sejam realizados quase por qualquer pessoa
e por quase, ou mesmo nenhum, custo. Este tipo de testes possibilitar que eles sejam
mais desenvolvidos, uma vez que no tero influncia nos custos totais, e possibilita-
r que o projecto saia fortalecido.
2.2.3 Realizao de testes
2.2.3.1 Como?
Antes da realizao dos testes devem ser determinados os objectivos desse teste e
quais as perguntas que procuram ser respondidas. Devem ser evitadas perguntas e
objectivos vagos como Determinar se o nosso stio fcil de utilizar porque estes
no permitiro obter uma resposta concreta. Posteriormente, e com a finalidade de
responder a essas perguntas composto um conjunto de tarefas que o utilizador ter
que desempenhar, com maior ou menor sucesso. S depois de uma elaborao dos
objectivos do teste e das tarefas a realizar que se pode partir para a realizao do teste.
Durante um teste de usabilidade temos a possibilidade de observar utilizadores
reais a interagirem com o stio e a executar tarefas que se aproximam dos seus objec-
tivos. O principal objectivo da realizao de um teste tentar perceber quais as partes
da interface que dificultam a interaco e, por isso, importante que o stio no seja
discutido antecipadamente com os sujeitos para que eles possam, desde o primeiro
contacto, dizer se perceberam para que serve o stio e como que ele funciona.
O teste deve comear por apresentar a plataforma a cada utilizador, para que ele
possa, numa fase posterior, desempenhar as tarefas previamente definidas. A reali-
zao do teste deve ser acompanhada por um facilitador cuja funo impedir o
sentimento de frustrao por parte do utilizador. Krug (2000) refere que a tarefa do
facilitador dizer aos utilizadores quais as tarefas que eles devem executar, encoraja-
los a pensar alto, ouvir cuidadosamente o que eles tm a dizer e protege-los45. Durante
a realizao do teste o mais importante ser que os utilizadores percebam que o ob-
jecto do teste a interface do stio, no eles prprios, e que, como refere Lukas Mathis
(2008), cada erro que eles faam ir ajudar a melhorar o stio46.
Ao longo da interaco com o sistema, o observador deve tirar notas extensi-
vas, porque mais tarde algumas coisas podero cair no esquecimento. Essas notas
podem ser tiradas seguindo um formato livre, ou preenchendo uma lista previamente
elaborada com todos os pontos essenciais para responder s perguntas iniciais. Prova-
velmente a forma mais eficaz ser a combinao de ambos os mtodos, o que permite
ao observador certificar-se que nenhum ponto importante esquecido e, ao mesmo
tempo, permite-lhe adicionar qualquer informao que ache relevante.
Aps a realizao do teste aconselhvel fazer um pequeno questionrio aos
utilizadores perguntando o que gostaram e o que no gostaram, que funcionalidades
esperariam de uma aplicao semelhante e se a iriam utilizar no futuro.
2.2.3.2 O que necessrio?

O material necessrio para a realizao de um teste varia de acordo com a envergadura
do teste que se est a preparar. Normalmente exigido um escritrio ou sala de confe-
rncias com duas cadeiras, um computador com ligao Internetse estiver a testar
um stio online, uma cmara vdeo e um trip. A cmara deve gravar o utilizador, o
que ele v e o que ele diz. Ela pode ainda estar ligada a um ecr que se encontra noutro
espao, permitindo que toda a equipa possa observar o teste. A maioria das gravaes
no sero visionadas posteriormente, no entanto importante que o possam ser se
necessrio, porque durante o teste muita informao passa despercebida ao obser-
vador. Permitir ao observador completar as notas tiradas durante a observao com a
gravao pode ser muito til e pode ajud-lo a tirar algumas dvidas, ou a confirmar
alguns elementos.
45 Your responsibility [as facilitator] is to tell the users what you want them to do, to encourage them to
think out loud, to listen carefully to what they have to say, and to protect them. (krug, 2000c)
46 Every mistake they make helps you improve the application. (mathis, 2008b)
Em ltima instncia apenas ser necessrio gravar o ecr do computador, o utili-

zador e o que ele tiver a dizer. Para isso no so necessrias grandes infra-estruturas ou
grande quantidade de material, visto que actualmente existem aplicaes que permi-
tem a gravao simultnea do ecr e do utilizadorpor exemplo Silverback47 para Mac
ou Morae48 para PC. Estas aplicaes apenas exigem um computador e uma webcam.
2.2.3.3 Quem pode realizar testes?

Como Krug refere na tabela comparativa anteriormente mencionada, qualquer ser
humano paciente poder realizar o teste de usabilidade. A pacincia a qualidade exi-
gida porque no ser favorvel para o utilizador e, consequentemente, para o teste, se
a pessoa responsvel se irritar facilmente com os possveis erros, hesitaes ou dvi-
das do utilizador.
2.2.3.4 Quantos utilizadores?

Krug diz-nos que testar com um utilizador 100% melhor que no testar, e que mesmo
o pior teste com o utilizador errado permitir encontrar formas de melhorar um stio49.
Mas para ele o nmero ideal de utilizadores 3, no mximo 4, porque permite acelerar
o processo de testagem, procedendo realizao dos mesmos e discusso dos re-
sultados no mesmo dia, beneficiando imediatamente daquilo que se aprendeu. Alm
disso, um teste com mais do que 4 utilizadores normalmente produz mais notas do
que aquelas que podem ser processadas50 (krug), tornando o esforo desnecessrio.
Lukas Mathis (2008) diz-nos que com apenas 3 podemos obter j uma lista con-
sidervel de problemas e que, acima de tudo, aconselhvel no parar de fazer testes
sucessivos at erradicar os problemas mais graves.
Jakob Nielsen, por sua vez, diz-nos que o nmero ideal de utilizadores 5, uma
vez que a curva de aprendizagem com um nmero maior bastante reduzida e, na
maior parte das vezes, no ir produzir mais conhecimento relevante. Para ele os me-
lhores resultados so obtidos testando no mximo 5 utilizadores e realizando o maior
47 http://silverbackapp.com/
48 http://www.techsmith.com/morae.asp
49 Testing one user is 100 percent better than testing none. [] Even the worst test with the wrong user
will show you things you can do that will improve your site. (krug, 2000b)
50 [] when you test more than four at a time, you usually end up with more notes than anyone has time
to process (krug, 2000b)
nmero possvel de pequenos testes51. Mas Nielsen vai ainda mais longe referindo que
logo aps o primeiro teste, j tero sido encontrados quase 1/3 de todos os problemas
possveis52.
A curva de aprendizagem referida por Nielsen mostra-nos que necessrio um
total de 15 utilizadores para encontrar todos os problemas de usabilidade do siste-
ma, no entanto, para ele prefervel realizar 3 testes com 5 utilizadores do que gastar
todo o oramento apenas num teste. A iterao crucial na realizao de testes porque
permitir melhorar efectivamente o sistema e no apenas encontrar falhas. Aps um
teste o sistema ser redesenhado para corrigir os problemas, mas ser essencial que o
utilizador possa avaliar se esses problemas foram de facto corrigidos, porque, como
refere Daniel M. Brown, estes testes apenas reportam que existe um problema e qual a
sua natureza, eles no dizem necessariamente como que ele pode ser corrigido53.
Aps uma leitura de vrias opinies consideraremos que o nmero ideal de uti-
lizadores para um teste de usabilidade varia entre 3 e 5, e que o mais importante que
os testes sejam realizados continuamente e de forma iterativa.
2.2.3.5 Quem devem ser os utilizadores?

Existe quem defenda que os utilizadores escolhidos para o teste devem ser represen-
tativos das pessoas que iro utilizar o stio (van duyne [et al.], 2007), mas o mais
importante ser sempre testar. Krug defende que no importa quem testado54, por-
que para a maioria dos stios (aqueles que so destinados ao pblico geral) apenas
necessrio algum que saiba o bsico sobre como usar a Web. Mas importante que
todos os utilizadores desconheam a aplicao e, por isso, os mesmos sujeitos no
devem ser repetidos em testes realizados em fases distintas.
Obviamente nem para todo o tipo de testes indiferente quem o utilizador tes-
tado. importante ter em ateno que (1) se o stio for utilizado quase exclusivamente
por um tipo de utilizadores, devem ser escolhidos utilizadores desse grupo, por exem-
plo num stio destinado a crianas, e (2) se o stio exigir algum tipo de conhecimento
especfico devem ser escolhidos os utilizadores que possuam esse conhecimento, por
exemplo se o stio for destinado apenas ao uso por profissionais de sade.
51 The best results come from testing no more than 5 users and running as many small tests as you can
afford. (nielsen, 2000b)
52 [] as soon as you collect data from a single test user, your insights shoot up and you have already lear-
ned almost a third of all there is to know about the usability of the design. (nielsen, 2000b)
53 These tests simply report that a problem exists and the nature of that problem, not necessarily how to
fix it. (brown, 2007)
54 [] doesnt much matter who you test. (krug, 2000a)

Steve Krug, no seu stio, sugere que convidemos um vizinho para testar o stio
em anlise enquanto observamos a sua interaco; ns levaremos a cerveja55. Com esta
sugesto Krug diminui a importncia dada escolha de utilizadores, e torna o teste
uma experincia algo informal, sem, no entanto, lhe retirar relevncia.
2.2.4 Depois da realizao dos testes
Aps a realizao do teste, as informaes, notas e observaes devem ser analisadas,

na tentativa de encontrar solues para resolver os maiores problemas encontrados
pelos utilizadores. As solues devem posteriormente ser implementadas e devem
realizar-se novos testes, para verificar se os problemas foram de facto resolvidos. Se o
tiverem sido provavelmente sero encontrados novos erros que devero ser tambm
corrigidos.
A realizao de testes deve, por isso, ser um processo iterativofaz-se algo, tes-
ta-se, corrige-se, e testa-se novamente.
2.2.5 Testes de acessibilidade com utilizadores
Os pontos acima mencionados so, na sua maioria, vlidos tambm para testes de
acessibilidade. A realizao de testes de acessibilidade com utilizadores importante,
porque s eles permitiro encontrar problemas de usabilidade especficos para utili-
zadores com algum tipo de limitao.
A maior diferena que podemos encontrar em relao a um simples teste de
usabilidade reside nos prprios utilizadores, que devem ter limitaes especficas
problemas de viso, audio, motores, etc. Como num teste de usabilidade ser
necessrio mais que um utilizador para cada limitao (entre 3 e 5), porque apenas
um no nos permitir encontrar todas as respostas necessrias. Outra diferena ser o
material necessrio para a realizao do teste, j que sero necessrias tecnologias de
assistncia que permitam ao utilizador interagir com o sistema.
A forma de conduzir e realizar os testes ser semelhante, embora o facilitador
deva ter conhecimento do funcionamento das tecnologias de assistncia e da forma
como elas so usadas pelos utilizadores. Desse modo no podero ser realizados por
qualquer pessoa, em qualquer circunstncia e tero limitaes muito maiores.
55 If you really want to know if your Web site works, ask your next door neighbor to try using it, while you
watch. (You bring the beer.) (krug, 1997)
2.2.6 Prototipagem em papel
Paper is accessible and so versatile. You can quickly sketch, lay out, and evaluate
interaction design concepts for basic usability, making it possible to rapidly
organize, articulate, and visualize interaction design concepts.
Bill Moggridge, Designing Interactions, 2007
Outro tipo de testes com utilizadores realizado recorrendo a prottipos em papel,

em vez de prottipos funcionais e dependentes de tecnologias. Carolyn Snyder diz-
nos que a prototipagem em papel uma variao dos testes de usabilidade, em que os
utilizadores realizam as tarefas interagindo com uma verso em papel da interface.
Esta verso manipulada por uma pessoa que faz de computador, e que, como o com-
putador, no explica como que a interface deve funcionar56.
Os prottipos em papel podem ser concebidos atravs de desenhos manuais, de
software ou at mesmo capturas de ecr impressas; a tcnica secundria, o mais im-
portante que eles permitam ao utilizador ter uma ideia geral das funcionalidades e
funcionamento do stio.
A utilizao de um prottipo em papel permite testar, desde os primeiros esbo-
os, a um custo muito baixo, permitindo desde o primeiro momento a correco de
alguns problemas de usabilidade e uma consequente diminuio dos custos com cor-
reces aps a implementao. Outras vantagens incluem a rapidez com que se pode
faz-lo, a facilidade que os utilizadores encontram em criticar um simples rascunho
no papel e a eliminao de variveis tecnolgicas durante os testes. A prototipagem
em papel tambm flexvel porque permite fazer alteraes rapidamenteapagar e
escrever por cima, tirar notas, dobrar e recortarmesmo durante o teste.
No entanto, como qualquer mtodo, no permite encontrar todo o tipo de pro-
blemas, e pode influenciar em larga medida a forma como os utilizadores interagem
com a interface, dificultando o processo de interaco. Outras desvantagens passam
pela possibilidade de transmitirem falta de profissionalismo, pela no produo de
cdigo que possa ser utilizado, e pela dificuldade em copiar alguns dos comportamen-
tos da interface.
56 Paper prototyping is a variation of usability testing where representative users perform realistic tasks
by interacting with a paper version of the interface that is manipulated by a person playing computer, who
doesnt explain how the interface is intended to work. (snyder, 2003)
Apesar das inmeras vantagens que podem advir da utilizao deste mtodo
Nielsen refere que a prototipagem em papel no muito usada, porque as pessoas no
acham que vo obter informao suficiente atravs de um mtodo to simples e bara-
to. A sua utilizao chega a parecer batota57, por se tratar de um mtodo muito barato,
mas que simplifica em larga medida o processo de design. Ele salienta ainda que
sensivelmente 100 vezes mais barato fazer alteraes antes do cdigo ter sido escrito,
do que esperar que a implementao esteja concluda58.
Segundo Ivo Gomes este mtodo particularmente til para recolher dados
sobre: conceitos e terminologias, navegao, contedo, layout da pgina e funciona-
lidades (2008). Este mtodo ser til no s para testar com utilizadores reais mas
tambm para utilizar em testes internos, dentro da equipa de design e de programa-
o, porque permitir perceber a facilidade ou dificuldade da realizao das tarefas e
navegao, e quais as exigncias reais para uma interaco bem sucedida.
2.2.7 Sugestes para a realizao de testes com utilizadores
Steve Krug (2000) define dez pontos essenciais a ter em mente quando se pretende
realizar um teste de usabilidade:
1) Testar o teste para ter a certeza que ele passvel de ser realizado no tempo es-
tabelecido para a sesso, e para certificar que o projecto pode ser acedido no
computador que ser utilizado;
2) Proteger o utilizador, no permitindo que ele fique frustrado se no conseguir
desempenhar determinada tarefa, e no final agradecer a sua participao escla-
recendo que ela foi de extrema importncia;
3) Ser simptico;
4) Tentar perceber o que o utilizador est a pensar e, se necessrio, perguntar-lho;
5) No fornecer pistas aos utilizadores sobre o que fazer;
6) Manter as instrues simples;
7) Sondar o utilizador sempre que ele fizer algum comentrio que nos parea im-
portante ver esclarecido;
8) No ter medo de improvisar;
57 Paper prototyping isnt used because people dont think they will get enough information from a me-
thod that is so simple and so cheap. It feels like youre cheating (nielsen, 2003a)
58 The most common estimate is that its 100 times cheaper to make a change before any code has been
written than it is to wait until after the implementation is complete. (nielsen, 2003a)
9) No ficar decepcionado se um utilizador no tiver experincia;

10) Aps cada sesso escrever algumas notas, porque a memria do ser humano vai
desvanecendo.
Alm destes 10 pontos enumerados por Krug, outros autores referem mais al-
guns que no devem ser esquecidos:
11) Manter o silncio enquanto os utilizadores esto a trabalhar;

12) No revelar quantas tarefas existem, porque por vezes pode ser mais vantajoso
fugir ao programa pr-estabelecido;
13) Evitar perguntas sobre design, as respostas para os problemas encontrados de-
vem ser discutidas depois do teste, no interior da equipa do projecto;
14) Respeitar os participantes e a sua confidencialidade no revelando os seus no-
mes e no fazendo comentrios negativos.
Estas 14 sugestes simplificam a realizao de testes com utilizadores, na medi-

da em que fornecem pistas ao facilitador sobre a melhor forma de conduzir os testes,
procurando que a experincia do utilizador com a interface possibilite responder a
todas as questes inicialmente definidas.
2.3 Testes automticos
Existem vrios testes que permitem a validao automtica das normas de constru-
o de contedos acessveis para a Web, e que permitem ao designer proceder a uma
verificao rpida. Para a realizao destes testes existem ferramentas online, entre as
quais se salientam os portais: Cynthia Says59 que verifica automaticamente as normas
do WAI e da Section 508atravs da verificao dos pontos definidos por ambas as
normas, Hera60 que faz uma verificao das WCAG 1.0 segundo as prioridades 1, 2 e
3, T.A.W., Web Accessibility Test61, e eXaminador62 uma ferramenta fornecida pelo Progra-
ma Acesso: Acessibilidade para cidados com necessidades especiais63.
59 http://www.contentquality.com
60 http://www.sidar.org/hera
61 http://www.tawdis.net/taw3/cms/en
62 http://www.acesso.umic.pt/webax/examinator.php
63 http://www.acesso.umic.pt
de salientar que impossvel validar a acessibilidade de um stio apenas com

testes automticos, e a validao nestas ferramentas automticas no permite des-
cobrir se um stio acessvel, apenas permite descobrir se ele tecnicamente no o .
Os testes automticos apenas permitem uma verificao dos aspectos tcnicos e no
da interaco humana. Por exemplo obrigatrio que todas as imagens possuam
uma descrio, e o teste automtico consegue verificar se de facto ela existe, mas ser
incapaz de determinar se esse texto adequado para a descrever, e se permite que a
informao da pgina seja igualmente apreendida com, ou sem, imagens. Por isso,
estes testes sero insuficientes para fornecer uma comprovao total de convergncia
com as normas, e no sero capazes de fornecer uma lista real de elementos que devem
ser alterados.
Nenhum teste automtico poder substituir o ser humano, no entanto ele pode
fazer algo que nenhum humano pode fazer: examinar dzias, ou mesmo milhes,
de pginas para encontrar elementos em falta. O ser Humano no bom em tarefas
exaustivas e cansativas64 (thatcher [et al.]).
A passagem por estes testes o primeiro passo na criao de um stio acessvel
e que cumpra as normas estabelecidas, o segundo passo deve ser recorrer a uma ava-
liao com utilizadores reais.
2.4 Sntese
Ao longo deste captulo foram referidas as vantagens de realizar testes de usabilidade

e acessibilidade, e apresentaram-se algumas sugestes sobre como o fazer. A avalia-
o destas questes foi abordada de forma algo informal, permitindo que qualquer
designer ou criador a pudesse realizar, facilmente e sem custos. Esta abordagem dei-
xa, como foi referido, uma lacuna real na comprovao da acessibilidade do stio, j
que apenas recorre a testes automticos de acessibilidade, mas poder ser considera-
da uma melhoria em relao prtica corrente do processo de Design para a Web.
No prximo captulo sero referidas as vrias fases de um projecto de Design
para a Web, e de que forma que um estudo de usabilidade e acessibilidade pode ser
levado a cabo, ao longo das diversas fases. Como teremos oportunidade de demons-
trar, a realizao destes pequenos testes ser essencial para que um designer possa
considerar o ser projecto concludo com sucesso e ser essencial para que o utilizador
se sinta confiante e satisfeito com a interaco.
64 [] examine dozens (even millions, for some tools) of pages to find missing alt attributes or label ele-
ments. Humans are not so good at such exhaustive and tedious examination. (thatcher [et al.], 2000)
3 Caso de Estudo 41
3 Caso de Estudo
Depois de realizar um estudo terico sobre as questes da usabilidade e da acessibili-

dade no design para a Web, o estudo de um caso real torna-se essencial para comprovar
teorias recolhidas e previamente estudadas por outros, e ao mesmo tempo procurar
contribuir para enriquecer o corpo terico de que parte. A aplicao dos conhecimen-
tos adquiridos durante o estudo inicial ter como objectivo chegar um conjunto de
concluses sobre como responder concretamente s necessidades, expectativas e exi-
gncias do utilizador.
3.1 Introduo ferramenta escolhida: tv.up.pt
O stio da tv.up foi a ferramenta escolhida para caso de estudo. Esta ferramenta preten-
de ser uma plataforma de comunicao entre a comunidade da U.Porto, aglomerando
vrias funcionalidades como a publicao de vdeos, a criao de canais ou blogues, e
ao mesmo tempo pretende ser um meio de divulgao da prpria universidade.
A tv.up tem como misso o estmulo produo de contedos audiovisuais e
multimdia no mbito da actividade da Universidade do Porto, e a sua distribuio
atravs de um Portal na Internet e de um canal interno de TV da U.Portoo canal
tv.up. Estes canais exibiro contedos produzidos pela sua equipa e, sobretudo, por
toda a comunidade da U.Porto. A tv.up define-se como um espao para a divulgao do
que se faz e acontece na U.Porto, catalisando o debate de ideias e das grandes questes
da comunidade, reforando as redes internas de comunicao existentes e, em simul-
tneo, actuando no sentido de constituir um acervo cientfico e cultural disponvel na
Web.65
65 http://tv.up.pt
A comunidade da U.Porto constituda por discentes, docentes, tcnicos, auxi-

liares de educao, administrativos, e todos os outros que no seu passado, presente ou
futuro passaram, ou passaro, por esta Universidade. No podemos definir, por isso, o
utilizador tipo, cada um deles ser nico e diferente de todos os outros; no podemos
esclarecer quanto a nveis de literacia, domnio da Web ou mesmo lngua mese
pensarmos em discentes de intercmbio.
Alm disso, apesar da plataforma pretender ser uma ferramenta de comunica-
o da U.Porto, o registo ser livre e possibilitar que qualquer pessoa, de qualquer
parte do mundo, alimente os contedos desta ferramentaalargando ainda mais o
(possvel) universo populacional do portal da tv.up.
3.2 Calendrio do projecto
A fase de anteprojecto deste portal comeou e a ser desenvolvida em Julho de 2007, e

encontra-se actualmente na fase de implementao. A verso Alfa foi lanada a 5 de
Julho de 2008 e a abertura ao pblico est prevista para Outubro de 2008, com a verso
Beta.
3.3 Fases do Projecto de Design
Idealmente um projecto de design para a Web desenvolvido em quatro fases(1)

anteprojecto, (2) projecto, (3) implementao e (4) ps-implementao. Descrevo em
seguida cada uma das fases, esclarecendo como que o estudo de usabilidade pode
ser realizado, e como que ele o foi neste caso especfico (nas fases j terminadas ou
em curso).
3.3.1 Anteprojecto
3.3.1.1 Anlise dos requisitos e funcionalidades exigidas

Na primeira fase do processo de design necessrio compreender as exigncias do
projecto e do cliente, para perceber quais as funcionalidades que podem ou devem
estar presentes. Este estudo prvio tem em considerao os requisitos estabelecidos
pelo cliente mas vai alm disso, equacionando outras exigncias possveis e avaliando
de que forma as vrias funcionalidades podero ser agrupadas e combinadas no seu
todo.
3 Caso de Estudo 43
No projecto da tv.up foram estudadas e discutidas as funcionalidades exigi-

das pelo clientecriao de conta, configurao do perfil, carregamento de vdeos,
criao de canais e blogues, pginas de contedo estticasnuma tentativa de as
organizar.
A listagem final de requisitos e funcionalidades era bastante mais completa:
processos de registo, autenticao, recuperao de palavra passe ou utilizador, carre-
gamento de vdeos, criao de playlists, canais, blogues e posts; configurao de perfil,
informao do vdeo, do canal e do blogue; possibilidade de adicionar um contedo
como favorito do utilizador ou de o reportar como abusivo; criao de pginas estti-
cas geradas a partir de uma zona de administrao; funcionalidades de pesquisa.
3.3.1.2 Anlise comparativa

Depois de sabermos quais os requisitos exigidos aconselhvel visitar outros stios
que ofeream as mesmas funcionalidades, ou parte delas, procurando solues para
problemas especficos e tentando perceber quais as opes oferecidas aos utilizado-
res. O designer deve ter em mente que o utilizador cria as suas expectativas com base
no que aprendeu noutros stios, por isso deve ter em considerao os hbitos pr-esta-
belecidos por estes. A experincia dos designers na utilizao de outras plataformas,
alm de permitir a descoberta de novas ofertas que podero ser teis no contexto do
projecto que esto a desenvolver, poder tambm ser-lhes til no processo de aprendi-
zagem e descoberta de boas prticas para solucionar problemas comuns.
Esta anlise comparativa permitiu-nos comparar resolues de cada um dos
processos e problemas identificados, e ajudou-nos a encontrar solues, que acredi-
tvamos que no chocariam o utilizador ou lhe dificultariam as tarefas.
3.3.2 Projecto
Durante esta segunda fase o designer comea por desenvolver os primeiros esboos da-
quilo que poder vir a ser o stio, para que a possa concluir com um prottipo funcional
do projecto. Nesta fase recorre-se por vezes utilizao de personaspersonagens-mo-
delo que representam os possveis utilizadores dos stios e as suas necessidadese de
wireframesuma representao visual estrutural do contedo do stio, cuja finalidade
projectar os locais destinados aos contedos sem, no entanto, desenvolver o design
final. Estas ltimas possibilitaro uma maior compreenso da interface com a qual o
utilizador ter que interagir, mas a maior vantagem na sua utilizao reside no facto
de serem uma ferramenta que encoraja a colaborao (kelway, 2008), encorajando
tambm a troca de ideias e a sua discusso, na procura da melhor interface.
Neste projecto no foram criadas personas, mas em cada fase eram tidos em conta
os possveis utilizadores, atravs de idealizaes e comparaes, e o que eles poderiam
necessitar para concluir com sucesso as tarefas desejadas. A utilizao de wireframes
facilitou o processo de design, permitindo que o projecto comeasse a ser desen-
volvido atravs de esboos rpidos, poupando tempo, e exigindo menos ateno na
programao da interface, uma vez que os pormenores locais j estavam definidos.
3.3.2.1 Escolha da tecnologia a utilizar

A escolha da tecnologia a ser utilizada poder ser determinante para a compatibili-
dade dos stios com os diversos navegadores e dispositivos, e influenciar em grande
medida a usabilidade e acessibilidade do stio. Algumas tecnologias como linguagem
de programao tornam mais difcil o processo da criao de stios fceis de usar,
por exemplo a utilizao de Flash da Adobeporque obriga a criar processos mais
complicados para colmatar falhas estruturais da linguagem, que no foi criada espe-
cificamente para programao Web.
O stio da tv.up foi programado em XHTML 1.0, seguindo as normas da W3C, e
foi formatado visualmente utilizando CSS 2.1. A utilizao destas linguagens permite
uma separao clara entre contedos e formataes visuais, uma maior adaptabili-
dade aos diversos dispositivos e uma maior flexibilidade para o futuro, tal como
defendido pelo W3C.
Alm destas tecnologias recorremos utilizao do plug-in Flash Player 9, da
Adobe, apenas para a incluso dos vdeos, e utilizao ocasional de JavaScript, para
possibilitar funcionalidades de suporte interaco. Como vimos no primeiro cap-
tulo a utilizao de plug-ins no aconselhada, porque o utilizador pode no os ter
instalados, no entanto a incluso de vdeos nas pginas XHTML requer sempre a uti-
lizao de um plug-in, e o Flash Player o mais utilizado na Web actual e encontra-se
instalado em 99% dos computadores pessoais com ligao Internetsegundo os da-
dos de um estudo realizado para a Adobe Systems, inc., em Junho de 2008 (millward
brown). Para evitar problemas em encontrar o plug-in na Web foi includo um pro-
cesso de verificao da existncia deste e, caso ele no exista, apresentada uma
mensagem explicitando a sua necessidade e disponibilizando uma hiperligao direc-
ta para o obter. A utilizao de JavaScript tambm ter algumas desvantagens, uma
vez que ele altera dinamicamente o contedo da pgina, quebrando, por exemplo, a
funo de retroceder e dificultando o processo de favoritar. No entanto, existem al-
guns mtodos que permitem que um valor diferente seja passado URLUniform
Resource Locator e que apenas exigem mais algum trabalho de programao, o que
3 Caso de Estudo 45
ser realizado. Outro inconveniente da utilizao desta linguagem o facto do utili-

zador poder desligar o JavaScript, por isso, essencial que nenhuma funcionalidade
dependa exclusivamente desta linguagem. No caso da tv.up as funcionalidades que
dependem de JavaScript podem tambm ser acedidas de outra forma, por exemplo
esta linguagem utilizada para possibilitar o drag-and-drop aquando da ordenao de
vdeos numa playlist, no entanto o mesmo pode ser conseguido atravs dos botes
disponibilizados para tal.
3.3.2.2 Padres do design ou boas prticas pr-estabelecidas

Como forma de guiar os designers na sua tarefa de desenhar um produto fcil de
utilizar e acessvel ao maior nmero possvel de pessoas, existe uma extensa bibliogra-
fiaJakob Nielsen, Steve Krug, Jenifer Tidwell, Jim Thatcher, Alan Cooper, e muitos
outrosque descreve prticas tidas como mais acertadas para resolver um determi-
nado nmero de problemas. Este conjunto de boas prticas existe numa tentativa de
evitar que o designer reinvente a roda sempre que tiver que resolver um problema es-
pecfico que j foi recorrentemente resolvido por outros. Ele permitir simplificar o
processo do design quer do layout, quer dos processos.
A utilizao de algumas destas prticas muitas vezes aconselhada no por-
que funcione melhor mas porque no trai a memria do utilizador, ajudando-o a
orientar-se. Donald A. Norman refere que os novos produtos, independentemente da
qualidade da ideia, iro quase garantidamente falhar66, se a forma de serem operados for
desconhecida pelos utilizadores.
Estas recomendaes so organizadas de vrias formas, algumas em artigos
independentesonline e impressos, outras em longos livros organizados segundo
temas ou problemticas, outras ainda em stios dedicados total ou parcialmente ao
tema.
Como foi j referido, as expectativas do utilizador para um stio so estabeleci-
das com base no que ele aprendeu a utilizar nos outros stios, por isso de extrema
importncia analisar solues que j foram implementadas, de forma a podermos
melhorar a nosso projecto. O desenvolvimento do projecto da tv.up coincidiu com a
fase de investigao para esta dissertao. Assim, toda a literatura consultada ajudou
a perceber problemas, a equacionar solues e a perceber como muitas das funciona-
lidades so implementadas.
66 [] new products almost guaranteed to fail, no matter how good the idea. (norman, 1998)
3.3.2.3 Testes informais e prototipagem em papel

Quanto mais cedo o projecto comear a ser mostrado e experimentado, mais depressa
se comearo a recolher informaes sobre ele. E, embora muitas vezes as equipas
tenham alguma relutncia em mostrar trabalhos em curso, deve ser tido em consi-
derao que os utilizadores se sentem mais vontade para comentar algo que parece
inacabado. O designer no deve nunca considerar o projecto concludo sem que este
tenha sido experimentado por utilizadores externos ao projecto.
Tambm de salientar que quanto mais cedo se receberem opinies de outras
pessoas, mais o projecto poder evoluir e mais rpida poder ser essa evoluo. As-
sim, durante o projecto de design, muito importante receber pareceres externos,
mesmo que eles cheguem de forma informal, porque para o designer qualquer p-
gina e/ou processo far, partida, sentido, mas para outra pessoa pode no fazer. O
simples perguntar a algum se acha que funciona pode ser muito eficaz, eliminando
grande parte dos potenciais problemas e, aqui, a multidisciplinaridade da equipa de
trabalho uma mais valia para o projecto. Uma equipa, constituda por criadores,
programadores e clientes, poder discutir no seu interior as funcionalidades e as so-
lues equacionadas, podendo desde logo ter em considerao mais que um cenrio
e diferentes opinies.
Nesta fase do processo de design tambm se recorre muitas vezes prototipa-
gem em papel para testar os primeiros esboos da plataforma. Esta apenas foi usada
entre os elementos da equipa de design, na tentativa de chegar rapidamente a solu-
es passveis de implementao.
Os testes informais so essenciais em qualquer fase do projecto, pelo que devem
continuar nas fases seguintes do projecto. O designer no um ser perfeito que tem
a capacidade plena de desenvolver produtos perfeitos. Ele no sabe qual a resposta
mais acertada para um determinado problema e, por isso, precisa de receber opinies
exteriores.
O projecto foi sendo regularmente mostrado, de forma informal, a pessoas exte-
riores equipa e a futuros utilizadores, o que foi particularmente til para encontrar
problemas na realizao de tarefas especficas, ou nos termos empregues. Por exem-
plo, na pgina de configurao do canal, era pedido ao utilizador que introduzisse a
URL desejada, este campo obrigou uma utilizadora a perguntar o que deveria colocar
na URL. Esta pergunta levou-nos a substituir URL por http://tv.up.pt/channels/,
seguido de um campo de texto, substituindo-se uma simples legenda por uma pis-
ta para o preenchimento do campo, que indicia a sua funcionalidade e muito mais
3 Caso de Estudo 47
explcita que uma legenda. Para ns o termo era imediato, mas a maior parte do utili-
zadores provavelmente teria dificuldade em o perceber.
Alm desta avaliao externa, a avaliao internapelos vrios elementos da
equipatambm foi essencial para encontrar erros e dificuldades. Numa tentativa de
simplificar o processo de insero de vdeos a informao necessria foi reduzida ao
mnimo possvel e, depois do processo de carregamento ter terminado, o utilizador
era redireccionado para a sua pgina de perfil. Neste caso, foi-nos salientado que, por
vezes, o utilizador podia querer preencher mais informao e que era obrigado a per-
correr um grande nmero de passos at o conseguir fazer. O problema foi resolvido
redireccionando o utilizador, logo aps a insero, para a prpria pgina de edio do
vdeo acabado de criar. A reviso de outros elementos, como botes de edio dos blo-
gues, que se podiam tornar confusos para o utilizador, da informao disponibilizada
ou mesmo da sua organizao, s foi possvel atravs de um trabalho de equipa em
que os elementos que questionavam as opes uns dos outros, com o objectivo de que
a interface resultasse o mais usvel possvel.
3.3.2.4 Prottipo funcional

Ao longo desta segunda fase procura-se construir um prottipo funcional do stio, ou
de partes e processos do stio, que permita uma compreenso do que ser o objecto
real. Este prottipo, que no precisa de compreender todas as funcionalidades de um
stio completo, permitir comparar as diferentes partes do projecto, encontrar incon-
gruncias e discordncias entre elas.
O final da segunda fase foi-se confundindo com o incio da terceira fase, e en-
quanto alguns processos ainda estavam a ser desenhados, outros estavam j a ser
implementados. Esta fase no se concluiu portanto com um prottipo funcional, est
sim a concluir-se com o conjunto de processos e layouts necessrios para que o portal
possa ser utilizado por todos.
3.3.3 Implementao
Ao longo da terceira fase do projecto constri-se do objecto real, programando-se to-

dos os processos da interaco. Durante esta fase a usabilidade levada a cabo atravs
de (mais) testes com utilizadores e atravs de uma verificao geral das funcionalida-
des do stio.
3.3.3.1 Alguns testes simples

Todos os processos e linguagens utilizadas devem ser verificados e, alguns, podem s-
lo atravs de alguns testes simples. Por exemplo, no livro The Design of Sites, Van Duyne
et al. referem uma lista com alguns testes simples que devem ser realizados durante
esta a fase:
1) Verificar se o stio tem todas as funcionalidades estipuladas anteriormente e se

estas esto implementadas de forma correcta;
2) Verificar se as pginas so compatveis com os vrios navegadores, inclusive
com navegadores de texto, como o Lynx67, j que estes so mais semelhantes aos
que so usados pelos invisuais;
3) Verificar se as pginas podem ser visualizadas em ecrs de resolues diferentes;
4) Verificar se as pginas so fornecidas em tempo aceitvel, numa ligao mais lenta;
5) Testar o stio por vrias pessoas em simultneocentenas ou milhares, se pos-
svelpara saber se ele continua a funcionar correctamente;
6) Corrigir erros gramaticais ou textuais.
James Kalbach, em Designing Web Navigation, refere mais alguns:
7) Desligar as imagens e ver se os atributos alt so usados de forma consistente;

8) Alterar o tamanho das fontes e ver se o stio ainda usvel;
9) Desligar as cores, ou imprimir em escalas de cinzento, para determinar se o
contraste suficientetambm existem algumas ferramentas online que o
permitem fazer, como Colorblind Web Page Filter68, Vischeck69 ou Colour Contrast
Check70;
10) Navegar no stio usando apenas o teclado, para ter a certeza que todas as reas
podem ser acedidas sem recorrer a um dispositivo apontador;
11) Verificar se a informao apresentada de forma lgica, por exemplo, quando
vista sem folhas de estilo.
67 http://www.delorie.com/web/lynxview.html
68 http://colorfilter.wickline.org
69 http://vischeck.com
70 http://snook.ca/technical/colour_contrast/colour.html
3 Caso de Estudo 49
Outros autores referem mais quatro:
12) Verificar as transcries dos contedos audiovisuais;

13) Verificar se os formulrios podem ser acedidos atravs de um navegador no vi-
sual, ou atravs de uma navegao por teclado;
14) Validar os documentos XHTML e CSS.
O cumprimento destes 14 passos simples permitir a correco de erros que po-

dem ser desfavorveis para o stio e uma potencial causa de perda de utilizadores.
Como foi referido anteriormente a ferramenta em estudo ainda se encontra nesta
terceira faseimplementao, pelo que nem todos os testes rpidos aqui referidos
foram j realizados. De seguida explico porque que alguns ainda no foram feitos, e
quais as concluses possveis com os testes j realizados.
1) As funcionalidades ainda no se encontram todas implementadas, por exemplo

a pesquisa ainda no est funcional.
2) O stio ainda no compatvel com Internet Explorer 6, porque este suporta as
CSS de forma deficiente; as folhas de estilo esto a ser corrigidas para que o stio
possa funcionar igualmente bem em todos os navegadores.
3) O stio est optimizado para ecr de resolues superiores a 1024 x 768 px, uma vez
que esta a largura mais comum de acesso Web em computadores pessoais
de salientar que diferentes dispositivos de acesso tero formataes distintas.
4 e 5) No foram testados porque o portal ainda no se encontra no servidor final.
6) O stio encontra-se numa fase de correco do texto utilizado, mas como o portal
ser alimentado pela comunidade, ser impossvel garantir uma correco gra-
matical e textual completa.
7) Tal como no ponto anterior, podemos exigir que o utilizador introduza descri-
es das imagens, mas a sua relevncia nunca poder ser assegurada.
8) O layout do stio e as fontes foram configuradas em tamanhos relativos e sempre
em funo do tamanho do texto; desse modo a usabilidade do stio no ser pos-
ta em causa aquando do redimensionamento do texto.
9) O stio foi verificado utilizando a ferramenta Vischeck, em todos os modos dispo-
nveis, e a informao permaneceu sempre visvel e legvel.
10) Uma navegao por teclado possibilita o acesso a todas as funcionalidades
disponibilizadas.
11) A estrutura da informao foi pensada partida de forma a poder ser correcta-
mente apreendida, independentemente da forma visualizao.
12) Os contedos audiovisuais sero alimentados pelos utilizadores, sendo imposs-
vel exigir a incluso de transcries.
13) Os formulrios podem ser correctamente acedidos atravs do teclado, mas no
foram testados, at ao momento, num navegador no visual.
14) Os documentos XHTML e CSS foram validados, no tendo sido encontrado ne-
nhum erro nesta datadevo salientar que ambos os documentos continuam a
ser alterados, pelo que devero que ser novamente verificados aquando da fina-
lizao do projecto.
3.3.3.2 Testes de Usabilidade

Durante a implementao essencial a realizao de testes de usabilidade com utiliza-
dores reais, porque, em ltima instncia, apenas eles podero validar a qualidade do
sistema. Apenas um utilizador que desconhea completamente o stio e que o utilize
tendo em vista a realizao de determinada tarefa que poder dizer qual o seu grau
de usabilidade.
A realizao destes testes e as suas concluses so discutidas na prxima seco
deste captulo. Mas importante referir que, alm desses testes, cerca de 15 utilizadores
reais, exteriores ao projecto e j registados no stio, tm vindo a utilizar regularmente
a verso Alfa da plataforma. Esses utilizadores mantm-nos informados da sua inte-
raco, enviando as suas apreciaes, dificuldades e problemas, bem como relatrios
dos bugs que possam identificar.
3.3.4 Ps-implementao
Aps o lanamento do stio ele deve continuar a ser monitorizado para que eventuais
erros possam ser corrigidos, novas solues possam ser implementadas, novos pro-
blemas sejam identificados e novas funcionalidades sejam desenvolvidas tendo em
vista a constante melhoria do sistema.
Nesta fase (1) fazem-se pequenas alteraes ao cdigo com a finalidade de cor-
rigir eventuais bugs, (2) verificam-se os novos contedos inseridos para evitar erros,
hiperligaes para pginas que no existem, ou pginas que no cumpram as normas,
(3) recolhem-se nveis de satisfao e usabilidade e (4) actualizam-se as perguntas fre-
quentesFAQ (Frequently Asked Questions). Estes quatro pontos so essenciais para
3 Caso de Estudo 51
melhorar (ou manter) o nvel de usabilidade do stio, porque evitam erros e orientam
o utilizador, melhorando a interaco.
Alm destes quatro pontos (5) essencial fazer cpias de segurana para evitar
a perda de informao e (6) manter dirios do servidorserver logsque mostram a
provenincia dos visitantes, quais os termos que utilizam na pesquisa e o que estavam
a fazer no stio. Estes dados sero essenciais para um novo design e de extrema rele-
vncia para a definio do novo projecto.
Van Duyne et al. afirmam que esta fase provavelmente o aspecto mais negli-
genciado do design para a Web71 porque a mais longa e, consequentemente, a mais
cara72.
O projecto ainda no chegou a esta fase, e por isso no posso falar dela. Parece-
me, no entanto, importante salientar a sua relevncia para qualquer projecto, porque
melhorar, ou pelo menos manter, nveis de usabilidade e acessibilidade ser essencial
para que qualquer projecto possa sobreviver, o que ser, em ltima anlise, a real pro-
va do seu sucesso.
3.3.5 Concluso
Ao longo das quatro fases necessrio ter em considerao que, como referem Van
Duyne et al. (2007), nenhuma equipa de design perfeita. O processo de design um
processo iterativo em 3 passos: Design, Prototipagem e Avaliao, e estes trs passos
constituem um loop contnuo. importante a utilizao deste processo iterativo por-
que ele: 1) permitir encontrar problemas enquanto estes no aumentam custos e so
fceis de corrigir; 2) assegurar que o stio ir ter todas as funcionalidades que o utili-
zador espera e necessita; 3) assegurar que essas funcionalidades so implementadas
de uma forma que o utilizador as poder usar.
71 [Implementation] is perhaps the most neglected aspect of Web site design. (van duyne [et al.], 2007)
67 [Implementation] is the longest part of the design cycle [and] consequently, it is also the most expensi-
ve. (van duyne [et al.], 2007)
3.4 Realizao de testes
3.4.1 Definio dos testes
Seguindo a bibliografia, deveria ter sido escolhido um grupo entre 3 e 5 utilizadores,

no entanto devido a atrasos e constrangimentos do projecto da tv.up, s foi possvel
realizar um teste at data. O projecto ainda se encontra actualmente na fase de im-
plementao e os testes iro continuar ao longo desta fase.
3.4.1.1 Objectivos
O objectivo da realizao do teste era avaliar os vrios processos chave do stio. O teste
consistia, por isso, na realizao de 7 tarefas:
1: Criar uma conta;

2: Configurar o perfil de utilizador;
3: Inserir vdeos;
4: Criar uma playlist, com vdeos dele ou de outro utilizador;
5: Criar um canal e adicionar-lhe contedos;
6: Criar um blogue;
7: Criar posts no blogue.
O sucesso de cada tarefa estava dependente da rapidez com ela era executada e
se o era de todo.
3.4.1.2 Fase de realizao

O teste realizou-se na fase de implementao do projecto, depois dos referidos proces-
sos estarem implementados, mas antes do projecto estar concludo; existiam seces
do stio ainda sem contedos e funcionalidades, como a pesquisa e a ajuda, que ainda
no estavam implementadas.
3.4.1.3 Processo utilizado na realizao

Foi mantida uma conversa introdutria com o utilizador apresentado a plataforma e
explicando qual o papel dele, salientado que qualquer erro no seria culpa dele mas
sim do stio, e que esses erros apenas iriam ajudar na construo de um projecto me-
lhor. Nesta conversa o utilizador foi aconselhado a pensar em voz alta para ajudar na
compreenso do que estava a fazer e a pensar.
3 Caso de Estudo 53
De seguida foi-lhe colocado um conjunto de questes simples sobre os seus

hbitos e passou-se ao teste propriamente dito, em que lhe foram dadas tarefas a
serem executadas. Durante o tempo de cada teste esteve a correr uma aplicao
Silverbackno computador que gravava o ecr e que utilizava a webcam para gravar o
utilizadoras suas expresses faciais e o que ele dizia.
Numa fase posterior ao teste foi feito um pequeno conjunto de questes ten-
tando perceber como foi a interaco com o stio, que outras funcionalidades ele
esperaria encontrar numa plataforma semelhante e quais os maiores problemas que
encontrou aquando do teste.
3.4.1.4 Caracterizao do utilizador

O utilizador escolhido tinha 26 anos e um utilizador habitual da Web, utilizando-a
para pesquisas, para comunicar com outras pessoas e como forma de divertimento.
Este utilizador no foi escolhido por pertencer a um determinado grupo tipo, mas sim
devido disponibilidade que mostrou. Na verdade, poderia ter sido utilizado qual-
quer outro utilizador habitual da Web.
3.4.2 Anlise e concluses
Remember: Its almost never too late to challenge basic assumptions. Rethinking
the basics doesnt necessarily mean changing everything, and it often turns out
that the solution to the problem is simpler than youve feared.
No captulo anterior, foi referido que testar apenas um utilizador era mais vantajo-
so para o projecto que no testar nenhum. O teste de usabilidade que foi realizado
permitiu encontrar problemas que para a equipa no existiam, e comprovou a sua
importncia enquanto elemento do processo de design.
A primeira tarefa do utilizador era registar-se no stio. Este processo foi com-
pletado com sucesso, no entanto, o utilizador comeou por introduzir os dados no
formulrio de autenticao, apenas encontrando o boto de registo momentos antes
de submeter o formulrioAh, tem ali um boto de registe-se!e por isso mudou
de direco. A dificuldade em ver partida o boto de registo leva-nos a concluso que
deve ser dado mais nfase a este boto no layout da pgina, para que no passe nunca
despercebido ao utilizador.
Depois de criada a conta, o utilizador comeou imediatamente a alterar o seu

perfil. Aqui, e apesar de todos os campos poderem ser acedidos atravs de uma nave-
gao por teclado, a inexistncia de :focus no permitiu que o utilizador o percebesse
e sentiu-se obrigado a utilizar o rato para navegar entre campos. Este acto prova-nos
que esse comportamento (:focus) essencial para que a interface possa ser compreen-
dida correctamente e dever ser includo.
O processo testado de seguida foi o carregamento de vdeos, em que a nica dvi-
da que surgiu foi o termo embeber, nas opes de partilha. Aps o carregamento do
vdeo o utilizador recebeu a informao de que o vdeo tinha sido inserido com suces-
so, no entanto, ele no o conseguia ver na sua pgina de vdeos o que o deixou bastante
confuso. Somente depois de percorrer vrias pginas do stio que encontrou, na
pgina de perfil, a informao que o vdeo estava com problemas de processamento.
Este processo no foi evidente para o utilizador que se sentiu perdido e sem perceber
porque que no sido informado partida que tal tinha sucedido. Este processo, ter
por isso que ser revisto e o utilizador dever ser informado mais cedo desse problema;
a mesma informao deve tambm estar disponvel na pgina de edio do vdeo
local para onde o utilizador direccionado aps a insero, e na pgina de vdeos do
utilizadorporque l que o utilizador o espera encontrar.
O usurio teve dificuldade em criar uma playlist, porque esperava que na sua
pgina pessoal de playlists houvesse a opo directa para criar uma nova. No entanto,
depois de percorrer vrias pginas conseguiu encontrar, na pgina de vdeo, a opo
pretendida. De qualquer forma, podemos concluir que para um utilizador no expe-
riente, seria mais vantajoso se houvesse uma opo explcita para criar uma playlist,
semelhana do que acontece noutros processos idnticos.
De seguida o utilizador partiu para a criao de um canal, e referiu a inexistncia
de uma opo para verificar a disponibilidade da URL desejada, mas no teve qualquer
dificuldade em adicionar contedos a esse canal.
Os ltimos processos a serem testados foram a criao de um blogue e a insero
de posts, o primeiro decorreu sem percalos. O segundo levantou alguns problemas
quanto aos termos utilizados Guardar, Guardar e continuar a editar, Publicar,
porque o utilizador nem sequer os leu e deduziu que o primeiro, Guardar iria pu-
blicar o post.
Todas as tarefas previamente estabelecidas para o teste foram desempenhadas,
mas o utilizador assumiu a responsabilidade pela ordem de realizao, comentando
logo aps a finalizao de cada tarefa agora vou configurar o perfil, agora tenho que
3 Caso de Estudo 55
colocar um vdeo, etc. A minha posio foi de mera observadora, esclarecendo ape-
nas dvidas relacionadas com o sistema operativo utilizadoMac OS 10.5.5.
A navegao livre e com objectivos reais permitiu tambm perceber que o
utilizador no encontrou dificuldades em navegar, que o processo de adicionar aos
favoritose que no fazia parte das tarefas iniciaisno causou problemas ao uti-
lizador. Um ponto assinalado pelo utilizador foi a impossibilidade de alterar um
comentrio, pelo menos por um curto espao de tempo, porque depois da submisso
o utilizador poderia encontrar um gralha que quisesse ver corrigida.
A realizao deste teste possibilitou a descoberta de vrios pontos que devem ser
repensados no projecto porque, como vimos, criaram dificuldades na interaco do
utilizador com o stio. Apesar de no podermos garantir a 100% que outros utilizado-
res experimentariam as mesmas dificuldades, estes pontos sero alterados para que a
interaco no saia defraudada.
3.5 Sntese
A anlise de um caso real provou ser de extrema relevncia, no s enquanto questio-
namento de opes tomadas ao longo do processo de design, mas tambm enquanto
factor de melhoria do projecto. Esta anlise permitiu encontrar problemas e, talvez,
solues para algumas das possveis dificuldades com que um utilizador se poder
deparar aquando da interaco.
O estudo de um caso real ajuda a comprovar afirmaes dos captulos anteriores:
que uma interface no perfeita, que o designer no sabe sempre qual a melhor op-
o, e que apenas os utilizadores sero capazes de fazer uma apreciao real do nvel
de usabilidade de uma plataforma. Este projecto da tv.up e o processo de design que
nele foi utilizado ajuda-nos a perceber tambm a importncia da colaborao num
projecto de design para a Web, no s entre elementos da equipa, mas tambm entre
estes e utilizadores exteriores.
No captulo seguinte tentaremos inferir e sistematizar um conjunto de boas
prticas que os designers podero seguir, numa tentativa de simplificar o processo
de design e enquanto possveis solues para resolver problemas especficos de casos
reais.
4 Boas Prticas 57
4 Boas Prticas
Can we generalize common solutions to apply to similar problems?

Alan Cooper, Robert Reimann & David Cronin, About Face 3: The Essentials of Interaction
Design, 2007
Aps um estudo dos autores relevantes na rea da usabilidade e da acessibilidade na

Web e depois da realizao de alguns testes, com a finalidade de perceber como que
os utilizadores olham para uma ferramenta pela primeira vez e quais os problemas
com que se deparam, pareceu-me importante sistematizar algumas das concluses a
que cheguei, e algumas das formas de resolver problemas com que, enquanto desig-
ners, nos podemos deparar recorrentemente.
Para isso, parto para a sistematizao de algumas boas prticas que podem ser
utilizadas no projecto de design. Esta sistematizao no pretende ser nica nem
aglomerar em si somente solues novas ou inovadoras, e os crditos de cada resposta
a um determinado problema esto distribudos entre todos os que j escreveram sobre
o assunto. Como menciona Brad Appleton os autores de padres no necessitam de
ser os inventores das solues que documentam73.
73 Pattern writers do not need to be the original inventor or discoverer of the solutions that they docu-
ment. (appleton, 2000)
4.1 Forma
A realizao deste pequeno lxico tenta ser o mais simples possvel, recorrendo para
isso ideia de padres do design, um conceito inicialmente desenvolvido por Chris-
topher Alexander em The Timeless Way of Building (1979) e A Pattern Language: Towns,
Buildings, Construction (1977).
Os padres do design capturam solues que se desenvolveram e evoluram ao
longo do tempo74 (gamma [et al.]). Van Duyne et al. refere que um padro do design
uma soluo genrica para um problema recorrente, e pode ser aplicado a qualquer
rea75. Dessa forma os designers no tero sempre que resolver cada problema desde o
incio, pelo contrrio, os padres ajudam o designer a reutilizar designs bem sucedi-
dos, baseando os novos designs em experincias anteriores76 (gamma[et al.]).
4.2 Estrutura
Posteriormente, e com base no trabalho de Alexander, foram desenvolvidos vrios

projectos que reutilizam a estrutura de padres como forma de propor solues
para problemas do design. Entre as linguagens desenvolvidas devo salientar algu-
mas que influenciaram directamente este trabalho: A Pattern Approach to Interaction
Design (borchers, 2001) a primeira que conheo relacionada com o design de inte-
raco, Designing Interfaces Patterns for Effective Interaction Design (tidwell, 2005),
74 Design patterns capture solutions that have developed and evolved over time. (gamma [et al.], 1998)
75 Simply put, a design pattern is a generic solution to a commonly recurring problem, whether for sof-
tware, building, landscaping, or Web design. (van duyne [et al.], 2007)
76 They help designers reuse successful designs by basing new designs on prior experience. (gamma [et
al.], 1998)
4 Boas Prticas 59
The design of sites: patterns for creating winning websites (van duyne [et al.], 2007) e al-
gumas referncias online como Welie.com, Patterns in Interaction Design77, Yahoo! Design
Pattern Library78, UI Patterns, User Interface Design Pattern Library79 e Information Design
Patterns80.
Alm destas linguagem tambm de salientar a que est a ser desenvolvida pe-
los alunos da cadeira de Interaco, na Faculdade de Belas Artes da Universidade do
Porto (FBAUP), que permitiu aos alunos da cadeira conhecer o conceito de linguagens
de padres, e que o utilizassem no estudo concreto de problemas relacionados com o
Design da Interaco.
As linguagens acima referidas tm em comum parte da estrutura, todas elas

comeam por dar um nome a cada padro, de seguida definem o problema, suge-
rem possveis solues e culminam relacionando esses padres com outros; como
refere Alexander cada padro uma regra em trs partes que relaciona um contex-
to, um problema e uma soluo81 (citado em coplien). Esta estrutura permite a fcil
identificao do problema e das suas possveis respostas, e permite identificar facil-
mente outros problemas relacionados ou outras respostas que podero ser teis para
os solucionar.
A vantagem deste tipo de estrutura , como menciona Alexander, o facto de-
lespadresserem abstractos e independentes e, por isso, poderem ser usados
para criar no um, mas uma infinidade de designs, todos eles livres combinaes do
mesmo conjunto de padres82.
77 http://www.welie.com
78 http://developer.yahoo.com/ypatterns
79 http://ui-patterns.com
80 http://www.infodesignpatterns.com
81 Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and
a solution. (coplien)
82 [] because they [padres] are abstract and independent, you can use them to create not just one design
but an infinite variety of designs, all of them free combinations of the same set of patterns. (alexander,
1971)
4.3 Universo de validade
necessrio ter em conta que nenhuma das solues aqui proposta tenta ser nica
ou absoluta, como menciona James Kalbach raramente existe uma nica soluo
perfeita83.
Cada uma das possveis solues aqui apresentada existe num contexto prprio
e varivel, podendo ser aplicada a quase todo o tipo de stios na Web, como Escrever
para a Web, Terminologia ou Legibilidade, ou tendo um universo de aco bas-
tante reduzido, como Tag clouds ou Drag-and-drop.
Todas as solues aqui apresentadas podem ser aplicadas num projecto seme-
lhante ao caso de estudo apresentado. Um projecto que pretende ser sustentado pela
informao construda por diversos utilizadores, e que pretende criar relaes entre
eles e os seus contedos. Mas na sua maioria podem ser aplicados a qualquer projecto
de design para a Web e alguns a qualquer projecto de interaco. Esta universalida-
de assente na no procura de algo universal, ou nico, foi uma das mais valias que
encontrei neste formato de apresentao das concluses tiradas a partir do estudo
desenvolvido.
83 [] rarely is there a single, optimal solution. (kalbach, 2007)

4 Boas Prticas 61
4.4 Linguagem de Padres
4.4.1 Escolha dos termos a utilizar
Contexto:
Na Web as pessoas no tm a preocupao de ler ou compreender todas as palavras,
elas apenas pesquisam rapidamente na pgina, atravs de uma leitura rpida, algo
que parea corresponder ao que procuram.
Problema:
Como refere Kalbach, se as pessoas concordassem sempre nos termos utilizados, a
palavra do utilizador seria igual palavra do designer e palavra do sistema; e o que o
utilizador escrevia ou procurava seria mutuamente entendido. Infelizmente as pesso-
as muitas vezes esto em desacordo nas palavras que utilizam84.
A Web um sistema navegacional85 (nielsen), por isso essencial que o uti-
lizador possa facilmente encontrar as opes de navegao que deseja, e que estas
correspondam as suas necessidades e exigncias. A escolha correcta dos termos a
utilizar no stio essencial para a criao de uma navegao eficaz e facilmente iden-
tificvel pelo utilizador.
Soluo:
Para que os termos utilizados sejam correctamente interpretados pelos utilizadores
eles:
Devem ser adequados linguagem do utilizador;

No devem ser termos vagos, porque apenas iriam confundir o utilizador;
No devem ser abreviaturas, j que o utilizador pode no as reconhecer;
No devem ser termos tcnicos ou acrnimos, a no ser que o seu significado
seja explicado;
84 If everyone always agreed on what to call things, the users word would be the designers word would
be the systems word, and what the user typed or pointed to would be mutually understood. Unfortunately,
people often disagree on the words they use for things. (kalbach, 2007)
85 The Web is a navigational system (nielsen, 2000)

No devem ser termos inventados, porque os utilizadores no compreendero o

seu significado;
Devem ser verificados ao nvel da ortografia e gramtica, pois a existncia de
erros apenas ajuda a descredibilizar o stio;
Devem ser termos que possam facilmente corresponder ao que o utilizador est
a procurarpode, por exemplo, ser til verificar quais os termos que costumam
ser usados em motores de busca ou numa busca local.
Referncias:
A terminologia utilizada ser essencial para que a escrita seja compreensvel
Escrever para a Web e os ttulos sejam descritivos para o utilizadorTtulos
HTML descritivos.
4 Boas Prticas 63
4.4.2 Escalabilidade
Contexto:
A dimenso de um stio , muitas vezes, alterada com o passar do tempo, comeando
por ser um stio de dimenses reduzidas e tornando-se numa estrutura com milhares
de pginas.
Problema:
A estrutura de um stio geralmente desenhada com base no tamanho actual do pro-
jecto e, muitas vezes, esquecido que ele poder crescer e poder ser necessrio incluir
mais seces na navegao principal, ou poder ser necessrio reutilizar o mesmo de-
sign numa outra lngua, que possua termos maiores.
Quando se est a decidir o design de um projecto cuja estrutura no est fechada
e/ou quando se pretende que ele possa crescer indefinidamente deve ser utilizado um
layout que possa crescer e transformar-se.
Soluo:
A soluo para que um stio possa crescer livremente passa por:
Utilizar uma interface de estrutura flexvel que permita expandir ou diminuir

funcionalidades;
Utilizar um layout flexvel que tem em conta o redimensionamento e a dimenso
dos contedos, adaptando-se a eles.
Referncias:
Este padro deve ser utilizado em conjunto com Layout flexvel, para que o sistema
seja o mais adaptvel possvel ao futuro e s preferncias do utilizador.
4.4.3 Traduo/simetria dos contedos
Contexto:
A Web um espao universal e o designer desconhece quem ir aceder a um determi-
nado contedo, as suas possveis limitaes, ou o dispositivo que ser utilizado para
o fazer.
Problema:
Um utilizador pode no ser capaz de utilizar o stio atravs de um processo visual,
mas como qualquer outro utilizador tem o direito de aceder a todos os contedos. Por
isso a insero de contedos no textuais num stio deve exigir mais que a simples
incluso de uma imagem, vdeo, etc. Ela deve exigir tambm que a insero destes
contedos seja pensada ao nvel da acessibilidade e usabilidade, equacionando, por
exemplo, possveis problemas para invisuais ou surdos.
Qualquer utilizador, independentemente de possveis limitaes ou do disposi-
tivo utilizado, deve beneficiar do acesso mesma informao.
Soluo:
A soluo para tornar os contedos universais passa por certificar que todos os
contedos podem ser acedidos directamente, ou atravs de uma traduo, indepen-
dentemente de qualquer constrangimento.
Certificar que todas as imagens possuem uma descrio textual, se forem mera-
mente decorativas essa descrio deve ser vazia;
Esta descrio deve ser colocada no atributo alt, que deve ser breve, no ul-
trapassando as 8/10 palavras86;
Caso seja demasiado grande pode ser usado o atributo longdesc, de des-
cries longas, ou podem ser compostas descries no corpo do texto e que
transmitam a mesma informao (por exemplo no caso de grficos);
Devem ser disponibilizadas transcries de ficheiros udio ou de ficheiros visu-
ais, se estes existirem;
86 ALT text should be brief and to the point, typically no more than 8 to 10 words. (nielsen, 2000)
4 Boas Prticas 65
Devem ser disponibilizadas verses legendadas dos contedos audiovisuais;

Deve ser sempre identificada a lngua utilizada em cada contedo, porque se um
utilizador visual pode reconhecer a lngua apresentada, um sintetizador de voz
necessitar de receber essa indicao para saber como pronunciar correctamente
as palavras.
Referncias:
O padro Contedos audiovisuais pode ser utilizado em complemento deste, para
que a experincia do utilizador seja positiva.
4.4.4 Assinalar as opes do utilizador
Contexto:
Na Web um utilizador faz vrias escolhas que iro influenciar o seu percurso. im-
portante que ele consiga perceber esse percurso e que a navegao consiga assinalar
a sua posio relativa totalidade da Web e estrutura do stio. Como refere Bush,
o utilizador cria um rasto dos seus interesses na imensido de materiais que lhe so
disponibilizados87.
Problema:
Como ajudar o utilizador a orientar-se no enorme espao que a Web?
Um utilizador pode perder-se na estrutura navegacional de um stio, ou pode ir parar
a qualquer stio atravs de um motor de pesquisa no sabendo onde se encontra.
importante que a navegao ajude o utilizador a situar-se na estrutura do stio, res-
pondendo a trs questes essenciais: Onde estou? Onde estive? e Onde posso ir?
Soluo:
Ajudar a orientao do utilizador deve passar por:
Marcar o local actual do utilizador na estrutura do stio;

Assinalar as opes que ele ter feito para l chegar;
Assinalar quais os locais onde o utilizador j esteve.
Referncias:
Esta orientao pode ser facilitada atravs do uso de reas clicveis, permitindo o
utilizador identificar mais facilmente outros locais onde j esteve, e atravs da Codi-
ficao cromtica, permitindo que ele se oriente na estrutura do stio em questo.
87 He [user] builds a trail of his interest through the maze of materials available to him. (bush, 1945)
4 Boas Prticas 67
4.4.5 reas clicveis
Contexto:
A interaco bsica carregar nas hiperligaes para navegar num grande espao de
informao88.
Problema:
A hiperligao o elemento base da Web, o elemento que permite saltar de uma p-
gina para a outra, ligando peas de contedo. A navegao a organizao sistemtica
de hiperligaes e que proporciona o acesso informao, ocupando um papel central
na experincia da Web. Por isso, essencial que os utilizadores percebam rapidamente
o que pode ser operado atravs de um clique e importante que o faam sem terem
que carregar em todos os elementos. Quando os utilizadores no sabem com que ele-
mentos podem interagir, a sua tarefa ser dificultada porque tero que adivinhar89
(nielsen).
Soluo:
Na procura de assinalar claramente o que pode ser interagido atravs do rato deve-se:
Assinalar de forma coerente em todo o stio o que clicvel, atribuindo compor-

tamentos semelhantes a todas as hiperligaes;
Aquando do :hoverrato sobre a ligaoe do :focusligao seleccionada
atravs do tecladoformatar a ligao de forma diferente;
Em ligaes textuais, utilizar rtulos descritivos e com significado, evitando so-
lues genricas como Carregue Aqui;
Certificar que o texto utilizado como ligao faz sentido quando retirado do seu
contexto. Este texto ser usado como elemento de navegao por utilizadores
invisuais que saltam entre ligaes procura de algo que lhes parea relevante.
Este texto tambm ser de extrema relevncia para os motores de busca90;
88 The basic user interaction is to click on hypertext links in order to move around a huge information
space. (nielsen, 2000a)
89 [] when people dont know whats clickable on site, they must work harder and guess. (nielsen [et
al.], 2006)
90 Search engines often place extra emphasis on the text used to describe a link to a page. (nielsen [et
al.], 2006)
Hiperligaes com descries maiores podem melhorar a acessibilidade mas

desaconselhado o uso de descries demasiado grandes;
As ligaes devem ser assinaladas de forma evidente, evitando o uso de texto
azul ou de sublinhados para algo que no seja clicvel;
Assinalar de forma diferente as ligaes internasque mantm o utilizador no
stioe as ligaes externasque direccionam o utilizador para outro espao
na Web;
Se a funo da hiperligao for permitir que um utilizador descarregue um fi-
cheiro, o seu tamanho e formato devem ser apresentados;
Ter em mente a lei de Fitts que nos diz que a eficcia de um utilizador aquando
da interaco via dispositivo apontador, varia de forma inversamente propor-
cional distncia que o rato ter que percorrer e ao tamanho do alvo, e por isso:
Evitar ligaes em corpo de texto demasiado reduzido ou que usam imagens
pequenas porque estas so demasiado difceis de activar com o rato;
Evitar compor elementos que sero operados pelo rato em locais que obri-
guem percorrer uma grande distncia;
Ter em considerao a lei de Hick que refere que quanto mais escolhas forem dis-
ponibilizadas ao utilizador mais tempo ele demorar a chegar a uma concluso.
Por isso:
Simplificar o nmero de escolhas, simplificando o processo para o utilizador.
Referncias:
A correcta utilizao de reas clicveis possibilitar ao utilizador uma navegao
eficiente e rpida.
4 Boas Prticas 69
4.4.6 Escolhas tecnolgicas
Contexto:
A Web est em constnuo movimento e constantemente so desenvolvidas novas tec-
nologias de acesso e publicao de contedos na Web.
Problema:
Actualmente existem vrias tecnologias que permitem criar contedos para a Web, e as
preferncias pessoais de cada designer variam. O mais importante que a tecnologia per-
mita flexibilidade e compatibilidade de ligaes e de dispositivosactuais e futuros.
Soluo:
aconselhada a utilizao de linguagens do Web Standards Project como forma
a melhorar a compatibilidade com as tecnologias de acesso Internet;
aconselhada uma separao entre estrutura e apresentao como forma a be-
neficiar a usabilidade:
A utilizao de HTML 4.1 ou XHTML 1.0 correcto como forma de marcao
semntica ir tornar os contedos mais legveis por utilizadores que no
utilizem um navegador visualisto , que utilizem navegadores de texto, lei-
tores de ecr, etc;
A utilizao de CSS como mtodo de apresentao ir tornar os contedos
mais versteis e compatveis com os diversos aparelhos de acesso Inter-
net, porque como refere Jim Thatcher as folhas de estilo so invisveis para a
acessibilidade91. A utilizao de folhas de estilo tambm permitir simplificar
mudanas que venham a ser necessrias, porque permite definir estilos dife-
rentes para meios diferentes (ecr, telemvel, impresso, etc.) e permite tornar
as pginas menos pesadas, exigindo menos tempo para serem descarregadas.
Referncias:
A utilizao de qualquer tecnologia deve ter em considerao padres como Layout
flexvel, Escalabilidade, Cores, Legibilidade e reas Clicveis para formataes
de layout; e padres como Saltar para o contedo, Manter o utilizador informado,
S teclado e Estruturao dos contedos para implementao de funcionalidades.
91 CSS is transparent to accessibility (thatcher [et al.], 2006)

4.4.7 Saltar para o contedo
Contexto:
A Web enquanto espao navegacional pode ser navegada atravs de diferentes dis-
positivos, que interagem com o sistema de forma diferente, exigindo, por vezes,
comportamentos distintos.
Problema:
A navegao global, presente em todas as pginas e normalmente no incio da estru-
tura, causa um problema a utilizadores que utilizam leitores de ecr, porque os obriga
a ouvir em todas as pginas as mesmas opes. Um utilizador que prefira navegar por
teclado tambm ser obrigado a passar sempre por todas as opes, o que constituir
uma perda de tempo significativa.
Soluo:
A soluo para este problema passa pela insero de uma hiperligao que permita
saltar elementos de navegao persistentes e cuja leitura no seja obrigatria em to-
das as pginas, redireccionando o utilizador para os contedos.
Thactcher (2006) sugere-nos quatro formas de o fazer:
1. Colocar uma ligao em texto normal;

2. Colocar uma ligao como texto alt de uma imagem que no contm informa-
o (no vlido para uma navegao por teclado);
3. Utilizar uma ligao textual formatada para ser invisvel;
4. Utilizar CSS para revelar a ligao quando seleccionada atravs do teclado (:focus).
Ainda, e segundo um estudo realizado por Theofanos e Redish em 2003, o tex-

to apresentado como ligao, num stio em ingls, deve ser Skip to main content
porque ser o mais compreensvel para o utilizadorapenas metade dos utilizadores
testados sabia o que significava Skip Navigation, e porque Skip to main content
ser bem pronunciado pelo leitor de ecr. Em portugus podemos apresentar algo
como Saltar para o contedo.
Referncias:
Este padro deve ser utilizado aquando de uma correcta Estruturao dos contedos,
essencial para que o utilizador tenha ao seu dispor Mltiplas formas de navegao
e ser indispensvel para uma navegao por tecladoS teclado.
4 Boas Prticas 71
4.4.8 Manter o utilizador informado
Contexto:
Na Web, dependendo da velocidade de ligao e da tarefa pretendida, a durao dos
processos pode variar entre milsimas de segundos e horas.
Problema:
Os utilizadores gostam de respostas rpidas e gostam de ser informados que uma de-
terminada aco est a decorrer. Se o ecr fica parado eles assumem que a aplicao
deixou de funcionar. Por exemplo, em processos que exijam carregar informao
vdeos, imagens, etc, ou descarregar contedos pesados, o utilizador pode ter que
despender um longo tempo de espera e se no for informado que o processo ainda est
a decorrer ele depreender que o sistema parou. Utilizadores impacientes chegam a
abandonar os stios que no proporcionam uma reaco adequada, assumindo que o
sistema deixou de funcionar (nielsen)92.
Soluo:
Nos stios em que alguns processos podem demorar bastante tempo essencial for-
necer algum tipo de informao aos utilizadores, para que eles possam reconhecer
que a aplicao no crashou. Cada aco deve ter um efeito evidente e imediato para o
utilizador. Neste casos o stio deve:
Incluir indicadores de progresso ou de aco (no mnimo introduzir imagens

animadas que traduzam movimento). Jakob Nielsen diz-nos que qualquer pro-
cesso que demore mais de 10 segundos deve disponibilizar ao utilizador um
indicador de progresso, mostrando a percentagem j completa.
Ao informar o utilizador a sua impacincia ir diminuir e o tempo psicolgico

da aco parecer menor, porque poder ver o progresso e saber o que deve esperar.
92 Impatient users leave sites that dont provide adequate feedback, often assuming the site is down becau-
se the page appears frozen. (nielsen [et al.], 2006)
4.4.9 Mltiplas formas de disponibilizar a mesma informao
Contexto:
Diferentes utilizadores procuram informaes diferentes sobre o mesmo contedo, e
mesmo um nico utilizador pode querer ter acesso a diferentes informaes sobre o
mesmo contedo.
Problema:
Por vezes os mesmos contedos esto associados a mais que um tipo de informao
que pode ser relevante para o utilizador; por exemplo, o utilizador pode estar interes-
sado em procurar o contedo mais recente, ou aquele que foi mais votado.
Soluo:
Para que o utilizador possa navegar de forma a poder absorver o mximo de informa-
o o stio deve:
Possibilitar que os contedos sejam navegados de vrias formas, possibilitan-

do, por exemplo, que eles sejam organizados de acordo com diferentes tipos de
informao: organizao cronolgica, organizao alfabtica, organizao ba-
seada na popularidade ou no nmero de comentrios, etc.
Referncias:
Aquando da utilizao deste padro deve ser tida em conta a Terminologia utilizada
para cada tipo de informao que disponibilizada.
4 Boas Prticas 73
4.4.10 Codificao cromtica
Contexto:
A navegao num stio por vezes complexa, dificultando a orientao do utilizador.
A cor, utilizada nestes contextos, pode facilitar a orientao na estrutura global do
stio, informado o utilizador da seco em que se encontra.
Problema:
Como apresentar ao utilizador pistas visuais relativas sua posio na estrutura do
sistema?
A aplicao cromtica nas vrias seces do stio poder ajudar o utilizador a
orientar-se no sistema enquanto o dinamiza visualmente, mas no dever nunca ser
usado como nico elemento de orientao, j que nem todos os utilizadores vem as
cores da mesma forma.
Soluo:
Atribuir cores a cada uma das seces do stio, para facilitar o reconhecimento
rpido por parte do utilizador, e para isso:
Fazer com que essas cores sejam utilizadas nos elementos de cada seco;
Relacionar as cores navegao, identificando cada ligao com a cor atribu-
da a essa seco.
Referncias:
Ao utilizar este padro no pode ser esquecido que os utilizadores observam as cores
de forma diferenteCores. A codificao cromtica ser uma mais valia para que o
utilizador se consiga orientar no sistema, assinalando o local onde ele se encontra na
estrutura do stioAssinalar as opes do utilizador.
4.4.11 Ttulos HTML descritivos
Contexto:
Procurar pginas sobre um determinado tema em motores de busca, ou revisitar pgi-
nas previamente guardadas, faz parte do dia a dia de um utilizador da Web.
Problema:
Como permitir uma navegao fcil e eficaz numa listagem de ttulos?
Os ttulos das pginas HTML so usados como marcadores e como atalhos guardados
no computador. Eles so tambm utilizados no histrico do navegador, numa pgina
de resultados de um motor de pesquisa, e como elemento de navegao entre as vrias
abas, ou janelas, do navegador. Por isso, importante que estes ttulos possibilitem
uma escolha acertada por parte do utilizador.
Soluo:
A soluo para que os ttulos sejam eficazes passa por:
Dar ttulos diferentes a todas as pginas;

Utilizar ttulos descritivos e concisos, o texto deve fazer sentido quando visto
sozinho, ou em conjunto com outros;
Comear os ttulos de forma descritiva, se possvel com termos que podero cor-
responder s necessidades do utilizador quando ele procura uma pgina numa
listagem de ligaes;
Eliminar os artigos no incio dos ttulos;
Podem ser usados como breadcrumbs, mostrando onde se encontra a pgina na
estrutura do stio.
Referncias:
A Terminologia usada tambm ser essencial para que estes ttulos sejam correcta-
mente compreendidos pelos utilizadores.
4 Boas Prticas 75
4.4.12 Input previsto
Contexto:
Actualmente, um grande nmero dos processos que so realizados na Web dependem
do utilizador e da informao que ele coloca em locais destinados para tal.
Problema:
Como que pode ser simplificada a insero de contedos? Como que se pode mini-
mizar as diferenas nos contedos inseridos pelos diversos utilizadores?
O preenchimento de formulrios torna-se uma tarefa montona para o uti-
lizador, que tem que introduzir imensa informao. Por vezes, a introduo dessa
informao passa por colocar palavras-chave, locais ou outros, que pretendem ser
uma forma de criar relaes entre os vrios utilizadores, ou contedos, de um sistema
(por exemplo a colocao de tags para relacionar contedos, ou de locais geogrficos
para criar grupos de utilizadores). No entanto, um utilizador pode optar por no co-
locar uma cedilha, ou um acento, criando entradas diferentes, apesar de significarem
o mesmo.
Soluo:
medida que o utilizador vai introduzindo as letras devem ser sugeridas palavras
que j tenham sido inseridas, ou que fazem parte de uma base de dados previamen-
te carregada, e que comecem com as mesmas letras. Esta sugesto de outros termos
permitir, por um lado, simplificar a tarefa do utilizador e, por outro, uniformizar as
bases de dados, reduzindo o nmero de entradas duplicadas.
Referncias:
A utilizao deste padro ser essencial para a criao de Tags Clouds eficazes e
permitir simplificar o processo de introduo de contedos num formulrio
Simplificao de formulrios.
4.4.13 Visibilidade inicial
Contexto:
Os utilizadores tm alguma relutncia em fazer scroll, e mesmo quando o fazem no o
fazem muito. Por vezes, isso leva-os a abandonarem um stio que tinha a informao
que eles procuravam porque esta se encontrava fora da rea visvel do ecr e eles no
a encontraram.
Problema:
Como garantir que a informao necessria para o utilizador encontrada?
Um utilizador ir utilizar a Web na procura de respostas e com a esperana de encon-
trar o que precisa, por isso, importante que ele no tenha que procurar demasiado
aquilo que necessita; alis, a maioria dos utilizadores no o ir fazer, e ir simples-
mente abandonar o stio.
Soluo:
Para garantir que a informao mais importante encontrada pelo utilizador deve-se:
Fazer pginas relativamente curtas;

Certificar que os contedos mais importantes se encontram na rea visvel do
ecr, mesmo que o ecr seja mais pequeno;
Escrever de forma invertida, comeando com a concluso;
Informar o utilizador que existe mais informao depois do final do ecr e fazer
o utilizador querer saber o que est mais abaixo;
Se a informao for demasiado longa pode ser colocado um ndice na parte supe-
rior da pgina, indicando quais os pontos mais importantes.
Referncias:
A utilizao de outros padres como Legibilidade ou Escrever para a Web podem
ajudar a que a informao seja transmitida correctamente. Outro padro que pode
ajudar a organizao dos contedos Paginao.
4 Boas Prticas 77
4.4.14 Minimizar os erros
Problema:
A probabilidade de erro, em qualquer interface, muito grande, por isso, essencial
que o designer tente diminuir a sua ocorrncia sempre que possvel.
Quando:
Sempre que a interface necessitar de introduo directa de contedos por parte do
utilizador, por exemplo, aquando do uso de formulrios de registo, o designer deve
prevenir os erros ao mximo e preparar o sistema para que, quando os erros acontece-
rem, o utilizador no sofra consequncias negativas.
Soluo:
A soluo para minimizar os erros passa por:
Colocar exemplos de como a informao deve ser colocada;

Colocar legendas e notas que expliquem o que pedido;
Disponibilizar ajuda local e global;
Avisar o utilizador quando ele estiver prestes a abandonar uma pgina se estiver
em causa a perda de informao;
Se a submisso do formulrio falhar a informao, que tinha sido previamente
introduzida, deve ser reposta.
Referncias:
A utilizao deste padro ser essencial para uma simplificao do preenchimento de
formulrios Simplificar formulriose dever ser completada com a utilizao
de Mensagens de erro.
4.4.15 S teclado
Contexto:
O design para a Web deve responder s exigncias e necessidades dos utilizadores,
para que a experincia seja o mais positiva possvel. Este padro utilizado em qual-
quer contexto que tenta tornar o sistema acessvel e verstil ao maior nmero possvel
de utilizadores.
Problema:
A navegao por teclado permite que o utilizador navegue num determinado sistema
sem ser obrigado a recorrer a dispositivos apontadores como o rato.
Um utilizador pode ter problemas de viso ou problemas motores que o impe-
dem de utilizar o rato, ou outro dispositivo apontador, ou pode simplesmente preferir
no os utilizar e centrar a sua ateno, e campo de aco, apenas no teclado.
Soluo:
A navegao apenas por teclado deve existir em qualquer interface como forma a pro-
mover a acessibilidade e a usabilidade do sistema a qualquer utilizador, promovendo
a sua versatilidade. Para isso deve:
Permitir que algumas teclas, como o as setas, permitam uma navegao espacial;
Fazer com que o :focus se desloque automaticamente em campos de insero de
dados e, se tal no for possvel, permitir que ele se desloque atravs do uso do
tecladotecla Tab;
Permitir que algumas teclas, como o Enter ou o Return, possam terminar
tarefas facilmente, activando botes de aco;
Integrar shortcuts para iniciar funes de forma rpidaaccesskeys;
Acima de tudo a navegao por teclado deve facultar o acesso a todas as funcio-
nalidades da interface e proporcionar uma ordem de navegao lgica atravs deste
dispositivo, promovendo uma experincia consistente e familiar entre pginas. Alm
disso, deve ser tido em considerao que os elementos que podem ser acedidos atravs
4 Boas Prticas 79
de teclado tm uma maior probabilidade de poderem ser acedidos atravs de tecnolo-

gias de assistncia93 (thatcher [et al.]).
Referncias:
Este padro poder simplificar a introduo de dados em formulriosSimplificar
formulriospor utilizadores experientes, no sendo necessrio saltar entre rato e
teclado para completar a tarefa que tm em mente.
93 When you develop accessible interactive pages, the keyboard is your friend. Elements that can be rea-
ched via tabbing are very likely to be available to other assistive technologies. (thatcher [et al.], 2006)
4.4.16 Escrever para a Web
Contexto:
A cultura de leitura na Web diferente da leitura de textos impressos, por isso, es-
sencial que a escrita de contedos para a Web reflicta essa cultura.
Problema:
Como escrever contedos que possam ser interpretados correctamente na Web?
Na Web os utilizadores no gostam de blocos densos de texto, porque estes transmi-
tem a ideia de que o utilizador ter dificuldade em extrair informao e utilizadores
com dislexia tero dificuldades acrescidas em faz-lo. A leitura na Web normalmen-
te feita atravs de uma leitura rpida, em que o utilizador tenta perceber a pgina.
Muitos problemas de usabilidade na Web devem-se incapacidade dos uti-
lizadores de responder aos seus objectivos primrios: encontrar, ler e perceber a
informao.
Soluo:
Os contedos textuais dos stios devem poder ser facilmente lidos e apreendidos pelo
utilizador, para isso devem:
Ser sucintos e sintticos: escrever textos curtos e com 50% do texto que seria
escrito para material impresso;
Comear com uma pequena concluso, porque a maioria dos leitores vai ler ape-
nas as primeiras linhasformato de pirmide invertida;
Estruturar o texto de forma a facilitar a procura rpida de informao, quebrando
o texto em pequenos pedaos de forma a facilitar a sua leitura e compreenso:
Compor ttulos e subttulos, concisos e descritivos a separar ideias;
Criar pargrafos curtos;
Compor o texto sob a forma de listas sempre que for possvel, porque elas
atraem a ateno do utilizador
Eliminar artigos no incio dos itens e evitar listas com mais de 7 itens, porque
estas se tornaro mais difcil de ler;
Criar blocos de texto curtos;
4 Boas Prticas 81
Enfatizar e destacar partes importantes, atraindo a ateno dos leitores para de-
terminadas reas da pgina;
Utilizar uma linguagem simples e familiar;
No escrever algo que parea promocional ou exagerado;
No utilizar linguagens especializadas, porque a maioria dos utilizadores no o ;
Certificar que os textos no tm erros gramaticais (no mnimo aconselhvel
passar todos os contedos por um corrector automtico).
Referncias:
Os termos usados na navegaoTerminologiatambm sero essenciais no
processo de escrita para a Web. A formatao dos contedos, e a sua consequente Le-
gibilidade ajudaro a que a informao seja apreendida pelo utilizador.
4.4.17 Diviso dos contedos
Contexto:
Os utilizadores no gostam de pginas demasiado longas porque os obriga a fazer
scroll e porque torna a visualizao dos contedos desconfortvel.
Problema:
Como disponibilizar uma grande quantidade de informao sem prejudicar a sua leitura?
Por vezes, a informao necessria para o utilizador no pode ser composta facil-
mente numa nica pgina e, se o fosse, iria prejudicar o processo de visualizao e
compreenso da mesma. Por exemplo, pginas de resultados de pesquisas ou pginas
de listagens de contedos, podem tornar-se muito extensas sendo, por isso, aconse-
lhado a sua diviso em mais que uma pgina.
Soluo:
Dividir a informao em partes mais pequenas que so disponibilizadas em p-
ginas sequenciais;
Mostrar nmero total do ocorrncias ou o nmero total de pginas necessrias
para as disponibilizar;
Permitir que o utilizador navegue para as outras pginas, no s de forma abso-
luta1, 2, 3,, mas tambm de forma relativaanterior, seguinte;
Permitir o acesso directo primeira e ltima pgina;
Mostrar claramente qual a pgina onde o utilizador se encontra;
Se utilizar setas ter em ateno que em algumas lnguas se l da direita para a
esquerda e, por isso, o sentido ser o inversocompor texto em conjunto com a
seta evita ambiguidade.
Referncias:
A utilizao deste padro permitir uma maior Visibilidade Inicial. Ele poder ser
utilizado em conjugao com reas clicveis, como forma a definir a melhor forma
de disponibilizar as ligaes para as outras pginas.
4 Boas Prticas 83
4.4.18 Legibilidade
Contexto:
A legibilidade refere-se claridade com que uma letra pode ser distinguida de todas as
outras, permitindo a sua leitura.
Problema:
Como formatar os contedos de forma a facilitar a sua leitura?
A legibilidade dos contedos Web talvez um dos problemas mais recorrentes deste
meio. A mal formatao de contedos para ser lidos no ecr, ou a profuso de ele-
mentos decorativos como fundo das pginas, servem como factores de distraco e
incompreenso por parte do utilizador.
Soluo:
A soluo para melhorar a legibilidade dos textos passa por:
Formatar os textos com caixas altas e caixas baixasa utilizao apenas de cai-
xas altas torna a leitura mais lenta, porque o leitor no capaz de reconhecer a
forma das letras;
Alinhar o texto esquerda, porque ao contrrio do alinhamento ao centro ou
direita, o alinhamento esquerda permite ao leitor saber onde deve comear a
ler; na Web o texto justificado tambm no a melhor opo porque os navega-
dores no hifenizam palavras, dando azo a que existam grandes espaos entre
palavras;
Listas:
Utilizar listas verticais em vez de listas em linha;
Alinhar as segundas linhas das listas pelo texto e no pelos marcadores;
No separar demasiado o texto do marcador, porque isso vai tornar o texto
mais difcil de ler;
Assegurar que existe contraste suficiente entre o fundo e a tipografia, compondo
cores claras sobre fundos escuros, ou cores escuras sobre fundo claros, e evitar a
utilizao de imagens confusas, preferindo a utilizao de padres simples, ou
de cores planas, para o fundo;
Assegurar que existe espao suficiente entre as linhas;
No alterar o word-spacingespao entre palavrasou letter-spacingespao

entre letras, excepto em casos especiais;
Utilizar fontes suficientemente grandes e em valores relativo,s que permitam o
seu redimensionamento por parte do utilizador;
Utilizar famlias tipogrficas de fcil leitura e evitar o uso de fontes no
normalizadas.
Limitar o tamanho das linhas de texto, no permitindo que estas se tornem de-
masiado grandes, porque isso ir dificultar a leitura. O tamanho mximo deve
ser dado em funo do tamanho da letra, para que aumentem ou diminuam caso
o tamanho seja alterado;
Evitar animaes e texto a piscar, porque alm de poderem ser um factor de dis-
traco so mais difceis de ler.
Referncias:
A legibilidade est dependente tambm da forma como os contedos esto estrutu-
radosEstruturao dos contedos, das Cores utilizadas na formatao visual
e da forma como os contedos esto escritosEscrever para a Web, Terminolo-
gia, nunca poder haver uma boa legibilidade se os contedos no forem escritos
de forma a serem perceptveis.
4 Boas Prticas 85
4.4.19 Tag Clouds
Contexto:
Por vezes, a informao nos stios associada a palavras-chave que fornecem pistas
sobre o assunto e permitem relacionar essa informao com outras, disponibilizadas
no mesmo stio e sobre o mesmo tema.
Problema:
Como relacionar os contedos de acordo com o seu tema?
A utilizao de tag clouds uma das formas mais comuns de apresentar uma classi-
ficao social dos contedos, porque permite que eles sejam facilmente navegveis
pelos assuntos disponibilizados, e pela sua importncia relativa no stio. Esta forma
de organizao particularmente til em stios com uma componente social e ali-
mentados atravs de contedos dinmicos. Nestes stios usual que os utilizadores
utilizem palavras-chave para classificarem os contedos que inserem.
Soluo:
A apresentao destas nuvens de palavras dever passar por:
Quanto mais frequente a palavra maior dever ser o seu tamanho, assim quanto
maior for a ligao mais contedos associados ela ter;
A cor tambm poder ser utilizada como elemento acentuador da diferena de
importncia, no devendo no entanto ser o nico elemento;
Tal como no deve ser utilizada apenas cor para transmitir informao tambm
no deve ser utilizado apenas o tamanho da fonte. Por isso importante dispo-
nibilizar tambm o nmero de itens indexado a cada palavrapodendo este
apenas ser disponibilizado quando se usa um leitor de ecr, por exemplo;
Permitir a sua organizao de mais que uma forma: alfabtica, nmero de ocor-
rncia, cronolgica, etc;
Compor ligaes directas para as informaes marcadas com a palavra-chave,
normalmente so compostos como numa listagem de resultados de pesquisa;
estas ligaes tambm podem dar acesso a uma listagem de outras palavras-
-chave relacionadas e permitir combinar mais que uma palavra;
Se o universo de palavras for demasiado vasto pode ser mostrado apenas um n-

mero limitado de palavras, truncado, por exemplo, cronologicamente;
Quando o espao para colocao de tags no permite que sejam colocadas todas
as que esto relacionadas a um determinado contedo, pode ser composto uma
ligao para ver todas;
Tambm pode ser til permitir aos utilizadores criarem grupos de tags para or-
ganizarem os seus contedos.
Referncias:
O universo de tags utilizado ser simplificado se se recorrer a um Input previsto.
4 Boas Prticas 87
4.4.20 Seleco de lngua
Contexto:
Actualmente a Web um espao universal, por isso os contedos de alguns stios so
disponibilizados em mais que uma lngua.
Problema:
Como e onde compor os botes que permitem aceder aos contedos noutras lnguas?
Quando o contedo disponibilizado em mais que uma lngua o utilizador pode esco-
lher aquela com a qual se sente mais confortvel, por isso, essencial que ele consiga
reconhecer fcil e rapidamente essa funcionalidade na interface.
Soluo:
Na criao de uma navegao lingustica eficaz essencial:
Compor ligaes para as verses alternativas dos contedos em todas as pgi-

nas, e no apenas na primeira pginaum utilizador pode dominar mais que
uma lngua e preferir ver contedos distintos em diferentes lnguas, ou pode
entrar no stio por outra pgina que no a primeira. O utilizador deve ter sem-
pre a hiptese de reconsiderar a escolha inicial por uma determinada lngua94
(nielsen).
Estas ligaes devem ser compostos em textoo texto normalmente a melhor
escolha95 (raskin)e no utilizando bandeiras, porque como refere Nielsen,
apesar da bandeira ser provavelmente o smbolo mais usado para a escolha a esse
nvel, elas representam pases e no lnguas96, e um utilizador do Brasil procura-
r um cone com a bandeira do Brasil e no com a de Portugal, e vice-versa.
Referncias:
A correcta utilizao de reas clicveis ser essencial para que o utilizador possa ra-
pidamente encontrar a funcionalidade de alterar a lngua, e para que possa facilmente
interagir com essa funcionalidade.
94 No matter whether the initial language choice is made on a staging page or on the home page, the user
should always be given the option to reconsider the choice of language on subsequent pages. (nielsen,
2000)
95 [] text is often the best visual cue. (raskin, 2000)
96 The most frequently used visual symbol for a language is probably a flag, but unfortunately flags repre-
sent countries and not languages. (nielsen, 2000)
4.4.21 Estruturao dos contedos
Contexto:
Nem todos os utilizadores acedem a Web atravs de um navegador visual. Mas, in-
dependentemente do navegador utilizado, os contedos devem ser apresentados
segundo uma ordem lgica.
Problema:
Como assegurar que os contedos so disponibilizados de forma lgica em qualquer
dispositivo e para qualquer utilizador?
Quando um utilizador utiliza um navegador de texto, ou um dispositivo de lei-
tura, como um leitor de ecr ou um leitor braille, a ordem de leitura ser a ordem pela
qual os elementos so colocados no cdigo HTML, e no a ordem pela qual os elemen-
tos so formatados, , por isso, necessrio que essa ordem faa sentido.
Soluo:
Para que a estrutura da informao seja lgica:
Os contedos da pgina devem ser apresentados de uma forma coerente quando

vistos, ou lidos, sem formataes de estilo;
Aquando da utilizao de tabelas para o layout a ordem de leitura normalmente
confusa, por isso, essencial que esta seja verificada utilizando um leitor de ecr
(ou um simulador);
Aquando da utilizao de folhas de estilo para o layout a ordem de leitura deve
ser verificada desligando as CSS;
Utilizar uma linguagem de markupHTML ou XHTMLcorrecta; no descui-
dando o cdigo s porque a sua apresentao pode ser alterada atravs de folhas
de estilo. O uso correcto do cdigo essencial para que uma pgina seja visio-
nada sem folhas de estilo, ou para uma correcta interpretao pelos leitores de
ecr.
Referncias:
A escolha das tecnologias a utilizarEscolhas Tecnolgicasser definidora da
possibilidade, ou impossibilidade, de uma pgina ser correctamente estruturada.
4 Boas Prticas 89
4.4.22 Drag-and-Drop
Contexto:
Alguns stios possibilitam que os utilizadores organizem visualmente a ordem dos
contedos, permitindo que eles arrastem elementos.
Problema:
Como transmitir aos utilizadores a informao que os elementos podem sofrer uma
interaco directa?
Em longas listas de contedos pode ser til permitir que os utilizadores arras-
tem o contedo para a posio desejada, simplificando o processo de organizao e
diminuindo o trabalho exigido.
Soluo:
Para que uma funcionalidade de drag-and-drop possa ser correctamente operada ela
deve:
Comunicar claramente que essa opo est disponvel, por exemplo atravs da
incluso de texto;
Alterar o cursor para o sinal de move, indicando aos utilizadores que o elemen-
to pode ser movido.
Mas tambm deve ser permitido que a mesma aco possa ser conseguida atra-
vs de outro mecanismo, esta opo essencial para um utilizador que no interaja
com o sistema atravs de um navegador visual, sem um dispositivo apontador, ou sem
a tecnologia necessria para que o mecanismo de drag-and-drop funcione.
4.4.23 Definies cromticas
Contexto:
Grande parte da populao mundial sofre de algum tipo de daltonismo, cerca de 8%
dos homens e 0,5% das mulheres sofre de algum tipo de invisibilidade s cores (niel-
sen [et al.])97. As cores tambm tm uma conotao social, variando o seu significado
de acordo com a sociedade em que so vistas.
Problema:
Como garantir que os contedos podem ser apreendidos independentemente da cor
utilizada?
Nas pginas Web so muitas vezes utilizadas cores de fundo e/ou texto que no
permitem que os contedos sejam lidos pelos utilizadores. E nos formulrios mui-
tas vezes utilizada a cor como nico elemento informador de que um campo foi mal
preenchido, por vezes distinguindo entre verde e vermelho, o tipo de daltonismo mais
comum.
Soluo:
Para garantir a leitura e interpretao de toda a informao essencial:
Evitar o uso de cores muito saturadas;

Evitar o uso de cores complementares nos problemas de daltonismoverde/ver-
melho, azul/amarelo, vermelho/preto;
No utilizar a cor como nico meio de transmitir informaes nas pginas Web,
assegurando que outro elemento na pgina transmite a mesma informao, por
exemplo, atravs da introduo de texto;
97 Approximately 8 percent of men and .5 percent of women have some form of color blindness that pre-
vents them from differentiating certain colors. (nielsen [et al.], 2006)
4 Boas Prticas 91
Assegurar que existe contraste suficiente, certificando que o texto pode ser lido
por pessoas que sofram de algum tipo de problema no visionamento de cores,
ou quando visto num ecr a preto e branco. Para isso existem ferramentas online
que simulam os vrios tipos de daltonismoColorblind Web Page Filter98, Vische-
ck99 ou Colour Contrast Check100.
Referncias:
A utilizao (in)correcta das cores influenciar a Legibilidade do stio e ser deter-
minante para uma Codificao cromtica funcional.
98 http://colorfilter.wickline.org/
99 http://vischeck.com/
100 http://snook.ca/technical/colour_contrast/colour.html
4.4.24 Mensagens de erro
Contexto:
Norman refere-nos que se um erro possvel, algum o ir fazer101, e por isso os siste-
mas devem ser desenhados tendo em considerao o erro102.
Problema:
Como ajudar o utilizador a recuperar de um erro?
Por exemplo aquando do preenchimento de formulrios muito frequente o utiliza-
dor cometer algumas falhas, no entanto, ele deve ser ajudo a continuar com a tarefa
que pretendia desempenhar, sem se sentir frustrado ou ter vontade de desistir.
Soluo:
Para ajudar o utilizador a recuperar de um erro e a terminar a tarefa desejada as men-
sagens de erro devem ser compostas da seguinte forma:
No atribuir culpas ao utilizador ou trivializar com humor o problema;

Explicar como recuperar do erro, sugerindo passos que o utilizador pode seguir
para resolver o problema;
A mensagem de erro deve ser colocada o mais perto possvel do erro, destacando
a rea. Esse destaque no deve ser feito recorrendo apenas cor ou a configura-
es de CSS, porque um utilizador pode no ter acesso a uma delas ou a ambas.
Referncias:
Este padro deve ser utilizado em complemento de Minimizar os erros, numa tenta-
tiva de simplificar os formulrios
101 If an error is possible, someone will make it. (norman, 1998)
102 Design for error. Assume that any error that can be made will be made. (norman, 1998)
4 Boas Prticas 93
4.4.25 Layout flexvel
Contexto:
O layout flexvel utilizado quando no se pode prever em que condies o sistema ser
visionadoum ou vrios ecrs, a sua resoluo e/ou tamanho, ou as preferncias
do utilizadorque pode pretender dedicar mais ou menos espao de ecr ao stio.
Problema:
Um utilizador pode necessitar de mais ou menos espao para completar determinada
aco ou tarefa, ou pode preferir dividir a sua ateno entre uma ou vrias janelas. O
design no deve obrigar o utilizador a adaptar as suas preferncias de visualizao; o
stio que se deve adaptar s preferncias do utilizador.
Norman refere que solues fixas iro certamente falhar para algumas pessoas.
Uma soluo flexvel pelo menos dar uma oportunidade a pessoas com necessida-
des especiais103. Alm disso o designer no pode esquecer que no consegue nunca
um layout realmente fixo, porque a apresentao depender do navegador, do sistema
operativo e das preferncias pessoais do utilizador.
Soluo:
A integrao de um possvel redimensionamento e consequente reorganizao da in-
terface permite a sua adequao s diferentes necessidades, preferncias ou contextos
de utilizao, e torna-a mais amigvel para o utilizador. As interfaces devem por isso
permitir que o utilizar possa controlar a rea disponibilizada, podendo faz-lo de v-
rias formas.
Permitir que o redimensionamento da janela/aplicao faa o seu contedo en-

cher o espao disponvel;
Permitir que o redimensionamento da janela reorganize e/ou redimensione os
contedos disponibilizados;
Acima de tudo aconselhado no desenhar para uma largura modelo, permi-

tindo que o layout funcione em janelas de vrios tamanhos. Idealmente qualquer
103 Fixed solutions will invariably fail with some people; flexible solution at least have a chance for those
with special needs. (norman, 1998)
sistema deve permitir que o utilizador faa uso dele de forma livre, podendo utilizar
a rea disponvel como preferir, e permitindo uma utilizao mais eficaz do espao
do ecr. A integrao de um layout flexvel por parte do designer relega para o utili-
zador a responsabilidade da aparncia do sistema, e da adequao s suas prprias
necessidades.
Referncias:
O padro Escabilidade ir completar este, na criao de um stio flexvel para cria-
dores e utilizadores.
4 Boas Prticas 95
4.4.26 Insero de Contedos Audiovisuais
Contexto:
A Web actual um espao onde os contedos audiovisuais se tm vindo a multiplicar.
Problema:
Como introduzir contedos visuais e/ou sonoros nas pginas Web?
Muitos contedos sonoros so includos como rudo de fundo dos stios, comeando
a tocar automaticamente mal se entra a pgina. Esta aco, que no requer qualquer
aco do utilizador, pode ser muito prejudicial no s porque se torna repetitiva, can-
sando o utilizador, mas tambm porque lhe pode criar problemas quando acede ao
stio num computador, ou local, pblicos. O mesmo pode acontecer quando o conte-
do audiovisual, como num filme, faz play automtico com som.
Soluo:
Para evitar que o utilizador seja surpreendido so sugeridas duas medidas:
O som de fundo das pginas, caso exista, apenas deve tocar se o utilizador ex-
pressamente o ligar;
No caso da incluso de vdeos, se existir play automtico, ele deve ser feito sem som.
4.4.27 Simplificar Formulrios
Contexto:
Na Web existem processos que exigem que o utilizador preencha longas listas de in-
formao, mas os utilizadores tm como objectivo realizar uma determinada tarefa e
os formulrios so apenas um meio para atingir um fim.
Problema:
Como simplificar o processo de preenchimento de formulrios?
O preenchimento de formulrios uma aco recorrente na Web, no entanto ela re-
presenta uma tarefa frustrante e cansativa para o utilizador. Quando os utilizadores
se deparam com formulrios longos e complicados que exigem a introduo de vrios
dados, principalmente pessoais, eles sentem-se desmotivados e muitas vezes aban-
donam o local. Eles apenas pretendiam criar uma conta, inserir um vdeo ou colocar
um post num blogue e vem a sua tarefa dificultada pela introduo de informao
desnecessria; os utilizadores querem resultados imediatos.
Soluo:
Para evitar o sentimento de frustrao por parte do utilizador aquando do preenchi-
mento de formulrios necessrio:
Diminuir o nmero de campos do formulrio, para que apenas seja exigida a

informao estritamente necessria para que o utilizador possa realizar a tarefa
que pretende. A introduo de informao poder ser completada posterior-
mente, atravs da utilizao de um boto de edio;
Assinalar claramente o que de preenchimento obrigatrio e o que opcional;
nunca recorrendo apenas cor ou a formataes de CSS, porque estas podem
no estar disponveis ao utilizador;
Compor uma srie de comportamentos por defeito, permitindo que estes sejam
alterados apenas se o utilizador pedir;
No separar demasiado as legendas das caixas de insero de dados, para que um
utilizador consiga facilmente associar uma outra (segundo um estudo recente
da Smashing Magazine, 41% dos formulrios utilizam alinhamento direita e
esquerda em que os itens da coluna esquerda, legendas, se alinham direita e
os itens da coluna direita, contedos, se alinham esquerda (2008);
4 Boas Prticas 97
Formatar correctamente as caixas de insero de texto e as respectivas legendas,

isto ser essencial para uma navegao no visual, por exemplo, atravs um lei-
tor de ecr.
Referncias:
A eficcia do formulrio poder ser melhorada recorrendo a padres como Input
previsto, Minimizar os erros, Mensagens de erro ou a introduo de campos j
assinalados por defeito. A Terminologia utilizada no formulrio tambm ser es-
sencial para a sua compreenso por parte dos utilizadores.
Concluso 99
Concluso
A criao da Web partiu dos conceitos de universalidade e troca de informao, no

entanto muito do design que actualmente para ela produzida levanta dvidas em
relao concretizao desses objectivos. Este projecto assume-se como um ques-
tionamento do processo de design para a Web, tendo em conta os problemas da
usabilidade e acessibilidade, e como uma tentativa de sistematizar um conjunto de
possveis resolues para problemas recorrentes no projecto de design. A relevncia
deste estudo relaciona-se com a importncia cada vez maior que a Internet tem na
vida contempornea, e com a necessidade crescente de pensar no em um utiliza-
dor idealizado, mas sim em mltiplos utilizadores, com necessidades e preferncias
completamente diferentes; essencial tornar a Web usvel e acessvel para que todos
possam usufruir das mesmas oportunidades.
Na procura desta Web foram criadas normas e legislaes que pretendem sim-
plificar a construo de stios, uniformizar linguagens, e flexibilizar os contedos. No
entanto, o seu cumprimento nunca poder ser suficiente para comprovar a eficcia de
um stio, na verdade apenas uma avaliao com utilizadores reais o poder fazer. Os
testes de usabilidade e acessibilidade surgem aqui como uma ferramenta para com-
provar o sucesso do stio mas, antes de mais, como uma ferramenta para eliminar
problemas e dificuldades na interaco do utilizador com a interface. Idealmente este
processo dever ser realizado de uma forma iterativaavaliao, correco, nova ava-
liao, porque apenas um loop contnuo permitir encontrar todos os problemas e
aferir se a sua correco foi bem sucedida.
A realizao de testes no ser a nica forma de salvaguardar a usabilidade e a
acessibilidade, durante todo o processo de design as opes devem ser discutidas e
avaliadas internamente pelos vrios membros da equipa. A colaborao, a troca de
ideias e o questionamento constante das decises podem, desde o primeiro momento,
eliminar problemas futuros. Um trabalho realizado unilateralmente apenas se preo-

cupar com um utilizadoro designer, e este no ter dificuldades em interagir
com o seu prprio projecto.
Em ltima instncia podemos referir que o processo de design nunca poder es-
quecer o utilizador, e que este deve ser considerado o elemento central e prioritrio de
qualquer interaco; mas este elemento deve ser equacionado numa multiplicidade
de contextos e com variadas necessidades.
Algumas limitaes do projecto

O facto do processo iterativo da realizao de testes com utilizadores no ter sido ain-
da terminado impossibilita o estudo de todas as vantagens desse processo. Esta levar
tambm impossibilidade de concluir se um segundo modelo, criado com base no
resultado dos testes, seria de facto mais fcil de usar, e se um novo teste revelaria igual
nmero de problemas. O processo iterativo no projecto da tv.up est ainda a ser rea-
lizado, mas por limitaes de calendrio, esta dissertao no pode beneficiar dessas
concluses.
As solues propostas no constituem uma linguagem de padres completa,
e por isso no podem ser usadas em exclusivo para resolver todos os problemas de
usabilidade de um projecto de design. Estas solues constituem um conjunto de
sugestes que necessitar de ser completado com outro(s) estudo(s) futuro(s) e articu-
lado com estudos de outros autores. A natureza permanentemente evolutiva da Web
tambm levar a que estas sugestes tenham que ser revistas; Mas as linguagens de
padres assumem-se, na sua maioria, como um objecto permanentemente incomple-
to, procura de concluso.
Mais-valias para outras reas de trabalho

Apesar desta dissertao ter por objectivo questionar o processo do design para a Web,
algumas das concluses podem ser aplicadas tambm ao design de interfaces de uma
forma mais geral, devido aos muitos pontos de contacto entre ambas as disciplinas.
Estes pontos de contacto devem-se ao facto de ambas se focarem na experincia e inte-
raco Homem-Mquina, e de ambas falharem se a mquina no for funcional. Assim,
o processo de design de interfaces ser em muitos aspectos prximo do processo de
design para a Web, exigindo uma constante troca de ideias, o contnuo pensamento
nas necessidades e exigncias do utilizador e a realizao de testes de forma iterativa
Concluso 101
como forma a melhorar o sistema. Algumas das boas prticas sugeridas, como Esco-
lha dos termos a utilizar, Manter o utilizador informado ou S Teclado, tambm
podem ser aplicadas a este processo de design.
Um possvel futuro
O futuro deste estudo sobre a usabilidade e acessibilidade no design para a Web dever
passar por continuar a desenvolver a linguagem de padres, evoluindo e completando
as solues propostas e construindo solues novas. Para essa construo de novos
padres ser essencial um estudo mais aprofundado destas questes, estudando um
maior nmero e uma maior diversidade de objectos concretos e recorrendo realiza-
o de testes com maior frequncia e maior envergadura, com mais e mais variados
utilizadores. A avaliao de utilizadores com limitaes, funcionais ou situacionais,
tambm ser essencial para perceber como que estas limitaes realmente afectam
a interaco, e como que ela pode ser melhorada. Mas ser til nunca esquecer que,
como refere Alan Cooper et al., no existe uma interface objectivamente boa, a qua-
lidade depender sempre do contexto: do utilizador, do que ele est a fazer e das suas
motivaes104.
104 There is no such thing as an objectively good user interfacequality depends on the context: who the
user is, what she is doing, and what her motivations are. (cooper [et al.], 2007)
Referncias Bibliogrficas
Alexander, Christopher- Notes on The Synthesis of Form. Cambridge,

Massachusetts: Harvard University Press, 1971. isbn 0-674-62751-2.
Alexander, Christopher, [et al.]- A Pattern Language. Towns, Buildings,

Construction. New York: Oxford University Press, 1977. isbn 0-19-501919-9.
Allison, Brian; Race, Phil- The Students Guide to Preparing dissertations and
Theses. London: Routledge Falmer, 2004. isbn 0-415-33486-1.
Apple- Apple Human Interface Guidelines (2008) p. 402.
Appleton, Brad- Patterns and Software: Essential Concepts and Terminology,

2000, actual. 2000.14.02. [Consult. 2008.03.14]. Disponvel em WWW:
<http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html>.
Ask Tog- A Quiz Designed to Give You Fitts, 1999. Disponvel em WWW:
<http://www.asktog.com/columns/022DesignedToGiveFitts.html>.
Assembleia da Repblica- Relatrio e Parecer da Assembleia da Repblica sobre

a Petio pela acessibilidade da Internet Portuguesa, 1999. Disponvel em
WWW: <http://www.acessibilidade.net/peticao/>.
Assembleia da Repblica- Relatrio Final da Comisso de tica, Sociedade e

Cultura, referente Petio pela Acessibilidade Electrnica Portuguesa. Lisboa,
2008. Disponvel em WWW: <http://www.lerparaver.com/relatorio_peticao>.
Bartlett, Kynn- Common Myths About Web Accessibility, 1999. Disponvel em

WWW: <http://www.icdri.org/Kynn/common_myths_about_web_accessibi.htm>.
Battiana, Marco- User-Centered Design and Usability: Its Role in a Project, 2008.
[Consult. 2008.06.15]. Disponvel em WWW: <http://accessites.org/site/2008/06/user-
centered-design-and-usability-its-role-in-a-project/>.
Beck, Kent; Cunningham, Ward- Using Pattern Languages for Object-Oriented

Programs, 1987. [Consult. 2008.03.14]. Disponvel em WWW:
<http://c2.com/doc/oopsla87.html>.
Berners-Lee, Tim- Answers for Young People. Disponvel em WWW:

<http://www.w3.org/People/Berners-Lee/Kids>.
Berners-Lee, Tim- The World Wide Web: A very short personal history, 1998.
Disponvel em WWW: <http://www.w3.org/People/Berners-Lee/ShortHistor>.
Borchers, Jan- A Pattern Approach to Interaction Design. Chichester: Wiley, 2001.

isbn 0-471-49828-9.
Brown, Daniel M.- Communicating Design: Developing Web Site Documentation

for Design and Planing. 1. Peachpit Press, 2007. isbn 0-321-39235-3.
Bush, Vannevar- As We May Think. (1945).
Buurman, Gerhard M.- Total Interaction: Theory and Practice of a New Paradigm
for the Design Disciplines. Basel: Birkhuser, 2005. isbn 978-3-7643-7076-3.
Carroll, John M.- HCI Models, Theories, and Frameworks: Toward a

Multidisciplinary science. San Francisco: Morgan Kaufmann Publishers, 2003.
isbn/issn 1-55860-808-7.
Cederholm, Dan- Web Standards Solutions: The Markup and Style Handbook.
Friendsof ED, 2004. isbn 1-59059-381-2.
Clarke, Andy- Transcending CSS: The Fine Art of Web Design. Berkeley, CA: New
Riders, 2007. isbn 0-321-41097-1.
Comisso Europeia- Comisso quer um Internet mais eficiente para os

deficientes. Bruxelas, 2008. [Consult. 2008.07.30].
Conselho de Ministros- Resoluo do Conselho de Ministros n. 155/2007 (2007)
Cooper, Alan; Reimann, Robert; Cronin, David- About Face 3: The Essentials of
Interaction Design. 3. Indianapolis, Indiana: Wiley Publishing, 2007.
isbn 978-0-470-08411-3.
Coplien, James O.- A Pattern Definition, -. Disponvel em WWW:

<http://www.hillside.net/patterns/definition.html>.
Dolson, Joe - Improving Accessibility through Typography, 2007. [Consult.

2008.01.01]. Disponvel em WWW:
<http://accessites.org/site/2007/06/improving-accessibility-through-typography/>.
Foss, Sorgia K.; Waters, William- Destination Dissertation: A Travelers Guide to

a Done Dissertation. 2007. isbn 978-0-7425-5440-5.
Gamma, Erich, [et al.]- Design Patterns CD: Elements of Reusable Object-
Oriented Software: Addison-Wesley Professional Computing Series. Reading,
MA: Addison-Wesley Longman, 1998. isbn 0-201-63498-8.
Garret, Jesse James- Ajax: A New Approach to Web Applications, 2005. Disponvel
em WWW: <http://www.adaptivepath.com/ideas/essays/archives/000385.php>.
Garret, Jesse James- Meet the Elements. In The Elements of User Experience,
User-Centered Design For the WebNew Riders and AIGA, 2002.
isbn 978-0735712027.
Gomes, Ivo- Prototipagem em Papel, Desenvolver e testar interfaces antes de

iniciar a programao: SAPO Unplugged 08. 2008. Disponvel em WWW:
<http://www.ivogomes.com/apresentacoes/prototipagem-em-papel.pdf>.
Google- Google 101: How Google crawls, indexes, and serves the web.
Disponvel em WWW: <http://www.google.com/support/webmasters/bin/answer.
py?answer=70897&ctx=sibling>.
Henry, Shawn Lawton- Just Ask: Integrating Accessibility Throughout Design,

2007. [Consult. 2008.02.22]. Disponvel em WWW:
<http://www.uiaccess.com/accessucd/>.
Henry, Shawn Lawton- Understanding Web Accessibility 2002.
Hurst, Mark- Asking customers for what you dont already know, 2008.
[Consult. 2008.06.30]. Disponvel em WWW:
<http://goodexperience.com/2008/04/asking-customers-for.php>.
Hurst, Mark- Tips on Moderating Listening Labs, 2004. [Consult. 2008.06.30].

Disponvel em WWW:
<http://www.goodexperience.com/2004/12/tips-on-moderating-listening-l.php>.
Internet World Stats- Internet Usage Statistics: The Internet Big Picture, World
Internet Users and Population Stats, 2008a. Disponvel em WWW:
<http://www.internetworldstats.com/stats.htm>.
Internet World Stats- Top 47 Countries With The Highest Internet Penatration
Rate, 2008b. Disponvel em WWW:
<http://www.internetworldstats.com/top25.htm>.
Kalbach, James- Designing Web Navigation. 1st. Sebastopol, CA: OReilly, 2007.
isbn 978-0-596-52810-2.
Kelway, James- The what, when and why of wireframes: User Pathways, 2008.
<http://userpathways.com/2008/06/26/the-what-when-and-why-of-wireframes/>.
Krug, Steve- Dont Make Me Think! A Common Sense Approach to Web

Usability. 2. Berkeley, California: New Riders, 2006. isbn 0-321-34475-8.
Krug, Steve- On not throwing the baby out with the dishes, Interpreting test results.
In Dont Make Me Think! A Common Sense Approach to Web Usability, 2000a.
Krug, Steve- This Months Tip (and Last Months Tip, since June 1997): Advanced
Common Sense, 1997. Disponvel em WWW: <http://www.sensible.com/>.
Krug, Steve- Usability testing on 10 cents a day, Keeping testing simpleso you do
enough of it. In Dont Make Me Think! A Common Sense Approach to Web
Usability, 2000b.
Krug, Steve- Usability testing: The movie, How to do your own testing. In Dont
Make Me Think! A Common Sense Approach to Web Usability, 2000c.
Lie, Hkon Wium; Bos, Bert- The CSS saga. In Cascading Style Sheets, designing
for the Web. 2Addison Wesley, 1999. isbn 0-201-59625-3.
Lwgren, Jonas; Stolterman, Erik- Thoughtful Interaction Design, A Design

Perspective on Information Technology. The MIT Press, 2004.
isbn 0-262-12271-5.
Mathis, Lukas- Consistency Killed the Cat, 2008a. [Consult. 2008.07.01]. Disponvel
em WWW: <http://ignorethecode.net/blog/2008/06/29/consistency/>.
Mathis, Lukas- You really, really need to do Usability Tests, 2008b. [Consult.
<http://ignorethecode.net/blog/2008/06/22/you-really-really-need-to-do-ui-tests/>.
Medero, Shawn- Paper Prototyping. A List Apart. (2007). [Consult. 2008].

Disponvel em WWW: <http://www.alistapart.com/articles/paperprototyping>.
issn 1534-0295.
Millward Brown- Flash Player Penetration, 2008. [Consult. 2008.09.10]. Disponvel

em WWW: <http://www.adobe.com/products/player_census/flashplayer/>.
Moggridge, Bill- Designing Interactions. The MIT Press, 2007.

isbn 978-0262134743.
Nielsen, Jakob- Designing Web Usability. 2. New Riders, 2000a.

isbn 1-56205-810-x.
Nielsen, Jakob- Paper Prototyping: Getting User Data Before You Code, 2003a.
<http://www.useit.com/alertbox/20030414.html>.
Nielsen, Jakob- Quantitative Studies: How Many Users to Test? , 2006. [Consult.
<http://www.useit.com/alertbox/quantitative_testing.html>.
Nielsen, Jakob- Site Map Usability: Useeit.com, Alerbox, 2008. [Consult. 2008].
Disponvel em WWW: <http://www.useit.com/alertbox/sitemaps.html>.
Nielsen, Jakob- Ten Usability Heuristics, 2005. [Consult. 2008.08.17]. Disponvel em

WWW: <http://www.useit.com/papers/heuristic/heuristic_list.html>.
Nielsen, Jakob- Usability 101: Introduction to Usability, 2003b. [Consult.

2008.08.11]. Disponvel em WWW: <http://www.useit.com/alertbox/20030825.html>.
Nielsen, Jakob- Why You Only Need to Test With 5 Users, 2000b. Disponvel em
WWW: <http://www.useit.com/alertbox/20000319.html>.
Nielsen, Jakob; Loranger, Hoa- Prioritizing Web Usability. New Riders, 2006.
isbn 0-321-35031-6.
Nielson, Jakob- Screen Resolution and Page Layout, 2006. [Consult. 2008.06.30].
Disponvel em WWW: <http://www.useit.com/alertbox/screen_resolution.html>.
Norman, Donald A.- The Design of Everyday Things. Cambridge, Massachusetts:

The MIT Press, 1998. isbn 0-262-64037-6.
Norman, Donald A.- The Design of Future Things. 1. Basic Books, 2007.
isbn 978-0-465-00227-6.
OUT-LAW- Disabled web users rank their usability priorities: OUT-LAW News,
2005. [Consult. 2008.08.30]. Disponvel em WWW:
<http://www.out-law.com/default.aspx?page=6314>.
Quinn, Liam- Accessibility Myths, --. Disponvel em WWW:

<http://htmlhelp.com/design/accessibility/myths.html>.
Raskin, Jef- The Humane Interface: New Directions For Designing Interactive
Systems. Reading, Massachusetts: ACM Press, 2000. isbn 0-2-1-37937-6.
Smashing Magazine- 10 Principles Of Effective Web Design, 2008a.

[Consult. 2008.02.01]. Disponvel em WWW: <http://www.smashingmagazine.
com/2008/01/31/10-principles-of-effective-web-design/>.
Smashing Magazine- Flexible Layouts: Challenge For The Future, 2008b. [Consult.
2008.07.01]. Disponvel em WWW: <http://www.smashingmagazine.com/2008/06/26/
flexible-layouts-challenge-for-the-future/>.
Smashing Magazine- Should Links Open In New Windows? , 2008c. Disponvel

em WWW: <http://www.smashingmagazine.com/2008/07/01/should-links-open-in-
new-windows/>.
Smashing Magazine- Web Form Design Patterns: Sign-Up Forms, 2008d.

com/2008/07/04/web-form-design-patterns-sign-up-forms/>.
Smashing Magazine- Web Form Design Patterns: Sign-Up Forms, Part 2, 2008e.
com/2008/07/08/web-form-design-patterns-sign-up-forms-part-2/>.
Snyder, Carolyn- Paper Prototyping: The fast way to design and refine user
interfaces, 2003. Disponvel em WWW: <http://www.paperprototyping.com/>.
Thatcher, Jim, [et al.]- Web Accessibility: Web Standards and Regulatory
Compliance. New York: friendsof ed, 2006. isbn 978-1-59059-638-8.
The Council of Ministers- Resolution of the Council of Ministers concerning the

accessibility of public administration Web sites for citizens with special needs,
1999. Disponvel em WWW:
<http://www.acessibilidade.net/petition/government_resolution.html>.
Theofanos, Mary Frances; Redish, Janice (Ginny)- Guidelines for Accessible and
Usable Web Sites: Observing Users Who Work With Screen Readers 2003.
Thomas, Matthew Paul- What do you mean by usability? , 2008. [Consult.

2008.08.11]. Disponvel em WWW: <http://mpt.net.nz/archive/2008/08/11/usability>.
Tidwell, Jenifer- Designing Interfaces, Patterns for Effective Interaction Design.

Sebastopol, California: OReilly, 2005. isbn 0-596-00803-1.
U.S. Department of Health and Human Services- Reasearch-Based Web Design &
Usability Guidelines. isbn 0-16-076270-7.
Van Duyne, Douglas K. ; Landay, James A.; Hong, Jason I.- The design of sites:
patterns for creating winning websites. 2nd. Prentice Hall, 2007.
Vella, Matt- The 10 Commandments of Web Design, 2008. [Consult. 2008.06.30].

Disponvel em WWW: <http://www.businessweek.com/innovate/content/jun2008/
id20080623_750025.htm>.
W3C- How People with Disabilities Use the Web, 2005. [Consult. 2008.02.15].
Disponvel em WWW: <http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/>.
W3C- Policies Relating to Web Accessibility, -. [Consult. 2008.06.30]. Disponvel

em WWW: <http://www.w3.org/WAI/Policy/>.
W3C- Web Content Accessibility Guidelines 1.0, 1999. [Consult. 2008.02.15].

Disponvel em WWW: <http://www.w3.org/TR/WAI-WEBCONTENT/>.
Walsh, Josh- Forget about the Fold, 2007a. Disponvel em WWW: <http://www.
designinginteractive.com/2007/09/12/forget-about-the-fold/>.
Walsh, Josh- New Browser Windows, 2007b. Disponvel em WWW: <http://www.

designinginteractive.com/design/new-browser-windows/>.
Walsh, Josh- Typography on the Web, 2007c. Disponvel em WWW: <http://www.

designinginteractive.com/design/typography-on-the-web/>.
Wroblewski, Luke- Scalable Design: UX matters, 2007. [Consult. 2008.05.26].

Disponvel em WWW: <http://www.uxmatters.com/MT/archives/000225.php>.
Zeldman, Jeffrey- Designing with Web Standards. 2. Berkeley, CA: New Riders,
2007. ISBN 0-321-38555-1.
Glossrio 111
Glossrio
Accesskeys
Accesskeys so shortcutsatalhos por tecladoutilizados nos navegadores Web e que

permitem aos utilizadores saltarem imediatamente para uma determinada parte de
uma pgina, utilizando apenas o teclado.
Atributos ALT
O atributo Alt faz parte da linguagem HTML e XHTML e utilizado para fornecer
uma descrio das imagens. Esta descrio ser usada em substituio das imagens
quando estas no puderem ser disponibilizadas aos utilizadores, por exemplo, em na-
vegadores de texto, leitores de ecr ou leitores braille, quando a velocidade de ligao
no o permitir. Estas descries tambm sero usadas pelos motores de pesquisa, para
indexarem o stio.
Breadcrumbs
O termo breadcrumbliteralmente migalhasderiva do conto de fadas Hansel and

Gretel, no qual os irmos vo deixando migalhas pela floresta como forma a marcar o
seu percurso e poderem encontrar o caminho de regresso.
Quando transposto para o contexto da Web refere-se a um percurso marcado
visualmente que permite ao utilizador saber onde se encontra na estrutura do stio e,
se necessrio, retroceder nessa estrutura.
Cascading Style Sheets
(Ver CSS)
CSS
CSSCascading Style Sheets uma linguagem de computao utilizada para formatar

a apresentao de documentos estruturados atravs de folhas de estilo, permitindo ao
designer configurar a aparncia das pginas HTMLlayout, fontes, cores, etcsem
ser obrigado a alterar as prprias pginas. Esta linguagem permite uma separao
completa entre contedo e apresentao, que era o objectivo de Berners-Lee com a
linguagem HTML.
A primeira especificaoCSS1foi publicada em 1996 pelo W3C e a segun-
daCSS2dois anos mais tarde. A verso em uso actualmente a 2.1, uma reviso da
sua predecessora. A CSS 2.1 encontra-se actualmente em reviso, no entanto alguns
elementos dessa nova especificaoCSS 3.0j so suportadas pelos navegadores
mais recentes.
Design de Interfaces
O Design de Interfaces refere-se a uma rea do design que se foca na experincia do

utilizador e na interaco deste com a Mquinacomputadores, mquinas, apare-
lhos de comunicaes mveis, etc.
FAQ
FAQ um acrnimo de Frequently Asked QuestionsPerguntas frequentese cor-

responde a um conjunto de perguntas e respostas, consideradas frequentes num
determinado contexto e relacionadas com um determinado tpico. Normalmente tm
um espao dedicado nos stios.
Glossrio 113
Frames
Frame um elemento HTML que permite criar uma sub-janela no navegador. Este ele-
mento utilizado para organizar vrias janelas dentro da mesma pgina, sendo que
cada uma poder ter um documento HTML diferente.
Hiperligao
A hiperligaoou ligaodesigna reas clicveis na pgina e podem surgir em

forma de texto ou imagem.
Hiperligao uma referncia existente num documento em hipertexto a outro
documento ou recurso. As hiperligaes so uma parte fundamental da WWW e cons-
tituem a parte mais importante do hipertexto, uma vez que so eles que possibilitam
que o utilizador navegue para uma localizao diferente na mesma pgina, ou em p-
ginas distintas.
Na Web existem dois tipos de hiperligaes: hiperligao internaque mantm
o utilizador no mesmo stioe hiperligao externaque direcciona o utilizador
para outro stio.
HTML
HTMLHyperText Markup Language uma linguagem de marcao utilizada nas p-

ginas Web. Ela proporciona uma forma de descrever a estrutura textual da informao
presente na pgina, atravs da marcao de pargrafos, ttulos, listas, etc, e de com-
pletar essa informao textual com outros meios como imagens, formulrios, etc.
A primeira referncia a esta linguagem feita por Tim Berners-Lee, em 1991,
num documento intitulado HTML Tags. A actual especificao desta linguagem
HTML 4.1foi publicada em 1999 e corrigida numa errata publicada em 2001.
Interaco Homem-Mquina
A Interaco Homem-MquinaHCI (Human-computer Interaction)estuda a interac-

o entre as pessoasutilizadorese as mquinasnormalmente o computador.
Internet
A Internet um sistema global de redes de computadores interligados que trocam

informao entre eles. A Internet ganhou nfase em 1991 com a divulgao do projecto
World Wide WebWWW, embora a sua tecnologia estivesse j disponvel h cerca
de uma dcada.
A Internet fornece um grande nmero de recursos e servios, como correio elec-
trnico, conversao online, transferncia de ficheiros, jogos online e a WWW.
JavaScript
JavaScript uma linguagem de programao, usada na desenvolvimento do projecto

e que permite alterar dinamicamente o contedo sem ter que fazer chamadas ao ser-
vidor, j que funciona do lado do cliente.
Esta linguagem foi criada em 1995 pela Netscape, e era inicialmente chamada de
LiveScript. Actualmente marca registada da Sun Microsystems.
Personas
Personagens-tipo utilizadas aquando do processo de Design. Estas personagens

tentam representar os vrios tipos de utilizadores possveis da Interface, as suas pre-
ferncias e necessidades, e surgem sob a forma de uma narrativa, que conta a sua
histria e comportamentos atravs de detalhes especficos.
Ligao
(Ver Hiperligao)
Navegador
O navegadorou explorador o programa que permite aos utilizadores interagi-

rem com as pginas e navegar na Web. Alguns exemplos normalmente disponveis
para computadores pessoais incluem o Firefox, Safari, Internet Explorer e Opera.
Glossrio 115
Tecnologias de assistncia
Tecnologias de assistnciaTA um termo genrico que inclui os dispositivos de

assistncia, de adaptao e reabilitao e os processos empregados na sua utilizao.
Estas tecnologias promovem uma maior independncia e autonomia para as pessoas
com limitaes, dando-lhe a oportunidade de realizar tarefas que de outra forma no
seriam possveis, ou com as quais teriam grande dificuldade.
Leitores de ecr, leitores de braille, ampliadores de ecr ou sintetizadores de voz
so algumas das TA a que alguns utilizadores tm que recorrer para conseguir intera-
gir com sistemas tecnolgicos.
URI
URIUniform Resource Identifier, em portugus Identificador Uniforme de Recur-

sos, o conjunto de caracteres utilizados para identificar ou nomear um recurso na
Internet, possibilitando uma interaco com ele.
URL
URLUniform Resource Locator uma URI, onde identificado o recurso disponibi-

lizado e o protocolo para o recuperar.
W3C
O World Wide Web ConsortiumW3Cfoi fundado, em 1994, por Tim Bernners-Lee

(actual director) com a finalidade de desenvolver normas para a World Wide Web. Este
consrcio coordena actualmente os protocolos e normas que so utilizados na cons-
truo de ferramentas e contedos para a Web.
At data criou especificaes como HTML, XML, XHTML, CSS, DOM.
World Wide Web
A World Wide WebWWWfoi criada em 1989 por Sir Tim Berners-Lee, mas apenas
foi disponibilizada ao pblico em 1991. Ela um sistema de documentos interligados e
que podem ser acedidos atravs da Internet. Internet e WWW so muitas vezes confun-
didas e os termos so utilizados como sinnimos, mas a WWW constitui apenas uma
pequena parte da Internet, apenas um servio que comunica atravs da Internet.
Wireframes
Wireframes so utilizados no design de interfaces como esboos preliminares do que

poder a vir a ser a interface final. Eles so meros desenhos estruturais, que no preten-
dem revelar o design propriamente dito, pretendem sim mostrar as reas destinadas
aos contedos. Os wireframes podem ser desenvolvidos atravs de diversas tcnicas
esboos rpidos, desenhos vectoriais, prottipose iro permitir que a organizao
geral dos contedos seja pensada de forma rpida, sem exigir qualquer componente
tecnolgico ou de programao.
XHTML
XHTMLeXtensible HyperText Markup Language uma linguagem de marcao ba-

seada na linguagem HTML. Esta linguagem utiliza um conjunto de codificaes que
marcam a estrutura dos contedos e que so depois interpretadas pelo navegador.
A verso XHTML 1.0 foi publicada em 2000 pela W3C e a verso actualXHTML
1.1em 2001.

Usabilidade e Acessibilidade No Design para A Web

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Usabilidade e Acessibilidade No Design para A Web

Uploaded by

Copyright:

Available Formats

Usabilidade e Acessibilidade no design para a Web i

2008. Faculdade de Belas Artes Universidade do Porto

orientador: Heitor Alvelos

Keywords: Usability, Accessibility, Webdesign, Interaction, User Centered Design,

Palavras-Chave: Usabilidade, Acessibilidade, Webdesign, Interaco, Design Centra-

1.8.5 Navegao ineficiente 20

2 Avaliao da Usabilidade e da Acessibilidade 27

4.4.24 Mensagens de erro 92

Referncias Bibliogrficas 103

A tecnologia e a Internet adquirem uma importncia cada vez maior na sociedade,

1 [] the word intuitive is a little bit deceptive. (tidwell, 2005)

familiar ou aprendido anteriormente pelo utilizador2. Com todas as suas limita-

A usabilidade estuda a relao entre as ferramentas e os seus utilizadores. Para que

A Eficincia relaciona-se com a rapidez e o grau de sucesso com que os utilizado-

In a broad sense, accessibility simply means ensuring that a given page

A acessibilidade uma subclasse da usabilidade. Enquanto a usabilidade se preocupa

1.3 A importncia da preocupao com a Usabilidade e

Somehow, when a device as simple as a door has to come with an instruction

A usabilidade e a acessibilidade so importantes quer do ponto de vista do utiliza-

Romper com o passado

mesma frequncia; (2) no obriga criao de um design desinteressante ou mera-

1.4 Problemticas do Design para a World Wide Web

The dream behind the Web is of a common information space in which we

17 [] a tool for communicating [] to help people understand each other (berners-lee)

1.5 Filosofias do Design: Design Centrado no Utilizador

User-Centered Design (UCD) is a user interface design process that focuses on

O objectivo do Design Centrado no Utilizador dar a conhecer os utilizadores e

1.6 Normas e Legislao para a construo de contedos

Without these standards, there can be no true usability and no coherent

1.6.1 World Wide Web Consortium

Numa tentativa de criar especificaes e normas para promover a evoluo da Web

Webe devido aos esforos deste projecto, os criadores de navegadores comearam

1.6.2 As normas de HTML, XHTML e CSS

A W3C especifica a utilizao das normas de HiperText Markup Language 4.1HTML

1.6.2.1 Validao das normas estabelecidas

Isto acontece porque normalmente os navegadores so tolerantes em relao a erros,

1.6.3 Porqu respeitar as normas?

O respeito e o uso pelas normas propostas pelo W3C ir reflectir-se favoravelmente no

1) Compatibilidade: no s com os vrios navegadores que existem mas tambm

1.6.4 Construo de stios acessveis

1.6.4.1 Web Content Accessibility Guidelines

Prioridade 1: um criador de contedos para a Web dever satisfazer esta priori-

Critrios de sucesso do nvel 1

1.6.5.1 O caso portugus

sua participao na vida pblica (assembleia da repblica, 1999). Assim a pe-

1.6.4.2 Na Unio Europeia

1.7 Heurstica do Design de Interfaces

1) Visibilidade do estado do sistema: O sistema deve manter sempre os utiliza-

processo est a decorrer. Se tal no acontecer o utilizador poder pensar que o

teclado, ou a utilizao de macros, que permitem ao utilizador gerar determina-

1.8 Os principais problemas referenciados

Almost three-quarters of the usability issues that people encounter have to do

1.8.1 Inexistncia de simetria entre os contedos

A afirmao de Nielsen remete-nos para a importncia que a apresentao dos con-

portante da acessibilidade fornecer informao textual para o contedo que no o

1.8.2 Formulao dos contedos

rapidamente o ecr, em vez de ler linearmente a informao32 (u.s. department of

1.8.3 Falta de legibilidade

1.8.4 Elementos visuais ou sonoros

A utilizao de elementos visuais ou sonoros que no podem ser desligados tambm

1.8.5 Navegao ineficiente

A falta de consistncia na navegao ou no layout ao longo do stio tambm apon-

1.8.6 Falta de compatibilidade entre os diferentes programas de