WCAG Samurai
Terça-feira, 26 de Junho de 2007
O que é o WCAG? Esta sigla significa “Web Content Accessibility Guidelines”, ou seja, é um conjunto de regras para assegurar que os conteúdos disponibilizados na Internet são acessíveis. O WCAG 1.0 foi publicado em 1999 e, com o evoluir das tecnologias e da própria Internet, as suas regras e recomendações estão já um pouco desactualizadas. Assim, há alguns anos começou-se a trabalhar no WCAG 2.0 que supostamente viria substituir a versão anterior e traria a devida actualização às regras e recomendações de acessibilidade.
No entanto, nem tudo são rosas. O WCAG 2.0 está ainda em fase de revisão e muitos afirmam que as regras e recomendações disponibilizadas não são fáceis de compreender porque estão escritas de uma forma demasiado genérica. Numa entrevista no Podcast UXPod, Gerry Gaffney entrevistou Gian Sampson-Wild, uma antiga colaboradora do projecto que deu um bom exemplo das diferenças de linguagem entre o WCAG 1.0 e o WCAG 2.0.
Por exemplo, na versão 1.0 é dito que “as Frames devem ter um título que as identifique e facilite a sua navegação”. No WCAG 2.0, a mesma recomendação é dita da seguinte maneira: “O destino de cada referência programática para outra unidade de entrega deve ser identificado por palavras ou frases que ocorrem no texto ou que podem ser programaticamente determinadas” (tradução livre).
Basicamente, o que se tentou fazer na versão 2.0 foi torná-la tecnologiamente neutra, ou seja, as recomendações devem ser aplicadas a vários tipos de elementos, não só aos “frames”, mas a outros elementos semelhantes que possam aparecer no futuro. No entanto, isto dificulta bastante a própria percepção das recomendações e é por isso que muitos autores desistiram do WCAG 2.0 e formaram um outro grupo, o WCAG Samurai.
A ideia por detrás do WCAG Samurai é a de criar uma Errata para o WCAG 1.0 de modo a que possamos continuar a usar essa versão do documento, mas adaptada à tecnologia actual. No passado dia 7 de Junho foi lançada a primeira versão da Errata e aqui estão as principais alterações efectuadas ao WCAG 1.0:
- Foram eliminados termos como “evite usar…” e passou a usar-se uma linguagem mais agressiva como “não use…” ou “é obrigatório ter…”;
- Eliminação das regras de Prioridade 3, por serem praticamente impraticáveis;
- É obrigatório seguir as recomendações das Prioridades 1 e 2. Isto significa que é obrigatório ter código válido em todos os casos;
- Não foram adicionadas novas regras para deficiências cognitivas. Tanto o WCAG 1.0 como o WCAG 2.0 têm falhas a este nível e o WCAG Samurai não certifica que, mesmo seguindo todas as regras, o website seja acessível para pessoas com este tipo de deficiência, como é o caso da dislexia ou outras;
- O uso de tabelas e frames para layout é completamente banido. No entanto podem usar-se ainda iframes;
- Fim do noscript. Todos os scripts e applets (mais conhecidos como AJAX e Flash na maioria dos casos) devem ser directamente acessíveis em vez de se usar a técnica do noscript;
- Não devem ser usados PDFs. Tudo o que estiver disponível em PDF deve também estar disponível em HTML;
- Todos os vídeos com som devem ter legendas ou audio descrição (dependendo dos conteúdos);
- Entre outras recomendações que estão disponíveis na Errata.
O aparecimento desta errata é um grande passo para a melhoria da acessibilidade na web. Veremos como vai ser o futuro deste WCAG Samurai e se vamos ver os validadores automáticos adoptar estas novas regras.
Ivo Gomes tem 29 anos e é licenciado em
Walmar Andrade
26 de Junho de 2007, 12:44
Boas informações, Ivo. Não tinha conhecimento do WCAG Samurai… renovaram-se minhas esperanças quanto ao WCAG 2.0
Dextro
26 de Junho de 2007, 13:25
Desconhecia mas agora vou fazer os possíveis para cumprir os requisitos do WCAG Samurai
João Martins
27 de Junho de 2007, 00:22
Se me permite uma nota acerca da acessibilidade nos PDFs, acho que, independentemente do que diz o WCAG Samurai, vale a pena ler o artigo de Joe Clark de 2005, reeditado no último número de A List Apart, sobre a acessibilidade de PDFs.
Jorge Laranjo
27 de Junho de 2007, 17:58
Excelente artigo Ivo.
Mas concordo com o João Martins porque diga o que disser o WCAG por vezes o PDF é o formato indicado.
O que não quer dizer que não se possa fazer um “parsing” do PDF para XHTML mas se o PDF for acessível… não via necessidade.
Ivo Gomes
29 de Junho de 2007, 15:20
O Joe Clark é um dos principais impulsionadores do WCAG Samurai, logo, ele é que disse para evitar o uso de PDF. No artigo na Lista Apart, ele diz a mesma coisa: O que existe em PDF deveria existir também em HTML. E se for mesmo necessário usar um PDF, então devem ser usadas tags no documento para estruturar a informação.
Jorge Laranjo
29 de Junho de 2007, 15:35
O que eu queria dizer é que é ridículo manter duas versões ainda que automáticas.
Claro que se estiver disponível em PDF deverá estar em formato acessível.
A versão automática poderá estar disponível mas o PDF tem um propósito diferente do XHTML.
E só porque há um tipo que até percebe disso a dizer que deve estar disponível em XHTML então para isso não precisamos do formato PDF…
Neste ponto discordo do que ele diz, salvaguardando que o PDF deve ser 100% acessível, claro está.
Ivo Gomes
29 de Junho de 2007, 16:00
Do meu ponto de vista, o PDF foi feito para documentos impressos, ou seja, é um método de partilha de documentos mantendo a sua formatação original, mas são documentos que estão formatados para impressão e não para leitura num site.
Jorge Laranjo
29 de Junho de 2007, 22:25
Embora concorde que o PDF tenha sido feito com o propósito da impressão já havia também o “post-script”.
Acho que o PDF é uma forma de ter um documento devidamente formatado e pronto para impressão, com a vantagem dessa impressão ser igual em qualquer lugar onde se abra esse PDF.
Mas o PDF tem outras vertentes desde suportar links.
Numa época em que se diz para poupar papel acho que o PDF é um bom formato para ler documentos no ecrã (desde que com um bom monitor).
Assim, se tenho um documento de várias páginas em PDF será viável fazer o “parsing” para XHTML se o PDF já foi acessível?
É que até o Google pesquisa dentro de PDFs.
Gaspar
2 de Julho de 2007, 00:18
Eu acho que o PDF nunca irá ser melhor do que uma página em HTML para ser lida online.
Sem me debruçar muito sobre o assunto não temos o controle do tamanho do texto, a navegabilidade é limitada, controle de imagens, actualização do conteúdo.
Agora também sei que o PDF tem numerosas funções que o HTML NUNCA vai ter.
Por isso também acho quase todos os PDFs online devem ter uma alternativa em HTML.
Jorge Laranjo
2 de Julho de 2007, 02:04
Atenção que o que é dito é que Tudo o que estiver disponível em PDF deve também estar disponível em HTML;
O que eu digo é que nem tudo o que está disponível em PDF tem necessariamente de o estar em XHTML.
Imaginemos que temos um formulário em PDF (100% acessível e para ser preenchido e enviado por e-mail e/ou correio normal).
Será licito exigir que seja produzido o mesmo formulário em XHTML apenas e só com o intuito de cumprir as regras?
E se o importante for imprimir e enviar por correio? (pode haver muitas justificações para isto e muitas mais para que tal não seja necessário).
O que eu quero afirmar é que é muito mais complicado do que pode parecer, IMHO, exigir que os PDF estejam acessíveis em XHTML.
Em minha opinião os PDF devem ser 100% acessíveis. Quanto à questão de estar disponível uma versão XHTML dependerá sempre do caso. Não fará, obviamente, sentido manter um site baseado em PDFs. Mas só porque estão disponíveis alguns PDF e desde que estes sejam acessíveis não vejo razão para a versão XHTML (que poderá ser complicada de manter).
É que os sites não são “fabricados” e depois ficam estáticos. Mudam de conteúdos e muitas vezes a pessoa (ou equipa) que os gere não está sensibilizada para a acessibilidade.
Uhm, ou estarei a ver mal a questão?
Gaspar
2 de Julho de 2007, 10:57
Eu quando disse “quase” tudo pensei nesses PDFs tipo formulários onde tu podes gravar o PDF para o disco e preenche-lo e posteriormente enviar. Também existe o caso dos relatórios e outros com muito gráficos. E existem N funções que poderás usar com o PDF em que não conseguirás o mesmo desempenho com o (X)HTML.
Agora tipo o anteior formulário poderias ter uma versão em (X)HTML e possibilitar o envio dos dados.
Jorge Laranjo
2 de Julho de 2007, 11:04
No que diz respeito a formulários: valerá a pena (será viável financeiramente) colocar online um formulário interactivo se esse mesmo formulário já estiver num PDF e o PDF for acessível?
Claro que falo de formulários que estarão online durante relativamente pouco tempo, porque se fosse para o “longo prazo” então seria viável colocar o XHTML. Mas no curto prazo e até mesmo médio prazo, será viável?
Depende! Da complexidade do formulário, por exemplo.
Gaspar
2 de Julho de 2007, 11:13
Financeiramente! Bom para mim que quisesse que pelo menos 10 pessoas preenchessem o tal formulário era o suficiente para justificar a criação do formulário em (X)HTML.
Não seu que despesas poderás vir a ter com um formulário? Não te é assim tão dispendioso.
Eu fazia a pergunta ao contrário valeria a pena colocar o formulário em PDF, preencho o formulário em uns minutos? terá o utilizador alguma vantagem em gravar para o disco? Poderei utilizar fácilmente os dados recebidos pelo PDF. Será este acessivel a todos os utlizadores?
Jorge Laranjo
2 de Julho de 2007, 11:20
Não te custa nada, criar o formulário se não tiveres uma empresa a sério.
Mas se tiveres de deslocar um designer para o desenhar (partindo do principio que o formulário não está desenhado e nem tem “CSS”) e um programador para dizer à framework que mostre o formulário e o valide, acho que isso já representa custos, pois essas pessoas vão estar a fazer essa tarefa e não outra qualquer.
Claro que se for em “casa” e ao estilo “amador” não custa nada… ou assim se pensa.
Na vida real isso já não é bem assim e cada hora tem de ser rentabilizada ao máximo.
Gaspar
2 de Julho de 2007, 12:59
Sim mas penso que o mesmo se passa com a criação de PDFs formulários minimamente acessiveis. Depois desses formulários vais criar uma base de dados? Tens modo de extrarir a informação do PDF de um modo rápido?
Um formulário simples a acessivel não custa muito a criar, existem N scripts que fazem a devida validação.
Jorge Laranjo
2 de Julho de 2007, 13:12
A questão é que se o PDF já existir porque haveremos de criar um XHTML?
Outro problema seria a integração de scripts que andam na net. Mais uma vez, a integração desses scripts custa tempo ao programador.
A questão que coloco é: se existir um PDF acessível então porque criar uma versão XHTML se isso não se mostrar financeiramente viável?
E extrair dados de PDF desde que ele esteja bem feito (ou via submissão) é trivial. Mais uma vez digo: se tais operações já estivessem previstas no PDF porque criar uma versão XHTML?
Então seria melhor criar a versão XHTML e apagar a PDF mas por vezes o PDF é o melhor formato.
É por isso que não se pode dizer “sempre” mas sim “quase sempre” quando se refere a necessidade da existência de uma versão XHTML de um documento PDF, IMHO.
Gaspar
2 de Julho de 2007, 14:07
1º ponto estou de acordo contigo não será sempre mas quase sempre e este “quase sempre” seria quando um PDF for mais mais eficiente (segurança, navegabilidade, acessibilidade, etc). O que eu não consigo encontrar não quer dizer que tal não exista.
Claro que quando comparo uma página em (X)HTML e um PDF parto do principio que ambos tem foram criados com o o mesmo nivel de acessibilidade, etc.
A implementação de um formulário é dispendiosa! também a do PDF! e este último secalhar ainda é mais!?
Mas podemos ficar a discutir eternamente sem chegarmos a nenhum consenso.
Terminando eu concordo que talvez não se deva usar o “sempre” mas para isso terás conseguires criar ujma solução em PDF com todas as garantias de uma página (X)HTML. E se mesmo nestas não consegues garantir uma eficiencia a 100% nos PDF muito menos.
Jorge Laranjo
2 de Julho de 2007, 14:12
“E se mesmo nestas não consegues garantir uma eficiencia a 100% nos PDF muito menos.”
Não concordo. Até acho que é bem mais fácil conseguir a acessibilidade total nos PDF do que no XHTML. Isto porque o XHTML foi feito para documento e não tanto para design. E é por isso que ainda temos problemas de acessibilidade… ou pelo menos isso ajuda à festa.
BTW: HTML já não se usa (says W3C). É por isso que escrevo XHTML e não (X)HTML.
E sim, podemos ficar a discutir eternamente que nunca vamos chegar a uma conclusão simplesmente porque a solução (PDF/XHTML) depende do problema a resolver e do que já existe feito.
Gaspar
2 de Julho de 2007, 14:39
HTML já não se usa! Tás redondamente enganado! Podes ver que o grupo de trabalho HTML da W3m podes dizer que foi abandonado até ao início deste ano mas o HTML 5 está a ser pensado agora, assim como o (X)HTML 2. Existem muitas divergencias e falhas com o XHTML para o HTML morrer.
Quanto á acessibilidade no PDF e (x)HTML já criei formulários em PDF há uns anos e não é tão fácil, reparei que o CS2 incorpora uma ferramenta nova somente para PDFs (não experimentei) mas garanto-te que sem saberes muito com o dreamweaver ou mesmo frontpage
basta seguires 2 ou 3 regras básicas e tens um formulário totalmente acessível.
E sim o HTML assim como o (x)HTML são meramente estruturais para o design ou apresentação tens o CSS.
O design de pouco serve para a acessibilidade pode ajudar nalguns casos mas mais a nível de usabilidade, pois normalmente se uma página estiver bem estruturada não é preciso nenhum design, basta simplesmente o HTML. Bom e nesta troca de argumentos não me posso aprofundar muito, pois a nível de criação de PDFs a minha experiencia é fraca agora a nivel de CSS/(x)HTML trabalho há mais de 5 anos e neste momento ocupa-me 2/3 do dia.
Jorge Laranjo
2 de Julho de 2007, 14:50
O HTML5 ainda não é definitivo logo continuo a ter razão: O HTML já não se usa, pelo menos até sair o HTML5 (se sair).
Dream-quê? Ah, isso da Adobe. Não sei, não uso. Não uso ferramentas Adobe para ter acessibilidade. Não preciso.
O design, a meu ver, serve muito na acessibilidade. Ninguém quer um site, documento, seja o que for feio. E o desenho também ajuda na acessibilidade até porque, IMHO, a acessibilidade anda de mão dada com a usabilidade.
PS: Não vamos medir os anos em que cada um anda a fazer o quê pois não?
Primeiro porque a experiência não é “ao quilo” e depois porque nesse campeonato sou bem capaz de ganhar… o que seria irónico, quando muito.
Acho que o assunto que começou a troca de “comentários” está finalizado, portanto este não é o local ideal para este tipo de discussões… digo eu.
Jorge Laranjo
2 de Julho de 2007, 14:53
BTW, quando falo em HTML refiro-me ao HTML 4. O HTML 5 ainda não existe com a sua forma definitiva (e longe estará de o ser…)
Portanto a não ser que esteja a ver mal as coisas, HTML já não se usa (até ver).
Gaspar
2 de Julho de 2007, 15:01
Também acho este não é o local indicado para discutir este assunto.
Apesar de achar estas discussões enriquecedoras e é com este intuito que participo nas mesmas.
Espero noutra altura num lugar mais apropriado possamos discutir este aprofundar este assunto. Garanto-te que vou insvestigar um pouco mais a acessibilidade nos PDFs.
ps.
Quanto ao HTML acredita que se usa e cada vez mais gente vai renunciando ao (x)HTML.
Jorge Laranjo
2 de Julho de 2007, 15:07
Tens o link para a minha homepage e tens lá o contacto. Podemos continuar esta troca de ideias via e-mail.
PS: Desculpa lá Ivo por termos invadido assim a tua “casa” na web
Ivo Gomes
2 de Julho de 2007, 15:58
No problem. As discussões são sempre boas quando as duas partes têm pontos de vista diferentes e tentam explicá-los educadamente. Quando se começa a baixar o nível é que é pior.
Vou só dar a minha opinião sobre o XHTML vs. HTML: Não acho que o HTML já não se use, antes pelo contrário. Aqui há 1 ou 2 anos o XHTML estava na moda, mas rapidamente está-se a voltar ao HTML 4 Strict em vez do XHTML. Isso prende-se com o facto do XHTML não suportar grande parte das funcionalidades de XML para as quais ele foi desenvolvido e porque vários browsers (IE) não reconhecem o mime/type XHTML. Assim estás a servir XHTML mas estás a dizer ao browser que o mime/type é text/html (http://hixie.ch/advocacy/xhtml). Ora, isso assim não faz sentido.
Tens aqui mais algumas razões porque não se deve usar (ainda) XHTML: http://codinginparadise.org/weblog/2005/08/xhtml-considered-harmful.html
Jorge Laranjo
2 de Julho de 2007, 16:21
Mas fará sentido ter tudo pronto para o XHTML para quando ele for suportado? A este ritmo não vejo o XHTML a ser suportado mas pelo menos o código já estava conforme… É um pau de dois bicos. Tenho usado XHTML e servido como HTML, sim mas não será melhor para o futuro ter isso assim pronto?
A W3C não está a ajudar com estas lutas internas.
Gaspar
3 de Julho de 2007, 11:54
Completando a informação desta discussão.
Pelo que eu vejo pela web fora existe muitas dúvidas, entre os experts, acerca se é correcto ou não usar o XHTML enquanto txt/html.
Eu por vezes uso outras não depende se pretende usar alguns atributos ou não.
Jorge Laranjo
3 de Julho de 2007, 12:29
Já agora deixo um link para um artigo que compara as diversas versões do HTML e XHTML.
Espero que seja útil.
HTML elements index
ponto
3 de Julho de 2007, 22:39
ui candidatos a marcadores no browser (:
Dextro
3 de Julho de 2007, 22:50
Quanto aquele link que o Ivo deixou aqui nos comentários preciso de deixar uma resalva: Não vejo porque é que os iframes continuam a ser tão importantes? Não é possível fazer o mesmo com CSS e a propriedade overflow? AJAX serve para renovar o conteúdo…
Claro que com tanta gente a alegar a redundância que que não se deve usar XHTML porque ainda não é muito usado vai manter as coisas como estão…
Eu pessoalmente gosto do XHTML, tudo o que obrigue um web developer a ter de abrir e fechar os elementos tal como em qualquer linguagem de programação é bom a meu ver, mesmo que pareça ser algo picuinhas.
Ivo Gomes
4 de Julho de 2007, 08:59
A única diferença entre o código que escrevo em HTML 4.1 Strict e XHTML é não usar o “/>” no final das tags que não têm a correspondente tag de fecho. Fora isso, só muda o DOCTYPE e mais nada. Assim posso facilmente mudar de HTML para XHTML sem grandes dificuldades. A maior parte das regras usadas no XHTML podem ser aplicadas no HTML.
Gaspar
4 de Julho de 2007, 09:57
Eu pessoalmente não gosto muito do AJAX quando este é usado para meramente renovar conteudo, enquanto conteudo. Caso este meramente sejam mensagens de aviso ou informação que não constitua o nucleo central da informação.
Penso que não justifica o uso de AJAX somente para renovar informação sem o reload da página. Penso que isso já se fazia nos anos 90s via framesets.
chulapa
19 de Julho de 2007, 15:10
nossa, d+ o seu blog, muito conteudo bom e como sou da area da informatica entao, um prato cheio…um abraco e muito sucesso pra vc parceiro
MAQ
31 de Março de 2008, 18:05
Bem, amigos, eu utilizo o HTML strict em um site e o XHTML em outro, ambos strict. A vantagem para mim que sou cego de utilizar o XHTML strict é que ele aponta erros de acessibilidade, como a ausência do atributo alt, a presença de targets na validação do markup do W3C… já facilitando a coisa para nós cegos. Quanto ao Samurai, quase esquecido nos comentários, quando é dito para não se utilizar a prioridade 3 do WCAG 1.0, tem-se de tomar cuidado em se ler todo o documento para se entender que existem muitas ressalvas em que se utiliza tal prioridade. Um exemplo é que no elemento htm a utilização do atributo lang deve ser usado, menos quando a página possua inúmeros idiomas e não se consiga definir qual deles é o heterogênio para ser utilizado. A colocação do idioma no atributo lang é importante para as abreviações do display Braille. Mas isso é uma outra história que daria um tutorial por aqui! De uma forma geral o WCAG Samurai vem preencher uma lacuna já há muito vazia e reavivar o implemento de acessibilidade no desenvolvimento de páginas, usabilidade e arquitetura da informação dos sites. Abraços acessíveis a todos… HTML e XHTML zeiros da web!
Ivo Gomes
4 de Abril de 2008, 17:30
É sempre bom ter comentários de pessoas que infelizmente sofrem na pele os problemas de acessibilidade dos sites. Só o facto de testarmos as nossas aplicações e websites em sistemas automáticos e tentarmos ao máximo ter todos os cuidados com a acessibilidade por vezes pode não ser suficiente.
É com utilizadores reais que vemos realmente que o nosso trabalho pode fazer a diferença.
Obrigado @MAQ