Novo Blog já no Ar.

Com o intuito de melhorar o acesso aos serviços da CSS TI, após um tempo de manutenção, hospedamos nosso Blog em nosso servidor, para um melhor controle.

Faça-nos uma visita:

Por enquanto este permanece no ar, mas o novo já está a todo vapor.

Acesse: http://www.wordpress.cssti.eti.br/

Atenciosamente,

Equipe CSS TI

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?”

W3C

É 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;
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 WCAG 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.

Web Design com w3c só a CSS TI tem.

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 …

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í…

Fonte: iMasters