Atualmente ouve-se falar muito em padrões web e acessibilidade entre os
desenvolvedores de
sites. Entretanto, o entendimento
que cada um traz desses conceitos é diverso e muitas vezes indefinido.

Os Padrões web sempre estão associados ao código da página web e
às recomendações do W3C especificadas para ele.
Para podermos desenvolver um site genuinamente de boa qualidade e
preparado para receber o extra de acessibilidade, os padrões
desenvolvidos em seu código devem abranger os seguintes itens:

1. Código html/xhtml e CSS válidos;
2. Separação em camadas: conteúdo, apresentação e comportamento.
3. Código (X)HTML semântico.

Para demonstrar a importância desses itens dos padrões web
para a acessibilidade de
sites, temos de especificar
para quem seja acessibilidade web, conceito culturalmente
só associado ao acesso de pessoas com deficiência visual.
“Para quem serve a acessibilidade?” é uma pergunta que
nos leva a várias questões e que nos ajudará a entender
a relação entre web standards
e acessibilidade. Podemos dividi-la em:

1. Acessibilidade web para pessoas cegas;
2. Acessibilidade web para pessoas com deficiência; e
3. Acessibilidade web universal, uma web para todos.

01- Acessibilidade web para pessoas cegas

Com certeza o foco principal do desenvolvimento de sites
acessíveis é o acesso de pessoas com deficiência ao conteúdo
de informação e serviços prestados em um site. Entretanto,
criamos no Brasil uma cultura de que acessibilidade web
seria somente para pessoas com deficiência visual e, mais
ainda, especificamente para pessoas cegas.

Dessa forma, para alguns desenvolvedores, testar acessibilidade
de um site significava
quase que exclusivamente pedir a uma pessoa cega que
navegasse com seu
software de fala pela
página e desse o seu ok nela. Este é, sem dúvida, um dos
itens, entre inúmeros outros, da metodologia proposta pelo
W3C/WCAG para testarmos a acessibilidade de uma página.
No entanto, este item, isoladamente, acaba por incorrer
em inúmeros erros: nem todo o leitor de tela tem a mesma
qualidade e funciona da mesma forma, fazendo com que o
teste de uma pessoa cega não especializada possa ser somente
válido para o leitor de tela ou tecnologia assistiva que essa
pessoa utiliza.Uma pessoa cega e usuária de leitores de tela não consegue,
apenas com uma navegação momentânea, perceber alguma falta
de informação sem comparar o que seu leitor de tela informou
e o conteúdo presente na tela. Essa pessoa
precisa ir ao código confirmar as
informações ou ter uma pessoa que enxergue para comparar sua
navegação com a da pessoa cega.

A cultura de se fazer acessibilidade web para pessoas cegas
acabou por ser legalizada através do decreto 5296 e pela má
interpretação das pessoas responsáveis pelos portais que se
enquadravam nele. O significado de deficiência visual
não era pensado como abrangendo as pessoas de baixa visão,
restringindo essa deficiência à cegueira. É
importante destacar que a cegueira, segundo o censo 2000 do IBGE, está presente em
torno de 300 mil pessoas da população, enquanto que o decreto,
ao referir-se à deficiência visual, definida no início do decreto como sendo
a cegueira e mais a baixa visão, destinava a acessibilidade a mais de
16 milhões de pessoas: Decreto Nº 5296 –
“Art. 47. No prazo de até doze meses a contar da data de
publicação deste Decreto, será obrigatória a acessibilidade
nos portais e sítios eletrônicos da administração pública
na rede mundial de computadores (internet), para o uso
das pessoas portadoras de deficiência visual, garantindo-lhes o
pleno acesso às informações disponíveis.”

No mesmo decreto, artigo 5º:
1.3 deficiência visual: cegueira, na qual a acuidade visual é
igual ou menor que 0,05 no melhor olho, com a melhor correção óptica; a
baixa visão, que significa acuidade visual entre 0,3 e 0,05 no melhor
olho, com a melhor correção óptica; os casos nos quais a somatória da
medida do campo visual em ambos os olhos for igual ou menor que 60o; ou
a ocorrência simultânea de quaisquer das condições anteriores;

Além disso, o WCAG não define que seja uma pessoa com deficiência visual, muito menos cega,
a realizar o teste. Como sabemos, inúmeras outras deficiências precisam de acessibilidade
na web.

02- Acessibilidade para pessoas com deficiência

Ao conhecermos as Diretrizes de Acessibilidade de Conteúdos Web
em suas duas versões, 1.0 e 2.0, percebemos a ênfase que os
itens de acessibilidade desses documentos dão aos acessos não
padronizados de pessoas que, em sua maioria, possuem deficiência,
como a deficiência visual, auditiva, cognitiva e motora. Nota-se, de pronto,
que as recomendações não se restringiram à deficiência visual
e nem mesmo a alguma tecnologia assistiva específica,
apesar de citá-las ao longo desses documentos.

Assim, por exemplo, ao destacarem os equivalentes textuais, o fizeram não só
como itens textuais alternativos para imagens (deficiência
visual), como também para sons (deficiência auditiva).
Esses itens combinados podem mesmo auxiliar, e muito,
o acesso de pessoas surdocegas, usuárias de display-braille.
Para as pessoas com deficiência intelectual
que, ao perceberem uma informação visual e auditiva simultânea, conseguem
elaborar informações com mais segurança, ainda disponibiliza itens como o
da “linguagem clara e simples” que, além de auxiliarem essas pessoas
especificamente, colaboram indistintamente com todas
as pessoas por deixar o conteúdo mais inteligível.
Alguns itens de acessibilidade como os saltos ajudam
o acesso de pessoas com deficiência motora com pouca
destreza manual que, apesar de enxergarem, utilizam a
navegação via teclado.

Não podemos deixar de mencionar, por sua importância e competência, a Errata
ao WCAG 1.0, realizada por Joe Clark, uma das maiores
autoridades em acessibilidade web do mundo, a conhecida
WCAG Samurai.

Atualmente, a existência de três WCAG, a dos W3C (versões
1.0 e 2.0) e a WCAG Samurai, criaram uma certa insegurança
nos desenvolvedores de sites
acessíveis, pois a WCAG 2.0 ainda não está muito bem aceita
e a WCAG Samurai, apesar de possuir ótimas soluções de acessibilidade web
e ter como base a W CAG 1.0, bastante aceita
e da qual é uma errata, não são recomendações do W3C e, portanto,
não tem o reconhecimento internacional que o W3C possui.
Essa “crise por excesso” de diretrizes tem criado uma outra
mais perigosa, que é a da mistura individual de soluções de
acessibilidade web dos três WCAG, que cada desenvolvedor
de conteúdos acaba criando.

A
Convenção dos Direitos da Pessoa com Deficiência 
da ONU, assinada pelo Brasil e ratificada como emenda
constitucional brasileira através do decreto legislativo
Nº 186, autoaplicável desde junho de 2008, amplia
a acessibilidade, restrita à pessoas com deficiência visual e
à portais do governo pelo decreto 5296/04, à todas as
deficiências e à empresas privadas. Se desejar conhecer,
procure os artigos 9, 21 e 30, que tratam do assunto.

Entretanto, apesar desse auxílio às boas práticas, ao
acesso e bom uso da web que os documentos WCAG fazem
inserindo diversas deficiências, ao incluírem os padrões
web aos padrões de acessibilidade web, passaram a criar
universalidade ao acesso, ou seja, sugerindo e orientando a
acessibilidade para pessoas com e sem deficiência, a uma
web para todos.

03- Acessibilidade Universal – uma web para todos

Ao juntarmos os itens de acessibilidade web aos itens
dos padrões web já conhecidos, ampliamos o desenvolvimento
de acessibilidade web e do conceito de desenho universal
aplicado à internet.

Para entendermos como podemos utilizar o conceito de desenho
universal na acessibilidade de
sites, vamos voltar aos itens
dos padrões web mencionados antes:

1- códigos corretos e validados

A primeira coisa que criadores web buscam quando falam em
Web Standards é que o
código do site deve ser
válido. Para a maioria das pessoas isto significa
apenas validar o código HTML/XHTML, mas existem
ferramentas que validam também as CSS.

Basicamente, ter um código (X)HTML válido significa
que o código da página Web está escrito de acordo com o
padrão, sem erros de sintax. Como é o código da página
que vai determinar como sua página será renderizada, em que
tempo e maneira isso irá acontecer nos diferentes navegadores e com que
qualidade, estando seu código válido, você não precisa se
preocupar com os diferentes erros de interpretação dos
diferentes navegadores e tecnologias assistivas, e
assegurar uma maneira uniforme de utilização por todos
eles.

Com relação ao código das CSS, apesar de haver diferenças
de renderização entre navegadores e suas versões e sermos
obrigados a testar para tentar conciliar as diferenças entre
eles, estamos começando a passar por uma tendência à
uma renderização bem aproximada após o fracasso
do navegador Internet Explorer 6.0, que acabou por perder muito mercado para o
concorrente Firefox, da Mozilla.

Códigos válidos significam também rapidez de interpretação
desses códigos para todos os agentes do usuário, sejam
navegadores ou tecnologias assistivas. Assim, conexões
lentas, discadas ou conexões divididas por inúmeros
usuários em rede, tecnologias assistivas, como ampliadores de
tela, que navegam associados muitas vezes a leitores
de tela e possuem um peso que acabam por aumentar o tempo
de navegação, começam, através de códigos corretos, a
possuírem um tempo de download
das páginas web mais adequados.

2- Separação em camadas: conteúdo, apresentação e comportamento

O conteúdo de uma página e sua estrutura são determinados
pelos textos, tabelas, formulários etc. São
criados através de marcações de html/xhtml, linguagens padrões
para esse fim.
Apresentação é tudo que é visual, como posicionamento do
conteúdo, coloração, tamanhos… é o CSS a linguagem, também conhecida por folhas
de estilos quando reunida em arquivo.
O Comportamento é criado por scripts. Nem o conteúdo
determinado pelo (X)HTML e nem a apresentação determinada
pelas folhas de estilo são dinâmicos.
Scripts acrescentam movimento e comportamentos às páginas.

Quando construímos uma página com códigos válidos e com
essas camadas independentes, estamos atendendo a diversos
itens de acessibilidade em uma página web, além de estarmos
cumprindo com mais um dos três itens dos padrões web.

Assim, testamos se o conteúdo, sem apresentação alguma de
cor, posicionamento e sem scripts está funcionando bem.
Depois, em um arquivo à parte, colocamos o código das folhas de estilo
de todas as páginas do site. Ou seja, as cores dos textos dos links, das
cores de plano de fundo, posicionamento de tabelas, colunas, de seções
de todas as páginas do site no mesmo arquivo. Deve-se evitar o estilo
inline.
Ainda, de forma independente, criamos comportamentos extras e algumas
funcionalidades através dos scripts, que devem ser não obstrutivos.

Cada uma dessas camadas se acrescentam entre si, tendo como
base o conteúdo. Assim, se precisarmos desativar a camada
de apresentação deixando o conteúdo limpo e, ainda, se
quisermos desativar comportamento e deixar a página com seus
scripts desativados, isso não gerará perda de conteúdo e a
página poderá ser navegada sem restrições.

Os leitores de tela para pessoas com deficiência visual
lêem quase que exclusivamente o conteúdo, deixando
de lado a apresentação da página. Se o conteúdo está validado
não existe erro em sua leitura e nem na execução de tarefas.
Se, além disso, o código está desenvolvido apenas para
cada tipo de camada com sua respectiva marcação, que não
está misturando conteúdo com cores e posicionamento de
elementos e, portanto, a camada de conteúdo com a de
apresentação, então o código de conteúdo estará proporcionando
uma leitura facilitada aos leitores de tela, que não precisarão selecionar
o que ler, pois o código a ser lido está “enxuto”. Ou seja,
os leitores de tela não terão de selecionar conteúdo entre
conteúdo, apresentação e comportamento do código.
É bom lembrar que, mesmo desativando os scripts e a
apresentação através do navegador que, misturadas, essas
camadas não serão retiradas do código. Assim, um código limpo,
com cada camada separada e acessível, é o ideal não só para
web standards, como especialmente para a acessibilidade web.

Quando desenvolvemos um site
em camadas e carregamos uma de suas páginas pelo navegador,
as camadas de apresentação e de comportamento ficam
guardadas na memória e arquivos temporários, de forma que
somente o conteúdo dessa página é renovado a cada entrada
nas outras diversas páginas do site. Isso significa uma
velocidade tremendamente maior para a montagem e
renderização dessas páginas.

Velocidade de acesso é acessibilidade web, independentemente
de para qual usuário. Conexões discadas ou banda larga
compartilhada em rede se beneficiam com muita clareza das
vantagens da rapidez do carregamento da página. Além dos
códigos corretos, a separação em camadas é um enorme auxílio
dos itens dos padrões web para a acessibilidade de sites.

3- Códigos semanticamente corretos

Um código semântico significa que as marcações utilizadas
foram usadas para os fins a que cada elemento do código se
destina. Dessa forma, se existe um código próprio para
criarmos cabeçalhos e títulos (h1/h6), ele deve ser utilizado
para a criação de cabeçalhos e títulos. Se existe um
código para a criação de tabelas de dados (table), somente
esse tipo de tabelas devem ser produzidas por ele.

Para exemplificar a necessidade dessa lógica dos padrões web
para se fazer acessibilidade, podemos tomar essas duas
situações acima:
Uma marcação existente para se fazer um cabeçalho deixa o
texto ao qual será aplicado com letras mais escuras e
em negrito, podendo-se alterar seu tamanho. Muitas vezes
desenvolvedores utilizam esse destaque que essa marcação
produz no conteúdo com o objetivo de ser um cabeçalho,
apenas para destacarem palavras soltas ou expressões no
meio de um texto, ou para ressaltar um texto de link
ao meio de outros links.

Os leitores de tela não têm como função somente lerem o
conteúdo textual das páginas, mas também de descrevê-la
para seus usuários. Dessa forma, quando ele passa por
uma marcação de um link,
ele sintetiza a palavra link para que o usuário possa saber
da existência desse elemento naquele texto. Quando passa por
uma marcação de tabela, ele diz da existência da
tabela naquele espaço, quantas colunas e quantas linhas
existem naquela tabela e, da
mesma forma, quando ele passa por uma marcação de cabeçalho
ele sonoriza a existência de um cabeçalho por ali e a que
nível ele se encontra: h1 – cabeçalho de nível 1, h2 –
cabeçalho de nível 2 e assim por diante.

Portanto, se marcações são feitas para codificarem
elementos específicos, estas devem ser usadas para
fazerem aquilo para o qual foram criadas. Codificar uma
palavra ou expressão com uma marcação de cabeçalho fora de
um cabeçalho, significa dar a informação errada para um
leitor de telas e, consequentemente, para seu ouvinte.

Além disso, leitores de tela gráficos e mais profissionais
criam alguns recursos aproveitando-se justamente dos
padrões web para facilitarem a navegação de seus usuários.
Dessa forma, para alguns, existe uma navegação chamada
teclagem de navegação rápida, que pressionada leva o usuário,
através de um salto, diretamente a cabeçalhos, tabelas,
formulários, parágrafos etc. Assim, se as marcações
certas forem utilizadas para realizarem ao que se destinam
fazer, a navegação por uma página ficará totalmente
acessível para esses recursos.

4- Acessibilidade e Padrões, Padrões e Acessibilidade

A demonstração da importância crucial dos padrões web do W3C
para a acessibilidade de tecnologias assistivas, para
tecnologias não assistivas, para pessoas com deficiência e
pessoas sem deficiência, passa pela experiência do uso
desses padrões. Não podemos pensar, no entanto, que
desenvolvendo um site
totalmente dentro dos padrões web
(web standards)
estaremos produzindo páginas totalmente acessíveis.
Os padrões web, com todos os seus itens,
são o básico para uma página web acessível, mas não o todo.
Para uma acessibilidade web integral temos de acrescentar
aos padrões web as técnicas de acessibilidade associadas
ao WCAG e suas recomendações. Não temos também como
criar páginas acessíveis apenas com algumas recomendações
dos WCAG em um código com semântica incorreta, sem separação
de camadas e cheio de erros de sintax. O casamento entre
padrões web e diretrizes de acessibilidade tem de ser
completo.

Por exemplo. Alguns desenvolvedores radicais de
tableless não admitem tabelas
nem mesmo para a confecção de tabelas de dados genuínas.
Dessa forma, alguns desses colegas optam por criarem tabelas
com listas (ul/li) horizontais e verticais, deixando-as
visualmente iguais a uma tabela de dados. No entanto, em um
código semântico, tabelas devem ser criadas com o elemento
<table>,
o que proporcionaria à usuários de leitores de tela a idéia
correta de que estão passando por uma tabela, por dados
tabulares, pois ao navegar por uma lista de itens em forma
de tabela, um leitor gráfico sintetizaria “lista de itens” e “item de nível 1”,
e não “tabela com 10 colunas e 20 linhas, por exemplo.
Por outro lado, nesse caso, uma tabela semanticamente
correta e dentro dos padrões, não necessitaria de ser criada
com os elementos <TH>, nem de
fazermos as associações destes através de
<ID> com <headers>
da célula de dados correspondente ao cabeçalho. O <ID>
e o <HEADERS> são marcações
extras de acessibilidade web que, no entanto, sem elas
os padrões web poderiam estar sendo perfeitamente seguidos,
mas a acessibilidade de tabelas não estaria sendo realizada.

Dessa forma, podemos afirmar que não existe uma acessibilidade
completa sem os padrões web conjugados aos padrões de
acessibilidade web. Um sem o outro ficam incompletos
no que tange à acessibilidade de cunho universal.
O W3C tem incorporado através dos códigos
strict alguns itens de acessibilidade web as web standards, ao juntar
alguns itens das diretrizes do WCAG, como o atributo de
imagem ALT em seu validador. Caso o elemento
<IMG> apareça sem o seu atributo
ALT o código para
aquela imagem não é dado como certo. Já nos códigos
transitional isso não acontece.
Percebe-se assim, já por iniciativa do W3C, uma junção dos dois padrões em
um só que, aos poucos, esperamos muito que aconteça por
completo. Será esperar demais? O HTML 5.0 vem aí…

*

Artigo originalmente publicado em http://acessibilidadelegal.com/23-padroes-web.php