Barra horizontal superior.
Coluna vertical direita.
A Acesso Digital criou uma lista de discussão para tratar de acessibilidade
na web. Quer participar? É só se inscrever.Esquerda - Conteúdo.
National Disability Authority - NDA
A prioridade 2 remove barreiras significativas para um ou mais grupos de usuários.
Lista de itens da prioridade 2.
(WAI Checkpoint 2.2).Texto WAI completo: "Certifique-se de que as combinações de cores de primeiro plano e de fundo forneçam contraste suficiente ao serem vistas por alguém que tenha deficiência de visão de cor ou vistas em tela em preto e branco. [Prioridade 2 para imagens, Prioridade 3 para texto].".
A diferença de contraste entre as cores de primeiro plano e de fundo usadas em qualquer imagem devem ser suficientes para que os usuários percebam corretamente a imagem, inclusive os usuários que tiverem deficiências de visão cromática, ou que usem uma tela em preto e branco.
Nem todos distinguem com facilidade combinações de cores e tons. Alguns usuários acham difícil ler conteúdo, reconhecer objetos ou selecionar itens de uma lista quando o item e o fundo tiverem tons similares, mesmo se as cores forem diferentes. Isto afeta particularmente os usuários mais velhos e os que têm alguma forma de cegueira cromática.
Os usuários também podem ter dificuldade para distinguir cores se usarem uma tela de má qualidade ou monocromática.
A cor tem três atributos que determinam como as pessoas as percebem - matiz, clareza e saturação. A matiz é a cor básica percebida, essencialmente o nome da cor - o cachecol é "vermelho". A clareza é a qualidade tonal - o cachecol poderia ser descrito "vermelho escuro". A saturação é a quantidade de cor - o cachecol é "muito vermelho". As cores ficam menos saturadas, movendo-se para o preto ou o branco.
Os esquemas de cores que obtêm diferenciação clara dos três atributos proporcionam o melhor contraste. A percepção que as pessoas têm do contraste das cores é ligada à sua capacidade de percepção de cada um ou de todos os três atributos, e isto varia enormemente. Nunca se deve considerar que quando se percebe claramente uma combinação de cores como bem contrastada, todos a perceberão assim.
.
(WAI Checkpoint 7.2).Texto WAI completo: "Até que os agentes de usuário permitam que os usuários controlem a intermitência luminosa, evite que o conteúdo pisque (ou seja, mude a apresentação com uma velocidade regular, tal como ligar e desligar)."
Os agentes de usuário são softwares usados para ter acesso a conteúdo na Internet. Eles incluem browsers gráficos, browsers somente de texto, browsers de voz, telefones móveis, reprodutores de multimídia, plug-ins e tecnologias assistivas tais como leitores de tela, ampliadores de tela e software de reconhecimento de voz.
É possível fazer o conteúdo piscar ou brilhar pela inserção de comandos para fazê-lo na página web. Isto se faz, geralmente, para criar um novo efeito, mas atualmente deve ser evitado, visto que nem todos os agentes de usuário permitem que este controle a velocidade da intermitência ou a desligue.
O movimento desordenado (flickering) pode induzir dano epilético nos usuários, se ocorrer regularmente a uma determinada velocidade.
Também é difícil ler conteúdo que esteja aparecendo e desaparecendo, ou ler conteúdo quando alguma outra coisa na página estiver apresentando luz intensa. A intermitência causa particular desvio de atenção em usuários que tenham capacidade limitada de leitura ou dificuldade de concentração, devido a ruído, stress, ou problema de aprendizado.
Não existem métodos de teste recomendados específicos para esta diretriz.
(WAI Checkpoint 7.3).Texto WAI completo: "Evite páginas contendo movimento, até que os agentes do usuário possibilitem a imobilização do conteúdo".
Os agentes de usuário são softwares usados para ter acesso a conteúdo na Internet. Eles incluem browsers gráficos, browsers somente de texto, browsers de voz, telefones móveis, reprodutores de multimídia, plug-ins e tecnologias assistivas tais como leitores de tela, ampliadores de tela e software de reconhecimento de voz.
É possível fazer o conteúdo ficar em movimento pela inserção de comandos para fazê-lo na página web. Isto se faz, geralmente, para criar um novo efeito, mas atualmente deve ser evitado, visto que nem todos os agentes do usuário permitem que este controle a velocidade do movimento ou o desligue.
Conteúdo que se movimenta continuamente distrai e aborrece a maioria dos usuários. Usuários que lêem visualmente muitas vezes ocultam animações ou texto móvel da tela cobrindo-os com as mãos, um pedaço de papel ou rolando a página para que o elemento não seja visualizado.
Links apresentados na forma de lista de rolagem contínua exige que os usuários leiam a lista e decidam seguir um dos links antes que este desapareça. Isso é maçante porque muitas pessoas preferem ler a lista inteira antes de tomar uma decisão. Clicar em links móveis pode ser difícil para usuários com habilidades limitadas.
Usuários de leitores de telas acham complicado ou impossível usar conteúdo móvel porque os leitores de telas não funcionam bem com conteúdo que muda continuamente na janela do navegador.
Usuários com dificuldade de leitura ou concentração consideram difícil compreender o conteúdo móvel, e usuários com deficiência visual acham muito complicado focalizar este tipo de conteúdo.
Não há técnicas específicas recomendadas para essa diretriz.
Não há métodos de teste específicos recomendados para essa diretriz.
(WAI Checkpoint 6.5).Texto completo da WAI: "Certifique-se de que o conteúdo dinâmico possa ser acessado ou ofereça uma apresentação ou página alternativa."
Conteúdo dinâmico é o conjunto de informações da página que sofre atualização em tempo real. Por exemplo, as últimas notícias carregadas "ao vivo" de um banco de dados dinâmico em tempo real. Vídeo, áudio e conteúdo apresentados por meio de scripts e applets também são dinâmicos. Um exemplo de conteúdo dinâmico apresentado por meio de script ou applet é a apresentação de manchetes de notícias na forma de letreiro atualizado continuamente. Frames (quadros) também são uma forma de conteúdo dinâmico, já que podem ser recarregados sem transição ou atualização da página.
Se a página da Web contiver informações dinâmicas, o conteúdo dinâmico deverá ser oferecido de forma que possa ser acessado. Se isso não for feito, os usuários precisarão ter uma forma de navegar para outra página onde as mesmas informações são apresentadas em formato acessível.
O conteúdo dinâmico pode ser inacessível por várias razões. Alguns tipos de conteúdo dinâmico, como áudio ou vídeo, não são aceitos em navegadores mais antigos ou nos que só reconhecem texto. Frames também não são universalmente suportados por navegadores e outros agentes de usuários. Leitores de tela podem lutar contra conteúdo dinâmico de atualização contínua, como letreiros de notícias. Eles também podem não conseguir reagir às atualizações de frames na forma como reagiriam a uma transição ou atualização de página, o que pode causar problemas. Usuários com conexões lentas podem desativar recursos do navegador, necessários ao processamento e à exibição do conteúdo dinâmico, a fim de agilizar os tempos de download.
.Teste navegadores e agentes de usuários diferentes. Realizar testes com a maior variedade possível de navegadores e agentes de usuários, como leitores de tela, dispositivos de Braille etc. mostrará se é necessária uma apresentação alternativa. Se você fornecer versões alternativas de conteúdo, teste-as para assegurar sua acessibilidade. Se você não tem acesso direto a essa tecnologia, peça que alguém com experiência em avaliação de sites teste a acessibilidade com os agentes de usuários.
(WAI Checkpoint 3.3).Texto completo da WAI: "Use folhas de estilo para controlar o layout e a apresentação."
As folhas de estilo são usadas para definir aspectos de apresentação de uma página da web, como fontes, tamanhos e cores usados no texto, nos cabeçalhos e nos hiperlinks, bem como o posicionamento de elementos na página. Use-as o mais freqüentemente possível ao invés de propriedades de elementos de codificação no HTML.
O uso de folhas de estilo separa a estrutura e a apresentação, o que gera muitos benefícios, como melhor acessibilidade, manuseabilidade e portabilidade.
A estrutura se refere à organização lógica do conteúdo. Por exemplo, um formulário on-line para inscrição em um programa de hipoteca pode ser dividido em seções lógicas, como informações pessoais, empresa onde trabalha, detalhes do imóvel etc. Essa estrutura lógica será a mesma para todos os usuários, mas pode ser apresentada de diferentes maneiras, dependendo das necessidades e das preferências de cada usuário. Por exemplo, em uma apresentação gráfica detalhada com várias colunas usando tons sutis de cores, uma única coluna com texto grande em cores bem contrastantes ou com voz sintetizada.
A acessibilidade é melhorada porque os usuários podem escolher entre os diferentes estilos e até mesmo substituir as folhas de estilo definidas por suas próprias folhas. Estas conteriam esquemas com fontes grandes ou cores diferentes para melhorar a legibilidade. Separar a apresentação e a estrutura permite a independência dos dispositivos, facilitando o ajuste da apresentação a diferentes navegadores ou agentes de usuários. Usar folhas de estilo também reduz o tamanho do arquivo de páginas da web e acelera o tempo de download, o que é muito útil para o usuário que trabalha com uma conexão lenta.
As folhas de estilo ajudam no gerenciamento e na manutenção ao permitir alterações rápidas na aparência visual de um site. Com as folhas de estilo, a necessidade de alterar a apresentação do site pode ser atendida imediatamente, no nível da folha de estilo, sem ser preciso acessar cada página no nível de elemento.
para obter informações técnicas e
exemplos detalhados
de recursos de acessibilidade CSS.
e obter informações sobre
layout
CSS,posicionamento, disposição em camadas e alinhamento
,
formatação e posicionamento de texto CSS.
.
Faça um teste com o
validador CSS do W3C.
Valide seu CSS.
(WAI Checkpoint 3.4).Texto completo da WAI: "Use unidades relativas em lugar de absolutas nos valores de atributos de linguagem de marcação e nos valores de propriedades da folha de estilo."
As linguagens de marcação são linguagens como a HTML, usadas para criar páginas da web. A marcação HTML para elementos como texto, cabeçalhos e hiperlinks pode especificar atributos de apresentação como fontes, tamanhos e cores a serem usadas. Folhas de estilo também podem ser usadas para especificar os atributos da apresentação de elementos.
Esses atributos podem ser especificados em unidades absolutas ou relativas. As unidades absolutas são valores fixos, como o tamanho de fonte de 12 pontos ou uma coluna de 800 pixels de largura. As unidades relativas definem o tamanho em unidades de medida como EMs (unidade de largura relativa a um tamanho de fonte) ou porcentagens da largura total da janela do navegador.
Controlados por marcação ou folhas de estilo, os tamanhos devem ser definidos em unidades relativas, e não em unidades absolutas.
Use texto HTML e certifique-se de ele possa ser redimensionado. Os navegadores permitem que os usuários redimensionem o texto especificado em valores relativos. Neste exemplo, o usuário não pode aumentar o tamanho da navegação principal porque são usadas imagens tabuladas, e não texto HTML. A subnavegação pode ser dimensionada porque é usado texto HTML redimensionável.
Projetar com tamanhos fixos, como um tamanho de janela de navegador "ideal" pode parecer uma boa idéia no papel, já que você pode pensar que está controlando a apresentação da interface, mas, na realidade, isso é um esforço desperdiçado. Se uma interface for projetada tendo-se em mente um tamanho de janela de navegador "fixa", na melhor das hipóteses ela não funcionará bem, ou será completamente inútil se o usuário não trabalhar com aquele tamanho de janela, já que os principais recursos desaparecerão pela borda da tela.
Isso afeta usuários com monitores menores, ou usuários que gostam de aumentar o tamanho do texto. Se a largura da página for projetada para ser bem exibida em um tamanho fixo de janela de navegador e o usuário aumentar o texto, ele pode ficar muito grande para ser exibido na tela.
Se o tamanho da fonte for fixo, o usuário não poderá dimensioná-lo para facilitar a leitura. Ele pode querer fazer isso se estiver visualizando conteúdo em uma tela pequena, como em um dispositivo móvel ou laptop, ou se for portador de alguma deficiência visual.
Além disso, você incorrerá em custos adicionais sempre que decidir disponibilizar seu serviço em outro dispositivo ou plataforma de acesso, devido ao esforço exigido para "encaixar" o projeto de interface no novo tamanho de janela.
O dimensionamento relativo significa não somente que o site da web pode ser usado em uma variedade maior de dispositivos de acesso com esforço de design mínimo, mas também que você oferecerá aos usuários a flexibilidade de dimensionar elementos importantes com o tamanho que melhor atender suas necessidades.
(WAI Checkpoint 3.5).Texto completo da WAI: "Use elementos de cabeçalho para demonstrar a estrutura do documento e use-os de acordo com as especificações."
Cabeçalhos são coisas como títulos, cabeçalhos de seções e de linhas e colunas em tabelas, usados para comunicar a estrutura das informações em páginas da web. Cabeçalhos só devem ser usados para demonstrar a estrutura das informações, de acordo com as regras de uso estabelecidas na definição da linguagem de marcação. Não use cabeçalhos para criar efeitos de apresentação como texto de tamanho diferente.
Muitas pessoas navegam ou percorrem documentos lendo os cabeçalhos para sentir sua estrutura e obter uma visão geral de seu conteúdo e escopo.
O HTML permite que você especifique uma hierarquia de níveis de cabeçalho usando diferentes etiquetas (tags) de cabeçalho: H1, H2, H3 etc. A marca não apenas define a ordem hierárquica de um cabeçalho, ela também afeta a apresentação visual. Assim, um cabeçalho H1 parece maior e mais forte (escuro) que um cabeçalho H2. Usar etiquetas de cabeçalho para aumentar ou reforçar texto pode confundir os usuários, já que o conteúdo assumirá a aparência de um cabeçalho. Isso dificulta a compreensão da estrutura do documento ou página.
Além disso, alguns leitores de tela lêem o conteúdo indicado como cabeçalho em um tom de voz diferente do usado para conteúdo da página, fornecendo ao usuário pistas importantes sobre a estrutura do documento. Usar incorretamente os atributos de cabeçalho confunde os usuários de leitores de tela.
Ordene os elementos de cabeçalho corretamente.
Os elementos do cabeçalho sempre devem seguir uma ordem hierárquica lógica.
Consulte as técnicas recomendadas da WAI para
obter informações
sobre o uso de elementos de cabeçalho
.
Não há métodos de teste específicos recomendados para essa diretriz.
(WAI Checkpoint 12.3).Texto completo da WAI: "Divida grandes blocos de informação em grupos manuseáveis quando natural e apropriado."
Sempre que possível, divida os elementos da página em grupos lógicos de fácil compreensão, como seções e subseções.
Geralmente, não é confortável ler grandes extensões de texto na tela. As pessoas tendem a filtrar o conteúdo examinando títulos, subtítulos, listas etc. Isso fica mais fácil se o conteúdo for dividido em grupos facilmente digeríveis.
É mais fácil compreender e navegar por elementos mais complexos, como formulários ou outros recursos interativos, se eles forem divididos em seções lógicas. Por exemplo, um formulário on-line pode ser dividido em seções lógicas, como informações pessoais, informações comerciais etc.
Dividir o conteúdo em pequenos grupos é vantajoso para todos, inclusive para usuários apressados que precisam encontrar informações rapidamente, como atendentes de centrais telefônicas, usuários com dificuldade de leitura, falantes não nativos e usuários de leitores de tela.
É muito importante agrupar elementos de formulário, como campos e listas de seleção usando HTML correto, pois assim os usuários de leitores de tela receberão informações contextuais importantes, que os ajudarão a navegar pelo documento.
Dividir formulários complexos em grupos usando HTML correto também facilita a recuperação de erros para usuários de leitores de telas, já que simplifica a tarefa de navegar de volta ao formulário e corrigir as informações erradas.
É importante que os grupos de informações sejam divididos logicamente. Grupos de elementos criados aleatoriamente confundirão os usuários.
nas técnicas recomendadas da WAI para saber como agrupar
itens de conteúdo.
corretamente.Não há métodos de teste específicos recomendados para essa diretriz.
(WAI Checkpoint 5.3).Texto completo da WAI: "Em layouts, só use tabelas se estas fizerem sentido quando linearizadas. Caso contrário (se a tabela não fizer sentido) ofereça uma alternativa equivalente (uma versão linearizada, por exemplo)."
Uma tabela é um elemento HTML que pode ser usado para apresentar informações no formato tabular ou controlar a apresentação visual da página da web. Se uma tabela usada para controlar a apresentação visual de uma página da web for linearizada, o conteúdo de suas células de dados será exibido em uma longa coluna. A ordem de exibição do conteúdo na versão linearizada é determinada pela ordem na qual as células da tabela são definidas no HTML subjacente.
O ideal é que o conteúdo da tabela faça sentido quando esta é linearizada. Se isso não ocorrer, ofereça ao usuário a opção de ver o conteúdo da tabela em outro formato (isto é, parágrafos ou blocos de texto que não são exibidos em tabela).
As tabelas são desenvolvidas originalmente como um recurso HTML, e especificamente para a apresentação de dados tabulares. Seu propósito nunca é controlar a apresentação. No entanto, as células de dados de uma tabela podem conter vários tipos diferentes de informações, incluindo texto, números ou imagens. Muitas vezes, os desenvolvedores usam tabelas para controlar o layout da página, por exemplo, para apresentar texto em um layout do tipo coluna de jornal, exibir elementos de navegação à esquerda da página com conteúdo no meio ou posicionar imagens dentro de blocos de texto.
Isso cria um problema para os usuários de leitores de tela ou de tecnologias mais antigas. Leitores de tela mais velhos e navegadores que só reconhecem texto não conseguem processar informações dispostas em colunas. Se duas colunas de texto forem posicionadas lado a lado, uma pessoa com visão satisfatória lerá a coluna da esquerda de cima para baixo antes de passar para a próxima coluna. Leitores de tela mais antigos e navegadores de texto lerão da esquerda para a direita, começando pela primeira frase da coluna da esquerda e seguindo para a primeira frase da coluna da direita. Prosseguirão assim até o fim da página. Resultado final: fragmentos de frases combinados em texto ininteligível.
Para evitar esse problema, alguns usuários linearizam tabelas de páginas da web usando controles de seus leitores de tela ou navegadores da web ou por meio de navegadores que reconhecem apenas texto, que conseguem linearizar tabelas.
A ordem na qual os elementos são exibidos na versão linearizada é determinada pela ordem de definição das células da tabela no HTML subjacente da página da web. Essa ordem pode ser diferente daquela na qual as tabelas são apresentadas visualmente.
Tome como exemplo a leitura de um jornal, no qual os títulos dos artigos de uma página são exibidos na parte superior esquerda desta. Os artigos são exibidos um após o outro em uma longa coluna e não há nada para associar os títulos aos seus artigos correspondentes. Também não é fácil saber onde um artigo termina e outro começa. É assim a leitura de uma tabela que não faz sentido quando linearizada.
.
(WAI Checkpoint 5.4).Texto completo da WAI: "Ao fazer o layout com base em uma tabela, não use etiquetas estruturais para fins de formatação visual."
Uma tabela é um elemento HTML que pode ser usado para apresentar informações no formato tabular ou controlar a apresentação visual da página da web. Não defina informações contidas em células de tabela com etiquetas estruturais para simplesmente obter um efeito visual, se a tabela for usada para controlar o layout da página.
Definir o conteúdo de texto de uma célula de tabela como cabeçalho de coluna, para que seja exibido como texto em negrito, é um exemplo de uso inadequado de marcações estruturais para obter um efeito visual. Por exemplo, em HTML, não utilizar a etiqueta TH para fazer com que o conteúdo de uma célula (que não seja de cabeçalho de tabela) apareça centrado e a negrito.
Pessoas que conseguem examinar visualmente uma página desenvolvida com tabelas podem notar a estrutura das informações identificando e comparando visualmente os elementos estruturais (cabeçalhos de linhas e colunas, títulos e subtítulos). No entanto, pessoas que usam navegadores que reconhecem apenas texto, ou que não conseguem enxergar a página, dependem de uma descrição precisa dos elementos estruturais para compreender a estrutura da página.
Se os itens de conteúdo forem identificados incorretamente como elementos estruturais no HTML subjacente, a estrutura da página não fará sentido quando for apresentada por um navegador de texto ou um leitor de tela.
.
(WAI Checkpoint 12.2).Texto WAI completo: "Descreva o propósito de cada frame e como eles se relacionam, se isso não for óbvio a partir dos títulos dos frames".
Os frames permitem que o designer quebre a página web em diferentes partes, cada uma contendo um arquivo HTML diferente. Os frames normalmente são usados para que a página contenha duas seções: uma contendo informações que não se alteram quando o usuário navega pelo site e outra que apresenta informações mais dinâmicas. Um exemplo típico é quando a navegação principal do site se apresenta num frame do lado esquerdo da página, enquanto o conteúdo é apresentado em outro frame à direita.
Neste caso, os links de navegação são mantidos num arquivo HTML à esquerda da página e o conteúdo fica em outro arquivo HTML, que é ativado conforme o link selecionado no frame da esquerda. Quando se clica num link do lado esquerdo, basicamente o que acontece é que uma nova página se abre do lado direito da janela do navegador.
Cada frame deve ter um título, atribuído através do atributo TITLE, mesmo que não exibido visualmente. Se os títulos dos frames usados para a formatação de uma página não explicarem claramente a organização estrutural, ou o relacionamento entre eles e a natureza de seus conteúdos, esta informação deve ser apresentada de alguma outra forma.
Usuários de navegadores antigos ou leitores de telas têm dificuldade para navegarem em páginas que contenham frames. Eles não conseguem ler cada frame individualmente, assim como não conseguem imaginar a estrutura da página.
Por exemplo, se um usuário de leitor de telas abrir uma página com frames, receberá uma lista dos frames que compõem a página. Se os frames não tiverem títulos, atribuídos através do atributo TITLE, o usuário receberá uma lista de nomes de arquivos que não terá sentido, ex.: -frame: a. A falta de informações úteis sobre os conteúdos do frame força o usuário a abrir cada frame individualmente, verificar seu conteúdo e descobrir como cada um deles se relaciona com os outros frames da página. É uma tarefa frustrante e demorada.
Por exemplo, pode-se dar o título "NAV" para um frame. Este título não é muito informativo. Se o título desse frame fosse title="links para a seção principal do site" isto seria mais compreensível.
Teste a página usando um navegador que não ofereça suporte para frames. Abra a página com um navegador como o Lynx, que não exibirá frames. Isto lhe mostrará como a página será apresentada em um navegador que não suporta frames. Se você vir uma lista de títulos de frames e o propósito e relacionamento entre eles não ficar claro, considere a necessidade de adicionar uma descrição.
(WAI Checkpoint 13.1).Texto completo da WAI: "Identificar claramente o destino de cada link."
Fornecer claramente informação sobre as conseqüências de seguir um link, incluindo seu destino e todos os efeitos associados.
As informações que devem ser dadas incluem o seguinte:
Os títulos dos links, quando objetivos e claros, são essenciais para que os usuários decidam-se se querem seguir um link, por compreenderem o destino ou função dos mesmos.
A clareza dos títulos dos links é particularmente importante para as pessoas que não são familiarizadas com computadores, com a WEB e seus serviços.
A clareza dos títulos dos links também são úteis para os usuários de leitores de tela, que navegam frequentemente de forma direta de link em link, como se tivessem apenas uma lista de links na página, antes de investirem na leitura completa de toda a página em detalhe. Essa varredura de links na página é para terem uma visão geral do conteúdo da página. Assim, os links são lidos fora do contexto completo e é importante fornecer os títulos dos links com clareza suficiente para não requererem que o usuário leia a informação circunvizinha. Por exemplo, não faça títulos dos links incompletos como "clique aqui" e "saiba mais", pois não fornecem informação do seu conteúdo quando lidos fora do contexto.
A informação sobre novos efeitos e funções, tais como a abertura de novas janelas de navegação, pode ser essencial aos usuários que são confundidos fàcilmente ou que não podem perceber a abertura da nova janela antecipadamente.
A informação sobre downloads é também essencial, de modo que o usuário possa calcular se tem recursos para o tempo e o espaço requeridos para o download e se o conteúdo deste é de um tipo acessível e que levaos melhores termos suas necessidades. É muito frustrante perceber que o download, depois de realizado, não é compatível com seu sistema ou software.
Não existem métodos específicos de teste recomendados para esta diretriz.
(WAI Checkpoint 13.2).Texto completo da WAI: "Fornecer metadata para adicionar informação semântica às páginas e sites."
Os Metadata são as informações que descrevem páginas, sites e seus conteúdos. Você deve fornecê-los para facilitar a compreensão do conteúdo.
Os metadata de boa qualidade melhoram a usabilidade e facilidades da busca, fornecendo keywords e descrições úteis e exatas do conteúdo e dos tipos de meios.
As descrições e os sumários dos conteúdos da página, indicados em resultados de busca, são extraídos frequentemente dos metadata que são introduzidos nas páginas. Os Metadata podem também fornecer as informações contextuais importantes para ajudar os usuários a compreenderem e navegarem pelo conteúdo.
Os exemplos dos metadata incluem descrições dos conteúdos e da organização estrutural de tabelas complexas ou de listas longas.
Sem metadata, a informação é mais difícil de ser compartilhada com os usuários de outros computadores através das facilidades de troca de dados. É mais complicado se recuperar informações satisfatoriamente se os esquemas padrão dos metadata não forem seguidos.
Verificar o HTML para ver se hás etiquetas META estão incluídas. Se os metadata forem incluídos na página, não será visível. Você tem que verificar o código do HTML para vê-lo. Para fazer isto, abra a página em seu navegador e selecione a opção "para ver a fonte ou código". Isto abrirá o código do HTML. Os metadados estarão sempre perto do topo do documento.
(WAI Checkpoint 13.3).Texto WAI completo: "Forneça informações sobre o layout geral do site (por exemplo: um mapa ou o índice do site)".
Forneça o histórico da estrutura do site que resuma seus conteúdos e sua organização.
O histórico da estrutura e do conteúdo do site facilita a navegação. Por exemplo, com o mapa ou o índice do site é mais fácil navegar nas seções fundamentais do que pesquisar nas páginas. Às vezes supõe-se que os usuários constroem "mapas mentais" das estruturas do site enquanto navegam pelas seções. Esse não é o caso. A maior parte das pessoas não quer perder tempo descobrindo como seu site está estruturado. Na melhor das hipóteses, lembrarão apenas de uma série de páginas que visitaram e do relacionamento entre essas páginas.
Com o índice ou o mapa do site, as pessoas deixam de ficar confusas ou desorientadas e passam a analisar os conteúdos, continuando a navegar.
Conter um mapa do site ou um índice no site. O mapa do site fornece o histórico de suas seções fundamentais e algumas indicações sobre o conteúdo, funcionalidade e acessibilidade existentes naquelas seções.
Não existem métodos de teste recomendados específicos para esta diretriz.
(WAI Checkpoint 13.4).Texto WAI completo: "Use os mecanismos de navegação de maneira consistente"
Os mecanismos de navegação indicam ao usuário onde podem chegar e sua atual posição dentro da estrutura do site. Exemplos: links, barras de navegação, números de página ou lista, ferramentas de pesquisa, anúncios, cabeçalhos e títulos de páginas. Os mecanismos de navegação devem ser apresentados de forma ordenada e uniforme em todo o site.
É importante que sejam apresentados dispositivos e estruturas de navegação consistentes a todos os usuários. Os mecanismos de navegação apresentados de maneira inconsistente desorientam rapidamente os usuários e induzem a erros, confusão e frustração.
A consistência torna o seu site mais previsível, permitindo que os usuários naveguem rapidamente até as informações desejadas. Além disso, ajuda-os a saltarem as partes da navegação ou conteúdos que não interessam, tornando mais eficiente a realização de tarefas ou a busca de informações.
Pode-se gerar consistência assegurando que as características dos mecanismos de navegação a seguir sejam mais ou menos uniformes em todo o site, ou em uma série de sites relacionados:
Os usuários que não estiverem familiarizados com o uso de computadores ou da web, ou que tenham dificuldade de aprendizagem ou estejam com pressa, todos estes têm benefícios quando os mecanismos de navegação são consistentes.
A manutenção é facilitada porque é mais fácil implementar mudanças e atualizações quando o site é construído em torno de uma estrutura consistente.
Não há técnicas específicas recomendadas para essa diretriz.
Ao abrir cada página:
(WAI Checkpoint 12.4).Texto WAI completo: "Associe as etiquetas de formulários explicitamente com seus controles.
Os exemplos de controle incluem campos de entrada de texto e caixas de verificação em formulários. Por exemplo, fazer etiquetagem dos controles em HTML através da etiqueta LABEL e o respectivo atributo "for".
"Etiquetagem" é dar nomes aos elementos de controle de formulários, como por exemplo: INPUT TEXT. "Nome Completo" pode ser uma etiquetagem feita pela etiqueta LABEL e seu atributo FOR, associado a um campo de entrada de texto. Nesse caso, o nome do campo poderia ser visualmente apresentado imediatamente acima ou à esquerda do controle. Chamamos de etiquetagem implícita o ato de associar a etiqueta com o controle de formulário, posicionando-os o mais próximo possível.
O relacionamento entre a etiquetagem e os elementos de controle pode ser definido como o HTML básico.
Uma boa prática é posicionar as etiquetas de forma a permitir que o relacionamento visual com os controles de formulário correspondentes seja óbvio.
No entanto, se o relacionamento entre as etiquetas e os controles de formulário não estiver explicitamente definido no HTML básico, a exatidão na apresentação do formulário por browsers mais antigos ou tecnologias assistivas pode ficar comprometida.
.
(WAI Checkpoint 10.2).Texto WAI completo: "Até que os agentes de usuário admitam associações explícitas entre marcações, e todos os controles de formulários, verifique se a marcação está corretamente posicionada".
Agente de usuário é um software que acessa conteúdos da Web. Podem ser browsers gráficos da área de trabalho, browsers de texto e de voz, telefones móveis, reprodutores multimídia, plug-ins e algumas tecnologias assistivas de software usadas em combinação com browsers do tipo leitores de tela, ampliadores de tela, ou software de reconhecimento de voz.
Os exemplos de elementos de controle de formulário incluem campos de entrada de texto e caixas de verificação.
As etiquetas são associadas com elementos de formulário quando são colocadas próximas uma da outra.
"Etiquetagem" é dar nomes aos elementos de controle de formulários, como por exemplo: INPUT TEXT. "Nome Completo" pode ser uma etiquetagem feita pela etiqueta LABEL e seu atributo FOR, associado a um campo de entrada de texto. Nesse caso, o nome do campo poderia ser visualmente apresentado imediatamente acima ou à esquerda do controle. Chamamos de etiquetagem implícita o ato de associar a etiqueta com o controle de formulário, posicionando-os o mais próximo possível.
Uma boa prática é posicionar as etiquetas de forma a permitir que o relacionamento visual com os controles de formulário correspondentes seja óbvio. No entanto, algumas tecnologias assistivas, como os leitores de tela, só podem ler da esquerda para a direita e, a menos que as etiquetas de formulários sejam posicionadas com cuidado, não conseguirão ler o formulário de forma a possibilitar sua compreensão.
(WAI Checkpoint 9.2).Texto WAI completo: "Assegure que qualquer elemento que tenha sua própria interface possa ser operado de maneira independente do dispositivo".
Exemplos de elementos que têm suas próprias interfaces incluem recursos interativos ou aplicativos, baseados na web, como calculadoras de impostos ou jogos escritos em Java ou Macromedia Flash. Esses elementos ficam embutidos em uma página da web e têm seus próprios controles, além de mecanismos de entrada e saída.
Verifique se é possível interagir com os controles, forneça as entradas e observe as saídas desses elementos usando a maior série possível de dispositivos de entrada (inclusive mouse, teclado, microfone, dispositivos em Braille, leitores de tela e outros dispositivos), ou dispositivos de saída (inclusive monitores de tela, alto-falantes, fones de ouvido ou dispositivos em Braille).
As interfaces que não oferecem flexibilidade quanto ao tipo de dispositivo usado para interagir são inerentemente inacessíveis. Os usuários de laptops preferem trabalhar sem o mouse. Nesse caso, se os recursos da página exigirem um recurso, tal como um "arraste e solte" como único meio de interagir, sua utilização não será possível. Da mesma forma, sites acessáveis por meio de terminais em quiosques ou públicos, apenas com interface de "toque na tela", não podem ser usados.
Desenvolvendo-se interfaces independentes dos dispositivos pode-se produzir uma usabilidade do site em uma gama maior de dispositivos de computação, inclusive aparelhos portáteis, PCs e sistemas de resposta interativa por voz [Interactive Voice Response systems (IVRs)].
Os usuários de leitores de tela confiam plenamente na entrada de teclado e na saída de áudio para interagir com websites. Se não houver suporte para saída de áudio ou para o teclado como um dispositivo de entrada, a utilização do site não será possível. Outros usuários podem usar saída de voz para operações sem uso das mãos em escritórios muito ativos ou caso haja limitação de destreza.
da
Sun Microsystems.
O Java tem recursos de acessibilidade inerentes. Verifique se está preparado para usá-los independentemente
do dispositivo
de entrada.
(WAI Checkpoint 9.3).Texto WAI completo: "Para os scripts, especifique os manipuladores lógicos de eventos em vez dos manipuladores de eventos dependentes do dispositivo".
Scripts são controles de funcionalidade escritas em outras linguagens diferentes do HTML, para possibilitar comportamento dinâmico ou interativo a partir de simples efeitos visuais até mini-aplicativos.
Alguns exemplos têm funcionalidade avançada como menus instantâneos codificados em DHTML, rotinas de validação de entradas de formulários escritas em JavaScript e aplicativos interativos como calculadores de impostos ou jogos escritos em Java ou Macromedia Flash.
O manipulador de eventos é um script que é chamado quando um determinado evento ocorre (por exemplo: quando o mouse se movimenta, o teclado é pressionado, o documento é carregado etc.).
Verifique se os manipuladores de eventos, que ativam recursos interativos. acionados por meio de scripts e applets, podem ser ativados e controlados usando-se a mais ampla variedade de dispositivos de entrada, inclusive mouse, teclado, microfone, dispositivos em Braille, leitores de tela ou outros dispositivos indicadores.
Alguns manipuladores de eventos produzem efeitos puramente visuais, enquanto outros são usados para completar tarefas críticas, tais como submissão de conteúdos de formulários, conclusão de cálculos ou envio de mensagens. Os manipuladores de eventos fundamentais para completar tarefas devem sempre ser independentes do dispositivo de entrada.
As interfaces que não oferecem flexibilidade no tipo de dispositivo em que o usuário deve confiar para dar entrada em informações ou receber saídas, são inerentemente inacessíveis. Os usuários de laptops talvez prefiram trabalhar sem o mouse e com o teclado. Nesse caso, se os recursos do site exigirem um recurso do tipo "arraste e solte" como único meio de interagir, sua utilização não será possível. Da mesma forma, sites acessáveis por meio de terminais em quiosques ou públicos, apenas com interface de toque na tela, não podem ser usados se não for possível ver a tela.
Esse item não está restrito somente à entrada de informações. É importante também oferecer saídas independentes do dispositivo. Os usuários de leitores de tela podem abrir o menu DHTML, mas se não receberem feedback sobre os nomes dos links que estão selecionando, o menu não terá utilidade. Da mesma forma, possibilitam abrir uma calculadora de impostos em Javascript e inserir dados, mas se a saída não for compatível com um sintetizador de voz, não é independente do dispositivo.
Quando se desenvolve interfaces que possibilitam entradas com independência do dispositivo, produz-se a usabilidade do site em uma gama maior de dispositivos de computação, inclusive aparelhos portáteis, PCs e sistemas de resposta interativa por voz [Interactive Voice Response systems (IVRs)].
Os usuários de leitores de tela confiam plenamente no teclado para interagir com os websites. Se não houver suporte para o teclado como dispositivo de entrada, a utilização do site não será possível. Outros usuários podem usar a entrada de voz para operações sem uso das mãos em escritórios muito ativos ou em caso de limitação de destreza.
da
Sun Microsystems.
O Java tem recursos de acessibilidade inerentes. Verifique se está preparado para usá-los independentemente
do dispositivo
de entrada.
para obter maiores informações sobre scripts.
O Centro IBM de Acessibilidade oferece maiores informações sobre scripts e
acessibilidade.
(WAI Checkpoint 6.4).Texto WAI completo: "Para scripts e applets, verifique se os manipuladores de eventos são independentes do dispositivo de entrada".
Scripts e applets são tipos de objetos programáveis. Trata-se de peças de funcionalidade escritas em outras linguagens diferentes do HTML, para possibilitar um comportamento dinâmico ou interativo a partir de simples efeitos visuais até mini-aplicativos.
Alguns exemplos têm funcionalidade avançada como menus instantâneos codificados em DHTML, rotinas de validação de entradas de formulários escritas em JavaScript e aplicativos interativos, tais como calculadores de impostos ou jogos escritos em Java ou Macromedia Flash.
O manipulador de eventos é um script que é chamado quando um determinado evento ocorre (por exemplo: quando o mouse se movimenta, o teclado é pressionado, o documento é carregado etc.). É preciso verificar se os manipuladores de eventos, que ativam recursos interativos liberados por meio de scripts e applets, podem ser ativados e controlados usando-se a mais ampla série de dispositivos de entrada, inclusive mouse, teclado, microfone, dispositivos em Braille, leitoras de cabeçote e outros dispositivos de indicação.
Alguns manipuladores de eventos produzem efeitos puramente visuais, enquanto outros são usados para completar tarefas críticas como submissão de conteúdos de formulários, conclusão de cálculos ou envio de mensagens. Os manipuladores de eventos fundamentais para completar tarefas devem sempre ser independentes do dispositivo de entrada.
As interfaces que não oferecem flexibilidade no tipo de dispositivo em que o usuário deve confiar para dar entrada em informações ou receber saídas, são inerentemente inacessíveis. Os usuários de laptops talvez prefiram trabalhar sem o mouse e com o teclado. Nesse caso, se os recursos do site exigirem um recurso do tipo "arraste e solte" como único meio de interagir, sua utilização não será possível. Da mesma forma, sites acessáveis por meio de terminais em quiosques ou públicos, apenas com interface de toque na tela, não podem ser usados se não for possível ver a tela.
Quando se desenvolve interfaces que possibilitam entradas com independência do dispositivo, produz-se a usabilidade do site em uma gama maior de dispositivos de computação, inclusive aparelhos portáteis, PCs e sistemas de resposta interativa por voz [Interactive Voice Response systems (IVRs)].
Os usuários de leitores de tela confiam plenamente no teclado para interagir com os websites. Se não houver suporte para o teclado como dispositivo de entrada, a utilização do site não será possível. Outros usuários podem usar a entrada de voz para operações sem uso das mãos em escritórios muito ativos ou em caso de limitação de destreza.
da
Sun Microsystems.
O Java tem recursos de acessibilidade inerentes. Verifique se está preparado para usá-los independentemente
do dispositivo
de entrada.Desconecte o mouse e tente navegar com o teclado. Supondo-se que saiba como interagir com um website usando apenas o teclado, este teste simples vai mostrar rapidamente se é possível navegar ou interagir com o site usando um dispositivo de entrada diferente do mouse. Verifique, principalmente desta forma, recursos interativos como formulários, menus suspensos, menus instantâneos etc.
(WAI Checkpoint 8.1).Texto completo da WAI: "Tornar os elementos de programa tais como scripts e applets diretamente acessíveis ou compatíveis com tecnologias assistivas [Prioridade 1 se a funcionalidade for importante e não estiver apresentada em outro local, do contrário Prioridade 2.]".
Scripts e applets são tipos de objetos programáveis. São partes da funcionalidade escritos em linguagem diferente da HTML, a fim de fornecer um comportamento interativo ou dinâmico que vai de simples efeitos visuais a mini-aplicativos. Alguns exemplos são de funcionalidade aumentada como menus pop-up codificados em DHTML, formulários de entrada de rotinas de validação escritos em JavaScript e aplicativos interativos tais como calculadoras de tributos ou jogos escritos em Java ou Macromedia Flash. Elementos programáveis deveriam ou ser inerentemente acessíveis ou incluir características que assegurassem que eles são usáveis com tecnologias de apoio.
Tecnologias de apoio permitem que os usuários forneçam dados de entrada e percebam as respostas onde estas não sejam possíveis usando tecnologias como o mouse, o teclado ou a tela do monitor. Por exemplo, usuários cegos possam usar um leitor de tela que é um programa que interpreta os conteúdos de texto da tela e os transfere ou para um sintetizador de voz ou para um display de Braile. Usuários com pouca visão podem usar um programa ampliador de tela para aumentar uma determinada parte da tela. Pessoas com deficiências motoras podem solicitar um teclado especial ou um dispositivo que aponte para a tela, controlado por um joystick ou por movimentos de cabeça.
Idealmente, elementos programáveis deveriam ser diretamente acessíveis para que um maior número de pessoas possam usá-los sem ter que recorrer a tecnologias de apoio. Nem sempre é possível, pois muitos navegadores ou sistemas operacionais não incluem perfis adequados de acessibilidade. Neste caso, perfis de acessibilidade que são fornecidos pelas tecnologias de programação e suportados pelas tecnologias de apoio deveriam ser incluídas nos elementos de programação.
A acessibilidade direta é desejável em situações onde o usuário quer acessar um serviço ou informação disponível em páginas em HTML, mas não pode utilizar tais dispositivos, ou tecnologias de apoio, porque estas não são práticas ou viáveis. Por exemplo, usar um leitor de tela para interagir com um quiosque em um espaço público. Isso seria impossível porque leitores de tela são tipicamente instalados no computador pessoal do usuário e configurado para satisfazer suas necessidades.
O Java tem características inerentes de acessibilidade. Certifique-se de que providenciou
independência dos dispositivos de entrada de dados ao usá-los. Veja as diretrizes da Sun sobre acessibilidade
que vem no
Java, com os detalhes sobre o seu uso.
(WAI Checkpoint 3.1).Texto completo da WAI: "Quando houver uma linguagem markup apropriada, utilize-a ao invés de imagens para enviar a informação."
Mark-up refere-se a comandos ou símbolos (etiquetas) usados para descrever a estrutura lógica de um documento, ou para indicar como este pareceria quando impresso ou na tela. Por exemplo, estilos de cabeçalho HTML (h1, h2, etc.) são usados para delimitar seções de cabeçalhos em uma página da internet. MathML pode ser usado para distinguir símbolos matemáticos e equações. É possível obter o mesmo efeito visual usando imagens ao invés de etiquetas, mas isso deveria ser evitado.
As vezes designers usam imagens para apresentar texto ou símbolos em um formato atrativo visualmente. Isto causa problemas pois imagens não podem ser descritas como parte da estrutura de todo um documento, o que significa que muita informação contextual importante é perdida.
Os usuários não podem redimensionar o texto que é apresentado como imagens em seus navegadores, o que torna difícil a leitura para pessoas com visão comprometida que preferem tamanhos maiores. Leitores de telas e displays de Braile podem decodificar markup (etiquetas) em voz ou Braile, tornando a estrutura e o conteúdo mais inteligível para leitores cegos.
Isto inclui um exemplo de
markup e de style sheets
usados para apresentar
informação matemática
utilizando MathML.Não há métodos de teste específicos recomendados para esta diretriz.
(WAI Checkpoint 3.2).Texto completo da WAI: "Criar documentos que validem gramáticas formais publicadas."
Uma etiqueta de documento HTML precisa seguir as regras que são definidas em um conjunto de declarações de markup que estão contidos em uma gramática formal publicada ou Definição de Tipo de Documento (DTD).
Documentos que são criados usando gramáticas formais publicadas serão suportados por mais navegadores e tecnologias de apoio.
Muitos perfis de acessibilidade de tecnologias de apoio, tecnologia de internet acessível e navegadores de internet, dependem de gramáticas formais publicadas. Ser incapaz de trabalhar com gramática formal publicada pode tornar uma página da internet inacessível ou inacessível para tecnologias de apoio, como leitores de tela, dispositivos de Braile, etc.
Escrever códigos que sejam compatíveis com gramáticas formais também facilita ferramentas de indexação, ferramentas de pesquisa, programas que extraem tabelas para bancos de dados, ferramentas de navegação que usam elementos de cabeçalhos e programa de tradução automáticas de texto.
pode
examinar seu código HTML (markup)
para assegurar que este está de acordo com as gramáticas formais. A W3C também
fornece uma lista completa das gramáticas
formais que são usadas. Algumas ferramentas de certificação também incluem validadores. se você
utiliza uma ferramenta de
certificação, deveria ser assegurado que
o validador está atualizado.
(WAI Checkpoint 3.6).Texto completo da WAI: "Listar corretamente os marcadores e itens de uma lista."
O código HTML permite que sejam criados diferentes tipos de listas para diferentes necessidades, por exemplo: UL, OL e DL. Cada uma destas listas têm propriedades de exibição que são apropriadas a cada necessidade. Por exemplo, em uma lista ordenada os itens são numerados, enquanto que uma lista de itens que não estão em ordem utiliza marcadores.
Elementos presentes em listas deveriam ser assinalados como listas, ao invés de ter os marcadores numéricos adicionados aos elementos em si. Elementos que não estejam presentes em listas não deveriam ser assinalados como listas para uma melhor apresentação visual. Por exemplo, um elemento não deveria ser atribuído a uma lista a fim de exibi-lo com um marcador ou número.
Listas com mais de um nível lógico também podem ser assinalados corretamente para criar um sistema de números compostos tais como 1.1, 1.2, 2.1, etc.
Usuários de leitor de tela notarão os números em uma lista ordenada para navegação e contexto. Se os números não se referirem a uma hierarquia estrutural clara, os usuários se confundirão facilmente.
Use um sistema de números compostos para listas numeradas
complexas.
Listas complexas, tais como aquelas numeradas 1.1, 1.2, 2.1 e assim
por diante podem ser criadas usando as técnicas recomendadas
da WAI para
listas markup em HTML
e para a
criação de listas ordenadas usando CSS.
Não há métodos de teste específicos recomendados para esta diretriz.
(WAI Checkpoint 3.7).Texto completo da WAI: "Não utilizar etiquetas de citação para efeitos de formatação, tais como indentação".
O HTML permite que citações sejam marcadas de fontes externas e de publicações. Estas serão então exibidas de forma apropriada.
Textos que são citações deveriam ser identificados como citação, ao invés de ter aspas e indentação especificados como atributos. Texto que não é uma citação não deveria ser identificado como tal para ter uma boa apresentação visual. Por exemplo, não deve-se identificar o texto como uma citação a fim de exibi-lo entre aspas.
O uso correto das etiquetas de citação, Q e BLOCKQUOTE, pode quebrar a página em pedaços grandes de conteúdo, e ajuda os usuários a ler mais facilmente na tela.
Alguns leitores de tela lerão o conteúdo identificado como citação com um tom de voz diferente, dando aos usuários pistas importantes sobre a estrutura do documento. O mal uso dos atributos de citação, por isso, confunde os usuários de leitores de tela.
Não há métodos de teste específicos recomendados para esta diretriz.
(WAI Checkpoint 11.1).Texto completo da WAI: "Utilize tecnologias da w3C quando estas estiverem disponíveis e forem apropriadas para uma tarefa e use as versões mais atualizadas quando suportadas."
Construa páginas da internet com tecnologias que sejam endossadas pela World Wide Web Consortium (W3C) e que sejam capazes de oferecer a funcionalidade exigida para implementar uma necessidade de usuário. Trabalhe com as especificações mais recentes de qualquer tecnologia W3C escolhida para um projeto específico.
A World Wide Web Consortium (W3C) é uma entidade internacional independente que cria padrões de linguagens de programação e de Internet, incluindo as diretrizes da WAI, da qual esta faz parte. Suas recomendações e padronizações são altamente reconhecidas.
Tecnologias W3C incluem versões padronizadas de HTML, XML, style sheets, multimídia e muitas outras tecnologias. Elas são universais, o que significa que elas são utilizáveis por uma grande variedade de navegadores e usuários.
Se tecnologias diferentes da W3C são usadas, pode ser solicitado ao usuário que faça o download de plug-ins ou aplicativos stand-alone que nem sempre são acessáveis. As tecnologias W3C são continuamente revistas para a acessibilidade. Usando uma tecnologia W3C, você tem mais chances de prover acessibilidade ao seu website.
As últimas versões das tecnologias W3C incluem muitas características que aperfeiçoarão a acessibilidade, embora não necessariamente de imediato. Estas características são construídas com tecnologias W3C na expectativa de que novos navegadores e outros usuários sejam beneficiados por elas. Utilizar estes perfis não afetará negativamente a performance de um site em navegadores e usuários mais antigos, desde que estes sejam adequadamente implementados. Incluir tais características em atuais projetos de desenvolvimento de páginas da web ajudará a garantir que o site terá "vida longa".
WAI para informação sobre tecnologias
W3C.Não há métodos de teste específicos recomendados para esta diretriz.
(WAI Checkpoint 11.2).Texto completo da WAI: "Evite as características que estão fora de uso das tecnologias W3C."
Um perfil "fora de uso" é aquele que a W3C deseja remover do padrão oficial para uma dada tecnologia, mas que ainda não se tornou oficialmente obsoleto ou foi removido. Embora eles sejam parte do padrão oficial, a W3C desaconselha o uso de perfis fora de uso. Por exemplo, a etiqueta "FONT" em HTML é um exemplo de um perfil não indicado em HTML 4.0.
A World Wide Web Consortium (W3C) é uma entidade internacional independente que cria padrões de linguagem de programação e de Internet. Suas recomendações e padronizações são altamente reconhecidas.
As tecnologias W3C são continuamente revistas para garantir a acessibilidade, por isso as últimas versões podem ter rejeitado algumas características que foram consideradas obstáculo para a acessibilidade. Usando uma tecnologia W3C, você tem mais chances de prover acessibilidade ao seu website.
lista todos os elementos em HTML 4.0.
Elementos fora de uso são indicados com um asterisco.
Testar com o validador HTML do W3C.
O
validador HTML do W3C
pode verificar o HTML para assegurar que este está de acordo com as gramáticas formais. A W3C também
fornece uma lista completa das gramáticas
formais que são usadas. Algumas ferramentas de certificação também incluem validadores. se você
utiliza uma ferramenta de
certificação, deveria ser assegurado que
o validador está atualizado e não valida as características que estão fora de
uso.
(WAI Checkpoint 7.4).Texto completo da WAI: "Até que os agentes do usuário supram a habilidade de parar a atualização, não crie páginas com atualização periódica automática."
Agentes do usuário são programas que as pessoas usam para acessar o conteúdo da Internet. Estes incluem navegadores gráficos, navegadores de texto, navegadores de voz, telefones celulares, tocadores multimídia, plug-ins e tecnologias assistivas, tais como leitores de tela, ampliadores de tela e programas de comandos de voz.
É possível criar páginas que se carreguem automaticamente no navegador do usuário, sempre que a janela do navegador estiver aberta. Isto deveria ser evitado no momento, uma vez que nem todos os agentes do usuário permitem que os usuários possam desabilitar a atualização automática.
O carregamento automático de uma nova página, ou da mesma página com um novo conteúdo pode ser muito confuso e frustrante para usuários que possam não estar completamente familiarizados com computadores e com o uso da Internet. Muitas pessoas consideram as páginas com auto-atualização (refresh)altamente confusas, porque elas controlam a navegação ao invés do usuário, que pode tornar-se rapidamente desorientado e deixar de compreender a estrutura do site.
Os usuários lêem em velocidades diferentes. É altamente perturbador e inquietante quando a página atualiza-se antes que o usuário tenha tido a chance de determinar o conteúdo desta ou antes que eles tenham terminado de lê-la. Isto pode tornar as páginas, ou seus conteúdos, não usáveis para usuários que tenham habilidade de leitura limitada ou dificuldade em concentrar-se por causa de ruído, stress ou desordem de aprendizagem.
Auto-atualização também causa problemas aos usuários de navegadores em texto, que geralmente não conseguem acompanhar a auto-atualização e podem falhar em exibir o conteúdo.
não deveria ser usado para redirecionar ou
auto-atualizar as páginasNão há métodos de teste específicos recomendados para esta diretriz.
(WAI Checkpoint 7.5).Texto completo da WAI: "Até que os agentes do usuário forneçam a faculdade de parar o redirecionamento automático das páginas, não use marcações para redirecioná-las automaticamente. Ao invés disso, configure o servidor para realizar os redirecionamentos."
Agentes do usuário são programas que as pessoas usam para acessar o conteúdo da Internet. Estes incluem navegadores gráficos, navegadores de texto, navegadores de voz, telefones celulares, tocadores multimídia, plug-ins e tecnologias assistivas, tais como leitores de tela, ampliadores de tela e programas de comandos de voz.
É possível criar páginas que enviam automaticamente, ou "direcionem" o usuário para uma nova página da Internet, como se eles estivessem seguindo um link. Links de auto-redirecionamento são freqüentemente "invisíveis", no sentido de que eles não são apresentados como uma escolha na página, mas estão inseridos no HTML. Isto deveria ser evitado no momento, uma vez que nem todos os agentes do usuário permitem que os usuários possam desabilitar o auto-redirecionamento.
O redirecionamento para uma nova página pode ser muito confuso e frustrante para usuários que possam não estar completamente familiarizados com computadores e com o uso da Internet. Muitas pessoas consideram as páginas com auto-redirecionamento altamente confusas porque elas controlam a navegação ao invés dos usuários, que podem tornar-se rapidamente desorientados e deixar de compreender a estrutura do site. O direcionamento automático para outra página diminui a confiança do usuário em um site, pois este lhe tira o controle sobre a navegação e a interação.
Os usuários lêem em velocidades diferentes. É altamente perturbador e inquietante quando a página atualiza-se antes que o usuário tenha tido a chance de determinar o conteúdo, ou antes que eles tenham terminado de lê-la. Isto pode tornar as páginas ou seus conteúdos não usáveis para usuários que tenham habilidade de leitura limitada ou dificuldade em concentrar-se por causa de ruído, stress ou desordem de aprendizagem.
O auto redirecionamento também causa problemas aos usuários de navegadores textuais, que geralmente não conseguem acompanhar o auto redirecionamento e podem falhar em exibir o conteúdo.
é preferível porque reduz o
tráfego de internet e tempo de
download, podem ser aplicados em documentos
que não estão no formato HTTP, e podem
também serem usados por agentes que solicitam apenas um pedido
principal (por exemplo: verificadores de links). Além disso, códigos
de status do tipo 30x fornecem informação
tais como "removido permanentemente" ou "removido temporariamente" que não podem ser dados com atualização
em
META.Não há métodos de teste específicos recomendados para esta diretriz.
(WAI Checkpoint 10.1).Texto completo da WAI: "Permitir aos usuários retirar as janelas automáticas, não deixar que pop-ups ou outras janelas apareçam e não mudar a janela atual sem informar o usuário."
É possível criar páginas que permitam que novas janelas abram automaticamente. Esta é chamada de "spawning" e as novas janelas são chamadas de "pop-ups", pois elas tendem a se abrir na tela, na parte superior da janela original. Pop-ups geralmente contém conteúdo publicitário, mas algumas vezes são usados para apresentar mensagens de erro. Cada vez que uma pop-up aparece, a atenção do usuário se direciona para esta janela.
Janelas pop-up deveriam ser evitadas no momento, uma vez que nem todos os agentes do usuário permitem que o usuário possa desabilitá-las. Se pop-ups forem usadas, o usuário deveria ser informado.
Agentes do usuário são programas que as pessoas usam para acessar o conteúdo da Internet. Estes incluem navegadores gráficos, navegadores de texto, navegadores de voz, telefones celulares, tocadores multimídia, plug-ins e tecnologias assistivas, tais como leitores de tela, ampliadores de tela e programas de comandos de voz.
Pop-ups podem ser bastante confusas e frustrantes para usuários que não estão totalmente familiarizados com computadores ou com a internet. Muitas pessoas as consideram desagradáveis pois elas controlam o computador no lugar do usuário, que podem rapidamente ficar desorientados. Pop-ups podem minar a confiança do usuário em um site, na medida em que estas controlam a navegação e a interação
Pop-ups causam problemas para os usuários de leitores de tela, pois estas lhes tiram a atenção sem avisar. Isto significa que o leitor de tela começa a ler o conteúdo da nova janela, freqüentemente sem avisar o usuário de que a nova janela abriu. Se a nova janela contém informação de outro site, o usuário pode ficar muito desorientado e confuso.
Abra a página e verifique se novas janelas aparecem. Novas janelas podem aparecer sobre ou atrás da janela atual. Formulários também deveriam ser testados para assegurar que janelas pop-up não são usadas para exibir mensagens de erro, submetendo deliberadamente informações incorretas nos formulários.
Disponibilizado em: 04/04/2008.
Barra horizontal inferior.
Acessibilidade Legal - www.acessibilidadelegal.com
1866
