Comments on: Acessibilidade e o WCAG Samurai

By: Diário de bordo #16 » Revolução Etc

Diário de bordo #16 » Revolução Etc — Sun, 22 Jun 2008 19:12:34 +0000

[...] de pessoas liderada por Joe Clark. Se você não se lembra ou nunca ouviu falar do WCAG Samurai, a quase um ano atrás eu escrevi um texto sobre ele aqui. A versão em português já foi divulgada e teve sua publicação autorizada pelo próprio Joe [...]

By: MAQ

MAQ — Mon, 17 Mar 2008 03:28:30 +0000

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.

By: MAQ

MAQ — Mon, 17 Mar 2008 03:00:54 +0000

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.

By: Anonymous

Anonymous — Wed, 03 Oct 2007 08:15:04 +0000

[...] Acessibilidade e o WCAG Samurai – Revolu��o.Etc [...]

By: Fábio Pavani

Fábio Pavani — Fri, 14 Sep 2007 10:35:57 +0000

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 ^^