Apesar do artigo apontar apenas os problemas identificados e não apontar sugestões de melhoria, é natural que alguns leitores achem que estamos apenas a “mandar abaixo” e a “dizer mal” em vez de estarmos calados no nosso canto.

Pessoalmente, custa-me que o artigo tenha apenas os pontos negativos e custa-me estar associado ao grupo de “velhos do restelo” que só dizem mal de tudo e de todos.

Acho que a empresa que desenvolveu o website do Portal do Governo não fez um mau trabalho. A sério. Todos os dias vemos enormes aberrações no nosso browser e ninguém se queixa nem se fazem artigos no jornal.

Mas o problema é que o Portal do Governo é, um site do governo. E como site do governo, tem de cumprir as regras estabelecidas pela resolução do conselho de ministros que obriga a que os websites da Administração Pública sejam compatíveis com a norma A de acessibilidade (os sites transaccionais são obrigados a passar a norma AA).

Quando digo que a empresa que criou o site fez um bom trabalho, refiro-me ao grafismo bastante apelativo, às páginas com conteúdos bastante interessantes (ex: para onde vão os seus impostos) e nada normais àquilo a que normalmente estamos habituados nos sites do estado (aborrecidos e demasiado institucionais). Fizeram também um bom trabalho, pelo menos para tentarem passar nos validadores automáticos de acessibilidade (apenas são detectados pequenos erros). Ou seja, eles pelo menos tentaram, e têm todo o mérito por isso.

Mas faltou-lhes só um bocadinho assim.

E é esse bocadinho que dá origem ao artigo e à onda de protestos pro e contra a falta de acessibilidade do website.

É claro que os problemas que restaram são problemas graves, como a impossibilidade de navegar com o teclado (ou qualquer outro dispositivo não apontador) ou a clara falta de contraste na cor dos textos (idosos e míopes vão ter dificuldade em ler). Mas são tudo pequenas coisas que em menos de 1 hora eram facilmente resolvidas mudando 2 ou 3 linhas no CSS e eventualmente fazendo alguns ajustes no HTML (para melhorar a estrutura dos headings). Isto tudo são problemas que os validadores automáticos remetem para uma validação manual, que ficou por fazer.

E para quem diz que apenas estamos aqui para mandar abaixo, há dois meses atrás fiz uma apresentação sobre como melhorar a acessibilidade de um website mudando apenas alguns pedaços de HTML e CSS. Nessa apresentação estão disponíveis as soluções que faltam para o site do Portal do Governo (infelizmente essa informação não saiu no artigo, apesar de ter sido fornecida) e outras que toda a gente pode aplicar nos seus websites, em menos de 1 hora.

Podem ver a apresentação aqui.

Sobre os comentários que apontam o SAPO como tendo também problemas de acessibilidade, é provável que os tenha, mas tentamos ao máximo fazer cumprir as nossas regras de usabilidade e acessibilidade aos nossos produtos.

Um dos exemplo apontados foi o facto de na homepage do SAPO não ser possível navegar com o teclado. Isso não é verdade. A navegação com o teclado é possível e o feedback é apropriado (damos sempre visibilidade ao link seleccionado). No entanto, por questões comerciais (às vezes o dinheiro fala mais alto), fomos obrigados a fazer “focus” no campo da pesquisa, o que faz com que os “skip-links” (que existem) deixem de ter o efeito desejado. Se clicarem fora da pesquisa e começarem a navegar com a tecla TAB verão os atalhos para as zonas mais importantes da página.

Por isso, todos os dias lutamos para tornar os nossos websites mais fáceis de usar e acreditem que não é fácil porque temos que justificar sempre muito bem as nossas decisões.

Mas nada melhor do que ver um utilizador invisual ou com paralisia cerebral a tentar executar uma tarefa num website, e ver o seu desespero durante 10 minutos a tentar executar uma tarefa que um utilizador “normal” faria em 10 segundos. Isso, meus caros, mudará completamente o vosso ponto de vista quando falarem sobre acessibilidade.

É costume ouvir estes responsáveis dizer que não precisam de se preocupar com a acessibilidade porque não têm utilizadores com necessidades especiais (pessoas com algum tipo de deficiência) a usar o site, ou se têm, são poucos. Algumas das principais desculpas são porque é preciso mais desenvolvimento para criar/alterar o site, e dá mais trabalho… No entanto, é impossível saber se há ou não utilizadores com algum tipo de deficiência a usar o site. Nas estatísticas, um utilizador com necessidades especiais é contabilizado como sendo um utilizador igual aos outros.

Os dados que existem actualmente para contabilizar o número de pessoas com necessidades especiais em Portugal são escassos e que eu saiba ainda não foi feito nenhum estudo dedicado ao uso da web por estas pessoas.

Numa pesquisa rápida pelo site do Instituto Nacional de Estatística descobri um estudo sobre o Enquadramento familiar das pessoas com deficiência (baseado nos Censos de 2001) que contém alguns dados interessantes.

Em 12 de Março de 2001, o recenseamento da população apurou 636 059 pessoas com deficiência (6,1% da população residente total) distribuídas pelos seguintes tipos de deficiência:

• Auditiva: 13,2%
• Visual: 25,7%
• Motora: 24,6%
• Mental: 11,2%
• Paralisia Cerebral: 2,4%
• Outras: 23%

Podem parecer poucos (felizmente), mas não deixa de ser uma fatia importante da população que também deve ter acesso à informação, tal como todos os outros. Ao tornarmos um website mais acessível, estamos a facilitar a vida a estas pessoas, quer sejam deficiente visuais que usem um screen-reader, ou deficientes motores que usem outros dispositivos apontadores em vez do rato.

Aliás, é mais provável que estas pessoas usem mais a web no dia-a-dia do que o mundo físico. Imaginem fazer compras num hipermercado sem conseguir ver. É muito mais fácil (se o site for minimamente acessível) fazer as compras online do que andar a vaguear pelos corredores do hipermercado sem quaisquer pistas auditivas ou tácteis para saber que tipo de produtos estamos a comprar.

Criar um site acessível (ou transformar um site já existente) não é uma tarefa complicada. Não dá assim tanto mais trabalho do que o normal (talvez no início seja necessário investir algum tempo a investigar como é que se deve fazer o site, mas após algum tempo é muito mais fácil e directo).
E se estamos a tornar um site mais fácil de usar para pessoas com necessidades especiais, estamos também a torná-lo mais fácil de usar para todos os outros.

Para a nova homepage desenvolvemos várias metodologias de usabilidade cujos resultados podem ser consultados em detalhe no blog oficial da Homepage:

• Estatísticas, Inquéritos, Brainstorming, Testes de Usabilidade e Eyetracking
• Wireframes
• Versão Beta e os resultados dos inquéritos aos utilizadores

Além de tudo isto, tivemos também uma grande preocupação com a Acessibilidade, garantindo que a página tem uma classificação AAA segundo o WCAG 1.0.

Em termos técnicos utilizámos as mais recentes tecnologias como HTML5 e CSS3, o que nos permite ter o site preparado para o futuro e aproveitar algumas funcionalidades do HTML5 (que pretendemos colocar online em breve). Infelizmente, o facto de usarmos HTML5 invalida (para já) que consigamos ter o site a passar totalmente na validação de acessibilidade WCAG 2.0 uma vez que o validador ainda não reconhece as novas tags do HTML5.
Esperemos que em breve possamos testar convenientemente a página (assim que o validador suporte HTML5) e garantir também o máximo de acessibilidade segundo estas guidelines mais recentes.

O objectivo do evento é promover a discussão sobre a importância das tecnologias assistivas e ajudas técnicas no processo de reabilitação e no dia-a-dia das pessoas com deficiência, com mobilidade reduzida, permanente ou temporária, idosos e seus familiares, cuidadores, profissionais da saúde, educadores e, em grande medida, de toda a sociedade, cada vez mais diversa e inclusiva.

Mais informações em http://simparatodos.com.br

Durante a apresentação foram mostrados alguns dados bastante interessantes. Aqui estão alguns que retirei da minha cobertura em directo do evento no Twitter:

• Em Portugal existem cerca de 630.000 cidadãos com algum tipo de deficiência;
• Na Europa este número chega aos 37 milhões de cidadãos com algum tipo de deficiência;
• Das 1000 maiores empresas portuguesas, 172 tinham o site offline/em manutenção;
• 51 dos sites foram desenvolvidos exclusivamente em Flash ou usando demasiado JavaScript o que criou uma barreira de acessibilidade ao próprio mecanismo de validação;
• Apenas sobraram 777 sites para a análise de acessibilidade (usaram o TAWDIS para fazer uma avaliação automática de 30 páginas em cada site usando o WCAG 1.0);
• Foram encontrados muitos mais erros de prioridade 2 e 3 do que erros de prioridade 1;
• Havia sites com mais de 40.000 erros (no somatório da avaliação das 30 páginas);
• As empresas foram divididas por sectores de actividade e as da “Saúde” obtiveram claramente os piores resultados;
• As empresas do sector de actividade da Agricultura foram as que tiveram melhores resultados;
• Das 777 empresas, apenas 1 cumpre o nível AA e 73 cumprem o nível A. Nenhuma cumpre o nível máximo de acessibilidade AAA;
• Foi feita uma comparação com os websites das 1000 melhores PMEs contra as 1000 maiores empresas em Portugal. As PMEs tiveram melhores resultados sendo que 1 cumpre o nível AAA, 1 cumpre o nível AA e 145 cumprem o nível A.

No final da apresentação foram feitas várias recomendações para melhorar a acessibilidade, mas essencialmente para chamar a atenção das pessoas para a importância de ter um website acessível. Recomendo vivamente a leitura do documento.

Relatório Acessibilidade Web da APDSI (PDF – 672KB)

Segundo a APDSI, a seguir vão fazer a análise de acessibilidade aos mesmos websites, mas com base no WCAG 2.0 para verificar se com as novas recomendações de acessibilidade os sites obtém melhores ou piores resultados.

Esta é uma conferência para todos os profissionais web que querem criar aplicações e sites que funcionem para toda a gente e em todas as circunstâncias.

Os participantes são convidados a desenvolver “hacks” para tornar acessíveis os sites inacessíveis. No ano passado foi criada uma versão do YouTube mais acessível e fácil de usar (EasyYouTube) e este ano espera-se que se continuem a criar alternativas para permitir o acesso universal à informação.

Os pontos altos da conferência deste ano são:

• Inclusive Design, por Mark Boulton
• Understanding Deafness: History, Language and the Web, por Lisa Herrod
• Accessibility with HTML 5 and WAI ARIA, por Steve Faulkner
• Painel de discussão sobre Accessibility beyond the desktop, com Henny Swan (Opera), Veronika Jermolina (AbilityNet), Damon Rose (BBC Ouch), entre outros
• Silverlight Accessibility, por Saqib Shaikh (Microsoft)
• Considerations for Accessible Mobile Application Graphical User Interface (GUI) Design, por Greg Fields (Blackberry)

Os bilhetes estão disponíveis por cerca de €216 (€112 para estudantes).

Este trabalho, realizado pelo Grupo de Trabalho Permanente “Negócio Electrónico”, pretende analisar a acessibilidade dos sitios web das 1000 maiores empresas Portuguesas em volume de negócio.
O relatório será apresentado no dia 17 de Setembro pelas 17:00 horas no Átrio da Casa do Futuro da Fundação Portuguesa das Comunicações.

A inscrição é gratuita mas obrigatória, através dos contactos:

• E-mail: secretariado@apdsi.pt
• Telefone: 217 510 762

Ver mapa maior

Basicamente falei um pouco sobre o que é a acessibilidade, a quem se destina e dei alguns exemplos dos principais problemas de acessibilidade que costumamos encontrar e como os resolver. Nada de muito aprofundado, foi apenas para dar a ideia de que não é difícil fazer um website acessível, basta ter atenção apenas a alguns detalhes e ter o mínimo de preocupação em criar HTML limpo e semântico.

Ver no SAPO Vídeos (para terem a opção de ver em ecrã inteiro)

Podem fazer download dos slides em PDF aqui:

Acessibilidade na Web (PDF – 7.2 Mb)

Para esta primeira edição o tema foi Web Development e contámos com as seguintes apresentações (clicar nas apresentações para ver os slides e o vídeo):

• CSS for Beginners, por Pedro Couto e Santos
• Acessibilidade na Web, por Ivo Gomes
• HTML, por André Torgal

O objectivo é que as apresentações sejam mais práticas do que teóricas e que no final os participantes possam sair com novos conhecimentos que possam aplicar nos seus projectos.

Esta primeira edição foi apenas para consumo interno do SAPO, mas a ideia é abrir as inscrições (que são gratuitas) para quem estiver interessado. Infelizmente, a lotação da sala (80 lugares) não nos permite, para já, abrir estas sessões ao público em geral, mas estamos a trabalhar para isso

A Direcção-Geral de Arquivos (antigo IAN/TT – Instituto dos Arquivos Nacionais / Torre do Tombo), devido às mudanças que houveram na instituição, passou a estar separada da Torre do Tombo. Assim, hoje temos a Direcção-Geral de Arquivos e o Arquivo Nacional da Torre do Tombo. Desta forma, teríamos que desenvolver dois websites distintos, mas mantendo a mesma linha gráfica.

Além do website principal (DGARQ) e do website dos arquivos nacionais (ANTT), a DGARQ é também responsável por 16 Arquivos Distritais, dos quais, 9 ainda não tinham website. Como parte do projecto, seria também necessário desenvolver os websites para os 9 Arquivos Distritais mantendo a mesma linha gráfica do website principal.

No total, foram 11 websites ao mesmo tempo

Apesar de já termos terminado os desenvolvimentos há cerca de um mês, ainda faltava a validação dos conteúdos em todos os websites, feita por cada uma das instituições. O website da DGARQ foi o primeiro a ser lançado, os restantes vieram algumas semanas depois.

Aqui estão os links quer para o site principal, quer para todos os sub-sites:

• Direcção-Geral de Arquivos
• Arquivo Nacional da Torre do Tombo
• Arquivo Distrital de Aveiro
• Arquivo Distrital de Beja
• Arquivo Distrital de Castelo Branco
• Arquivo Distrital de Évora
• Arquivo Distrital de Lisboa
• Arquivo Distrital de Portalegre
• Arquivo Distrital de Santarém
• Arquivo Distrital de Setúbal
• Arquivo Distrital de Viana do Castelo

Screenshots

Direcção-Geral de Arquivos

Gestão de Conteúdos

Para a gestão dos 11 websites usámos o WordPress MU uma vez que era necessário manter toda a gestão centralizada num único local e que o interface de introdução de conteúdos fosse o mais simples de usar possível.

Do ponto de vista do utilizador que tem que inserir e gerir conteúdos, penso que o WordPress é a melhor opção devido à sua facilidade de uso e, até agora, o feedback que tivémos dos utilizadores foi sempre positivo.

Acessibilidade

Conseguimos manter o nível AA em todas as páginas, no entanto há um ponto de verificação que, sempre que aparece uma imagem no meio do texto, falha. Isto acontece por que o ponto 3.4 das regras de acessibilidade (WCAG 1.0) indica que não devem ser usadas medidas de unidades absolutas, apenas relativas. Isto é, não devemos usar medidas fixas, mas sim medidas flexíveis, como por exemplo, percentagens.

O que acontece é que o WordPress adiciona uma DIV à volta das imagens para poder adicionar uma legenda (CAPTION) e indica uma largura em pixels para essa DIV. O validador automático detecta que há um elemento na página com largura definida em pixels e dá o erro.

Penso que o validador automático leva esta regra demasiado à letra, ou seja, tudo o que tiver uma dimensão definida em pixels, é considerado inválido. Convém salientar que as regras em que os validadores automáticos se baseiam actualmente são as do WCAG 1.0 criadas há 9 anos atrás. Nessa altura fazia sentido que os elementos não tivessem medidas fixas porque os browsers ainda não suportavam bem elementos gráficos nem o aumento/redução do tamanho do texto, mas hoje em dia esta regra deixou de fazer sentido. A versão actual das regras de acessibilidade (WCAG 2.0) já eliminou este ponto de verificação que foi considerado obsoleto.

Não é isto que vai fazer com que o site seja menos acessível, mas é chato quando dizemos ao cliente que o site passa na validação AA e ele depois vai ao validador e vê este erro… Infelizmente ainda não encontrei forma de evitar isto, uma vez que é o próprio WordPress que adiciona essa DIV à volta das imagens.

Créditos

Além da restante equipa da log que esteve envolvida no projecto, tivémos também a colaboração do Filipe Serrazina que me ajudou na parte do web design e XHTML+CSS+JS (uma vez que eram 11 websites ao mesmo tempo, a ajuda do Filipe foi preciosa).

http://acessibilidade.cm-lisboa.pt/

Achei interessante a ideia, mas mais interessante é o facto do site ser muito pouco acessível. Além de utilizar frames (o site usa uma só frame, pelo que desconheço a razão que os levou a criar o site assim), só na página inicial foram encontrados 15 erros de acessibilidade, a maior parte devido a imagens sem texto alternativo (ainda há gente que comete este erro?) e alguns eventos de mouseover inseridos directamente no código (podia ser feito de forma não intrusiva usando JQuery, por exemplo). Além disso, o tamanho do texto é demasiado pequeno para poder ser lido com alguém com menos acuidade visual.

Pode não ser suficiente para impedir que alguém com necessidades epeciais consiga aceder ao site, mas já que se trata de informação sobre acessibilidade, podiam ter-se esforçado só um pouco mais para cumprir as regras mínimas. Só lhes ficava bem e não custava nada

Hoje não vou falar da experiência web, mas sim da experiência do atendimento automático e a sua usabilidade (ou falta dela). Como tal, apenas vou falar da experiência da comunicação das leituras de agua e gás.

EPAL

Fiquei bastante satisfeito com o atendimento fornecido pela EPAL. Normalmente este tipo de atendimentos costuma ter uma voz de mulher, mas no caso da EPAL é um homem. Ao contrário de outros sistemas automáticos em que a voz parece a de um robô, esta voz era simpática e tinha um tom calmo e, explicando calmamente e detalhadamente o processo de comunicação da leitura: “por favor comunique apenas os algarismos com fundo preto e descarte os que têm fundo vermelho”.

A voz que confirma os valores inseridos é uma voz de mulher. Não sei porque mudaram o locutor, mas uma vez que era apenas a leitura do número que inseri, se calhar quiseram dar um ênfase maior, colocando uma voz diferente.

No final da leitura: “para confirmar o valor inserido, marque 3, para corrigir, marque 1″.

Ok, foi fácil. Aposto que qualquer pessoa consegue ligar para a EPAL e fazer a comunicação da leitura da água.

Lisboa Gás

Depois foi a vez da comunicação da leitura do gás. Neste caso, o atendimento foi com a normal voz de mulher robótica, com a particularidade de haver duas vozes diferentes em várias fases do processo. Não foi como no caso da EPAL em que a voz de mulher apenas serviu para confirmar o número introduzido. No caso da Lisboa Gás, temos uma mulher que nos dá as boas vindas e outra que nos dá a ordem para inserir a leitura. Depois volta novamente para a voz inicial. Até aqui tudo bem, desde que se perceba o que elas dizem, não há problema.

O problema está nas instruções para a comunicação (ou falta delas). No caso da EPAL foi claramente indicado para comunicar apenas os valores com fundo preto e descartar os de fundo vermelho. No caso da Lisboa Gás, nada. Apenas: “comunique a sua leitura”.

No final: “para a confirmação da leitura marque cardinal, para corrigir, marque 1″

Ora, há muita gente que não sabe qual é a tecla cardinal e muitas confundem com o asterisco. Porque é que não pediram simplesmente para marcar um número como no caso da EPAL?

Para quem nunca comunicou uma leitura via telefone e o fizer pela primeira vez usando o serviço da Lisboa Gás, não tenho duvidas que terá algumas dificuldades em o fazer. Porquê complicar um processo tão simples que provavelmente até será usado (também) por pessoas com baixa escolaridade que podem não perceber imediatamente o que lhes é pedido? 

Tal como já disse anteriormente, fiquei bastante satisfeito com o serviço da EPAL e um pouco desiludido com o da Lisboa Gás. Para a próxima, uso também o serviço telefónico da EDP só para ver como é.

Estes 10 exemplos mostram aquilo que NÃO DEVE SER FEITO, mas que costumamos ver recorrentemente

1. Usar frases grandes no texto ALT das imagens

Alguns web designers costumam inserir demasiado texto alternativo (ALT) nas imagens na esperança de que isso irá ajudar os utilizadores com leitores de ecrã. No entanto, o texto ALT deve ser curto e sucinto, e não deve conter mais informação do que aquela que é transmitida pela imagem. As imagens decorativas devem ter um ALT nulo (alt="") de forma a serem ignoradas pelos leitores de ecrã.

2. Usar caracteres aleatórios para separar os links

Uma das regras de acessibilidade indica que os links adjacentes (consecutivos) devem ser separados por algum texto sem link uma vez que alguns browsers muito antigos tinham alguns problemas com os links dispostos desta forma. Esta regra já não é relevante apesar de continuar a ser recomendada pelos sistemas de verificação automática, por isso os caracteres que se costumam usar para separar os links (normalmente costuma-se usar uma barra vertical “|”) são anunciadas aos leitores de ecrã como “barra vertical”, o que atrapalha bastante a navegação destes utilizadores na página.

3. Inserir texto nos campos vazios dos formulários

Outra recomendação antiga e desactualizada indica que os campos dos formulários devem conter um texto de exemplo. Esta regra foi criada porque os antigos leitores de ecrã não conseguiam encontrar os campos que se encontravam vazios. Actualmente, todos os leitores de ecrã conseguem identificar todos os campos dos formulários, pelo que esta regra pode ser ignorada.

4. Usar teclas de atalho

Podemos associar uma tecla de atalho para aceder a um determinado link através do teclado. No entanto, estas teclas de atalho sobrepõem-se às teclas dos leitores de ecrã, tornando-as inúteis. O outro problema das teclas de atalho é o de não haver nenhum standard, por isso os poucos sites que as implementam usam as teclas que bem lhes interessam, tornando difícil a criação de um modelo mental que funcione de mesma forma em todos os sites.
Em termos de acessibilidade, o uso destas teclas pode ser mau, mas em termos de usabilidade pode ser algo muito bom. A navegação pelo teclado é muito mais rápida do que a navegação com a movimentação do rato+clique. Por isso, neste aspecto é necessário criar um compromisso. Se queremos melhorar a acessibilidade, não usamos teclas de atalho, mas se queremos melhorar a usabilidade, podemos usar o teclado, desde que as teclas seleccionadas não se sobreponham às teclas de atalho do próprio browser e que haja uma página que explique todos os atalhos existentes.

5. Usar resumos nas tabelas (só são importantes se adicionarem valor à tabela)

Os leitores de ecrã lêm em voz alta o resumo das tabelas (summary="resumo") antes de iniciarem a leitura dos dados. Alguns websites que usam tabelas para o layout às vezes adicionam estes resumos do tipo summary="tabela de layout", o que não traz nenhum valor à tabela e só atrapalha a navegação de quem usa um leitor de ecrã.

6. Esquecer os conteúdos

A forma como os conteúdos estão estruturados na página é uma grande parte da acessibilidade da mesma. Um website pode ter um código perfeito e estar em conformidade com o nível mais elevado de acessibilidade, mas se os conteúdos estiverem mal estruturados, o site será de difícil navegação ou até impossível para alguns utilizadores com necessidades especiais.
É necessário assegurar que os conteúdos sejam disponibilizados em pequenos pedaços (parágrafos) e acompanhados de um título (cabeçalho). Devem também ser usadas listas (<ul> ou <ol>) sempre qur for apropriado e uma linguagem simples e directa.

7. Preocupar-se com grandes declarações sobre a acessibilidade

Muitos sites desenvolvidos a pensar na acessibilidade costumam ter páginas bastante extensas a explicar as funcionalidades de acessibilidade que foram implementadas. Com ou sem necessidades especiais, os utilizadores não costumam consultar as páginas de “ajuda” de nenhum site. Em vez disso, preferem experimentar e descobrir por eles próprios (a não ser que o site seja mesmo muito difícil de usar, e aí passamos a ter um problema de usabilidade). Apesar de não haver nada de errado em ter uma página a explicar que o nosso site é acessível, não é necessário perder muito tempo com isso.

8. Agonizar com os acrónimos e abreviações

Declarar se alguma palavra é um acrónimo ou uma abreviação é facil de fazer em HTML usando as tags <acronym> ou <abbr>. A maior parte dos leitores de ecrã não suportam estas funcionalidades, por isso não será um grande benefício para os utilizadores com necessidades especiais. Até alguns browsers como o Internet Explorer 6 não suportam este tipo de tags, nomeadamente a <abbr>, pelo que também não se deve perder muito tempo com isso.

9. Alterar a ordem das tabulações (a não ser que haja uma boa razão para isso)

O atributo tabindex pode ser usado para alterar a ordem da tabulação da página (navegação com o teclado usando a tecla TAB), mas raramente é necessário. Os browsers e leitores de ecrã costumam navegar nos sites pela ordem em que os elementos se encontram no HTML. Desde que a navegação seja feita do canto superior esquerdo para o canto inferior direito (o que normalmente acontece) então a ordenação das tabulações está perfeitamente adequada e não necessita de ser alterada.

10. Esquecer-se de ouvir o site num leitor de ecrã

Enquanto estiver a desenvolver um website acessível, não se esqueça de experimentar ouvi-lo num leitor de ecrã para se assegurar que as funcionalidade de acessibilidade funcionam correctamente e que o site é navegável. Além disso, também é recomendável navegar no site usando um browser de texto (ex: Lynx).

Outras considerações

Apesar de haverem regras de acessibilidade que podemos ignorar (ver pontos 2, 3 e 5), quando estamos a desenvolver um website cujo requisito é passar no teste de acessibilidade, por vezes temos mesmo que aplicar essas regras. Isto porque o cliente se poderá queixar de que o seu site não passa no validador X e que nós lhe tínhamos assegurado que o site iria ser acessível e passaria nos testes.

Isto passa-se por exemplo nos sites da Administração Pública que foram obrigados a cumprir as regras mínimas de acessibilidade e que após terem sido implementados há sempre alguém que vai correr a validação de acessibilidade e verificar se passa em todos os pontos, caso contrário o site é tirado do ar. Por isso, dependendo dos casos, as regras terão que ser cumpridas à risca, apesar de já estarem um pouco desactualizadas da realidade.

Hoje vejo que já têm um novo site, mais bonito e mais “clean” que o anterior (em termos visuais). No entanto há alguns aspectos menos positivos nesta nova versão. Para começar, a previsão do tempo no mapa requer o plugin Flash. Apesar de não ser totalmente contra o uso do Flash, penso que neste caso poderia ter sido evitado uma vez que o site pode ser consultado através de dispositivos móveis que não possuem essa tecnologia ou mesmo por causa da acessibilidade (apesar de terem uma versão HTML com uma tabela com o tempo para cada cidade, o link está um pouco escondido e os dados da tabela não estão estruturados de forma acessível).

Tirando a parte visual, que gosto (exceptuando o facto do mapa estar um pouco “atarracado”), o código em si não esta grande coisa, com muitas tabelas no meio do HTML e pouca ou nenhuma semântica (não usam cabeçalhos nos titulos nem nas tabelas), isto para não falar dos inumeros erros de HTML.

Em termos de acessibilidade, nao está assim tão mau, contendo apenas alguns erros resultados do uso de código HTML inválido. Apenas o facto de usar Flash para mostrar a previsão no mapa estraga este ponto.

Só para comparação, aqui vai um screenshot da nova versão do site do Intituto de Meteorologia com a maquete desenhada por mim na altura em que fizemos a proposta.

Versão Actual

A minha maqueta

De notar que a minha versão é apenas uma maquete e foi o primeiro esboço, por isso, pode não estar tão apelativa visualmente

Da comparação entre as duas versões, no novo website acho que é de difícil visualização o menu para escolha do dia/hora em que se quer ver a previsão. Penso que em termos de usabilidade, a versão que desenhei tornava esse menu mais visível e mais fácil de usar.

Outra funcionalidade que tambem não foi implementada é a listagem do tempo nas cidades mais importantes nos próximos dias (com a possibilidade de definir outras cidades depois do login). Na anterior versão e nesta nova, continua a ser necessário seleccionar um dia/hora em cima do mapa para ver o tempo nos próximos dias (agora com a versão em Flash é mais rápido do que na versão anterior, mas mesmo assim, podem ser cliques desnecessários). Finalmente, outra coisa que me irritava um pouco no site anterior (e neste continua na mesma) é o facto de ao clicar numa cidade não ter acesso à meteorologia para essa mesma cidade. Em vez disso, é necessário aceder ao item “tempo na cidade” que está no fundo do mapa e depois escolher um das cidades num menu dropdown. Seria muito mais fácil clicar na cidade directamente no mapa…