Introdução à WCAG Samurai Errata para as
Recomendações para Acessibilidade do Conteúdo da Web 1.0 (WCAG)

Esta é uma introdução à errata (correções) para as Recomendações para Acessibilidade do Conteúdo da Web 1.0. A errata é uma criação e publicação do WCAG Samurai, um grupo de desenvolvedores independentes formado no ano de 2006.

Aonde eu encontro a íntegra errata?

A errata está disponível desde 26 de fevereiro de 2008. Existem ainda dois documentos complementares — uma Paleta de Brewer para deficiências com cores e também uma versão PDF.

E sobre o WCAG 2?

Esta errata não cobre as WCAG 2.0 em nenhum dos seus aspectos. A WCAG Samurai Errata é uma alternativa à WCAG 2. Você pode seguir a WCAG 2 ou esta errata, ou mesmo não seguir nenhuma delas, mas não é possível seguir ambas.

Esta é a versão final?

Provavelmente sim. Esta versão 1.0 da errata é definitiva pelo menos para um futuro previsível nos dias atuais. Contudo, não podemos declarar taxativamente que revisões futuras não virão. Vamos esperar para ver como as coisas evoluem. Pequenos erros ou eventualmente maiores erros, serão corrigidos. Opiniões divergentes não se constituem erro no contexto da errata até porque, no geral, a errata é o produto final da opinião de um grupo.

Sumário rápido

A seguir um rápido sumário das modificações que fizemos nas WCAG 1. (Se você pretende seguir as WCAG+Samurai consulte os detalhes nas diversas seções componentes e não este sumário, que foi produzido apenas pela conveniência de fornecer uma visão geral.)

• Tal como no mundo real nós supomos que você está desenvolvendo, quase todo o tempo, com HTML e CSS e usando JavaScript algumas vezes. Nós não assumimos para nossas conclusões a hipótese de páginas futurísticas desenvolvidas prioritariamente com Flash, Silverlight e outras tecnologias.
• Nós banimos ou obrigamos: Nós não lançamos confusão usando termos imprecisos como "evite" e "até que os agentes de usuário" cujas definições dão margem a interpretações errôneas ou mesmo são ignorados. Em lugar disto você deve ou não deve aplicar uma determinada diretriz. Usamos termos como "apague", "ignore", "não requerido", "não deve ser usado" e "não use" ou então, "deve".
• Não para a prioridade 3: A maioria das diretrizes da prioridade 3 é inexeqüível, assim você não somente não tem que obedecê-lhas como também não deve cumpri-las.
• Sim para as prioridades 1 e 2: Você deve cumprir as diretrizes das prioridades 1 e 2 com as correções introduzidas pela Samurai. Entre outras coisas isto significa que você deve validar seu código em quase todas as situações.
• Não há novas diretrizes para deficiências cognitivas: WCAG 1 e 2 são inadequadas nas questões que tratam das deficiências cognitivas tal como a dislexia (esta é apenas uma das inúmeras inaptidões que em geral têm necessidades conflitantes). Nós não poderíamos deixar de concordar com a única diretriz abaixo da prioridade 3 que tenta contemplar deficiência cognitiva ("Use linguagem clara e simples"), contudo nós não criamos um conjunto de diretrizes para esta área. Nem ninguém criou, pois um trabalho desta grandeza requer muita pesquisa e mais importantes ainda, muitos testes com usuários. E nós não confiamos em muitas coisas que os ditos experts nesta área têm escrito. Estamos deixando as WCAG 1 quase exatamente como ela é. Por outro lado nós dizemos que a conformidade com a WCAG+Samurai não pode ser uma garantia de acessibilidade para pessoas com deficiências cognitivas.
• Tabelas para layout e uso de frames são práticas banidas: Todas as diretrizes que preconizam tabelas para layout e uso de frames devem ser apagadas. Você pode usar <iframe>.
• Adeus <noscript>: Scripts e "applets" (que podem ser entendidos como Ajax e Flash na maioria dos casos) devem ser diretamente acessíveis. Não use o elemento <noscript> para fornecer conteúdo alternativo, este elemento não deve ser usado.
• Nós banimos a maioria dos PDFs: PDFs que poderiam ser HTML estão banidos a menos que seja fornecido o respectivo HTML. Todos os demais PDFs têm que ser etiquetados.
• Adeus às relíquias do século 20: Em lugar de se quebrar a cabeça para fazer acessíveis as raridades do século passado nós simplesmente banimos artifícios desnecessários, tal como arte com ASCII.
• Multimídia é para nós mais sério do que para qualquer outra pessoa: Quase todos os vídeos sonoros devem ser legendados, a maioria ou todos os vídeos devem ter uma descrição sonora (dependendo do conteúdo), você deve transcrever diálogos podcast (mas não precisa transcrever músicas podcast) e não deve usar arquivos de texto ou HTML como substitutos para legendas ou descrições sonoras.

Como posso estar em conformidade com a errata?

A primeira coisa que deve ficar bem clara é que você não tem que estar em conformidade com esta errata. A WCAG Samurai Errata é uma opção às WCAG 1 que nós usamos como base para nosso trabalho. Comece lendo e entendendo as WCAG 1 e depois leia a errata como uma correção das WCAG 1.

A errata diz a você quais são as partes das WCAG 1 que devem ser ignoradas e quais estão incorretas. Ela esclarece a você os modernos e apropriados métodos a aplicar para desenvolver em conformidade com as WCAG 1. Assim, a errata escolhe, corrige ou aplica integralmente itens contidos na WCAG 1 como um todo. Mas você não pode escolher quais itens da errata irá aplicar. Você tem que cumprir todos os itens da errata no seu documento onde haja conteúdo no qual se aplique uma diretriz de acessibilidade.

Você não é obrigado a reivindicar conformidade com a WCAG Samurai Errata mesmo que você esteja conforme com ela. Mas, se você quer reivindicar a conformidade deve deixar isto bem claro. Nós não padronizamos uma forma oficial para isto, mas mostramos a seguir alguns exemplos:

• Este site está conforme as WCAG 1.0 corrigidas pela WCAG Samurai Errata.
• Nosso site foi desenvolvido em conformidade com as WCAG+Samurai.
• Nós nos preocupamos com acessibilidade e estamos em conformidade com as WCAG Samurai Errata.

Se apenas algumas páginas do seu site são conforme, reivindique acessibilidade somente para elas. Se apenas poucas páginas do seu site não são conforme, indique que elas não estão em conformidade.

A seguir exemplos de terminologia que você não pode usar:

• Estamos em conformidade com a maioria das diretrizes do WCAG (corrigidas). [Você não especificou claramente as WCAG Samurai.]
• A maioria das páginas deste site está em conformidade com as WCAG 1.0 e a WCAG Samurai. [Você tem que citar especificamente as páginas não conformes.]

Por que nós desenvolvemos o projeto Samurai em um processo fechado

Porque o processo ostensivamente aberto do W3C atualmente encontra-se fechado: Ele é dominado por multinacionais; a opinião de qualquer um que não seja convidado pode ser e é ignorada; o status de expert-convidado tem sido recusado ou revogado; o Grupo de Trabalho pode reivindicar que houve "consenso" mesmo nas questões não resolvidas por discordâncias internas; o processo de trabalho em si é inacessível a pessoas com necessidades especiais, como surdos, por exemplo; os membros do Grupo de Trabalho para as WCAG têm atuado como tiranos.

O processo "aberto" do W3C simplesmente não funciona. Nós tentamos fazer algo mais.

Implicações com a semântica HTML

A conformidade com a WCAG+Samurai implica em conformidade com todas as diretrizes das prioridades 1 e 2 das WCAG 1.0 devidamente corrigidas. Isto inclui a diretriz 3.2, que requer um código válido ("documentos passíveis de validação por gramáticas formais, publicadas"). Sabemos por experiência própria que um documento que seja estritamente válido para o HTML pode, ainda assim, ser inacessível. Um exemplo clássico é um documento que usa tabelas para layout. Um exemplo de maior relevância é o documento HTML válido, mas com marcação semântica pobre (por exemplo: todos os blocos de texto são marcados com o elemento parágrafo p, inclusive cabeçalhos e listas). Nós não podemos criticar o W3C por ter omitido a semântica quando escreveu as WCAG 1.0 nos idos de1990s, mas agora devemos corrigir aquela omissão.

Conformidade com a WCAG+Samurai implica em escrever documentos HTML válidos (com CSS também válida) e uso de marcação semântica correta. Sabemos que alguns conteúdos são ambíguos e em alguns casos você tem que fazer aproximações (Devo usar lista de definição ou listas não ordenada? Marcar um texto com <strong>? ou somente bold?) Casos extremos como estes não desqualificam um documento para conformidade com a WCAG+Samurai porque na web, a semântica correta para a maioria dos conteúdos é bem clara e não está em questão.

Uma vez que validação é obrigatória muitas das diretrizes das WCAG 1 tornam-se redundantes ou muito restritivas. Em particular, ao eliminar a necessidade de conformidade com a prioridade 3 algumas de suas exigências incluem a necessidade de um código válido e semanticamente correto.

• Você deve usar os elementos abbr ou acronym quando seu código exigir, mas há algumas considerações a fazer.
  • Você deve usar a marcação somente nos casos em que possa haver confusão para um humano ou uma tecnologia adaptiva (por exemplo: não marque "emissora de TV" como "emissora de <abbr>TV</abbr>").
  • Acrônimos e abreviações sem uma forma expandida no mundo real (por exemplo: DVD) não devem ser marcadas com estes elementos.
  • Não existe uma conclusão definitiva sobre o real significado de "abreviação", "acrônimo" e "inicialismo" e esta Errata deliberadamente não entra neste mérito.
  • Não existe um significado preciso do que a diretriz das WCAG quer dizer com a frase "em um documento no qual [a abreviação ou o acrônimo] aparecem pela primeira vez", pelo fato de que o usuário pode começar a ler o documento no ponto onde ele bem entender. Ignore esta recomendação.
  • Nós pretendemos esclarecer os problemas com o HTML relacionados à acessibilidade; não estamos interessados em perpetuar uma diretriz que dê margem a que alguém venha lhe dizer que sua página é inacessível porque a escolha inteligente que você fez para marcar abreviaturas e acrônimos não está de acordo com o seu ponto de vista. Você não só está autorizado como deve fazer as escolhas que julgue inteligente.
  • Também não estamos interessados em perpetuar práticas segundo as quais os autores sejam obrigados a marcar exaustivamente trechos de seus documentos para os quais os fabricantes de tecnologias adaptivas não estão se importando em implementar.
  • Não pensamos que um leitor ao procurar o significado de uma abreviação ou de um acrônimo crie barreiras para pessoas com necessidades especiais; naquele contexto tais leitores estão em um nível igual aos leitores sem necessidades especiais.
  Resumindo, o debate abreviação/acrônimo consome um tempo desproporcional ao quase nenhum dano que causa à acessibilidade até mesmo nos piores e mais mal marcados documentos.
• Concordamos que uma mudança no idioma principal do documento deva ser convenientemente marcada, mas é preciso que este idioma principal tenha sido definido no documento.
• Você dispõe de mais de uma maneira de explicar a finalidade de uma tabela de dados (inclusive com uso de um texto explicativo), então não há razão para requerer o uso do atributo summary que por padrão não é renderizado para alguém que enxerga, inclusive pessoas com necessidades especiais.
• Nós dispensamos você da obrigação de aplicar as diretrizes para as quais não existe uma semântica HTML – tal como agrupar seções relacionadas de um documento para a qual a única opção possível é o elemento não semântico <div>.
• Formulários dever ser corretamente marcados, inclusive com uso de rótulos para todos os controles que o exigem.

Diretrizes da Prioridade 3 a ignorar

Ignore todas as diretrizes da prioridade 3. Em particular:

• Diretriz 4.2: Você não é obrigado a fornece uma alternativa por extenso de abreviaturas e acrônimos a não ser que uma pessoa com necessidades especiais não consiga entender o documento sem a alternativa, conforme explicamos anteriormente.
• Diretriz 4.1: Você deve especificar o idioma principal do documento para poder marcar as mudanças de idioma. Isto é um pré-requisito para a diretriz 4.3 que requer a marcação de mudança de idioma. Marcação de idioma é sempre requerida quer para o idioma principal quer para mudanças de idioma. Não há como marcar mudança de idioma para os atributos, inclusive para os textos contidos no atributo alt assim não tente fazer isto.
• Diretriz 9.4: Não tente criar sua própria ordem de tabulação. Isto é tarefa para o navegador e para as tecnologias assistivas.
• Diretriz 9.5: Não personalize atalhos de teclado. Isto é tarefa para o navegador e para as tecnologias assistivas.
• Diretrizes 10.4 e 10.5: Não use textos pré-definidos em campos de formulários. Isto é tarefa para o navegador e para as tecnologias adaptivas. Campos de formulários podem conter textos depois de serem processados – por exemplo: após ter sido constatado que o ID escolhido por um usuário está indisponível o campo pode sugerir um ID – mas isto não é um texto pré-definido. Ou pode ser gravado um cookie com as informações já fornecidas pelo usuário para repopular os campos do formulário em determinados casos. Isto também não é um texto pré-definido.
• Diretriz 11.3: Na prática, não há como cumprir esta diretriz. Ela requer que o autor forneça traduções do documento (isto não é uma questão de acessibilidade) ou diferentes "tipos de conteúdos" (por exemplo: duplicar uma página inteira usando SVG, o que também não é uma questão de acessibilidade). Ignore esta diretriz.
• Diretriz 13.5: Nem todos os sites precisam de uma barra de navegação. Esta diretriz aplica-se somente aos sites que exigem uma barra de navegação. Se o site requer uma barra de navegação, ela deve ser consistente (por exemplo: não altere o aspecto e estrutura da navegação em seções correlatas do site) e usar marcação apropriada (em geral listas não ordenada <ul>). Se o site não requer um mecanismo de navegação você não é obrigado a construir a navegação.
• Diretriz 13.6: Nem todos os sites ou páginas têm "links relacionados" e o único elemento HTML semanticamente relevante para tal fim é previsto para uso em formulários (por exemplo, optgroup). O uso do elemento <link> dentro do elemento <head> não é obrigatório..
• Diretriz 13.7: Você não precisa oferecer múltiplos tipos de mecanismos de pesquisa ou busca (isto não é uma questão de acessibilidade). Ignore esta diretriz.
• Diretriz 13.8: Cabeçalhos são "informações identificadoras" e nós não conhecemos nenhum idioma que requeira começar cada parágrafo com uma "informação identificadora". Ignore esta diretriz. Contudo, algumas páginas web, como os glossários, podem seguir esta diretriz, colocando palavras-chave antes ou depois do parágrafo.
• Diretriz 13.9: Ignore esta diretriz.
• Diretriz 13.10: Não use arte ASCII.
• Diretriz 14.2: Use conteúdos da sua escolha. Você não é obrigado a ilustrar seus documentos (se você é cego não poderá ilustrar), pois ilustrações requerem textos alternativos.
• Diretriz 14.3: Você pode usar qualquer "estilização" que desejar, inclusive estilos não "consistentes".
• Diretriz 1.5: Ignore esta diretriz.
• Diretriz 5.5: O atributo summary de acordo com as especificações não é visível. HTML prevê inúmeras maneiras de explicar a finalidade de uma tabela (caption, summary, headers) e o mesmo resultado pode ser obtido descrevendo a tabela com texto puro. Quando afirmamos que você pode ignorar esta diretriz queremos dizer que você pode ignorar a obrigação de usar o atributo summary. Para algumas tabelas este atributo é útil.
• Diretriz 5.6: Ignore. Desnecessária e sem suporte consistente; esta diretriz requer abreviação para todos os cabeçalhos de uma tabela.
• Diretriz 10.3: Layouts CSS são mais do que adequadamente suportados, e você não deve usar tabelas para layout.

Exceção geral para documentos de ensino.

Documentos destinados ao ensino da acessibilidade, incluindo aqueles intencionalmente marcados de maneira errada ou que contenham funcionalidades a serem corrigidas pelos estudantes ou leitores estão isentos das WCAG+Samurai desde que sua destinação educacional seja declarada.

Revisores

Uma versão anterior desta Errata foi submetida a dois revisores independentes, Gian Sampson-Wild e Alastair Campbell. Você pode ler o resultado do trabalho deles em revisão de Gian e revisão de Alastair (ambos os links remetem a documentos em inglês). O WCAG Samurai não tem controle, não interferiu ou interfere nos conteúdos destas revisões.

Copyright

Esta errata é copyright © 2008 WCAG Samurai.

Baseamos esta errata no seguinte documento original do W3C (ao qual nós não somos filiados):

Documento original

Web Content Accessibility Diretrizes 1.0

E seus direitos copyright

Copyright W3C (MIT, INRIA, Keio). Todos os direitos reservados.

O status do documento do W3C

Este documento foi revisto por membros do W3C e por outras partes interessadas. Foi subscrito pelo diretor do W3C, como Recomendação Oficial do W3C. Trata-se de um documento estável, que pode ser utilizado como material de referência ou citado como referência normativa, em outro documento. O propósito do W3C, ao emitir esta Recomendação é chamar a atenção para o que nele foi especificado e promover a sua adoção generalizada, a fim de maximizar a funcionalidade e a universalidade da Web.

Colocamos as referências acima para cumprir as exigências de direitos autorais requeridas pelo W3C. Não confunda as referências como sendo aplicáveis ao documento que você está lendo.

Esta errata foi desenvolvida independentemente do W3C e não expressam nenhuma declaração ou impressão a respeito das posições e ações do W3C. Francamente nós não temos intenção de emitir juizo a respeito do W3C nem queremos que eles emitam juízo sobre nós.

W3C™ é marca registrada do World Wide Web Consortium. Também é o HTML™, mas "WCAG" não é.

Adicionalmente, esta errata é publicada como uma revisão e crítica ao WCAG 1.0 sobre os termos das leis canadenses de direitos autorais. Esta errata não é um trabalho derivado das WCAG1.0 e nem uma "integração de errata".