WCAG Samurai Errata para as Recomendações para Acessibilidade ao conteúdo da Web (WCAG) 1.0

V1.0 de 26 de fevereiro de 2008

Se você ainda não o fez, talvez seja interessante ler a introdução antes de prosseguir. As seções que se seguem foram organizadas segundo as Recomendações para a acessibilidade ao conteúdo da web (WCAG) 1.0 as quais tomamos como base para nosso trabalho.

Nota especial sobre deficiências cognitivas

Esta errata não faz uma correção substancial das diretrizes do WCAG 1 no que diz respeito às deficiências cognitivas. Conformidade com a WCAG+Samurai não pode gerar reivindicação de plena acessibilidade para pessoas com deficiências cognitivas.

Diretriz 1.
Fornecer alternativas equivalentes ao conteúdo sonoro e visual

O erro maior nas discussões sobre equivalentes textuais é acreditar que um texto equivalente deve ser capaz de "transmitir, em essência, as mesmas funções e finalidade que o conteúdo sonoro ou visual" (WCAG 1). Dito assim, leva as pessoas a concluir que devam escrever um tratado para descrever uma simples imagem: "Esta é a imagem de uma seta que é um link para a home page".

Ademais, equivalentes textuais somente podem ser avaliados por humanos. Escrevê-los é uma tarefa subjetiva. WCAG Samurai não pretende ditar a maneira como devam ser escritos.

WCAG Samurai redefine equivalente textual como sendo um substituto para uma imagem ou outro conteúdo.

• Você deve ser capaz de substituir um texto equivalente pelo seu item original. Feito isto a página não deve perder sua funcionalidade e os leitores não perderão a informação.
• Não há como evitar perda de significado quando se descreve textualmente alguns objetos como fotografias e pinturas. Seria irrelevante definir "significado" neste contexto; assim como nós incentivamos você a escrever seus próprios textos equivalentes, também o incentivamos a decidir racionalmente o que é realmente equivalente.

Correções gerais na Diretriz 1.1

• Fornecer um equivalente textual "no conteúdo do elemento" aplica-se somente a eventuais elementos iframes e quando conveniente a SVG ou Flash. Em páginas HTML comuns não há como fornecer texto equivalente "no conteúdo dos elementos". Posicionar fora da tela um conteúdo alternativo para o texto contido em uma imagem é permitido.
• Você pode deixar o equivalente textual em branco — por exemplo: alt="" (sem inserir espaços em branco entre as aspas) se o texto imediatamente anterior ou posterior à imagem cumprir a função de texto equivalente.
• "Representações [g]ráficas de textos" e "imagens representativas de textos" são uma espécie de retrato do texto. Não há qualquer proibição de usar imagens de textos, desde que se forneça uma alternativa textual equivalente.
  • Em HTML use o atributo alt para descrever exatamente o mesmo texto contido na imagem (mesmo que o texto esteja escrito em mais de um idioma).
  • Exemplos tipográficos ou ilustrações não ligadas a uma linguagem corrente não precisam de descrições detalhadas como por exemplo: alt="Exemplo da fonte Verdana mostrando letras e números". Imagens contendo detalhes tipográficos que interessam ao contexto (por exemplo: determinados tipos de fontes ou grafia em negrito ou itálico), ou imagens contendo extensos blocos de texto onde o design gráfico seja de interesse não precisam de um equivalente textual para o texto completo, bastando apenas uma explicação sobre os pontos de interesse na imagem.
  • Símbolos não são "representações gráficas de textos" a menos que sejam imagens. Neste caso use símbolos para transmitir informação em gráficos somente se não houver um equivalente Unicode ou em outra codificação de caracteres. Por exemplo: não use a imagem de uma seta, use o caractere Unicode que representa uma seta.
• "Applets" e "scripts" devem ser intrinsecamente acessíveis, usando as funcionalidades do JavaScript ou do Flash. Não use equivalentes textuais para applets intrinsecamente acessíveis. Ignore as referências do WCAG sobre "objetos programados".
• Se você pretende usar imagens para marcadores de lista, faça isto com CSS:

  ul {list-style: url("seta.gif") disc;}

• Arquivos PDF quando publicados de maneira normal (por exemplo: um link para o PDF) não é uma informação não textual e portanto não necessitam de equivalentes textuais.
• Quando um link aponta para uma imagem de modo a que ela seja vista separadamente não é necessário fornecer um equivalente textual. Por exemplo: um link apontando para http://wcagsamurai.org/imagem.jpg não precisa de um equivalente textual.

O que não fazer

Não usar GIFs animadas, arte ASCII, frames, imagens espaçadoras, ou mapa de imagens no lado do servidor.

Cartas e diagramas

• O equivalente textual para uma carta ou diagrama (por exemplo: o atributo alt) deve explicar as funcionalidades da carta ou diagrama que sejam relevantes para o entendimento do documento e sirvam para evitar interpretações errôneas.
• Cartas e diagramas contendo muitas informações devem ser explicadas com uso do atributo longdesc ou mesmo com texto e neste caso o texto poderá ser posicionado fora da tela se for assim desejado.
• Não forneça a título de texto equivalente, um link para um documento contendo um conjunto de dados. Esta prática é permitida somente como um adicional ao fornecimento do equivalente textual.

Sons e arquivos de áudio

• Sons não devem ser ativados sem que haja intervenção do usuário. Suas páginas ou seu site não devem reproduzir som automaticamente ao serem carregadas.
• Sons e diálogos em games ou inseridos em qualquer outro conteúdo quer sejam pré-gravados quer sejam gerados, devem ser legendados (ressalvado os casos a seguir).
• Podcasts e gravações de diálogos, discursos e entrevistas devem ter uma versão transcrita.
  • Grandes sites com possibilidades financeiras significativas e com recursos disponíveis devem publicar uma versão transcrita dos conteúdos simultaneamente ao lançamento do podcast. A publicação simultânea não é uma obrigatoriedade para pequenos sites com orçamentos limitados (inclusive para blogs pessoais), mas a posterior publicação não deve demorar um tempo considerável. (Nós não definimos o que é um site pequeno ou grande e nem o que seja tempo considerável.)
  • Gravações usadas como exemplificações de língua falada (onde a própria língua ou seu uso são a finalidade da gravação e não está em questão o significado das palavras gravadas), inclusive sessões de aprendizagem e gravações lingüísticas, não têm que ser transcritas.
• Podcasts e gravações musicais, incluindo repertórios de DJ e programações musicais das broadcasters e webcasters, não têm que ser transcritas. Contudo deve ser publicada uma listagem contendo os títulos das músicas e respectivos artistas o mais rapidamente possível após o lançamento do podcast. (Nós não definimos um prazo para "o mais rapidamente possível".)
• Podcasts e gravações em idiomas diferentes do idioma principal do documento não precisam ser traduzidas ou dubladas. (Se você lança 20 podcast em um idioma e a metade de um episódio em um podcast está em outro idioma, você não precisa traduzí-lo.) Não reivindique acessibilidade para uma tradução.
• Broadcasts e webcasts não precisam ser transcritas ou legendadas quando reproduzidas ao vivo e não gravadas. Caso sejam gravadas ou arquivadas aplicam-se as disposições anteriores. Em particular, isto significa que serviços de audio-streaming que reproduzem broadcast devem tratar tais reproduções como qualquer outra gravação.
• Telefonia na internet, troca instantânea de mensagens, conversação durante games e outras formas de voz ao vivo não são conteúdos web e assim, não precisam ser transcritas ou legendadas.

Vídeos

• Vídeos não devem ser ativados sem que haja a intervenção do usuário. Suas páginas ou seu site não devem reproduzir vídeos automaticamente ao serem carregadas.
• Vídeos com narração sonora devem ser legendados. (As legendas devem ser no mesmo idioma da narração sonora e não uma tradução da narração.) Filmes mudos não precisam ser legendados, mas deve ser fornecida uma explicação da condição de ausência de som no link ou no objeto que contém o vídeo.
• Videos que não possam ser entendidos pela sua própria narração sonora devem ser acompanhados de uma descrição em áudio. Vídeos com narração sonora e desprovidos de componente visual (por exemplo: uma tela preta) não precisam de descrição áudio, mas pelo fato de não existir um componente visual deve ser fornecida uma explicação da condição de ausência do componente visual tanto no link para como no objeto que contém o vídeo.
• Vídeos contendo exemplificações de linguagem escrita, falada, ou de sinais, (onde a própria língua ou seu uso são a finalidade da gravação e não está em questão o significado das palavras gravadas), inclusive sessões de aprendizagem e gravações lingüísticas, não têm que ser transcritas.
• Vídeos em idiomas diferentes do idioma principal do documento não precisam ser traduzidos ou dublados. (Se você lança 20 vídeos em um idioma e a metade de um episódio em um vídeo está em outro idioma, você não precisa traduzi-lo.)
  • Incluindo-se aí vídeos sobre linguagem de sinais, que não precisam ser traduzidos. Mas, se houver explicação com voz ou outro tipo de som correspondente, deverá ser legendado.
  • Não reivindique acessibilidade para uma tradução.
• Screencasts (slideshows narrados) são equivalentes a vídeos em câmera lenta com narração em velocidade normal e devem ser legendados.

Notar que uma transcrição seja em texto puro, seja em HTML ou outro formato qualquer não é um substituto para legendas ou descrição áudio. Uma transcrição pode ser fornecida como opção adicional.

Diretriz 2.
Não recorrer apenas à cor

Esta é talvez a mais simples e a mais mal interpretada diretriz das WCAG 1, em parte devido a confusão causada pela inabilidade do ser humano em tratar com o equipamento computador (e também pela falta de interpretação correta desta inabilidade).

As finalidades desta diretriz são:

• Prevenir o uso de cores que possam causar confusão (para usuários com deficiências visuais – protanopia, deuteranopia, e tritanopia).
• Evitar fazer referência a qualquer item na página usando somente a cor. Esta prática contempla um pequeno grupo de usuários portadores da deficiência visual achromatopsia, que vem a ser a incapacidade de distinguir cores e também para usuários cegos).

As diretrizes das WCAG não preconizam combinações de cores preferenciais para usuários com determinadas deficiências de aprendizado. Assim como para outras diretrizes constantes da WCAG, referentes a deficiências de aprendizado, esta errata não contempla tais deficiências.

Ignore tudo que diz respeito a "dispositivos não visuais" ou "dispositivos monocromáticos". Acessibilidade na web diz respeito a usuários com necessidades especiais e não a seus equipamentos. Um "dispositivo" não é uma pessoa e não precisa de acessibilidade.

Cores confusas são tipicamente aquelas ao longo dos eixos das cores vermelha e verde (para as mais comuns das deficiências para cores, protanotopia e deuteranopia) e dos eixos das cores azul e verde (para o outro tipo de deficiência, a tritanopia). As cores substitutas para os deficientes também são confusas e tendem para as cores beje, amarelo não saturado e marrom. Todas as cores e tons similares são cores confusas.

• Para conteúdos (na maioria dos casos textos) não defina cores confusas uma sobre a outra. Por exemplo: não coloque textos na cor vermelha sobre um fundo verde ou preto. Não há limitações para uso de cores confusas em elementos de design nem para seu uso em elementos próximo uns dos outros (por exemplo: um retângulo vermelho sólido ao lado de um retângulo de fundo branco contendo textos em verde).
• Não use a cor isoladamente para transmitir uma informação no documento, quer seja na marcação quer em folhas de estilo. Por exemplo: não retorne ao usuário um formulário contendo erros que devam ser corrigidos, indicando-os somente com uso de cor vermelha; use marcação adicional tal como strong, e/ou links de texto como um asterisco; e/ou explique textualmente quais foram os erros cometidos e aonde eles se encontram.

Diretriz 3.
Utilizar corretamente marcações e folhas de estilo

Todas as páginas em conformidade com a WCAG+Samurai devem usar códigos HTML e CSS válidos.

• Você pode usar qualquer DOCTYPE para HTML ou para XHTML exceto Frameset, qualquer revisão para o HTML que tenha sido publicada (até mesmo "HTML 5" ou a versão em rascunho para o "HTML 5") ou ainda qualquer DOCTYPE para XML, inclusive suas próprias versões personalizadas para documentos XHTML.
• Se a única causa para invalidar sua página HTML ou XHTML ter sido o uso da tag embed para vídeo, sua página será considerada válida desde que o vídeo seja acessível de acordo com os critérios de acessibilidade descritos nesta errata. Você pode usar um XHTML personalizado que contenha a tag embed (exemplo em inglês).
• Qualquer código HTML ou CSS inserido em uma página por script ou outro método similar deve produzir uma página válida quando renderizada. Isto significa que mesmo com uso de comentários condicionais, programação ou instruções quaisquer para servir códigos a determinados agentes, tais códigos devem produzir HTML e CSS válidos. A página servida ao usuário deve ser válida.
• Você pode usar qualquer versão das CSS.
• Caso o validador encontre um erro no seu documento e sabe-se que o validador está errado, sua página será considerada válida para aquele item específico.
• Você pode usar qualquer unidade de medida para definir tamanhos de textos, layouts e demais propósitos em geral. Seu layout não estará violando qualquer diretriz das WCAG 1.0 ou desta Errata.
  • Você deve testar seu site para maiores e menores tamanhos de fontes em relação a fonte projetada como padrão. Nenhuma barreira à acessibilidade deverá ser constatada nos testes. (Nós não definimos para quanto menor e maior devem ser realizados os testes)
  • Layouts líquidos são preferidos, contudo admitem-se os fixos e mistos desde que não haja comprometimento para a acessibilidade.
  • As diferenças entre unidades absolutas e relativas não têm nenhuma importância para esta errata.
    • A unidade px, segundo as especificações, foi e continua sendo uma medida relativa. Usar px para dimensionar textos é uma prática explicitamente permitida. Contudo, cada unidade de medida carrega consigo um significado semântico próprio que deve ser respeitado, assim pt é usado quase que exclusivamente para páginas impressas enquanto px faz mais sentido para dimensionamento de textos curtos que devam estar em um determinado tamanho (por exemplo: alertas legais e direitos autorais).
  • Se não existe um validador para a marcação ou linguagem de script na qual sua página foi escrita, as diretrizes de validação não se aplicam.

  Mantendo páginas em conformidade

  Apenas como lembrança, nem todas as páginas de um site precisam estar em conformidade com a WCAG+Samurai.

  • Constatado o fato de que uma página anteriormente em conformidade com as WCAG+Samurai tornou-se inválida por uma razão qualquer você deverá providenciar a correção em um prazo mais curto possível. Se for impossível corrigir a causa da não conformidade, deverá ser retirada da página a reivindicação de validade.
  • Páginas para as quais não é possível manter o status de conformidade – inclusive fóruns de discussões nos quais o público entra seus próprios textos ou mesmo marcações ou aplicações – não devem reivindicar conformidade com a WCAG+Samurai.

  Exigências de uso de HTML semântico

  Não só o código HTML deve ser válido na sua página como também seu HTML deve ser semântico

  • É obrigatório o uso de elementos apropriados de marcação para seus conteúdos, como cabeçalhos, listas e citações.
  • Em casos ambíguos use o elemento que você julgar mais conveniente ao seu conteúdo mesmo que outros autores discordem de você. Por exemplo: certos itens ambíguos podem ser marcados com listas de definição mesmo que outros autores usem listas não ordenada; use elementos de apresentação tais como b ou i nos casos em que a estrutura do conteúdo não exija o contrário (por exemplo: para destacar visualmente um conteúdo).
    • A discordância de outros autores em relação as suas escolhas não tem relevância alguma para esta errata.
    • Estas observações aplicam-se somente aos casos que possam suscitar dúvidas e não a marcação típica em uma página. Isto não é uma licença ou incentivo para que se marque tudo em uma página como parágrafo ou que se use negrito ou itálico para formatar cabeçalhos em lugar dos elementos corretamente semânticos para estes casos, ou que se use parágrafos para marcar itens de uma lista ou ainda usar indiscriminadamente b ou i.
  • Você não deve usar o elemento q; marque as citações inline com aspas ou imagens de traços.
  • Não use blockquote para endentar (recuar o texto).

  Diretriz 4.
  Indicar claramente qual o idioma utilizado

  Como lembrança convém ressaltar que o conceito de linguagem natural refere-se a idioma usado para comunicação entre humanos. Linguagens de programação para computadores, de qualquer natureza, mesmo aqueles que se assemelham a uma linguagem natural não se classificam como linguagens naturais.

  • Identifique o idioma principal do documento — de preferência na tag html que deve estar presente em documentos XHTML (por exemplo: html lang="código do idioma" ou html xml:lang="código do idioma"). Use os códigos para idioma publicados regularmente (não somente os preconizados nas ISO 639-1).
  • Se uma página é bi ou multi-língue não especifique um idioma principal já que nestes casos não existe o idioma "principal". Especifique o idioma usado em diferentes partes da página. Por exemplo: use os elementos div ou span para conter os textos no idioma diferente e os declare na marcação (por exemplo: <div lang=""> ou <span lang="">).
  • Uma página que seja um container para um vídeo de linguagem de sinais ou para um vídeo ou gravação de um idioma falado deve ser marcada com o código para aquele idioma. Uma página contendo um vídeo ou gravação em idioma diferente do idioma principal da página deve ser marcada de modo a identificar aquele idioma, se necessário use um elemento div ou span para conter o vídeo ou gravação.
  • Quando o autor sabe que um link remete o usuário a uma página escrita ou que contenha um vídeo ou gravação em outro idioma que não o da página de origem deve ser marcado o atributo hreflang com o código de idioma apropriado no link (por exemplo: hreflang="fr" para um link partindo de uma página escrita em português).
  • Não tente marcar mudança de idioma em atributos.
  • Ignore as referências das WCAG aos mecanismos de busca.

  Diretriz 5.
  Criar tabelas passíveis de transformação harmoniosa

  • Não use tabelas para layout.
  • O uso de summary, caption, e abreviações para cabeçalhos de tabelas está previsto Diretriz 3. Use estes atributos somente se seus conteúdos dele necessitarem. Mais especificamente, não existe qualquer obrigatoriedade do uso do atributo summary para cada tabela.
    • Você pode usar qualquer método para descrever e explicar uma tabela inclusive summary, <caption>, cabeçalhos da tabela, cabeçalhos (<h1> até <h6>) e texto puro.

  Diretriz 6.
  Assegurar que as páginas dotadas de novas tecnologias sejam transformadas harmoniosamente

  • Não forneça apresentações ou páginas alternativas (Ponto de verificação 6.5). Construa a página principal acessível. Em particular o uso de JavaScript para cumprir esta diretriz deve ser feito de uma maneira que não crie barreiras à acessibilidade. Você não é obrigado a criar páginas que se comportem exatamente da mesma maneira com ou sem script e tampouco criar uma página com e outra sem script.
  • Uma página que use gerenciamento para direitos digitais ou protegidas para cópias não pode avocar compatibilidade com a WCAG+Samurai uma vez que a compatibilidade com tecnologias assistivas e futuras tecnologias não pode ser comprovada.

  Diretriz 7.
  Assegurar o controle do usuário sobre as alterações temporais do conteúdo

  • Não use efeitos visuais piscantes, intermitentes ou cintilantes. Esta exigência aplica-se também para propaganda de terceiros inseridas em sua página.
  • "Conteúdos que se movem", rolagens, movimentações em geral ou animações não devem ser disparadas automaticamente sem o controle do usuário, mesmo para propagandas na página. Ao usuário deve ser passado o controle destas movimentações (quer seja por escolha de preferência de visualização do site quer por outro método qualquer acessível a usuários com necessidades especiais).
    • O usuário deve ser capaz de parar e reiniciar conteúdos móveis. Não há exceções para esta diretriz.
    • O usuário deve ser capaz de alterar a velocidade de conteúdos móveis a não ser que a implementação de mecanismo para alterar a velocidade seja uma tarefa de difícil consecução (Se você tiver que escolher baseado nas limitações prefira implementar mecanismos para reduzir a velocidade dos conteúdos no lugar de aumentar.)
  • Quando o redirecionamento de um site não for possível (por exemplo: impossibilidade de se modificar o arquivo .htaccess ou equivalente) é permitido usar a tag meta com refresh igual a zero.
  • blink e marquee não devem ser usados mesmo em um documento escrito em XHTML personalizado.

  Diretriz 8.
  Assegurar acessibilidade às interfaces de usuário incorporadas à página

  [Não há errata para esta diretriz.]

  Diretriz 9.
  Projetar páginas considerando a independência de dispositivos

  • Não use mapas de imagem no lado do servidor.
  • Não crie uma tabulação personalizada com uso de tabindex. Não use tabindex.
  • Não crie atalhos de teclado personalizados usando accesskey. Não use accesskey.

  Diretriz 10.
  Utilizar soluções de transição

  • Não abra pop-ups ou janelas adicionais e nem altere a janela corrente sem antes informar ao usuário.
    • Use texto puro para passar esta informação ao usuário. Outras alternativas devem ser usadas somente quando texto puro for de difícil implementação.
    • O atributo title em um elemento hyperlink <a> cumpre esta finalidade somente para casos de links apontando para páginas muito antigas e difíceis de serem adaptadas. Em casos de páginas novas ou em outras circunstâncias este atributo não é indicado e nem suficiente para cumprir esta diretriz.
  • Não forneça textos lineares como alternativa. Use a semântica corretamente; não use tabelas para layout.
  • Não coloque textos pré-definidos em caixas e áreas de entrada de textos, mesmo que sejam removidos por script quando receberem o foco, a menos que:
    • o texto seja incluído após o processamento da entrada do usuário (por exemplo: sugerir um novo ID caso o usuário tenha escolhido um já em uso).
    • a semântica do documento justifique a inclusão dos textos pré-definidos (por exemplo: ofertas de produtos válidas somente para usuários residentes em um determinado país podem ter o campo correspondente previamente preenchido com o nome do país).
    • os caracteres tenham sido entrados previamente pelo usuário (por exemplo: refinamento de uma busca prévia).
• Não use caracteres para separar links adjacentes (separados ou não por espaços) a menos que a semântica do documento justifique a inclusão dos caracteres.

Diretriz 11.
Utilizar tecnologias e diretrizes do W3C

• Use XHTML ou HTML para documentos contendo basicamente textos e/ou gráficos. Não é requerido usar a última versão do HTML ou XHTML. Variações do HTML desenvolvidas fora do W3C são permitidas desde que adequadamente definidas. Documentos XHTML personalizados são permitidos.
• Use CSS como forma prioritária de controle dos documentos HTML e XHTML.
• Flash, JavaScript e outras tecnologias interativas são permitidas contudo em todos os casos devem seguir as recomendações de acessibilidade correntes.
• Funcionalidades em desuso, incluindo elementos e atributos podem ser usados desde que não exista uma alternativa válida.
• Use PDF somente para determinados tipos de documentos. Todos os PDFs devem ser "etiquetados", usando a semântica apropriada ao documento.
• Não crie páginas alternativas. Projete páginas acessíveis.

Diretriz 12.
Fornecer contexto e orientações para ajudar os usuários a compreenderem páginas ou elementos complexos

• Não use frames. (Você pode usar iframes)
• Você não é obrigado a fornecer um mapa do site ou tabela de conteúdos a menos que o site não possa ser entendido ou navegado sem elas.
• Não forneça informações identificadoras no início de cabeçalhos, parágrafos, listas etc. a menos que seja muito difícil entender o documento sem aquela informação. (Nós não definimos o que seja "muito difícil".)
• Não use arte ASCII.
• É válido esconder informações estruturais (por exemplo: elementos cabeçalho posicionados fora da tela) quando a semântica do documento assim o permita.