Esta secção do site apresenta diversos padrões de elementos de interação para sites Web e mobile. Incorporam boas práticas e descobertas feitas pela nossa equipa de forma a poder utilizar soluções que maximizem a usabilidade, acessibilidade e visibilidade a motores de pesquisa.

Para que servem?

Procuramos naturalmente padrões quando estamos num site ou aplicação, e tomamos decisões com base nas experiências passadas. Para os utilizadores, os padrões de design reduzem a carga cognitiva apresentando algo familiar, assim não terão de descobrir quais os passos que terão de dar para atingirem o seu objetivo.

Como utilizar?

Todos os padrões listados nesta secção irão apresentar uma estrutura similar e que explicam que tipo de interação pretendem solucionar, o código desse padrão, a explicação, caraterísticas adicionais e referências adicionais.

Segue-se uma descrição exemplificativa de um padrão:

Nome do padrão

Problema

Após o nome do padrão, é apresentado um sumáro que descreve o que é e qual o problema que o padrão tenta resolver.

Solução

Detalha a solução e explica de que forma os problemas são solucionados.

Esta secção poderá igualmente conter excertos de códigos HTML, CSS e JavaScript que funciona como uma receita, pronta a usar, que soluciona a padrão de interação:

	
		<h1>Exemplo markup HTML da solução para o padrão.</h1>
	

A disciplina de "Search Engine Optimizations"(SEO) procupa-se em estruturar website, páginas e conteúdo de forma a que sejam mais facilmente descobertas e o seu valor acentuado aos olhos dos motores de pesquisa (tais como Google, Bing, Yahoo, etc.). Consequentemente, se as nossas páginas forem mais relevantes para os motores de pesquisa, os nossos utilizadores conseguem encontrá-las mais facilmente.

Um efeito secundário interessante de nos preocuparmos com questões de SEO é o facto de contribuir para a melhoria da acessibilidade do nosso site.

Nota: Esta página ainda está a ser activamente trabalhada e irá futuramente ter mais informação acerca desta temática.

Estratégia de conteúdo

Para resultados de SEO consistentes, é necessário, antes de considerar qualquer tag e optimização, qual é a estratégia de conteúdo que se pretende. Ou seja, quais são os termos relevantes que queremos ver associados com o site, que termos irão os utilizadores utilizar para chegar a conteúdo (nosso ou não) do tipo que oferecemos? Esses termos tornam-se relevantes para as descrições, meta keywords e outros conteúdos do site.

Informação genérica necessária:

• Nome do produto;
• Palavras chaves que queremos ver associadas ao produto;
• Descrição para o produto;
• Descrição para as várias secções do site.

Consideremos, por exemplo, um produto chamado "SAPO Fisco" com as palavras-chaves:

• "IRS", "preenchimento", "declaração", "ajuda"

Recursos

Ficheiros essenciais ou que ajudam os crawlers dos sistemas de pesquisa a recolherem o conteúdo certo.

Robots.txt

O ficheiro robots.txt permite dar indicações aos crawlers dos sistemas de pesquisa sobre que páginas não deverão recolher ou quais as condições para recolhê-las (e.g., limitar a certa altura do dia).

Tipicamente, pretende-se impedir o acesso dos crawlers:

• às páginas de pesquisa;
• ao login e signup;
• aos backoffices.

Sitemap.xml

O sitemap.xml consiste num ficheiro que lista as páginas existentes no site.

Não sendo mandatório, o site ajuda os crawlers do motor de pesquisa a encontrar todas as páginas.

É particularmente útil incluir este ficheiro no site quando:

• O site tem uma grande dimensão. Minimiza a hipótese do crawler não apanhar uma página nova ou que foi actualizada;
• O site é novo e tem poucos sites a fazer link para ele;
• As páginas não se referenciam entre si ou estão isoladas.

Metadados

Na concepção de páginas, vários campos e metadados precisam de ser preenchidos para aumentar a relevância das páginas. Esses metadados são declinados a partir do que foi definido na estratégia de conteúdos.

Títulos

De acordo com o tipo de página, o conteúdo e formato do título tem que ser ajustado para destacar a informação que for mais específica no contexto da página que está a ser vista.

O título da homepage tem que ser o nome do produto. Opcionalmente, poderá incluir informação extra de descrição de produto.

Títulos (exemplo):

• SAPO Fisco ou SAPO Fisco: ajuda nas declaração IRS

As páginas internas do site têm que apresentar um título que consiste na ordem da hierarquia. Ou seja, primeiro o nome da página, seguido da secções que se lhe antecedem e por fim o nome do site.

Categorias/artigos/etc.:

• estatudo de mecenato - benefícios sociais - SAPO Fisco

Description

O campo de "description" é usado para descrever a página que se está a apresentar. É importante notar que não se quer um descrição para todas as páginas de site mas sim uma que descreva cada página. Idealmente, deverá conter as palavras-chaves que se considerem relevantes para o contexto. É recomendado uma dimensão entre os 70 e 160 caracteres para este campo.

Exemplo de descrição para a homepage:

Gerir as finanças e preencher o IRS não tem que ser complicado. O SAPO Fisco dá-lhe ajuda na sua declaração de IRS.

Exemplo para uma descrição de uma página de artigo:

Na sua declaração pode incluir o seu contributo para mecenato social. A sua doação a entidades o desenvolvimento dão-lhe vantagens fiscais.

Open Graph - Facebook

O Facebook utiliza um conjunto de atributos, chamados "Open Graph", para definir metadados que utiliza para apresentar páginas partilhadas nas suas redes sociais. A informação pedida para o "Open Graph" são: título da página; descrição; URL. Caso seja uma página de artigo, poderá referir o nome do site (com og:site_name). Se a página tiver uma página que descreva o conteúdo, poderá ser referenciada com o atributo og:image (deverá ter pelo menos 1200×630 pixels).

É possível diferenciar as descrições apresentadas nas meta-tags de "Open Graph", mas é suficiente reaproveitar o que está a ser usado para os crawlers dos motores de pesquisa.

Mais informação disponível em Incluir as tags Open Graph.

Twitter Card

Da mesma forma que é possível partilhar páginas e enriquecer a informação apresentada no Facebook, é possível definir meta-tags para formatar os resultados no Twitter. É denominado de "Twitter Card".

Para um "Twitter card"(twitter:card) do tipo sumário ("summary") é preciso apresentar:

• A indicação do tipo: twitter:card;
• O título: twitter:title;
• A descrição: twitter:description;
• O endereço da página: twitter:url;

Opcionalmente, pode ser definido:

• Uma imagem para o tweet: twitter:image. Deverá ter no mínimo uma dimensão de 120×120px;
• O nome da conta de twitter associada ao site: twitter:site.

Existem mais tipos de "Twitter card" que poderão ser opcionalmente usados: "summary_large_image", "photo", "gallery", "product", "app" ou "player".

Mais informação disponível em: Twitter Cards - Getting Started Guide

Hierarquia de informação

A hierarquia de um site, para as diversas páginas existentes, é importante não só para um bom posicionamento em motores de pesquisa, mas também tem impacto em utilizadores com necessidades especiais (e.g., invisuais).

Como tal, é importante que o elemento <h1> corresponde ao título da página e não ao nome do site (excepto para o caso da homepage), e que não exista saltos entre a hierarquia de cabeçalhos.

A página "Apresentar os conteúdos seguindo uma hierarquia" detalha os cuidados a ter.

Código HTML sem erros

Apesar de inexistência de erros no HTML das páginas não garantir um impacto positivo no SEO das páginas, erros nas páginas podem levar a que os motores de pesquisa não percebam ou interpretem mal a informação contida nas páginas. Como tal, os erros de html tem um impacto negativo na visibilidade que as páginas têm para os motores de pesquisa.

Como tal, verificar sempre o HTML no Validador da W3C.

Atributo ALT nas imagens

O atributo alt nas imagens é mandatório e ajuda os motores de pesquisa a perceber o que está representado na imagem. Infelizmente, a informação muitas vezes mal preenchida.

Caso a imagem seja usada por fins decorativos, o atributo alto deverá estar vazio(alt=""). Caso contrário, a imagem terá que descrever o que está a ser mostrado na imagem.

Para mais informação consultar como Fornecer alternativas textuais aos elementos não-textuais.

Indicar o idioma da página

Não é fácil identificar automaticamente o idioma na qual as páginas estão escritas daí que as os motores de pesquisa necessitam que lhes seja indicado o idioma no qual a página está escrita.

A identificação do idioma é feita no atributo 'lang' de elemento <html> da seguinte forma:

<!doctype html>
<html lang="pt">
  <!-- Documento escrito em português -->
  …

Este atributo aceita quer códigos de idiomas(pt para português, en para inglês, ...) quer idioma por região (pt-PT, português de Portugal; pt-BR, português do Brasil).

No caso de existir pedaços de texto que estou num idioma diferente do que está especificado pela página, é igualmente possível utilizadar o atributo lang. Por exemplo, se quiser indicar uma expressão francesa numa página em português, poderia marcar da seguinte forma:

<!doctype html>
<html lang="pt">
  <!-- Documento escrito em português -->
  …
<body>
  …
  <p>Em francês, <em>por favor</em> é dito <em lang="fr">s'il vous plaît</em>.</p>
  …

Os valores aceites para os idioma estão definidos nas especificações RFC bcp47, ISO 639-1 e ISO 3166-1 alpha-2.

Indicar conteúdo traduzido

Caso o site tenha páginas que apresente o mesmo conteúdo diferentes locais, quer adaptando o idioma quer adaptando a informação lá contida(moeda, horários, ...), é necessário identificar as versões localizadas de forma a que os motores de pesquisa possam fornecer a versão mais relevante aos utilizadores.

Para indicar a existência de versões alternativas, é necesário incluir dentro do elemento <head> um elemento <link> com os atributos 'rel="alternate"' e 'hreflang="[idioma]".

<html lang="pt">
<head>
  …
  <link rel="alternate" hreflang="en" href="http://ux.sapo.pt/en/" />
  …
</head>
…

Todas as versões, se forem conteúdo canónico, deverão apontar para as versões alternativas, e não somente a versão que consideramos como a principal. Ou seja, na página de destino do exemplo anterior, o cabeçalho html deverá conter a seguinte informação:

<html lang="pt">
<head>
  …
  <link rel="alternate" hreflang="pt" href="http://ux.sapo.pt/" />
  …
</head>
…

Como nota final, só os conteúdos canónicos é que deverão incluir a informação de conteúdos alternativos. Às páginas não-canónicas só lhes é exigido que apontem para as páginas canónicas.

Saber mais

• Uso de hreflang para definir os URLs de idioma e região

Referências

• Search Engine Optimization Starter Guide - Google

Nesta secção, dedicada à usabilidade para aplicações mobile, vamos deixar algumas dicas e regras que temos vindo a recolher à medida que fomos ganhando experiência a desenvolver e testar aplicações para várias plataformas.

O nosso objectivo é partilhar as nossas experiências e não listar todas as regras de usabilidade para cada plataforma diferente. Para isso, recomendamos vivamente que se leiam e se sigam as recomendações de design e de interface da plataforma em que se está a desenvolver.

• Android design guidelines
• iOS human interface guidelines
• User interface for Windows Phone 8

É possível identificar padrões em mobile?

Independentemente da plataforma, o design de interface mobile deve encontrar soluções para os problemas dos utilizadores, mais do que responder a uma lógica de produto. Isto significa defender a experiência do utilizador a todo o custo contra algumas ameaças comuns:

• navegação pouco óbvia - introduzir elementos de navegação que não falam por si;
• excesso de conteúdo - incluir a informação do desktop, sem selecionar ou prioritizar;
• funcionalidades sobrepostas - replicar o que já é feito, e bem, por outras aplicações;
• tarefas exigentes - tornar o caminho longo e penoso;
• falta de feedback - deixar o utilizador sem saber o que aconteceu;
• muitas atualizações - criar a impressão de que há demasiada coisa que precisa de correção.

Para combater estas ameaças, elaborámos um conjunto de práticas e metodologias assentes num único pressuposto: uma aplicação mobile tem de ser, em simultâneo, útil e intuitiva. Se não for útil, não há valor adicional face à concorrência e não há uma razão forte para convencer os utilizadores a fazerem download. Se é útil mas exige uma dolorosa e longa curva de aprendizagem, os utilizadores vão desistir de a usar. E muito provavelmente vão deixar registo da má experiência.

O que há de diferente nas plataformas mobile?

O contexto das aplicações mobile é muito específico - as aplicações são reunidas em lojas, de acordo com o sistema operativo para que foram criadas, e estão expostas a verdadeiras comunidades de utilizadores. É possível consultar datas de lançamento, histórico de atualizações, número de utlizadores, screenshots ou pequenas introduções às funcionalidades. Mais importante que tudo isso, é possível consultar críticas e score atribuído a cada aplicação.

Lançar uma aplicação significa, por isso, estar exposto a uma comunidade vasta e heterogénea, com objectivos e expectativas diferentes. Com dispositivos e usos diferentes. O que pode gerar feedback muito diverso. O sucesso de uma aplicação, que costumamos traduzir apenas pelo número de downloads, passa também por ter utilizadores regulares satisfeitos, e passa por estar presente, ouvir o que eles têm a dizer e fornecer feedback sempre que possível, seja sob a forma de resposta direta a um comentário, seja sob a forma de uma atualização.

Ao longo desta secção, vamos abordar os problemas comuns encontrados pelos profissionais e que se refletem na experiência do utilizador, bem como as soluções reutilizáveis, ou padrões, que encontrámos para eles. Estas práticas são naturalmente dependentes do contexto em que se inserem, embora sejam geralmente agnósticas no que diz respeito a sistemas operativos, dispositivos ou linguagens de programação.

Assim, não vamos expor funcionalidades prontas a ser incorporadas, nem resolver os desafios específicos de cada plataforma, mas vamos explanar as boas práticas que fazem o dia-a-dia da equipa do SAPO.

Vamos a isso.

A disciplina de "Search Engine Optimizations"(SEO) preocupa-se em estruturar o website, páginas e conteúdo de forma a que sejam mais facilmente descobertas e o seu valor seja acentuado aos olhos dos motores de pesquisa (tais como Google, Bing, Yahoo, etc.). Consequentemente, se as nossas páginas forem mais relevantes para os motores de pesquisa, os nossos utilizadores conseguem encontrá-las mais facilmente.

Um efeito secundário interessante de nos preocuparmos com questões de SEO é o facto de contribuir para a melhoria da acessibilidade do nosso site.

Principios básicos

• Adicionar conteúdo direccionado para os potenciais utilizadores do site;
• Site com boa user experience;
• Criar um site com informação de valor e original.

Podemos dividir em 2 domínios as técnicas referentes ao SEO: On-page, técnicas referentes às páginas, títulos, conteúdo e estrutura global do site e o Off-page, que foca-se em aumentar a relevância do site, com links externos a redireccionar para o nosso site, como em redes sociais, blogs e outros sites.

Nos capítulos seguintes fornecemos um conjunto de regras e dicas mais direccionado para o on-page, ambos (on-page e off-page) são importantes mas deve-se começar por ter uma boa estrutura no site e depois passar para o off-page.

A usabilidade (ou falta dela) é uma componente muito importante de um website, e que pode significar o sucesso ou insucesso do mesmo junto dos seus utilizadores. Uma má experiência de utilização pode fazer com que os utilizadores desistam de usar o website e comecem a usar o site da concorrência. Assim, é importante não só garantir uma boa experiência de utilização, como ter a certeza de que o site cumpre com os objectivos a que se propõe, ou seja, que faça aquilo que os utilizadores esperam que o site os ajude a fazer.

Um sistema usável depende de um conjunto de factores:

• Funcionalidades disponibilizadas: É importante que as funcionalidades sejam úteis aos utilizadores. Não interessa a quantidade de funcionalidades disponíveis, mas sim a sua utilidade e facilidade de uso. Não importa ter um site que faz 1001 coisas, se depois a sua utilização é frustrante e difícil. Às vezes mais vale ter apenas 2 ou 3 funcionalidades e executá-las muito bem para passar a ser uma referência e um ponto de visita obrigatório para os utilizadores que procuram essas funcionalidades;
• Conteúdos: Se não temos conteúdos úteis para os utilizadores, então não temos nada que chame pessoas ao nosso website. Mais importante do que as funcionalidades, a navegação ou a pesquisa, é importante ter conteúdos úteis. Por vezes, mesmo com uma péssima navegação, websites com conteúdos muito úteis fazem com que os utilizadores façam de tudo para ultrapassar as dificuldades apresentadas para conseguir chegar à informação;
• Navegabilidade: Se os conteúdos são úteis, torna-se também necessário facilitar o acesso aos mesmos. Uma boa navegação permite que os utilizadores cheguem mais rapidamente aos conteúdos que procuram, melhorando assim a sua experiência de utilização;
• Acessibilidade: Ao contrário do que se pensa, acessibilidade não é apenas para utilizadores com deficiência ou necessidades especiais. Acessibilidade significa que os conteúdos devem estar acessíveis universalmente a todos os utilizadores, independentemente da sua deficiência, necessidade ou dispositivo utilizado. Assim, é necessário garantir o acesso à informação quer se use um portátil ou um telemóvel, quer se navegue com o rato ou com o teclado, ou quer se tenha alguma limitação física (ex: pessoas com mobilidade reduzida, um braço partido, dificuldades na visão, etc). Em relação a este ponto, temos toda uma secção deste website dedicado à acessibilidade.

Como medir a usabilidade?

A usabilidade pode ser "medida" de várias maneiras. No entanto, não se pode propriamente indicar a quantidade de usabilidade que um sistema tem. Em vez disso, indica-se uma lista de problemas que foram encontrados, e qual a sua gravidade. No SAPO usamos uma escala de gravidade de 5 níveis que vai do "Crítico" ao "OK".

Normalmente, as formas mais comuns de identificar problemas num website são através de:

• Avaliações heurísticas: As avaliações heurísticas são feitas usando uma checklist de pontos de verificação. Dependendo da heurística utilizada, esta checklist pode ir das dezenas de pontos de verificação até às várias centenas. No entanto, a checklist mais usada é a de Nielsen com os seus 10 pontos de verificação principais. Esses 10 pontos podem depois ser interpretados e transformados em vários sub-pontos de verificação, como neste exemplo. Como referência, disponibilizamos também no SAPO UX uma checklist de pontos de verificação de usabilidade que pode ser usada como ponto de partida para identificar potenciais problemas de usabilidade a corrigir nos vossos websites.
• Avaliações por peritos (expert reviews): As avaliações por peritos são feitas por avaliadores experientes que tentam simular o comportamento dos utilizadores no website. É uma mistura de avaliação heurística com testes com utilizadores, em que se aproveita a experiência do avaliador para encontrar potenciais problemas de usabilidade no website. Estudos recentes que compararam os problemas encontrados por "expert reviews" vs utilizadores reais concluiram que a fiabilidade das expert reviews é muito próxima dos testes com utilizadores, com a vantagem de demorar muito menos tempo e ser mais barata. Mais testes comparativos aqui.
• Testes com utilizadores: Esta é a forma mais fiável de identificar problemas de usabilidade em qualquer sistema. Colocar utilizadores reais a usar o sistema, pedindo-lhes para realizar algumas tarefas e observar como navegam e se conseguem ou não atingir os objectivos de cada tarefa, permite identificar os pontos críticos onde é preciso intervir para melhorar a experiência de utilização de um website ou aplicação. Não é preciso fazer testes com muitos utilizadores, pois com apenas 5 ou 6 em cada iteração podemos identificar entre 80% a 90% dos problemas de usabilidade. Sempre que possível, é melhor testar com poucos utilizadores várias vezes ao longo do desenvolvimento de um website, do que gastar logo todos os recursos num teste com dezenas de utilizadores a testar as mesmas tarefas numa única iteração.

A escolha do método vai depender do contexto do website que se vai testar, do tempo disponível, e se existe ou não a possibilidade de poder ter pessoas externas a participar nos testes com utilizadores.

Como posso melhorar a usabilidade do meu website?

Nos capítulos seguintes, fornecemos um conjunto de dicas e regras de usabilidade que podem e devem ser seguidas para garantir uma boa usabilidade e uma boa experiência de utilização em websites. A aplicação cega das regras e guidelines não vai automaticamente tornar um mau site num bom site. A experiência de utilização tem de ser vista como um todo, e sob vários contextos de utilização.

Assim, além da aplicação das nossas dicas e recomendações, recomendamos vivamente que sejam feitos testes com utilizadores. Mesmo que não haja a possibilidade de testar com utilizadores reais, é sempre possível testar com amigos e familiares. Basta apresentar-lhes o website, dar um conjunto de 3 ou 4 tarefas (ex: "comprar um telemóvel nesta loja e chegar à página de pagamento onde são pedidos os dados do cartão de crédito") e ver onde existem falhas a corrigir. E fazer isto várias vezes ao longo do tempo para haver uma melhoria contínua.

Vamos começar!

Tal como num website, a navegação de uma aplicação deve permitir que os utilizadores acedam às diferentes funcionalidades de forma eficaz e eficiente.

Independentemente do tipo de aplicação, o modo como os utilizadores navegam vai determinar se vão ficar satisfeitos o bastante para continuar a usá-la.

Seguem-se algumas regras e dicas de navegação, úteis para o contexto dos dispositivos móveis.

Organizar o conteúdo em unidades de sentido

A seleção e hierarquização de informação assume especial relevância nas plataformas móveis.

A um utilizador em trânsito, cuja atenção é partilhada com as tarefas do mundo físico, com um ecrã reduzido e, em alguns casos, rede intermitente ou bateria prestes a acabar, apresenta-se apenas o essencial.

E de forma rápida e direta.

OK Numa aplicação de um festival é útil mostrar, acima de tudo, os próximos concertos.
Fonte: MEO OUTJAZZ - Windows Phone

Ser consistente e previsível no layout

OK A navegação baseada no conteúdo é um padrão para incorporar transições transparentes entre overviews e vistas de detalhe.
Fonte: AIRBNB - iOS

Depois de selecionar cuidadosamente o tipo de conteúdo a incluir, há que planear a forma como apresentar esse conteúdo ao utilizador.

Optar por desenhar o layout da aplicação móvel a partir do conteúdo significa fornecer ao utilizador uma experiência mais fluída, e acaba por gerar soluções de navegação originais e mais adaptadas ao contexto de utilização, mas sempre consistentes e previsíveis entre ecrãs.

O objectivo é tornar tão naturais os gestos do utilizador, que a própria aplicação seja uma ferramenta quase invisível.

Facilitar o acesso à navegação

Ao contrário do que acontece num website, o ecrã de um dispositivo móvel não nos permite criar zonas amplas reservadas à navegação, mas deve permitir-nos um acesso rápido a esses elementos, bem como um feedback em permanência acerca da localização do utlizador no contexto da aplicação.

OK O uso de um menu lateral deve ser acompanhado do highlight da área onde se encontra o utilizador.
Fonte: GUARDIAN - Android

Permitir o reconhecimento imediato dos elementos de navegação

Os elementos de navegação devem ser agrupados e diferenciados dos restantes elementos da aplicação, de forma a que a sua visibilidade e reconhecimento não sejam comprometidos.

Observem-se os seguintes exemplos:

NOK O uso da cor para marcar itens clicáveis e outros não clicáveis deixa o utilizador confuso.
Fonte: AMAZON - Android

NOK Os botões devem provocar reconhecimento imediato. No ex., a leitura está comprometida.
Fonte: POCKET - Android

OK Todos os itens clicáveis são da mesma cor, distinguindo-se do restante conteúdo.
Fonte: SAPO SABORES - iOS

Pontos de verificação

Estes são exemplos de alguns dos pontos principais de avaliação que equipa de usabilidade vai verificar e qual a sua classificação.

Tipo de Problema	Classificação (saber mais)	Observações
Existem ecrãs sem navegação e que são becos sem saída para o utilizador	Crítico
Ecrãs de erro não permitem recuperar do erro e voltar a navegar ou pesquisar pelo conteúdo que se procurava	Problema Grave
Inconsistências na forma como a navegação é disponibilizada ao longo dos diferentes ecrãs da mesma aplicação	Problema Grave
Não existe indicação no menu de navegação de qual a secção em que o utilizador se encontra	Problema
Os títulos dos links clicados não coincidem com os títulos das páginas de destino	Problema
Não é possível distinguir claramente os elementos clicáveis dos restantes elementos que não são clicáveis	Crítico
Há elementos na página que não são links, mas que têm o mesmo aspecto dos elementos clicáveis	Crítico
Não existe forma de aceder facilmente ao ecrã inicial em todos ou alguns ecrãs da aplicação	Crítico
O texto dos links não faz sentido quando lido fora do seu contexto, ex: uso de links "clique aqui"	Problema

Nota: Esta não é uma lista exaustiva, apenas um exemplo. Podem existir mais problemas identificados na avaliação de usabilidade à aplicação que não estão listados aqui. Cada aplicação tem as suas particularidades e contextos de utilização diferentes.

O conteúdo é, usando o termo de forma genérica, a informação apresentada ao utilizador no website ou aplicação. Pode surgir sob diferentes formatos, como texto, imagens ou vídeo, e servir uma multiplicidade de propósitos, como vender um produto, educar ou sensibilizar para uma temática, entreter.

Para uma app móvel, a dificuldade está precisamente aqui: como selecionar vastas quantidades de informação, de forma a que os utilizadores sintam que estão perante uma ferramenta útil? como apresentar um layout simples e direto, de forma a que até os utilizadores em contextos menos favoráveis (rede fraca, bateria prestes a acabar...) consigam aceder rapidamente ao que pretendem?

Servir o conteúdo sob a forma de funcionalidades-chave

Quando existe um website como ponto de partida para a criação de uma aplicação móvel, há que escolher e prioritizar o conteúdo relevante para a categoria do negócio.

Por exemplo, para uma loja online, é crucial que se possa fazer uma pesquisa de produtos ou verificar o estado de um pedido. No entanto, fazer uma escolha significa aqui saber não só o que é relevante para o negócio, nem saber que uma aplicação não pode conter tudo o que um website contém, mas o que pode ou não funcionar em ambiente mobile.

Assim, pode não haver necessidade de oferecer comparações de produtos ou extensas fichas de detalhe.

Para além do excesso de conteúdo e de funcionalidades, outro erro frequente é a disponibilização de conteúdos multimédia em excesso. Este tipo de conteúdo adiciona valor à aplicação sempre que é usado com moderação, já que é sobretudo usado em duas circunstâncias: quando o utilizador está à espera de uma distracção (como notícias ou conteúdos de entretenimento) ou quando tem conteúdo educacional (por exemplo, como usar a aplicação ou uma nova feature).

OK Exemplo de uma aplicação que apresenta uma seleção de notícias.
Fonte: YAHOO NEWS DIGEST - Android

Ser coerente em todas as plataformas

A escolha das funcionalidades principais pode ser enriquecida com funcionalidades mobile-only, usando as capacidades dos dispositivos para agradar e surpreender os utilizadores; e funcionalidades cross-channel, estabelecendo coerência e continuidade entre plataformas (ex.: utilizadores que fazem login devem ver as duas definições personalizadas, independentemente da plataforma em que estão; se a funcionalidade não está totalmente disponível no mobile, encaminhar para o canal apropriado).

OK Exemplo de uma aplicação que permite usar o touch id definido no dispositivo.
Fonte: MEO WALLET - iOS

Otimizar para o contexto mobile

Para além da coerência multiplataforma, todas as funcionalidades disponibilizadas devem estar otimizadas para o uso nos dispositivos móveis, o que implica assegurar que:

• os conteúdos têm em conta a natureza do dispositivo a que se destinam (ex.: ter a certeza que o store locator mostra as lojas mais perto baseando-se na localização do dispositivo e tornar os números de telefone click-to-call);
• os conteúdos são apresentados em formatos suportados pela generalidade dos dispositivos (ex.: não pedir aos utilizadores de iOS para fazerem download do Flash);
• o copywriting dos conteúdos deve ser adaptado à atenção reduzida (pelo contexto) dos utilizadores;
• o conteúdo multimédia deve ser apresentado em boas condições, independemente do tamanho, densidade ou resolução do ecrã;
• o controlo sobre o conteúdo deve estar sempre do lado do utilizador, o que significa não fazer auto-start a um vídeo ou som, ou permitir fazer skip ou parar (ex.: devido, por exemplo, ao consumo de dados implicado no processo ou ao espaço físico onde se encontra o utilizador).

Desenhar o layout em função do conteúdo

A apresentação visual dos conteúdos e dos elementos de navegação constitui parte importante da experiência do utilizador.

As decisões tomadas a nível de design gráfico, branding e layout devem ter em conta que estas são ferramentas de comunicação visual, que imediatamente podem causar percepções e emoções positivas como a credibilidade, a consistência, a inovação, ou então deixar transparecer um carácter descuidado, inconsistente, obsoleto.

Numa aplicação móvel, não se pode tratar apenas de replicar o design das plataformas pré-existentes, mas servir-se de um ponto de partida, mantendo a consitência visual, através do uso da cor, da tipografia, etc., para desenhar experiências fluídas e adaptadas ao conteúdo e ao contexto de utilização (neste contexto, a Nokia popularizou a frase: "Don't shrink, rethink").

OK A coerência entre as diferentes plataformas produz reconhecimento e confiança.
Fonte: EBAY - app e website (full e mobile)

Contar um conto

O layout é o guia do utilizador - guia-o desde o elemento visual mais proeminente até aos restantes elementos, com a intenção clara de ajudar a completar tarefas com o mínimo ruído possível.

Assim, um bom fluxo visual faz uso do conteúdo e das funcionalidades, apresentando-as como quem conta uma história, mas uma história de leitura rápida e fácil.

Tirar partido da orientação

No processo de design, há ainda que considerar as orientações portrait e landscape. Muitas aplicações são apenas disponibilizadas numa orientação, o que pode fazer sentido conforme a natureza dos conteúdos (por exemplo, é habitual que os jogos se joguem em landscape e as notícias se leiam em portrait).

OK Pode-se tirar partido da orientação apresentando conteúdos adaptados a cada modo.
Fonte: CAL - Android

Ao ter em conta a orientação física do dispositivo móvel, deve-se sempre manter a localização do utilizador no ecrã e mudar a informação disponível em cada modo.

Pontos de verificação

Estes são exemplos de alguns dos pontos principais de avaliação que equipa de usabilidade vai verificar e qual a sua classificação.

Tipo de Problema	Classificação (saber mais)	Observações
Inconsistências graves na organização da informação ao longo dos vários ecrãs da mesma aplicação	Problema Grave
O espaçamento entre linhas não é o suficiente para garantir uma boa legibilidade	Problema
Não existe contraste suficiente entre a cor dos textos e a cor de fundo	Crítico
Conteúdos demasiado encavalitados e sem espaçamentos ou separadores entre si	Problema Grave
O título do ecrã não corresponde com o título do conteúdo principal desse ecrã	Crítico
São apresentados conteúdos em formatos não suportados pelo dispositivo	Crítico
O conteúdo multimédia é despoletado pela ação do utilizador	Problema Grave
Os títulos e os conteúdos são longos e exaustivos	Problema

Nota: Esta não é uma lista exaustiva, apenas um exemplo. Podem existir mais problemas identificados na avaliação de usabilidade à aplicação que não estão listados aqui. Cada aplicação tem as suas particularidades e contextos de utilização diferentes.

A arquitetura de informação de uma aplicação móvel diz respeito à estrutura lógica do conteúdo e das funcionalidades, de forma a ajudar os utilizadores a encontrar a informação de que precisam e a completar as tarefas a que a aplicação se propõe.

Esta estrutura é apresentada ao utilizador sob a forma de elementos de navegação, pesquisa e labelling. As regras de ouro para desktop, como não forçar os utilizadores a terem de se lembrar da informação, estruturar a sequência das ações de forma óbvia ou fornecer opções de navegação óbvias para continuar o workflow, valem também para o contexto dos dispositivos móveis.

Neste contexto, não se pretende que o nível de complexidade das tarefas seja muito aprofundado, e que o esforço necessário para interagir com a aplicação móvel, como por exemplo a introdução de dados em formulários, seja minimizado. Apresentamos de seguida algumas dicas e regras para conseguir um workflow simples e direto:

Ter as tarefas na ponta dos dedos

Em mobile, é importante permitir a navegação pelos conteúdos e funcionalidades com o mínimo possível de toques.

Como estamos a falar de ecrãs habitualmente mais pequenos, a navegação deve ser mais abrangente e menos profunda.

Por exemplo, se optarmos por criar demasiadas entradas no menu ou vários níves secundários de navegação, é possível que o utilizador se sinta tentado a abandonar o processo e tomar a decisão de continuar a tarefa mais tarde, quando estiver confortavelmente sentado a trabalhar no desktop.

Cada nível adicional significa mais toques, mais espera e mais dados consumidos. O número razoável de toques (ou taps) aceitáveis para completar a generalidade das tarefas não está formalmente estabelecido, mas é comum pretender chegar-se a qualquer área de uma aplicação com um máximo de três toques.

Mesmo que sejam necessários mais toques, o utilizador deve reconhecer que cada gesto que faz é útil para completar a tarefa.

OK Se estivermos a falar de uma aplicação de receitas convém ter todas as funcionalidades por perto.
Fonte: KITCHEN STORIES - iOS

Prioritizar de acordo com as necessidades

No entanto, simplificar nem sempre significa ter de abdicar de ter diferentes níveis de navegação.

A quantidade e a natureza dos conteúdos e das funcionalidades podem exigir níveis de navegação primária e secundária (geralmente verticais, em vez de horizontais como no desktop), que devem sempre incluir links para o que é considerado como principal no ecrã de início, prioritizados de acordo com as necessidades dos utilizadores.

Como em desktop, é essencial usar, nos elementos de navegação, labels claras, concisas e consistentes com as outras plataformas e tamanhos que permitam o toque a dedos menos precisos.

OK Exemplo de uma aplicação com vários níveis de navegação.
Fonte: SAPO DESPORTO - iOS

Fornecer pistas de navegação

Em todos os ecrãs, há que fornecer pistas de navegação, de forma a que o utilizador saiba sempre onde está, como fazer para voltar atrás e como chegar rapidamente ao ecrã inicial.

As breadcrumbs mobile, ao contrário do desktop, não podem mostrar todo o percurso efectuado pelo utilizador e são frequentemente implementadas substituíndo o botão "back" por uma label que apenas mostra a secção ou categoria de onde vieram.

Se estivermos a falar de uma aplicação com vários níveis de navegação, a opção de fazer "back" até ao ecrã inicial torna-se algo mais complicado e devem ser dadas alternativas mais eficazes ao utilizador, como usar uma drawer acessível por swipe a partir de qualquer localização ou um long press para voltar ao início, desde que se ensine ao utilizador como fazê-lo.

OK Exemplo de uma aplicação com um botão para o ecrã inicial sempre presente.
Fonte: SHAZAM - Android

Limitar o user input

Não se deve pedir ao utilizador mais do que o estritamente necessário. Há uma série de regras muito simples de implementar sobre o que deve ou não ser considerado quando se está a desenhar um formulário mobile:

• limitar o input aos campos essenciais - por exemplo, limitar um formulário de registo aos campos mínimos obrigatórios na aplicação e pedir restantes dados no site desktop;
• ter em conta que o esforço necessário para introduzir dados não deve exigir o uso das duas mãos;
• mostrar valores default para facilitar a introdução de dados - é sempre mais fácil escolher de uma lista do que escrever tudo (isto quando as opções são limitadas, para não tornar a lista demasiado grande);
• disponibilizar mecanismos de input alternativos baseados nas capacidades dos dispositivos (câmara, voz, geolocalização, ...);
• usar os mecanismos correctos de input e mostrar o keyboard respectivo, para evitar que o utilizador tenha de navegar pelos vários ecrãs antes de introduzir informação;
• permitir que os utilizadores permaneçam logados (em aplicações que não lidem com informação muito sensível) e guardar info como o endereço de email/nome de utilizador, já que os dispositivos móveis tendem a ser dispositivos de uso pessoal;
• oferecer auto-completion, corretor ortográfico e tecnologia de predição para reduzir o esforço necessário para introduzir dados e para reduzir erros - com a funcionalidade de reverter as predições/correcções se necessário
• desabilitar funcionalidades como o CAPTCHA quando não é necessário.

OK O login com contas existentes e o pré-preenchimento de dados facilitam a vida ao utilizador.
Fonte: HOTEL TONIGHT - Android

Pontos de verificação

Estes são exemplos de alguns dos pontos principais de avaliação que equipa de usabilidade vai verificar e qual a sua classificação.

Tipo de Problema	Classificação (saber mais)	Observações
O utilizador tem de preencher dados que já preencheu anteriormente no mesmo formulário	Crítico
O utilizador tem de preencher mais dados que nas outras plataformas	Problema Grave
Não existe forma de simplificar o preenchimento de dados num formulário que são semelhantes aos dados já pedidos no mesmo formulário.	Problema Grave
Os menus não indicam em que secção o utilizador se encontra	Problema Grave
Aaplicação tem uma estrutura complexa (vários sub-níveis de navegação) e não facilita o acesso ao ecrã inicial	Problema
A estrutura de uma sequência de passos que o utilizador tem de executar não é óbvia, obrigando a ter de encontrar a ação para continuar para o passo seguinte	Crítico
Não existe indicação do número de passos de um workflow com vários passos	Problema Grave
Quando existe indicação do número de passos, não existe indicação de qual o passo atual	Crítico
Os textos dos botões de navegação não correspondem com a ação que vai ser desempenhada ao clicar nesse botão	Problema Grave
Os textos dos botões de navegação não são claros	Problema

Nota: Esta não é uma lista exaustiva, apenas um exemplo. Podem existir mais problemas identificados na avaliação de usabilidade à aplicação que não estão listados aqui. Cada aplicação tem as suas particularidades e contextos de utilização diferentes.

O feedback é o conjunto de métodos utilizados por uma aplicação móvel para atrair a atenção do utilizador e mostrar-lhe informação relevante para a tarefa que pretende iniciar, que está em curso ou que está prestes a terminar.

Pode tratar-se de informação que confirme e apoie o desempenho da tarefa, mas pode também tratar-se de erros, que interfiram ou impeçam as ações do utilizador.

Indicar sempre a localização do utilizador

A localização do utilizador de uma aplicação móvel deve ser algo evidente e imediato, tal como acontece em desktop.

É habitual ver-se no topo do ecrã o título da área em que o utilizador se encontra e, dependendo do sistema operativo, um botão de back com a área imediatamente anterior.

Não deve ser implementada a lógica de breacrumbs, já que se assume que a navegação não deve ser tão profunda que o justifique. Deve ser evidente para o utilizador saber onde está olhando apenas para os itens de navegação visíveis.

Para complementar esses elementos, um menu de acesso lateral pode fornecer o restante contexto e transportar o utilizador para qualquer área da aplicação.

OK O uso de um menu lateral deve ser acompanhado do highlight da área onde se encontra o utilizador.
Para complementar essa info, o título do ecrã está sempre presente.
Fonte: TODOIST - Android

Tornar claro aquilo que permite ação do utilizador

No contexto mobile, não é possível usarmos técnicas como o hover para explicar para que servem os elementos antes de os selecionar, já que o toque despoleta imediatamente a ação.

Daí que os elementos que podem ser selecionados, tapped ou swiped devem ser assinalados de forma clara e evidente (devem conter a qualidade de serem reconhecidos para aquilo que servem - affordance).

Links, botões ou ícones devem ser distintos dos restantes elementos não clicáveis e incluir labels inequívocas.

Fornecer feedback de todas as ações e erros

A informação prestada ao utilizador sob a forma de alertas ou notificações deve ser reduzida àquilo que é, de facto, relevante.

O objectivo deve ser não interromper o workflow do utilizador quando tal não se justifique, fornecendo apenas feedback e informação. Para tal, um alerta deve ser breve e conciso, explicando o que o originou e oferecendo ao utilizador uma alternativa, uma maneira de ultrapassar o obstáculo com botões de ação claros e evidentes.

Uma notificação deve ser breve e informativa, sem interferir com o que o utilizador está a fazer e sugerindo uma ação fácil de concretizar ou de dismiss rápido.

OK Exemplo de um alerta com um botão de "atualizar".
Fonte: EVERNOTE - Android

Usar a tecnologia disponível

OK Exemplo de push notification que inclui botões de
ação.
Fonte: DOLLARBIRD - Android

Uma das formas mais marcantes de convidar o utilizador à interação e aumentar o engagement com uma aplicação móvel são as push notifications.

Inicialmente, foram introduzidas como popups ou alertas despoletadas mesmo quando a aplicação não está em uso e que o convidam a entrar na aplicação e consultar conteúdo ou realizar uma ação específica. No entanto, o uso deste tipo de notificação evoluiu sob a premissa de que o utilizador pode interagir sem interromper grandemente o que está a fazer: permitindo a consulta rápida de conteúdo ou a ação específica na própria notificação.

Por exemplo, o Twitter pode iniciar uma conversa com o utilizador mandando-lhe uma notificação e permitindo-lhe a resposta direta na própria notificação, sem ter de entrar na aplicação.

Pontos de verificação

Estes são exemplos de alguns dos pontos principais de avaliação que equipa de usabilidade vai verificar e qual a sua classificação.

Tipo de Problema	Classificação (saber mais)	Observações
Não existe indicação no menu de navegação de qual a secção em que o utilizador se encontra	Problema
Não existe feedback quando o utilizador clica em ações que são demoradas e que envolvem algum processamento antes de mostrar o resultado final da ação	Crítico
Inexistência de qualquer tipo de feedback ao utilizador quando ocorrem erros	Crítico
As mensagens de erro não permitem saber o que aconteceu nem como corrigir o problema	Crítico

Nota: Esta não é uma lista exaustiva, apenas um exemplo. Podem existir mais problemas identificados na avaliação de usabilidade à aplicação que não estão listados aqui. Cada aplicação tem as suas particularidades e contextos de utilização diferentes.

Nesta secção vamos apenas deixar algumas dicas e regras base que devem ser tidas em conta quando se estiver a desenvolver aplicações móveis.

O nosso objetivo é o de partilhar as nossas experiências e não o de listar todas as regras de acessibilidade para cada plataforma diferente. Para isso, recomendamos vivamente que se leiam e se sigam as recomendações da plataforma em que se está a desenvolver.

Seguir as recomendações de cada sistema operativo

Para garantir que as aplicações são compatíveis com as ajudas de acessibilidade do próprio sistema operativo, devem ser seguidas as recomendações de cada plataforma:

• Google accessibility resources for developers
• Accessibility programming guide for iOS
• Apple accessibility for developers

Pensar como é que a nossa aplicação pode ser usada por alguém com necessidades especiais

Ao desenhar uma aplicação, devemos pensar como é que os utilizadores com vários tipos de necessidades especiais poderão usar a nossa aplicação usando tecnologias assistivas. Por exemplo, podemos imaginar a utilização da nossa aplicação com os seguintes constrangimentos:

• Sem som;
• Sem cores;
• Com o modo de alto contraste ativado;
• Com o ecrã maximizado ou com zoom;
• Com um screen-reader (sem ver o ecrã);
• Apenas usando controlos de voz;
• Usando uma combinação de vários constrangimentos listados acima;

Sempre que possível, devemos testar o uso da aplicação com estes modos de acessibilidade do dispositivo, e verificar se conseguimos aceder a toda a informação disponibilizada.

Fazer com que as zonas clicáveis tenham pelos menos 48x48 pixels

As zonas clicáveis deverão ter um tamanho mínimo recomendado de 48x48 (px, dp) para qualquer elemento no ecrã.

É também preciso ter em conta o espaçamento entre os vários elementos. Na maior parte dos casos, os espaçamentos deverão ser iguais ou superiores a 8dp.

Mesmo que os elementos ou ícones sejam inferiores a
48dp, as áreas clicáveis devem-se manter

Garantir que a aplicação continua legível com textos grandes

Se o utilizador usar as opções de zoom do ecrã ou ativar os textos grandes nas opções de acessibilidade, a app continua legível?

Todos os elementos essenciais devem permanecer visíveis, usáveis e não sobrepostos uns aos outros.

Usar um contraste suficiente entre a cor de fundo e a cor dos textos

Um contraste suficiente significa normalmente ter um rácio de 4.5:1 ou superior. Havendo contraste entre a cor de fundo e a cor dos textos permite que os utilizadores em geral (e os que têm menor acuidade visual em particular) consigam ler os conteúdos da aplicação mais facilmente.

Os textos mais pequenos necessitam de um contraste maior (rácio de 3:1), enquanto que os textos grandes conseguem tolerar uma palete de cores mais abrangente e menores contrastes.

Na prática, podemos usar sistemas que calculam automaticamente o contraste entre duas cores e nos indicam se passa ou não no teste de acessibilidade:

• Colour Contrast Check - por Jonathan Snook
• Contrast Ratio - por Lea Verou

Exemplo de cálculo do rácio de contraste entre um fundo branco e dois tons de cinza.

Não confiar apenas na cor para fornecer informação

Devemo-nos assegurar que todas as informações fornecidas através de um código de cores podem ser visualizadas sem o uso da cor.

Nunca se deve usar apenas a cor como único meio de indicar atividades críticas. Cerca de 8% das pessoas de sexo masculino e 0.5% do sexo feminino têm dificuldades em distinguir as cores. A maior parte tem dificuldades em ver as cores no espetro verde.

Comparação de mensagens de sucesso e erro vistas por um utilizador com visão normal (à esquerda) e um com Deuteranopia, a forma mais comum de daltonismo (à direita).

Para assegurar que a informação é visível por todos os utilizadores:

• Escolher combinações de cores que possam ser distinguíveis por utilizadores daltónicos (existem aplicações que permitem simular como um daltónico vê as cores, ex: Color Oracle);
• Assegurar que existe um contraste suficiente entre o texto e a cor de fundo;
• Usar ícones representativos das ações ou das informações (ex: uma mensagem de erro pode vir acompanhada de um ícone correspondente em vez de vir apenas com texto a vermelho);
• Acompanhar sempre a cor de padrões, ícones ou legendas de modo a que a informação possa ser percebida caso a cor se confunda com outra cor.

Usar controlos de interface standard

Devem ser usados controlos e objetos (ex: botões, formulários, listas, etc) standard da plataforma para a qual se está a desenvolver, de modo a garantir a sua acessibilidade. Controlos costumizados têm uma grande probabilidade de não implementar todas as funcionalidades de acessibilidade disponíveis pelo sistema.

Por exemplo, os controlos em iOS incluem já descrições e funcionalidades que são compreendidas e lidas pelo sistema VoiceOver, enquanto que um controlo que não seja standard pode não ter essas funcionalidades.

Acompanhar sempre as notificações áudio de informação visual

Por exemplo, uma notificação de um alerta sonoro deve ser sempre acompanhada de uma notificação visual (e vice versa) de modo a que vários utilizadores (invisuais, surdos, etc) consigam ter acesso à informação disponibilizada nesses alertas.

Permitir que as definições de acessibilidade do sistema mudem o aspeto da aplicação

Por exemplo, se o utilizador indicar nas definições do sistema operativo que quer ver o texto em "Grande", as aplicações devem seguir essa indicação e aumentar os textos de acordo com o tamanho escolhido pelo utilizador.

Poderá ainda ser necessário garantir que existe uma versão de alto contraste ou que mostre as cores escolhidas pelo utilizador para texto/fundo, caso o sistema operativo o permita.

Durante muito tempo (e mesmo para algumas pessoas hoje em dia) quando se falava em acessibilidade, apenas se pensava em versões alternativas dos sites em texto para poderem ser lidas por sistemas de leitura de ecrã para invisuais.

A acessibilidade na web é muito mais do que isso. É permitir o acesso à informação de forma universal, para todos os utilizadores, independentemente das suas necessidades especiais.

E quando falamos em necessidades especiais, podemos estar a falar de um invisual, de um surdo, de uma pessoa com paralisia cerebral, ou até mesmo de utilizadores com outro tipo de "deficiências" como por exemplo uma deficiência tecnológica (usa um computador antigo; o rato está avariado) ou uma deficiência temporária (o braço que costumava usar o rato está partido e tem de usar o outro braço).

Assim, existem um conjunto de recomendações de acessibilidade que devem ser seguidas para que o acesso aos conteúdos seja universal e que todos consigam navegar e ler a informação disponível:

• Recomendações WCAG 1.0 (antigas, foram durante muitos anos a norma)
• Recomendações WCAG 2.0 (mais recentes, publicadas em 2008 para substituir as WCAG 1.0)
• Recomendações WAI-ARIA 1.0 para Rich Internet Applications
• Unidade Acesso da Fundação para a Ciência e Tecnologia (inclui artigos, ferramentas e muita documentação sobre acessibilidade em português)
• 20 dicas de HTML e CSS para tornar um website mais acessível sem grande esforço (apresentação feita por um dos membros da equipa UX do SAPO)

Como medir a acessibilidade?

Existem várias ferramentas online que permitem fazer uma verificação inicial de acessibilidade. Todos eles usam ou as WCAG 1.0 ou as WCAG 2.0 como base para mostrar os resultados, por isso o resultado num validador irá ser muito semelhante em outro validador. O que pode variar são as dicas de ajuda e resolução dos problemas que cada validador apresenta.

Uma vez que as WCAG 1.0 já estão obsoletas, recomendamos o uso apenas de validadores que usem as WCAG 2.0 como base. Alguns exemplos de validadores online são:

• Access Monitor - Validador da Fundação para a Ciência e Computação
• WAVE
• AChecker
• Checklist com as regras da W3C
• T.A.W.
• Lista completa de várias ferramentas de acessibilidade

O facto de uma ferramenta automática indicar que o site passa na validação não garante que seja acessível, mas está no bom caminho. O problema é que os validadores automáticos apenas conseguem validar itens que possam ser testados por uma máquina, ou seja, verificam o código HTML e procuram por padrões e problemas conhecidos.

Um validador automático tem mais dificuldades em verificar o contraste entre cores ou se os textos e elementos clicáveis são suficientemente grandes para poderem ser lidos e usados por todos os utilizadores.

Desta forma, sempre que possível, além da validação automática, recomendamos o teste com alguns utilizadores com necessidades especiais de modo a validar se o site é ou não totalmente acessível. Na impossibilidade de recrutar esse tipo de pessoas, podemos testar simulando alguns constrangimentos, como por exemplo:

• Tentar navegar no site usando apenas o teclado;
• Ligar o screen reader (em OS X basta ligar o VoiceOver; em Windows pode-se instalar o NVDA gratuitamente) e tentar navegar com os olhos fechados;
• Usar o site sentado a 1 e 2 metros do ecrã e ver se consegue ler os textos e se consegue navegar nos menus;
• Usar o rato com a mão não dominante e tentar clicar nos links e botões para perceber se utilizadores com mobilidade reduzida conseguiriam usá-los.

Nos capítulos seguintes, vamos listar algumas dicas e recomendações de acessibilidade que permitem tornar os websites mais acessíveis e que são normalmente de fácil implementação.

Vamos começar!

Desenvolver aplicações para a TV é um desafio.

Com o aparecimento das SmartTVs, Google TV, Amazon Fire TV, Roku, etc e aplicações interativas nas boxes dos operadores de televisão por cabo, começa a ser mais comum a possibilidade de desenhar apps para serem usadas em TV.

Existem inclusivamente algumas regras específicas para cada plataforma que devem ser seguidas se se estiver a desenvolver para as mesmas:

• Google TV Design Patterns
• Principles of designing applications for Samsung Smart TV
• LG Smart TV and Media product UI guidelines

Na plataforma MEO também existe uma grande quantidade de aplicações interactivas, muitas delas desenvolvidas pelo SAPO, e como tal, queremos partilhar algumas dicas de usabilidade a ter em conta no desenvolvimento para esta plataforma.

Tamanho do ecrã

Apesar do tamanho dos ecrãs de TV ser normalmente maior do que os ecrãs de computador, a sua resolução é menor. E apesar de ser possível fazer scroll, a experiência não é muito agradável e nada parecida com o scroll num browser no computador.

Assim, é necessário desenhar cada ecrã de forma que a informação importante caiba toda no ecrã. Se estivermos a desenhar para ecrãs HD com resoluções de 1980x1080px pode parecer que temos muito espaço para isso, mas não. A TV está normalmente na sala, a uma distânca de alguns metros do utilizador, pelo que todos os elementos têm de ser consideravelmente maiores do que seriam se estivéssemos a desenhá-los para um monitor com essa resolução.

No caso das apps do MEO temos ainda que contar com ecrãs que não são HD (ainda há muitos por aí), e que normalmente têm uma resolução de 720x576px (sistema PAL), mas esse não é o espaço que temos disponível para usar, pois as televisões com ecrãs CRT muitas vezes "comem" cerca de 20% do espaço nos limites do ecrã e temos de garantir que existe uma "safe area" a toda a volta do ecrã que não podemos usar para colocar conteúdo. Isto deixa-nos com cerca de 576x460px de área útil.

Diferenças na área útil entre ecrãs HD e SD

Dadas as diferenças brutais entre os dois tipos de ecrã, recomendamos que se desenhem duas versões da aplicação, uma para HD e outra para SD. No caso do MEO mantemos na mesma uma "safe area" nos ecrãs HD para garantir que não existe nenhum elemento textual ou de interação junto dos limites do ecrã, para um melhor conforto na legibilidade e navegabilidade das aplicações. O Google recomenda a mesma coisa para quem desenvolver apps para a Google TV e Chromecast.

Tamanho dos textos

Devido à distância a que normalmente os ecrãs de TV estão dos utilizadores, é necessário que os textos sejam claramente visíveis e legíveis para quem está sentado no sofá.

Na plataforma MEO, o tamanho mínimo para os textos no ecrã é de 16pt. Para outras plataformas recomendamos que se mantenha esta regra. Adicionalmente, devem ser usados apenas tipos de letra sans-serif.

Cor e contraste

Na TV não podemos usar todas as cores que queremos. Cores com muita saturação e algumas combinações de cores lado a lado tendem a criar um fenómeno chamado de "color bleeding", ou seja, as cores parecem sair fora da área em que é suposto estarem contidas, ou criam sombras ou desfocagens quando se usam duas cores "incompatíveis" lado a lado.

Exemplo de color bleeding num ecrã CRT

Também não se devem usar cores muito claras, como por exemplo um branco puro. Em determinadas TVs, sempre que aparece algo no ecrã que use a cor branca pura, parece ouvir-se um som de "bzzzzzzz". Isto acontece porque as cores demasiado claras e saturadas ocupam uma parte do sinal que era suposto ser exclusivo da faixa de som, num fenómeno parecido com o "color bleeding" mas que passa para o sinal sonoro da emissão.

Em termos de legibilidade, numa TV é mais fácil ler textos claros sobre fundo escuro do que textos escuros sobre fundos claros.