Acessibilidade e o WCAG Samurai

Confesso que escrever sobre acessibilidade e o WCAG Samurai me atrai muito ao mesmo tempo em que acho um pouco nebuloso. Mas nebuloso pelo contexto e não pelo assunto em si. Talvez seja por isso que praticamente nada (com exceção do texto do Ivo Gomes) que está em Portugal) tenha sido escrito em português sobre a errata do WCAG Samurai. Nada. Vamos do início e ver o que acontece…

O WCAG é o acrônimo de Web Content Accessibility Guidelines (Guia de acessibilidade para conteúdo na web) que tem o objetivo que estabelecer padrões e técnicas de acessibilidade para a web. Como a versão do WCAG 1 foi publicado em 1999, recentemente sofreu a revisão para a versão WCAG 2 (2007). Na teoria o WCAG 2 deveria ser a evolução e a substituição do WCAG 1.

O que deveria ser sinal de esperança com o advento do WCAG 2, resultou em grande frustração. O fato é que o WCAG 2 é confusa demais e tem problemas sérios de integridade em relação aos outros padrões da web. Suas recomendações são praticamente inviáveis em vários aspectos. Para se ter uma idéia de algumas contradições, em alguns casos é necessário abrir mão de markup válida para se alcançar algum requisito do WCAG. E isto porque a W3C está por trás tanto do (X)HTML quando do WCAG. Segundo Clark, de lobby até falta de participação de pessoas com alguma deficiência marcaram todo o processo para se alcançar o WCAG 2. E o resultado não poderia ser mais triste.

WCAG Samurai

Ao invés de esperar sentados a boa vontade do WAI, o WCAG Samurai é um grupo de desenvolvedores liderados por Joe Clark (autor do livro “Building Accessible Websites“) que mandaram para o inferno os guidelines do WCAG 2 e criaram um documento de acessibilidade mais realista. Em resumo, ou você desenvolve seus sites seguindo o WCAG 2, ou o WCAG Samurai ou nenhum deles. Leia aqui. Porque não é possível seguir ambos.

O WCAG Samurai é um errata do WCAG 1 e que ignora completamente o WCAG 2. A errata diz quais partes do WCAG 1 você deve ignorar e quais são as corretas. Mais um exemplo de padrões emergindo à margem da W3C, por mãos de pessoas com reconhecimento suficiente ao ponto de serem seguidas, como as iniciativas dos microformats e HTML 5. Mas isso já é outra história.

Veja algumas considerações da errata:

  • Termos como “evite utilizar” foram banidos e deram lugar a termos como “utilize” ou “é obrigatório utilizar”.
  • Recomendação de ignorar a prioridade 3.
  • Seguir as recomendações 1 e 2 com código válido.
  • Tabelas para layout e frames foram banidos. Se necessário utilize iframes.
  • Banida a utilização de noscript. E se for utilizar Flash ou AJAX eles devem ser acessíveis.
  • Todas as páginas que querem se compliant com o WCAG Samurai devem ter (X)HTML válido e semântico.

Neste contexto, muito do que alguns validadores de acessibilidade como o WebXACT (este validador não existe mais, a empresa foi comprada pela IBM e o serviço foi descontinuado) e o Cynthia Says apontam como erros devem ser desconsiderados irrelevantes. De fato, validação nunca garantiu e provavelmente nunca vai garantir um site realmente acessível (muito menos semântico), mas agora mais do que nunca, a acessibilidade precisa ser revisitada.

Para se alcançar um bom resultado de acessibilidade, não é necessário produzir markup inválida. Uma coisa deve depender da outra. Este é um ponto crítico em relação ao WCAG e que fomentou o surgimento do WCAG Samurai. Entretanto a situação não é muito clara na prática, browsers continuam violando padrões, a W3C insistiu com o WCAG 2 mesmo que ele viole outros padrões, o que fomenta perda de credibilidade por parte da indústria e assim por diante.

De qualquer maneira recomendo a leitura completa da errata que não é muito grande. Mantenha-se atualizado também com o feed do WCAG Samurai para as constantes atualizações. Seria muito bom a participação de pessoas envolvidas com acessibilidade na divulgação e discussão do WCAG Samurai, incluindo pessoas com deficiência visual. Enquanto todos estão em silencio esperando uma solução de acessibilidade que caia do céu ou apareça pronta no seu editor de HTML, ela só vai ficar cada vez mais distante.

  • Pingback: University Update - AJAX - Acessibilidade e o WCAG Samurai()

  • http://www.fazedordesite.com Rodrigo Fante

    agora sim…. excelente texto… parabéns

  • http://www.coisasdeweb.blogspot.com Ramon

    Acessiblidade, é um assunto, à meu ver, muito crítico na internet, pois diverge em muitos pontos e nem sempre podemos analisar todas as necessidades que possam por ventura surgir, mas isso da WCAG 2, realmente surpreendeu-me, em relação à abrir mão da validação, epero que tenham se tocado, que isso não é uma coisa muito legal e começarem a analisarem outras formas de resolver essa situação.

    Fuiii…

  • http://fatorw.com/ Walmar Andrade

    Iniciativas como a do WCAG Samurai comprovam que o verdadeiro poder da web está nas mãos das pessoas e não de organizações. Se o W3C faz algo ruim, os milhões de desenvolvedores em todo o mundo podem se juntar e apresentar algo melhor que, no futuro, venha a ser padrão. Mundo de pontas.

  • Camilo Vitorino da C

    Interessante esse WCAG Samurai. Para falar a verdade ainda não estudei muito a fundo o WCAG 2 e já vi alguns problemas de compatibilidade com os padrões (X)HTML. A W3C só está queimando o filme, criando padrões incompatíveis entre si e tomando rumos sem perceber o que acontece na WEB. Seria um ditador cego. Ainda bem que existem pessoas competentes o suficiente para fazer algo melhor e outras centenas ou milhares de pessoas compentes o suficiente para perceber essa Anarquia e se permitir utilizar de modos mais éticos de escrever a nossa WEB.

    Excelente texto

  • Pingback: amf | ref » Acessibilidade e o WCAG Samurai()

  • http://exprophony.wordpress.com Alvaro Sasaki

    O Joe, como uma pessoa importante, pode ter esse poder de iniciar um movimento novo como esse do WCAG Samurai, mas o que me assusta é de que algum cara venha a público com idéias ainda mais atraentes, em primeiro momento, para os vários desenvolvedores "ingênuos" e com isso o grupo promova o caos na web… Não digo que todo tipo de iniciativa de agora em diante será assim, mas com certeza haverão riscos.

  • Murilo Cruz

    Em todo caso é preciso ter senso crítico para seguir qualquer lista de recomendações. Para cada projeto algumas recomendações são mais importantes que outras, o que torna muito complicado levar algo ao pé da letra. Em todo caso é muito importante ter alternativas como o WCAG Samurai. Muito bomo post! :)

  • Thiago de Assis

    Eu acho essa artigo um lixo!!! Estou aprendendo web com o frontpage e sou o rei do ASP!!!

  • Canha

    Henrique, dá uma olhada no link do meu nick.

    São as imagens do novo visual do Orkut. Tá muito mais bacana!

    Dá uma olhada, vale a pena!

    Abraços!

    PS: Desculpa comentar aqui, mas não sabia onde mais falar isso.

  • http://www.bengalalegal.com MAQ

    Um colega escreveu:

    Interessante esse WCAG Samurai. Para falar a verdade ainda não estudei muito a fundo o WCAG 2 e já vi alguns problemas de compatibilidade com os padrões

    (X)HTML. A W3C só está queimando o filme, criando padrões incompatíveis entre si e tomando rumos sem perceber o que acontece na WEB. Seria um ditador cego.

    O estranho amigo, é que acessibilidade tem seu foco principal em pessoas com deficiência e o WCAG 2.0 prescindiu dessas pessoas para acrescentar nossa experiência. Sou cego e não ditador, mas o ditador cego que o amigo indicou, enxerga bem! Será que a questão está na cegueira ou visão dos componentes de quem fez o WCAG 2.0? Em outras palavras: 1 – sou cego e faria um WCAG 2.0 muito melhor; 2 – ditador cego é a mãe!

  • Matheus de Oliveira

    É bem interessante estas considerações do WCAG Samurai, porém eu só não entendi o porquê de banir o "noscript"…

    Alguém pode me dar um motivo convincente?

  • Bruno

    Henrique, estou começando a desenvolver um site e tenho me preocupado muito com a questão da acessibilidade. O problema é que, após muita busca no google, horas e horas lendo tutoriais CSS de várias fontes, decobri, na prática, que é impossível desenvolver apenas com CSS um site com 3 colunas de igual altura, elástico, sem inúmeros hacks. Por outro lado, é simples alcançar esse feito com o uso de tabelas para layout. A maioria dos tutoriais se refere a esse layout como o "Santo Graal". Acho um contra-senso abolir as tabelas para layout, já que elas conseguem atingir resultados impossíveis para as "divs" sem exigir "workarounds" que nem validam no W3C. É possível conciliar as tabelas no meu layout sem prejudicar a acessibilidade? Obrigado!

  • Pingback: Spam e acessibilidade » Revolução Etc()

  • Fábio Pavani

    Huahsuaheuh, amei o texto do MAQ.

    Vejo, com o WCAG Samurai como exemplo, que apesar da internet (e tudo em nossa vida) estar virando cada dia mais um "imperialismo democrático", ainda nos resta as CABEÇAS verdadeiras.

    Belo texto, belas definições…

    Resumindo:

    Magnífico

  • Fábio Pavani

    uma "resposta" ao Bruno aqui em cima:

    Bruno, o problema maior das tabelas na acessibilidade é a forma com que elas são "lidas" pelo navegador, ou por leitores de tela, sobre a validação: validação não é tudo, apesar de ser MUITO importante, não é tudo, e se tratanto de hacks, a regra abre uma "brexa"…

    Mas enquanto a "ser ou não ser"… sinceramente, eu acho que não é por uma coisa ser "lei" ou não, que você tenha que acatar totalmente…

    Faça como você fazia quando era criança e sua mãe dizia pra você não fazer… mas tenha a consciencia de que está fazendo "errado…"

    abraços ^^

  • Pingback: Anônimo()

  • http://www.bengalalegal.com MAQ

    Quanto ao colega que perguntou o porque não fazer layout com tabelas, tenho dois motivos mais importantes, além de outros:

    O leitor de telas que utilizo (sou cego) para navegar pelos sites, além de ler os textos do site, faz também uma descrição da estrutura do mesmo. Assim, quando ele passa por um link, diz para mim: link… quando passa por uma imagem, diz: gráfico… quando passa poruma tabela, ele diz: tabela com tantas colunas e tantas linhas. Sendo assim, depois de ele ler o elemento table, fico esperando uma tabela de dados aparecer e não aparecendo, penso: "esse cara não conhece padrões web, usa tabelas para não tabelas. Eu já sou um cara descolado nisso, mas alguns colegas cegos ficam perdidos escutando uma coisa e acontecendo outra. Todas as tecnologias assistivas, tais como os leitores de tela, são programadas para encontrarem padrões e poderem transmitir também padrões. Elas próprias podem ficar desorientadas quando estão lendo códigos fora dos padrões. Tabelas não foram feitas para diagramar páginas, isso é quebra galho e não é profissional.

    O segundo motivo é que o elemento table, atributos e etc… são muito lentos na renderização. Para quem tem banda larga isso não é muito notado, mas se o site for grande e o usuário for um sujeito que mora em um lugar que não tem banda, ou que não tem grana para a banda larga, entrando com conecção discada ou um dispositivo móvel, terá de ir tomar um cafezinho enquanto sua página entra. Se o amigo colocar um flash para "ajudar", ele poderá tomar dois cafezinhos!

    Abraços e bom desenvolvimento de sites! MAQ.

  • http://www.bengalalegal.com MAQ

    Só mais um detalhe, dessa vez quanto ao texto do meu amigo Henrique. O WCAG Samurai, apesar de em uma primeira instância dizer para não utilizarmos os itens da prioridade 3 do WCAG 1.0, mais abaixo no documento, ele repara o que escreveu, dando exemplos um pouco contraditórios à essa afirmação. Por exemplo, ele diz que não se deve colocar o atributo lang indicando o idioma da página (prioridade 3), mas afirma que isso só deve acontecer quando não houver idioma prioritário na página. Vamos supor que a página seja brasileira (pt-br) e tenha um texto em inglês (en) e o mesmo texto, na mesma página, também em francês (fr). Sendo assim, ele afirma que a página não deve ser "taxada" de brasileira, apesar de o site ser, não deve ser também em inglês ou francês, pois não há hegemonia de um idioma na página. Assim, deve-se fazer a expansão do idioma em inglês no texto em inglês e a expansão em frances, no texto deste idioma. No entanto, a página em si não deve ser marcada como brasileira. Estou de acordo com isso. No entanto, a interpretação de muitos é que nunca se deve colocar o idioma da página, pelo simples fato de ser prioridade 3. Isto é completamente errado, pois o display braille, utilizado por cegos e por surdocegos, especialmente, utiliza o idioma da página para fazer abreviaturaas, como explicar, taquigráficas. Por exemplo: a as terminações em português como a mente, de felizMENTE, facilMENTE etc… no Braille, pode ser escrita como felizM, facilM, ou seja, apenas com um M maiúsculo, avisando que é esta terminação que vem a seguir. Sem o aviso de que idioma se trata na página como um todo, o leitor não poderia fazer os sufixos, radicais e prefixos abreviados nos idiomas. Em todos os idiomas têm isso… e é também com essa finalidade que existe o lang no elemento html/xhtml, ok? Outra coisa do da prioridade 3 é o summary, colocado nas tabelas para fazer um resumo da mesma. Ele não diz que é para suprimir, mas que ele não será obrigatório. O que não é obrigatório não é exatamente proibido! E por aí vai… Colocar uma carta inteira fora da tela por se tratar de uma imagem, pode ser muito interessante caso seja a única coisa da página, porque se estiver numa página principal e termos de ler sempre a tal carta que ele menciona, haja ouvido, haja audição! Sendo assim, seria melhor um d.link ou um longdesc que ele proibe… Como agora, há poucos dias, segundo o Maurício Samy Silva, saiu a versão definitiva, a 01, do Samurai, algumas coisas devem ter sido revistas e não sei como ficaram esses pontos, por exemplo.

    E lembrem-se sempre: acessibilidade é para todos, não é só para cegos. Abraços acessíveis do MAQ.

  • Pingback: Diário de bordo #16 » Revolução Etc()