Esquerda - Conteúdo.

Acessibilidade web: tudo tem sua primeira vez - Parte II.

Marco Antonio de Queiroz* (MAQ).

Variações de idioma na página Web.

Mais que o simples idioma, a variação da língua natural no texto da página e nos equivalentes, textuais ou não textuais, deve ser identificada. As línguas naturais são a língua falada, escrita e a gestual. No Brasil a língua falada e escrita é o português e a gestual é a LIBRAS (Língua Brasileira de Sinais).

Assim, quando em um texto em português encontramos a palavra SITE, por exemplo, um leitor de telas enviará exatamente essa informação, ou seja, será lida palavra igualmente como no idioma principal da página, o português: será lido site. Quando se faz a marcação da mudança de idioma, as pessoas que estiverem escutando o texto ouvirão como no idioma de origem da palavra marcada no código, o inglês. Escutarão foneticamente como "saite", com a pronúncia certa.

Da mesma forma que os equivalentes textuais, as marcações de variação de língua não aparecem na tela, ficando somente no código da página que é transmitido pelo leitor de tela. No entanto, se formos passar um corretor ortográfico no texto da página, ao chegar em palavras de outros idiomas ele mostra como erro. Por outro lado, se estiver marcado o idioma correto da palavra, ele só apresentará erro se a palavra também não for reconhecida no idioma indicado.

Muitas vezes a pronúncia incorreta das palavras dificulta o entendimento das informações. No entanto, se mal aplicadas as marcações de mudança de línguas, podemos nos deparar com uma página em português totalmente pronunciada em inglês, o que dificultará o entendimento da mesma forma.

Isso pode acontecer por dois motivos: um desenvolvedor de outro país colocar que a página é toda em inglês e alguém copiar a página colocando o texto em português. Isso acontece muito em blogs estrangeiros utilizados por brasileiros, ou mesmo com programas editores de páginas da web que estão no idioma inglês.

A outra forma é quando um criador de páginas abre uma marcação para o inglês e se esquece de fechá-la. Essas marcações têm início e fim, servindo tanto para apenas uma palavra como para expressões, citações e até parágrafos e, assim, as marcas têm de ser bem colocadas no início e fim da variação do idioma. Demos o exemplo do idioma inglês por ser aquele em que esses erros são mais comuns.

A identificação da língua natural também auxilia os tradutores automáticos: softwares ou máquinas capazes de ler o conteúdo de uma página e traduzi-lo para outro idioma. Quando tais tradutores se deparam com uma marcação de mudança de idioma, ele não o traduz, pois pode ser um termo técnico ou mesmo uma expressão conhecida no idioma marcado.

Conteúdos dinâmicos.

Conteúdos dinâmicos são informações que se atualizam em tempo real. Podem ser conteúdo em texto, vídeo, áudio e conteúdo apresentado por meio de scripts e applets, ou qualquer tipo de conteúdo que transforme a página ou parte dela periodicamente.

As Diretrizes irlandesas de acessibilidade baseiam-se nos seguintes fundamentos para a boa utilização desse item do WCAG:

"Alguns métodos causam problemas para usuários com mobilidade limitada, dificuldades de leitura ou deficiência visual. Isso pode acontecer quando o conteúdo dinâmico muda continuamente ou se renova automaticamente em uma única área da página de internet, ex.: um noticiário resumido (news ticker) de rolagem contínua. Esse tipo de apresentação causa problemas para leitores de tela. Usuários com mobilidade limitada podem ter dificuldades para clicar nos links em movimento. Usuários com deficiência visual ou dificuldade de leitura não têm facilidade para ler textos em movimento."2

Assim, informações apresentadas com recursos dinâmicos também devem possibilitar a navegação por aqueles que não possuem meios capazes de fazê-lo, adequando o acesso às informações dessa dinâmica, mesmo que seja através da repetição numa versão equivalente igualmente atualizada. Porém, "essa versão deve ser tão imediata e atualizada quanto a versão dinâmica. Caso contrário, os usuários ficarão mal informados".2

"Frames" ou "Quadros".

Os "frames", ou "quadros", são recursos que apresentam numa só tela do monitor mais de uma página da web. Assim, por exemplo, podemos ter uma tela com um "frame" à esquerda com os menus e links de navegação, que é uma informação fixa. Do lado direito da tela, teremos o conteúdo relativo aos links que estão à esquerda. Esse conteúdo é um quadro (frame) com informações dinâmicas, pois as páginas se alteram à direita a cada clique dado ao lado esquerdo.

Os "Quadros", ou "frames", têm alguns problemas para pessoas com deficiência visual. Esses usuários não percebem, de uma só vez, a estrutura da página. O leitor de telas apresenta o conteúdo linha a linha, ou mesmo somente o pedaço que está lendo, sem uma visão geral da tela. A percepção do todo se dá ao final de toda a leitura, caso cada "frame" esteja bem intitulado, como por exemplo: "Frame superior, Cabeçalho", "frame esquerdo - menus", "frame principal, conteúdo" etc.

No caso dos usuários cegos que se utilizam de navegadores somente texto, como o Webvox ou Lynx, uma lista de frames, na forma de links, lhe é apresentada ao entrar no endereço principal do site. Se os frames não estiverem adequadamente contextualizados, a estrutura da página estará mal apresentada e pode não ser percebida. Dessa forma, a pessoa com deficiência terá de entrar em cada "frame" para saber do que se trata e, aos poucos, ir montando o todo em sua imaginação. Isso pode ser demorado e frustrante. Colocar títulos em "frames" não necessariamente precisa ser no modo visual, podendo ser por marcação na configuração do "frame".

Um "frame" acessível deve conter também, quando seu conteúdo é constituído de vários menus, um salto do início para o final, dando a possibilidade ao usuário da navegação via teclado de passar por todos os menus de uma só vez, pois os mesmos se repetirão em todas as páginas do site.

Tabelas de Dados.

As tabelas de dados servem para organizar informações mediante interseções entre linhas e colunas. Assim, por exemplo, se seguirmos as colunas até uma determinada linha correspondente, conseguimos encontrar os dados procurados. No entanto, se estivermos utilizando um leitor de telas, talvez nossa pesquisa não seja tão fácil assim.

Vamos nos utilizar de uma tabela de dados simples como exemplo. Imaginemos que estamos organizando os dados da quantidade de pessoas que visitaram determinado site da internet, a cada mês e dia do ano. Poderíamos ter os 12 meses nas colunas horizontais, de janeiro a dezembro, e os dias nas linhas verticais, de 1 a 31.

O leitor de telas procura os dados linha a linha e, portanto, se o número de colunas for grande, pode confundir seu usuário. Vamos supor que ele queira saber quantas pessoas entraram em seu site no dia 15 de setembro. Passando a linha horizontal dos meses do ano, a próxima linha seria o dia 1. Ele correria, dependendo do tipo de tabela, até o dia 15, quando escutaria o 15 do dia e as 12 informações subseqüentes de cada mês, mês a mês, ou todos os meses de uma só vez. Ou seja, faria uma leitura linear do dia 15 e teria de contar mentalmente quantos resultados passaram até chegar o que deseja, no caso, o do mês em questão, setembro, que seria o nono resultado após a leitura do dia. O usuário escutaria algo mais ou menos assim:

15 353 381 402 324 397 299 306 332 411 391 392 305

enquanto que, se acessível, esta tabela reproduziria: 1 setembro 353, 2 setembro 381... até 15 setembro 411, bastando que, com as teclas de atalho, posicionasse sua audição no dia 15 e fosse pressionando nove vezes até chegar no mês 9 (setembro).

Algumas tabelas de dados, como as estatísticas do IBGE, que já não são muito fáceis de serem interpretadas pela maioria das pessoas que enxergam, são impossíveis para usuários de leitores de telas se não forem feitas acessíveis. Para além das coordenadas a serem encontradas numa tabela, esses usuários ainda têm de entender, pela leitura dos cabeçalhos, o que significam inúmeras abreviaturas que não têm explicação imediata, e se eles estão procurando exatamente aqueles tipos de dados.

Também existe acessibilidade para isso, através de marcações em HTML que fazem o leitor de tela ler por extenso o que está abreviado, ajudando, além disso, as pessoas que não utilizam tais auxílios, pois se passando o mouse na abreviatura, assim como nos equivalentes textuais já mencionados, dependendo do navegador utilizado, abre uma janela com a abreviatura ou acrônimo estendido.

Conteúdo, estrutura e apresentação (HTML & CSS).

O WAI, Web Accessibility Initiative, departamento do W3C, responsável pelo WCAG, documento de diretrizes de acessibilidade para a web, recomenda que, para se ter um acesso rápido às páginas da internet, deve-se desenvolvê-las separando conteúdo e estrutura da apresentação.

O conteúdo é o principal agente de informação; é constituído do texto, formulários, listas de itens, parágrafos, hiperlinks etc., formando juntos a estrutura da página. As técnicas sugeridas pelo WCAG3 seguem, naturalmente, os padrões web, e são em HTML, que é uma codificação de marcações.

A apresentação de uma página é o tamanho, forma e cores do texto, do fundo da página, das bordas de imagens e tudo aquilo que faça parte do estilo visual do site. A recomendação é que essa apresentação seja feita em CSS (Cascading Style Sheets).

A linguagem HTML é limitada quando se trata de aplicar a apresentação a uma página. Isto porque trata-se de uma linguagem que foi concebida para usos mais específicos que os atuais. Para solucionar este problema, os desenvolvedores de páginas começaram a utilizar técnicas, tais como o uso de tabelas para formatar o layout das páginas, imagens transparentes como espaçadoras de largura e altura de células de tabelas, codificações que não são padrões do HTML e outras, que degradam a acessibilidade e velocidade no momento de sua utilização pelo usuário.

O funcionamento das CSS consiste em definir, mediante uma sintaxe especial, a apresentação que os desenvolvedores de sites podem aplicar à um site inteiro, considerando-o em todas as suas páginas, à uma página em especial, ou mesmo a um pedaço de página.

Na apresentação feita pelo CSS, reconhecemos inúmeros recursos já conhecidos do HTML, só que muito mais amplos e rápidos. A potência da tecnologia é muito maior:

  • Pode-se definir, por exemplo, vários tipos de parágrafos: em vermelho, em azul, com margens, sem margens, com letras grandes, médias ou pequenas...
  • Pode-se definir a distância entre as linhas do texto;
  • Pode-se aplicar recuo às primeiras linhas do parágrafo;
  • Pode-se colocar elementos na página com maior precisão, e sem lugar para erros;
  • Possibilita definir a visibilidade dos elementos, margens, sublinhados, riscados, etc...

A principal razão para o desenvolvimento desta tecnologia, foi a de que as páginas web têm misturado em seu código HTML o conteúdo da página com a codificação necessária para lhe dar estilo, ou seja, fazer a apresentação visual.

Assim, a recomendação sugerida no WCAG 1.0 é exatamente a separação do conteúdo e estrutura da apresentação, em espaços diferentes, que possam ser unidos na visualização da página na hora de ser carregada. No momento em que entramos em uma página, o conteúdo se "veste" de sua apresentação, ou seja, o HTML se "veste" de CSS.

Navegadores somente texto, como o Lynx e Webvox, para pessoas com deficiência visual, não chamam nunca a "apresentação", apenas o "conteúdo" e, assim, para esses, a navegação é muito rápida. A exemplo desses navegadores somente texto, a idéia do WCAG 1.0 é a de que, um navegador gráfico seria quase tão rápido quanto um somente texto, utilizando-se folhas de estilo (CSS) e conteúdo separados, para qualquer navegador, como para qualquer auxílio técnico, pois o código do conteúdo e estrutura a ser carregado seria mais simples e menor, enquanto o código da apresentação, apesar de ter mais recursos técnicos, seria muito mais rápido.

Essa técnica é excelente para conexões lentas, como as discadas, sem banda larga e para usuários com baixa visão, pois podem ter suas folhas de estilo particulares, com letras ampliadas e de cores diferentes, ajudando-os na visualização da página (mesmo que não fique tão bonita como o designer idealizou). As folhas de estilo trazem uma acessibilidade importante para alguns usuários que necessitam mudar a apresentação, e para todos que gostam de uma navegação rápida e eficiente.

Dispositivos de entrada, dispositivos de saída e acessibilidade.

Dispositivos de entrada são os dispositivos através dos quais entram informações que são trabalhadas por programas, eventos, ou mesmo apenas formulários, envio de e-mails, etc., existentes no site e que serão utilizadas pelo o usuário, ou apenas tarefas comuns como acionamento de links, lista de opções etc. Esses dispositivos podem ser o mouse, o teclado e o comando de voz. Os dispositivos de saída são os receptores dessas tarefas. Podem ser, por exemplo, a tela do monitor, as saídas de som, Braille, etc.

Alguns eventos produzem efeitos puramente visuais, "enquanto outros são usados para completar tarefas críticas, tais como submissão de conteúdos de formulários, conclusão de cálculos ou envio de mensagens. Eventos fundamentais para completar tarefas devem sempre ser independentes do dispositivo de entrada."2

As "diretrizes Irlandesas de Acessibilidade" observam que:

"as interfaces que não oferecem flexibilidade no tipo de dispositivo em que o usuário deve confiar para dar entrada em informações ou receber saídas, são inerentemente inacessíveis. Os usuários de laptops talvez prefiram trabalhar sem o mouse e com o teclado. Nesse caso, se os recursos do site exigirem um recurso do tipo "arraste e solte" como único meio de interagir, sua utilização não será possível." (...) isso (...)não está restrito somente à entrada de informações. É importante também oferecer saídas independentes do dispositivo. Os usuários de leitores de tela podem abrir um menu, mas se não receberem feedback sobre os nomes dos links que estão selecionando, o menu não terá utilidade."2

Essa observação se ajusta exatamente aos menus programados para que, ao serem apontados através do mouse, haja a abertura de uma janela onde aparecem inúmeros links de navegação, e ao ser retirado o ponteiro do mouse desses menus, essa janela com links desapareça. Essas janelas, no entanto, não são iguais as que aparecem nos textos alternativos para mostrarem os equivalentes textuais, pois são preparadas através de programas feitos por desenvolvedores e com seus códigos fechados aos dispositivos de entrada, como o teclado, e os de saída, como sintetizadores de voz.

Esse tipo de recurso é utilizado para o maior aproveitamento possível do espaço na tela, porém, é totalmente dependente do mouse. Por exemplo: vamos supor que um governo esteja apresentando suas várias secretarias. Quando, com o mouse, o usuário passa seu ponteiro sobre o item educação, abre-se uma janela com inúmeros submenus como: "secretaria, escolas, bibliotecas, ano letivo, novas matrículas, corpo docente, eventos", sem, no entanto, entrar em uma outra página. Assim, só aparecem esses novos submenus (links) desse menu quando apontados com o mouse, dificultando, ou mesmo eliminando, os usuários de outros dispositivos, como o teclado, do uso desses links.

Menu
Imagem do menu antes dos submenus serem ativados pelo mouse.

Submenus
Imagem dos submenus depois de serem ativados pelo mouse.

Nesse sentido, as diretrizes irlandesas complementam:

"Quando se desenvolve interfaces que possibilitam entradas com independência do dispositivo, produz-se a usabilidade do site para uma gama maior de mecanismos de computação, inclusive aparelhos portáteis, PCs e sistemas de resposta interativa por voz [Interactive Voice Response systems (IVRs)]."

Além disso "os usuários de leitores de tela confiam plenamente no teclado para interagir com os websites. Se não houver suporte para o teclado como dispositivo de entrada, a utilização do site não será possível. Outros usuários podem usar a entrada de voz para operações sem uso das mãos em escritórios muito ativos ou em caso de limitação de destreza." (Item 2.202)

Para se verificar a existência dessa inacessibilidade, basta passar o ponteiro do mouse sobre o item do menu, que automaticamente submenus aparece logo abaixo, com diversos links específicos sobre o item em questão. Outra forma é, naturalmente, navegando-se apenas através do teclado e, sabendo-se da existência dos links de abertura, passar pelo menu sem conseguir abri-los. (acessibilidade e usabilidade zero).

Existem outras tarefas que também podem ser testadas dessa forma. Por exemplo, em uma lista de opções, ao se passar pela primeira opção, esta seja ativada automaticamente apenas por ter sido marcada pelo teclado sem que o usuário tenha tido intenção de fazê-lo. Assim, o usuário da navegação via teclado, nunca consegue passar da primeira opção, pois essa já fica acionada, entrando por ali, querendo ou não. Assim, se seu interesse for a terceira das opções, ele se vê obrigado a entrar na primeira, voltar e, esta estando focada, passar com o teclado para a segunda que, acionada sem intenção, novamente a tarefa será realizada e, voltando novamente, passar da segunda para a terceira, quando a ação irá fazer realizar a real intenção do usuário. (Péssima acessibilidade e usabilidade).

Uma inacessibilidade muito comum e especial para cegos.

A partir de um determinado momento, e por motivo de segurança, inúmeros aplicativos em sites começaram a possuir senhas numéricas e alfanuméricas em imagens para que fossem repetidas pelo usuário através do teclado. Isso impede completamente o acesso de pessoas com deficiência visual a esses aplicativos. Essas pessoas sem poderem ver as imagens e sem que essas imagens tenham equivalência textual, pois softwares inteligentes conseguiriam ler esses textos e colocá-los no campo de edição, onde deveria ser digitada a senha, ficam sem poder entrar em diversas seções dos sites, como as de bancos on line, por exemplo. Isso acabou por se tornar uma grande barreira de acesso em diversas partes da web, deixando as pessoas cegas fora de serviços essenciais para elas.

Uma das formas de solucionar esse grande problema, é se fazer perguntas básicas e de dificuldade mínima, a ser escolhida pelo próprio usuário. Por exemplo: qual o primeiro mês do ano? Qual o mês que se costuma comemorar o Natal? Nenhum software consegue responder perguntas, ainda mais quando são periodicamente trocadas. Além disso, é claro, em lugares de maior segurança, como nas contas bancárias, somente o dono da conta conhece sua senha pessoal, que pode e sempre é colocada por via do teclado.

Outra possibilidade é a de ser repetida a senha que está na imagem por voz, contanto que seja devagar e com poucos caracteres, para que a pessoa cega possa digitar as letras e números "falados" sem se perderem pelo caminho.

Padronização, uniformidade, consistência.

Quando entramos em um site que não conhecemos, acabamos por nos acostumar a ele, desde que se utilize, em suas páginas, recursos de navegação mais ou menos uniformes em todo o site, tais como:

  • Apresentação visual - os elementos de navegação devem parecer idênticos em cada página. Se cada uma tiver um visual diferente, poderá frustrar o entendimento do conjunto, ou até mesmo o usuário achar que mudou de site.
  • Ordem - os elementos de navegação serem apresentados em uma mesma seqüência consistente. Se um link de "Fale Conosco" vier ao final de uma seqüência de links, não deve aparecer como primeiro em outra página do mesmo site.
  • Comportamento - os links e os controles de navegação devem realizar a mesma operação quando ativados.
  • Linguagem - a terminologia deve ser repetida nas páginas e não alterada em cada uma, assim como textos diferentes nos links NÃO devem levar a lugares iguais.

Essas pequenas regras ajudam demais na rapidez da navegação por usuários que estiverem entrando pela primeira vez na página, assim como aqueles que não estiverem familiarizados com o uso de computadores ou da web, que tenham dificuldades de aprendizagem ou estejam com pressa.

"A uniformidade torna o site mais previsível e mostra aos usuários como ele funciona, tornando cada nova visita ao site mais simples e facilitando a obtenção da informação desejada. Isso também ajuda os usuários a pularem aquelas partes já conhecidas, facilitando a conclusão das tarefas ou a obtenção das informações."2

Nem economia, nem estatística, apenas percentuais.

Não é raro encontrarmos em sites mais antigos, e mesmo em alguns atuais, a expressão: "Melhor visualizado em 800 X 600". Isso em geral acontece devido ao fato do desenvolvedor da página ter determinado medidas absolutas nos tamanhos das marcações de HTML.

Dessa forma, por exemplo, se ele fixar que sua tabela de dados terá a largura de 400 pixels, ela ficará assim em qualquer tela, seja a de um monitor de 17 polegadas, quanto na de um visor de telefone celular. Se esse mesmo desenvolvedor estipular que o tamanho é em percentual, ou seja, um percentual relativo ao tamanho total da tela, esta página poderá se adaptar a qualquer espaço. Assim, controlados por marcação ou folhas de estilo, os tamanhos devem ser definidos em unidades relativas, e não em unidades absolutas.

Se uma página for projetada tendo-se em mente um tamanho de janela de navegador "fixa", para uma resolução determinada, ela poderá ficar menor que o total da tela, ou ainda poderá se tornar completamente inútil se ficar maior, já que os principais recursos desaparecerão pela borda da tela.

Isso atinge especialmente usuários com monitores menores, como os de telefones celulares, e usuários que necessitam de aumentar o tamanho do texto para poderem visualizar a página, como por exemplo pessoas com baixa visão, ou visão cansada.

Quando uma página é dimensionada por medidas absolutas torna-se muito fácil de se identificar. Basta alterar o tamanho do texto nos menus do navegador. Se você não conseguir redimensionar é porque o tamanho da fonte foi definido como absoluto pelo criador da página. Observe que as imagens são exceção. Elas não podem ser alteradas de forma a fluírem para um outro tamanho como acontece com o texto.

Para pessoas com deficiência e para todos.

As diretrizes que norteiam a acessibilidade de páginas na web vão além das necessidades específicas de pessoas com deficiência. No entanto, este é o seu foco principal, que procuramos seguir nas nossas explicações sobre acessibilidade e usabilidade. É difícil descrever literariamente uma coisa que, afinal, se concretiza de forma totalmente técnica. Cada observação textual tem correspondente numa marcação em HTML, ou em qualquer linguagem dos padrões web. Quando saímos dessa linguagem, protocolos como os da folha de estilo também necessitam se fazer acessíveis e, mais uma vez, caímos na técnica para concretizar a acessibilidade. Deixamos de lado outros itens que, devido à sua complexidade, tornariam este texto cansativo.

As coisas que as pessoas sem deficiência vislumbram na tela do monitor sem saberem que se trata de acessibilidade ou de inacessibilidade, ou as barreiras à navegação com que pessoas com deficiência já toparam e que podem ser perfeitamente contornadas por um bom desenvolvedor de páginas, já são assunto suficientemente amplo. O desenvolvedor, em geral, conhece algumas técnicas, mas nem desconfia de que algumas delas, se executadas nas páginas que produz, seriam de enorme valia para grande número de pessoas.

O bloco a seguir constitui-se como uma espécie de panfleto técnico para qualquer projetista de conteúdos web e, principalmente, para os clientes que pagam por uma página para que esta seja visitada pelo maior número de usuários possível e também para que seja garantida visibilidade para sua empresa por meio de uma página de qualidade.

Este panfleto também é dirigido para desenvolvedores de páginas amadores, pessoas com deficiência ou sem deficiência, leigos ou profissionais da área, jovens que gostem de assumir causas importantes para si e para outros. e tem como objetivo contribuir com alguma metodologia no sentido de fazer acessibilidade comprometida com inclusão social, econômica, política e individual de pessoas com os mais variados tipos de deficiências. Seguindo essa metodologia, um bom profissional pode checar a acessibilidade de páginas. Além disso, na seqüência, serão apresentadas ferramentas de acessibilidade para que qualquer pessoa possa verificar se a metodologia foi bem aplicada, bastando colocar o endereço completo da página. Embora somente um conjunto de fatores possa, realmente, validar a acessibilidade, essas ferramentas emitem relatórios, alguns bastante precisos, relativos à acessibilidade das páginas avaliadas.

Métodos e ferramentas de acessibilidade.

"A validação da acessibilidade deve ser feita por meio de ferramentas automáticas e da revisão direta. Os métodos automáticos são geralmente rápidos, mas não são capazes de identificar todas as vertentes da acessibilidade. A avaliação humana pode ajudar a garantir a clareza da linguagem e a facilidade da navegação"1. Deve-se começar por utilizar métodos de validação automáticos nas fases iniciais do desenvolvimento. Assim, as questões de acessibilidade identificadas anteriormente serão mais fáceis de evitar ou corrigir.

Os importantes métodos de validação que se seguem são abordados com mais profundidade na seção de validação do documento de técnicas do WCAG 1.04 e são:

  1. Utilizar uma ferramenta de acessibilidade automatizada. Note-se que as ferramentas automáticas não incidem sobre todas as questões da acessibilidade, como seja a clareza de um texto, a aplicabilidade de um equivalente textual, etc. (Ler bloco abaixo).
  2. Validar a sintaxe (por ex., HTML, XML, etc., em: validador HTML do W3C - http://validator.w3.org Essa validação do código importa em que sua interpretação pelo navegador seja mais rápida e eficiente, já que estará em contato com um código totalmente correto;
  3. Validar as folhas de estilo (por ex., CSS, valide em: Validador Css do W3C - http://jigsaw.w3.org/css-validator/ Pelo mesmo motivo que se deve validar o código do HTML, se deve fazer o mesmo com o do CSS.
  4. Utilizar um navegador só de texto (Lynx ou Webvox) ou um emulador;
  5. para se averiguar se o conteúdo está completo, Utilizar vários navegadores gráficos na verificação do conteúdo, com:
    1. o som e os gráficos ativos;
    2. sem gráficos;
    3. sem som;
    4. sem mouse;
    5. sem carregar frames, programas interpretáveis, folhas de estilo ou applets.
  6. Utilizar vários navegadores, antigos e recentes, para verificar a consistência dos dados entre eles;
  7. Utilizar um navegador de emissão automática de fala, um leitor de tela, software de ampliação de tela, uma tela de pequenas dimensões, etc. Este item é difícil de ser realizado, mas importantíssimo para uma página realmente acessível;
  8. Utilizar corretores ortográficos e gramaticais. Uma pessoa que, para ler uma página, se sirva de um sintetizador de voz, pode não ser capaz de decifrar a melhor aproximação do sintetizador a uma palavra que contém um erro de ortografia. A eliminação dos problemas gramaticais aumenta o grau de compreensão da página.
  9. Rever o documento, verificando-lhe a clareza e a simplicidade. O melhor é pedir a um revisor literário experiente que reveja o conteúdo escrito e avalie a clareza da redação;
  10. Peça a pessoas com deficiências que revejam os documentos. Estes usuários , com ou sem experiência, são uma fonte inestimável de informações sobre o estado dos documentos, no que diz respeito ao seu grau de acessibilidade e de facilidade de utilização.

Avaliadores de Acessibilidade - Validadores Automáticos.

Os avaliadores ou validadores de acessibilidade, são ferramentas automáticas que fazem uma pesquisa no código de uma página emitindo relatórios onde indicam os erros de acessibilidade segundo as prioridades sugeridas nas Diretrizes para a Acessibilidade dos Conteúdos da Web - 1.0.

O número de avisos em relatórios de acessibilidade normalmente supera em muito a quantidade de erros listados. Isso ocorre em razão da capacidade limitada das regras que podem ser testadas automaticamente por esses softwares.

Existem diferenças relevantes entre as ferramentas de avaliação de acessibilidade, principalmente na sua aderência aos Web Standards (padrões web), portanto, para obter um bom resultado, é mais garantido testarmos em mais de um desses softwares.

É também bom lembrar que a metodologia para se fazer uma boa acessibilidade numa página não se resume na aprovação desses avaliadores automáticos, eles são tão somente referência para se chegar a uma acessibilidade de excelência, para descobrirmos erros muitas vezes imperceptíveis numa avaliação manual. Uma avaliação também só feita por pessoas com deficiência incorre no erro da página ficar acessível somente aquela deficiência, ou à tecnologia assistiva que ela esteja utilizando. Acessibilidade é se fazer algo o mais universal possível, para todas as pessoas com deficiência, para todos os tipos de acesso (rápidos ou lentos, banda larga ou discado) e para todos os tipos de dispositivos (laptops, celulares, de tecnologias assistivas, etc.).

Aí estão os avaliadores mais conhecidos e utilizados:

O preço do costume.

Algumas pessoas, apesar de saberem a respeito de acessibilidade nas páginas da web, têm medo de que sua implementação seja muito cara. É certo que, fazer do início uma página com acessibilidade é muito mais simples que tornar acessível uma página em que a acessibilidade nunca foi pensada. Implementar textos equivalentes e alguns saltos em páginas da web podem ajudar sua navegação para pessoas com deficiência, mas não significa exatamente que a página se tornará uma página acessível. Existem aproximadamente 60 itens de acessibilidade que podemos observar nos sites, cada qual com sua prioridade e atendendo a necessidades específicas. No entanto, não podemos só pensar em acessibilidade para pessoas com deficiência, uma boa acessibilidade é boa para a navegação de todos.

A acessibilidade de uma página tem de vir associada à sua usabilidade e ambas a um desenho e conteúdo atrativos. Não podemos produzir páginas maravilhosas para pessoas cegas e completamente desinteressantes ou de mal gosto para quem vê. Se acessibilidade pretende ser a prática de um desenho universal, então, como dissemos antes, é para todos.

Acessibilidade e usabilidade têm de andar juntas, têm lógica própria, exigem estudo e experiência. No entanto, nada que o costume, a rotina de suas implementações não possam ser absorvidas, e os desenvolvedores de páginas não consigam fazê-las "no automático" um dia. Só é preciso começar a entendê-las, torná-las algo natural e não especial, e o custo final do acréscimo de acessibilidade e usabilidade poderá, no futuro e por conseqüência, ser muito baixo. Isso justamente porque já estaremos acostumados a esse processo e não o trataremos mais como um acréscimo.

Conclusão.

O WCAG 1.0, mencionado aqui desde o início do texto afirma: "Os criadores de conteúdo web devem tornar as suas produções compreensíveis e navegáveis. Isto passa não só por uma linguagem clara e simples, mas também pela disponibilização de meios compreensíveis para proceder a navegação entre páginas e no interior delas. A inclusão de ferramentas de navegação e orientação nas páginas é um fator que potencializa a acessibilidade e a facilidade de utilização para todos"1.

O que o W3C, o WAI, através do WCAG demonstra, é a possibilidade de se fazer com que pessoas com deficiência possam se utilizar da internet. O que nós, consultores de acessibilidade, desenvolvedores de páginas inseridos nas questões de acesso inclusivo e pessoas com deficiências usuárias da internet sabemos, é que a acessibilidade nas páginas da web, hoje em dia, é algo mais que a possibilidade prática do uso da internet por pessoas com dificuldades de acesso, é algo além de ser uma ferramenta de inclusão digital da pessoa com deficiência, ao menos aquelas que necessitam de recursos acessíveis programados. Atualmente a web está se tornando uma verdadeira ferramenta de transposição de barreiras, transformando a internet como um todo numa autêntica tecnologia assistiva. E não apenas para pessoas com deficiência, mas também para todos os usuários deste meio que possibilita às pessoas comuns serem incentivadoras e agentes do desenvolvimento da tecnologia e cultura a serviço da inclusão de cidadãos mais iguais, mais próximos, mais fortes.

Por outro lado, nós, pessoas com deficiência, cada vez mais, nos tornamos conscientes de que as páginas por onde estamos navegando também foram pensadas em função das diferenças e para que o uso comum nos torne iguais. Iguais por direito, iguais pela luta, iguais pela solidariedade, iguais porque todos assim o querem.

Desejamos uma acessibilidade por uma sociedade inclusiva, constituída de indivíduos que enxerguem o que há a frente das deficiências: pessoas. Que percebam o que há por traz das incapacidades: falta de tecnologia, conhecimento e atitude. Toda incapacidade tem uma solução a espera de ser descoberta. A acessibilidade já está aí, olhando para todos e esperando ser aplicada.

Marco Antonio de Queiroz (MAQ).

Referências: 1- Web Contents Accessibility Guidelines 1.0 - Diretrizes para a Acessibilidade dos Conteúdos da Web - 1.0 (www.utad.pt/wai/wai-pageauth.html).
2- Diretrizes Irlandesas de Acessibilidade na web (www.acessibilidadelegal.com/13-irlandesas.php).
3- Documento de técnicas do WCAG 1.0 (www.w3.org/TR/WAI-WEBCONTENT-TECHS).
4- Seção de validação do documento de técnicas do WCAG 1.0 (www.w3.org/TR/WAI-WEBCONTENT-TECHS#validation).

* Marco Antonio de Queiroz - MAQ.

  • Consultor especialista em acessibilidade e usabilidade digital, com 23 anos de experiência em programação de sistemas de informação no SERPRO (Serviço Federal de Processamento de Dados) e desenvolvedor de acessibilidade nas páginas da web desde o ano 2000;
  • Ministra cursos de acessibilidade Web para empresas e universidades como: UNISYS, SERPRO, UNIRIO, Acesso Digital, Future Kids do Brasil, Porto Digital, CHESF, Prefeitura de Angra dos Reis, entre outros;
  • palestrante em eventos como RioInfo, WAIU, Encontro Dosvox, Encontro de Acessibilidade dos países lusófonos, em universidades como UNIRIO, UFRJ, UFJF, PUC-Rio e em empresas como Petrobras, Fiocruz, Eletrobras, Golden Cross, CET/SP entre outras;
  • Editor de artigos, desenvolvedor da versão portuguesa das Diretrizes Irlandesas de Acessibilidade, criador e conteudista dos sites:
  • Membro fundador e atual consultor do grupo Acesso Digital: estudos, pesquisa e desenvolvimento de acessibilidade em páginas web, produtores do vídeo: Acessibilidade web: Custo ou Benefício? (Videolog 24,5 Mb);
  • Consultor do Centro de Vida Independente Araci Nallin (CVI AN) SP - www.cvi.org.br;
  • Consultor em acessibilidade web da "Click Maujor" - www.clickmaujor.com
  • Autor do livro: "Sopro no Corpo - Vive-se de Sonhos, RiMa Editora, 2005, onde escreve sobre a perda de visão aos 21 anos e sua reabilitação.
  • Cego, divulgador e incentivador da inclusão social e digital para pessoas com deficiência.
  • Currículo Completo.

Disponibilizado em: 04/04/2008.