Acessibilidade

Índice

Conceitos básicos

Acessibilidade diz respeito a Locais, produtos, serviços ou informações efetivamente disponíveis ao maior número e variedade possível de pessoas, independentemente de suas capacidades físico-motoras e perceptivas, culturais e sociais.

Isto requer a eliminação de barreiras arquitetônicas, disponibilidade de comunicação, de acesso físico, de equipamentos e programas adequados, disponibilidade de conteúdo e apresentação da informação em formatos alternativos.

Legislação Brasileira

Decreto 5.296, de 2 de dezembro de 2004, regulamenta:

Lei 10.048, de 8 de novembro de 2000, que dá prioridade de atendimento às pessoas que especifica;
Lei 10.098, de 19 de dezembro de 2000, que estabelece normas gerais e critérios básicos para a promoção da acessibilidade das pessoas com necessidades especiais, e dá outras providências;

Art. 8o Para os fins de acessibilidade, considera-se:

I – acessibilidade: condição para utilização, com segurança e autonomia, total ou assistida, dos espaços, mobiliários e equipamentos urbanos, das edificações, dos serviços de transporte e dos dispositivos, sistemas e meios de comunicação e informação, por pessoa portadora de deficiência ou com mobilidade reduzida;

II – barreiras: qualquer entrave ou obstáculo que limite ou impeça o acesso, a liberdade de movimento, a circulação com segurança e a possibilidade de as pessoas se comunicarem ou terem acesso à informação;

Essas barreiras podem ser classificadas como:

Barreiras urbanísticas: as existentes nas vias públicas e nos espaços de uso público;
Barreiras nas edificações: as existentes no entorno e interior das edificações de uso público e coletivo e no entorno e nas áreas internas de uso comum nas edificações de uso privado multifamiliar;
Barreiras nos transportes: as existentes nos serviços de transportes; e
Barreiras nas comunicações e informações: qualquer entrave ou obstáculo que dificulte ou impossibilite a expressão ou o recebimento de mensagens por intermédio dos dispositivos, meios ou sistemas de comunicação, sejam ou não de massa, bem como aqueles que dificultem ou impossibilitem o acesso à informação;

Art. 47. No prazo de até doze meses a contar da data de publicação deste Decreto, será obrigatória a acessibilidade nos portais e sítios eletrônicos da administração pública na rede mundial de computadores (internet), para o uso das pessoas portadoras de deficiência visual, garantindo-lhes o pleno acesso às informações disponíveis.

§ 1º Nos portais e sítios de grande porte, desde que seja demonstrada a inviabilidade técnica de se concluir os procedimentos para alcançar integralmente a acessibilidade, o prazo definido no caput será estendido por igual período.

§ 2º Os sítios eletrônicos acessíveis às pessoas portadoras de deficiência conterão símbolo que represente a acessibilidade na rede mundial de computadores (internet), a ser adotado nas respectivas páginas de entrada.

Art. 48. Após doze meses da edição deste Decreto, a acessibilidade nos portais e sítios eletrônicos de interesse público na rede mundial de computadores (internet), deverá ser observada para obtenção do financiamento de que trata o inciso III do art. 2o.

Art. 55. Caberá aos órgãos e entidades da administração pública, diretamente ou em parceria com organizações sociais civis de interesse público, sob a orientação do Ministério da Educação e da Secretaria Especial dos Direitos Humanos, por meio da CORDE, promover a capacitação de profissionais em LIBRAS.

Acessibilidade em TI

Acesso ao computador sem mouse: Pessoas com deficiência visual, dificuldade de controle dos movimentos, paralisia ou amputação de um membro superior.

Acesso ao computador sem teclado: Pessoas com amputações, grandes limitações de movimentos ou falta de força nos membros superiores. Interação através de um periférico especial de reconhecimento da fala ou de um emulador de teclado na tela.

Acesso ao computador sem monitor: A informação processada por um computador não é de natureza visual. Para obter a informação que é projetada na tela, os deficientes visuais recorrem a softwares (programas leitores de tela) que a enviam para sintetizadores de voz ou terminais Braille.

Acesso ao computador sem áudio: Pessoas com baixa audição e pessoas com surdez completa.

Construindo um Web Site Acessível

O trabalho requerido para construir um Web site acessível depende de vários fatores, entre eles: o tipo de conteúdo, o tamanho e a complexidade do site, e as ferramentas e o ambiente de desenvolvimento.

Muitos dos aspectos da acessibilidade serão facilmente implementados se forem planejados antes do início do desenvolvimento ou redesign. Adaptar sites existentes pode demandar uma quantidade considerável de trabalho e esforço.

Acessibilidade na Web

O W3C (World Wide Web Consortium) criou o WAI (Web Accessibility Initiative).

O WAI mantém grupos de trabalho elaborando conjuntos de diretrizes para garantir a acessibilidade do conteúdo da Web a pessoas com necessidades especiais, condições especiais de ambiente, equipamento, navegador e outras ferramentas Web.

Versão 1.0 das Diretrizes para a Acessibilidade do Conteúdo da Web (WCAG 1.0) é a Principal referência em termos de acessibilidade na Web.

Versões 1.0 e 2.0 das WCAG

As Diretrizes para acessibilidade ao conteúdo da Web foram aprovadas em maio de 1999 e se constituem uma versão estável e segura de referência.

As WCAG 2.0 estão sendo desenvolvidas para aplicação à diferentes tecnologias da Web, serem fáceis de entender e usar, serem mais refinadamente testadas.

A WAI colocou em fase de testes as WCAG 2.0, as WCAG 1.0 permanecerão a última versão aprovada até que as WCAG 2.0 estejam finalizadas.

A Web é, fundamentalmente, projetada para funcionar para todas as pessoas, independentemente do hardware, software, língua, cultura, localização, ou capacidade física ou mental do usuário. Quando a Web atende a esse objetivo, é acessível a pessoas com deficiência auditiva, de movimento, visão etc. A W3C publica um documento padrão (Web Content Accessibility Guidelines – WCAG), destinado, entre outros, a desenvolvedores Web, que explica como tornar o conteúdo Web mais acessível a pessoas com deficiência. A versão 2.0 desse documento tem 12 diretrizes que estão organizadas em quatro princípios (POUR): perceivable (Perceptibilidade), operable (Operabilidade), understandable (Compreensibilidade) e robust (robustez).

Perceptibilidade: a informação e os componentes da interface do usuário têm de ser apresentados aos usuários em formas que eles possam perceber.

Alternativas em Texto: Fornecer alternativas em texto. (Lembram do atributo “alt”?)
Mídias com base no tempo: Fornecer alternativas para mídias com base no tempo. (Legendas e descrição do conteúdo sonoro)
Adaptável: Criar conteúdos que possam ser apresentados de diferentes maneiras (por ex., um layout mais simples) sem perder informação ou estrutura. (CSS para impressão – print; e telas menores – handheld)

Operabilidade: Os componentes de interface de usuário e a navegação têm de ser operáveis

Acessível por Teclado: Fazer com que toda a funcionalidade fique disponível a partir do teclado. (Estruturação do conteúdo)
Ataques Epilépticos: Não criar conteúdo de uma forma conhecida que possa causar ataques epilépticos (Evitar piscar de telas)
Navegável: Fornecer formas de ajudar os usuários a navegar, localizar conteúdos e determinar o local onde estão (Finalidade do link – contexto);

Compreensibilidade: A informação e a operação da interface de usuário têm de ser compreensíveis.

Legível: Tornar o conteúdo de texto legível e compreensível. (Identificação do idioma, abreviaturas – acronym, etc).
Previsível: Fazer com que as páginas Web surjam e funcionem de forma previsível (Evitar que links abram novas janelas sem que o usuário saiba).

Robustez: O conteúdo tem de ser robusto o suficiente para poder ser interpretado de forma concisa por diversos agentes do usuário, incluindo tecnologias assistivas.

Compatível: Maximizar a compatibilidade com atuais e futuros agentes de usuário, incluindo tecnologias assistivas (Evitar elementos em desuso das tecnologias do W3C)

Diretrizes de acessibilidade ao conteúdo da Web (WCAG)

Explicam como produzir conteúdos para a Web que sejam acessíveis às pessoas portadoras de necessidades especiais. Genericamente, “conteúdo” da Web refere-se à informação contida em uma página web ou a uma aplicação Web. Inclui textos, imagens, formulários, sons e correlatos.

WCAG é parte de uma série de diretrizes para acessibilidade, incluindo:

Diretrizes para ferramentas de produção (ATAG)
Diretrizes para agentes de usuários (UAAG)

14 diretrizes (ou guias) contendo princípios gerais para projetos acessíveis

Cada diretriz é composta por um ou mais checkpoints que explicam como aquela diretriz se aplica em uma determinada área
Cada checkpoint tem uma prioridade
Com cada checkpoint é fornecido um link para as técnicas
- Técnicas básicas para as WCAG 1.0
- Técnicas HTML para as WCAG 1.0
- Técnicas CSS para as WCAG 1.0
As técnicas definem guias de implementação, incluindo explicações, estratégias e exemplos detalhados de marcação do código.

Diretrizes

Fornecer alternativas ao conteúdo sonoro e visual;
Não recorrer apenas à cor;
Utilizar corretamente marcações e folhas de estilo;
Indicar claramente qual o idioma utilizado;
Criar tabelas passíveis de transformação harmoniosa;
Assegurar que as páginas dotadas de novas tecnologias sejam transformadas harmoniosamente;
Assegurar o controle do usuário sobre as alterações temporais do conteúdo;
Assegurar a acessibilidade direta de interfaces do usuário integradas;
Projetar páginas considerando a independência de dispositivos;
Utilizar soluções de transição;
Utilizar tecnologias e recomendações do W3C;
Fornecer informações de contexto e orientações;
Fornecer mecanismos de navegação claros;
Assegurar a clareza e a simplicidade dos documentos.

Componentes essenciais para Acessibilidade à Web

É essencial que diferentes componentes do desenvolvimento e da interação Web se relacionem entre si com o objetivo de tornar a Web acessível às pessoas portadoras de necessidades especiais.

Estes componentes abrangem:

Conteúdo: informação contida em uma página ou aplicação Web;
Navegadores Web, players de mídia, e outros “agentes de usuário”;
Tecnologias auxiliares (assistivas), em alguns casos – leitores de tela, teclados alternativos, softwares de varredura, etc.;
Usuários, conhecimento, experiência e em alguns casos estratégias adaptadas para uso da Web;
Desenvolvedores – designers, programadores, autores, etc., incluindo desenvolvedores portadores de necessidades especiais e usuários com suas contribuições.
Ferramentas de criação – software para criação de Web sites
Ferramentas de aperfeiçoamento – ferramentas de aperfeiçoamento da acessibilidade à Web, validadores de HTML, validadores de CSS, etc.

Como os Componentes se relacionam

Desenvolvedores Web normalmente usam ferramentas de criação e ferramentas de aperfeiçoamento para criar conteúdo Web.

Pessoas (“usuários”) usam navegadores Web, players de mídia, tecnologias assistivas, outros “agentes de usuário” para acessar e interagir com o conteúdo.

Planejando a implementação de acessibilidade à Web

É importante desenvolver um planejamento para a implementação da acessibilidade:

Estabelecer responsabilidades;
Proceder uma avaliação inicial;
Desenvolver a política da organização;
Selecionar o Software;
Dar treinamento;
Desenvolver um Web Site acessível;
Promover uma consciência na organização;
Monitorar a acessibilidade ao Web Site;

O plano real de implementação, bem como a ordem das etapas, varia de organização para organização.

Modelo de Acessibilidade de Governo Eletrônico (e-Mag)

Conduzir o processo de acessibilidade dos sítios do Governo Brasileiro de forma padronizada, de fácil implementação, coerente com as necessidades brasileiras, e em conformidade com os padrões internacionais.

O processo para desenvolver um sítio acessível

O processo para desenvolver um sítio acessível: A acessibilidade à Web refere-se a garantir acesso facilitado a qualquer pessoa, independente das condições físicas, dos meios técnicos ou dispositivos utilizados. No entanto, ela depende de vários fatores, tanto de desenvolvimento quanto de interação com o conteúdo. O processo para desenvolver um sítio acessível é realizado em três passos:

Seguir os padrões Web;
Seguir as diretrizes ou recomendações de acessibilidade;
Realizar a avaliação de acessibilidade

Primeiro Passo: Padrões Web

Para se criar um ambiente online efetivamente acessível é necessário, primeiramente, que o código esteja dentro dos padrões Web internacionais definidos pelo W3C.

Os padrões de desenvolvimento Web do W3C, ou Web Standards, são um conjunto de recomendações que visa padronizar o conteúdo Web, possibilitando melhores práticas no desenvolvimento de páginas da Web. Uma página desenvolvida de acordo com os padrões Web deve estar em conformidade com as normas HTML, XML, XHTML e CSS, seguindo as regras de formatação sintática. Além disso, é muito importante que o código seja semanticamente correto, ou seja, que cada elemento seja utilizado de acordo com um significado apropriado, valor e propósito.

A conformidade com os padrões Web permite que qualquer sistema de acesso à informação interprete a mesma adequadamente e da mesma forma, seja por meio de navegadores, leitores de tela, dispositivos móveis (celulares, tablets, etc.) ou agentes de software (mecanismos de busca ou ferramentas de captura de conteúdo). Páginas que não possuem um código de acordo com os padrões do W3C apresentam comportamento imprevisível, e na maioria das vezes impedem ou pelo menos dificultam o acesso.

Segundo Passo: Diretrizes ou Recomendações de Acessibilidade

As diretrizes ou recomendações de acessibilidade explicam como tornar o conteúdo Web acessível a todas as pessoas, destinando-se aos criadores de conteúdo Web (autores de páginas e criadores de sítios) e aos programadores de ferramentas para criação de conteúdo. Um dos principais documentos nessa área é a WCAG, atualmente em sua versão 2.0, desenvolvida pelo consórcio W3C a partir da criação do WAI (Web Accessibility Initiative), contendo as recomendações de acessibilidade para conteúdo Web. Em nível nacional, o e-MAG é o documento que contém as diretrizes ou recomendações que norteiam o desenvolvimento de sítios e portais acessíveis.

Terceiro Passo: Avaliação de Acessibilidade

Após a construção do ambiente online de acordo com os padrões Web e as diretrizes de acessibilidade, é necessário testá-lo para garantir sua acessibilidade. No caso dos padrões Web, há um validador automático disponibilizado pelo próprio W3C (ver seção de Recursos). No que diz respeito às diretrizes de acessibilidade, é necessário realizar, inicialmente, uma validação automática através de validadores, que são softwares ou serviços online que ajudam a determinar se um sítio respeitou ou não as recomendações de acessibilidade, gerando um relatório de erros. Uma das ferramentas que podem ser utilizadas é o ASES, avaliador e simulador de acessibilidade em sítios, cujos instrumentos permitem avaliar, simular e corrigir a acessibilidade de páginas, sítios e portais, viabilizando a adoção da acessibilidade por órgãos do governo. Além do ASES, existem outros validadores automáticos (para mais informações, ver seção de Recursos deste documento).

É preciso salientar que, apesar de tornarem a avaliação de acessibilidade mais rápida e menos trabalhosa, os validadores automáticos por si só não determinam se um sítio está ou não acessível. Para uma avaliação efetiva, será necessária uma posterior validação manual.

A validação manual é necessária porque nem todos os problemas de acessibilidade em um sítio são detectados mecanicamente pelos validadores. Para a validação manual, são utilizados checklists de validação humana.

Assim, os passos sugeridos para a avaliação de acessibilidade em um sítio são os seguintes:

Validar os códigos do conteúdo HTML e das folhas de estilo;
Verificar o fluxo de leitura da página – para tal, utilizar um navegador textual, como o Lynx, ou um leitor de tela (recomendamos o NVDA ou ORCA). Para maiores detalhes, ver documento Descrição dos Leitores de Tela, disponível em: http://www.governoeletronico.gov.br/acoes-e-projetos/e-MAG/material-de-apoio.
Verificar o fluxo de leitura da página sem estilos, sem script e sem as imagens;
Verificar as funcionalidades da barra de acessibilidade, aumentando e diminuindo a letra, modificando o contraste, etc.;
Realizar a validação automática de acessibilidade utilizando o ASES e outros avaliadores automáticos;
Realizar a validação manual, utilizando os checklists de validação humana

A validação manual é uma etapa essencial na avaliação de acessibilidade de um sítio, já que os validadores automáticos não são capazes de detectar todos os problemas de acessibilidade em um sítio, pois muitos aspectos requerem um julgamento humano. Por exemplo, validadores automáticos conseguem detectar se o atributo para descrever imagens foi utilizado em todas as imagens do sítio, mas somente uma pessoa poderá verificar se a descrição da imagem está adequada ao seu conteúdo. Para realizar uma validação manual efetiva, o desenvolvedor deverá ter conhecimento sobre as diferentes tecnologias, as barreiras de acessibilidade enfrentadas por pessoas com deficiência e as técnicas ou recomendações de acessibilidade.

Outra etapa essencial da validação de uma página é a realização de testes com usuários reais (pessoas com deficiência ou limitações técnicas). Um usuário real poderá dizer se um sítio está realmente acessível, compreensível e com boa usabilidade e não simplesmente tecnicamente acessível. Quanto maior e mais diversificado o número de usuários reais participando da avaliação de acessibilidade, mais eficaz e robusto será o resultado.

Visões do Modelo de Acessibilidade de Governo Eletrônico

A versão 3.0 do e-MAG é apresentada em apenas um documento, não havendo separação entre visão técnica e visão do cidadão. O conteúdo das visões foi mantido na apostila apenas para efeito histórico, pois algumas bancas ainda cobram o assunto de forma defasada.

Visão Técnica: Cartilha de recomendações práticas para a construção e/ou adaptação de sítios eletrônicos. A Visão Técnica é voltada ao desenvolvedor, à pessoa que fará as alterações nos códigos dos sítios eletrônicos.

Visão do Cidadão: Arquitetura de segmentação da Visão Técnica. A Visão do Cidadão proporciona uma orientação e compreensão mais lógica e intuitiva do modelo propriamente dito e da Visão Técnica.

Visão do Cidadão

A Visão do Cidadão é uma arquitetura de abstração e entendimento das Recomendações de Acessibilidade. Caracteriza e detalha as necessidades de acessibilidade com foco no cidadão. Separa os princípios de acessibilidade percebidos em áreas, as quais denotam um tipo específico de benefício.

Áreas de Acessibilidade compreendidas na Visão do Cidadão:

Área da Percepção;
Área da Operação;
Área do Entendimento;
Área da Compatibilidade.

A Área da Percepção trata de benefícios relacionados à apresentação do conteúdo, da informação. Preocupa-se com a percepção de elementos como gráficos, sons, imagens, multimídia e equivalentes.

A Área da Operação preocupa-se com a manipulação da informação, do conteúdo. Garantir formas alternativas ao acesso às informações através de maneiras diferenciadas de navegação ou técnica similar. Garantir sempre ao usuário o controle da navegação e interação com o sítio.

A Área do Entendimento trata de questões relacionadas à compreensão do conteúdo publicado. Garantir que todo o conteúdo apresentado seja de fácil compreensão para qualquer tipo de usuário.

A Área da Compatibilidade aborda questões como a necessidade de utilizar-se sempre de tecnologias acessíveis e compatíveis com o modelo proposto.

Acessibilidade evolutiva

Nível de Acessibilidade de Prioridade 1:

Exigências básicas de acessibilidade.
Pontos que precisam ser satisfeitos obrigatoriamente pelos criadores e adaptadores de conteúdo Web.
Se não cumpridas, grupos de usuários ficarão impossibilitados de acessar as informações do documento.

Nível de Acessibilidade de Prioridade 2:

Normas e recomendações de acessibilidade que sendo implementadas garantem o acesso às informações do documento.
Se não cumpridas, grupos de usuários terão dificuldades para navegar e acessar as informações do documento.

Nível de Acessibilidade de Prioridade 3:

Normas e recomendações de acessibilidade que sendo implementadas facilitarão o acesso aos documentos armazenados na Web.
Se não cumpridas, grupos de usuários poderão encontrar dificuldades para acessar as informações dos documentos armazenados na Web.

Processo de acessibilidade

O processo ocorre em cinco etapas:

Verificação da necessidade de acessibilidade do conteúdo;
Tornar acessível o conteúdo;
Validação da acessibilidade do conteúdo;
- Validação automática (softwares específicos);
- Validação por técnicos de desenvolvimento;
- Validação por indivíduos com necessidades especiais.
Promoção da acessibilidade conquistada;
- Selo de acessibilidade (níveis A, AA e AAA).
Garantia contínua da acessibilidade.

Programas Avaliadores de Acessibilidade

Com base no W3C/WAI, foram desenvolvidos softwares que avaliam o nível de acessibilidade em sítios na internet. Tais programas produzem relatórios precisos com os problemas encontrados e que deveriam ser corrigidos para que o sítio se torne acessível.

Alguns destes softwares:

Da Silva (desenvolvido pela Acessibilidade Brasil e contempla o modelo de níveis de prioridade);
Bobby, Lift e Cynthia Says (em inglês);
TAW (em Espanhol);

Programas Leitores de Tela

Os usuários com necessidades especiais utilizam-se de programas capazes de ler e interpretar diretamente a tela do computador.

No Brasil, são utilizados três leitores de tela:

Dosvox/Webvox (desenvolvido no Brasil);
Virtual Vision (desenvolvido no Brasil);
Jaws for Windows.

Visão Técnica

Diretrizes: Organizam as recomendações conforme os resultados percebidos. Facilitam o entendimento, a aprendizagem e a fixação de conteúdos principalmente para os técnicos desenvolvedores.

Recomendações: Formam a base para a acessibilidade dos conteúdos, informações e serviços. Podem ser segmentadas conforme os Níveis de Prioridades, as Diretrizes de Acessibilidade e as tecnologias envolvidas.

Segmentação por tecnologia: organiza o processo de acessibilidade; agrupa as recomendações conforme suas características técnicas de implementação; possibilita a distribuição de atividades baseadas nos conhecimentos específicos dos técnicos desenvolvedores envolvidos; é realizada dentro de cada Nível de Prioridade.

Diretrizes de acessibilidade (e-MAG)

As Diretrizes Técnicas de Acessibilidade de Governo Eletrônico buscam facilitar ao técnico a compreensão, a fixação e o domínio das recomendações aqui propostas. Elas não definem uma ordem de implementação, que cabe ao modelo de Níveis de Acessibilidade, contudo, agrupam as recomendações de acordo com a percepção do resultado.

Forneça alternativas equivalentes para o conteúdo gráfico e sonoro.
Assegure-se de que seu sítio seja legível e compreensível mesmo sem o uso de formatações.
Dê preferência às tecnologias de marcação e formatação.
Assegure que toda a informação seja interpretada corretamente, com clareza e simplicidade.
Assegure que as tecnologias utilizadas funcionem – de maneira acessível – independente de programas, versões e futuras mudanças.
Assegure sempre o controle do usuário sobre a navegação no sítio.
Identifique claramente quais são os mecanismos de navegação.
Em casos não contemplados pelas diretrizes anteriores, utilize sempre recursos reconhecidos – por instituições com propriedade no assunto – como tecnologias acessíveis.

Segmentação por tecnologia

Casos gerais;
Casos em que são utilizados imagens e mapas de imagem;
Casos em que são utilizadas tabelas;
Casos em que são utilizados frames;
Casos em que são utilizados applets, objects, scripts e programas interpretáveis;
Casos em que é utilizada multimídia;
Casos em que são utilizados formulários.

Recomendações de Acessibilidade

O e-MAG abandonou os níveis de prioridade A, AA e AAA, visto que o padrão é voltado as páginas do Governo, não sendo permitido exceções com relação ao cumprimento das recomendações. Além disso, no e-MAG 3.0 foi incluída a seção chamada “Padronização de acessibilidade nas páginas do governo federal”, com o intuito de padronizar elementos de acessibilidade que devem existir em todos os sítios e portais do governo.

Os padrões de acessibilidade compreendem recomendações ou diretrizes que visam tornar o conteúdo Web acessível a todas as pessoas, inclusive às pessoas com deficiência, destinando-se aos autores de páginas, projetistas de sítios e aos desenvolvedores de ferramentas para criação de conteúdo. A observação destes padrões também facilita o acesso ao conteúdo da Web, independente da ferramenta utilizada (navegadores Web para computadores de mesa, laptops, telefones celulares, ou navegador por voz) e de certas limitações técnicas, como, por exemplo, uma conexão lenta, a falta de recursos de mídia, etc.

As recomendações de acessibilidade deste documento não estão dividas por níveis de prioridade, já que todas elas são de grande importância e devem ser seguidas. Dessa forma, optou-se por classificar as recomendações nas seguintes seções:

Marcação
Comportamento (DOM)
Conteúdo/Informação
Apresentação/Design
Multimídia
Formulário

OBS: As recomendações deste documento são baseadas em HTML 4.0 e XHTML 1.1. A maioria dos exemplos apresentados nas recomendações a seguir mostram o código (X)HTML que deve ser renderizado no navegador, já que é esse código que apresenta importância para garantir a acessibilidade. Assim, não foram apresentados exemplos do lado do servidor, pois o desenvolvedor pode utilizar a linguagem do lado do servidor que preferir, apenas tomando o cuidado com o código que será gerado.

Marcação

RECOMENDAÇÃO 1 – RESPEITAR OS PADRÕES DE DESENVOLVIMENTO WEB

Ver WCAG 2.0 Critérios de Sucesso 4.1.1 e 4.1.2

É essencial seguir os padrões de desenvolvimento Web, do W3C (World Wide Web Consortium), com o intuito de maximizar a compatibilidade com atuais e futuros agentes de usuário.

É preciso declarar o DOCTYPE correto da página de qualquer documento HTML ou XHTML. O DOCTYPE define qual versão do (X)HTML o documento está usando e esta é uma informação fundamental para que os agentes de usuário processem corretamente o documento. Além disso, é por meio do DOCTYPE que as ferramentas de validação analisam o código da página e indicam correções. Poderá ser utilizado qualquer DOCTYPE para HTML ou XHTML, com exceção do Frameset. Além disso, 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.

As camadas lógicas deverão ser separadas, de acordo com o objetivo para o qual elas foram desenvolvidas. Assim, para a camada de conteúdo devem ser utilizadas as linguagens de marcação, como html e xhtml. Para a camada de apresentação visual do conteúdo, utilizam-se as folhas de estilo css em qualquer uma de suas versões. Já para a camada que modifica o comportamento dos elementos, são utilizadas linguagens javascript e modelos de objeto (dom).

RECOMENDAÇÃO 2 – ORGANIZAR O CÓDIGO HTML DE FORMA LÓGICA E SEMÂNTICA

Ver WCAG 2.0 Critério de Sucesso 1.3.1

O código HTML deve ser organizado de forma lógica e semântica, ou seja, apresentando os elementos em uma ordem compreensível e correspondendo ao conteúdo desejado. Assim, marcação semântica adequada deve ser utilizada para designar os cabeçalhos (h1, h2, h3), as listas (ul, ol, dl), texto enfatizado (strong), marcação de código (code), marcação de abreviaturas (abbr), marcação de citações longas (blockquote), etc. Dessa forma, as páginas poderão ser apresentadas e compreendidas sem recursos de estilização, tal como as folhas de estilo. Além disso, o código semanticamente correto é muito importante para usuários com deficiência visual, pois os leitores de telas descrevem primeiro o tipo de elemento e depois realizam a leitura do conteúdo que está dentro desse elemento.

RECOMENDAÇÃO 3 – UTILIZAR CORRETAMENTE OS NÍVEIS DE CABEÇALHO

Ver WCAG 2.0 Critérios de Sucesso 1.3.1 e 2.4.10

Os níveis de cabeçalho devem ser utilizados de forma lógica e semântica para facilitar a leitura e compreensão. Além disso, pessoas acessando uma página com leitor de tela podem navegar através dos cabeçalhos, pulando de um para outro, agilizando, assim, a navegação. Conceitualmente, existem seis níveis de títulos, sendo o h1 o mais alto, ou seja, deverá corresponder ao título principal da página. Dessa forma, cada página deverá ter apenas um h1, o qual poderá ser substituído por uma imagem, mas deverá permanecer com seu conteúdo, mesmo que não visualmente, permitindo a leitura pelo leitor de tela. Já os níveis do h2 ao h6 poderão ser utilizados mais de uma vez na página, mas sem excesso e com lógica textual. Para compreender melhor os níveis de título pode-se tomar como exemplo um sítio de um livro, onde o nome do livro é o h1, os capítulos são h2, os subcapítulos são h3 e assim por diante.

RECOMENDAÇÃO 4 – ORDENAR DE FORMA LÓGICA E INTUITIVA A LEITURA E TABULAÇÃO

Ver WCAG 2.0 Critérios de Sucesso 1.3.2 e 2.4.3

Deve-se criar o código HTML com uma sequência lógica de leitura para percorrer links, controles de formulários e objetos. Essa sequência é determinada pela ordem que se encontra no código HTML.

É recomendável disponibilizar o bloco de conteúdo no HTML antes do bloco de menu, para que usuários, navegando pelo teclado, não precisem navegar por todos os itens de menu antes de chegar ao conteúdo. Apesar de os atalhos auxiliarem nesse sentido, alguns usuários não sabem utilizá-los. Os atalhos não funcionam em interfaces especializadas, como o do Leitor de Tela DOSVOX e podem ser de difícil utilização para pessoas com deficiência motora.

OBS: O atributo tabindex somente deverá ser utilizado quando existir real necessidade. Com o uso de CSS para fins de leiaute, o código HTML pode facilmente ser desenvolvido de maneira que a ordem de tabulação seja a correta. No entanto, se houver necessidade de utilizar o tabindex, o mesmo deverá ser utilizado com a semântica correta e deverá ser verificado manualmente se o fluxo fornecido pelo tabindex é realmente o desejado, evitando, assim, que o uso do tabindex resulte em uma ordem de tabulação inconsistente.

RECOMENDAÇÃO 5 – DISPONIBILIZAR TODAS AS FUNÇÕES DA PÁGINA VIA TECLADO

Ver WCAG 2.0 Critérios de Sucesso 2.1.1 e 2.1.2

Todas as funções da página desenvolvidas utilizando-se linguagens de script (javascript) deverão estar disponíveis quando for utilizado apenas o teclado. É importante salientar que o foco não deverá estar bloqueado ou fixado em um elemento da página, para que o usuário possa mover-se pelo teclado por todos os elementos.

Algumas funções específicas do mouse possuem uma função lógica correspondente via teclado, conforme mostrado na tabela a seguir:

OBS: * Alguns manipuladores de eventos são dispositivo-independentes, ou seja, se aplicam a qualquer dispositivo (mouse, teclado ou outro), como é o caso de: onFocus, onBlur, onSelect, onChange, e onClick (quando o onClick for utilizado em um link ou elemento de formulário).

Quando forem utilizados múltiplos manipuladores de eventos para uma ação, de maneira que ela funcione tanto pelo mouse como pelo teclado, é importante testar o resultado final em diferentes navegadores e utilizando diferentes recursos de tecnologia assistiva, para garantir que o evento seja, de fato, acessível.

Dê preferência por utilizar o onclick/onkeypress em vez de onmousedown/onkeydown e onmouseup/onkeyup, pois estes últimos fazem com que o evento seja disparado automaticamente através do teclado. Se houver real necessidade de utilização destes eventos, deverá ser feito um controle sobre qual tecla deverá ser acionada para que o evento ocorra.

Existem funções do mouse que não possuem uma função correspondente via teclado, como é o caso de duplo clique (dblclick). Nesses casos, é necessário implementar a função de maneira alternativa, como, por exemplo, incluindo botões que executem, pelo teclado, a função de forma equivalente. O evento onclick já funciona pelo teclado (tecla ENTER) na maioria dos navegadores.

RECOMENDAÇÃO 6 – FORNECER ÂNCORAS PARA IR DIRETO A UM BLOCO DE CONTEÚDO

Ver WCAG 2.0 Critério de Sucesso 2.4.1

Devem ser fornecidas âncoras, disponíveis na barra de acessibilidade, que apontem para links relevantes presentes na mesma página. Assim, é possível ir ao bloco de conteúdo desejado. Os links devem ser colocados em lugares estratégicos da página, como por exemplo, no início e final do menu, do conteúdo, etc.

Para facilitar a utilização das âncoras, podem ser disponibilizados atalhos por teclado, utilizando o atributo accesskey nos links relevantes. É importante ressaltar que as dicas de atalhos presentes na barra de acessibilidade não devem possuir o atributo accesskey, já que não pode haver repetição do mesmo accesskey em uma página. Recomenda-se fornecer atalhos para o menu principal, para o conteúdo e para a caixa de pesquisa.

Deve-se utilizar ambos os atributos name e id para que as âncoras funcionem em todos os navegadores, tanto textuais quanto gráficos, já que há os que suportam ambos os atributos e os que suportam apenas um deles.

As dicas dos principais atalhos do sítio devem ser disponibilizadas na barra de acessibilidade e na página sobre a acessibilidade do sítio.

RECOMENDAÇÃO 7 – NÃO UTILIZAR TABELAS PARA DIAGRAMAÇÃO

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnica H51)

As tabelas devem ser utilizadas apenas para dados tabulares e não para efeitos de disposição dos elementos na página. Para este fim, utilize as folhas de estilo.

RECOMENDAÇÃO 8 – SEPARAR LINKS ADJACENTES

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnica H48)

Links adjacentes devem ser separados por mais do que simples espaços, para que não fiquem confusos, em especial para usuários que utilizam leitor de tela. Para isso, é recomendado o uso de listas, onde cada elemento dentro da lista é um link. As listas podem ser estilizadas visualmente com CSS para que os itens sejam mostrados da maneira desejada, como um ao lado do outro, por exemplo.

Caso os links estejam no meio de um parágrafo, pode-se utilizar vírgulas, parênteses, colchetes, etc., para fazer a separação.

RECOMENDAÇÃO 9 – NÃO ABRIR NOVAS INSTÂNCIAS SEM A SOLICITAÇÃO DO USUÁRIO

Ver WCAG 2.0 Critério de Sucesso 3.2.5

A decisão de se utilizar-se de novas instâncias – por exemplo abas ou janelas – para acesso a páginas e serviços ou qualquer informação é do cidadão. Assim, não devem ser utilizados:

Pop-ups;
A abertura de novas abas ou janelas;
O uso do atributo target=“_blank”;
Mudanças no controle do foco do teclado;
Entre outras, que não tenham sido solicitadas pelo usuário.

Comportamento (DOM)

RECOMENDAÇÃO 10 – GARANTIR QUE OS OBJETOS PROGRAMÁVEIS SEJAM ACESSÍVEIS

Ver WCAG 2.0 Critérios de Sucesso 2.1.1 e 2.1.2

Deve-se garantir que scripts, Flash, conteúdos dinâmicos e outros elementos programáveis sejam acessíveis. Se não for possível que o elemento programável seja diretamente acessível, deve ser fornecida uma alternativa em HTML para o conteúdo. Assim, é preciso garantir que o conteúdo e as funcionalidades de objetos programáveis sejam acessíveis aos recursos de tecnologia assistiva e que seja possível a navegação por teclado.

Quando o script for utilizado em uma página da Web, uma forma de fornecer uma alternativa para ele é através do elemento <noscript>. Este elemento pode ser utilizado para mostrar conteúdos em navegadores que não suportam scripts ou que tenham o script desabilitado. No entanto, se o navegador tiver suporte a scripts e estes estiverem habilitados, o elemento <noscript> será ignorado. Dessa forma, a utilização do elemento <noscript> para um script inacessível não garante que o objeto seja acessível. Assim, a recomendação é que o próprio script seja desenvolvido tomando-se o cuidado para que ele seja acessível, e o elemento <noscript> deve ser utilizado para abranger os casos em que scripts não são suportados.

OBS: A função “alert” do JavaScript não gera um pop-up e sim uma mensagem que é lida por todos os leitores de tela.

RECOMENDAÇÃO 11- NÃO CRIAR PÁGINAS COM ATUALIZAÇÃO AUTOMÁTICA PERIÓDICA

Ver WCAG 2.0 Critério de Sucesso 3.2.5 (Técnicas SVR1 e H76)

Não devem ser criadas páginas com atualização automática periódica. Assim, não deve ser utilizada a meta tag refresh, nem outra forma de atualização automática. Páginas que se atualizam automaticamente podem confundir e desorientar os usuários, especialmente usuários que utilizam leitores de tela.

RECOMENDAÇÃO 12 – NÃO UTILIZAR REDIRECIONAMENTO AUTOMÁTICO DE PÁGINAS

Ver WCAG 2.0 Critério de Sucesso 3.2.5 (Técnicas SVR1 e H76)

RECOMENDAÇÃO 13 – FORNECER ALTERNATIVA PARA MODIFICAR LIMITE DE TEMPO

Ver WCAG 2.0 Critério de Sucesso 2.2.1

Em uma página onde há limite de tempo para realizar uma tarefa deve haver a opção de desligar, ajustar ou prolongar esse limite. Essa recomendação não se aplica a eventos em que o limite de tempo é absolutamente necessário.

Exemplo : Na inserção de dados em um formulário para obtenção de um benefício ou consulta a processo, o cidadão deve ter tanto tempo quanto for necessário para o preenchimento de seus dados.

RECOMENDAÇÃO 14 – NÃO INCLUIR SITUAÇÕES COM INTERMITÊNCIA DE TELA

Ver WCAG 2.0 Critério de Sucesso 2.3.1

Não devem ser utilizados efeitos visuais piscantes, intermitentes ou cintilantes. Em pessoas com epilepsia fotosensitiva, o cintilar ou piscar pode desencadear um ataque epilético. A exigência dessa diretriz aplica-se também para propaganda de terceiros inserida na página.

RECOMENDAÇÃO 15 – ASSEGURAR O CONTROLE DO USUÁRIO SOBRE AS ALTERAÇÕES TEMPORAIS DO CONTEÚDO

Ver WCAG 2.0 Critério de Sucesso 2.2.2

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 em propagandas na página. Ao usuário deve ser repassado o controle sobre essas movimentações (quer seja por escolha de preferência de visualização da página, quer por outro método qualquer acessível a usuário com deficiência). Além disso, o usuário deve ser capaz de parar e reiniciar conteúdos que se movem, sem exceção.

A velocidade desses conteúdos também deve ser passível de controle pelo usuário, a menos que a implementação de mecanismo para alterar a velocidade seja uma tarefa de difícil execução (se for necessário realizar uma escolha baseando-se nas limitações, prefira implementar mecanismos para reduzir a velocidade dos conteúdos no lugar de aumentar).

RECOMENDAÇÃO 16 – IDENTIFICAR O IDIOMA PRINCIPAL DA PÁGINA

Ver WCAG 2.0 Critério de Sucesso 3.1.1

Deve-se identificar o principal idioma utilizado nos documentos. A identificação é feita por meio do atributo lang do HTML e, para documentos XHTML, é utilizado o xml:lang.

RECOMENDAÇÃO 17 – OFERECER UM TÍTULO DESCRITIVO E INFORMATIVO À PÁGINA

Ver WCAG 2.0 Critério de Sucesso 2.4.2

O título da página deve ser descritivo e informativo, já que essa informação será a primeira lida pelo leitor de tela, quando o usuário acessar a página. O título é informado pela tag <title>.

Por exemplo: O sítio sobre o Projeto Acessibilidade Virtual da RENAPI (Rede Nacional de Pesquisa e Inovação em Tecnologias Digitais) apresenta o seguinte título: Projeto Acessibilidade Virtual – Portal RENAPI – Página Inicial.

RECOMENDAÇÃO 18 – DISPONIBILIZAR INFORMAÇÃO SOBRE A LOCALIZAÇÃO DO USUÁRIO NA PÁGINA

Ver WCAG 2.0 Critério de Sucesso 2.4.8

Deverá ser fornecido um mecanismo que permita ao usuário orientar-se dentro de um conjunto de páginas, permitindo que ele saiba onde está no momento. Assim, poderá ser utilizado o recurso de “migalha de pão” (breadcrumbs), que são links navegáveis em forma de lista hierárquica e permitem que o usuário saiba qual o caminho percorrido até chegar à página em que se encontra no momento.

OBS: Na migalha de pão, todos as páginas do caminho, com exceção da qual está o usuário (posição atual), deverão estar implementadas como links.

RECOMENDAÇÃO 19 – DESCREVER LINKS CLARA E SUCINTAMENTE

Ver WCAG 2.0 Critérios de Sucesso 2.4.4 e 2.4.9

Deve-se identificar claramente o destino de cada link, informando, inclusive, se o link remete a outro sítio. Além disso, é preciso que o texto do link faça sentido mesmo quando isolado do contexto da página.

É preciso tomar cuidado para não utilizar o mesmo título para dois ou mais links que apontem para destinos diferentes.

Exemplo: Leia mais notícias sobre Educação Superior

Repare que não há necessidade de utilizar o atributo title em links, já que esse atributo não é bem suportado por recursos de tecnologia assistiva, como leitores de tela, não tem utilidade para quem navega apenas pelo teclado e não tem bom suporte em dispositivos móveis, como celulares, entre outros problemas. Assim, se você quiser fornecer informações adicionais para um link, faça-o no próprio texto do link ou no contexto.

OBS: Não é recomendada a utilização de links do tipo “clique aqui” pois esta expressão não faz sentido fora do contexto. Muitos usuários de leitores de tela navegam por links, tornando descrições como “Clique aqui”, “Veja mais” insuficientes para o usuário saber o destino do link, ou localizá-lo na página. Evitar essas expressões para evitar verborragia, ou seja, evitar que o leitor de tela “leia” para o usuário palavras ou frases desnecessárias.

RECOMENDAÇÃO 20 – FORNECER ALTERNATIVA EM TEXTO PARA AS IMAGENS DO SÍTIO

Ver WCAG 2.0 Critério de Sucesso 1.1.1 (Técnica G95)

Deve ser fornecida uma descrição para as imagens da página, utilizando-se o atributo alt. Imagens que não transmitem conteúdo, ou seja, imagens decorativas, devem ser inseridas por CSS.

No entanto, descrever qualquer imagem, em geral, é algo bastante subjetivo e a descrição deve ser adaptada ao contexto em que a imagem se encontra. Para maiores detalhes de como escrever um texto alternativo veja o tutorial O uso correto do texto alternativo na seção do e-MAG no portal de Governo Eletrônico.

Apesar de não haver um limite de caracteres no atributo alt, ele é utilizado para descrições sintéticas, em poucas palavras ou em uma frase curta. Para imagens mais complexas que exigem uma descrição mais detalhada, como gráficos, por exemplo, deve-se fornecer, além do alt, a descrição no próprio contexto ou um link para a descrição longa logo após a imagem. Deve ficar claro para o usuário que esse link remete para a descrição longa da imagem, conforme o exemplo a seguir.

Para gráficos, poderá ser disponibilizada tanto a descrição textual quanto a tabela de dados que lhe deu origem, desde que a tabela seja fornecida em HTML, tomando-se os devidos cuidados relativos à acessibilidade.

Além de fornecer a descrição longa no contexto ou em um link próximo, pode-se utilizar o atributo longdesc na imagem, o qual é recomendado pela WCAG para descrições longas, mas não é suportado por alguns recursos de tecnologia assistiva.

RECOMENDAÇÃO 21 – FORNECER ALTERNATIVA EM TEXTO PARA AS ZONAS ATIVAS DE MAPA DE IMAGEM

Ver WCAG 2.0 Critério de Sucesso 1.1.1 (Técnica H24)

Para mapas de imagem do lado do cliente, devem ser fornecidas descrições através do atributo alt para cada uma das zonas ativas, ou seja, para cada um dos links que receberá o foco.

Além dos mapas de imagem do lado do cliente, existem os do lado do servidor. No entanto, é recomendada a utilização de mapas de imagem do lado do cliente, já que para mapas de imagem do lado do servidor não é possível fornecer um alt para cada uma das zonas ativas, somente para o mapa como um todo, não sendo possível, portanto, torná-lo acessível. No entanto, se for realmente necessária sua utilização, devem ser fornecidos links redundantes relativos a cada região ativa do mapa de imagem, conforme o exemplo a seguir, para que, desta forma, usuários com leitores de tela possam ter acesso ao seu conteúdo.

OBS: Não devem ser utilizados mapas de imagem para menus ou seleção de regiões para serviços.

RECOMENDAÇÃO 22 – DISPONIBILIZAR DOCUMENTOS EM FORMATOS ACESSÍVEIS

Sem correspondência a critérios da WCAG 2.0

Os documentos devem ser disponibilizados preferencialmente em HTML. Também podem ser utilizados arquivos para download no formato ODF, tomando-se os cuidados para que sejam acessíveis. Se um arquivo for disponibilizado em PDF, deverá ser fornecida uma alternativa em HTML ou ODF. É necessário, também, informar a extensão e o tamanho do arquivo no próprio texto do link.

OBS: O ODF (Open Document Format) é um formato aberto de documento adotado pela e-PING (Arquitetura de Interoperabilidade em Governo Eletrônico) que pode ser implementado em qualquer sistema. O ODF engloba formatos como: ODT para documentos de texto, ODS para planilhas eletrônicas, ODP para apresentações de slides, entre outros.

Muitos softwares já utilizam esses formatos, como é o caso do OpenOffice, BrOffice, Google Docs, Abiword e StarOffice. O Microsoft Office 2010 também inclui suporte para ODF. Para versões anteriores do Microsoft Office, pode ser instalado um Add-in gratuito para suporte aos formatos ODF.

RECOMENDAÇÃO 23 – EM TABELAS, UTILIZAR TÍTULOS E RESUMOS DE FORMA APROPRIADA

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnicas H39 e H73)

O título da tabela deve ser definido pelo elemento caption e deve ser o primeiro elemento utilizado após a declaração do elemento table. Em casos de tabelas extensas, deve ser fornecido um resumo de seus dados através do atributo summary que deve ser declarado no elemento table.

RECOMENDAÇÃO 24 – ASSOCIAR CÉLULAS DE DADOS ÀS CÉLULAS DE CABEÇALHO EM UMA TABELA

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnicas H43 e H63)

Em tabelas de dados simples, a uso apropriado do elemento th para os cabeçalhos e do elemento td para as células de dados é essencial para torná-las acessíveis. Para incrementar a acessibilidade, deve-se utilizar os elementos thead, tbody e tfoot, para agrupar as linhas de cabeçalho, do corpo da tabela e do final, respectivamente, com exceção de quando a tabela possuir apenas o corpo, sem ter seções de cabeçalho e rodapé. O W3C sugere utilizar o tfoot antes do tbody dentro da definição table para que o agente de usuário possa renderizar o rodapé antes de receber todas (potencialmente numerosas) linha de dados.

Para tabelas mais complexas, é necessário utilizar marcações para associar as células de dados com as células de cabeçalho. A maneira mais adequada de realizar esse procedimento é utilizar os elementos id/headers ou scope/col. No primeiro, pode-se associar qualquer célula de conteúdo a qualquer célula de cabeçalho, utilizando o mesmo valor para o atributo id e para o headers. No segundo caso, a associação é automática, sendo mais utilizado em tabelas de associação direta, onde é dado o valor “col” para o atributo scope nos cabeçalhos.

RECOMENDAÇÃO 25 – GARANTIR A LEITURA E COMPREENSÃO DAS INFORMAÇÕES

Ver WCAG 2.0 Critério de Sucesso 3.1.5

O texto de um sítio deve ser de fácil leitura e compreensão, não exigindo do usuário um nível de instrução mais avançado do que o ensino fundamental completo. Quando o texto exigir uma capacidade de leitura mais avançada, deve ser disponibilizado informações suplementares que expliquem ou ilustrem conteúdo principal. Outra alternativa é versão simplificada do conteúdo em texto.

Existem algumas técnicas que auxiliam na melhora da inteligibilidade de textos, como, por exemplo:

Desenvolver apenas um tópico por parágrafo;
Utilizar sentenças organizadas de modo simplificado para o propósito do conteúdo (sujeito, verbo e objeto, preferencialmente);
Dividir sentenças longas em sentenças mais curtas;
Evitar o uso de jargão, expressões regionais ou termos especializados que possam não ser claros para todos;
Utilizar palavras comuns no lugar de outras pouco familiares;
Utilizar listas de itens ao invés de uma longa série de palavras ou frases separadas por vírgulas;
Fazer referências claras a pronomes e outras partes do documento;
Utilizar, preferencialmente, a voz ativa.

Para mais informações sobre como escrever textos para web, acesse a Cartilha de Redação Web na Seção do e-PWG (Padrões Web em Governo Eletrônico) no Portal de Governo Eletrônico.

RECOMENDAÇÃO 26 – DISPONIBILIZAR UMA EXPLICAÇÃO PARA SIGLAS, ABREVIATURAS E PALAVRAS INCOMUNS

Ver WCAG 2.0 Critérios de Sucesso 3.1.3 e 3.1.4

Deve estar disponível uma explicação que identifique a forma completa ou o significado das abreviaturas e siglas. Para isso, pode ser utilizada a tag abbr.

Já as palavras que podem ser ambíguas, desconhecidas ou utilizadas de forma muito específica, deverão ser definidas através de um texto adjacente, uma lista de definições ou estarem contidas num glossário.

RECOMENDAÇÃO 27 – INFORMAR MUDANÇA DE IDIOMA NO CONTEÚDO

Ver WCAG 2.0 Critério de Sucesso 3.1.2

Se algum elemento de uma página possuir conteúdo em um idioma diferente do principal, este deverá estar identificado pelo atributo lang. Essa recomendação não se aplica para nomes próprios ou termos técnicos que sejam compreendidos no contexto.

Apresentação/Design

RECOMENDAÇÃO 28 – OFERECER CONTRASTE MÍNIMO ENTRE PLANO DE FUNDO E PRIMEIRO PLANO

Ver WCAG 2.0 Critério de Sucesso 1.4.3

As cores do plano de fundo e do primeiro plano deverão ser suficientemente contrastantes para que possam ser visualizadas, também, por pessoas com baixa visão, com cromodeficiências ou que utilizam monitores de vídeo monocromático.

Não deverão ser utilizadas imagens atrás do texto (background), pois acabam por dificultar a leitura e desviar a atenção do usuário.

A relação de contraste pode ser encontrada dividindo-se o valor da luminosidade relativa da cor mais clara de um dos planos pelo valor da luminosidade relativa da cor mais escura do outro plano. A relação de contraste entre plano de fundo e primeiro plano de 3:1 é o nível mínimo de contraste recomendado pela ISO-9241-3. No entanto, levando-se em consideração a perda de percepção do contraste resultante da baixa acuidade visual, cromodeficiência ou perda de sensibilidade ao contraste devido ao envelhecimento, é recomendada aqui uma maior relação de contraste, de, no mínimo, 4,5:1. Existem ferramentas gratuitas disponíveis na Web que verificam a relação de contraste entre as cores do plano de fundo e do primeiro plano.

RECOMENDAÇÃO 29 – NÃO UTILIZAR APENAS COR OU OUTRAS CARACTERÍSTICAS SENSORIAIS PARA DIFERENCIAR ELEMENTOS

Ver WCAG 2.0 Critérios de Sucesso 1.3.3 e 1.4.1

A cor ou outras características sensoriais, como forma, tamanho, localização visual, orientação ou som não devem ser utilizadas como o único meio para transmitir informações, indicar uma ação, pedir uma resposta ao usuário ou distinguir um elemento visual.

RECOMENDAÇÃO 30 – PERMITIR REDIMENSIONAMENTO DE TEXTO SEM PERDA DE FUNCIONALIDADE

Ver WCAG 2.0 Critério de Sucesso 1.4.4

A página deve continuar legível e funcional quando redimensionada para até 200%. Assim, é preciso garantir que, quando a página for redimensionada, não ocorram sobreposições de texto nem o aparecimento de uma barra horizontal.

RECOMENDAÇÃO 31 – DIVIDIR AS ÁREAS DE INFORMAÇÃO

Ver WCAG 2.0 Critério de Sucesso 3.2.3 (Técnica G61)

Áreas de informação devem ser divididas em grupos fáceis de gerenciar. As divisões mais comuns são “topo”, “conteúdo”, “menu” e “rodapé”. Nas páginas internas deve-se manter uma mesma divisão para que o usuário se familiarize mais rapidamente com a estrutura do sítio. É importante destacar, entretanto, que a página inicial pode ter uma divisão diferente das páginas internas, pois normalmente ela contém mais elementos.

A divisão em blocos de conteúdo representa a base para a utilização dos atalhos, permitindo que o usuário tenha rápido acesso à área desejada.

É importante que as diversas páginas de um sítio possuam um estilo de apresentação coerente e sistemático, mantendo-se um padrão de estrutura. Assim, elementos principais de navegação deverão ser mantidos na mesma posição em todas as páginas, com exceção da página inicial que, muitas vezes, apresenta uma estrutura diferenciada.

RECOMENDAÇÃO 32 – POSSIBILITAR QUE O ELEMENTO COM FOCO SEJA VISUALMENTE EVIDENTE

Ver WCAG 2.0 Critério de Sucesso 2.4.7

A área que recebe o foco pelo teclado deve ser claramente marcada, devendo a área de seleção ser passível de ser clicada.

Por padrão, links e elementos de formulário já apresentam a borda destacada ao receberem o foco do teclado. Essa borda pode ser modificada via CSS, mas não deverá ser removida.

A pseudo-classe :focus é utilizada para definir o estilo de qualquer elemento HTML que receber o foco do teclado, como links e elementos de formulário. A pseudo-classe :hover é utilizada para definir o estilo de um elemento quando passa-se o mouse sobre ele. Já a pseudo-classe :active define o estilo de link ativo.

Multimídia

RECOMENDAÇÃO 33 – FORNECER ALTERNATIVA PARA VÍDEO

Ver WCAG 2.0 Critérios de Sucesso 1.2.1, 1.2.2, 1.2.6 e 1.2.8

Deve haver uma alternativa sonora ou textual para vídeos que não incluem faixas de áudio. Para vídeos que contêm áudio falado e no idioma natural da página, devem ser fornecidas legendas. Além de essencial para pessoas com deficiência visual, a alternativa em texto também é importante para usuários que não possuem equipamento de som, que desejam apenas realizar a leitura do material ou não dispõem de tempo para ouvir um arquivo multimídia. Para tanto, podem ser fornecidos:

Situação 1: Um vídeo mostra como produzir uma tecnologia assistiva de baixo custo. Não há áudio, mas o vídeo inclui uma série de números para representar cada etapa do processo. Nesse caso, junto ao vídeo, deve ser disponibilizado um arquivo com a alternativa de texto que indica o conteúdo do vídeo e a descrição de cada uma das etapas.

Situação 2: Uma universidade oferece a opção de visualizar suas videoaulas com ou sem legendas.

Além de alternativa em texto e legenda, é desejável que os vídeos com áudio apresentem alternativa na Língua Brasileira de Sinais (Libras).

RECOMENDAÇÃO 34 – FORNECER ALTERNATIVA PARA ÁUDIO

Ver WCAG 2.0 Critérios de Sucesso 1.2.1, 1.2.2 e 1.2.6

Áudio gravado deve possuir uma transcrição descritiva. Além de essencial para pessoas com deficiência auditiva, a alternativa em texto também é importante para usuários que não possuem equipamento de som, que desejam apenas realizar a leitura do material ou não dispõem de tempo para ouvir um arquivo multimídia. Neste caso, também é desejável a alternativa em Libras.

Situação 1

Em um podcast o entrevistador faz perguntas a um especialista de saúde. Como essas informações são disponibilizadas ao usuário do sítio em um arquivo de áudio, deve ser fornecido um link para um arquivo com alternativa em texto, logo após o conteúdo em áudio.

Uma apresentação prévia do conteúdo dos dois tipos de arquivo e de sua duração também é desejável.

RECOMENDAÇÃO 35 – OFERECER AUDIODESCRIÇÃO PARA VÍDEO PRÉ-GRAVADO

Ver WCAG 2.0 Critério de Sucesso 1.2.3, 1.2.5 e 1.2.7

Vídeos que transmitem conteúdo visual que não está disponível na faixa de áudio devem possuir uma audiodescrição.

A audiodescrição consiste na descrição clara e objetiva de todas as informações apresentadas de forma visual e que não fazem parte dos diálogos. Essas descrições são apresentadas nos espaços entre os diálogos e nas pausas entre as informações sonoras.

Exemplo: Um vídeo de um malabarista se apresentando para um grupo de crianças inclui uma versão com audiodescrição. O narrador da audiodescrição descreve o número e o tipo de instrumentos que o malabarista utiliza, bem como as reações que as crianças têm durante a performance.

RECOMENDAÇÃO 36 – FORNECER CONTROLE DE ÁUDIO PARA SOM

Ver WCAG 2.0 Critério de Sucesso 1.4.2

Deve ser fornecido um mecanismo para parar, pausar, silenciar ou ajustar o volume de qualquer som que se reproduza na página.

RECOMENDAÇÃO 37 – FORNECER CONTROLE DE ANIMAÇÃO

Ver WCAG 2.0 Critério de Sucesso 2.2.2

Para qualquer animação que inicie automaticamente na página devem ser fornecidos mecanismos para que o usuário possa pausar, parar ou ocultar tal animação.

Formulários

RECOMENDAÇÃO 38 – FORNECER ALTERNATIVA EM TEXTO PARA OS BOTÕES DE IMAGEM DE FORMULÁRIOS

Ver WCAG 2.0 Critério de Sucesso 1.1.1

Ao serem utilizados botões do tipo imagem (input type=”image”), que servem para o mesmo propósito do botão do tipo submit, deve ser fornecida uma descrição textual para o botão através do atributo alt.

Já para outros tipos de botões (reset e button), é preciso substituir o botão pela imagem que se deseja utilizar através do CSS. Nesse caso, para que o botão seja acessível, ele deve possuir um value descritivo.

RECOMENDAÇÃO 39 – ASSOCIAR ETIQUETAS AOS SEUS CAMPOS

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnica H44)

As etiquetas de texto (label) devem estar associadas aos seus campos (input) correspondentes no formulário, através dos atributos for do label e id do input, os quais deverão ter o mesmo valor.

RECOMENDAÇÃO 40 – ESTABELECER UMA ORDEM LÓGICA DE NAVEGAÇÃO

Ver WCAG 2.0 Critério de Sucesso 2.4.3

Os elementos do formulário devem ser distribuídos corretamente através do código HTML, criando, assim, uma sequência lógica de navegação. Assim, os formulários devem primeiro ser codificados considerando a ordem lógica de navegação para depois serem organizados visualmente via CSS.

OBS: O atributo tabindex somente deverá ser utilizado quando existir real necessidade. É importante ressaltar que este atributo deverá ser utilizado com a semântica correta e deverá ser verificado manualmente se o fluxo fornecido pelo tabindex é realmente o desejado.

RECOMENDAÇÃO 41 – NÃO PROVOCAR AUTOMATICAMENTE ALTERAÇÃO NO CONTEXTO

Ver WCAG 2.0 Critério de Sucesso 3.2.2

Quando um elemento de formulário receber o foco, não deve ser iniciada uma mudança automática na página que confunda ou desoriente o usuário. Assim, as mudanças devem ocorrer através do acionamento de um botão.

RECOMENDAÇÃO 42 – FORNECER INSTRUÇÕES PARA ENTRADA DE DADOS

Ver WCAG 2.0 Critério de Sucesso 3.3.2

Para conteúdo que exigir entrada de dados por parte do usuário, devem ser fornecidas, quando necessário, instruções de preenchimento juntamente com as etiquetas (label). A utilização de caracteres pré-definidos em áreas de entrada de texto só deve ocorrer se:

O texto for incluído após a entrada de dados pelo usuário (por exemplo, sugerir um novo nome de usuário caso o escolhido já exista);
A semântica do documento justifique a inclusão de texto pré-definido (por exemplo, uma loja virtual que só vende para determinado país já vem com o campo país preenchido);
Os caracteres tenham sido fornecidos previamente pelo usuário (por exemplo, refinamento de busca).

RECOMENDAÇÃO 43 – IDENTIFICAR E DESCREVER ERROS DE ENTRADA DE DADOS

Ver WCAG 2.0 Critério de Sucesso 3.3.1

Quando um erro de entrada de dados for automaticamente detectado, o item que apresenta erro deve ser identificado e descrito ao usuário por texto.

Exemplo 1: Um usuário tenta submeter um formulário, mas esquece de preencher campos obrigatórios. Utilizando validação client-side (do lado do cliente), a omissão é detectada e um alerta aparece informando ao usuário que campos obrigatórios não foram preenchidos. Para a identificação destes campos, as etiquetas são modificas tornando-se avisos e também o foco do teclado é remetido para o primeiro campo sem preenchimento.

Exemplo 2: Quando o usuário enviar o formulário e esquecer-se de preencher um campo obrigatório ou preencher um campo de maneira incorreta, o foco é remetido novamente ao formulário, mas que estará contendo apenas os campos com erro, para que o usuário não precise navegar por todos os outros campos novamente. Abaixo dos campos com erro que deverão ser novamente preenchidos, haverá o botão de envio e um botão para o usuário retornar ao formulário completo, caso ele deseje verificar todos os campos.

Exemplo 3: O usuário envia o formulário e deixa de preencher campos obrigatórios ou preenche algum campo de maneira incorreta. O foco retorna ao início do formulário contendo o aviso de erro e links (âncoras) para os campos do formulário que apresentaram erro.

RECOMENDAÇÃO 44 – AGRUPAR CAMPOS DE FORMULÁRIO

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnicas H71 e H85)

Deverão ser agrupados os controles de formulário relacionados de maneira lógica, utilizando-se o elemento fieldset, associando o elemento legend de forma significativa (o elemento fieldset é útil para agrupar, de forma lógica, elementos do formulário). Para cada fieldset, é possível fornecer uma legenda que explica claramente o propósito ou natureza dos agrupamentos.

Para agrupar elementos option dentro de um elemento de lista select, deve ser utilizado o elemento optgroup.

RECOMENDAÇÃO 45 – FORNECER CAPTCHA HUMANO

Ver WCAG 2.0 Critério de Sucesso 1.1.1 (Técnicas G143 e G144)

O CAPTCHA (teste interativo humano, completamente automatizado, para distinguir computadores de seres humanos), quando utilizado, deverá ser fornecido em forma de pergunta de interpretação. Tais perguntas poderão ser respondidas apenas por um ser humano. No entanto, é preciso garantir que a pergunta não seja de difícil resolução, permitindo que a mesma possa ser respondida por pessoas de variadas culturas e níveis de instrução. Para tal, podem ser utilizadas perguntas de senso comum, como por exemplo, “qual é a cor do céu?” ou “o fogo é quente ou frio?”. Também podem ser utilizados testes matemáticos. No entanto, é preciso tomar cuidado para que esses testes não sejam facilmente “quebrados” por determinados programas. Uma alternativa é solicitar que o usuário escreva o resultado do teste matemático por extenso, como “escreva por extenso quanto é 2 + 3”, ou ainda “responda por extenso quanto é dois mais três”.

OBS: O CAPTCHA deverá ser utilizado apenas quando estritamente necessário.

Padrões de acessibilidade digital do governo eletrônico

Esta seção pretende padronizar elementos de acessibilidade que devem ter características em comum em todas as páginas do governo federal, para fins de facilitar o acesso por pessoas com deficiência. Este conjunto de elementos busca garantir o desenvolvimento de sítios acessíveis a todas as pessoas.

Os elementos a serem padronizados, que devem estar presentes em todas as páginas do Governo Federal são:

Página com a descrição dos recursos de acessibilidade
Teclas de atalho
Barra de acessibilidade
Apresentação do mapa do sitio
Apresentação de formulário
Conteúdo alternativo para imagens
Apresentação de documentos

Ao final também serão apresentados elementos que não serão permitidos nas páginas do governo federal.

Página de descrição com os recursos de acessibilidade

Esta página apresenta os recursos de acessibilidade presentes no sítio, como as teclas de atalho disponíveis, as opções de redimensionamento de texto e alto contraste, detalhes sobre testes de acessibilidade realizados no sítio e outras informações pertinentes a respeito de sua acessibilidade. O link para a página contendo os recursos de acessibilidade deve ser disponibilizado na barra de acessibilidade, a qual será abordada no terceiro item desta seção.

Atalhos de teclado

Deverão ser disponibilizados atalhos por teclado para pontos estratégicos da página, permitindo que o usuário possa ir diretamente a esses pontos. Os atalhos deverão funcionar através de números precedidos da tecla padrão de cada navegador (Alt no Internet Explorer, Shift + Alt no Firefox, Shift + Esc no Opera, etc.). Os atalhos que deverão existir nas páginas do Governo Federal são os seguintes:

Para ir ao conteúdo;
Para ir ao menu principal;
Para ir à caixa de pesquisa;

As dicas dos atalhos deverão ser disponibilizadas na barra de acessibilidade, abordada a seguir e, também, na página sobre a acessibilidade do sítio, já comentada anteriormente.

Barra de acessibilidade

O sítio deverá conter uma barra de acessibilidade no topo de cada página contendo os seguintes itens:

Aumentar fonte
Diminuir fonte
Fonte normal
Alto contraste
Atalhos (para Menu, Conteúdo e Busca)
Acessibilidade (link para a página contendo os recursos de acessibilidade do sítio)

Quando uma das ferramentas aumentar fonte, diminuir fonte e fonte normal for utilizada, o bloco como um todo deve ser modificado, não apenas a fonte do texto.

A opção alto contraste deve gerar uma página em que a relação de contraste entre o plano de fundo e os elementos do primeiro plano seja de, no mínimo 7:1 (contraste otimizado). As ferramentas utilizadas para verificar a relação de contraste entre as cores estão listadas no capítulo 4 – Recursos e Ferramentas para Acessibilidade.

Apresentação do mapa do sítio

Deverá ser fornecido um mapa do sítio para sítios que contenham páginas internas que não estão presentes no menu. O mapa do sítio deve ser disponibilizado em forma de lista, podendo conter quantos níveis forem necessários.

Apresentação de formulário

Os formulários deverão estar de acordo com os seguintes itens:

Sempre utilizar a tag form, mesmo que o formulário possua apenas um elemento, como é o caso de uma caixa para pesquisa.
Disponibilizar os elementos do formulário no HTML na ordem correta de navegação, sem utilizar o tabindex.
Associar as etiquetas (label) aos seus campos (input) correspondentes.
Não deve ocorrer mudança no contexto quando um elemento receber o foco.
Deve ser fornecido um botão de envio (submit) para enviar os dados. No entanto, é necessário fornecer uma maneira de o usuário poder verificar as informações antes que elas sejam enviadas.
Os erros de entrada de dados devem ser identificados e descritos ao usuário.
Para cada conjunto de informações, com dois ou mais elementos de entrada de dados, os mesmo deverão ser agrupados através do elemento fieldset/legend. Em um formulário de busca simples, por exemplo, não há a necessidade de utilizar o elemento fieldset/legend, pois apresenta apenas um campo de entrada de dados.

Após clicar no botão enviar, uma tela de confirmação deverá aparecer permitindo que o usuário verifique e, se necessário, edite as informações antes de enviá-las.

Conteúdo alternativo para imagens

Deverá ser fornecida uma alternativa textual, pelo atributo alt, para imagens, fotos, gráficos, banners, botões de imagem, áreas ativas de mapa de imagem, CAPTCHA, etc. Além do alt, para imagens mais complexas, que necessitem de uma descrição mais detalhada, deverá ser fornecida uma descrição longa no próprio contexto ou em um link (claramente identificado como descrição da imagem) logo após a imagem.

Apresentação de documentos

Os documentos em texto deverão ser disponibilizados preferencialmente em HTML. Também podem ser disponibilizados arquivos para download no formato ODF, tomando-se os cuidados para que sejam acessíveis. Se houver necessidade de disponibilizar arquivos em PDF, deverá ser fornecida uma alternativa em HTML ou ODF. É necessário, também, informar a extensão e o tamanho do arquivo no próprio texto do link.

Elementos que não devem ser utilizados

Tabelas para fins de diagramação, conforme Recomendação 7;
Atualizações automáticas periódicas, conforme Recomendação 11;
Situações com intermitência de tela, conforme Recomendação 14;
Elementos considerados depreciados pelo W3C, como frame, applet, blink, marquee, basefont, center, dir, align, font, isindex, menu, strike, u, etc.

Bibliografia

Decreto Nº 5.296:2006

Questões

Arquitetura de Software:
- Acessibilidade
- E-Mag (Modelo de Acessabilidade de Governo Eletrônico)
- Responsabilidade Social Junto aos Deficientes

Resolução de Questões de Concursos Anteriores

TER-MS – Analista Judiciário – 2013 – CESPE

Considerando as recomendações da W3C, assinale a opção correta, a respeito de acessibilidade na Web. a) Quando o documento acessado está no formato PDF, não se faz necessário quaisquer ajustes, pois esse tipo de documento já se enquadra nativamente nas recomendações da W3C. b) Recomenda-se combinar recursos de cores e marcadores semânticos, como, por exemplo, elementos em negrito, de modo a permitir que usuários que não distinguem cores tenham outra forma de receber a informação desejada. c) Com objetivo de facilitar a leitura por meio de ferramentas específicas para as pessoas com deficiência na visão, é recomendado não separar o conteúdo estrutural do conteúdo informacional. d) Todo e qualquer conteúdo não textual, tais como imagens, vídeos e áudios pré-gravados, devem possuir texto alternativo por meio da palavra chave alt, como, por exemplo, em <=”” li=”” style=”padding: 0px; margin: 0px; border: 0px;”> e) Quando o CAPTCHA é usado para se certificar que o acesso está sendo realizado por um humano e não por uma máquina, não se faz necessário quaisquer ajustes para melhorar a acessibilidade.

RESPOSTA: B

ANAC – Analista Administrativo – 2012 – CESPE

De acordo com o E-MAG 3.0, um sítio efetivamente acessível deve ser escrito com código listado nos padrões web internacionais definidos pelo W3C, ou seja, ele deve conformar-se com as normas HTML, XML e XHTML. No entanto, por não tratar de conteúdo, não é necessário que esteja em conformidade com a norma CSS. Certo ou Errado?

RESPOSTA: Errado

Para se criar um ambiente online efetivamente acessível é necessário, primeiramente, que o código esteja dentro dos padrões Web internacionais definidos pelo W3C.

Portanto, deve estar em conformidade com o CSS.

ANAC – Analista Administrativo – 2012 – CESPE

De acordo com o E-MAG 3.0, é fundamental declarar o DOCTYPE da página de qualquer documento HTML ou XHTML, dada a necessidade de os agentes de usuário, assim como as ferramentas de validação, identificarem a versão correta do documento (X)HTML utilizado pelo sítio. Certo ou Errado?

RESPOSTA: Certo

“É preciso declarar o DOCTYPE correto da página de qualquer documento HTML ou XHTML. O DOCTYPE define qual versão do (X)HTML o documento está usando e esta é uma informação fundamental para que os agentes de usuário processem corretamente o documento. Além disso, é por meio do DOCTYPE que as ferramentas de validação analisam o código da página e indicam correções.”

CGU – Analista de Finanças e controle (Desenvolvimento de Sistemas) – 2012 – ESAF

Segundo o Modelo de Acessibilidade do Governo Eletrônico (e-MAG), os passos para se desenvolver um sítio acessível são: a) Definir padrões customizados. Seguir as diretrizes ou recomendações de compatibilidade. Realizar a avaliação de acessibilidade. b) Seguir os padrões Web. Seguir as diretrizes ou recomendações de acessibilidade. Realizar a avaliação de acessibilidade. c) Seguir os padrões Web. Criar padrões de acessibilidade. Validar a acessibilidade. d) Seguir os padrões Web. Compatibilizar a acessibilidade com os recursos disponíveis. Projetar a atualização da acessibilidade e) Desenvolver padrões Web. Seguir as diretrizes ou recomendações de acessibilidade. Realizar a otimização da acessibilidade.

RESPOSTA: B

Seguir os padrões Web;
Seguir as diretrizes ou recomendações de acessibilidade;
Realizar a avaliação de acessibilidade.

CGU – Analista de Finanças e controle (Desenvolvimento de Sistemas) – 2012 – ESAF

Segundo o Modelo de Acessibilidade do Governo Eletrônico (e-MAG) os elementos que devem estar em todas as páginas do Governo Federal são: a) Teclas de atalho. Barra de usabilidade. Apresentação do mapa do sítio. Apresentação de formulário. Conteúdo para imagens de contexto. Apresentação de documentos. Identificação dos autores. b) Página com a descrição dos recursos de acessibilidade. Teclas de atalho. Barra de acessibilidade. Apresentação do mapa do sítio. Apresentação de formulário. Conteúdo alternativo para imagens. Apresentação de documentos. c) Página com a descrição dos recursos de acessibilidade. Teclas de controle de hardware. Barra de acessibilidade. Apresentação do mapa de localização da instituição. Apresentação de formulário. Conteúdo alternativo para atalhos. Apresentação de documentos. d) Teclas de instituições de apoio. Barra de portabilidade. Apresentação do mapa do sítio. Editores de formulário. Conteúdo alternativo para imagens. Apresentação de documentos. e) Página com a descrição dos motivos para acessibilidade. Teclas de atalho. Barra de interface. Apresentação do organizador do sítio. Apresentação de formulário. Conteúdo alternativo para imagens. Apresentação de atuadores.

RESPOSTA: B

Os elementos a serem padronizados, que devem estar presentes em todas as páginas do Governo Federal são:

Página com a descrição dos recursos de acessibilidade;
Teclas de atalho;
Barra de acessibilidade;
Apresentação do mapa do sitio;
Apresentação de formulário;
Conteúdo alternativo para imagens;
Apresentação de documentos.

FMP-RS – Auditor Público Externo – 2012 – FCC

Os padrões Brasil e-gov são recomendações de boas práticas agrupadas em formato de cartilhas com o objetivo de aprimorar a comunicação e o fornecimento de informações e serviços prestados por meios eletrônicos pelos órgãos do governo federal. Qual cartilha se preocupa com o estudo e a aplicação de técnicas que proporcionem a facilidade de navegação em um site web buscando assegurar que qualquer pessoa consiga utilizá-lo e que este funcione de forma esperada? a) Cartilha de codificação. b) Cartilha de administração. c) Cartilha de usabilidade. d) Cartilha de redação web. e) Cartilha de desenho e arquitetura de conteúdo.

RESPOSTA: C

FMP-RS – Auditor Público Externo – 2012 – FCC

Qual das assertivas é verdadeira a respeito das recomendações do programa de Governo Eletrônico (e-gov)? a) O guia de administração de sítios veda qualquer contração de equipe externa de desenvolvimento e hospedagem exceto quando realizados por dispensa de licitação seguindo os procedimento de instrução normativa própria. b) A definição de sítio promocional corresponde a um sítio de grande complexidade e com serviços agregados. c) O indicador de maior peso utilizado no processo de avaliação de serviços e-gov é o de “Transparência”. d) O código deve ser desenvolvido seguindo o modelo de quatro camadas: conteúdo, apresentação, comportamento e armazenamento. e) O guia de codificação recomenda a separação entre a forma e o conteúdo, em que a forma e a cor devem ser criadas de folhas de estilo.

RESPOSTA: E

Código em camadas: Desenvolver seguindo os padrões web significa utilizar as linguagens seguindo os objetivos para a quais elas foram desenvolvidas. Dessa forma o código é organizado em camadas, a saber: conteúdo, apresentação e comportamento.

TRT 6ª Região – Técnico Judiciário – 2012 – FCC

Na construção ou adaptação de conteúdos do Governo Brasileiro na Internet há um conjunto recomendado de diretrizes de acessibilidade que inclui a) fornecer conteúdo exclusivamente gráfico e de fácil compreensão para prender a atenção do usuário. b) fornecer conteúdo legível e compreensível apenas com as formatações originais. c) dar preferência às tecnologias gráficas como Flash e Silverlight. d) assegurar que toda a informação seja interpretada corretamente, com clareza e simplicidade. e) construir o site funcional apenas para as últimas versões dos principais navegadores.

RESPOSTA: D

Errada! Não exclusivamente gráfico, mas texto, audios, videos e etc.
Errada! A informação deve ser legível e compreensível em diferentes formatos (Navegado, celular, tablets e etc).
Errada! Flash e Silverlights, geralmente, não são acessiveis.
Correta!
Errada! Sites deve ter suporter a multiplos navegadores independente de sua versão.

TRT 6ª Região – Técnico Judiciário – 2012 – FCC

O Decreto nº 5.296/2004, Art. 8º, inciso II, define como barreiras: qualquer entrave ou obstáculo que limite ou impeça o acesso, a liberdade de movimento, a circulação com segurança e a possibilidade de as pessoas se comunicarem ou terem acesso à informação. Segundo o Decreto, essas barreiras podem ser classificadas, entre outras, como a) públicas e privadas. b) urbanísticas e nas edificações. c) permanentes e móveis. d) internas e externas. e) de limitação de mobilidade e de limitação de interatividade.

RESPOSTA: B

De acordo com o decreto, Art. 8º , inciso II essas barreiras podem ser classificadas como:

barreiras urbanísticas: as existentes nas vias públicas e nos espaços de uso público;
barreiras nas edificações: as existentes no entorno e interior das edificações de uso público e coletivo e no entorno e nas áreas internas de uso comum nas edificações de uso privado multifamiliar;
barreiras nos transportes: as existentes nos serviços de transportes; e
barreiras nas comunicações e informações: qualquer entrave ou obstáculo que dificulte ou impossibilite a expressão ou o recebimento de mensagens por intermédio dos dispositivos, meios ou sistemas de comunicação, sejam ou não de massa, bem como aqueles que dificultem ou impossibilitem o acesso à informação;

TRT 6ª Região – Técnico Judiciário – 2012 – FCC

Analise o texto: A Web é, fundamentalmente, projetada para funcionar para todas as pessoas, independentemente do hardware, software, língua, cultura, localização, ou capacidade física ou mental do usuário. Quando a Web atende a esse objetivo, é acessível a pessoas com deficiência auditiva, de movimento, visão etc. A W3C publica um documento padrão destinado, entre outros, a desenvolvedores Web, que explica como tornar o conteúdo Web mais acessível à pessoas com deficiência. A versão 2.0 desse documento tem 12 diretrizes que estão organizadas em quatro princípios: perceivable, operable, understandable e robust. O documento citado no texto é o a) Web Accessibility Initiative (WAI). b) Accessible Rich Internet Applications (WAI-ARIA). c) Web Content Accessibility Guidelines (WCAG). d) Authoring Tool Accessibility Guidelines (ATAG). e) User Agent Accessibility Guidelines (UAAG).

RESPOSTA: C

Correios – Analista de Correios (Analista de Sistemas) – 2011 – CESPE

Com relação aos sistemas de suporte a decisão e gestão de conteúdo, julgue os seguintes itens. As recomendações de nível de prioridade 1 do e-MAG referem-se às exigências básicas de acessibilidade; se essas exigências não forem cumpridas, grupos de usuários ficam impossibilitados de acessar as informações. As recomendações de nível 2 garantem as informações do documento, e as de nível 3 facilitam o acesso aos documentos armazenados na Web. Certo ou Errado?

RESPOSTA: Certo

Porém a questão está desatualizada, segundo o E-Mag 3.0:

“… Outra decisão foi o abandono dos níveis de prioridade A, AA e AAA, visto que o padrão é voltado as páginas do Governo, não sendo permitido exceções com relação ao cumprimento das recomendações.”

Ou seja, a versão 3 do e-MAG abandonou a abordagem por níveis por entender que todas as recomendações são importantes e devem ser seguidas.

Correios – Analista de Correios (Analista de Sistemas) – 2011 – CESPE

Com relação aos sistemas de suporte a decisão e gestão de conteúdo, julgue os seguintes itens. Para o processo de avaliação de conformidade, o e-MAG recomenda apenas a utilização de programas validadores de acessibilidade automáticos, a fim de se evitarem possíveis erros humanos. Certo ou Errado?

RESPOSTA: Errado

São 3 fases:

1ª validação automática com programas;
2ª validação humana com técnicos por meio de um plano de testes dirigido e planejado;
3ª validação humana com portadores de deficiência de forma aleatória e não dirigida.

Correios – Analista de Correios (Analista de Sistemas) – 2011 – CESPE

Com relação aos sistemas de suporte a decisão e gestão de conteúdo, julgue os seguintes itens. O modelo de acessibilidade de governo eletrônico (e-MAG) consiste em um conjunto de recomendações a ser considerado no desenvolvimento de portais e sítios eletrônicos da administração pública, a fim de garantir, a pessoas com necessidades especiais, o pleno acesso aos conteúdos disponíveis. Certo ou Errado?

RESPOSTA: Certo

TCE-PR – Analista de Controle – 2011 – FCC

O Modelo de Acessibilidade em Governo Eletrônico compreende recomendações ou diretrizes que visa tornar o conteúdo Web acessível a todas as pessoas. É INCORRETO afirmar que dentre estas recomendações está a de a) utilizar corretamente os níveis de cabeçalho. b) não utilizar redirecionamento automático de páginas. c) ordenar de forma lógica e intuitiva a leitura e tabulação. d) garantir que os objetos programáveis sejam inacessíveis. e) não utilizar tabelas para diagramação.

RESPOSTA: D

Recomendação 10 – Garantir que os objetos programáveis sejam acessíveis: Deve-se garantir que scripts, Flash, conteúdos dinâmicos e outros elementos programáveis sejam acessíveis. Se não for possível que o elemento programável seja diretamente acessível, deve ser fornecida uma alternativa em HTML para o conteúdo. Assim, é preciso garantir que o conteúdo e as funcionalidades de objetos programáveis sejam acessíveis aos recursos de tecnologia assistiva e que seja possível a navegação por teclado.

TRT 23ª Região – Analista Judiciário – 2011 – FCC

Para os fins de acessibilidade, o Decreto nº 5.296/2004, considera qualquer entrave ou obstáculo existente nas vias públicas e nos espaços de uso público são denominadas barreiras a) urbanísticas. b) nas edificações. c) nos transportes. d) nas informações. e) nas comunicações.

RESPOSTA: A

TRE-AP – Técnico Judiciário – 2011 – FCC

Em relação às recomendações da W3C para utilização de Web Standards é correto afirmar: a) Desenho vetorial deve ser evitado. b) O documento HTML deve restringir-se a conteúdo e apresentação visual. c) O princípio básico dos web stardards é separar informação e formatação. d) A exibição de cores deve ser obtida, preferencialmente, através do uso de tecnologia RGB. e) Resource Description Frameworks devem ser evitados.

RESPOSTA: C

CVM – Analista de Sistemas – 2010 – ESAF

Segundo o Decreto n. 5.296, de 02 de dezembro de 2004, a) Art. 55. Caberá aos órgãos e entidades da administração pública, … , promover a capacitação de profissionais em WEBSIGN. b) Art. 47. … será obrigatória a acessibilidade nos programas e sítios eletrônicos da administração pública na rede mundial de computadores (internet), para o uso das pessoas portadoras de deficiência física, … . c) Art. 47. … será obrigatória a acessibilidade nos portais e sítios eletrônicos da administração pública na rede mundial de computadores (internet), para o uso das pessoas portadoras de deficiência visual, … . d) Art. 47. … será obrigatória a usabilidade nos portais e sítios eletrônicos da administração pública na rede mundial de computadores (internet), para o uso das pessoas portadoras de deficiência auditiva, … . e) Art. 55. Caberá aos órgãos e entidades da administração pública e privada, … , promover a capacitação de profissionais de organizações não-governamentais em LIBRAS

RESPOSTA: C

Os artigos falam:

CVM – Analista de Sistemas – 2010 – ESAF

O CSS é a) o padrão MVC para modificação da representação audiovisual para as páginas web. b) o padrão W3C de definição da apresentação visual para as páginas web. c) o mesmo que cascading spread system. d) o agente de definição da programação de páginas web. e) o componente WMW de gestão de páginas de monitoramento.

RESPOSTA: B

DPE-SP – Agente de Defensoria – 2010 – FCC

No contexto do e-MAG – Modelo de Acessibilidade de Governo Eletrônico, considere: A padronização do layout, ou seja, um mesmo estilo de apresentação em cada página permite aos usuários encontrar facilmente os botões de navegação, assim como, procurar o conteúdo anterior em cada página. Enquanto isto ordena logicamente, resulta em grande benefício para pessoas com incapacidade de leitura e aprendizagem. Torna também previsível a localização da informação necessária em dada uma das páginas, maximizando desta forma sua localização. O texto acima refere-se à recomendação e-MAG a) 1.9 – Utilizar a linguagem mais clara e simples possível, logicamente, adequada ao conteúdo do sítio. b) 1.10 – Utilizar os mecanismos de navegação de maneira coerente, consistente e sistemática. c) 1.6 – Organizar os documentos de tal forma que possam ser lidos sem recurso à folhas de estilo. d) 1.8 – Criar uma sequência lógica de tabulação para percorrer links, controles de formulários e objetos. e) 2.5 – Não utilizar marcações para redirecionar as páginas automaticamente, até que os leitores de tela ou navegadores do usuário possibilitem interromper o processo.

RESPOSTA: B

BACEN – Analista de Sistemas – 2010 – CESGRANRIO

Analise o fragmento HTML abaixo. <img src=http://www.exemploxyz.com.br/destaques/bportal/image width=”120″ height=”60″ alt=”” /> Considerando-se as recomendações de acessibilidade para sites do governo brasileiro na Internet, o fragmento é problemático porque (A) apresenta imagens em formatos desproporcionais. (B) disponibiliza links em elementos gráficos ou sonoros. (C) possui uma URL absoluta, em vez de relativa. (D) não está adequado para apresentação em dispositivos móveis. (E) não apresenta um equivalente textual para a imagem.

RESPOSTA: E

O atributo ALT está em branco, caso a imagem não possa ser disponibilizada para um dispositivo, ou algum leitor de tela utilizado para deficientes visuais, a imagem não poderá ser compreendida.

BACEN – Analista de Sistemas – 2010 – CESGRANRIO

Considere o seguinte código HTML. Linha: 01 <html lang=”pt-br”> 02 <script language=”JavaScript” type=”text/javascript”> 03 function janela() {alert(“Cadastre-se e ganhará um brinde!”);} 04 </script> 05 <body> 06 <img src=”carro.jpg” longdesc=”carro.html” alt=”Carro amarelo.”><br> 07 <a href=”javascript:janela()”>Cadastres-se</a> 08 <form method=”post” action=”home.htm”> 09 Qual o seu nome? <br> 10 <input type=”text” name=”tbin” tabindex=”1″ size=”20″><br> 11 Escolha a cor do carro?<br> 12 <input type=”checkbox” name=”cb1″ value=”cb1″ tabindex=”2″>Azul<br> 13 <input type=”checkbox” name=”cb1″ value=”cb1″ tabindex=”3″>Verde<br> 14 <input type=”submit” value=”enviar” tabindex=”4″> 15 </form> 16 </body> 17 </html> Na cartilha técnica intitulada Recomendações de Acessibilidade para a Construção e Adaptação de Conteúdos do Governo Brasileiro na Internet, as recomendações de Nível de Prioridade 1 referem-se às exigências básicas de acessibilidade, tratando-se de pontos em que os criadores e adaptadores de conteúdo Web devem satisfazer inteiramente. Caso não sejam cumpridos, grupos de usuários ficarão impossibilitados de acessar as informações do documento. Qual das linhas do código HTML acima fere as recomendações de Nível de Prioridade 1? (A) 1 (B) 6 (C) 7 (D) 10 (E) 14

RESPOSTA: C

Caso o navegador do usuário não tenha o JavaScript habilitado ele não poderá acessar a informação. Além disso, o javascript quebra a sequencia da leitura da página, principalmente para leitores de tela, pois o texto estará presente ema caixa de dialogo e não junto ao resto da página.

O Tabindex é uma recomendação feita, uma vez que deficientes visuais navegam através de teclado e não por uso do mouse.

BACEN – Analista de Sistemas – 2010 – CESGRANRIO

No projeto de interfaces, as mensagens ou alertas de erro representam um papel muito importante. Assim, NÃO apresenta uma prática adequada para alertas produzidos por um sistema interativo a mensagem que: (A) descreve o problema em um jargão que o usuário possa entender. (B) fornece sugestão construtiva para recuperação do erro. (C) indica quais as consequências negativas do erro, de modo que o usuário possa se assegurar de que elas não ocorreram. (D) é acompanhada por uma indicação audível ou visual. (E) é opinativa, colocando a culpa no usuário caso isso ocorra.

RESPOSTA: E

Questão que não merece nem comentário.

BACEN – Analista de Sistemas – 2010 – CESGRANRIO

Acessibilidade na web significa que pessoas com algum tipo de deficiência podem usar a web. Mais especificamente, estas pessoas com deficiência podem perceber, entender, navegar e interagir, além de poderem contribuir com a produção de conteúdo. Esta necessidade é tão relevante, que o consórcio W3C criou um grupo para discutir iniciativas sobre a questão da acessibilidade na web. Este grupo define 4 princípios para acessibilidade. Relacione as características dos princípios com seus significados ou uso. I – Perceptível II – Operável III – Compreensível IV – Robusto P – Existe descrição textual para as imagens da página. Q – O site é criado maximizando a compatibilidade com a tecnologia assistiva presente e futura. R – Evita que o usuário cometa erros, corrigindo e apresentando-os. S – Toda as funções podem ser acessadas pelo teclado; o mouse é opcional. T – Desabilita algumas funções do site por segurança em função do grau de deficiência do usuário. Estão corretas as associações: A) I – P , II –S , III – R , IV – Q. B) I – P , II – T , III – P , IV – Q. C) I – Q, II –R , III – P , IV – T. D) I – Q, II –S , III – R , IV – T. E) I – R, II –S , III – P , IV – T.

RESPOSTA: A

BACEN – Analista de Sistemas – 2010 – CESGRANRIO

No que tange à usabilidade, acessibilidade e interoperabilidade em sistemas Web, são fornecidas as seguintes afirmativas: I – Serviços Web (Web Services) permitem a interoperabilidade entre aplicações Web, mesmo que essas aplicações tenham sido desenvolvidas com linguagens de programação diferentes. II – Testes de usabilidade são projetados por uma equipe de engenharia da Web e conduzidos por usuários finais. III – Um entrave para a produção de sistemas Web de boa acessibilidade é o fato de que estes normalmente se tornam mais difíceis de serem utilizados por usuários sem alguma deficiência. É correto APENAS o que se afirma em (A) I. (B) III. (C) I e II. (D) I e III. (E) II e III.

RESPOSTA: C

A alternativa I está correta, a II nem tanto. Testes de usabilidade são projetados por uma equipe da web e conduzidos COM usuários finais. Afinal, eles participam dos testes, porém os testes devem ser conduzidos por engenheiros e os usuários apenas participando. Porém, a banca considerou esta alternativa como certa.

MPU – Analista de Informática – 2010 – CESPE

A W3C define quatro princípios que constituem a base da acessibilidade na Web: perceptível, operável, compreensível e robusto. Certo ou Errado?

RESPOSTA: Certo

Perceptível: Disponível aos sentidos (visão e ouvindo principalmente) tanto através do uso de browser ou pelas tecnologias de assistência a deficientes (por exemplo leitores de tela, ampliadores de tela, etc.)
Operacional: Os usuários podem utilizar todos os controles e elementos com interatividade usando um mouse, teclado, ou um artifício de assistência ao deficiente.
Compreensível: O conteúdo deve estar descrito com clareza, limitando a confusão e ambiguidade.
Robusto: Um vasto leque de tecnologias (incluindo os antigos e os novos Browsers de usuários e as tecnologias de assistência a deficientes) podem ter acesso ao conteúdo. Estas primeiras letras destes quatro princípios o acrônimo POUR (em inglês). Este acrônimo pode ajudar a lembra-se deles.

MPU – Analista de Informática – 2010 – CESPE

As diretrizes técnicas de acessibilidade de governo eletrônico definem uma ordem de implementação das recomendações de acordo com a percepção do resultado. Certo ou Errado?

RESPOSTA: Errado

MPU – Analista de Informática – 2010 – CESPE

Se o conteúdo de um sítio é apresentado de modo a permitir que os agentes de usuário, incluindo as tecnologias de apoio, possam obter e apresentar a informação aos usuários de diferentes maneiras, diz-se que o sítio é determinado de forma programática. Certo ou Errado?

RESPOSTA: Certo

De acordo com o glossário do documento “Recomendações de Acessibilidade para Conteúdo Web (WCAG) 2.0”:

Determinado de forma programática (determinável de forma programática): determinado pelo software a partir de dados fornecidos pelo autor, de forma a que os diferentes agentes de usuário, incluindo tecnologias assistivas, possam extrair e apresentar esta informação aos usuários de diferentes maneiras.

Exemplo 1: Determinado numa linguagem de marcação a partir de elementos e atributos que são acessados diretamente através de tecnologias assistivas normalmente disponíveis.

Exemplo 2: Determinado a partir de tecnologias especificas de estrutura de dados numa linguagem que não é de marcação e exposta a tecnologia assistiva através de uma API de acessibilidade que é suportada por tecnologia assistiva normalmente disponível.

Petrobrás – Analista de Sistemas – 2010 – CESGRANRIO

A User Agent Accessibility Guidelines 2.0 (UAAG 2.0) é parte de uma série de boas práticas sobre acessibilidade publicada pelo W3C Web Accessibility Initiative (WAI) e preconiza que web sites devem ser acessíveis para pessoas portadoras de necessidades especiais. Qual das alternativas a seguir está de acordo com a construção de sistemas Web mais acessíveis para uma faixa maior de pessoas com tais necessidades? (A) Usar código em JavaScript no lado cliente para implementar a navegação entre páginas HTML. (B) Usar cores para enfatizar elementos em partes menos visíveis de uma página HTML. (C) Restringir o conteúdo alternativo ao mínimo possível na construção das páginas HTML. (D) Testar o acesso às páginas HTML em um navegador (browser) com acesso em modo textual. (E) Organizar tabelas das páginas HTML para que cada tabela possa ser lida em uma coluna por vez.

RESPOSTA:

A alternativa A é um problema, pois a utilização de JavaScript pode quebrar a lógica da página, e não pode ser lido por leitores de tela.

A alternativa B apesar de ser um técnica útil, para pessoas com problemas visuais é algo inútil.

A alternativa C está incorreta pois qualquer conteúdo deve ter uma alternativa em texto, seja ele imagem, áudio, ou vídeo.

A alternativa D é uma boa recomendação.

A alternativa E está incorreta, na verdade as tabelas devem ser organizada de forma que a leitura seja facilitada por um leitor de tela. Ou seja, para que cada tabela possa ser lida em uma linha por vez.

TCU – Auditor Federal de Controle Externo – 2010 – CESPE

De acordo com o referido modelo, toda figura não decorativa apresentada ao usuário final nas páginas em navegadores deverá possuir valor não nulo para o atributo ALT da tag IMG. O valor desse atributo deverá ser preciso e representar textualmente o conteúdo da figura. Deve-se usar ou poucas palavras ou uma frase curta; deve-se iniciar com o texto “Imagem de (…)”, “Gráfico de (…)” ou “Foto de (…)” quando se tratar de uma imagem, um gráfico ou uma fotografia, respectivamente; deve-se fazer referência ao sistema de navegação global do sítio. Certo ou Errado?

RESPOSTA: Errado

“Não iniciar o texto alternativo com “imagem de…”, “gráfico de…” ou “foto de…” para descrever a imagem. É desnecessária e redundante a informação de que aquele conteúdo apresentado é uma imagem”.

Além disso toda imagem deve apresentar o conteúdo ALT.

“Toda a imagem deve ter o atributo ALT mesmo que vazio ou nulo isto é um requisito dos padrões web. Imagens sem o atributo ALT são inacessíveis. Quando os leitores de tela encontram uma imagem sem o atributo ALT eles extraem a informação de outro lugar – como o nome do arquivo da imagem, suas dimensões ou sua localização – dados que não representam a função e conteúdo da imagem.”

TRE-RS – Analista Judiciário – 2010 – FCC

A W3C publica documentos que definem as tecnologias web. Estes documentos seguem um processo destinado a promover o consenso, justiça, responsabilidade pública e qualidade. No final deste processo, a W3C publica recomendações, que são consideradas como padrões web. A recomendação que apresenta as diretrizes que explicam como tornar o conteúdo Web acessível a pessoas com deficiência é a a) Web Content Accessibility Guidelines (WCAG). b) Web Accessibility Initiative (WAI). c) Authoring Tool Accessibility Guidelines (ATAG). d) User Agent Accessibility Guidelines(WAG). e) WebCGM.

RESPOSTA: A

TRE-RS – Analista Judiciário – 2010 – FCC

Web standards são padrões para a construção de sites determinados pelo W3C. Nesse contexto, considere: I. O HTML deve ser usado como padrão de linguagem de marcação e conter tags otimizadas que integrem as fases de programação e design. II. O HTML deve ser usado com a finalidade para a qual foi criado, ou seja, o documento HTML só deve ter conteúdo e não apresentação visual. III. A apresentação visual deve ser toda formatada através de CSS, permitindo, dessa forma, que as fases de design e programação ocorram em paralelo, reduzindo o tempo de produção. IV. HTML estruturado da maneira recomendada pelo W3C traz como um dos benefícios, a indexação em mecanismos de busca inteligentes, melhor realizada. É correto o que se afirma SOMENTE em a) I e III. b) I e IV. c) II e IV. d) I, III e IV. e) II, III e IV.

RESPOSTA: E

TRT 21ª Região – Analista Judiciário – 2010 – CESPE

As recomendações da e-mag incluem a identificação do idioma na tag ‹HTML›; a criação de sequência lógica de tabulação por meio da palavra-chave “tabindex” para elementos, como ‹button› e ‹select›; a informação sobre imagem, quando não decorativa, por meio do atributo “alt”, na tag ‹img›; e o resumo das tabelas de dados utilizando o atributo “summary”. Certo ou Errado?

RESPOSTA: Certo

Baseando-se na versão 3.0, ficaram assim as recomendações:

RECOMENDAÇÃO 16 – IDENTIFICAR O IDIOMA PRINCIPAL DA PÁGINA: Deve-se identificar o principal idioma utilizado nos documentos. A identificação é feita por meio do atributo lang do HTML e, para documentos XHTML, é utilizado o xml:lang.

RECOMENDAÇÃO 4 – ORDENAR DE FORMA LÓGICA E INTUITIVA A LEITURA E TABULAÇÃO: Deve-se criar o código HTML com uma sequência lógica de leitura para percorrer links, controles de formulários e objetos. Essa sequência é determinada pela ordem que se encontra no código HTML.

RECOMENDAÇÃO 20 – FORNECER ALTERNATIVA EM TEXTO PARA AS IMAGENS DO SÍTIO: Deve ser fornecida uma descrição para as imagens da página, utilizando-se o atributo alt. Imagens que não transmitem conteúdo, ou seja, imagens decorativas, devem ser inseridas por CSS.

RECOMENDAÇÃO 23 – EM TABELAS, UTILIZAR TÍTULOS E RESUMOS DE FORMA APROPRIADA: O título da tabela deve ser definido pelo elemento caption e deve ser o primeiro elemento utilizado após a declaração do elemento table. Em casos de tabelas extensas, deve ser fornecido um resumo de seus dados através do atributo summary que deve ser declarado no elemento table.

Penso que a questão ainda continuaria certa, mesmo com a nova versão do e-MAG

IPHAN – Analista (Tecnologia da Informação) – 2009 – Funiversa

Tomando como base o Decreto n. o 5.296, de 2 de dezembro de 2004, que contém recomendações de acessibilidade para a construção e adaptação de conteúdo do governo brasileiro na Internet, é correto afirmar que a) os sítios eletrônicos acessíveis às pessoas portadoras de deficiência conterão símbolo que represente a acessibilidade na rede mundial de computadores (Internet). b) os sítios eletrônicos acessíveis às pessoas portadoras de deficiência conterão link apontando para página com procedimentos a serem seguidos para prover a acessibilidade. c) será obrigatória a acessibilidade nos portais e sítios eletrônicos da administração pública na rede mundial de computadores (Internet), para o uso das pessoas portadoras de deficiência auditiva, no prazo de até doze meses a contar da data de publicação do Decreto n. o5.296. d) os sítios eletrônicos acessíveis às pessoas portadoras de deficiência visual conterão procedimentos no formato de arquivos de áudio. e) será obrigatória a acessibilidade nos portais e sítios eletrônicos da administração pública na rede mundial de computadores (Internet), para o uso das pessoas portadoras de qualquer tipo de deficiência, no prazo de até vinte e quatro meses a contar da data de publicação do Decreto n. o 5.296.

RESPOSTA: A

MEC – Arquiteto de Sistemas – 2009 – FCC

Analise o texto a seguir: “Consiste em um conjunto de recomendações a ser considerado para que o processo de acessibilidade dos sítios e portais do governo brasileiro seja conduzido de forma padronizada e de fácil implementação. É coerente com as necessidades brasileiras e em conformidade com os padrões internacionais. Foi formulado para orientar profissionais que tenham contato com publicação de informações ou serviços na Internet a desenvolver, alterar e/ou adequar páginas, sítios e portais, tornando-os acessíveis ao maior número de pessoas possível. Ele surgiu devido a uma exigência do decreto 5.296, publicado em dezembro de 2004, que torna obrigatória a acessibilidade nos portais e sítios eletrônicos da administração pública na rede mundial de computadores para o uso das pessoas com necessidades especiais, garantindo-lhes o pleno acesso aos conteúdos disponíveis.” O texto faz referência ao: a) e-PAC. b) e-CAC. c) e-CAP. d) e-PING. e) e-MAG.

RESPOSTA: E

É comum a confusão entre os padrões e-PING e e-MAG à primeira vista para leigos. Lembrar que, por definição, a arquitetura e-PING define um conjunto mínimo de premissas, políticas e especificações que regulamentam a utilização da TI e Comunicações na interoperabilidade de Serviços do Governo Eletrônico, estabelecendo condições de interação com demais Poderes e esferas do governo e com a sociedade em geral.

Vejam que a palavra-chave aqui é interoperabilidade; no caso do e-MAG trata-se de padrões de acessibilidade dos sítios e portais do governo brasileiro. A palavra-chave nesse último é acessibilidade.

TJ-SE – Técnico Judiciário – 2009 – FCC

O padrão web RSS definido pela W3C a) trata-se de uma estrutura e ferramentas de desenvolvimento de sites. b) foi escrito na linguagem Java e poderá ser lido por qualquer ferramenta RSS. c) apresenta uma maneira simplificada para os servlets se comunicarem com o servidor. d) possibilita que o conteúdo de cada site seja pesquisado pelo internauta por meio do RSS. e) disponibiliza todas as novas noticias capturadas dos sites pelo agregador de RSS.

RESPOSTA: E

A tecnologia do RSS permite aos usuários da internet se inscrever em sites que fornecem “feeds” RSS. Estes são tipicamente sites que mudam ou atualizam o seu conteúdo regularmente. Para isso, são utilizados Feeds RSS que recebem estas atualizações, desta maneira o utilizador pode permanecer informado de diversas atualizações em diversos sites sem precisar visitá-los um a um.

Os feeds RSS oferecem conteúdo Web ou resumos de conteúdo juntamente com os links para as versões completas deste conteúdo e outros metadados. Esta informação é entregue como um arquivo XML chamado “RSS feed”, “webfeed”, “Atom” ou ainda canal RSS.

Petrobrás – Analista de Sistemas Júnior – 2008 – Cesgranrio

Já em 1999, o W3C emitiu recomendações sobre acessibilidade de páginas Web em seu Web Content Accessibility Guidelines 1.0. Estas recomendações visam, em especial, a permitir que pessoas com algum tipo de deficiência possam utilizar as páginas, ainda que com dispositivos alternativos como leitores de tela. Entre os itens de acessibilidade a serem observados no projeto de sites e aplicações web, em geral, NÃO se inclui: a) evitar usar imagens para representar texto (em botões, por exemplo). b) evitar o uso de tabelas para fins de layout, a menos que façam sentido quando linearizadas. c) evitar usar elementos que piscam ou se movem na tela. d) abrir novas janelas para minimizar a necessidade do uso do botão Retornar do navegador. e) organizar o conteúdo das páginas de forma que possa ser lido sem folhas de estilo.

RESPOSTA: D

Recomenda-se que não se crie pop-ups ou mude de janela, pois isto pode ser desorientador para usuários que não conseguem ver que isso aconteceu.

TCU – Auditor Federal de Controle Externo – 2010 – CESPE

Uma ação correta para se atestar a aderência do mencionado CMS aos padrões de acessibilidade definidos pelo padrão e-Mag consiste em preparar o ambiente de testes de homologação do CMS para o uso da ferramenta de software Avaliador e Simulador para a Acessibilidade de Sítios (ASES), que está disponível gratuitamente a partir do portal de governo eletrônico do Brasil, funciona em versão desktop e, além de verificar se o conteúdo é acessível a portadores de catarata, miopia e daltonismo, avalia a conformidade com os padrões XHTML e HTML. Certo ou Errado?

RESPOSTA: Certo

ASES: Tendo por objetivo fornecer instrumentos que viabilizem a adoção da acessibilidade pelos órgãos do governo, o ASES – Avaliador e Simulador de Acessibilidade de sítios – é uma ferramenta que permite avaliar, simular e corrigir a acessibilidade de páginas, sítios e portais, sendo de grande valia para os desenvolvedores e publicadores de conteúdo.

Para os usuários brasileiros o programa é distribuído de forma gratuita sob licença LGPL – GNU Lesser General Public License.

Funcionalidades:

Avaliador de acessibilidade (e-MAG e WCAG);
Avaliador de CSS;
Avaliador de HTML (4.01 e XHTML);
Simuladores de leitor de tela (tempo) e Baixa visão (daltonismo, miopia, catarata);
Ferramenta para selecionar o DocType, conteúdo alternativo, associador de rótulos, links redundantes, corretor de eventos e preenchimento de formulários.

TJ-RO – Analista Judiciário – 2008 – Cesgranrio

O Modelo de Acessibilidade de Governo Eletrônico (e-MAG) possui como referência uma Cartilha Técnica com recomendações voltadas ao desenvolvedor de sítios (sites) e profissionais relacionados. As recomendações da Cartilha Técnica a) são de observância obrigatória para todas as entidades públicas e entidades de direito privado que se relacionem com o Governo. b) podem ser verificadas através de um software fornecido pelo Governo Eletrônico capaz de testar um sítio (site) quanto à acessibilidade e à aderência às recomendações da Cartilha. c) cobrem apenas tópicos específicos da realidade do Brasil, que não figuram nas recomendações de acessibilidade do W3C. d) sugerem, como alternativa ao uso de cores para destacar elementos da página, o uso de elementos que piscam, já que os mesmos são mais facilmente identificados por pessoas com deficiências visuais. e) sugerem que seja abolido o uso de frames HTML, pois as mesmas causam inúmeras dificuldades de navegação e são incompatíveis com softwares leitores de telas.

RESPOSTA: B

TJ-RO – Analista Judiciário – 2008 – Cesgranrio

Uma das recomendações de acessibilidade presentes na Cartilha Técnica do e-MAG diz respeito à indicação explícita da ordem de navegação/tabulação por elementos de um formulário, a qual pode ser especificada através do atributo HTML a) taborder b) navindex c) navorder d) tabindex e) formindex

RESPOSTA: D

Importante lembrar que no novo e-mag, a exigência do tabindex é apenas se for fundamental o uso, uma vez que o tabindex utilizado de forma incorreta pode desorganizar a navegação.

TRT 5ª Região – Analista Judiciário – 2008 – CESPE

A utilização de unidades relativas, e não absolutas, nos valores dos atributos de tabelas e textos, faz parte do conjunto de recomendações do nível de prioridade 1 do e-MAG, segundo o documento de referência v.2.0. Certo ou Errado?

RESPOSTA: Errado

Faz parte do nível de prioridade 2 do e-MAG.

Recomendação 2.2: Utilizar unidades relativas, e não absolutas, nos valores dos atributos de tabelas, textos, etc.

Lembre-se, o E-Mag 3 acabou com as prioridades por acreditar que todos os itens são importantes.

TCU – Analista de Controle Externo – 2007 – CESPE

As normas e recomendações de acessibilidade de nível 2 garantem o acesso às informações do documento e, se não forem cumpridas, grupos de usuários terão dificuldades para navegar e para acessar as informações do documento. Certo ou Errado?

RESPOSTA: Certo

TCU – Analista de Controle Externo – 2007 – CESPE

Para atender à recomendação de não utilizar marcações para redirecionar páginas automaticamente, a orientação da cartilha é de não se utilizar atributos meta-refresh e, sim, cabeçalhos http. Certo ou Errado?

RESPOSTA: Certo

RECOMENDAÇÃO 12 – NÃO UTILIZAR REDIRECIONAMENTO AUTOMÁTICO DE PÁGINAS

Não devem ser utilizadas marcações para redirecionar para uma nova página, como a meta tag refresh. Ao invés disso, deve-se configurar o servidor para que o redirecionamento seja transparente para o usuário. Para isso utiliza-se o cabeçalho HTTP 300 – Movido Permanentemente (301) ou Movido Temporariamente (302).

Polícia Federal – Perito Criminal Federal (Informática) – 2004 – CESPE

A facilidade de uso é uma das funções mais importantes do sistema. Certo ou Errado?

RESPOSTA: Errado

Facilidade de uso não é uma função do sistema. É uma característica que pode ser denominada como um requisito não funcional. Os seis requisitos não funcionais segundo Kirner são: Desempenho (Performance), Confiabilidade, Seguro, Segurança, Facilidade de uso, e Manutenibilidade.

Fonte: Kirner T.G. e Davis A .M. no livro: Nonfunctional Requirements of Real-Time Systems, da editora Advances in Computers, Vol 42 pp 1-37.