WCAG Samurai

Boas informações, Ivo. Não tinha conhecimento do WCAG Samurai… renovaram-se minhas esperanças quanto ao WCAG 2.0 :)

Desconhecia mas agora vou fazer os possíveis para cumprir os requisitos do WCAG Samurai :D

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.

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.

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.

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á.

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.

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.

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.

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?

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.

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.

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?

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.

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.

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.

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.

“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.

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.

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.

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).

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.

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 :)

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

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.

Completando a informação desta discussão.

A primeira recomendação XHTML completa foi publicada no início de 2000. Contudo devido ao maciço legado do conteúdo Web, baseado em variações do HTML, os fabricantes de navegadores começaram vagarosamente a adotar o XHTML. Isto resultou em pouca motivação para os desenvolvedores de conteúdos adotar o XHTML em seu ambiente tradicional de desenvolvimento. Expoentes das comunidades de desenvolvedores e de design apelaram ao W3C para a necessidade urgente de uma revisão dos seus compromissos com o HTML

A primeira coisa que você deve saber é que o Internet Explorer 6 (e versões anteriores) não suporta XHTML. Ponto. Na verdade ele nem chega a suportar o HTML completamente. Seu XHTML funciona bem mesmo sendo enviado como se fosse HTML porque você aprendeu a escrever XHTML cumprindo as regras descritas no apêndice C da especificação do XHTML 1.0, mesmo que inconscientemente.

O apêndice C define as regras de compatibilidade entre XHTML 1.0 e HTML 4.01. São as regras que você deve seguir para poder enviar seus documentos XHTML como text/html e assegurar que os UAs atuais consigam renderizá-lo a contento.

O XHTML provou seu valor em outros mercados como o mercado de dispositivos móveis, em aplicações empresariais, no lado do servidor e em um crescente número de aplicações Web tal como os software para Blogs. Por exemplo: O Grupo de Trabalho para Práticas Web para Dispositivos Móveis, incluiu o módulo XHTML Basic como uma pedra angular nas Boas Práticas para Web Móvel porque softwares rodando com memória reduzida suportam aquele módulo. O mercado para XML é vasto e está crescendo, assim o W3C definirá a sintaxe XML para o novo HTML como complemento a sintaxe HTML tradicional.

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.

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

ui candidatos a marcadores no browser (:

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.

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.

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.

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

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!

É 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 :)