Sim, mas não exclusivamente para pessoas com essa deficiência, ou mesmo para pessoas que tenham alguma deficiência.
Em geral, restringimo-nos à nossa experiência pessoal, ou mesmo à nossa imaginação, ao pensarmos a dificuldade do outro. Assim, para entendermos o modo de uso da Internet por algumas pessoas, devemos lembrar que existem muitos usuários que atuam em contexto muito diferente do comum, como é o caso dos que não têm a capacidade de ver, ouvir ou deslocar-se, que tenham grandes dificuldades, quando não mesmo a impossibilidade, de interpretar determinados tipos de informação, não serem capazes de utilizar teclado ou mouse, que necessitam tecnologias assistivas específicas associadas e necessárias à navegação, como navegadores completamente diferentes dos habituais, por voz ou que apenas apresentem texto.
Por outro lado, algumas tecnologias hoje consideradas comuns, como os telefones celulares, palmtops, navegadores de páginas que não sejam iguais ao mais comum, o Internet Explorer, mas que podem oferecer opções de navegação diferenciadas, as várias resoluções de tela, como a 800 x 600, 1024 x 768, 1280 x 1024, 1440 x 900, 1680 x 1050 etc, podem também não funcionar adequadamente caso determinados padrões de codificação não sejam realizados e, assim, atrapalharem a visualização oferecidas pelos navegadores.
Usuários com acesso discado ou mesmo com banda larga pouco velozes, estão cada dia mais impedidos de uma navegação tranqüila e execução de aplicativos que exijam maior velocidade.
Dessa forma, acessibilidade na web não é só para pessoas com deficiência visual, ou qualquer outro tipo de deficiência, mas para um número de pessoas cada vez maior, tanto quanto se expandam as diferentes formas de utilização e acesso à web.
No Brasil, o
decreto nº. 5296/2004 ![Site Externo.]( "Site Externo.")
, regulamentador da lei de acessibilidade nº 10098, em seu capítulo VI, dedicou 14 artigos ao Acesso à Informação e Comunicação das pessoas com deficiência. Tornou obrigatória a acessibilidade na Internet, porém, apenas para às pessoas com deficiência visual (não contemplando as pessoas com mobilidade motora reduzida e com deficiência auditiva) e somente a portais do governo.
Percebe-se assim, a existência do mito de que acessibilidade web seja apenas para pessoas com deficiência visual, chegando a ponto de, erroneamente, legalizar-se tal idéia.
A acessibilidade na internet foi contemplada nos artigos 9 e 21 da Convenção, tornando obrigatória e crime de discriminação qualquer informação na internet não acessível para qualquer tipo de deficiência e a qualquer categoria de portal ou site, de empresa privada ou governamental, acabando assim com as restrições anteriores do decreto.
A ideia de que sites acessíveis seriam feitos para pessoas com deficiência visual, especialmente as cegas, acabou por fazer acreditar que os sites acessíveis tivessem de ser feitos somente de texto. Em determinada época, inúmeros sites, inclusive de instituições de/para cegos, chegaram a disponibilizar versões somente texto para deficientes visuais e versões gráficas para as demais pessoas.
Essa prática incorre em dois erros principais:
- Como a acessibilidade para pessoas com deficiência visual, por tornar a navegação por via do teclado plenamente possível, é compatível para pessoas que não conseguem utilizar mouse na navegação, como usuárias de notebooks, paralisadas cerebrais e tetraplégicas, com pouca destreza manual para mouses, mas suficiente para a navegação via teclado, acabavam tendo de desfrutar de uma versão de site completamente sem atrativos, inadequada visualmente para elas;
- quando o desenvolvedor da página tinha de atualizar informações, em geral, só o fazia na versão gráfica, ficando a versão texto quase sempre desatualizada. Quando fazia a atualização nas duas versões, ficava com trabalho dobrado.
Sendo assim, uma versão acessível e comum a todos é a mais prática e recomendável de ser realizada, incorrendo na inclusão digital de todas as pessoas no mesmo espaço e com as mesmas informações.
Para isso, não é necessário que esse espaço não tenha imagens, cores de qualquer natureza e uma estética desagradável. Existem formas de tornar acessíveis as imagens criando-se seus
equivalentes textuais, para que pessoas com deficiência visual possam conhecer seu conteúdo e função no contexto da página, e pessoas sem essa deficiência estejam em um espaço agradável e atraente para seus olhos.
Essa leitura do código transforma-se em linguagem inteligível para o ouvinte, não só lendo o que seja realmente o texto, como descrevendo os elementos existentes na página, como imagens, links, formulários, tabelas etc. Quando ele passa por um link que contém uma imagem, ele descreve: "link" e "gráfico". Se no elemento de imagem houver o atributo ALT, ele complementa a narração dos elementos com o conteúdo textual que estiver dentro do atributo. Assim, se passarmos por um link com imagem, onde a imagem tenha escrito "Quem Somos" e houver o atributo ALT com o mesmo texto, ele disponibilizará: "gráfico", "link" "Quem Somos" audivelmente ou em Braille, por exemplo. Temos de observar que ele falará, em verdade, o conteúdo do atributo ALT e não o desenhado na imagem e que, para quem vê parece ser texto. Todo texto em imagem não é um texto real, mas desenhado, como poderia ser qualquer outro desenho.
Os leitores de tela não são em Braille ou possuem som. Eles somente carregam em uma área temporária sua interpretação do código. Fica a cargo dos sintetizadores de voz ou
displays Braille que essa interpretação se torne audível ou tátil.
Alguns cuidados devem ser tomados para que os leitores de tela se tornem cada vez mais capazes de transmitir a mensagem corretamente. Os sintetizadores de voz são a voz do leitor de tela, e a maioria deles identifica a pontuação através de pausas, de silêncios na "voz", por alguns deles quase imperceptíveis. Assim um ponto tem um tempo de silêncio até que se leia a próxima palavra, um tempo menor para a vírgula e tempos mais fracionados ainda para dois pontos e ponto e vírgula. A exclamação e a interrogação têm sonoridades semelhantes ao que representam, tanto quanto a reticências. A tecnologia anda tão avançada nesse aspecto, que alguns sintetizadores reproduzem fantasticamente a voz humana.
Assim, verificar a pontuação, a gramática e utilizar um corretor ortográfico são medidas importantes, pois os sintetizadores de voz reproduzem exatamente o que um leitor de tela lê. Dessa forma, um texto mal escrito ortograficamente, com abreviaturas do tipo qdo (quando), palavras acentuadas de forma incorreta, erros gramaticais como palavras no singular quando deveriam estar no plural e coisas do gênero, podem deixar um usuário sem entender o texto, ou tendo de parar a leitura corrente para voltar a trechos não entendidos pelos quais acabou de passar.
A utilização de equivalentes textuais para as imagens também é fundamental para que o leitor, em sua passagem, possa transmitir a importância do significado da imagem no contexto em que se encontra.
Um dos cuidados mais fundamentais para a acessibilidade de um conteúdo web é o desenvolvimento do código desse conteúdo dentro dos
padrões web (web standards), tanto apresentando um código semântico, quanto separando-o em camadas de conteúdo, apresentação e comportamento. O trabalho só pode estar completo quando o código estiver validado, tanto o de (X)HTML, quanto o de CSS e scripts, sendo estes não obstrutivos. Os códigos
strict têm contemplado, em sua validação, alguns itens de acessibilidade, como por exemplo a presença obrigatória do atributo ALT no elemento IMG, existência de elementos e atributos obsoletos, etc.
É necessário notar que um leitor de tela utilizado em navegadores gráficos, tem a função não somente de fazer a leitura dos conteúdos puramente textuais existentes em uma página web, mas também de descrever a estrutura dessa página. Sendo assim, ao passar por um elemento
e por seus elementos
e | ele fará a leitura para seu usuário como "tabela com tantas colunas e tantas linhas", além de que, em alguns deles, pressionando-se a tecla "t" pode-se chegar diretamente no início dessa tabela. Se um layout de página for feito por tabelas, prejudicará sensivelmente a navegação de um usuário dessa e outras tecnologias assistivas, pois ele, ao se utilizar da teclagem rápida alcançará inúmeros trechos dessa página que não são tabelas como se fossem, além de ficar escutando a todo momento "tabela com tantas colunas e tantas linhas", sem isso estar existindo visualmente. |
Outros inúmeros erros semânticos são usuais, como a utilização do elemento
-
, onde o tamanho da fonte pode ser definido e o negrito é padrão, utilizados no meio de textos ou mesmo em links, para destaques e não para cabeçalhos propriamente ditos. Ao se teclar a letra h em navegadores gráficos alguns leitores de tela se aproveitam dessa semântica para fazerem saltos de cabeçalho em cabeçalho dentro da mesma página. Pode ser cabeçalho de um menu, de uma combobox e de um artigo separado em inúmeros subtítulos. No entanto, se não for utilizado corretamente, o usuário que tem isso como uma forma acessível de navegação rápida, acabará saltando para lugares que não são cabeçalhos onde esse elemento foi utilizado de forma inadequada. Essa apresentação deve ser feita em folhas de estilo. Por isso a importância de um código semântico, onde cada elemento é utilizado para o fim a que foi criado.
Da mesma forma, a separação entre camadas deixa o código mais "enxuto" para que o leitor de tela (que lê códigos e não telas), possa ler sem ter ele mesmo que fazer essa separação na hora da leitura, agilizando e simplificando sua tarefa.
Outros cuidados de acessibilidade devem ser tomados mas, em sua maioria, não são específicos para a deficiência visual, nem para os leitores de tela necessários para maioria das pessoas que a possui.
A acessibilidade no desenvolvimento de sites é hoje uma ferramenta de mercado que aumenta potencialmente o público que pode chegar até o produto disponível, seja mercadoria ou informação. Não é uma concessão, um ato de boa vontade para com usuários com necessidades específicas: é uma visão estratégica. Imagine o site de um supermercado, uma loja ou de um banco construídos sem a acessibilidade adequada: uma pessoa com deficiência visual ou com qualquer tipo de dificuldade motora - potenciais clientes - estarão automaticamente excluídos. E o que dizer dos sites de serviços públicos?
Nesse caso, provavelmente, os excluídos se sentirão também menos cidadãos. A imagem que tais sites deixarão para tais pessoas, multiplicadoras de opinião através de suas famílias e de si mesmas, certamente não será positiva.
Por outro lado, as empresas que não percebem tais pessoas como potenciais consumidoras, não percebem também as pessoas que não possuem deficiência como possíveis usuárias de tecnologias diferentes das mais comuns. Notebooks, celulares e programas de navegação alternativos ao Internet Explorer, como o Firefox, Opera, Safari e outros, muitas vezes ficam inaptos para a apresentação de suas páginas, perdendo assim potenciais clientes apenas por não se darem conta de tais possibilidades.
Existem diretrizes brasileiras e internacionais de acessibilidade web que orientam o desenvolvimento de páginas acessíveis. A primeira delas foi a que é, até hoje, a mais utilizada e completa de todas, feita pelo consórcio que padroniza e atualiza os padrões de codificação como HTML, XHTML, CSS e outros, o chamado W3C
World Wide Web Consortium que, em 1999, publicou o documento de
Diretrizes de Acessibilidade do Conteúdo da Web 1.0 ![Site Externo.]( "Site Externo.")
(original em inglês
(Web Content Accessibility Guidelines 1.0 ![Site Externo.]( "Site Externo.")
), o WCAG 1.0.
Recentemente o W3C publicou uma nova versão, a
WCAG 2.0 ![Site Externo.]( "Site Externo.")
e
Joe Clark um dos participantes da confecção do WCAG 1.0, em busca de atualizar esse documento publicou o
WCAG Samurai ![Site Externo.]( "Site Externo.")
, que está sendo muito considerado entre os profissionais criadores de conteúdos web acessíveis, mas que, no entanto, apesar de possuir muita consistência e acertos, não é um documento completo em si mesmo, mas apenas complementar ao WCAG 1.0.
A orientação básica utilizada para se desenvolver páginas acessíveis ainda é o WCAG 1.0, mesmo porque, o WCAG Samurai é apenas uma errata a essas diretrizes. Entretanto, acredito que, com o tempo, o W3C continuará, pelo respeito internacional que ainda possui pelos desenvolvedores web, mesmo questionado, orientando a produção web acessível e através do WCAG 2.0.
Acessibilidade na web é sempre feita dentro dos códigos dos padrões web. Assim, acessibilidade na web começa por se construir com um código dentro desses padrões
(web standards), ou seja, com esse código válido e testado em avaliadores automáticos e dentro de uma metodologia definida, como por exemplo, a da própria W3C (
Métodos e Ferramentas de Acessibilidade). Além disso, para que estejamos realmente respeitando as
web standards, esse código deve ser semântico e estar separado em camadas: conteúdo, apresentação e comportamento.
Entre os itens da metodologia do W3C está o de se navegar pelas páginas com um leitor de tela de um navegador somente texto e um leitor de tela em um navegador gráfico. Outro item da metodologia é a avaliação da página por pessoas com deficiência. Embora esses sejam dois itens de 11 ao todo, alguns desenvolvedores teimam em achar que, se uma pessoa com deficiência visual navegar por sua página e disser que está boa, que a página está acessível. Isso pode ser verdade para apenas o leitor de tela que aquela pessoa cega utiliza, existindo vários no mercado, em qualidade e para ambientes diferentes. Além disso, temos de ter sempre em mente que acessibilidade web não é feita somente para pessoas com deficiência visual, mas dentro de padrões que servem não somente para outras deficiências como para todas as pessoas, com ou sem deficiência, e que um leitor de tela determinado pode não detectar em sua maior parte.
O buscador Google indexa as páginas da web segundo alguns critérios próprios, entre os quais estão os de acessibilidade do site. Temos de levar em conta que a indexação é feita por palavras chave e que essas palavras são captadas textualmente. Dessa forma, uma imagem sem descrição não entra em sua busca por imagens, frames não são indexados se não pelas metatags da página de configuração, a frameset, e o Google só penetra nas páginas frameadas caso sejam linkadas através do noframes. Como o noframes faz parte da acessibilidade feita em frames no WCAG 1.0, somente com eles e os links do site em seu bojo, que o site se torna visível para os robots de busca. A errata do Samurai 1.0 bane os frames, retirando-os do desenvolvimento acessível de sites. Como os leitores de tela só lêem textos e os robots de busca também, fazendo-se acessibilidade no código de sites, dentro dos padrões web, estamos fazendo também acessibilidade para robots de indexação como o Google. Pode-se dizer, sem erro, que o Google é o maior leitor de tela, na verdade, tal como os leitores de tela, o maior leitor de códigos que existe.
Sim, mas não exclusivamente para pessoas com essa deficiência, ou mesmo para pessoas que tenham alguma deficiência.
Em geral, restringimos à nossa experiência pessoal, ou mesmo à nossa imaginação, ao pensarmos a dificuldade do outro. Assim, para entendermos o modo de uso da Internet por algumas pessoas, devemos lembrar que existem muitos usuários que atuam em contexto muito diferente do comum, como é o caso dos que não têm a capacidade de ver, ouvir ou deslocar-se, que tenham grandes dificuldades, quando não mesmo a impossibilidade, de interpretar determinados tipos de informação, não serem capazes de utilizar teclado ou mouse, que necessitam tecnologias assistivas específicas associadas e necessárias à navegação, como navegadores completamente diferentes dos habituais, por voz ou que apenas apresentem texto.
Por outro lado, algumas tecnologias hoje consideradas comuns, como os telefones celulares, palmtops, navegadores de páginas que não sejam iguais ao mais comum, o Internet Explorer, mas que podem oferecer opções de navegação diferenciadas, as várias resoluções de tela, como a 800 x 600, 1024 x 768, 1280 x 1024, 1440 x 900, 1680 x 1050 etc, podem também não funcionar adequadamente caso determinados padrões de codificação não sejam realizados e, assim, atrapalharem a visualização oferecidas pelos navegadores.
Usuários com acesso discado ou mesmo com banda larga pouco velozes, estão cada dia mais impedidos de uma navegação tranquila e execução de aplicativos que exijam maior velocidade.
Dessa forma, acessibilidade na web não é só para pessoas com deficiência visual, ou qualquer outro tipo de deficiência, mas para um número de pessoas cada vez maior, tanto quanto se expandam as diferentes formas de utilização e acesso à web.
No Brasil, o
decreto nº. 5296/2004 ![Site Externo.]( "Site Externo.")
, regulamentador da lei de acessibilidade nº 10098, em seu capítulo VI, dedicou 14 artigos ao Acesso à Informação e Comunicação das pessoas com deficiência. Tornou obrigatória a acessibilidade na Internet, porém, apenas para às pessoas com deficiência visual (não contemplando as pessoas com mobilidade motora reduzida e com deficiência auditiva) e somente a portais do governo.
Percebe-se assim, a existência do mito de que acessibilidade web seja apenas para pessoas com deficiência visual, chegando a ponto de, erroneamente, legalizar-se tal ideia.
A acessibilidade na internet foi contemplada nos artigos 9 e 21 da Convenção, tornando obrigatória e crime de discriminação qualquer informação na internet não acessível para qualquer tipo de deficiência e a qualquer categoria de portal ou site, de empresa privada ou governamental, acabando assim com as restrições anteriores do decreto.
A ideia de que sites acessíveis seriam feitos para pessoas com deficiência visual, especialmente as cegas, acabou por fazer acreditar que os sites acessíveis tivessem de ser feitos somente de texto. Em determinada época, inúmeros sites, inclusive de instituições de/para cegos, chegaram a disponibilizar versões somente texto para deficientes visuais e versões gráficas para as demais pessoas.
Essa prática incorre em dois erros principais:
- Como a acessibilidade para pessoas com deficiência visual, por tornar a navegação por via do teclado plenamente possível, é compatível para pessoas que não conseguem utilizar mouse na navegação, como usuárias de notebooks, paralisadas cerebrais e tetraplégicas, com pouca destreza manual para mouses, mas suficiente para a navegação via teclado, acabavam tendo de desfrutar de uma versão de site completamente sem atrativos, inadequada visualmente para elas;
- quando o desenvolvedor da página tinha de atualizar informações, em geral, só o fazia na versão gráfica, ficando a versão texto quase sempre desatualizada. Quando fazia a atualização nas duas versões, ficava com trabalho dobrado.
Sendo assim, uma versão acessível e comum a todos é a mais prática e recomendável de ser realizada, incorrendo na inclusão digital de todas as pessoas no mesmo espaço e com as mesmas informações.
Para isso, não é necessário que esse espaço não tenha imagens, cores de qualquer natureza e uma estética desagradável. Existem formas de tornar acessíveis as imagens criando-se seus
equivalentes textuais, para que pessoas com deficiência visual possam conhecer seu conteúdo e função no contexto da página, e pessoas sem essa deficiência estejam em um espaço agradável e atraente para seus olhos.
O leitor de tela é um programa que interpreta os conteúdos do código e os apresenta através de um sintetizador de voz ou impresso em Braille. Ele, em verdade, não lê a tela, mas o código por trás dela, interpretando os elementos e atributos sequencialmente conforme sua leitura, de cima para baixo e da esquerda para a direita.
Essa leitura do código transforma-se em linguagem inteligível para o ouvinte, não só lendo o que seja realmente o texto, como descrevendo os elementos existentes na página, como imagens, links, formulários, tabelas etc. Quando ele passa por um link que contém uma imagem, ele descreve: "link" e "gráfico". Se no elemento de imagem houver o atributo ALT, ele complementa a narração dos elementos com o conteúdo textual que estiver dentro do atributo. Assim, se passarmos por um link com imagem, onde a imagem tenha escrito "Quem Somos" e houver o atributo ALT com o mesmo texto, ele disponibilizará: "gráfico", "link" "Quem Somos" audivelmente ou em Braille, por exemplo. Temos de observar que ele falará, em verdade, o conteúdo do atributo ALT e não o desenhado na imagem e que, para quem vê parece ser texto. Todo texto em imagem não é um texto real, mas desenhado, como poderia ser qualquer outro desenho.
Os leitores de tela não são em Braille ou possuem som. Eles somente carregam em uma área temporária sua interpretação do código. Fica a cargo dos sintetizadores de voz ou
displays Braille que essa interpretação se torne audível ou tátil.
Alguns cuidados devem ser tomados para que os leitores de tela se tornem cada vez mais capazes de transmitir a mensagem corretamente. Os sintetizadores de voz são a voz do leitor de tela, e a maioria deles identifica a pontuação através de pausas, de silêncios na "voz", por alguns deles quase imperceptíveis. Assim um ponto tem um tempo de silêncio até que se leia a próxima palavra, um tempo menor para a vírgula e tempos mais fracionados ainda para dois pontos e ponto e vírgula. A exclamação e a interrogação têm sonoridades semelhantes ao que representam, tanto quanto a reticências. A tecnologia anda tão avançada nesse aspecto, que alguns sintetizadores reproduzem fantasticamente a voz humana.
Assim, verificar a pontuação, a gramática e utilizar um corretor ortográfico são medidas importantes, pois os sintetizadores de voz reproduzem exatamente o que um leitor de tela lê. Dessa forma, um texto mal escrito ortograficamente, com abreviaturas do tipo qdo (quando), palavras acentuadas de forma incorreta, erros gramaticais como palavras no singular quando deveriam estar no plural e coisas do gênero, podem deixar um usuário sem entender o texto, ou tendo de parar a leitura corrente para voltar a trechos não entendidos pelos quais acabou de passar.
A utilização de equivalentes textuais para as imagens também é fundamental para que o leitor, em sua passagem, possa transmitir a importância do significado da imagem no contexto em que se encontra.
Um dos cuidados mais fundamentais para a acessibilidade de um conteúdo web é o desenvolvimento do código desse conteúdo dentro dos
padrões web (web standards), tanto apresentando um código semântico, quanto separando-o em camadas de conteúdo, apresentação e comportamento. O trabalho só pode estar completo quando o código estiver validado, tanto o de (X)HTML, quanto o de CSS e scripts, sendo estes não obstrutivos. Os códigos
strict têm contemplado, em sua validação, alguns itens de acessibilidade, como por exemplo a presença obrigatória do atributo ALT no elemento IMG, existência de elementos e atributos obsoletos, etc.
É necessário notar que um leitor de tela utilizado em navegadores gráficos, tem a função não somente de fazer a leitura dos conteúdos puramente textuais existentes em uma página web, mas também de descrever a estrutura dessa página. Sendo assim, ao passar por um elemento
e por seus elementos
e | ele fará a leitura para seu usuário como "tabela com tantas colunas e tantas linhas", além de que, em alguns deles, pressionando-se a tecla "t" pode-se chegar diretamente no início dessa tabela. Se um layout de página for feito por tabelas, prejudicará sensivelmente a navegação de um usuário dessa e outras tecnologias assistivas, pois ele, ao se utilizar da teclagem rápida alcançará inúmeros trechos dessa página que não são tabelas como se fossem, além de ficar escutando a todo momento "tabela com tantas colunas e tantas linhas", sem isso estar existindo visualmente. |
Outros inúmeros erros semânticos são usuais, como a utilização do elemento
-
, onde o tamanho da fonte pode ser definido e o negrito é padrão, utilizados no meio de textos ou mesmo em links, para destaques e não para cabeçalhos propriamente ditos. Ao se teclar a letra h em navegadores gráficos alguns leitores de tela se aproveitam dessa semântica para fazerem saltos de cabeçalho em cabeçalho dentro da mesma página. Pode ser cabeçalho de um menu, de uma combobox e de um artigo separado em inúmeros subtítulos. No entanto, se não for utilizado corretamente, o usuário que tem isso como uma forma acessível de navegação rápida, acabará saltando para lugares que não são cabeçalhos onde esse elemento foi utilizado de forma inadequada. Essa apresentação deve ser feita em folhas de estilo. Por isso a importância de um código semântico, onde cada elemento é utilizado para o fim a que foi criado.
Da mesma forma, a separação entre camadas deixa o código mais "enxuto" para que o leitor de tela (que lê códigos e não telas), possa ler sem ter ele mesmo que fazer essa separação na hora da leitura, agilizando e simplificando sua tarefa.
Outros cuidados de acessibilidade devem ser tomados mas, em sua maioria, não são específicos para a deficiência visual, nem para os leitores de tela necessários para maioria das pessoas que a possui.
A acessibilidade no desenvolvimento de sites é hoje uma ferramenta de mercado que aumenta potencialmente o público que pode chegar até o produto disponível, seja mercadoria ou informação. Não é uma concessão, um ato de boa vontade para com usuários com necessidades específicas: é uma visão estratégica. Imagine o site de um supermercado, uma loja ou de um banco construídos sem a acessibilidade adequada: uma pessoa com deficiência visual ou com qualquer tipo de dificuldade motora - potenciais clientes - estarão automaticamente excluídos. E o que dizer dos sites de serviços públicos?
Nesse caso, provavelmente, os excluídos se sentirão também menos cidadãos. A imagem que tais sites deixarão para tais pessoas, multiplicadoras de opinião através de suas famílias e de si mesmas, certamente não será positiva.
Por outro lado, as empresas que não percebem tais pessoas como potenciais consumidoras, não percebem também as pessoas que não possuem deficiência como possíveis usuárias de tecnologias diferentes das mais comuns. Notebooks, celulares e programas de navegação alternativos ao Internet Explorer, como o Firefox, Opera, Safari e outros, muitas vezes ficam inaptos para a apresentação de suas páginas, perdendo assim potenciais clientes apenas por não se darem conta de tais possibilidades.
Existem diretrizes brasileiras e internacionais de acessibilidade web que orientam o desenvolvimento de páginas acessíveis. A primeira delas foi a que é, até hoje, a mais utilizada e completa de todas, feita pelo consórcio que padroniza e atualiza os padrões de codificação como HTML, XHTML, CSS e outros, o chamado W3C
World Wide Web Consortium que, em 1999, publicou o documento de
Diretrizes de Acessibilidade do Conteúdo da Web 1.0 ![Site Externo.]( "Site Externo.")
(original em inglês
(Web Content Accessibility Guidelines 1.0 ![Site Externo.]( "Site Externo.")
), o WCAG 1.0.
Recentemente o W3C publicou uma nova versão, a
WCAG 2.0 ![Site Externo.]( "Site Externo.")
e
Joe Clark um dos participantes da confecção do WCAG 1.0, em busca de atualizar esse documento publicou o
WCAG Samurai ![Site Externo.]( "Site Externo.")
, que está sendo muito considerado entre os profissionais criadores de conteúdos web acessíveis, mas que, no entanto, apesar de possuir muita consistência e acertos, não é um documento completo em si mesmo, mas apenas complementar ao WCAG 1.0.
A orientação básica utilizada para se desenvolver páginas acessíveis ainda é o WCAG 1.0, mesmo porque, o WCAG Samurai é apenas uma errata a essas diretrizes. Entretanto, acredito que, com o tempo, o W3C continuará, pelo respeito internacional que ainda possui pelos desenvolvedores web, mesmo questionado, orientando a produção web acessível e através do WCAG 2.0.
Acessibilidade na web é sempre feita dentro dos códigos dos padrões web. Assim, acessibilidade na web começa por se construir com um código dentro desses padrões
(web standards), ou seja, com esse código válido e testado em avaliadores automáticos e dentro de uma metodologia definida, como por exemplo, a da própria W3C (
Métodos e Ferramentas de Acessibilidade). Além disso, para que estejamos realmente respeitando as
web standards, esse código deve ser semântico e estar separado em camadas: conteúdo, apresentação e comportamento.
Entre os itens da metodologia do W3C está o de se navegar pelas páginas com um leitor de tela de um navegador somente texto e um leitor de tela em um navegador gráfico. Outro item da metodologia é a avaliação da página por pessoas com deficiência. Embora esses sejam dois itens de 11 ao todo, alguns desenvolvedores teimam em achar que, se uma pessoa com deficiência visual navegar por sua página e disser que está boa, que a página está acessível. Isso pode ser verdade para apenas o leitor de tela que aquela pessoa cega utiliza, existindo vários no mercado, em qualidade e para ambientes diferentes. Além disso, temos de ter sempre em mente que acessibilidade web não é feita somente para pessoas com deficiência visual, mas dentro de padrões que servem não somente para outras deficiências como para todas as pessoas, com ou sem deficiência, e que um leitor de tela determinado pode não detectar em sua maior parte.
O buscador Google indexa as páginas da web segundo alguns critérios próprios, entre os quais estão os de acessibilidade do site. Temos de levar em conta que a indexação é feita por palavras chave e que essas palavras são captadas textualmente. Dessa forma, uma imagem sem descrição não entra em sua busca por imagens, frames não são indexados se não pelas metatags da página de configuração, a frameset, e o Google só penetra nas páginas frameadas caso sejam linkadas através do noframes. Como o noframes faz parte da acessibilidade feita em frames no WCAG 1.0, somente com eles e os links do site em seu bojo, que o site se torna visível para os robots de busca. A errata do Samurai 1.0 bane os frames, retirando-os do desenvolvimento acessível de sites. Como os leitores de tela só lêem textos e os robots de busca também, fazendo-se acessibilidade no código de sites, dentro dos padrões web, estamos fazendo também acessibilidade para robots de indexação como o Google. Pode-se dizer, sem erro, que o Google é o maior leitor de tela, na verdade, tal como os leitores de tela, o maior leitor de códigos que existe.
