Planejando interfaces Web acessíveis

Update no endereço… Avenida Presidente Wilson 164 – 12º andar

A Synapsis DI está com uma parceria bem legal de desenvolvimento com a 288 Design. Eles estão começando agora com algumas atividades e eu sugeri para eles alguns temas legais para fazer algumas palestras curtinhas, recheadas de exemplos práticos. Eu vou dar a primeira delas sobre acessibilidade:

288 atividades: Planejando interfaces Web acessíveis
A acessibilidade numa interface Web começa antes da fase codificação. Ela toma forma no briefing com o cliente. É ali que se define o público-alvo e que tipo de interação será exercida. Planejar interfaces acessíveis desde a fase zero do projeto é o melhor caminho para a experiência do usuário, seja ele qual for.

Data e hora:
Terça-feira, 9 de outubro de 2007, das 9 às 12 horas

Local: Avenida Presidente Wilson, 164 – 12o. andar – Centro – Rio de Janeiro

Mais informações

Tags: , ,

Jornada em acessibilidade na Web

O Seprorj está promovendo uma série de jornadas todas as quartas-feiras para os profissionais de informática. O primeiro deles é sobre Acessibilidade com o grupo de pesquisa Acesso Digital, o mesmo do vídeo Acessibilidade na Web: Custo ou Benefício?.

A taxa de participação é R$ 420,00 e as inscrições podem ser feitas pelo telefone(21) 3974 5015 com Aline ou pelo e-mail curso@riosoft.softex.br.

SEPRORJ
Rua Buenos Aires 68, 14o andar
Centro – Metrô Uruguaiana
Rio de Janeiro
27 de junho de 2007
das 8hs às 17hs.

Tags:

Acessível para quem?

O discurso politicamente correto da acessibilidade na Web está esgotado e deu poucos resultados. Precisamos de numa nova estratégia? Não, apenas precisamos enxergar bem mais longe do que isso.

Qualquer dicionário de bolso traz uma definição bem clara e precisa sobre acessibilidade:

acessibilidade
do Lat. Accessibilitate. s. f., qualidade de ser acessível; facilidade na aproximação, no trato ou na obtenção.
Priberam Informática – Língua Portuguesa On-Line

Não sei como, mas todos ficaram obcecados com a idéia de que acessibilidade serve apenas para usuários portadores de alguma deficiência visual. Nem mencionam miopia, hipermetropia, daltonismo ou qualquer outro defeito de percepção visual: acessibilidade é para quem possui baixa visão ou cegueira e ponto final. Desta forma, não há cliente ou chefe que seja convencido a pagar a mais pela verificação de acessibilidade de um código, mesmo que a especificação seja criada para impedir qualquer tipo de obstáculo ao acesso a qualquer tipo de usuário.

Somos todos míopes

Esta percepção também é uma herança de nossa arrogância nos primeiros anos do desenvolvimento Web. Focamos o projeto em um público-alvo bem específico e construímos o melhor do mundo para estes usuários.

Anos atrás, durante um curso de usabilidade, participei de um grupo que fazia um teste em um website de uma montadora de veículos. O site era inteiramente em Flash, daqueles altamente “interativos” com efeitos de som para cada botão na interface. Quesítionados se algum portador de deficiência visual poderia ter acesso àquela informação, chegamos à conclusão que cegos não precisam acessar sites de carros e partimos para o ponto seguinte. Qualquer discussão com este foco acaba sempre em um beco sem saída.

Olhando um pouco mais para o futuro onde usaremos mais dispositivos móveis e mais computação ubíqua, será que poderemos usar um site projetado para computadores desktop e obter a mesma experiência em um celular? Talvez esta interface consiga ser acessível de qualquer outro dispositivo que não um computador com teclado e mouse, mas eu não apostaria meu emprego nisso.

Imagine um usuário Web avançado usando seu smartfone num táxi. Ele deseja comprar um carro novo. Neste instante, passa por ele um modelo 2008, incrível, de sua montadora favorita. Imediatamente, ele sente vontade de acessar o website da montadora para verificar as especificações do carro e condições de financiamento. Este usuário pode estar a um passo da decisão de compra do produto, mas se ele não conseguir acessar imediatamente, como ele está acostumado a fazer, o desejo esfria e a memória sobre o modelo vira fumaça.

Robôs: os preteridos

Numa era onde falta apenas enviar flores com dedicatórias amorosas para o GoogleBot para convencê-lo a indexar as páginas com mais atenção e carinho, não acredito que ninguém pense na sua acessibidade. Afinal, ele é um usuário como qualquer outro.

Bem, isso não é inteiramente verdade. O GoogleBot ainda não passou no Teste de Turing, é totalmente cego e surdo, não entende JavaScript, entende muito pouco de Flash, entre outras limitações que o distinguem de um navegador moderno e de um usuário humano. Poucos usuários devem ser tratados com tanto amor e ao mesmo tempo são tão desprezados pela maior parte dos desenvolvedores Web.

WCAG não é tudo na vida

A principal lista de verificação de acessibilidade em uso é WCAG 1.0. É um documento de oito anos numa mídia onde tudo muda de um ano para o outro. Não é exatamente o que podemos chamar de confiável. Há vários parâmetros interessantes, mas outros passam batidos.

Por exemplo: muitos afirmam que para uma interface ser acessível ele não precisa ser construído com marcação semântico e CSS design. E ele de fato consegue passar um site montado com tabelas em um verificador automático e conseguir o selo de conformidade que desejar, mas ele não cumpriu o WCAG 1.0 de verdade e nem conseguiu uma interface realmente acessível. O desenvolvedor foi iludido porque considerou apenas o mundo ideal de acesso usando um computador desktop. Em qualquer outro dispositivo o acesso à informação fica seriamente comprometida. Além disso, há várias citações à marcação semântica na lista, como nas seções 2, 3 e 11.

Há uma nova versão do rascunho do WCAG 2.0. A principal diferença entre este e seu antecessor é que o foco saiu dos usuários com necessidades especiais e o W3C passou ambicionar que a Web atinja realmente todos usuários, “independentemente do seu equipamento, software, infra-estrutura de rede, idioma, cultura, localização geográfica, ou habilidade mental ou física” [W3C in 7 points]. Ainda é um rascunho e não há verificadores automáticos para ele. Por enquanto, segue a regra: não faça do WCAG uma verdade absoluta. O seu julgamento enquanto usuário, desenvolvedor e testador é bem mais importante do que um selinho de conformidade gerado por um robô.

Além disso, o grupo WCAG Samurai fez uma revisão interessante sobre a lista de verificação original do W3C.

O melhor verificador

A solução mais fácil para garantir a acessibilidade de um dispositivo é ser simples. Construa as interfaces do seu website ou seu webapp respeitando os padrões Web e acrescente as camadas de aprimoramento da experiência do usuário aos poucos. Não faça com que este aprimoramento se torne um obstáculo. Se for importante para conseguir o reconhecimento de algum verificador automático para exibir um selo de conformidade, é necessário apenas seguir as especificações tomando um ou outro cuidado especial de acordo com o tipo de elemento utilizado.

O compromisso com a acessibilidade vai além de um selo de conformidade. Leia de novo todas as tags XHTML e seus atributos. Desta vez, preste atenção onde é possível melhorar a acessibilidade. Nos formulários mais complexos das webapps, abuse dos atributos accesskey e tabindex para otimizar a realização da tarefa. Verifique mesmo o conteúdo alternativo de elementos multimídia para melhorar a indexação do documento por um mecanismo de busca.

A verificação de acessibilidade é uma tarefa diária no desenvolvimento Web e é responsabilidade de todos na equipe. Cada um tem uma pespectiva própria de uma interface e deve opinar no código sim. No desenvolvimento de aplicativos, é importante o acompanhamento do usuário realizando a tarefa. Nos testes de usabilidade, leve alguém que entenda de marcação HTML que possa ajudar a criar atalhos para os usuários avançados, identificar quais conteúdos podem ser omitidos ou mostrados de acordo com a mídia utilizada, entre outros fatores.

Palestra sobre planejamento de interfaces acessíveis para Web

Em outubro, fiz uma palestra (na realidade, uma mesa redonda) para discutir o projeto de interfaces Web acessíveis para a maior parte dos usuários. Esta foi a apresentação:

Referências:

Modelo de Acessibilidade disponível para consulta pública

As recomendações para o Modelo de Acessibilidade de Governo Eletrônico e para a Cartilha Técnica estão disponíveis para download e abertas para consulta pública até 24 de fevereiro. Estes documentos são essenciais para quem quiser trabalhar em qualquer site nas três esferas governamentais, autarquias, empresas públicas e adjacências. Fale agora ou cale-se para sempre!

Baixe aqui:
Veja mais:

Colaboração do amigo André Marcanth

Quando a ordem dos fatores altera o produto

Como contei no último post, foi uma experiência fantástica [porém assustadora] testar alguns programas de leitura de tela para portadores de deficiência visual. O drama começa porque o mouse não é a melhor ferramenta para se movimentar pela tela para um portador de alguma deficiência, e sim o teclado. Usa-se o Tab para seguir pelos links, e Shift + Tab para voltar pelo caminho inverso.

Este pode ser um problema muito grande. O Tab segue literalmente a ordem dos links que estão no código da página. Deste modo, seja qual for a estrutura da página que você estiver construindo [tabelas, layers, diabo a quatro], você deve respeitar a ordem lógica da página.

Uma sugestão é primeiro construir o topo com o logotipo do site/empresa. Neste logotipo, coloque aquele link básico para a home e um alt dizendo qual é o site e explicando que clicando ali o usuário vai para a home-page. Depois, vem a primeira navegação, segunda navegação e o texto.

Um site que atende portadores de alguma deficiência pode e deve ser interessante para os dois públicos. O site não precisa ser como o do Ministério da Educação e Cultura, que jura de pé junto que é bom em acessibilidade, mas além de ter uma estética pobre e saturada de links, não tem um tamanho de fonte flexível para o corpo do texto. Talvez uma estética minimalista ajude os portadores de deficiências visuais, mas verifique se esta é uma boa opção para todos os outros usuários também. Ou simplesmente um meio de errar menos…

Faça você mesmo

Se você tem o Windows XP, verifique se você tem instalado o Narrator. O atalho para ele fica dentro de Acessórios, Acessibilidade. Ele é um programinha bem simples, mas mostra bem como os programas comerciais de leitura de tela funcionam. Existem outros softwares melhores como o Virtual Vision. Há um grupo de discussão no Yahoo!Groups de usuários deste software. Se você puder investir, compre-o.

O teste do Tab

Se não puder usar um leitor de telas, simples, faça o teste do Tab. Selecione o campo da URL do browser. Clique devagar na tecla Tab e localize os elementos que estão selecionados. Veja se eles estão em formato texto e estão compreensíveis somente com o conteúdo visível do texto. Se estiverem em imagens, passe o mouse por cima e veja se tem um texto alternativo que realmente diz algo sobre a imagem [“este é um botãozinho azul” é o tipo da informação que não precisamos 8:P]. Se não obtiver os melhores resultados, use os atributos alt e title para melhorar a compreensão destes elementos isolados e continue o teste sempre do inicio.

Um indício que a sua página não está estruturada de forma lógica é se há várias mudanças bruscas na localização dos elementos ao longo da página. Se ir e vir do topo ao rodapé várias vezes durante a leitura de uma página pode te deixar tonto, imagine quem não sabe exatamente onde está?

Dicas básicas

  • Para as imagens, use sempre o atributo alt, menos para imagens que realmente não tenham nada a dizer.
  • Para qualquer link que precise de uma explicação melhor que o rótulo, use o title. Qualquer tag HTML/XHTML aceita este atributo.
  • Menus DHTML como os que tem no site do MEC não são muito bons para serem acessados pelo Tab. Se houver necessidade de explicitar um segundo nvel de navegação neste menu, pense em outras alternativas.
  • Alguns recursos são verdadeiras armadilhas para o Tab, como alguns tipos de animações, frames e AppletsJava. Sempre que colocar algum elemento novo na página, faça o teste dos Tab.
  • Se você usa recursos de rollover para descrever algum conteúdo essencial, use também as propriedades de foco [no JavaScript básico onFocus/onBlur].

Se você acha que isso não tem nada a ver com você…

Pense então em dinheiro. Está na Câmara dos Deputados uma alteração na Lei nº 10.098, de 19/12/2000, para garantir a acessibilidade de todos 8 mil websites públicos aos portadores de deficiência ou necessidade especial. Sabe o impacto que isso vai ter no seu trabalho? As oportunidades que podem surgir para a sua empresa? 8;)

Não deixe de…

Case: Fundação Laramara

Estava navegando por a quando descobri este hotsite da Fundação Laramara no blog do Rodrigo Kono. Imediatamente lembrei de algumas pesquisas que fiz com softwares de leitura de tela para deficientes visuais. Era estranho para mim tentar interagir com um computador sem a visão [sou uma pessoa extremamente visual].

Acessibidade é um assunto que nunca tinha citado aqui no blog não sei bem o porquê. É um tópico que mexe muito comigo, mas que não consigo entender ainda direito. Vale a dica do hotsite e a promessa que vou falar mais disso nos próximos posts.

O site que vai do freezer ao microondas

Estava navegando a toa por aí e caí no site americano da Tupperware. Legal! Eles tem um lance de reuniões virtuais, como as que a minha mãe fazia em casa quando eu era pequena [boas lembranças… 8;)].