Padrão Acessibilidade Web-Nível Básico_v2.2
Transcrição
Padrão Acessibilidade Web-Nível Básico_v2.2
Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) Versão 2.2 N.B. / 2008 (Nota: Substitui a Versão 2.1 N.B. / 2008 ) Proposta elaborada em conjunto por: Sérgio Franco Brandão – Analista de TIC Consultor - UPP,Unidade de Prospecção e Padronização / ATI Marco Antônio de Queiroz – Especialista em Acessibilidade WEB, cego, construiu e mantém na Internet os sítios nacionais: “BengalaLegal & AcessibilidadeLegal” Antônio Muniz da Silva – Presidente atual da Associação Pernambucana de Cegos - APEC Organização deste documento. Este documento é constituído de um conteúdo abrangente, pois além da definição de critérios objetivos, métodos e técnicas para o estabelecimento de um Padrão de Acessibilidade WEB para o Governo PE, trata questões como Acessibilidade, Inclusão e Tecnologias Assistivas concernentes à Informação e Comunicação de produtos e serviços públicos do Estado, para todos os cidadãos pernambucanos, incluindo as Pessoas com Deficiência, e suas entidades representativas, conforme regulamentado em Leis próprias. Por isso foi organizado nas seguintes partes complementares: PARTE 1 - Introdução e Considerações Gerais; PARTE 2 - Resumo Didático e Orientação de Uso desta Recomendação; PARTE 3 - Requisitos para implementação de Acessibilidade WEB no Nível Básico; - Contém Lista Numerada de Tópicos, e Orientação detalhada para implementação de cada tópico. PARTE 4 - Requisitos para implementação de Acessibilidade WEB no Nível Intermediário; (Em construção.) PARTE 5 - Requisitos para implementação de Acessibilidade WEB no Nível Avançado; (Em construção.) PARTE 6 – Norma na íntegra da W3C / WAI – WCAG 1.0, como base para consulta de detalhamento aprofundado para a implementação dos Padrões de Nível Básico, Intermediário e Avançado; PARTE 7 – Instrumentos e ferramentas para verificação automática de Acessibilidade WEB, e/ou de apoio à construção de páginas e sítios WEB acessíveis; PARTE 8 – Legislação sobre Acessibilidade, Inclusão e Tecnologias Assistivas que respaldam a definição desta proposta de Padrão de Acessibilidade WEB para o Governo de Pernambuco, e outras referências; PARTE 9 – Fontes e Referências Bibliográficas; CONCLUSÃO Obs. Solicitamos aos leitores e usuários destas recomendações enviar suas críticas e sugestões, além de apontar qualquer erro encontrado à coordenação deste: Sérgio F.Brandão [email protected] e [email protected] Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 1 de 79 UPP – Unidade de Prospecção e Padronização PARTE 1 - Introdução e Considerações Gerais: Este documento publica recomendações de Nível Básico para implementação e manutenção de acessibilidade WEB, para páginas e sítios de Internet disponibilizados pelo Governo de Pernambuco, de produtos e serviços da Administração Pública e do Governo Estadual, para todos os cidadãos pernambucanos. Esta Versão 2.2 N.B. / 2008, Nível Básico, antecipa uma orientação técnica, que junto com as recomendações de Nível Intermediário e de Nível Avançado, a serem ainda publicadas, formará um todo indivisível que atualizará e substituirá a Versão 1.0, da primeira publicação feita pela UPP/ATI em março 2007 e se constituirá no novo Padrão de Acessibilidade WEB a ser adotado pelo Governo de Pernambuco. Do mesmo modo que a primeira versão, esta proposta deverá ser seguida de versões complementares, para incorporarem atualizações e melhorias técnicas, visando se adequar a novos requisitos legais sancionados depois de sua elaboração, sobre Acessibilidade, Inclusão e Tecnologias Assistivas, assim como procurar atender a demandas e sugestões oriundas de entidades representativas de-e-para pessoas com deficiência, que as legitimem. Diretrizes que orientaram a produção e uso desta Versão 2.2 N.B. / 2008 Foi solicitado pela direção da ATI, o particionamento do padrão de acessibilidade anteriormente proposto em três níveis, que estabelecesse uma gradação progressiva do custo e do esforço de desenvolvimento de Sítios e Páginas WEB Acessíveis a serem desenvolvidas, alteradas e/ou contratadas pelo Governo do Estado. Quanto ao formato foi também solicitada pela direção da ATI, para facilitar a leitura deste documento, a remoção das numerações de referência dos textos originais utilizados no início das linhas ao lado dos índices numéricos dos ítens, assim nesta versão 2.2 N.B. / 2008 as mesmas referências foram deslocadas, aparecendo entre colchetes '[ ]”, no final de cada parágrafo correspondente, ao invés de no início. Foi tomado com base principal o cumprimento da legislação brasileira sobre Acessibilidade, Inclusão e Tecnologias Assistivas para todos, em particular para as Pessoas com Deficiência e seus direitos, assim como os deveres do Estado para com os cidadãos do Brasil nesse sentido, considerando-se inclusive os prazos legais previstos. Foi considerado como critério prioritário para definição dos requisitos de Acessibilidade WEB exigidos, em cada Nível, o atendimento das necessidades fundamentais de acesso às informações e comunicação das pessoas com deficiência, tendo participação na escolha as representações de entidades das pessoas com deficiência e seus associados. Foram considerados também aspectos técnicos envolvidos no processo de construção e manutenção de páginas e sítios WEB atuais, buscando-se ordenar as etapas de implementação sempre que possível do mais simples para o mais complexo tanto para profissionais dos quadros do Governo PE como para serviços contratados. Por fim enfatiza-se que o particionamento do Padrão de Acessibilidade WEB nos níveis Básico, Intermediário e Avançado estabelece tão somente um roteiro para orientar e facilitar a implementação gradativa do Padrão Acessibilidade WEB Total, Universal e para Todos, conforme exigido por Lei, não Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 2 de 79 UPP – Unidade de Prospecção e Padronização devendo este documento ser tomado em hipótese alguma como permissão para uma Implementação parcial e truncada de Acessibilidade WEB para o Governo PE, ou de quem quer que seja. Assim chamamos a atenção de que esta versão 2.2 N.B. de Nível Básico, é apenas a liberação de uma primeira parte da Proposta de Padrão de Acessibilidade WEB para o Governo PE, que se encontra em construção, não sendo permitida a sua divulgação como documento completo, e nem como um documento final aprovado pelas representações das Entidades das Pessoas com Deficiência de Pernambuco, que são responsáveis legais pela cobrança e fiscalização do cumprimento da legislação sobre Acessibilidade e Inclusão no Estado. Assim, quaisquer definições condições e prazos para implementação das recomendações técnicas propostas neste documento, remetem a negociações diretas entre as Direções das Entidades Representativas das Pessoas com Deficiência e das Instituições governamentais responsáveis por essa implementação, conforme previsto por lei, para ambas, estando portanto fora do escopo deste documento o estabelecimento dessas condições e/ou prazos. Esclarecimentos e Agradecimentos sobre a elaboração em conjunto. Este documento foi elaborado em conjunto, contando com três participações, visando sua qualidade técnica, legitimidade e agilidade em produzí-lo. A) Este trabalho teve como seu organizador, elaborador e redator responsável, Sérgio Franco Brandão, Analista de Tecnologia da Informação Consultor, dedicado à Acessibilidade, Inclusão e Tecnologias Assistivas enquanto membro da Unidade de Prospecção e Padronização da Agência de Tecnologia da Informação do Estado de Pernambuco. B) Orientou tecnicamente este trabalho o Sr. Marco Antônio de Queiroz enquanto Consultor e Especialista em Acessibilidade WEB de referência Nacional. Sua participação deveu-se não só a sua experiência, competência e atualização técnica específica sobre o tema, ( ex-funcionário do SERPRO, desenvolveu e mantém os sítios WEB “Bengala Legal”, “Acessibilidade Legal”, e tem ministrado cursos de Acessibilidade WEB em diversos estados do Brasil), além de possuir a vivência específica enquanto usuário por ser também uma pessoa cega, o que confere ainda maior legitimidade às suas orientações técnicas. O mesmo dispôs-se a contribuir voluntariamente com este projeto, por uma articulação com a Associação Pernambucana de Cegos – APEC nesta etapa de elaboração do trabalho, e efetivamente contribuiu com: 1- O Estudo e crítica do documento produzido pela equipe da UPP/ATI, “Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco 2007” - Versão 1.0 - março / 2007; 2- Propôs atualizações, melhoramentos e sugeriu novas referências documentais para Acessibilidade WEB aplicáveis à construção do Padrão pretendido de acordo com a legislação vigente e técnicas mais atuais. 3- Indicou técnicas e softwares mais eficazes e eficientes para desenvolvimento, assim como para revisão automática de Acessibilidade de páginas e sítios WEB do Governo de PE e outros métodos. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 3 de 79 UPP – Unidade de Prospecção e Padronização 4- Disponibilizou e cedeu para produção deste documento, textos publicados e inéditos de sua autoria para serem integralmente inseridos neste trabalho, em especial dos sítios WEB de sua autoria, “BengalaLegal” e “AcessibilidadeLegal”. 5- Orientou tecnicamente o Analista Sérgio F.Brandão da UPP/ATI coordenador responsável por este trabalho, quanto à definição dos critérios para o estabelecimento das etapas e dos itens que constituirão os Níveis Básico, Intermediário e Avançado de implementação de Acessibilidade WEB para páginas e sítios do Governo de Pernambuco, (atendo-se no momento exclusivamente ao Nível Básico.) 6- Revisou os textos produzidos pela UPP/ATI, assim como aqueles produzidos sob sua orientação para produção deste documento sobre o Nível Básico. Frisamos que a Versão 2.2 N.B. / 2008 deste documento, não teria sido possível com a qualidade, legitimidade e no prazo demandado, (o qual foi antecipado em dois meses em relação ao previsto) sem a inestimável orientação abalizada e competente, assim como a dedicação do Sr. Marco Antônio de Queiroz para este projeto, pelo que nos sentimos na obrigação de lhe fazer aqui, um agradecimento especial. (Esperamos ainda poder negociar o seu apoio futuro para produção dos Níveis Intermediário e Avançado deste Padrão de Acessibilidade WEB para o Governo de PE, assim como para elaboração de metodologia e treinamento de técnicos e revisores de Acessibilidade WEB – Possivelmente através de Convênio a ser firmado entre a ATI e a APEC – já previsto no planejamento UPP/2008) C) Contou-se ainda com participação do Sr. Antônio Muniz da Silva, na qualidade de atual Presidente da Associação Pernambucana de Cegos – APEC, pessoa atuante e liderança influente no Segmento das Pessoas com Deficiência tanto em nível Estadual como Nacional; é membro de diversas entidades e conselhos de-e-para Pessoas com Deficiência, com um histórico de ocupação de cargos públicos tanto na esfera municipal como estadual, sempre em prol da luta pela Inclusão Social, empregabilidade, autonomia e qualidade de vida de todas as pessoas, e em especial das Pessoas com Deficiência. Profundo conhecedor da legislação brasileira e internacional sobre a Pessoa com Deficiência, é além disso exímio Braillista, e usuário cego (com baixa visão), assíduo e competente de computadores com programas e interfaces de Acessibilidade. Sua contribuição tem sido bem diversificada para este trabalho: 1- Demandou formalmente à ATI, em nome da APEC, que as páginas e sítios WEB do Governo de PE assim como os produtos e serviços públicos estaduais sejam Acessíveis, exercendo sua atribuição de cobrar e fiscalizar o cumprimento das leis de Acessibilidade e Inclusão , na qualidade de Presidente atual de Entidade Representativa de Pessoas com Deficiência; 2- Articulou com a coordenação deste trabalho na ATI, e apoiou a viabilização da consultoria técnica do Sr. Marco Antônio de Queiroz, já mencionada, imprescindível para realização deste trabalho. 3- Mobilizou os associados da APEC, e promoveu forum em que foram discutidas questões pertinentes ao desenvolvimento deste trabalho, tais como critérios de Acessibilidade e prazos, considerando tanto a legislação de Acessibilidade vigente, como os interesses do Segmento, que legitimam as escolhas e decisões aqui tomadas. 4- Forneceu informações, prontas e precisas sobre leis pertinentes, revisou o conteúdo e redação deste documento, articulou apoios outros de pessoas do Segmento, ou não, para este trabalho, e Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 4 de 79 UPP – Unidade de Prospecção e Padronização engajou-se pessoalmente tendo fornecido críticas e sugestões valiosas sobre Acessibilidade, por sua vivência enquanto usuário cego de computador. Critérios utilizados na definição do Nível Básico Foram considerados como critérios fundamentais nesta proposta: A observância da legislação que a obriga; a eficácia e eficiência da acessibilidade a ser obtida, a prioridade de implantação, a preferência pelo baixo custo dos recursos a serem empregados para sua obtenção e uso, a facilidade de implementação das mesmas, o alinhamento com os esforços precedentes de padronização oficiais adotados no Brasil em todas as esferas de governo, a especificidade local e regional, necessidades e prioridades demandadas pela APEC. Para isso procedeu-se inclusive a escuta de algumas pessoas com deficiências, dentre elas representantes de entidades, tais como a presidência da APEC (Associação Pernambucana de Cegos), membro do CONED (Conselho Estadual de Defesa dos Direitos da Pessoa com Deficiência, O Presidente do COMUD/Recife:(Conselho Municipal de Defesa dos Direitos da Pessoa com Deficiência.), tendo já a versão 2.0 N.B. deste documento sido citada e propostas algumas de suas recomendações, no Grupo de Acessibilidade, na Pré-Conferência Municipal da Pessoa com Deficiência do Recife, em 02/04/2008. Outras entidades e pessoas envolvidas com a questão, ainda deverão ser consultadas para a incorporação de novas medidas visando o aprimoramento e maior abrangência da acessibilidade a ser atingida tanto quantitativa quanto qualitativa, atendendo a uma diversidade mais ampla de pessoas com necessidades específicas. Considerou-se também a possibilidade da implementação de serviços de apoio à revisão e credenciamento das páginas web do governo do estado, os quais poderão vir a ser realizados de acordo com essas recomendações, por profissionais dos vários segmentos de pessoas com deficiências das diversas modalidades, através de convênios com suas respectivas entidades representativas. PARTE 2 - Resumo Didático e Orientação de uso desta Recomendação O objetivo deste resumo é introduzir o assunto, seus principais conceitos e dar uma uma orientação abrangente para facilitar a compreensão e implementação prática desta Recomendação como um todo. Conceituação de Acessibilidade: Acessibilidade Universal se obtém mediante a produção de conteúdos e a criação de meios para que todas as pessoas, sejam quais forem as suas diferenças biológicas, possam ter acesso a tudo que é público e disponibilizado para todos, informações, serviços, transportes, trabalho, lazer, etc., de modo autônomo e sem a necessidade de ajuda, e portanto sem a dependência, nem a intervenção de terceiros. Observa-se que o Conceito de Acessibilidade tem sido muito mal compreendido por diversas pessoas no Mundo, mesmo por muitas daquelas comprometidas e empenhadas em contribuir para sua viabilização, em específico no que se refere a atender às Pessoas com Deficiências, empregando erradamente energia em fazer objetos e conteúdos especiais, alternativos àqueles disponibilizados Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 5 de 79 UPP – Unidade de Prospecção e Padronização para todas as outras pessoas gerando um espaço dependência de segregação em um mundo à parte só para elas. Acessibilidade diz respeito a tornar locais, produtos, serviços ou informações efetivamente disponíveis ao maior número e variedade possível de pessoas independente de suas capacidades físico-motoras e perceptivas, culturais e sociais. Isto requer a eliminação de barreiras arquitetônicas, a disponibilidade de comunicação, de acesso físico, de equipamentos e programas adequados, de conteúdo e apresentação da informação em formatos alternativos. No que se refere a acesso à informação e à comunicação, produtos e serviços públicos disponibilizados através do uso de terminais informatizados (computador), identificamos cinco categorias principais de situações por parte de usuários com deficiência, que se encontram relacionadas a seguir: 1. Acesso a terminais informatizados (computador) sem mouse: pessoas com deficiência visual parcial ou total, (cegueira), com deficiência física de membro superior, ausência ou dificuldade de controle dos movimentos de braços e mãos, (paralisia, atrofia ou amputação). Tais pessoas sentem várias dificuldades na utilização do mouse; 2. Acesso a terminais informatizados (computador) sem teclado: pessoas com amputações, grandes limitações de movimentos ou falta de força nos membros superiores. Essas pessoas têm sérias dificuldades para utilizar o teclado tradicional. Nesses casos, a interação poderá ser feita através de um periférico especial de reconhecimento da fala, outros movimentos corporais, como os pés, os olhos, ou de um emulador de teclado na tela; 3. Acesso a terminais informatizados (computador) sem monitor: pessoas com deficiência visual total ou parcial acentuada (cegueira), assim como com deficiência física neurológica que afete o controle dos movimentos que permitam a leitura, recorrem programas (softwares) leitores de tela, que produzem saídas das informações em áudio, gerando uma leitura em voz sintetizada, daquilo que está sendo projetado na tela do vídeo permitindo a perfeita compreensão do conteúdo, pois na verdade a informação processada por um computador não é em si de natureza visual. Podendo ainda produzir uma saída em um terminal Braille, ou outro dispositivo de Tecnologia Assistiva adequado. 4. Acesso a terminais informatizados (computador) sem áudio: encontram-se relacionadas neste caso pessoas com deficiência auditiva, parcial ou total (surdez). Este grupo de usuários possui dificuldade em acessar determinadas informações que se encontram disponíveis somente através de dispositivos de áudio, além da necessidade de tradução para linguagem de sinais como LIBRAS ou SignWrite, etc. 5. Acesso a terminais informatizados (computador) sem dois ou mais desses recursos simultaneamente: pessoas com deficiências múltiplas, como auditiva e motora, ou visual e motora, ou ainda auditiva e visual (como pessoas surdocegas pós-lingüísticas), exigindo o emprego de tecnologias assistivas especiais para permitir a entrada e saída de informações e a comunicação necessárias, mas todas elas se apoiando e tendo como base principal os conteúdos e organizações com a Acessibilidade Universal proposta neste documento. As recomendações aqui propostas para acessibilidade de páginas web do Governo de Pernambuco abrangem três aspectos: 1. Garantir a acessibilidade de conteúdos para qualquer plataforma tecnológica obediente aos padrões de acessibilidade. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 6 de 79 UPP – Unidade de Prospecção e Padronização É a capacidade da página ser exibida por todos os programas de leitura de páginas web (browsers) que satisfaçam as normas e padrões atuais de tratamento de acessibilidade, sem perda de conteúdo ou funcionalidade. Atualmente os principais navegadores (browsers), das plataformas disponíveis mercado são: 1. Internet Explorer (para ambientes Windows) 2. Firefox (Software Livre para Linux pode também funcionar no Windows e MacOS) 3. Safari (Navegador para ambientes MacOS) As principais recomendações para que o conteúdo de uma página web possa ser exibido nesses três browser é que ele siga as orientações sintáticas da W3C para construção de páginas web. • Adoção de estrutura de código HTML ou XHTML com separação do conteúdo da apresentação através da utilização de CSS - Cascading Style Sheets, tecnologia usada para formatar documentos HTML, XML e XHTML; • Evitar o uso de objetos não HTML/XHTML nas páginas, tais como Flash, Applets Java e principalmente Active X; • Passar todas as páginas geradas por um validador sintático tal como o próprio da w3c que é acessível pelos links: Validador HTML/XHTML http://validator.w3.org/ e validador de CSS http://jigsaw.w3.org/css-validator/;(Ver Parte 7 Instrumentos e ferramentas para verificação auto...) • Proceder a avaliação das páginas web empregando pessoas com deficiência capacitadas e profissionalizadas para atuarem com revisores de acessibilidade web, para identificarem e recomendarem correções daquilo que não possa ser feito pelos softwares validadores automáticos. Apesar das recomendações acima, alguns browser não tem suporte completo ao padrão w3c, por este motivo é muito importante testar as páginas geradas para os principais navegadores de cada plataforma para garantir que o resultado gerado seja o mais aproximado possível. 2. Implementar uma boa Navegabilidade (Padronização da disposição dos elementos de texto, imagem e som nas telas web) Deve ser observada a necessidade de especificar-se um padrão de organização para navegação nas páginas do governo, que permita a qualquer usuário ou usuária encontrar facilmente onde estão disponibilizados e como utilizar os comandos que lhes possibilite encontrar e acessar as informações e serviços que procuram, preservando a disposição lógica de ícones, links, títulos e conteúdos texto dos mesmos de modo que o investimento desse usuário ou usuária em aprendizado para navegar em uma página do governo possa ser reutilizado na navegação em qualquer outra página web do governo, tornando-se assim facilmente reconhecíveis pelos mesmos todos serviços disponibilizados pelo Estado, independente do serviço, secretaria ou órgão que o usuário esteja acessando. 3. Apontar Requisitos para garantir a Acessibilidade para Pessoas com Deficiências. Define boas práticas para se possibilitar a inclusão de pessoas com quaisquer deficiências, permitindo seu acesso ao conteúdo web através de ferramentas de tecnologias assistivas, tais como leitores de tela e browses específicos para cegos, surdos ou pessoas com deficiências motoras; • Usar as recomendações selecionadas especialmente para Acessibilidade WEB em língua Portuguesa, feitas por especialista estudioso e prático na matéria, o Sr. Marco Antônio de Queiroz, que filtrou e orientou as especificação das etapas de Implementação de Nível Básico, Intermediário e Avançado deste documento, (Partes 3, 4 e 5 deste documento) baseadas na avaliação atualizada das melhores práticas Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 7 de 79 UPP – Unidade de Prospecção e Padronização e fontes sobre a Acessibilidade WEB, W3C/WAI/WCAG 1.0, Diretrizes Irlandesas NDA, ETC. • Usar a sintaxe e empregar uma semântica para os conteúdos em HTML/XHTML usando essa orientação. • A página pode ser validada através do site http://www.dasilva.org.br, (***) (***) Vide melhor orientação em: (PARTE 7 – Instrumentos e ferramentas para verificação automática de Acessibilidade WEB, e/ou de apoio à construção de páginas e sítios WEB acessíveis;) • Embora existam outras fontes e documentos que estão começando a ser publicadas, para auxiliar na elaboração de páginas acessíveis, como a especificação e-MAG, Modelo de Acessibilidade de Governo Eletrônico, e outras iniciativas que podem ser utilizadas, de forma complementar, mas ainda estarão sendo estudadas pela equipe que está recomendando este padrão. • Alerta-se quanto a conflitos de orientações ou publicações ainda não devidamente testadas e aprovadas pelo Segmento das Pessoas com Deficiência e Usuários específicos, (por exemplo o documento da própria W3C o WAI/WCAG 2.0 NÃO FOI APROVADO, continuando vigente sua versão WCAG 1.0 )pelo que sugerimos apenas consultá-las para apreender melhor uma técnica aqui recomendada, a não para implementação de abordagem alternativa, portanto com ressalvas. • Atenção para a não exclusão da pessoa com deficiência através da “duplicação” em separado de informação pública. O mesmo texto disponível ao público em geral deve apresentar recursos de acessibilidade numa base única para garantir à pessoa com deficiência o acesso ao mesmo conteúdo atualizado (idêntico) ao que for disponibilizado à todas as demais pessoas. (Desenho Universal) • Permitir telas em Alto contraste; • Além destes documentos técnicos existe uma legislação que deve ser seguida, citada na Parte 8 deste documento, e que deve ser também consultada pois possibilitará ao desenvolvedor conhecer os princípios e objetivos em que se baseiam essas recomendações tornando assim mais fácil a sua implementação. Alguns poucos Exemplos de recomendações técnicas sugeridas, amplamente detalhadas nas Partes 3, 4 e 5 deste documento. • Tornar as páginas sintaticamente válidas no padrão HTML/XHTML através das especificações do W3C e checar através de ferramentas disponíveis pelo W3C; • Tornar as páginas semanticamente válidas para a especificação WCAG; • Evitar o uso de images com textos e sempre que for necessário o uso de imagens colocar a descrição do seu significado no atributo "alt"; • Evitar o uso de objetos não HTML/XHTML nas páginas, tais como Flash, Applets Java e principalmente Active X; • Utilizar elementos de lista (Ex.: "lu" "lo" "li") para itens de menu; • Não usar imagens mapeadas; • Sempre permitir acesso aos elementos de um formulário através do teclado e também permitir o envio do mesmo pelo teclado; • Não usar fontes de tamanho fixo, permitindo que as mesmas sejam alteradas facilmente pelo usuário; Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 8 de 79 UPP – Unidade de Prospecção e Padronização • Não usar textos em formato de imagem, ou reproduzir tais textos integralmente na descrição da imagem em que aparece na tela. Orientação de uso desta Recomendação: Os Níveis para Implementação de Acessibilidade WEB propostos, Básico, Intermediário e Avançado, devem observar certos cuidados para que possam ser atingidos com sucesso: 1º Precisam ser necessariamente considerados como etapas sucessivas na Implementação de Acessibilidade WEB Universal para os Portais, Sítios e Páginas de disponibilização de produtos e serviços públicos oferecidos pelo Governo de Pernambuco. 2º Portanto, deve-se proceder a implementação de cada nível, antecipando que o mesmo será forçosamente sucedido do nível seguinte, assim é preciso cuidar para que a forma de implementação de um nível, não impacte sobre a implementação dos níveis seguintes. 3º Para isso estão incluídos nessa recomendação nas Partes 4 e 5, as diretrizes e requisitos mínimos que deverão orientar a definição dos Níveis seguintes: Intermediário e Avançado; Assim como como está incluída na Parte 6 a Norma da W3C, a WCAG 01 na íntegra, visando evitar implementações conflitantes com a evolução futura. 4º Recomenda-se fortemente a abordagem de construção e implementação de páginas WEB por camadas, tornando o Conteúdo a ser publicado uma camada independente da formatação de Apresentação do mesmo. Fazendo uso de folhas de estilo e CSS por exemplo. 5º Alerta-se cuidado na utilização de geradores automáticos, e outras tecnologias para construção de páginas, que são muito interessantes para permitir aos usuários finais, produzirem e publicarem seus próprios conteúdos na WEB, com flexibilidade e boa apresentação, sem ter a necessidade de recorrer à figura do técnico e programador WEB, pois: a) Tais geradores de páginas muitas vezes utilizam-se de linguagens de programação e técnicas que são incompatíveis com a implementação de Acessibilidade Universal para todos, e portanto devem ser evitados; Por outro lado, a tendência do usuário final poder produzir e publicar diretamente seus conteúdos é boa e em si, não é incompatível com a Acessibilidade Universal, assim; b) Recomenda-se que os WEB designers e construtores de páginas de Internet e Terminais de Auto-Atendimento, programem os formulários e campos que poderão ser diretamente selecionados e preenchidos por usuários finais com seus conteúdos, incluindo neles e tornando obrigatório o preenchimento dos ítens de Acessibilidade requeridos. 6º Para facilitar e tornar seguro o processo de implementação, adoção e migração de ferramentas e técnicas de construção, e se poder acompanhar evolução de Acessibilidade de Portais, Sites e Páginas WEB, ou Telas de Terminais de Auto-Atendimento, sugere-se a adoção de métodos de exportação dos conteúdos e dos respectivos formatos empregados, para arquivos portáveis de backup dos mesmos. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 9 de 79 UPP – Unidade de Prospecção e Padronização Seqüência sugerida para Validação da Acessibilidade e Promoção de Conformidade de Portais, Sítios e Páginas do Governo PE. Recomenda-se que o processo de avaliação de conformidade ocorra através de três (3) fases distintas. São elas: 1. Primeiramente, sugere-se que sejam utilizados programas validadores automáticos de acessibilidade para testarem as páginas web produzidas. Existem programas na Web 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. A maior parte dos programas trabalham com base no W3C/WAI, como o “Da Silva”, desenvolvido no Brasil, encontrado em http://www.acessobrasil.org.br (Vide melhores na Parte 7) Incorporamos à partir da versão 2.1 N.B. deste documento, validadores sugeridos e comentados nos sítios “Bengala Legal” e antecipadamente pelo “AcessibilidadeLegal” do Sr. Marco Antônio de Queiroz que recomenda diversos outros validadores (inclusive em Português) mais eficazes e eficientes, na Parte - 7 2. Depois, propõe-se que seja realizada uma validação humana, através da navegação pelo sítio com programas leitores de tela – realizada pelos técnicos desenvolvedores, que implementaram a Acessibilidade, através de um plano de testes dirigido e planejado para as especificidades dos requisitos desenvolvidos; 3. Por fim, sugere-se também que seja realizada uma outra validação humana através da navegação pelo sítio com programas leitores de tela; contudo, desta vez, feita por usuários com deficiências diversas, capacitados, profissionalizados e contratados como revisores de Acessibilidade, antecipando e reproduzindo de maneira fiel a situação real de utilização do sítio por usuários com deficiência.(De preferência indicados ou certificados por entidades de Pessoas com Deficiência.) Tanto a etapa 2. como a 3., deverão ser em breve normalizadas, para maior comodidade e uniformidade de validação de páginas Accessíveis produzidas pelo Governo de PE. Esta última sugestão preenche diversos aspectos desejáveis tanto políticos quanto técnicos, pois: ● Permite uma qualidade de revisão superior que não poderia ser realizada nem automaticamente nem tão pouco por uma única pessoa sem as diversas deficiências, conferindo assim uma qualidade melhor ao produto resultante quanto a sua acessibilidade universal. ● Possibilita dessa maneira a profissionalização e o emprego a pessoas com deficiência incluindo-as no mercado de trabalho de forma honrosa. ● Isenta o Governo de PE, e às instituições contratadas quanto à Acessibilidade de seus produtos e serviços públicos disponibilizados e entregues ao povo de Pernambuco. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 10 de 79 UPP – Unidade de Prospecção e Padronização PARTE 3 – Requisitos para implementação de Acessibilidade WEB no Nível Básico. O particionamento da implementação da Acessibilidade WEB nos três níveis complementares X , inseparáveis, Básico, Intermediário e Avançado, (vide Diretrizes na Parte -1 ), foi planejado para estabelecer uma gradação no processo de implementação de Páginas e Sítios WEB para o Governo PE e a satisfazer aos critérios explicitados nos itens “Requisito de Nível X – Critérios” Requisitos Nível Básico – CRITÉRIOS Satisfazer às necessidades mais prementes de Acessibilidade WEB para todos os usuários, incluindo as Pessoas com Deficiência, os recursos atuais de Tecnologias Assistivas, a Experiência e Demanda encaminhada pelos especialistas técnicos, usuários de computadores com Deficiência, assim como a Legislação Vigente sobre o assunto. Requisitos Nível Básico – ÍNDICE DE TÓPICOS NUMERADOS - Números entre “ [ ] ” no final de parágrafo são referências aos textos originais: Diretrizes Irlandesas, WCAG 1.0, etc. - Ver detalhamento e recomendações mais adiante. - “ * “ após a numeração Indicam maior ênfase no tópico. Orientação especial, sugerida pelo Sr. Marco Antônio de Queiroz 0)* Saltos são fundamentais para navegação acessível: Seleção tomando por base as Diretrizes Irlandesas de Acessibilidade Extraídas do Site Bengala Legal do Sr. Marco Antônio de Queiroz Obs. Os comentários ((entre parênteses duplos)), foram acrescidos pelos autores deste documento. 1)* - Fornecer um texto equivalente para cada elemento não textual. [1.1] 2)* Garantir que as informações não se baseiem na percepção de cores. ((nem em outros elementos estritamente visuais)) [1.2] 3)* Evitar o tremido na tela / Evitar que o conteúdo fique piscando. - ((i.e. lampejos luminosos intensos e repetitivas em determinadas faixas de freqüência, pois seqüências de flashes em intervalos superiores a 2 por Segundo, em torno de 1 por segundo entre si, como efeitos estroboscópicos, podem deflagrar ataques epilépticos em pessoas foto sensíveis.)) [1.3 / 2.2 – 1.3] 4) Fornecer uma descrição auditiva das informações visuais nas apresentações multimídia. / Para multimídia, assegurar que o tempo das descrições alternativas estejam sincronizadas com a apresentação. -((Fornecer uma descrição auditiva das informações visuais nas apresentações multimídia sincronizada com a exibição dos textos e imagens correspondentes. )) [1.4 / 1.5 - 1.4 ] 5) Utilizar a linguagem apropriada mais clara e simples [1.6 ] 6) Para tabelas de dados, identifique sempre os cabeçalhos de linhas e colunas. ((uma tabela não deve servir para formatar um layout de página)) [1.9] 7)* Para tabelas de dados complexas, use marcação (mark-up) para associar células de dados e células de cabeçalhos. [1.10] 8)* Adicione títulos a frames (quadros). ((evitar frames sempre que possível)) [1.11] 9) Certifique-se de que os documentos possam ser lidos sem folhas de estilo (style sheets). [1.12] Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 11 de 79 UPP – Unidade de Prospecção e Padronização 10) Forneça links de texto para emular mapas de imagem do servidor. ((quando houver vários links na mesma imagem))[1.13] 11) Onde possível, use mapas de imagens do cliente ao invés de mapas de imagens do servidor. [1.14] 12)* Certificar-se de que os scripts e applets que forneçam a única fonte de funcionalidade importante sejam diretamente acessíveis ou compatíveis com tecnologias assistivas ((funcione com e sem script)) [1.15] 13)* Certifique-se de que as imagens tenham contraste suficiente para as pessoas com deficiência cromática na visão [2.1] 14) Evite movimento no conteúdo.[2.3] 15)* Certifique-se de que o conteúdo dinâmico possa ser acessado ou ofereça uma apresentação ou página alternativa – ((efetivamente um link alternativo)) [2.4] 16) Use folhas de estilo para controlar o layout e a apresentação ((se possível para o gestor de conteúdo(CMS), desenvolver as páginas em tableless )) [2.5] 17)* Use unidades relativas, e não absolutas.[2.6] 18) Use elementos de cabeçalho para demonstrar estrutura.[2.7] 19)* Divida grandes blocos de informação quando apropriado. [2.8] 20) Assegure-se de que as informações fornecidas em tabelas façam sentido quando linearizadas ou ofereça uma alternativa equivalente [2.9] 21) Não use etiquetas estruturais para formatar informações dispostas com tabelas [2.10] 22) Descreva o propósito de cada frame e como eles se relacionam caso isso não seja óbvio somente a partir dos títulos. [2.11] 23)* Identificar claramente o destino de cada link.[2.12] 24)* Associe as etiquetas explicitamente com seus controles. [2.16] 25)* Posicione as etiquetas de controles de formulário corretamente.[2.17] 26)* Verifique se as interfaces do usuário são independentes de dispositivo.[2.18 ] 27) Use manipuladores lógicos de eventos em scripts.[2.19] 28) Use manipuladores lógicos de eventos independentes do dispositivo em scripts e applets.[2.20] 29) Garanta que scripts e applets sejam acessíveis.[2.21] 30)* Criar documentos que validem gramáticas formais publicadas.[2.23] 31)* Crie listas de marcadores e de itens usando as etiquetas apropriadas de HTML[2.24] 32) Não atualizar automaticamente as páginas em períodos. ((períodos de tempo))[2.28] 33)* Não utilize etiquetas para redirecionar as páginas automaticamente.[2.29] Requisitos Nível Básico - Detalhamento de Primeira Ordem. 0)* Saltos são Fundamentais para navegação acessível: (MAQ) Saltos. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 12 de 79 UPP – Unidade de Prospecção e Padronização Para além da acessibilidade que um navegador possa ter através de suas teclas de navegação originais, existem formas de se criar teclas de navegação e atalho pelo desenvolvedor nas páginas da web . Quando pensamos em fazer acessibilidade estamos querendo adaptar os sites para além das possibilidades já existentes nos navegadores comuns, como também superar barreiras de acesso criadas por funcionalidades programáveis que, estando fora dos padrões web , se tornem incompatíveis com tecnologias assistivas e o bom uso da navegação via teclado ou por voz. Por outro lado, algumas vezes, mesmo estando acessíveis as informações ou funcionalidades programadas pelo desenvolvedor, essas não possuem um acesso fácil, gastando-se tempo para entendê-las em sua utilização ou mesmo para se chegar a elas. Todas as páginas que possuem menus padronizados em um site , para serem além de acessíveis, terem uma boa usabilidade, têm de possuir teclas de atalho que permitam o salto para o conteúdo principal da página. Essas teclas de atalho podem ser colocadas pelo desenvolvedor sem prejuízo de qualquer outro conteúdo * . Outro momento da navegação em que a colocação de saltos é boa e necessária, é aquele em que sendo o texto muito extenso e com diversos temas sendo abordados, possa-se pular de um tema para outro dentro da mesma página. Técnicas para se fazer saltos. Quando no início de uma página encontramos um salto para o assunto principal , este foi feito da forma abaixo: <a href="#1s">Salto para Conteúdo.</a> Este é um link para a mesma página que faz o navegador pular, ou saltar, de onde é clicado até alguma marca. Esta marca pode ser feita assim: <a name="1s" id="1s">Conteúdo Principal.</a> Repare que estamos utilizando o name e o id. Isso acontece para atender os inúmeros leitores e navegadores utilizados por pessoas cegas. Alguns, os somente texto, só obedecem a marca name, os gráficos obedecem o id. Dessa forma redundante, estaremos atendendo a todos. Para quem não utiliza leitores de tela isso não tem a menor lógica. No entanto, os saltos para a mesma página são fundamentais para quem navega via teclado, pois faz a "rolagem" da tela, pulando-se inúmeros links que teriam de ser lidos ou textos anteriores ao que se quer chegar. Marco Antonio de Queiroz. (MAQ) * Adaptado do texto Acessibilidade web: tudo tem sua primeira vez, de Marco Antonio de Queiroz. Outras recomendações para implementação de Acessibilidade WEB. (MAQ) Livro: Criando Sites com CSS e XHTML. Sites Controlados por Folhas de Estilo em Cascata. Autor: Maurício Samy Silva - Maujor. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 13 de 79 UPP – Unidade de Prospecção e Padronização Sinopse. Seja você um desenvolvedor experiente, um acadêmico, um estudante da área relacionada à construção de sites para web ou um iniciante, Construindo sites com CSS e (X)HTML ampliará seus conhecimentos e será uma fonte de consulta valiosa no seu dia-a-dia de trabalho. Este livro aborda a técnica de construção de sites baseada nas Web Standards do W3C, cujo princípio básico é separar a marcação (X)HTML da apresentação visual. As CSS são uma poderosa ferramenta à disposição do desenvolvedor para criar um arquivo central de controle de todo o layout e apresentação do site. De forma didática, são apresentadas as razões da criação das Web Standards e suas vantagens, a sintaxe (X)HTML e CSS, as propriedades CSS e a criação de layouts fixos e elásticos multicolunares. Os assuntos tratados são ilustrados com códigos, exemplos e figuras que mostram a renderização no navegador. No site de apoio, o leitor encontrará os códigos para download e informações complementares sobre o livro. Sobre o autor. Maurício Samy Silva é formado em Engenharia Civil pelo IME - Instituto Militar de Engenharia. Fundador e ex-diretor presidente da Planep Engenharia, foi professor de geometria descritiva e de matemática ao longo de 25 anos. É divulgador ferrenho das Web Standards e desenvolve o site CSS para Web Design. e o Blog do Maujor. Ficha Cadastral. • Título: Criando Sites com CSS e XHTML. • Subtítulo: Sites Controlados por Folhas de Estilo em Cascata. • Autor: Maurício Samy Silva. • Nacionalidade do autor: Brasileiro. • ISBN: 978-85-7522-139-6 • Dimensões: 16x23 cm • Número de páginas: 448 • Preço: R$75,00 • Tiragem: 2.000 exemplares. • Palavras-chave: Folhas de estilo, folhas de estilo em cascata, CSS, XHTML, web standards, web design, construção de sites, desenvolvimento web, HTML, padrões web, normas web, tableless. • Público-alvo: Desenvolvedores, web designers, programadores e estudantes. Sumário. • • • • • • • • • • • • • • • • Agradecimentos. Sobre o autor. Introdução. Para quem foi escrito este livro. Convenções tipográficas. Site do livro. Capítulo 1 - As ferramentas básicas de desenvolvimento. Capítulo 2 - Histórico e (X)HTML. Capítulo 3 - Folhas de estilos em cascata. Capítulo 4 - O modelo CSS. Capítulo 5 - Seletores. Capítulo 6 - Estilização de textos. Capítulo 7 - Cores e background. Capítulo 8 - Cabeçalhos e links. Capítulo 9 - Listas HTML. Capítulo 10 - Formulários. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 14 de 79 UPP – Unidade de Prospecção e Padronização • • • • • • • • • • Capítulo 11 - Criando tabelas Web Standards. Capítulo 12 - Posicionamento CSS. Capítulo 13 - Layout CSS. Capítulo 14 - Bugs e Hacks. Capítulo 15 - Miscelânea. Apêndice A - Breve introdução à HTML. Apêndice B - FAQ CSS. Apêndice C - Referência CSS 2.1 Referências bibliográficas. Índice Remissivo. Seleção com base nas Diretrizes Irlandesas de Acessibilidade Extraídas do Site Bengala Legal do Sr. Marco Antônio de Queiroz Obs. Os comentários ((entre parênteses duplos)), foram acrescidos pelos autores deste documento. 1)* - Fornecer um texto equivalente para cada elemento não textual.[1.1] Ponto de verificação WAI 1.1 (Checkpoint 1.1). Texto completo da WAI: "Fornecer um texto equivalente para cada elemento não textual (por exemplo, através de "alt", "longdesc", ou elemento de conteúdo). Isso inclui: imagens, representações gráficas de texto (inclusive símbolos), imagens de mapas, animações (por exemplo, GIFs animados), pequenos programas (applets) e objetos programáveis, arte ascii, frames, scripts, imagens usadas como lista de marcadores, espaçadores, botões gráficos, sons (reproduzidos com ou sem interação do usuário), arquivos de áudio autônomos, trilhas de áudio de vídeos, e vídeo.". Todas as informações devem ser apresentadas em texto. Isso significa que, se for usada alguma outra mídia, tal como imagens, as informações que elas contêm devem ser repetidas em uma descrição textual. Essa descrição deve ser "equivalente", o que significa que ela deve transmitir as mesmas informações que o objeto que estiver sendo descrito. "alt" e "longdesc" são técnicas para a criação de textos equivalentes(consulte Instruções e Técnicas abaixo). Os exemplos mais comuns de elementos não textuais são imagens, animações, filmes e sons. As imagens podem consistir de arte-final, fotografias e enchimentos coloridos ou espaçadores. No entanto, eles também podem ser desenhos de texto, usados para títulos, cabeçalhos ou logos de empresas. Nesses casos, eles não são texto. Texto significa somente o que é chamado de "texto real", e é formado por caracteres ASCII ou unicode. Não inclui desenhos de texto. Do mesmo modo, as imagens usadas para os botões também devem ter um texto equivalente, pois elas não contém texto real. Imagens de mapas são compostas de muitas partes, cada qual é um botão gráfico ou link separado. Arte ASCII é o nome dado para figuras feitas com muitos caracteres de texto, do mesmo modo que uma imagem de jornal é feita de muitos pontos. A figura resultante tem um significado que não pode ser deduzido dos caracteres ou pontos. Esse significado deve ser apresentado em uma descrição textual alternativa. "ASCII" é o nome de um sistema comum de codificação de caracteres utilizado pelos computadores. Objetos programáveis, tais como os scripts e applets, são outro tipo de elemento não textual. São partes de uma funcionalidade escrita em linguagens outras que não HTML, para criar um comportamento dinâmico ou iterativo que vai dos simples efeitos visuais a miniaplicações. São exemplos os menus pop-up codificados em DHTML, letreiros e aplicações interativas, tais como calculadoras de tributos ou jogos escritos Java ou Macromedia Flash. Teoricamente, qualquer efeito ou funcionalidade pode ser criado utilizando um script ou applet. Sons incluem fala, sinais de áudio, tons de alerta e trilhas de áudio em vídeo, em arquivos baixáveis ou streaming. Nem todos os usuários podem acessar ou utilizar esses elementos diretamente e, assim, necessitam que a informação ou funcionalidade seja fornecida no formato texto. Há uma variedade de Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 15 de 79 UPP – Unidade de Prospecção e Padronização técnicas de HTML que podem ser usadas para fornecer informações equivalentes, inclusive "alt" e "longdesc", que podem ambas serem utilizadas para complementar as imagens visuais com texto. Fundamentos. Para alguns usuários, texto é a única mídia que podem acessar. Um cego não pode ver a tela e, portanto, não pode ler as informações no formato de imagem. Se os títulos são apresentados como imagens por questões de efeito visual, os usuários cegos não poderão ler e perderão grande quantidade de informações importantes. Se as imagens são usadas para botões e links de navegação, usuários cegos podem ser totalmente incapazes de utilizá-las ou de navegar pelo site. As informações apresentadas em figuras, gráficos, mapas ou fotografias também não estarão disponíveis para usuários cegos, a menos que elas existam em texto equivalente. Usuários portadores de deficiência visual freqüentemente utilizam um leitor de tela, um programa que interpreta os conteúdos de texto da tela e os apresenta através de um sintetizador de voz ou impresso em Braille. Se os elementos não textuais tiverem textos equivalentes, o leitor de tela poderá lê-los. Se não tiverem os textos equivalentes, o leitor de tela informará ao usuário que existe um elemento mas não dirá nada sobre ele, exceto, talvez, o nome do arquivo. Um surdo não pode ouvir os sons de alerta, narração ou outras informações em áudio. Entretanto, eles podem ler os textos equivalentes. Muitos usuários têm equipamentos velhos ou modens lentos e se conectam através de linhas telefônicas tarifadas continuamente. Esses usuários freqüentemente cancelam o downloading de imagens para economizar tempo e dinheiro. Instruções e Técnicas. Use o atributo Alt para objetos não textuais simples, tais como figuras e títulos gráficos ou botões, deve-se especificar a descrição textual utilizando o atributo HTML "Alt" (alternativo). O texto do atributo Alt deve ser escrito cuidadosamente para que possa fornecer informações equivalentes. Se o texto do Alt não transmitir com eficácia as informações que a imagem mostra, ele será inútil. Ao se usar um texto no atributo Alt para fornecer textos equivalentes para imagens utilizadas como links, o texto deve ter sentido como um título do link quando for lido fora do contexto. Para imagens meramente decorativas que não contêm informações, tais como espaçadores, linhas e enchimentos, usa-se o texto Alt vazio (descrito abaixo). Consulte as técnicas recomendadas pela WAI: Uso do texto no atributo Alt para fornecer conteúdo textual equivalente para imagens (Using Alt text for providing equivalent text content for images) e Fornecimento de textos equivalentes para applets e objetos programáveis (Providing text equivalents for applets and programmatic objects). Uso do atributo ALT com texto vazio para objetos que não contêm informações. Para imagens que são meramente decorativas e não contêm informações, tais como espaçadores, marcadores, linhas e enchimentos, usa-se o espaço vazio para o atributo ALT (Alt=" "). Ele será ignorado pela maioria das tecnologias de auxílio, tais como leitores de tela, e evitará bombardear o usuário com centenas de descrições inúteis, tais como "um espaçador, uma linha azul, marcador, marcador..." Deve-se notar que o texto vazio no atributo ALT tem um espaço vazio entre as aspas. Ele não é o mesmo que Alt="", que não contém espaço ou caracter e, portanto, não é um atributo ALT vazio, mas nulo. Tecnologias de auxílio podem não ignorar objetos com atributo ALT que não contenham espaço. Consulte as técnicas recomendadas pela WAI para o Uso de imagens como pontos de marcador (Using images as bullet points) e Uso de imagens como links (Using images as links). Fornecimento de uma longa descrição quando o texto Alt não for adequado. Realmente, o atributo Alt não é útil para explicações complexas demais para serem descritas em poucas palavras. Por exemplo, se for exibir um gráfico que mostre o crescimento populacional de três países (França, Alemanha e Espanha) de 1995 a 2001, pode-se utilizar o atributo Alt para dar uma descrição básica do gráfico, tal como: "Gráfico que mostra o crescimento populacional de França, Alemanha e Espanha, 1995 a 2001". Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 16 de 79 UPP – Unidade de Prospecção e Padronização Entretanto, as informações contidas no gráfico podem ser muito complexas e exigirem uma descrição muito maior. O gráfico pode mostrar linhas coloridas com os parâmetros de cada país, permitindo ao usuário identificar rapidamente tendências globais e fazer comparações. Isto está além da capacidade do atributo Alt e, nesse caso, deve-se utilizar a tag HTML "Longdesc" ou um link "D". Essas duas técnicas permitem aos usuários acessar um texto separado que descreve o contexto. Longdesc, embora seja parte da especificação do HTML, não é suportado por grande parte dos navegadores. A técnica alternativa link "D" envolve a inserção, além da imagem, de um link apresentado como a letra maiúscula "D". O alvo desse link deve ser uma página web separada que mostra uma longa descrição em formato de texto puro. Quando o usuário tiver lido esse texto, ele pode retornar à página com a imagem. "Longdesc" significa "longa descrição". Consulte as técnicas recomendadas pela WAI em Fornecimento de descrições longas com Longdesc e "D" link (Providing long descriptions with Longdesc and the "D" link). Fornecimento de um texto equivalente para cada link ativo que contém uma imagem de mapa. Consulte a técnica recomendada pela WAI em Fornecimento de texto equivalente de links contidos em imagens de mapas (Providing text equivalents of links contained in image maps). Notar que o link deve ser um link do lado do cliente para trabalhar com essa técnica. Como identificar essas situações? • Cancele o downloading de imagens do navegador. Isso mostrará a página sem as imagens. Deve ser possível ver o texto do atributo alt onde as imagens não mais aparecem. Verifique se o texto do atributo Alt está ou não adequado. • Cancele os scripts e Java do navegador. Isso permitirá ver a aparência da página e seu funcionamento sem scripts e applets. Com isso, será possível verificar se é ou não possível utilizar a página sem scripts e applets. • Teste a página com a ferramenta Bobby. Bobby" é uma ferramenta automática que informa se as imagens em uma página de internet tem texto Alt associado. Bobby pode ser obtido em Bobby. Note, entretanto, que a Bobby não informa se o texto Alt é adequado ou não. Essa é uma decisão sua. Bobby tem suas limitações e é necessário reservar um tempo para ler a documentação nas seções: "Como Ler um Relatório Bobby ("How to Read the Bobby Report") e FAQs (Perguntas mais freqüentes) no site da Bobby. • Ver Ponto de verificação WAI 1.1 (View WAI Checkpoint 1.1). 2)* Garantir que as informações não se baseiem na percepção de cores. ((nem em outros elementos estritamente visuais))[1.2] Ponto de Verificação WAI 2.1 (WAI Checkpoint 2.1). Texto WAI completo: "Assegure-se de que todas as informações fornecidas com cor estejam também disponíveis sem cor, por exemplo a partir do contexto ou com marcas." A cor é útil para fornecer informações, mas não se deve basear na cor como a única maneira de comunicar o significado. Use mais do que somente a cor para informar, utilizando rótulos, efeitos de estilo, etc. Fundamentos. Nem todas as pessoas percebem facilmente as diferenças de cor, podendo ter dificuldades para entender as informações que são transmitidas somente através delas. Por exemplo: imagine dois botões em uma tela, ambos idênticos em termos de tamanho e forma. Um é verde, o outro vermelho. O clique no botão vermelho destrói o computador do usuário. Se o usuário não puder distinguir entre as cores e não houver rótulos nos botões ele não tem como fazer a escolha certa. Os usuários têm dificuldade de perceber as cores se eles trabalham com monitores de baixa qualidade ou monocromáticos, e se são daltônicos. Do mesmo modo, é difícil ler um texto sobre um fundo cuja cor seja muito próxima, ou sem contraste com a cor do texto. Algumas combinações de cores, tal como um texto vermelho sobre fundo verde, também são difíceis de diferenciar. Não confie somente na cor para transmitir o significado. Escreva, por exemplo, "Os botões desta página web baseiam-se na capacidade do usuário distinguir entre o vermelho e o verde". Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 17 de 79 UPP – Unidade de Prospecção e Padronização Instruções e Técnicas. • Complemente as informações fornecidas através da cor com efeitos de estilo. Efeitos de estilo, como fontes, podem ser usados para realçar as diferenças nas informações. • Acrescente rótulos ou símbolos em links gráficos ou botões para comunicar sua função. Os rótulos podem ser exibidos como um texto claramente associado ao link gráfico ou botão. O rótulo pode ser no formato de texto ou de um ícone ou símbolo exibido junto com o elemento gráfico. Também pode ser usado o atributo Alt para associar um rótulo a um controle gráfico. • Forneça títulos de links que façam sentido quando lidos fora do contexto. Quando fornecer um grupo de links, não confie somente na cor para transmitir as informações sobre os links (por exemplo, "clique nos links vermelhos para editar os documentos" seguido de uma lista de links, todos com a inscrição "clique aqui". Alguns são vermelhos.). Títulos de links devem fazer sentido quando lidos fora do contexto, por exemplo, "Editar a ortografia", "Editar os estilos das fontes". Como identificar essas situações? • Imprima a página em uma impressora preto e branco. Isso dará uma indicação sobre como a página é vista sem cor. Entretanto, não é um teste completo. A maioria dos navegadores é configurada para não imprimir cores de fundo que podem estar por detrás do corpo principal do texto na página. • Veja a página com um navegador monocromático. Isso mostrará como a página seria vista sem cor e é possível verificar se somente a cor é utilizada para transmitir a informação. • Teste com Vischeck. Vischeck é um software que pode emular como uma página aparecerá para um usuário cego. Vischeck pode ser obtido em Vischeck.com 3)* Evitar o tremido na tela / Evitar que o conteúdo fique piscando. - ((i.e. lampejos luminosos intensos e repetitivas em determinadas faixas de freqüência, pois seqüências de flashes em intervalos superiores a 2 por Segundo, em torno de 1 por segundo entre si, como efeitos estroboscópicos, podem deflagrar ataques epilépticos em pessoas foto sensíveis.))[1.3 / 2.2 – 1.3] [1.3] Evitar o tremido na tela: Ponto de verificação WAI 7.1 (WAI checkpoint 7.1). Texto completo da WAI: "Até que os agentes do usuário permitam o controle dos tremidos pelo usuário, evite fazer com que a tela trema." Agente do usuário é um software para acessar o conteúdo Web. Os agentes do usuário podem ser navegadores gráficos na área de trabalho, navegadores de texto, navegadores de voz, telefones celulares, jogos multimídia, plug-ins, e algumas tecnologias de auxílio usadas em conjunto com leitoras de tela, lentes de tela e software de reconhecimento de voz. É possível fazer com que a tela trema inserindo comandos no código HTML de uma página web, normalmente para criar um efeito visual. Nem todos os agentes do usuário permitem que o usuário controle a taxa na qual a tela treme. Enquanto o usuário não tiver esse controle, não devem ser criados efeitos de tremidos. Fundamentos. É difícil concentrar-se em uma tela tremendo. Uma tela que treme também pode provocar ataques epiléticos. Pessoas com epilepsia fotossensível pode ter ataques provocados por tremidos ou flashes na faixa de 2 a 60 flashes por segundo (Hertz), com um pico de sensibilidade em 20 flashes por segundo, bem como por mudanças bruscas de escuro para claro (como nas luzes estroboscópias). Instruções e Técnicas. • Assegurar que a tela trema dentro de uma faixa de segurança. Manter o tremido em um nível menor que 2 flashes por segundo (Hertz) e não alterar bruscamente de escuro para claro. • Fornecer um mecanismo ou controle para congelar o tremido.ou movimento. Se você criar efeitos de tremidos utilizando applets Java ou outras técnicas, é necessário fornecer um Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 18 de 79 UPP – Unidade de Prospecção e Padronização controle óbvio que permita ao usuário congelar o movimento ou desabilitar o efeito de tremido. Como identificar essas situações? Não há método de teste específico recomendado para essa instrução. 3)* (Continuação) – Evitar o tremido na tela / Evitar que o conteúdo fique piscando. - ((i.e. lampejos luminosos intensos e repetitivas em determinadas faixas de freqüência, pois seqüências de flashes em intervalos superiores a 2 por Segundo, em torno de 1 por segundo entre si, como efeitos estroboscópicos, podem deflagrar ataques epilépticos em pessoas foto sensíveis.))[1.3 / 2.2] [2.2] Evitar que o conteúdo fique piscando: Ponto de Verificação WAI 7.2 (WAI Checkpoint 7.2). Texto WAI completo: "Até que os agentes de usuário permitam que os usuários controlem a intermitência luminosa, evite que o conteúdo pisque(ou seja, mude a apresentação com uma velocidade regular, tal como ligar e desligar)." Os agentes de usuário são softwares usados para ter acesso a conteúdo na Internet. Eles incluem browsers gráficos, browsers somente de texto, browsers de voz, telefones móveis, reprodutores de multimídia, plug-ins e tecnologias assistivas tais como leitores de tela, ampliadores de tela e software de reconhecimento de voz. É possível fazer o conteúdo piscar ou brilhar pela inserção de comandos para fazê-lo na página web. Isto se faz, geralmente, para criar um novo efeito, mas atualmente deve ser evitado, visto que nem todos os agentes de usuário permitem que este controle a velocidade da intermitência ou a desligue. Fundamentos. O movimento desordenado (flickering) pode induzir dano epilético nos usuários, se ocorrer regularmente a uma determinada velocidade. Também é difícil ler conteúdo que esteja aparecendo e desaparecendo, ou ler conteúdo quando alguma outra coisa na página estiver apresentando luz intensa. A intermitência causa particular desvio de atenção em usuários que tenham capacidade limitada de leitura ou dificuldade de concentração, devido a ruído, stress, ou problema de aprendizado. Instruções e Técnicas. • Certifique-se de que a intermitência da tela fique dentro de uma faixa segura. Mantenha a intermitência abaixo de 2 ocorrências por segundo (Hertz) e não mude rapidamente de escuro para claro. • Criar mecanismo ou controle para controlar ou desativar a intermitência. Se criar efeitos de intermitência usando applets Java ou outras técnicas, crie também um controle óbvio que permita ao usuário congelar o movimento ou desabilitar o efeito intermitente. Como se pode verificar isso? Não existem métodos de teste recomendados específicos para esta diretriz. 4) Fornecer uma descrição auditiva das informações visuais nas apresentações multimídia. / ((Fornecer uma descrição auditiva das informações visuais nas apresentações multimídia sincronizada com a exibição dos textos e imagens correspondentes. )) [1.4 / 1.5 - 1.4] [1.4] Fornecer uma descrição auditiva das informações visuais nas apresentações multimídia: Ponto de verificação WAI 1.3 (WAI checkpoint 1.3). Texto completo da WAI: "Até que os agentes do usuário possam ler em voz alta o texto equivalente de uma trilha visual, forneça uma descrição auditiva das informações importantes da trilha visual de apresentação multimídia." Agente do usuário é um software para acessar o conteúdo Web. Os agentes do usuário podem ser navegadores gráficos na área de trabalho, navegadores de texto, navegadores de voz, telefones celulares, jogos multimídia, plug-ins, e algumas tecnologias de auxílio usadas em conjunto com leitoras de tela, lentes de tela e software de reconhecimento de voz. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 19 de 79 UPP – Unidade de Prospecção e Padronização Multimídia é uma informação apresentada em uma combinação de formas, inclusive áudio (fala, sons, música, etc.) e imagens (vídeo, texto, gráficos, figuras, animações, filmes, etc.). Na internet, as informações multimídia podem ser apresentadas pelos navegadores em qualquer desses formatos ou em combinações deles. As animações criadas com um produto como o Macromedia Flash pode combinar imagens e áudio. Uma animação institucional em Flash sobre webdesign pode incluir imagens de uma página na internet em um monitor de computador, uma tradução ou narração e imagens de uma pessoa utilizando o software. As imagens ficam contidas na trilha de imagem, enquanto a narração fica contida na trilha de áudio. Uma descrição auditiva é uma descrição falada do conteúdo do arquivo multimídia. No caso de vídeo, a descrição auditiva descreveria através da fala o conteúdo visual do vídeo, inclusive as imagens, ações, linguagem corporal, mudanças de cenas, etc. A descrição auditiva é normalmente sincronizada com o conteúdo de áudio do arquivo. No filme institucional sobre web design, a descrição auditiva seria inserida entre pontos de silêncio da narração. Ela poderia informar o usuário se o instrutor estava demonstrando um recurso do software de design, ou se a narração estava se referindo a uma imagem da tela. A descrição auditiva pode ser apresentada como uma fala pré-gravada ou produzida por sintetizador. O texto equivalente de uma trilha visual é "equivalente" quando ambos atendem essencialmente a mesma função ou propósito. O texto equivalente pode ser uma descrição da trilha visual, isto é, como ela se parece ou soa. É apresentada no formato texto. A maioria dos navegadores não lêem automaticamente o texto equivalente da trilha visual e, enquanto não o fizerem, é necessário apresentar a descrição auditiva nos formatos texto e áudio. Fundamentos. Usuários que não podem ver o conteúdo visual de uma apresentação multimídia necessitam de uma descrição auditiva. Isso é importante quando os usuários não podem chegar suficientemente perto do monitor, têm visão deficiente ou são cegos. Os usuários que não podem ouvir uma trilha de áudio necessitam de um texto descritivo. Eles podem estar trabalhando em um ambiente quieto, como uma biblioteca, com o som desligado ou podem estar em um ambiente barulhento onde o som é abafado pelo ruído. Eles podem ter audição deficiente ou serem surdos. Alguns recursos de acessibilidade são melhor executados pelo agente do usuário. Idealmente, os usuários deveriam ser capazes de configurá-lo para ignorar quaisquer comandos, que poderiam estar embutidos no código HTML e que pudessem tornar inutilizável o conteúdo de uma página da internet. Alguns navegadores mais novos fornecem suporte para controles de acessibilidade, mas nem todos os navegadores o fazem. Não há controles padronizados, consistentes e largamente adotados. Idealmente, todos os agentes do usuário detectariam se há texto equivalente de uma trilha visual e automaticamente leriam em voz alta para o usuário. Entretanto, esse não é o caso e a exigência de assegurar que o site seja usável, sem se basear nos recursos do navegador proprietário, é colocada nos ombros do desenvolvedor, até o dia em que o comportamento dos navegadores for padronizado. Até então, é necessário fornecer um equivalente auditivo que é lido em voz alta e embutido na trilha de áudio do arquivo multimídia. Instruções e Técnicas. Fornecer descrições textuais para vídeo, na forma de legendas. Legendas são textos equivalentes do conteúdo visual de um vídeo. Elas são fornecidas sincronizadas com o conteúdo do vídeo. Alguns formatos de mídia (por exemplo, Quicktime e SMIL) permitem a adição de legendas e descrições ao clipe multimídia. Se esses formatos estiverem sendo utilizados, deve-se tirar proveito desses recursos. Como identificar essas situações? Veja a apresentação com o monitor desligado ou sem olhar para o monitor. Se não puder acompanhar a apresentação somente com som, então se faz necessário uma descrição auditiva. 4) (Continuação) - Fornecer uma descrição auditiva das informações visuais nas apresentações Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 20 de 79 UPP – Unidade de Prospecção e Padronização multimídia. / Para multimídia, assegurar que o tempo das descrições alternativas estejam sincronizadas com a apresentação. -((Fornecer uma descrição auditiva das informações visuais nas apresentações multimídia sincronizada com a exibição dos textos e imagens correspondentes. ))[1.4 / 1.5 - 1.4] [1.5] Para multimídia, assegurar que o tempo das descrições alternativas estejam sincronizadas com a apresentação: Ponto de verificação WAI 1.4 (WAI checkpoint 1.4). Texto completo da WAI: "Para qualquer apresentação multimídia baseada em tempo (por exemplo, um filme ou animação), sincronize as alternativas equivalentes (por exemplo, legendas ou descrições auditivas da trilha visual) com a apresentação." Filmes e animações são exemplos de apresentações baseadas em tempo, onde o conteúdo muda constantemente de momento a momento. Legendas ou descrições auditivas são exemplos de alternativas equivalentes. Elas são descrições não visuais que comunicam o conteúdo da parte visual ou auditiva de uma apresentação. Alternativas equivalentes devem ser inseridas nos intervalos apropriados ou nos silêncios do conteúdo auditivo ou textual, ou podem ser posicionados de modo a não interferir no conteúdo visual da apresentação. Fundamentos. Usuários que não podem ver o conteúdo visual de uma apresentação multimídia necessitam de uma descrição auditiva porque não podem chegar suficientemente perto do monitor, têm visão deficiente ou são cegos. Os usuários que não podem ouvir uma trilha de áudio necessitam de um texto descritivo. Eles podem estar trabalhando em um ambiente quieto, como uma biblioteca, com o som desligado, ou podem estar em um ambiente barulhento onde o som é abafado pelo ruído. Eles podem ter audição deficiente ou serem surdos. Filmes, vídeos e animações normalmente incluem conteúdo de áudio. Podem ser uma narração ou efeitos sonoros importantes. Eles também podem incluir importante conteúdo em texto, como o nome e título do emprego de uma pessoa em uma entrevista ou legendas de diálogos em um filme traduzido. As alternativas equivalentes - sejam elas legendas ou descrições auditivas - não devem ser borrados nem interferir nesse conteúdo importante. Instruções e Técnicas. Não há método de teste específico recomendado para essa instrução. Como identificar essas situações? • Veja a apresentação com as legendas ativadas. Abra a apresentação em um aparelho que suporte legendas e habilite o recurso de legenda para ver como as legendas são apresentadas e se interferem no contexto visual, tais como texto de tela, legendas, gráficos, etc. • Ouça a descrição auditiva da apresentação sem olhar para a tela. Quando o fizer, ouça para verificar se a descrição auditiva interfere com o conteúdo auditivo da apresentação. Olhar para longe da tela ou desligar o monitor significa que você terá que interpretar a apresentação sem a ajuda das informações visuais. 5) Utilizar a linguagem apropriada mais clara e simples [1.6] Ponto de verificação WAI 14.1 (WAI checkpoint 14.1) Texto completo da WAI: "Use a linguagem apropriada mais clara e simples para o conteúdo do site." A menos que o site apresente conteúdo muito especializado que requeira uma terminologia especializada, a linguagem utilizada para transmitir as informações deve ser compreensível para a audiência mais diversa possível. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 21 de 79 UPP – Unidade de Prospecção e Padronização Fundamentos. O uso excessivo de jargão torna o texto difícil de entender. Frases complexas ou longas são difíceis de ler e compreender. Os usuários não gostam de ler trechos grandes on-line e, portanto, o conteúdo deve ser estruturado de modo que possa ser lido superficialmente com facilidade. A leitura superficial envolve ler rapidamente os cabeçalhos, títulos e listas de marcadores para ter uma idéia do conteúdo total de uma página antes da leitura detalhada. Instruções e Técnicas. • Criar um guia de estilo para o conteúdo escrito. Um guia de estilo ajudará a fornecer constantemente um conteúdo acessível e fácil de entender, porque dá aos fornecedores de conteúdo as instruções quanto ao estilo, tom de voz e uso da linguagem. • Revisar o conteúdo para assegurar que é claro e simples. Defina um procedimento editorial para assegurar que o conteúdo esteja livre de jargões e escrito para facilitar a leitura on-line antes de ser publicado. • Examine a possibilidade de fornecer um glossário de termos. Se há termos especializados que devem ser usados no site, forneça um glossário que permita aos usuários consultar o significado de palavras difíceis ou não familiares. • Use cabeçalhos claros e concisos e títulos de links. Os cabeçalhos fornecem contexto e ajudam as pessoas a verificar a estrutura das informações escritas. Os títulos, inclusive os títulos de links, devem fornecer uma visão geral ou uma pista sobre o conteúdo associado. • Quebre o conteúdo em pequenas porções fáceis de ler. Use parágrafos, listas de marcadores e títulos para quebrar o conteúdo em pequenas porções que são mais fáceis de ler e visualizar. • Use uma linguagem clara e simples nas trilhas de áudio. Se fornecer informações através de áudio ou vídeo, assegure-se de que a linguagem é simples e clara. Como identificar essas situações? Não há método de teste específico recomendado para essa instrução. ((Obs. 1 - Convém se fazer uso de corretor ortográfico quanto a sintaxe e ortografia corretas das palavras – conteúdo e comentários - para evitar leitura e sintetização de voz incorretas pelos leitores de tela.)) ((Obs. 2 - Convém se fazer uso de Glossário específico para esclarecimento de termos técnicos e outras palavras não usuais contidas no texto – visando permitir ao leitor a compreender o conteúdo exibido.)) 6) Para tabelas de dados, identifique sempre os cabeçalhos de linhas e colunas. ((uma tabela não deve servir para formatar um layout de página))[1.9] Ponto de verificação WAI 5.1 (WAI checkpoint 5.1). Texto WAI completo: "Para tabelas de dados, identifique os cabeçalhos de linhas e colunas". Tabelas de dados contêm informações que são apresentadas em formato tabular, ex.: demonstrativos financeiros, cronogramas etc. Os cabeçalhos de linhas e colunas descrevem os conteúdos das células da tabela, fornecendo contexto para as informações contidas na tabela como um todo. Os cabeçalhos são definidos inserindo-se o atributo HTML correto, que indica a estrutura da tabela de modo não visual. Obs.: As tabelas também são usadas para controlar o layout de imagens e texto em páginas de internet. Tabelas usadas exclusivamente para esse propósito não são tabelas de dados e não precisam de cabeçalhos de linhas e colunas. Fundamentos. As pessoas capazes de examinar uma tabela visualmente, percebem o sentido da estrutura das informações ao comparar visualmente os cabeçalhos de linhas e colunas com os conteúdos das Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 22 de 79 UPP – Unidade de Prospecção e Padronização células da tabela. Entretanto, usuários de navegadores somente texto, ou de leitores de tela, dependem dos cabeçalhos para conseguir compreender a estrutura da tabela. Se os cabeçalhos não estiverem corretamente identificados no HTML subjacente, as informações contextuais necessárias para entender a estrutura da tabela se perderão ao serem lidas pelo navegador somente texto, ou pelo leitor de tela, tornando inúteis as informações contidas na tabela. Instruções e Técnicas. • Use os atributos HTML TH e TD para associar os dados da tabela aos respectivos cabeçalhos. Usa-se o TD para criar uma célula de dados de tabela. TH é usado para criar cabeçalhos de colunas. • Associe o conteúdo das células de dados ao atributo "headers". • Consulte as técnicas recomendadas pela WAI sobre como usar TH e TD para identificar cabeçalhos de tabelas Como verificar isso? Teste a página com uma leitora de tela ou navegador de áudio. Com isso você saberá se a página está corretamente codificada já que o sintetizador de fala lerá os conteúdos da tabela com a estrutura correta. 7)* Para tabelas de dados complexas, use marcação (mark-up) para associar células de dados e células de cabeçalhos. [1.10] Ponto de verificação WAI 5.2 (WAI checkpoint 5.2). Texto WAI completo: "Para tabelas de dados com dois ou mais níveis lógicos de cabeçalhos de linhas ou colunas, use marcação (mark-up) para associar células de dados e células de cabeçalhos." Tabelas de dados contêm informações que são apresentadas em formato tabular, ex.: demonstrativos financeiros, cronogramas etc. Os cabeçalhos de linhas e colunas descrevem os conteúdos das células da tabela, fornecendo contexto para as informações contidas na tabela como um todo. Os cabeçalhos são definidos inserindo-se o atributo HTML correto, que indica a estrutura da tabela de modo não visual. Quando as informações contidas numa tabela estão organizadas numa hierarquia estrutural com cabeçalhos e sub-cabeçalhos, diz-se que ela tem "níveis lógicos". Cada título e sub-título corresponde a um nível lógico. É necessário definir a hierarquia estrutural dos cabeçalhos e sua relação com as células de dados da tabela. Obs.: As tabelas também são usadas para controlar o layout de imagens e texto em páginas de internet. Tabelas usadas exclusivamente para esse propósito não são tabelas de dados e não precisam de cabeçalhos de linhas e colunas. Fundamentos. As pessoas capazes de examinar uma tabela visualmente percebem o sentido da estrutura das informações ao comparar visualmente os cabeçalhos de linhas e colunas com os conteúdos das células da tabela. Entretanto, usuários de navegadores somente texto, ou de leitores de tela, dependem dos cabeçalhos para conseguir compreender a estrutura da tabela. Se a relação entre cabeçalhos e células de dados não estiver corretamente identificada no HTML subjacente, as informações contextuais necessárias para dar sentido à estrutura da tabela se perderão ao serem lidas por um navegador somente texto, ou um leitor de tela, tornando inúteis as informações contidas na tabela. Instruções e Técnicas. • Use a marcação HTML correta para montar tabelas. Ao redigir em HTML, use THEAD, TFOOT e TBODY para agrupar linhas, COL e COLGROUP para agrupar colunas, e os atributos "axis" (eixo), "scope" (escopo) e "headers" (cabeçalhos) para descrever relações mais complexas entre os dados. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 23 de 79 UPP – Unidade de Prospecção e Padronização • Consulte as técnicas recomendadas pela WAI sobre boas práticas de HTML na definição de relações lógicas em tabelas Como verificar isso? Teste a página com uma leitora de tela ou navegador web de áudio. Com isso você saberá se a página está corretamente codificada, já que o sintetizador de fala lerá os conteúdos da tabela com a estrutura correta. 8)* Adicione títulos a frames (quadros). ((evitar frames sempre que possível))[1.11] Ponto de verificação WAI 12.1 (WAI checkpoint 12.1). Texto WAI completo: "Dê um título a cada frame para facilitar sua identificação e navegação". Os frames permitem que o designer quebre a página web em diferentes partes, cada uma contendo um arquivo HTML diferente. Os frames normalmente são usados para quebrar a página em duas seções: uma contendo informações que não se alteram quando o usuário navega pelo site e outra que apresenta informações mais dinâmicas. Um exemplo típico é quando a navegação principal do site se apresenta num frame do lado esquerdo da página, enquanto o conteúdo é apresentado em outro frame à direita. Neste caso, os links de navegação são mantidos num arquivo HTML à esquerda da página e o conteúdo fica em outro arquivo HTML, que é ativado conforme o link selecionado no frame da esquerda. Quando se clica num link do lado esquerdo, basicamente o que acontece é que uma nova página se abre do lado direito da janela do navegador. Cada frame deve ter um título, mesmo que não fique em modo visual. Fundamentos. Os usuários de navegadores ou leitores de tela mais antigos têm dificuldade de navegar páginas de internet com frames. O usuário capaz de examinar visualmente a página para determinar a relação dos seus elementos talvez nem perceba que estão sendo usados frames e entenderá facilmente a estrutura da página, mas usuários que não conseguem ver a página inteira não têm essa habilidade. Por exemplo, se um usuário de leitor de tela abrir uma página com frames, receberá uma lista dos frames que compõem a página. Se os frames não tiverem títulos, o usuário receberá uma lista de nomes de arquivos que não terá sentido, ex.: -frame: a'. A falta de informações úteis sobre os conteúdos do frame força o usuário a abrir cada frame, um a um, verificar seu conteúdo e descobrir como cada um deles se relaciona com os outros frames da página. É uma tarefa frustrante e demorada. Instruções e Técnicas. • Não use frames para fins puramente de apresentação. Os frames podem oferecer benefícios do ponto de vista funcional, mas se a sua única razão para usá-los for puramente estética, então melhor não usá-los. A maioria dos problemas de acesso causados pelo uso de frames ocorrem porque são um elemento estrutural, inapropriadamente usados para layout visual. • Use o atributo "title" para nomear frames. Ao codificar o HTML para frames, não deixe de usar o atributo "title" para dar um nome a cada frame. Trate títulos ou nomes de frames da mesma forma que títulos de links e use sempre nomes significativos, que dêem aos usuários uma boa idéia do conteúdo do quadro, ex.: "navegação principal do site" é um nome melhor do que "nav". • Consulte as técnicas recomendadas pela WAI para uso do atributo "title" para nomear frames. Como verificar isso? Não há métodos de teste específicos recomendados para essa diretriz. 9) Certifique-se de que os documentos possam ser lidos sem folhas de estilo (style sheets). [1.12] Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 24 de 79 UPP – Unidade de Prospecção e Padronização Ponto de verificação WAI 6.1 (WAI checkpoint 6.1). Texto WAI completo: "Organize os documentos de modo que possam ser lidos sem folhas de estilo. Por exemplo, quando um documento HTML é aberto sem associação a folhas de estilo, é necessário que ainda assim ele possa ser lido." As folhas de estilo especificam a apresentação do documento na internet. Podem ser usadas para controlar qualidades como tipos, tamanhos de fonte, cores e o posicionamento de elementos na página. É recomendável que se possa ler o conteúdo da página, na ordem lógica correta, sem o recurso das folhas de estilo. Fundamentos. As folhas de estilo não são tratadas da mesma forma por navegadores diferentes, sendo que alguns navegadores nem sequer as aceitam. Se o layout visual que descreve a estrutura das informações é controlado por folhas de estilo e a página estiver sendo visualizada num navegador que não as aceita, a estrutura lógica e as informações ficarão sem sentido. Alguns usuários anulam a folha de estilo padrão (default) para substituí-la por outra que seja mais adequada às suas necessidades. Por exemplo, o usuário pode precisar de fontes maiores ou de um esquema de cores diferente que lhe facilitem a leitura. Pode ser que a página não fique tão bonita como o designer idealizou, mas ainda estará legível e com sentido. Esta diretriz introduz o conceito de "degradação oportuna", também denominada "transformação oportuna". Um site de internet degrada-se oportunamente quando as informações e funcionalidades centrais ficam disponíveis para uma gama de diferentes tipos de navegadores, ainda que talvez não da maneira mais elegante possível. Instruções e Técnicas. • Use folhas de estilo para gerar conteúdo do tipo números de parágrafo, que ajuda os usuários de leitores de tela a acompanhar sua posição dentro do documento. Essa técnica gera o conteúdo de modo a ficar "oculto" ou não apresentado visualmente. A WAI recomendou Técnicas de Folha de Estilo em Cascata (CSS - do inglês Cascading Style Sheet) para geração de conteúdo em CSS. • A WAI recomendou técnica CSS para réguas e bordas em CSS Réguas e bordas podem transmitir a noção de "separação" para usuários dotados de visão, mas o significado não pode ser deduzido fora de um contexto visual. Esta técnica mostra como criar réguas e bordas usando as Folhas de Estilo em Cascata (CSS) e como indicar a ordem lógica usando estilos. • Observe as técnicas CSS recomendadas pela WAI para uso de posicionamento de folhas de estilo e marcação para transformação oportuna. Verifique o uso de folhas de estilo para controlar layout e apresentação com transformação oportuna. • Usando as técnicas recomendadas pela WAI para folhas de estilo e layout, crie folhas de estilo que controlam layout e apresentação numa ordem lógica, mesmo que o navegador usado pelo usuário não aceite ou desative as folhas de estilo. • Use o validador de folha de estilo WAI Esta ferramenta de software pode ser usada para validar CSS 1 e CSS 2. Abra o Validador Css do W3C. Como verificar isso? • Teste o website em diferentes navegadores e plataformas. Teste o website com diferentes navegadores para determinar se o site funciona em navegadores com recursos diferentes de folhas de estilo. Por exemplo, teste nas plataformas Macintosh e PC com diferentes navegadores, como Internet Explorer, Opera, Netscape e um navegador somente texto, como o Lynx. • Teste o website em navegadores mais antigos. Navegadores mais antigos às vezes não aceitam as folhas de estilo; por isso, ao testar o website com um navegador mais antigo, você saberá se as informações e funcionalidades podem ser acessadas por esses navegadores. • Desabilite o recurso folha de estilo de seu navegador e abra o web site. Com isso, você verá como fica a aparência do site e se ele funciona sem as folhas de estilo habilitadas. • Teste as folhas de estilo com o Validador CSS do W3C. Esta ferramenta de software pode ser usada para validar CSS 1 e CSS 2. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 25 de 79 UPP – Unidade de Prospecção e Padronização 10) Forneça links de texto para emular mapas de imagem do servidor. ((quando houver vários links na mesma imagem))[1.13] Ponto de verificação WAI 1.2 (WAI checkpoint 1.2). Texto WAI completo: "Forneça links de texto redundante para cada região ativa do mapa de imagens do servidor." Os mapas de imagens são imagens formadas por muitas partes, cada uma das quais é um botão gráfico ou link separado. Para seguir um link no mapa de imagens do servidor, o usuário clica num ponto da imagem com o mouse. As coordenadas geométricas do ponto são enviadas para o servidor onde reside a página, e o usuário é direcionado para uma página correspondente ao link associado àquele ponto. Os mapas de imagens do servidor são divididos em porções denominadas 'regiões ativas'. Essas regiões correspondem a links que conduzem a diferentes destinos e normalmente possuem formatos irregulares. Por exemplo, poderia ser apresentado ao usuário um mapa da Irlanda, dentro do qual o usuário teria que clicar num condado para visualizar mais informações sobre aquela área. Neste caso, o mapa da Irlanda é um mapa de imagens do servidor e cada condado é uma região ativa do mapa. Os links de texto redundante são apresentados em formato texto e correspondem aos links contidos nas regiões ativas do mapa de imagens. Fundamentos. Os mapas de imagens do servidor não fornecem suporte adequado a alt text, já que não pode ser fornecido para cada região ativa. Alt text só é aplicado ao mapa como um todo, o que significa que não pode ser usado em navegadores não gráficos, ou se as imagens forem desabilitadas num navegador gráfico, impedindo assim o acesso dos usuários a qualquer dos links. Além disso, os mapas de imagens do servidor dependem da interação "apontar e clicar" com o mouse, fazendo com que não possam ser usados com navegação só por teclado, ou seja, por usuários de laptops sem mouse, leitores de tela, telas de toque ou dispositivos indicadores especiais. Instruções e Técnicas. • Forneça uma lista alternativa de links depois da IMG e indique a existência e local da lista alternativa. • Se usar o elemento OBJECT, inclua a técnica de links de texto redundante recomendada pela WAI para o fornecimento de links alternativos ao usar o elemento OBJECT • Certifique-se de que os títulos dos links de texto redundante façam sentido. Os links de texto redundante devem fazer sentido mesmo lidos fora do contexto, ex.: se você fosse apresentar números relativos à população dos condados da Irlanda através de um mapa de imagens no formato do mapa da Irlanda, onde cada condado seria uma região ativa, os links de texto redundante deveriam dar indicação da conseqüência de seguir o link. Você poderia usar "População do Condado de Limerick" ao invés de apenas "Limerick". Isso oferece informação contextual útil para as pessoas que não podem ver o mapa de imagens. • Se não for adequado usar uma lista de links de texto, forneça a lista numa combo-box. Se não achar adequado inserir uma longa lista de links somente texto na página web, considere a possibilidade de usar uma caixa combo (combo box), desde que possa garantir que a caixa poderá ser acessada. • Forneça alt text para todas as regiões ativas do mapa de imagens do cliente. Ao fornecer alt text para as regiões ativas, lembre-se que devem fazer sentido como títulos de links ao serem lidos fora de contexto. O usuário que depende do alt text para usar o mapa de imagens necessita obter informações contextuais úteis dos títulos dos links. CAST recomendou técnicas para alt text e mapas de imagens do cliente. Como verificar isso? • Tente usar o site com o mouse desligado. Se não conseguir navegar pelo site com o mouse desligado, terá que inserir links de texto redundante. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 26 de 79 UPP – Unidade de Prospecção e Padronização • Teste o site com um navegador somente texto. Navegadores somente texto, como o Lynx, não conseguem reconhecer imagens, apresentando somente o texto. Páginas com mapas de imagens do servidor só podem ser usadas se forem fornecidos links de texto redundante. 11) Onde possível, use mapas de imagens do cliente ao invés de mapas de imagens do servidor. [1.14] Ponto de verificação WAI 9.1 (WAI checkpoint 9.1). Texto WAI completo: "Forneça mapas de imagens do cliente ao invés de mapas de imagens do servidor, exceto onde as regiões não possam ser definidas com um formato geométrico disponível." Os mapas de imagens são imagens formadas por muitas partes, cada uma das quais é um botão gráfico ou link separado. As diferentes partes são denominadas 'regiões ativas'. Com os mapas de imagens do servidor, o usuário clica num ponto do mapa e as coordenadas do ponto são enviadas para um aplicativo de processamento de mapa de imagens no servidor que hospeda o site. Com os mapas de imagens do cliente, o processamento é feito no navegador do usuário. Devem ser usados os mapas de imagens do cliente, a menos que haja necessidade absoluta de definir as regiões ativas com formatos irregulares (em oposição a formatos geométricos simples, como quadrados ou retângulos). Fundamentos. Os mapas de imagens do servidor não fornecem suporte adequado a alt text, já que não pode ser fornecido para cada região ativa. Alt text só é aplicado ao mapa como um todo, o que significa que não pode ser usado em navegadores não gráficos, ou se as imagens forem desabilitadas num navegador gráfico, impedindo assim o acesso dos usuários a qualquer dos links. Além disso, os mapas de imagens do servidor dependem da interação "apontar e clicar" com o mouse, fazendo com que não possam ser usados com navegação só por teclado, ou seja, por usuários de laptops sem mouse, leitores de tela, telas de toque ou dispositivos indicadores especiais. No entanto, os mapas de imagens do cliente não são adequados para alguns aplicativos. Por exemplo, seria muito difícil apresentar um sistema de informações geográficas baseado em coordenadas através de um mapa de imagens do cliente formado a partir de milhares de imagens individuais, cada uma com seu próprio alt text. Instruções e Técnicas. Não há técnicas específicas recomendadas para essa diretriz. Como verificar isso? Não há métodos de teste específicos recomendados para essa diretriz. 12)* Certificar-se de que os scripts e applets que forneçam a única fonte de funcionalidade importante sejam diretamente acessíveis ou compatíveis com tecnologias assistivas ((funcione com e sem script))[1.15] Ponto de verificação WAI 8.1 (WAI checkpoint 8.1). Texto completo da WAI: "Tornar os elementos de programa tais como scripts e applets diretamente acessíveis ou compatíveis com tecnologias assistivas [Prioridade 1 se a funcionalidade for importante e não estiver apresentada em outro local, do contrário Prioridade 2.]". Os scripts e os applets são tipos de objetos de programação. São peças de funcionalidade escritas em linguagens outras que não HTML, para fornecer comportamento dinâmico ou interativo desde os efeitos visuais simples até as mini aplicações. Há alguns exemplos de funcionalidade melhorada, tais como menus pop-up codificados em formato DHTML, rotinas de validação de entrada escritas em JavaScript e aplicações interativas tais como calculadores de impostos ou jogos escritos em Java ou Macromedia Flash. Os elementos de programa deverão ser inerentemente acessíveis ou incluir características que assegurem a sua utilização com tecnologias assistivas. As tecnologias assistivas permitem aos usuários fornecer entradas e perceber saídas onde não o poderiam fazer usando tecnologias como o mouse, o teclado ou a tela do monitor. Os usuários cegos Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 27 de 79 UPP – Unidade de Prospecção e Padronização podem usar, por exemplo, um leitor de tela, que é um programa que interpreta o conteúdo de texto da tela e o reproduz em um sintetizador de voz, ou em uma tela Braille. Os usuários de baixa acuidade visual pode usar um programa ampliador de tela para aumentar uma parte selecionada da tela. As pessoas que têm deficiências motoras podem precisar de um teclado ou dispositivo de apontamento (mouse) especiais, controlados por um joystick ou pelos movimentos da cabeça. Fundamentos. Os elementos de programação ideais são aqueles que dêem acesso direto ao público mais amplo, sem que este tenha de recorrer a tecnologias assistivas. Isto nem sempre é possível, visto que muitos browsers ou sistemas operacionais não trazem características adequadas de acessibilidade. Nesse caso, devem se incluir aos elementos de programação fornecidos pelas tecnologias de programação e que contam com o suporte das tecnologias assistivas. A acessibilidade direta é desejável em situações em que o usuário queira acessar um serviço ou informação que chega em páginas HTML, mas não possa usar os seus dispositivos ou tecnologias assistivas, porque isso não seja prático ou viável. Por exemplo, usar um leitor de tela para interagir com uma cabine em um local público. Isto seria impossível, porque os leitores de tela são, tipicamente, instalados nos PCs dos usuários e configurados para as suas necessidades. Instruções e Técnicas. • Applets acessíveis de escrita direta. Veja as técnicas recomendadas WAI para applets acessíveis de escrita direta. • Se você utilizar Java para criar applets, consulte as Java Look and Feel Guidelines da Sun Microsystems. O Java tem características inerentes de acessibilidade. Certifique-se de que providenciou independência dos dispositivos de entrada de dados ao usá-los. Veja as diretrizes da Sun sobre acessibilidade que vem no Java, com os detalhes sobre o seu uso. • Scripts acessíveis de escrita direta. Veja as técnicas recomendadas WAI para scripts acessíveis de escrita direta. Como se pode verificar isso? • Teste elementos programáveis com tecnologias assistivas. Os testes com tecnologias assistivas, tais como leitores de tela, ampliadores de tela, ou dispositivos especiais de apontamento, vão demonstrar se são diretamente acessíveis ou compatíveis. Deve-se considerar a hipótese de testar com usuários reais e ao fazê-lo, deve-se usar uma metodologia estruturada de teste de usuário. • Teste elementos de programa com teclado. Somente para navegação • Teste elementos programáveis com browsers de áudio. 13)* Certifique-se de que as imagens tenham contraste suficiente para as pessoas com deficiência cromática na visão [2.1] Ponto de Verificação WAI 2.2 (WAI Checkpoint 2.2). Texto WAI completo: "Certifique-se de que as combinações de cores de primeiro plano e de fundo forneçam contraste suficiente ao serem vistas por alguém que tenha deficiência de visão de cor ou vistas em tela em preto e branco. [Prioridade 2 para imagens, Prioridade 3 para texto].". A diferença de contraste entre as cores de primeiro plano e de fundo usadas em qualquer imagem devem ser suficientes para que os usuários percebam corretamente a imagem, inclusive os usuários que tiverem deficiências de visão cromática, ou que usem uma tela em preto e branco. Fundamentos. Nem todos distinguem com facilidade combinações de cores e tons. Alguns usuários acham difícil ler conteúdo, reconhecer objetos ou selecionar itens de uma lista quando o item e o fundo tiverem tons similares, mesmo se as cores forem diferentes. Isto afeta particularmente os usuários mais velhos e os que têm alguma forma de cegueira cromática. Os usuários também podem ter dificuldade para distinguir cores se usarem uma tela de má qualidade ou monocromática. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 28 de 79 UPP – Unidade de Prospecção e Padronização A cor tem três atributos que determinam como as pessoas as percebem- matiz, clareza e saturação. A matiz é a cor básica percebida, essencialmente o nome da cor - o cachecol é "vermelho". A clareza é a qualidade tonal - o cachecol poderia ser descrito "vermelho escuro". A saturação é a quantidade de cor - o cachecol é "muito vermelho". As cores ficam menos saturadas, movendo-se para o preto ou o branco. Os esquemas de cores que obtêm diferenciação clara dos três atributos proporcionam o melhor contraste. A percepção que as pessoas têm do contraste das cores é ligada à sua capacidade de percepção de cada um ou de todos os três atributos, e isto varia enormemente. Nunca se deve considerar que quando se percebe claramente uma combinação de cores como bem contrastada, todos a perceberão assim. Instruções e Técnicas. • Entenda como se percebe o contraste entre as cores. Para ter mais informações sobre como a escolha das cores afeta a percepção do contraste, veja Lighthouse. • Veja as técnicas recomendadas WAI para esta diretriz: Cores em imagens. • Veja as técnicas recomendadas WAI para fornecer contraste suficiente: Contraste de cores em CSS. Como se pode verificar isso? • Veja a página em um monitor monocromático. Isto mostrará como a página fica sem cor, e você poderá ver se a diferenciação de cor é essencial para o entendimento da informação. • Imprima a página em uma impressora preto e branco. Isto dará alguma informação de como a página fica sem cor, e você poderá ver se as informações são percebidas. Este teste, entretanto, não é definitivo. A maioria dos browsers são configurados de tal forma que não imprimem cores de fundo que poderiam aparecer atrás do corpo principal de texto na página. • Teste com Vischeck. Vischeck é um elemento de software capaz de emular como uma imagem ou uma página apareceriam para um usuário que fosse cego ou deficiente cromático. Você pode baixar Vischeck em www.vischeck.com (( Obs. 1 - Acessibilidade Visual: Analizador de Contraste de Cores. Recomendação do site Acessibilidade Legal)) 14) Evite movimento no conteúdo.[2.3] Ponto de Verificação WAI 7.3 (WAI Checkpoint 7.3). Texto WAI completo: "Evite páginas contendo movimento, até que os agentes do usuário possibilitem a imobilização do conteúdo". Os agentes de usuário são softwares usados para ter acesso a conteúdo na Internet. Eles incluem browsers gráficos, browsers somente de texto, browsers de voz, telefones móveis, reprodutores de multimídia, plug-ins e tecnologias assistivas tais como leitores de tela, ampliadores de tela e software de reconhecimento de voz. É possível fazer o conteúdo ficar em movimento pela inserção de comandos para fazê-lo na página web. Isto se faz, geralmente, para criar um novo efeito, mas atualmente deve ser evitado, visto que nem todos os agentes do usuário permitem que este controle a velocidade do movimento ou o desligue. Fundamentos. Conteúdo que se movimenta continuamente distrai e aborrece a maioria dos usuários. Usuários que lêem visualmente muitas vezes ocultam animações ou texto móvel da tela cobrindo-os com as mãos, um pedaço de papel ou rolando a página para que o elemento não seja visualizado. Links apresentados na forma de lista de rolagem contínua exige que os usuários leiam a lista e decidam seguir um dos links antes que este desapareça. Isso é maçante porque muitas pessoas preferem ler a lista inteira antes de tomar uma decisão. Clicar em links móveis pode ser difícil para usuários com habilidades limitadas. Usuários de leitores de telas acham complicado ou impossível usar conteúdo móvel porque os leitores de telas não funcionam bem com conteúdo que muda continuamente na janela do navegador. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 29 de 79 UPP – Unidade de Prospecção e Padronização Usuários com dificuldade de leitura ou concentração consideram difícil compreender o conteúdo móvel, e usuários com deficiência visual acham muito complicado focalizar este tipo de conteúdo. Instruções e Técnicas. Não há técnicas específicas recomendadas para essa diretriz. Como identificar essas situações? Não há métodos de teste específicos recomendados para essa diretriz. 15)* Certifique-se de que o conteúdo dinâmico possa ser acessado ou ofereça uma apresentação ou página alternativa – ((efetivamente um link alternativo))[2.4] Ponto de Verificação WAI 6.5 (WAI Checkpoint 6.5). Texto completo da WAI: "Certifique-se de que o conteúdo dinâmico possa ser acessado ou ofereça uma apresentação ou página alternativa." Conteúdo dinâmico é o conjunto de informações da página que sofre atualização em tempo real. Por exemplo, as últimas notícias carregadas "ao vivo" de um banco de dados dinâmico em tempo real. Vídeo, áudio e conteúdo apresentados por meio de scripts e applets também são dinâmicos. Um exemplo de conteúdo dinâmico apresentado por meio de script ou applet é a apresentação de manchetes de notícias na forma de letreiro atualizado continuamente. Frames (quadros) também são uma forma de conteúdo dinâmico, já que podem ser recarregados sem transição ou atualização da página. Se a página da Web contiver informações dinâmicas, o conteúdo dinâmico deverá ser oferecido de forma que possa ser acessado. Se isso não for feito, os usuários precisarão ter uma forma de navegar para outra página onde as mesmas informações são apresentadas em formato acessível. Fundamentos. O conteúdo dinâmico pode ser inacessível por várias razões. Alguns tipos de conteúdo dinâmico, como áudio ou vídeo, não são aceitos em navegadores mais antigos ou nos que só reconhecem texto. Frames também não são universalmente suportados por navegadores e outros agentes de usuários. Leitores de tela podem lutar contra conteúdo dinâmico de atualização contínua, como letreiros de notícias. Eles também podem não conseguir reagir às atualizações de frames na forma como reagiriam a uma transição ou atualização de página, o que pode causar problemas. Usuários com conexões lentas podem desativar recursos do navegador, necessários ao processamento e à exibição do conteúdo dinâmico, a fim de agilizar os tempos de download. Instruções e Técnicas. • Use o elemento LINK para orientar os usuários a formatos alternativos. O elemento LINK também pode ser usado para designar documentos alternativos. Os navegadores devem carregar a página alternativa automaticamente baseados no tipo de navegador do usuário e em suas preferências. Veja as técnicas recomendadas da WAI para o elemento Link e documentos alternativos. • Use scripts para detectar automaticamente navegadores diferentes e apresentar versões adequadas de páginas da Web. Um "detector de navegador" é um script que consegue detectar o tipo de navegador usado pelo visitante do site. Se um detector de navegador for usado junto com versões alternativas, será possível apresentar ao usuário a versão da página que funciona melhor com seu navegador. Observe que não é possível saber se o usuário está usando um leitor de tela, já que este não é um navegador. • Use os scripts do servidor para gerar páginas alternativas sob demanda. Os scripts do Servidor, como servlets Java ou PHP, podem ser usados para criar apresentações alternativas de uma página, se o usuário assim solicitar, usando o navegador. A vantagem de oferecer páginas alternativas desta forma reside no fato de que não há requisitos para a manutenção de "versões" distintas de um site da web, o que reduz o esforço de manutenção e assegura que o usuário receberá conteúdo atualizado, independente das versões que selecionar. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 30 de 79 UPP – Unidade de Prospecção e Padronização • Oferecer um link claro para versão(ões) alternativa(s) no topo de cada página. Oferecer o link no topo da página significa que o usuário não precisará perambular por conteúdo inacessível para ver a versão alternativa. Também é necessário oferecer um link que permita ao usuário voltar à versão original. • Considerar o uso de perfis de usuário para páginas visitadas com freqüência. Se o site contém informações ou serviços que o usuário provavelmente usará de forma contínua, considere oferecer a opção de salvar um perfil com suas preferências para a versão das páginas de que ele precisa. Assim, ele não precisará navegar para uma versão alternativa a cada vez que acessar o site. • Escreva scripts que possam ser interpretados quando desativados. Dizemos que um script pode ser interpretado quando desativado, se as informações fornecidas ficam disponíveis para o usuário mesmo quando o navegador ou usuário não aceita scripts. A apresentação pode variar e pode não ficar tão elegante como ficaria para usuários cujos navegadores suportam scripts, mas as informações ou a funcionalidade devem estar disponíveis. Consulte as técnicas recomendadas da WAI para saber mais sobre a interpretação de scripts desativados. • Se você usa frames, forneça uma forma de navegar para versões sem frames. Escreva HTML que permita aos usuários de navegadores que não aceitam frames navegar para uma versão do site que não usa frames. Consulte as técnicas recomendadas da WAI para saber como programar para navegadores que não aceitam frames Como identificar essas situações? Teste navegadores e agentes de usuários diferentes. Realizar testes com a maior variedade possível de navegadores e agentes de usuários, como leitores de tela, dispositivos de Braille etc. mostrará se é necessária uma apresentação alternativa. Se você fornecer versões alternativas de conteúdo, teste-as para assegurar sua acessibilidade. Se você não tem acesso direto a essa tecnologia, peça que alguém com experiência em avaliação de sites teste a acessibilidade com os agentes de usuários. 16) Use folhas de estilo para controlar o layout e a apresentação ((se possível para o gestor de conteúdo(CMS), desenvolver as páginas em tableless ))[2.5] Ponto de Verificação WAI 3.3 (WAI Checkpoint 3.3). Texto completo da WAI: "Use folhas de estilo para controlar o layout e a apresentação." As folhas de estilo são usadas para definir aspectos de apresentação de uma página da web, como fontes, tamanhos e cores usados no texto, nos cabeçalhos e nos hiperlinks, bem como o posicionamento de elementos na página. Use-as o mais freqüentemente possível ao invés de propriedades de elementos de codificação no HTML. Fundamentos. O uso de folhas de estilo separa a estrutura e a apresentação, o que gera muitos benefícios, como melhor acessibilidade, manuseabilidade e portabilidade. A estrutura se refere à organização lógica do conteúdo. Por exemplo, um formulário on-line para inscrição em um programa de hipoteca pode ser dividido em seções lógicas, como informações pessoais, empresa onde trabalha, detalhes do imóvel etc. Essa estrutura lógica será a mesma para todos os usuários, mas pode ser apresentada de diferentes maneiras, dependendo das necessidades e das preferências de cada usuário. Por exemplo, em uma apresentação gráfica detalhada com várias colunas usando tons sutis de cores, uma única coluna com texto grande em cores bem contrastantes ou com voz sintetizada. A acessibilidade é melhorada porque os usuários podem escolher entre os diferentes estilos e até mesmo substituir as folhas de estilo definidas por suas próprias folhas. Estas conteriam esquemas com fontes grandes ou cores diferentes para melhorar a legibilidade. Separar a apresentação e a estrutura permite a independência dos dispositivos, facilitando o ajuste da apresentação a diferentes navegadores ou agentes de usuários. Usar folhas de estilo também reduz o tamanho do arquivo de páginas da web e acelera o tempo de download, o que é muito útil para o usuário que trabalha com uma conexão lenta. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 31 de 79 UPP – Unidade de Prospecção e Padronização As folhas de estilo ajudam no gerenciamento e na manutenção ao permitir alterações rápidas na aparência visual de um site. Com as folhas de estilo, a necessidade de alterar a apresentação do site pode ser atendida imediatamente, no nível da folha de estilo, sem ser preciso acessar cada página no nível de elemento. Instruções e Técnicas. • Separe a estrutura e a apresentação durante a fase de design. Desenhe a estrutura de documentos ou páginas da web antes de pensar em como eles serão apresentados ao usuário. • Use os recursos de acessibilidade de folhas de estilo em cascata, ou CSS (Cascading Style Sheets). As folhas de estilo em cascata oferecem vários recursos de acessibilidade. Consulte www.w3.org/TR/CSS-access para obter informações técnicas e exemplos detalhados de recursos de acessibilidade CSS. • Use texto e folhas de estilo para controlar a apresentação: não se baseie apenas em imagens. O layout, o posicionamento, a distribuição em camadas e o alinhamento podem ser feitos com folhas de estilo. • Usar texto em lugar de imagens torna a informação da página da web disponível para mais usuários (com sintetizadores de voz, terminais Braille, visores gráficos etc). • Se a apresentação do texto é controlada por folhas de estilo, o projetista ainda consegue controlar a aparência visual usando técnicas de folha de estilo como flutuações e posicionamento absoluto.. • Consulte as técnicas recomendadas da WAI para saber como usar texto em vez de imagens e obter informações sobre layout CSS,posicionamento, disposição em camadas e alinhamento, formatação e posicionamento de texto CSS. • Use os elementos HTML adequados para marcar ênfases. Use os elementos EM e STRONG para indicar ênfases estruturais. Isso pode ser posteriormente transformado de várias formas (alterações de estilo de fonte, alterações na inflexão da voz, etc) por navegadores, leitores de tela e outros agentes de usuário. Esses elementos devem ser usados em lugar dos elementos B e I. Consulte as técnicas recomendadas da WAI para obter informações sobre marcação de ênfase em texto • Consulte as técnicas recomendadas da WAI para saber como usar folhas de estilo para controlar estrutura e apresentação. Como identificar essas situações? Faça um teste com o validador CSS do W3C. Valide seu CSS. 17)* Use unidades relativas, e não absolutas.[2.6] Ponto de Verificação WAI 3.4 (WAI Checkpoint 3.4). Texto completo da WAI: "Use unidades relativas em lugar de absolutas em valores de atributos de linguagem de marcação e em valores de propriedades da folha de estilo." As linguagens de marcação são linguagens como a HTML, usadas para criar páginas da web. A marcação HTML para elementos como texto, cabeçalhos e hiperlinks pode especificar atributos de apresentação como fontes, tamanhos e cores a serem usadas. Folhas de estilo também podem ser usadas para especificar os atributos da apresentação de elementos. Esses atributos podem ser especificados em unidades absolutas ou relativas. As unidades absolutas são valores fixos, como o tamanho de fonte de 12 pontos ou uma coluna de 800 pixels de largura. As unidades relativas definem o tamanho em unidades de medida como EMs (unidade de largura relativa a um tamanho de fonte) ou porcentagens da largura total da janela do navegador. Controlados por marcação ou folhas de estilo, os tamanhos devem ser definidos em unidades relativas, e não em unidades absolutas. Use texto HTML e certifique-se de ele possa ser redimensionado. Os navegadores permitem que os usuários redimensionem o texto especificado em valores relativos. Neste exemplo, o usuário não pode aumentar o tamanho da navegação principal porque são usadas imagens tabuladas, e não texto HTML. A sub-navegação pode ser dimensionada porque é usado texto HTML redimensionável. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 32 de 79 UPP – Unidade de Prospecção e Padronização Fundamentos. Projetar com tamanhos fixos, como um tamanho de janela de navegador "ideal" pode parecer uma boa idéia no papel, já que você pode pensar que está controlando a apresentação da interface mas, na realidade, isso é um esforço desperdiçado. Se uma interface for projetada tendo-se em mente um tamanho de janela de navegador "fixa", na melhor das hipóteses ela não funcionará bem, ou será completamente inútil se o usuário não trabalhar com aquele tamanho de janela, já que os principais recursos desaparecerão pela borda da tela. Isso afeta usuários com monitores menores, ou usuários que gostam de aumentar o tamanho do texto. Se a largura da página for projetada para ser bem exibida em um tamanho fixo de janela de navegador e o usuário aumentar o texto, ele pode ficar muito grande para ser exibido na tela. Se o tamanho da fonte for fixo, o usuário não poderá dimensioná-lo para facilitar a leitura. Ele pode querer fazer isso se estiver visualizando conteúdo em uma tela pequena, como em um dispositivo móvel ou laptop, ou se for portador de alguma deficiência visual. Além disso, você incorrerá em custos adicionais sempre que decidir disponibilizar seu serviço em outro dispositivo ou plataforma de acesso, devido ao esforço exigido para "encaixar" o projeto de interface no novo tamanho de janela. O dimensionamento relativo significa não somente que o site da web pode ser usado em uma variedade maior de dispositivos de acesso com esforço de design mínimo, mas também que você oferecerá aos usuários a flexibilidade de dimensionar elementos importantes com o tamanho que melhor atender suas necessidades. Instruções e Técnicas. • Consulte as técnicas recomendadas da WAI para obter informações sobre o uso de unidades de medida relativas. • Medidas relativas em frames. • Unidades de medida. Como identificar essas situações? • Tente alterar o tamanho do texto na janela do navegador. Se você não conseguir redimensionar o texto da janela do navegador usando os controles fornecidos no menu do navegador, significa que o tamanho da fonte foi definido com tamanhos absolutos. • Teste o site em vários tamanhos de janelas de navegador e de monitores. Se você não conseguir ver todo o conteúdo sem rolar a tela horizontalmente, significa que a largura da janela ou as tabelas da página foram definidas com tamanhos absolutos. Observe que as imagens são exceção. Elas não podem ser redimensionadas de forma a não fluir para um tamanho de janela menor, como acontece com o texto. 18) Use elementos de cabeçalho para demonstrar estrutura.[2.7] Ponto de Verificação WAI 3.5 (WAI Checkpoint 3.5). Texto completo da WAI: "Use elementos de cabeçalho para demonstrar a estrutura do documento e use-os de acordo com as especificações." Cabeçalhos são coisas como títulos, cabeçalhos de seções e de linhas e colunas em tabelas, usados para comunicar a estrutura das informações em páginas da web. Cabeçalhos só devem ser usados para demonstrar a estrutura das informações, de acordo com as regras de uso estabelecidas na definição da linguagem de marcação. Não use cabeçalhos para criar efeitos de apresentação como texto de tamanho diferente. Fundamentos. Muitas pessoas navegam ou percorrem documentos lendo os cabeçalhos para sentir sua estrutura e obter uma visão geral de seu conteúdo e escopo. O HTML permite que você especifique uma hierarquia de níveis de cabeçalho usando diferentes etiquetas (tags) de cabeçalho: H1, H2, H3 etc. A marca não apenas define a ordem hierárquica de um cabeçalho, ela também afeta a apresentação visual. Assim, um cabeçalho H1 parece maior e mais forte (escuro) que um cabeçalho H2. Usar etiquetas de cabeçalho para aumentar ou reforçar texto Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 33 de 79 UPP – Unidade de Prospecção e Padronização pode confundir os usuários, já que o conteúdo assumirá a aparência de um cabeçalho. Isso dificulta a compreensão da estrutura do documento ou página. Além disso, alguns leitores de tela lêem o conteúdo indicado como cabeçalho em um tom de voz diferente do usado para conteúdo da página, fornecendo ao usuário pistas importantes sobre a estrutura do documento. Usar incorretamente os atributos de cabeçalho confunde os usuários de leitores de tela. Instruções e Técnicas. Ordene os elementos de cabeçalho corretamente. Os elementos do cabeçalho sempre devem seguir uma ordem hierárquica lógica. Consulte as técnicas recomendadas da WAI para obter informações sobre o uso de elementos de cabeçalho. Como identificar essas situações? Não há métodos de teste específicos recomendados para essa diretriz. 19)* Divida grandes blocos de informação quando apropriado.[2.8] Ponto de Verificação WAI 12.3 (WAI Checkpoint 12.3). Texto completo da WAI: "Divida grandes blocos de informação em grupos manuseáveis quando natural e apropriado." Sempre que possível, divida os elementos da página em grupos lógicos de fácil compreensão, como seções e subseções. Fundamentos. Geralmente, não é confortável ler grandes extensões de texto na tela. As pessoas tendem a filtrar o conteúdo examinando títulos, subtítulos, listas etc. Isso fica mais fácil se o conteúdo for dividido em grupos facilmente digeríveis. É mais fácil compreender e navegar por elementos mais complexos, como formulários ou outros recursos interativos, se eles forem divididos em seções lógicas. Por exemplo, um formulário on-line pode ser dividido em seções lógicas, como informações pessoais, informações comerciais etc. Dividir o conteúdo em pequenos grupos é vantajoso para todos, inclusive para usuários apressados que precisam encontrar informações rapidamente, como atendentes de centrais telefônicas, usuários com dificuldade de leitura, falantes não nativos e usuários de leitores de tela. É muito importante agrupar elementos de formulário, como campos e listas de seleção usando HTML correto, pois assim os usuários de leitores de tela receberão informações contextuais importantes, que os ajudarão a navegar pelo documento. Dividir formulários complexos em grupos usando HTML correto também facilita a recuperação de erros para usuários de leitores de telas, já que simplifica a tarefa de navegar de volta ao formulário e corrigir as informações erradas. É importante que os grupos de informações sejam divididos logicamente. Grupos de elementos criados aleatoriamente confundirão os usuários. Instruções e Técnicas. • Use cabeçalhos (H1 a H6) para criar documentos estruturados e dividir longos trechos de texto. Os cabeçalhos de seções melhoram a navegação pelo conteúdo e sua compreensão. Consulte o parágrafo 1.2.1 xxx sobre o uso de elementos de cabeçalho nas técnicas recomendadas da WAI para saber como agrupar itens de conteúdo. • Divida as linhas de texto em parágrafos usando o elemento P. Use o elemento "P" para definir parágrafos em HTML. • Agrupe links correlatos. Uma barra de navegação no topo de uma página da web é um exemplo de agrupamento de links correlatos. Outro exemplo é um mapa de site contendo listas de links organizados. • Conheça as técnicas da WAI para saber como estruturar elementos em grupos. • Use as etiquetas UL, OL e DL para aninhar elementos de lista corretamente. • Use tabelas para dados tabulares e descreva a tabela usando a marca CAPTION. Forneça legenda para tabelas usando o elemento CAPTION. A legenda oferece uma breve descrição Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 34 de 79 UPP – Unidade de Prospecção e Padronização do conteúdo da tabela, geralmente em uma a três frases. Ela pode ser considerada semelhante ao título da página. A marca "Caption" deve ser inserida imediatamente após a marca "Table". É possível especificar apenas uma legenda por tabela. • Agrupe linhas e colunas de tabelas com THEAD, TBODY, TFOOT e COLGROUP. Esses elementos facilitam o agrupamento de linhas ou colunas de uma tabela. Esse elemento é válido apenas dentro da marca "Table". Ele agiliza a navegação e a compreensão para usuários de leitores de tela e facilita a visualização, a percepção e a impressão de informações. • Use OPTGROUP para organizar longas listas de opções de menu em grupos menores. O elemento OPTGROUP pode ser usado para agrupar itens SELECT (definidos por OPTION) em uma hierarquia. • Agrupe controles, elementos e opções de menu de formulários em grupos lógicos. As etiquetas HTML podem ser usadas para agrupar elementos de formulários e outros elementos interativos em grupos lógicos. Os agrupamentos resultantes nem sempre são exibidos no navegador padrão, mas ajudam a assegurar a compatibilidade com tecnologias assistivas. Consulte as técnicas recomendadas da WAI para saber como agrupar elementos de formulários Como identificar essas situações? Não há métodos de teste específicos recomendados para essa diretriz. 20) Assegure-se de que as informações fornecidas em tabelas façam sentido quando linearizadas ou ofereça uma alternativa equivalente[2.9] Ponto de Verificação WAI 5.3 (WAI Checkpoint 5.3). Texto completo da WAI: "Em layouts, só use tabelas se estas fizerem sentido quando linearizadas. Caso contrário (se a tabela não fizer sentido) ofereça uma alternativa equivalente (uma versão linearizada, por exemplo)." Uma tabela é um elemento HTML que pode ser usado para apresentar informações no formato tabular ou controlar a apresentação visual da página da web. Se uma tabela usada para controlar a apresentação visual de uma página da web for linearizada, o conteúdo de suas células de dados será exibido em uma longa coluna. A ordem de exibição do conteúdo na versão linearizada é determinada pela ordem na qual as células da tabela são definidas no HTML subjacente. O ideal é que o conteúdo da tabela faça sentido quando esta é linearizada. Se isso não ocorrer, ofereça ao usuário a opção de ver o conteúdo da tabela em outro formato (isto é, parágrafos ou blocos de texto que não são exibidos em tabela). Fundamentos. As tabelas são desenvolvidas originalmente como um recurso HTML, e especificamente para a apresentação de dados tabulares. Seu propósito nunca é controlar a apresentação. No entanto, as células de dados de uma tabela podem conter vários tipos diferentes de informações, incluindo texto, números ou imagens. Muitas vezes, os desenvolvedores usam tabelas para controlar o layout da página, por exemplo, para apresentar texto em um layout do tipo coluna de jornal, exibir elementos de navegação à esquerda da página com conteúdo no meio ou posicionar imagens dentro de blocos de texto. Isso cria um problema para os usuários de leitores de tela ou de tecnologias mais antigas. Leitores de tela mais velhos e navegadores que só reconhecem texto não conseguem processar informações dispostas em colunas. Se duas colunas de texto forem posicionadas lado a lado, uma pessoa com visão satisfatória lerá a coluna da esquerda de cima para baixo antes de passar para a próxima coluna. Leitores de tela mais antigos e navegadores de texto lerão da esquerda para a direita, começando pela primeira frase da coluna da esquerda e seguindo para a primeira frase da coluna da direita. Prosseguirão assim até o fim da página. Resultado final: fragmentos de frases combinados em texto ininteligível. Para evitar esse problema, alguns usuários linearizam tabelas de páginas da web usando controles de seus leitores de tela ou navegadores da web ou por meio de navegadores que reconhecem apenas texto, que conseguem linearizar tabelas. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 35 de 79 UPP – Unidade de Prospecção e Padronização A ordem na qual os elementos são exibidos na versão linearizada é determinada pela ordem de definição das células da tabela no HTML subjacente da página da web. Essa ordem pode ser diferente daquela na qual as tabelas são apresentadas visualmente. Tome como exemplo a leitura de um jornal, no qual os títulos dos artigos de uma página são exibidos na parte superior esquerda desta. Os artigos são exibidos um após o outro em uma longa coluna e não há nada para associar os títulos aos seus artigos correspondentes. Também não é fácil saber onde um artigo termina e outro começa. É assim a leitura de uma tabela que não faz sentido quando linearizada. Instruções e Técnicas. • Separe estrutura e apresentação. Desenhe a estrutura de documentos ou páginas da web antes de pensar em como eles serão apresentados ao usuário. • Avalie como a página será lida por um leitor de tela ou com tabelas linearizadas. • Consulte as técnicas recomendadas da WAI para saber como usar folhas de estilo para controlar estrutura e apresentação. • Use folhas de estilo para fazer o layout sempre que possível. Atualmente, as folhas de estilo não são amplamente aceitas por navegadores da web, mas seu uso como suporte vem aumentando. O posicionamento da folha de estilos pode ser linearizado de forma inteligível. Consulte as técnicas recomendadas da WAI sobre layout CSS,posicionamento, disposição em camadas e alinhamento • Ofereça uma página alternativa contendo uma versão linearizada inteligível. Ao fornecer uma página alternativa contendo uma versão linearizada das informações que seriam incluídas em uma tabela, assegure-se de que o link esteja facilmente disponível, que o título do link seja significativo e que as informações contidas na versão linearizada sejam iguais às da versão não linearizada. Como identificar essas situações? • Leia as tabelas em um navegador linear. Navegadores exclusivos para texto, como o Lynx, mostram o resultado da página quando a tabela é linearizada. O Opera é um navegador da web que permite linearizar tabelas, e também pode ser usado. Leia o conteúdo da tabela para ver se ele faz sentido quando linearizado. • Teste a tabela com um leitor de tela. Alguns leitores de tela não funcionam bem com tabelas; é melhor ler a tabela com um desses leitores para ver como o conteúdo é lido quando a tabela é linearizada. 21) Não use etiquetas estruturais para formatar informações dispostas com tabelas[2.10] Ponto de Verificação WAI 5.4 (WAI Checkpoint 5.4). Texto completo da WAI: "Ao fazer o layout com base em uma tabela, não use etiquetas estruturais para fins de formatação visual." Uma tabela é um elemento HTML que pode ser usado para apresentar informações no formato tabular ou controlar a apresentação visual da página da web. Não defina informações contidas em células de tabela com etiquetas estruturais para simplesmente obter um efeito visual, se a tabela for usada para controlar o layout da página. Definir o conteúdo de texto de uma célula de tabela como cabeçalho de coluna, para que seja exibido como texto em negrito, é um exemplo de uso inadequado de marcações estruturais para obter um efeito visual. Por exemplo, em HTML, não utilizar a etiqueta TH para fazer com que o conteúdo de uma célula (que não seja de cabeçalho de tabela) apareça centrado e a negrito. Fundamentos. Pessoas que conseguem examinar visualmente uma página desenvolvida com tabelas podem notar a estrutura das informações identificando e comparando visualmente os elementos estruturais (cabeçalhos de linhas e colunas, títulos e subtítulos). No entanto, pessoas que usam navegadores que reconhecem apenas texto, ou que não conseguem enxergar a página, dependem de uma descrição precisa dos elementos estruturais para compreender a estrutura da página. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 36 de 79 UPP – Unidade de Prospecção e Padronização Se os itens de conteúdo forem identificados incorretamente como elementos estruturais no HTML subjacente, a estrutura da página não fará sentido quando for apresentada por um navegador de texto ou um leitor de tela. Instruções e Técnicas. • Separe estrutura e apresentação. Desenhe a estrutura de documentos ou páginas da web antes de pensar em como eles serão apresentados ao usuário. • Avalie como a página será lida por um leitor de tela e com tabelas linearizadas. • Consulte as técnicas recomendadas da WAI para saber como usar folhas de estilo para controlar estrutura e apresentação. Como identificar essas situações? • Leia as tabelas em um navegador linear. Navegadores exclusivos para texto, como o Lynx, mostram o resultado da página quando a tabela é linearizada. O Opera é um navegador da web que permite linearizar tabelas, e também pode ser usado. Leia o conteúdo da tabela para ver se ele faz sentido quando linearizado. • Teste a tabela com um leitor de tela. Alguns leitores de tela não funcionam bem com tabelas; é melhor ler a tabela com um desses leitores para ver como o conteúdo é lido quando a tabela é linearizada. 22) Descreva o propósito de cada frame e como eles se relacionam caso isso não seja óbvio somente a partir dos títulos. [2.11] Ponto de Verificação WAI 12.2 (WAI Checkpoint 12.2). Texto WAI completo: "Descreva o propósito de cada frame e como eles se relacionam, se isso não for óbvio a partir dos títulos dos frames". Os frames permitem que o designer quebre a página web em diferentes partes, cada uma contendo um arquivo HTML diferente. Os frames normalmente são usados para que a página contenha duas seções: uma contendo informações que não se alteram quando o usuário navega pelo site e outra que apresenta informações mais dinâmicas. Um exemplo típico é quando a navegação principal do site se apresenta num frame do lado esquerdo da página, enquanto o conteúdo é apresentado em outro frame à direita. Neste caso, os links de navegação são mantidos num arquivo HTML à esquerda da página e o conteúdo fica em outro arquivo HTML, que é ativado conforme o link selecionado no frame da esquerda. Quando se clica num link do lado esquerdo, basicamente o que acontece é que uma nova página se abre do lado direito da janela do navegador. Cada frame deve ter um título, atribuído através do atributo TITLE, mesmo que não exibido visualmente. Se os títulos dos frames usados para a formatação de uma página não explicarem claramente a organização estrutural, ou o relacionamento entre eles e a natureza de seus conteúdos, esta informação deve ser apresentada de alguma outra forma. Fundamentos. Usuários de navegadores antigos ou leitores de telas têm dificuldade para navegarem em páginas que contenham frames. Eles não conseguem ler cada frame individualmente, assim como não conseguem imaginar a estrutura da página. Por exemplo, se um usuário de leitor de telas abrir uma página com frames, receberá uma lista dos frames que compõem a página. Se os frames não tiverem títulos, atribuídos através do atributo TITLE, o usuário receberá uma lista de nomes de arquivos que não terá sentido, ex.: -frame: a. A falta de informações úteis sobre os conteúdos do frame força o usuário a abrir cada frame individualmente, verificar seu conteúdo e descobrir como cada um deles se relaciona com os outros frames da página. É uma tarefa frustrante e demorada. Por exemplo, pode-se dar o título "NAV" para um frame. Este título não é muito informativo. Se o título desse frame fosse title="links para a seção principal do site" isto seria mais compreensível. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 37 de 79 UPP – Unidade de Prospecção e Padronização Instruções e Técnicas. • Descreva o relacionamento entre os frames no HTML underlying (oculto). Relacionamento entre frames e a natureza dos conteúdos de frames pode ser descrita no HTML underlying (oculto?), como por exemplo, através dos atributos ALT, LONGDESC e D. LINK, que explica como esta informação será exibida em navegadores que não suportam frames. • Veja as técnicas recomendadas pela WAI para descrever o relacionamento entre frames. Como se pode verificar isso? Teste a página usando um navegador que não ofereça suporte para frames. Abra a página com um navegador como o Lynx, que não exibirá frames. Isto lhe mostrará como a página será apresentada em um navegador que não suporta frames. Se você vir uma lista de títulos de frames e o propósito e relacionamento entre eles não ficar claro, considere a necessidade de adicionar uma descrição. 23)* Identificar claramente o destino de cada link.[2.12] Ponto de Verificação WAI 13.1 (WAI Checkpoint 13.1). Texto completo da WAI: "Identificar claramente o destino de cada link." Fornecer claramente informação sobre as conseqüências de seguir um link, incluindo seu destino e todos os efeitos associados. As informações que devem ser dadas incluem o seguinte: • O destino do link • Se ao entrar no link o usuário for desligado do site corrente; • Se ao entrar no link abrir uma nova janela (); • Se ao entrar no link ativar uma função que possa prender o navegador por um tempo, tal como um download; • Se ao entrar no link submeter a informação a uma base de dados. Fundamentos. Os títulos dos links, quando objetivos e claros, são essenciais para que os usuários decidam-se se querem seguir um link, por compreenderem o destino ou função dos mesmos. A clareza dos títulos dos links é particularmente importante para as pessoas que não são familiarizadas com computadores, com a WEB e seus serviços. A clareza dos títulos dos links também são úteis para os usuários de leitores de tela, que navegam frequentemente de forma direta de link em link, como se tivessem apenas uma lista de links na página, antes de investirem na leitura completa de toda a página em detalhe. Essa varredura de links na página é para terem uma visão geral do conteúdo da página. Assim, os links são lidos fora do contexto completo e é importante fornecer os títulos dos links com clareza suficiente para não requererem que o usuário leia a informação circunvizinha. Por exemplo, não faça títulos dos links incompletos como "clique aqui" e "saiba mais", pois não fornecem informação do seu conteúdo quando lidos fora do contexto. A informação sobre novos efeitos e funções, tais como a abertura de novas janelas de navegação, pode ser essencial aos usuários que são confundidos fàcilmente ou que não podem perceber a abertura da nova janela antecipadamente. A informação sobre downloads é também essencial, de modo que o usuário possa calcular se tem recursos para o tempo e o espaço requeridos para o download e se o conteúdo deste é de um tipo acessível e que levaos melhores termos suas necessidades. É muito frustrante perceber que o download, depois de realizado, não é compatível com seu sistema ou software. Instruções e Técnicas. • Escrever claramente os títulos dos links para que façam sentido quando lidos fora do contexto Ver Técnicas recomendadas da WAI para textos de link • Evitar de usar o mesmo título para dois ou mais links que apontem para destinos diferentes. Fazer isto é altamente desconcertante. Se dois ou mais links apontarem destinos diferentes, mas compartilharem do mesmo texto do link, distinguir os links especificando um Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 38 de 79 UPP – Unidade de Prospecção e Padronização valor distinto para o atributo "TITLE" em cada etiqueta "A". Ver Técnicas recomendadas da WAI para textos de link • Incluir avisos nos textos dos links que ativarem pop-ups ou novas janelas. Incluir um aviso como "abre em uma nova janela", como parte do título do link que ativar uma janela. O aviso como parte do hyperlink faz o título do link mais significativo quando lido fora do contexto. Por exemplo, será lido por usuários de leitores de tela quando navegarem diretamente pelos links da página. • Indicar tamanho de arquivo e tipo de documento nos textos de links que ativam downloads. Nos links que ativam downloads Fornecer aos usuários os detalhes do tamanho do arquivo e tipo de documento. Por exemplo, "relatório pdf (153K)". Se possível, é também útil fornecer estimativas dos tempos de download para vários tipos de conexões, ao lado do link do download. Por exemplo, "modem de 56K - 3 minutos". Como se pode verificar isso? Não existem métodos específicos de teste recomendados para esta diretriz. 24)* Associe as etiquetas explicitamente com seus controles. [2.16] Ponto de Verificação WAI 12.4 (WAI Checkpoint 12.4). Texto WAI completo: "Associe as etiquetas de formulários explicitamente com seus controles. Os exemplos de controle incluem campos de entrada de texto e caixas de verificação em formulários. Por exemplo, fazer etiquetagem dos controles em HTML através da etiqueta LABEL e o respectivo atributo "for". "Etiquetagem" é dar nomes aos elementos de controle de formulários, como por exemplo: INPUT TEXT. "Nome Completo" pode ser uma etiquetagem feita pela etiqueta LABEL e seu atributo FOR, associado a um campo de entrada de texto. Nesse caso, o nome do campo poderia ser visualmente apresentado imediatamente acima ou à esquerda do controle. Chamamos de etiquetagem implícita o ato de associar a etiqueta com o controle de formulário, posicionando-os o mais próximo possível. O relacionamento entre a etiquetagem e os elementos de controle pode ser definido como o HTML básico. Fundamentos. Uma boa prática é posicionar as etiquetas de forma a permitir que o relacionamento visual com os controles de formulário correspondentes seja óbvio. No entanto, se o relacionamento entre as etiquetas e os controles de formulário não estiver explicitamente definido no HTML básico, a exatidão na apresentação do formulário por browsers mais antigos ou tecnologias assistivas pode ficar comprometida. Instruções e Técnicas. • Use formulários com etiquetagem e o HTML correto. • Veja as técnicas WAI recomendadas para definir explicitamente o relacionamento entre controles e etiquetas. • Veja também o exemplo da IBM que mostra como etiquetar tipos diferentes de controle de formulário. Como se pode verificar isso? • Teste com um leitor de tela ou browser de áudio. O teste feito com um leitor de tela ou browser de áudio mostrará como as etiquetas e os controles de formulário estão associados. • Teste a ordem de leitura do formulário com o WAVE. O WAVE é um testador automático que lê o HTML básico de uma página e devolve um relatório indicando a ordem de leitura. Trata-se de uma ferramenta muito útil para testar páginas com formulários porque mostra como os formulários implicitamente etiquetados seriam lidos por um leitor de tela ou browser exclusivo de textos. Vá para a página inicial do WAVE. 25)* Posicione as etiquetas de controles de formulário corretamente.[2.17] Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 39 de 79 UPP – Unidade de Prospecção e Padronização Ponto de Verificação WAI 10.2 (WAI Checkpoint 10.2). Texto WAI completo: "Até que os agentes de usuário admitam associações explícitas entre etiquetas e todos os controles de formulários, verifique se a etiqueta está corretamente posicionada". Agente de usuário é um software que acessa conteúdos da Web. Podem ser browsers gráficos da área de trabalho, browsers de texto e de voz, telefones móveis, reprodutores multimídia, plug-ins e algumas tecnologias assistivas de software usadas em combinação com browsers do tipo leitores de tela, ampliadores de tela, ou software de reconhecimento de voz. Os exemplos de elementos de controle de formulário incluem campos de entrada de texto e caixas de verificação. As etiquetas são associadas com elementos de formulário quando são colocadas próximas uma da outra. "Etiquetagem" é dar nomes aos elementos de controle de formulários, como por exemplo: INPUT TEXT. "Nome Completo" pode ser uma etiquetagem feita pela etiqueta LABEL e seu atributo FOR, associado a um campo de entrada de texto. Nesse caso, o nome do campo poderia ser visualmente apresentado imediatamente acima ou à esquerda do controle. Chamamos de etiquetagem implícita o ato de associar a etiqueta com o controle de formulário, posicionando-os o mais próximo possível. Fundamentos. Uma boa prática é posicionar as etiquetas de forma a permitir que o relacionamento visual com os controles de formulário correspondentes seja óbvio. No entanto, algumas tecnologias assistivas, como os leitores de tela, só podem ler da esquerda para a direita e, a menos que as etiquetas de formulários sejam posicionadas com cuidado, não conseguirão ler o formulário de forma a possibilitar sua compreensão. Instruções e Técnicas. • Construa com cuidado o layout dos formulários. • Coloque as etiquetas ao lado dos controles de formulário e não acima deles. Os leitores de tela lêem da esquerda para a direita. Desta forma, ficará fácil ler o formulário e torná-lo compreensível com um leitor de tela. Como se pode verificar isso? • Teste com um leitor de tela ou browser de áudio. O teste feito com um leitor de tela ou browser de áudio mostrará como as etiquetas de formulário e os controles de formulário estão associados. • Teste a ordem de leitura do formulário com o WAVE. O WAVE é um testador automático que lê o HTML básico de uma página e devolve um relatório indicando a ordem de leitura. Trata-se de uma ferramenta muito útil para testar páginas com formulários porque mostra como os formulários implicitamente etiquetados seriam lidos por um leitor de tela ou browser exclusivo de textos. Vá para a página inicial do WAVE. 26)* Verifique se as interfaces do usuário são independentes de dispositivo.[2.18] Ponto de Verificação WAI 9.2 (WAI Checkpoint 9.2). Texto WAI completo: "Assegure que qualquer elemento que tenha sua própria interface possa ser operado de maneira independente do dispositivo". Exemplos de elementos que têm suas próprias interfaces incluem recursos interativos ou aplicativos, baseados na web, como calculadoras de impostos ou jogos escritos em Java ou Macromedia Flash. Esses elementos ficam embutidos em uma página da web e têm seus próprios controles, além de mecanismos de entrada e saída. Verifique se é possível interagir com os controles, forneça as entradas e observe as saídas desses elementos usando a maior série possível de dispositivos de entrada (inclusive mouse, teclado, microfone, dispositivos em Braille, leitores de tela e outros dispositivos), ou dispositivos de saída (inclusive monitores de tela, alto-falantes, fones de ouvido ou dispositivos em Braille). Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 40 de 79 UPP – Unidade de Prospecção e Padronização Fundamentos. As interfaces que não oferecem flexibilidade quanto ao tipo de dispositivo usado para interagir são inerentemente inacessíveis. Os usuários de laptops preferem trabalhar sem o mouse. Nesse caso, se os recursos da página exigirem um recurso, tal como um "arraste e solte" como único meio de interagir, sua utilização não será possível. Da mesma forma, sites acessáveis por meio de terminais em quiosques ou públicos, apenas com interface de "toque na tela", não podem ser usados. Desenvolvendo-se interfaces independentes dos dispositivos pode-se produzir uma usabilidade do site em uma gama maior de dispositivos de computação, inclusive aparelhos portáteis, PCs e sistemas de resposta interativa por voz [Interactive Voice Response systems (IVRs)]. Os usuários de leitores de tela confiam plenamente na entrada de teclado e na saída de áudio para interagir com websites. Se não houver suporte para saída de áudio ou para o teclado como um dispositivo de entrada, a utilização do site não será possível. Outros usuários podem usar saída de voz para operações sem uso das mãos em escritórios muito ativos ou caso haja limitação de destreza. Instruções e Técnicas. • Separe a estrutura da apresentação. Projete a estrutura dos documentos ou das páginas da web antes de pensar na forma de apresentá-los aos usuários. Consulte as técnicas recomendadas da WAI para saber como usar folhas de estilo para controlar estrutura e apresentação. • Se usar Java para criar applets, consulte o manual de instruções "Java Look and Feel Guidelines" da Sun Microsystems.. O Java tem recursos de acessibilidade inerentes. Verifique se está preparado para usá-los independentemente do dispositivo de entrada. Como se pode verificar isso? • Desconecte o mouse e tente navegar com o teclado. Supondo-se que saiba como interagir com um website usando apenas o teclado, este teste simples vai mostrar rapidamente se é possível navegar ou interagir com o site usando um dispositivo de entrada diferente do mouse. Verifique, principalmente desta forma, recursos interativos como formulários, menus suspensos, menus instantâneos etc. 27) Use manipuladores lógicos de eventos em scripts.[2.19] Ponto de Verificação WAI 9.3 (WAI Checkpoint 9.3). Texto WAI completo: "Para os scripts, especifique os manipuladores lógicos de eventos em vez dos manipuladores de eventos dependentes do dispositivo". Scripts são controles de funcionalidade escritas em outras linguagens diferentes do HTML, para possibilitar comportamento dinâmico ou interativo a partir de simples efeitos visuais até miniaplicativos. Alguns exemplos têm funcionalidade avançada como menus instantâneos codificados em DHTML, rotinas de validação de entradas de formulários escritas em JavaScript e aplicativos interativos como calculadores de impostos ou jogos escritos em Java ou Macromedia Flash. O manipulador de eventos é um script que é chamado quando um determinado evento ocorre (por exemplo: quando o mouse se movimenta, o teclado é pressionado, o documento é carregado etc.). Verifique se os manipuladores de eventos, que ativam recursos interativos. acionados por meio de scripts e applets, podem ser ativados e controlados usando-se a mais ampla variedade de dispositivos de entrada, inclusive mouse, teclado, microfone, dispositivos em Braille, leitores de tela ou outros dispositivos indicadores. Alguns manipuladores de eventos produzem efeitos puramente visuais, enquanto outros são usados para completar tarefas críticas, tais como submissão de conteúdos de formulários, conclusão de cálculos ou envio de mensagens. Os manipuladores de eventos fundamentais para completar tarefas devem sempre ser independentes do dispositivo de entrada. Fundamentos. As interfaces que não oferecem flexibilidade no tipo de dispositivo em que o usuário deve confiar para dar entrada em informações ou receber saídas, são inerentemente inacessíveis. Os usuários de Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 41 de 79 UPP – Unidade de Prospecção e Padronização laptops talvez prefiram trabalhar sem o mouse e com o teclado. Nesse caso, se os recursos do site exigirem um recurso do tipo "arraste e solte" como único meio de interagir, sua utilização não será possível. Da mesma forma, sites acessáveis por meio de terminais em quiosques ou públicos, apenas com interface de toque na tela, não podem ser usados se não for possível ver a tela. Esse item não está restrito somente à entrada de informações. É importante também oferecer saídas independentes do dispositivo. Os usuários de leitores de tela podem abrir o menu DHTML, mas se não receberem feedback sobre os nomes dos links que estão selecionando, o menu não terá utilidade. Da mesma forma, possibilitam abrir uma calculadora de impostos em Javascript e inserir dados, mas se a saída não for compatível com um sintetizador de voz, não é independente do dispositivo. Quando se desenvolve interfaces que possibilitam entradas com independência do dispositivo, produz-se a usabilidade do site em uma gama maior de dispositivos de computação, inclusive aparelhos portáteis, PCs e sistemas de resposta interativa por voz [Interactive Voice Response systems (IVRs)]. Os usuários de leitores de tela confiam plenamente no teclado para interagir com os websites. Se não houver suporte para o teclado como dispositivo de entrada, a utilização do site não será possível. Outros usuários podem usar a entrada de voz para operações sem uso das mãos em escritórios muito ativos ou em caso de limitação de destreza. Instruções e Técnicas. • Separe a estrutura da apresentação. Projete a estrutura dos documentos ou das páginas da web antes de pensar na forma de apresentá-los aos usuários. Consulte as técnicas recomendadas da WAI para saber como usar folhas de estilo para controlar estrutura e apresentação. • Se precisar usar atributos dependentes do dispositivo, forneça os mecanismos de entrada redundantes. • Em HTML 4.01, os atributos de eventos em nível de aplicativo são: "onfocus", "onblur" (o contrário de "onfocus") e "onselect". Observe que esses atributos foram projetados para funcionar independentes do dispositivo, mas foram implementados como eventos específicos de teclado nos navegadores atuais. • Caso precise usar atributos dependentes do dispositivo, forneça mecanismos de entrada redundantes (isto é, especifique dois manipuladores para o mesmo elemento): • Use "onmousedown" com "onkeydown"; • Use "onmouseup" com "onkeyup" • Use "onclick" com "onkeypress" • Observe que não há teclado equivalente para duplo clique ("ondbclick") no HTML 4.01. • Se usar o Java para criar applets, consulte o manual de instruções "Java Look and Feel Guidelines" da Sun Microsystems.. O Java tem recursos de acessibilidade inerentes. Verifique se está preparado para usá-los independentemente do dispositivo de entrada. • Consulte o Centro IBM de Acessibilidade para obter maiores informações sobre scripts. O Centro IBM de Acessibilidade oferece maiores informações sobre scripts e acessibilidade. Como se pode verificar isso? • Desconecte o mouse e tente navegar com o teclado. Supondo-se que saiba como interagir com um website usando apenas o teclado, este teste simples vai mostrar rapidamente se é possível navegar ou interagir com o site usando um dispositivo de entrada diferente do mouse. Verifique, principalmente desta forma, recursos interativos como formulários, menus suspensos, menus instantâneos etc. • Faça os testes com uma série de dispositivos de entrada. Fazendo o teste com uma série de dispositivos, inclusive teclado, mouse, agentes do usuário, como telefones móveis, navegadores gráficos e texto, inclusive tecnologias assistivas, como leitores de tela com sintetizadores de voz, softwares de comando de voz etc, será possível verificar se os manipuladores de eventos podem ser utilizados com a amplitude de dispositivos de entrada assistidos por agentes do usuário. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 42 de 79 UPP – Unidade de Prospecção e Padronização 28) Use manipuladores lógicos de eventos independentes do dispositivo em scripts e applets.[2.20] Ponto de Verificação WAI 6.4 (WAI Checkpoint 6.4). Texto WAI completo: "Para scripts e applets, verifique se os manipuladores de eventos são independentes do dispositivo de entrada". Scripts e applets são tipos de objetos programáveis. Trata-se de peças de funcionalidade escritas em outras linguagens diferentes do HTML, para possibilitar um comportamento dinâmico ou interativo a partir de simples efeitos visuais até mini-aplicativos. Alguns exemplos têm funcionalidade avançada como menus instantâneos codificados em DHTML, rotinas de validação de entradas de formulários escritas em JavaScript e aplicativos interativos, tais como calculadores de impostos ou jogos escritos em Java ou Macromedia Flash. O manipulador de eventos é um script que é chamado quando um determinado evento ocorre (por exemplo: quando o mouse se movimenta, o teclado é pressionado, o documento é carregado etc.). É preciso verificar se os manipuladores de eventos, que ativam recursos interativos liberados por meio de scripts e applets, podem ser ativados e controlados usando-se a mais ampla série de dispositivos de entrada, inclusive mouse, teclado, microfone, dispositivos em Braille, leitoras de cabeçote e outros dispositivos de indicação. Alguns manipuladores de eventos produzem efeitos puramente visuais, enquanto outros são usados para completar tarefas críticas como submissão de conteúdos de formulários, conclusão de cálculos ou envio de mensagens. Os manipuladores de eventos fundamentais para completar tarefas devem sempre ser independentes do dispositivo de entrada. Fundamentos. As interfaces que não oferecem flexibilidade no tipo de dispositivo em que o usuário deve confiar para dar entrada em informações ou receber saídas, são inerentemente inacessíveis. Os usuários de laptops talvez prefiram trabalhar sem o mouse e com o teclado. Nesse caso, se os recursos do site exigirem um recurso do tipo "arraste e solte" como único meio de interagir, sua utilização não será possível. Da mesma forma, sites acessáveis por meio de terminais em quiosques ou públicos, apenas com interface de toque na tela, não podem ser usados se não for possível ver a tela. Quando se desenvolve interfaces que possibilitam entradas com independência do dispositivo, produz-se a usabilidade do site em uma gama maior de dispositivos de computação, inclusive aparelhos portáteis, PCs e sistemas de resposta interativa por voz [Interactive Voice Response systems (IVRs)]. Os usuários de leitores de tela confiam plenamente no teclado para interagir com os websites. Se não houver suporte para o teclado como dispositivo de entrada, a utilização do site não será possível. Outros usuários podem usar a entrada de voz para operações sem uso das mãos em escritórios muito ativos ou em caso de limitação de destreza. Instruções e Técnicas. • Separe a estrutura da apresentação. Projete a estrutura dos documentos ou das páginas da web antes de pensar na forma de apresentá-los aos usuários. Imagine como a página será lida por um leitor de tela ou com tabelas linearizadas. Consulte as técnicas recomendadas da WAI para saber como usar folhas de estilo para controlar estrutura e apresentação. • Utilize gatilhos de eventos em nível de aplicativo em vez de gatilhos em nível de interação de usuários. • Em HTML 4.01, os atributos de eventos em nível de aplicativo são "onfocus", "onblur" (o contrário de "onfocus") e "onselect". Observe que esses atributos foram projetados para serem independentes do dispositivo, mas foram implementados como eventos específicos de teclado nos browsers atuais. • Caso precise usar atributos dependentes do dispositivo, forneça mecanismos de entrada redundantes (isto é, especifique dois manipuladores para o mesmo elemento): • Use "onmousedown" com "onkeydown"; • Use "onmouseup" com "onkeyup"; • Use "onclick" com "onkeypress". Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 43 de 79 UPP – Unidade de Prospecção e Padronização • Observe que não há teclado equivalente para duplo clique ("ondbclick") no HTML 4.01. • Não grave manipuladores de eventos que dependam de coordenadas do mouse. Essa não é uma boa prática porque depende do uso de um mouse e de um estilo altamente visual de interação para invocar um manipulador de eventos. Manipuladores de eventos que dependam de coordenadas do mouse não admitem entradas de teclado. • Se usar Java para criar applets, consulte o manual de instruções "Java Look and Feel Guidelines" da Sun Microsystems.. O Java tem recursos de acessibilidade inerentes. Verifique se está preparado para usá-los independentemente do dispositivo de entrada. Instruções e Técnicas. Desconecte o mouse e tente navegar com o teclado. Supondo-se que saiba como interagir com um website usando apenas o teclado, este teste simples vai mostrar rapidamente se é possível navegar ou interagir com o site usando um dispositivo de entrada diferente do mouse. Verifique, principalmente desta forma, recursos interativos como formulários, menus suspensos, menus instantâneos etc. 29) Garanta que scripts e applets sejam acessíveis.[2.21] Ponto de Verificação WAI 8.1 (WAI Checkpoint 8.1). Texto completo da WAI: "Tornar os elementos de programa tais como scripts e applets diretamente acessíveis ou compatíveis com tecnologias assistivas [Prioridade 1 se a funcionalidade for importante e não estiver apresentada em outro local, do contrário Prioridade 2.]". Scripts e applets são tipos de objetos programáveis. São partes da funcionalidade escritos em linguagem diferente da HTML, a fim de fornecer um comportamento interativo ou dinâmico que vai de simples efeitos visuais a mini-aplicativos. Alguns exemplos são de funcionalidade aumentada como menus pop-up codificados em DHTML, formulários de entrada de rotinas de validação escritos em JavaScript e aplicativos interativos tais como calculadoras de tributos ou jogos escritos em Java ou Macromedia Flash. Elementos programáveis deveriam ou ser inerentemente acessíveis ou incluir características que assegurassem que eles são usáveis com tecnologias de apoio. Tecnologias de apoio permitem que os usuários forneçam dados de entrada e percebam as respostas onde estas não sejam possíveis usando tecnologias como o mouse, o teclado ou a tela do monitor. Por exemplo, usuários cegos possam usar um leitor de tela que é um programa que interpreta os conteúdos de texto da tela e os transfere ou para um sintetizador de voz ou para um display de Braile. Usuários com pouca visão podem usar um programa ampliador de tela para aumentar uma determinada parte da tela. Pessoas com deficiências motoras podem solicitar um teclado especial ou um dispositivo que aponte para a tela, controlado por um joystick ou por movimentos de cabeça. Fundamentos. Idealmente, elementos programáveis deveriam ser diretamente acessíveis para que um maior número de pessoas possam usá-los sem ter que recorrer a tecnologias de apoio. Nem sempre é possível, pois muitos navegadores ou sistemas operacionais não incluem perfis adequados de acessibilidade. Neste caso, perfis de acessibilidade que são fornecidos pelas tecnologias de programação e suportados pelas tecnologias de apoio deveriam ser incluídas nos elementos de programação. A acessibilidade direta é desejável em situações onde o usuário quer acessar um serviço ou informação disponível em páginas em HTML, mas não pode utilizar tais dispositivos, ou tecnologias de apoio, porque estas não são práticas ou viáveis. Por exemplo, usar um leitor de tela para interagir com um quiosque em um espaço público. Isso seria impossível porque leitores de tela são tipicamente instalados no computador pessoal do usuário e configurado para satisfazer suas necessidades. Instruções e Técnicas. • Escrever diretamente appletes acessíveis. Veja as técnicas recomendadas WAI para applets acessíveis de escrita direta. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 44 de 79 UPP – Unidade de Prospecção e Padronização • Se você utilizar Java para criar applets, consulte o manual de instruções "Java Look and Feel Guidelines" da Sun Microsystems. O Java tem características inerentes de acessibilidade. Certifique-se de que providenciou independência dos dispositivos de entrada de dados ao usá-los. Veja as diretrizes da Sun sobre acessibilidade que vem no Java, com os detalhes sobre o seu uso. • Scripts acessíveis de escrita direta. Veja as técnicas recomendadas WAI para scripts acessíveis de escrita direta. Como se pode verificar isso? • Teste elementos programáveis com tecnologias assistivas. Os testes com tecnologias assistivas, tais como leitores de tela, ampliadores de tela, ou dispositivos especiais de apontamento, vão demonstrar se são diretamente acessíveis ou compatíveis. Deve-se considerar a hipótese de testar com usuários reais e ao fazê-lo, deve-se usar uma metodologia estruturada de teste de usuário. • Teste elementos programáveis com navegação apenas através do teclado. Tente operálos usando apenas o teclado. Se alguma funcionalidade não puder ser alcançada ou adequadamente controlada, então ela não é acessível. 30)* Criar documentos que validem gramáticas formais publicadas.[2.23] Ponto de Verificação WAI 3.2 (WAI Checkpoint 3.2). Texto completo da WAI: "Criar documentos que validem gramáticas formais publicadas." Uma etiqueta de documento HTML precisa seguir as regras que são definidas em um conjunto de declarações de markup que estão contidos em uma gramática formal publicada ou Definição de Tipo de Documento (DTD). Fundamentos. Documentos que são criados usando gramáticas formais publicadas serão suportados por mais navegadores e tecnologias de apoio. Muitos perfis de acessibilidade de tecnologias de apoio, tecnologia de internet acessível e navegadores de internet, dependem de gramáticas formais publicadas. Ser incapaz de trabalhar com gramática formal publicada pode tornar uma página da internet inacessível ou inacessível para tecnologias de apoio, como leitores de tela, dispositivos de Braile, etc. Escrever códigos que sejam compatíveis com gramáticas formais também facilita ferramentas de indexação, ferramentas de pesquisa, programas que extraem tabelas para bancos de dados, ferramentas de navegação que usam elementos de cabeçalhos e programa de tradução automáticas de texto. Instruções e Técnicas. • Incluir uma declaração de tipo de documento referente a uma DTD publicada. Usar a declaração DOCTYPE como a primeira linha do arquivo HTML para a gramática particular (por exemplo: a DTD HTML 4.0 específica) ao qual o código se ajusta. • Observar as técnicas recomendadas pela WAI para criar documentos válidos. Como se pode verificar isso? • Testar com o validador HTML do W3C. O validador HTML do W3C pode examinar seu código HTML (markup) para assegurar que este está de acordo com as gramáticas formais. A W3C também fornece uma lista completa das gramáticas formais que são usadas. Algumas ferramentas de certificação também incluem validadores. se você utiliza uma ferramenta de certificação, deveria ser assegurado que o validador está atualizado. 31)* Crie listas de marcadores e de itens usando as etiquetas apropriadas de HTML[2.24] Ponto de Verificação WAI 3.6 (WAI Checkpoint 3.6). Texto completo da WAI: "Listar corretamente os marcadores e itens de uma lista." Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 45 de 79 UPP – Unidade de Prospecção e Padronização O código HTML permite que sejam criados diferentes tipos de listas para diferentes necessidades, por exemplo: UL, OL e DL. Cada uma destas listas têm propriedades de exibição que são apropriadas a cada necessidade. Por exemplo, em uma lista ordenada os itens são numerados, enquanto que uma lista de itens que não estão em ordem utiliza marcadores. Elementos presentes em listas deveriam ser assinalados como listas, ao invés de ter os marcadores numéricos adicionados aos elementos em si. Elementos que não estejam presentes em listas não deveriam ser assinalados como listas para uma melhor apresentação visual. Por exemplo, um elemento não deveria ser atribuído a uma lista a fim de exibi-lo com um marcador ou número. Listas com mais de um nível lógico também podem ser assinalados corretamente para criar um sistema de números compostos tais como 1.1, 1.2, 2.1, etc. Fundamentos. Usuários de leitor de tela notarão os números em uma lista ordenada para navegação e contexto. Se os números não se referirem a uma hierarquia estrutural clara, os usuários se confundirão facilmente. Instruções e Técnicas. Use um sistema de números compostos para listas numeradas complexas. Listas complexas, tais como aquelas numeradas 1.1, 1.2, 2.1 e assim por diante podem ser criadas usando as técnicas recomendadas da WAI para listas markup em HTML e para a criação de listas ordenadas usando CSS. Como se pode verificar isso? Não há métodos de teste específicos recomendados para esta diretriz. 32) Não atualizar automaticamente as páginas em períodos. ((períodos de tempo))[2.28] Ponto de Verificação WAI 7.4 (WAI Checkpoint 7.4). Texto completo da WAI: "Até que os agentes do usuário supram a habilidade de parar a atualização, não crie páginas com atualização periódica automática." Agentes do usuário são programas que as pessoas usam para acessar o conteúdo da Internet. Estes incluem navegadores gráficos, navegadores de texto, navegadores de voz, telefones celulares, tocadores multimídia, plug-ins e tecnologias assistivas, tais como leitores de tela, ampliadores de tela e programas de comandos de voz. É possível criar páginas que se carreguem automaticamente no navegador do usuário, sempre que a janela do navegador estiver aberta. Isto deveria ser evitado no momento, uma vez que nem todos os agentes do usuário permitem que os usuários possam desabilitar a atualização automática. Fundamentos. O carregamento automático de uma nova página, ou da mesma página com um novo conteúdo pode ser muito confuso e frustrante para usuários que possam não estar completamente familiarizados com computadores e com o uso da Internet. Muitas pessoas consideram as páginas com auto-atualização (refresh)altamente confusas, porque elas controlam a navegação ao invés do usuário, que pode tornar-se rapidamente desorientado e deixar de compreender a estrutura do site. Os usuários lêem em velocidades diferentes. É altamente perturbador e inquietante quando a página atualiza-se antes que o usuário tenha tido a chance de determinar o conteúdo desta ou antes que eles tenham terminado de lê-la. Isto pode tornar as páginas, ou seus conteúdos, não usáveis para usuários que tenham habilidade de leitura limitada ou dificuldade em concentrar-se por causa de ruído, stress ou desordem de aprendizagem. Auto-atualização também causa problemas aos usuários de navegadores em texto, que geralmente não conseguem acompanhar a auto-atualização e podem falhar em exibir o conteúdo. Instruções e Técnicas. • Prover um mecanismo ou controle que desabilite a atualização automática. Se forem criadas páginas com auto-atualização usando applets Java ou outras técnicas, deveria ser fornecido um controle que permita ao usuário decidir a taxa de atualização ou desabilitá-la. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 46 de 79 UPP – Unidade de Prospecção e Padronização • Evite usar o elemento META para auto-atualização. Verifique a descrição da WAI de porque META (HTTP-EQUIV=refresh) não deveria ser usado para redirecionar ou autoatualizar as páginas Como se pode verificar isso? Não há métodos de teste específicos recomendados para esta diretriz. 33)* Não utilize etiquetas para redirecionar as páginas automaticamente.[2.29] Ponto de Verificação WAI 7.5 (WAI Checkpoint 7.5). Texto completo da WAI: "Até que os agentes do usuário forneçam a faculdade de parar o redirecionamento automático das páginas, não use etiquetas para redirecioná-las automaticamente. Ao invés disso, configure o servidor para realizar os redirecionamentos." Agentes do usuário são programas que as pessoas usam para acessar o conteúdo da Internet. Estes incluem navegadores gráficos, navegadores de texto, navegadores de voz, telefones celulares, tocadores multimídia, plug-ins e tecnologias assistivas, tais como leitores de tela, ampliadores de tela e programas de comandos de voz. É possível criar páginas que enviam automaticamente, ou "direcionem" o usuário para uma nova página da Internet, como se eles estivessem seguindo um link. Links de auto-redirecionamento são freqüentemente "invisíveis", no sentido de que eles não são apresentados como uma escolha na página, mas estão inseridos no HTML. Isto deveria ser evitado no momento, uma vez que nem todos os agentes do usuário permitem que os usuários possam desabilitar o auto-redirecionamento. Fundamentos. O redirecionamento para uma nova página pode ser muito confuso e frustrante para usuários que possam não estar completamente familiarizados com computadores e com o uso da Internet. Muitas pessoas consideram as páginas com auto-redirecionamento altamente confusas porque elas controlam a navegação ao invés dos usuários, que podem tornar-se rapidamente desorientados e deixar de compreender a estrutura do site. O direcionamento automático para outra página diminui a confiança do usuário em um site, pois este lhe tira o controle sobre a navegação e a interação. Os usuários lêem em velocidades diferentes. É altamente perturbador e inquietante quando a página atualiza-se antes que o usuário tenha tido a chance de determinar o conteúdo, ou antes que eles tenham terminado de lê-la. Isto pode tornar as páginas ou seus conteúdos não usáveis para usuários que tenham habilidade de leitura limitada ou dificuldade em concentrar-se por causa de ruído, stress ou desordem de aprendizagem. O auto redirecionamento também causa problemas aos usuários de navegadores textuais, que geralmente não conseguem acompanhar o auto redirecionamento e podem falhar em exibir o conteúdo. Instruções e Técnicas. • Configure o servidor para utilizar o código HTTP de status (301) apropriado. O uso de códigos de status HTTP é preferível porque reduz o tráfego de internet e tempo de download, podem ser aplicados em documentos que não estão no formato HTTP, e podem também serem usados por agentes que solicitam apenas um pedido principal (por exemplo: verificadores de links). Além disso, códigos de status do tipo 30x fornecem informação tais como "removido permanentemente" ou "removido temporariamente" que não podem ser dados com atualização em META. • Evite usar o elemento META para auto-atualização. Verifique a descrição da WAI de porque META (HTTP-EQUIV=refresh) não deveria ser usado para redirecionar ou autoatualizar as páginas • Substitua a página que seria redirecionada por uma estática contendo um link normal para uma nova página. Forneça uma página estática com um link e, idealmente, uma explicação de que o usuário será redirecionado para outra página. Esta é uma boa prática porque fornece informação objetiva sobre a nova página. Os usuários estarão menos suscetíveis de se desorientarem se eles souberem o que esperar. Se você fornecer um link, assegure-se de que o título do link é significativo. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 47 de 79 UPP – Unidade de Prospecção e Padronização Como se pode verificar isso? Não há métodos de teste específicos recomendados para esta diretriz. PARTE 4 - Requisitos para implementação de Acessibilidade WEB no Nível Intermediário. Requisitos Nível Intermediário – CRITÉRIOS Tendo sido satisfeitas pelo Nível Básico as necessidades mais prementes de Acesso à Informação e à Comunicação de todos os usuários, o Nível Intermediário propõe-se oferecer recursos e funcionalidades complementares, focando na maior usabilidade buscando incrementar a facilidade de uso, a produtividade e eficiência de navegação, a melhoria de segurança da informação, e a disponibilidade de formas alternativas de acesso, dentre outras facilidades. Também aborda a implementação de recursos mais complexos, menos freqüentes, ou que sejam de implementação mais difícil e/ou demorada para atender à Acessibilidade WEB para todos os usuários, incluindo as Pessoas com Deficiência, em conformidade com os recursos atuais de Tecnologias Assistivas, a Experiência e Demanda encaminhada pelos especialistas técnicos, usuários de computadores com Deficiência, assim como a Legislação Vigente sobre o assunto. (Em construção - será publicado junto com a Versão 2.b.0 N.B.I.) PARTE 5 - Requisitos para implementação de Acessibilidade WEB no Nível Avançado. Requisitos Nível Avançado – CRITÉRIOS Tendo sido satisfeitas pelos Níveis Básico e Intermediário as necessidades mais prementes de Acesso à Informação e à Comunicação de todos os usuários, acrescida da maior facilidade de uso, maior eficácia e eficiência, segurança e outras funcionalidades opcionais, e tendo sido resolvidas as implementações mais complexas, o Nível Avançado propõe-se definir padrões de Organização das Páginas e Sítios destinados a oferecer Produtos e Serviços do Governo PE, de forma Padronizada e Ergonômica de modo que qualquer pessoa encontrará com facilidade os comandos, identificará com facilidade os serviços e produtos, e seu investimento em aprender a utilisar um serviço do Governo será aproveitado para qualquer outro de natureza análoga. Também abordará a implementação de recursos mais complexos, e funcionalidades novas através da adoção de módulos padronizados, desenvolvidos e/ou contratados pelo Governo PE para serem utilizados em todas as Páginas e Sítios que disponibilizem Produtos e Serviços Públicos do Governo do Estado atendendo à Acessibilidade WEB para todos os usuários, incluindo as Pessoas com Deficiência, em conformidade com os recursos atuais de Tecnologias Assistivas, a Experiência e Demanda encaminhada pelos especialistas técnicos, usuários de computadores com Deficiência, assim como a Legislação Vigente sobre o assunto. (Em construção - será publicado junto com a Versão 2.b.i.0 N.B.I.A.) Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 48 de 79 UPP – Unidade de Prospecção e Padronização PARTE 6 – Norma na íntegra da W3C / WAI – WCAG 1.0, como base para consulta de detalhamento aprofundado para a implementação dos Padrões de Nível Básico, Intermediário e Avançado; Nota explicativa: - O documento reproduzido abaixo é o WCAG 1.0 de 1999, que até hoje março 2008 é adotado internacionalmente como a norma padrão para Acessibilidade WEB, mesmo tendo sido publicada uma nova versão o WGAG 2.0 posterior, esse último não foi aprovado internacionalmente permanecendo ainda o primeiro com padrão atual. (aqui reproduzido em língua Portuguesa.) Este documento é uma adaptação, para o vocabulário brasileiro, da versão traduzida para o português de Web Content Accessibility Guidelines 1.0, do W3C, a qual pode conter erros de tradução. A versão normativa, no idioma inglês, pode ser encontrada no endereço: http://www.w3.org/TR/WAI-WEBCONTENT Esta tradução da versão inglesa encontra-se no endereço: http://www.geocities.com/claudiaad/acessibilidade_web.html. Tradutor: mailto:[email protected] A tradução, manutenção e revisão deste documento é da responsabilidade de Cláudia Dias, auditora da tecnologia da informação do Tribunal de Contas da União (TCU). A reprodução e distribuição é livre, desde que cumpra os requisitos do documento do W3C sobre direitos de autor e copyright. [sumário] [lista de verificação] Recomendações para a acessibilidade do conteúdo da Web - 1.0 Guia do W3C, de 5 de Maio de 1999 Esta versão: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505 (em inglês) http://www. geocities.com/claudiaad/acessibilidade_web.html (em português) Versão mais recente: http://www.w3.org/TR/WAI-WEBCONTENT Versão anterior: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324 Editores: Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 49 de 79 UPP – Unidade de Prospecção e Padronização Wendy Chisholm, Trace R & D Center, Universidade de Wisconsin - Madison (EUA) Gregg Vanderheiden, Trace R & D Center, Universidade de Wisconsin - Madison (EUA) Ian Jacobs, W3C Copyright © 1999 (, , Keio). Todos os direitos reservados. São aplicáveis as disposições do W3C relativas a responsabilidade, marcas, utilização de documentos e licença de software. Sinopse As recomendações deste documento explicam como tornar o conteúdo Web acessível a pessoas com deficiências, destinando-se a todos os criadores de conteúdo Web (autores de páginas e projetistas de sites) e aos programadores de ferramentas para criação de conteúdo. O principal objetivo dessas recomendações é promover a acessibilidade. No entanto, sua observância faz também com que o conteúdo da Web se torne de mais fácil acesso a todos os usuários, independentemente da ferramenta usada (navegadores web para computadores de mesa, laptops, telefones celulares, ou navegador por voz) e das limitações associadas ao respectivo uso (ambientes barulhentos, salas mal iluminadas ou com excesso de iluminação, utilização sem o uso das mãos). A observância destas recomendações propicia, a qualquer usuário, acesso mais rápido às informações na Web. Estas recomendações não visam de modo algum restringir a utilização de imagem, vídeo, por parte dos produtores de conteúdo; ao contrário, explicam como tornar o conteúdo multimídia mais acessível a um público mais vasto. O presente documento é considerado uma referência para princípios de acessibilidade e idéias de design. Algumas das estratégias nele tratadas incidem sobre fatores relacionados com a internacionalização da Web e com o acesso móvel. Todavia, o documento se concentra no tema da acessibilidade e não trata, em detalhes, de questões relacionadas a outras atividades do . Para mais informações, consulte a página do W3C sobre acesso móvel e a página sobre internacionalização. Para que o conteúdo deste documento fosse duradouro, não foram fornecidas informações específicas sobre suporte de navegadores para as diferentes tecnologias, já que seriam informações necessariamente sujeitas a constantes alterações. Essas informações detalhadas podem ser obtidas no site da Iniciativa para a acessibilidade da Web (consultar [WAI-UA-SUPPORT]). Este documento inclui um anexo que organiza os pontos de verificação por tópico e nível de prioridade, com links para as respectivas definições. Os tópicos identificados no anexo abrangem imagens, multimídia, tabelas, frames, formulários e programas interpretáveis. O anexo está disponível na forma de tabela , ou lista de pontos de verificação. Um documento específico, sobre técnicas relativas às recomendações para a acessibilidade do conteúdo da Web (versão 1.0) ([TECHNIQUES]), explica como pôr em prática os pontos de verificação definidos no presente documento. Esse documento de técnicas, em inglês, aborda cada um dos pontos de verificação em mais detalhes e dá exemplos utilizando a linguagem de marcação de hipertexto ( - Hypertext Markup Language), folhas de estilo em cascata ( - Cascading Style Sheets), linguagem de integração de multimídia sincronizado ( - Synchronized Multimedia Integration Language ) e linguagem de marcação matemática ( - Mathematical Markup Language). Esse documento aborda ainda técnicas para validação e teste de documentos web e um sumário de elementos e atributos de HTML (indicando quais as técnicas que os utilizam). O documento de técnicas foi concebido para acompanhar as alterações tecnológicas e será atualizado com mais freqüência do que o presente documento. Nota: Nem todos os navegadores ou ferramentas de multimídia suportam as funcionalidades descritas nas recomendações, em particular, as novas funcionalidades dos formatos HTML 4.0, CSS 1 e CSS 2. O documento "Recomendações para a acessibilidade do conteúdo da Web - 1.0" faz parte de uma série de recomendações de acessibilidade, publicadas pela Iniciativa para a acessibilidade da Web, Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 50 de 79 UPP – Unidade de Prospecção e Padronização que inclui ainda recomendações para a acessibilidade de agentes do usuário ([WAI-USERAGENT]) e recomendações para a acessibilidade de ferramentas de criação de conteúdo ([WAI-AUTOOLS]). Status deste documento Este documento foi revisto por membros do W3C e por outras partes interessadas. Foi subscrito pelo diretor do W3C, como Recomendação Oficial do W3C. Trata-se de um documento estável, que pode ser utilizado como material de referência ou citado como referência normativa, em outro documento. O propósito do W3C, ao emitir este Guia, é chamar a atenção para o que nele foi especificado e promover a sua adoção generalizada, a fim de maximizar a funcionalidade e a universalidade da Web. A versão em língua inglesa das especificações aqui presentes é a única versão normativa. No entanto, existem traduções para outras línguas, em http://www.w3.org/WAI/GL/WAI-WEBCONTENTTRANSLATIONS. A errata relativa à versão original (em língua inglesa) deste documento está disponível em http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA. Por favor envie comentários sobre esse documento para o endereço [email protected]. É possível obter uma lista das Recomendações do W3C em vigor, assim como outros documentos técnicos, no endereço http://www.w3.org/TR. A produção deste documento está integrada à Iniciativa para a acessibilidade da Web, do W3C. O objetivo do Grupo de trabalho de recomendações para conteúdo da Web é descrito na Carta do grupo . Sumário Sinopse Status deste documento 1. Introdução 2. Temas para designs acessíveis • 2.1 Assegurar uma transformação harmoniosa • 2.2 Tornar o conteúdo compreensível e navegável • 3. Organização das recomendações • 3.1 Convenções utilizadas neste documento • 4. Níveis de prioridade • 5. Conformidade • 6. Recomendações para a acessibilidade do conteúdo da Web • 1. Fornecer alternativas equivalentes ao conteúdo sonoro e visual • 2. Não recorrer apenas à cor • 3. Utilizar corretamente marcações e folhas de estilo • 4. Indicar claramente qual o idioma utilizado • 5. Criar tabelas passíveis de transformação harmoniosa • 6. Assegurar que as páginas dotadas de novas tecnologias sejam transformadas harmoniosamente • 7. Assegurar o controle do usuário sobre as alterações temporais do conteúdo • 8. Assegurar a acessibilidade direta de interfaces do usuário integradas • 9. Projetar páginas considerando a independência de dispositivos • 10. Utilizar soluções de transição • 11. Utilizar tecnologias e recomendações do W3C • 12. Fornecer informações de contexto e orientações • 13. Fornecer mecanismos de navegação claros • • • • Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 51 de 79 UPP – Unidade de Prospecção e Padronização • • • • • 14. Assegurar a clareza e a simplicidade dos documentos Anexo A -- Validação Anexo B -- Glossário Bibliografia e agradecimentos Referências. A relação de pontos de verificação, incluída em anexo, está disponível na forma de tabela, ou lista. 1. Introdução Muitas pessoas não fazem idéia do que é, nem que importância pode ter, a temática da acessibilidade associada ao design de páginas para a Web. A Web pode ser usada, em diferentes contextos, por pessoas que: sejam incapazes de ver, ouvir, se deslocar, ou interpretar determinados tipos de informações; • tenham dificuldade em ler ou compreender textos; • não tenham um teclado ou mouse, ou não sejam capazes de utilizá-los; • possuam tela que apresenta apenas texto, ou com dimensões reduzidas, ou ainda uma conexão lenta com a Internet; • não falem ou compreendam fluentemente o idioma em que o documento foi escrito; • estejam com seus olhos, mãos ou ouvidos ocupados (por exemplo, ao volante, a caminho do trabalho, ou em um ambiente barulhento); • possuam uma versão ultrapassada de navegador web, diferente dos habituais, um navegador por voz, ou um sistema operacional pouco convencional. • Os criadores de conteúdo devem levar em conta essas diferentes situações, ao conceberem uma página para a Web. Embora haja uma variedade de situações, cada design de página, para ser verdadeiramente acessível, deve ser útil a vários grupos de incapacidade ou deficiência simultaneamente e, por extensão, ao universo dos usuários da Web. Assim, por exemplo, por meio de folhas de estilo para controlar tipos de fonte e eliminar o elemento FONT, os autores de páginas em HTML obtêm um maior domínio sobre as páginas que criam, tornando-as mais acessíveis a pessoas com problemas visuais e, com o compartilhamento de folhas de estilo, reduzem os tempos de transferência de páginas, para benefício da totalidade dos usuários. As recomendações abordam questões de acessibilidade, apresentam soluções de design e concentram-se em cenários típicos (semelhantes ao exemplo acima, sobre tipos de fontes) que podem trazer problemas a usuários com determinadas incapacidades. Por exemplo, a recomendação 1 explica de que modo os criadores de conteúdo podem tornar as imagens acessíveis. Alguns usuários podem não ser capazes de ver imagens; outros podem utilizar navegadores textuais e que não suportam imagens; e ainda outros podem ter desativado o suporte a imagens (por ex., porque possuem uma conexão lenta com a Internet). As recomendações não aconselham que sejam evitadas imagens para que a acessibilidade melhore. Ao contrário, explicam que a apresentação de um equivalente textual da imagem pode torná-la acessível. Como um equivalente textual pode tornar acessível uma imagem? Ambas as palavras da expressão "equivalente textual" são importantes: O conteúdo textual pode ser apresentado ao usuário sob a forma de discurso sintetizado, em Braille ou ainda em texto visível. Cada um desses três processos é direcionado a um sentido diferente (a audição, no caso do discurso sintetizado; o tato, no caso do Braille; a visão, no caso do texto visível), tornando as informações acessíveis a grupos representativos de um vasto leque de incapacidades e deficiências sensoriais ou não. • Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 52 de 79 UPP – Unidade de Prospecção e Padronização Para ser verdadeiramente útil, o texto deve transmitir a mesma função ou finalidade que a imagem. Considere o caso do equivalente textual de uma imagem fotográfica da Terra vista do espaço. Se a finalidade da imagem é, sobretudo, decorativa, um texto do tipo "Fotografia da Terra, vista do espaço" pode preencher a função necessária. Por outro lado, se a finalidade da fotografia for ilustrar uma informação bem determinada acerca da geografia do planeta, o equivalente textual deve transmitir essa informação. Se a fotografia tiver sido inserida na página para indicar ao usuário que ele deve selecionar a imagem (por ex., clicando sobre ela), o equivalente textual seria "Informações sobre a Terra". Assim, se o texto veicular, ao usuário deficiente, a mesma função ou finalidade transmitidas aos outros usuários, pode-se considerar um equivalente textual. • Nota-se que, além de beneficiarem os usuários deficientes, os equivalentes textuais contribuem para que todos e quaisquer usuários encontrem as páginas mais depressa, já que os mecanismos de busca podem se servir do texto em sua indexação. Embora o fornecimento de equivalentes textuais de imagens e demais conteúdos multimídia seja da competência dos criadores de conteúdo Web, a apresentação das informações ao usuário é responsabilidade dos agentes do usuário (por ex., navegadores e tecnologias de apoio, como os leitores de tela, monitores Braille). Os equivalentes não textuais de texto (por ex., ícones, discurso pré-gravado ou um vídeo de uma pessoa traduzindo o texto para linguagem de sinais) podem tornar os documentos acessíveis a pessoas que têm dificuldade em acessar texto escrito, entre elas as que têm deficiências cognitivas, dificuldades de aprendizagem ou surdez. Os equivalentes não textuais de texto podem também ser úteis a pessoas que não lêem. Exemplo de um equivalente não textual de informações visuais é a descrição sonora. A descrição falada de uma passagem visual de uma apresentação multimídia beneficia quem não consegue ver as informações visuais. 2. Temas para designs acessíveis As recomendações abordam dois temas genéricos: assegurar uma transformação harmoniosa e tornar o conteúdo compreensível e navegável. 2.1 Assegurar uma transformação harmoniosa Levando em consideração estas recomendações, os criadores de conteúdo Web podem produzir páginas cuja transformação seja harmoniosa. Uma página com estas características mantém-se acessível apesar da presença de quaisquer das limitações descritas na introdução, dentre as quais se encontram as deficiências físicas, sensoriais e cognitivas, as limitações de trabalho e as barreiras tecnológicas. A seguir, são apresentados alguns pontos-chave para o design de páginas que possibilitem uma transformação harmoniosa. Separar a estrutura da apresentação (ver a diferença entre conteúdo, estrutura e apresentação). • Incluir texto (equivalentes textuais). O texto pode ser incluído de tal modo que seja possível ser interpretado por praticamente todos os dispositivos de navegação e por quase todos os usuários. • Criar documentos que cumpram a sua finalidade, mesmo que o usuário não consiga ver e/ou ouvir. Fornecer informações que preencham a mesma finalidade ou função que o áudio ou o vídeo, de tal maneira que se adaptem o melhor possível a canais sensoriais alternativos. Isso não significa que deva ser criada uma versão áudio pré-gravada de todo o site, para torná-lo acessível a usuários cegos ou com problemas visuais graves. Esses podem recorrer à tecnologia dos leitores de tela para extraírem todas as informações textuais das páginas. • Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 53 de 79 UPP – Unidade de Prospecção e Padronização Criar documentos que não dependam apenas de um tipo de equipamento. As páginas devem poder ser utilizadas por pessoas que não possuam mouse, que tenham monitores de vídeo pequenos, de baixa resolução ou monocromáticos, que apenas recebam voz ou texto. • O tema da transformação harmoniosa é tratado especialmente nas recomendações 1 a 11. 2.2 Tornar o conteúdo compreensível e navegável Os criadores de conteúdo Web devem tornar as suas produções compreensíveis e navegáveis. Isso passa não só por uma linguagem clara e simples, mas também pela apresentação de meios compreensíveis para proceder à navegação entre páginas e no interior delas. A inclusão de ferramentas de navegação e orientação nas páginas é um fator promotor da acessibilidade e da facilidade de uso. Nem todos os usuários podem se servir de "pistas" gráficas (como mapas de imagens, barras de deslocamento proporcionais, frames colocados lado a lado, ou gráficos) que guiam os usuários com visão normal, em navegadores gráficos de estações de trabalho gráficas. Os usuários perdem também informações de contexto quando apenas conseguem ver uma parte da página, seja porque estão acessando a página palavra a palavra (por discurso sintetizado ou monitor Braille), seja seção a seção (em um monitor de vídeo pequeno ou muito ampliado). Sem informações de orientação, os usuários podem não compreender tabelas, listas ou menus extensos, por exemplo. O tema da percepção e navegabilidade é abordado, em especial, nas recomendações 12 a 14. 3. Organização das recomendações Este documento contém 14 recomendações, ou princípios gerais, sobre design acessível. Cada recomendação inclui: O número da recomendação. A descrição da recomendação. Links para navegação. A presença de três links permite passar para a recomendação seguinte (ícone da seta para a direita), para a anterior (ícone da seta para a esquerda), ou para a posição que, no sumário, é ocupada por essa mesma recomendação (ícone da seta para cima). • A lógica relacionada com a recomendação e a indicação de alguns dos grupos de usuários que podem ser beneficiados com ela. • Uma lista de definições de pontos de verificação. • • • As definições dos pontos de verificação de cada recomendação explicam de que modo esta se aplica a cenários típicos de desenvolvimento de conteúdo Web. Cada ponto de verificação inclui: O número do ponto de verificação. A descrição do ponto de verificação. O nível de prioridade a que está associado. Os pontos de verificação de prioridade 1 são destacados por folhas de estilo. • Notas informativas facultativas, para esclarecer exemplos, e ainda referências cruzadas que apontam para recomendações e pontos de verificação relacionados. • Um link para a seção do documento de técnicas ([TECHNIQUES] - em inglês ), onde são abordadas questões sobre como pôr em prática os pontos de verificação, com exemplos. • • • Cada um dos pontos de verificação foi elaborado de forma que fosse suficientemente específico, permitindo que qualquer pessoa que examine a página ou site possa verificar facilmente se o ponto de verificação em questão foi satisfeito. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 54 de 79 UPP – Unidade de Prospecção e Padronização 3.1 Convenções utilizadas neste documento Neste documento foram utilizadas as seguintes convenções editoriais: • • • Os nomes dos elementos aparecem em maiúsculas. Os nomes dos atributos aparecem em minúsculas. Os links para as definições são destacados por folhas de estilo. 4. Níveis de prioridade O grupo de trabalho atribuiu a cada ponto de verificação um nível de prioridade, com base no respectivo impacto, em termos de acessibilidade. [Prioridade 1] Pontos que os criadores de conteúdo Web devem satisfazer inteiramente. Se não o fizerem, um ou mais grupos de usuários ficarão impossibilitados de acessar as informações contidas no documento. A satisfação desse tipo de pontos é um requisito básico para que determinados grupos possam acessar documentos disponíveis na Web. [Prioridade 2] Pontos que os criadores de conteúdos na Web deveriam satisfazer. Se não o fizerem, um ou mais grupos de usuários terão dificuldades em acessar as informações contidas no documento. A satisfação desse tipo de pontos promoverá a remoção de barreiras significativas ao acesso a documentos disponíveis na Web. [Prioridade 3] Pontos que os criadores de conteúdos na Web podem satisfazer. Se não o fizerem, um ou mais grupos poderão se deparar com algumas dificuldades em acessar informações contidas nos documentos. A satisfação deste tipo de pontos irá melhorar o acesso a documentos armazenados na Web. Alguns pontos de verificação especificam um nível de prioridade que poderá mudar sob determinadas condições (explicitadas). 5. Conformidade Esta seção define três níveis de conformidade com este documento: Nível de conformidade "A": foram satisfeitos todos os pontos de verificação de prioridade 1; • Nível de conformidade "Duplo A": foram satisfeitos todos os pontos de verificação de prioridades 1 e 2; • Nível de conformidade "Triplo A": foram satisfeitos todos os pontos de verificação de prioridades 1, 2 e 3. • Nota: Os níveis de conformidade são apresentados por extenso no texto, para que sejam compreendidos quando traduzidos para discurso sonoro. Todas e quaisquer declarações de conformidade com este documento devem utilizar, obrigatoriamente, um dos seguintes formatos: Formato 1. Especificar: O título da recomendação: "Web Content Accessibility Guidelines 1.0". O (Uniform Resource Identifier) da recomendação: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505 • O nível de conformidade satisfeito: "A", "Duplo A" ou "Triplo A". • O âmbito abrangido pela declaração de conformidade (por ex., página, site ou porção definida de um site). • • Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 55 de 79 UPP – Unidade de Prospecção e Padronização Exemplo do formato 1: Esta página está de acordo com o documento do W3C "Web Content Accessibility Guidelines 1.0", disponível em http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, de nível "Duplo A". Formato 2. Incluir, em cada uma das páginas, em relação às quais se declara conformidade, um dos três símbolos fornecidos pelo W3C e estabelecer o link entre esse símbolo e a respectiva explicação (da autoria do W3C) do que representa essa declaração. Em [WCAG-ICONS] são encontradas informações sobre os símbolos e como inseri-los nas páginas. 6. Recomendações para a acessibilidade do conteúdo da Web Recomendação 1 - Fornecer alternativas ao conteúdo sonoro e visual Proporcionar conteúdo que, ao ser apresentado ao usuário, transmita, em essência, as mesmas funções e finalidade que o conteúdo sonoro ou visual. Mesmo que algumas pessoas não possam acessar diretamente imagens, filmes, sons, applets, continuam a poder acessar páginas que incluam informações equivalentes ao conteúdo visual ou sonoro. As informações equivalentes devem preencher as mesmas funções que o conteúdo visual ou sonoro. Assim, o equivalente textual de uma imagem de uma seta para cima, que estabelece o link a um sumário poderia ser "Ir para o sumário". Em alguns casos, o equivalente deve ainda descrever o aspecto do conteúdo visual (por ex., no caso de diagramas complexos) ou do conteúdo sonoro (por ex., no caso de áudio utilizado para fins educativos). Esta recomendação realça a importância de fornecer equivalentes textuais de conteúdo não textual (como imagens, áudio pré-gravado, vídeo). O poder dos equivalentes textuais reside na capacidade de serem comunicados de modo acessível a pessoas com diferentes deficiências, utilizando uma grande variedade de tecnologias. O texto pode ser rapidamente reproduzido por sintetizadores de voz e monitores Braille, e pode ser apresentado visualmente (em vários tamanhos) em monitores ou em papel. O discurso sintetizado é essencial para cegos e para muitas pessoas com dificuldades de leitura, freqüentemente associadas à surdez, deficiências cognitivas ou de aprendizagem. O sistema Braille é fundamental tanto para pessoas cegas e surdas como para aquelas cuja única deficiência sensorial é a cegueira. O texto apresentado sob a forma visual beneficia tanto os surdos quanto a maioria dos usuários da Web. O fornecimento de equivalentes não textuais (imagens, vídeos, áudio pré-gravado) de texto é também benéfico para determinados usuários, especialmente para aqueles que não lêem ou têm dificuldade de leitura. Em alguns filmes e apresentações visuais, é possível que a ação visual (como a linguagem de sinais ou outras "pistas" visuais) não seja acompanhada de informação sonora suficiente para transmitir a idéia central com a mesma integridade e clareza. Se não forem fornecidas descrições verbais desse tipo de informações, quem não vê (ou não pode olhar) o conteúdo visual não poderá atingir o mesmo grau de compreensão. Pontos de verificação: 1.1 Fornecer um equivalente textual a cada elemento não textual (por ex., por meio de "alt" ou "longdesc", ou como parte do conteúdo do elemento). Isso abrange: imagens, representações gráficas do texto (incluindo símbolos), regiões de mapa de imagem, animações (por ex., GIF animados), applets e objetos programados, arte , frames, programas interpretáveis, imagens utilizadas como sinalizadores de pontos de enumeração, espaçadores, botões gráficos, sons (reproduzidos ou não com interação do usuário), arquivos de áudio independentes, trilhas áudio de vídeo e trechos de vídeo. [Prioridade 1] Por exemplo, em HTML: Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 56 de 79 UPP – Unidade de Prospecção e Padronização Utilizar "alt" para os elementos IMG, INPUT e APPLET, ou fornecer um equivalente textual como parte do conteúdo dos elementos OBJECT e APPLET. • No caso de um conteúdo complexo (um gráfico ou diagrama), em que o texto "alt" não proporcione um equivalente textual suficientemente completo, fornecer uma descrição adicional, utilizando "longdesc" com IMG ou FRAME, um link dentro de um elemento OBJECT ou um link descritivo. • Em mapas de imagem, utilizar o atributo "alt" com AREA ou o elemento MAP com elementos A por conteúdo. • Ver também o ponto de verificação 9.1 e o ponto de verificação 13.10. Técnicas para o ponto de verificação 1.1 1.2 Fornecer links de texto redundantes relativos a cada região ativa de um mapa de imagem armazenado no servidor. [Prioridade 1] Ver também o ponto de verificação 1.5 e o ponto de verificação 9.1. Técnicas para o ponto de verificação 1.2 1.3 Fornecer uma descrição sonora das informações importantes veiculadas em trechos visuais das apresentações multimídia, até que os agentes do usuário consigam ler, automaticamente e em voz alta, o equivalente textual dos trechos visuais. [Prioridade 1] Sincronizar a descrição sonora e a pista de áudio, de acordo com o disposto no ponto de verificação 1.4. Para informações sobre equivalentes textuais de informações visuais, consultar o ponto de verificação 1.1. Técnicas para o ponto de verificação 1.3 1.4 Em apresentações multimídia baseadas em tempo (filme ou animação), sincronizar as alternativas equivalentes (legendas ou descrições sonoras dos trechos visuais) e a apresentação. [Prioridade 1] Técnicas para o ponto de verificação 1.4 1.5 Fornecer links textuais redundantes para cada região ativa dos mapas de imagem no cliente, até que os agentes do usuário proporcionem equivalentes textuais dos links a mapas de imagem armazenados no cliente. [Prioridade 3] Ver também o ponto de verificação 1.2 e o ponto de verificação 9.1. Técnicas para o ponto de verificação 1.5 Recomendação 2 - Não recorrer apenas à cor Assegurar a percepção do texto e dos elementos gráficos quando vistos sem cores. Se a cor for o único meio utilizado para transmitir informações, as pessoas que não são capazes de diferenciar certas cores, bem como os usuários de dispositivos não coloridos ou com monitores não visuais, não receberão essas informações. Se as cores de fundo e de primeiro plano tiverem tons muito próximos, podem não ser suficientemente contrastantes quando vistas em telas monocromáticas ou por pessoas com diferentes cromodeficiências. Pontos de verificação: 2.1 Assegurar que todas as informações veiculadas com cor estejam também disponíveis sem cor, por exemplo a partir do contexto ou de marcações. [Prioridade 1] Técnicas para o ponto de verificação 2.1 2.2 Assegurar que a combinação de cores entre o fundo e o primeiro plano seja suficientemente contrastante para poder ser vista por pessoas com cromodeficiências, bem como pelas que utilizam monitores de vídeo monocromáticos. [Prioridade 2 para imagens; prioridade 3 para texto]. Técnicas para o ponto de verificação 2.2 Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 57 de 79 UPP – Unidade de Prospecção e Padronização Recomendação 3 - Utilizar corretamente marcações e folhas de estilo Marcar os documentos com os elementos estruturais adequados. Controlar a apresentação por meio de folhas de estilo, em vez de elementos de apresentação e atributos. A utilização incorreta -- isto é, sem observar as especificações -- de marcações prejudica a acessibilidade. A utilização errônea de uma marcação ou efeito de apresentação (por ex., utilizar uma tabela para a disposição de objetos na página, ou um cabeçalho para mudar o tamanho do tipo de fonte) torna difícil, aos usuários com software especializado, compreender a organização da página e navegarem nela. Além disso, a utilização de marcações de apresentação em vez de marcações estruturais para representar uma estrutura (por ex., construir, com um elemento PRE de HTML, aquilo que parece uma tabela de dados) dificulta a apresentação inteligível da página a outros dispositivos (ver a descrição da diferença entre conteúdo, estrutura e apresentação). Os criadores de conteúdo Web podem se sentir tentados a fazer uso (ou mau uso) de esquemas construtivos que produzam um determinado efeito de formatação em navegadores mais antigos. Já que tais práticas podem provocar problemas de acesso, é necessário avaliar se a formatação em questão é tão importante que compense o risco de tornar o documento inacessível a parte dos usuários. No extremo oposto, os criadores de conteúdo não podem sacrificar determinadas marcações só porque um determinado navegador ou tecnologia de apoio não as trata corretamente. Por exemplo, é correta a utilização do elemento TABLE do HTML para marcar informações tabulares, mesmo que alguns leitores de tela não consigam processar texto lado a lado, como deveria ser (ver ponto de verificação 10.3). A utilização correta de TABLE e a criação de tabelas passíveis de transformação harmoniosa (ver a recomendação 5) permite que o software reproduza tabelas de outras maneiras além da forma de grades com duas dimensões. Pontos de verificação: 3.1 Sempre que existir uma linguagem de marcação apropriada, utilizar marcações em vez de imagens para transmitir informações. [Prioridade 2] Por exemplo, utilizar MathML para marcar equações matemáticas, e folhas de estilo para formatar texto e organizar a sua paginação (disposição na página). Além disso, evitar o uso de imagens para representar texto -- utilizar, em vez disso, texto e folhas de estilo. Ver também a recomendação 6 e a recomendação 11. Técnicas para o ponto de verificação 3.1 3.2 Criar documentos passíveis de validação por gramáticas formais, publicadas. [Prioridade 2] Por exemplo, incluir uma declaração de tipo de documento no início do documento, que se refira a uma publicada (por ex., a DTD estrita do HTML 4.0). Técnicas para o ponto de verificação 3.2 3.3 Utilizar folhas de estilo para controlar a paginação (disposição em página) e a apresentação. [Prioridade 2] Por exemplo, utilizar a propriedade 'font' do CSS ao invés do elemento FONT do HTML no controle de estilos de tipo de fonte. Técnicas para o ponto de verificação 3.3 3.4 Utilizar unidades relativas, e não absolutas, nos valores dos atributos da linguagem de marcação e nos valores das propriedades das folhas de estilo. [Prioridade 2] Por exemplo, em CSS, utilizar 'em' ou percentagens em vez das unidades absolutas 'pt' ou 'cm'. Se forem utilizadas unidades absolutas, deve-se verificar se o conteúdo reproduzido é utilizável (ver a seção sobre validação). Técnicas para o ponto de verificação 3.4 3.5 Utilizar elementos de cabeçalho indicativos da estrutura do documento, de acordo com as especificações. [Prioridade 2] Por exemplo, em HTML, utilizar H2 para indicar uma subseção de H1. Não utilizar cabeçalhos para produzir efeitos de tipo de fonte. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 58 de 79 UPP – Unidade de Prospecção e Padronização Técnicas para o ponto de verificação 3.5 3.6 Marcar corretamente listas e pontos de enumeração em listas. [Prioridade 2] Por exemplo, em HTML, hierarquizar corretamente as listas OL, UL e DL. Técnicas para o ponto de verificação 3.6 3.7 Marcar as citações. Não utilizar marcações de citação para efeitos de formatação, como, por exemplo, o avanço de texto. [Prioridade 2] Por exemplo, em HTML, utilizar os elementos Q e BLOCKQUOTE para, respectivamente, marcar citações curtas e mais extensas. Técnicas para o ponto de verificação 3.7 Recomendação 4 - Indicar claramente qual o idioma utilizado Utilizar marcações que facilitem a pronúncia e a interpretação de abreviaturas ou texto em língua estrangeira. Se os criadores de conteúdo marcarem as mudanças de idioma em um documento, os sintetizadores de voz e os dispositivos Braille podem passar automaticamente para o novo idioma, tornando o documento mais acessível a usuários multilíngües. Os criadores de conteúdo devem identificar o idioma predominante do conteúdo do documento (por meio de marcações ou dos cabeçalhos do ). Devem ainda fornecer a versão por extenso de quaisquer abreviaturas e siglas. Além de ser um auxiliar precioso para as tecnologias de apoio, a marcação do idioma permite que os mecanismos de busca procurem e identifiquem documentos em um determinado idioma. A marcação do idioma aumenta também a legibilidade da Web para todos os usuários, incluindo os que têm deficiências de aprendizagem, cognitivas ou surdez. Se as abreviaturas e as mudanças de idioma não forem identificadas, podem se tornar indecifráveis quando forem utilizados comandos por voz ou sistemas Braille. Pontos de verificação: 4.1 Identificar claramente quaisquer mudanças de idioma no texto de um documento, bem como nos equivalentes textuais (por ex., legendas). [Prioridade 1] Por exemplo, em HTML, utilizar o atributo "lang". Em , utilizar "xml:lang". Técnicas para o ponto de verificação 4.1 4.2 Especificar por extenso cada abreviatura ou sigla quando da sua primeira ocorrência em um documento. [Prioridade 3] Por exemplo, em HTML, utilizar o atributo "title" ou os elementos ABBR e ACRONYM. Fornecer a versão por extenso no corpo principal do documento também contribui para a sua melhor utilização. Técnicas para o ponto de verificação 4.2 4.3 Identificar o principal idioma utilizado nos documentos. [Prioridade 3] Por exemplo, em HTML, definir o atributo "lang" no elemento HTML. Em XML, utilizar "xml:lang". Os operadores de servidores devem configurá-los de modo a tirar partido dos mecanismos de negociação de conteúdo do HTTP ([RFC2068], seção 14.13), para que os clientes possam baixar automaticamente documentos no idioma preferido. Técnicas para o ponto de verificação 4.3 Recomendação 5 - Criar tabelas passíveis de transformação harmoniosa Assegurar que as tabelas têm as marcações necessárias para poderem ser transformadas harmoniosamente por navegadores acessíveis e outros agentes do usuário. Devem ser utilizadas tabelas para marcar as informações tabulares genuínas ("tabelas de dados"). Os criadores de conteúdo devem evitar utilizá-las para efeitos de paginação ("tabelas de disposição"). Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 59 de 79 UPP – Unidade de Prospecção e Padronização As tabelas, qualquer que seja seu uso, acarretam problemas aos usuários de leitores de tela (ver o ponto de verificação 10.3). Alguns agentes do usuário permitem que os usuários naveguem entre as células das tabelas e acessem o cabeçalho e outras informações sobre as células. Se não forem adequadamente marcadas, essas tabelas não irão fornecer as informações apropriadas aos agentes do usuário. (Ver também a recomendação 3.) Os pontos de verificação que se seguem se destinam a beneficiar diretamente as pessoas que acessam tabelas por meios sonoros (por ex., um leitor de tela ou um computador pessoal para automóvel) ou que vêem apenas uma parte da página de cada vez (por ex., usuários cegos ou com baixa visão que utilizem comando por voz ou um monitor Braille ou ainda quem usa monitores de vídeo de dimensões reduzidas). Pontos de verificação: 5.1 Em tabelas de dados, identificar os cabeçalhos de linha e de coluna. [Prioridade 1] Por exemplo, em HTML, utilizar TD para identificar as células de dados e TH para identificar os cabeçalhos. Técnicas para o ponto de verificação 5.1 5.2 Em tabelas de dados com dois ou mais níveis lógicos de cabeçalhos de linha ou de coluna, utilizar marcações para associar as células de dados às células de cabeçalho. [Prioridade 1] Por exemplo, em HTML, utilizar THEAD, TFOOT e TBODY para agrupar linhas, COL e COLGROUP para agrupar colunas, e os atributos "axis", "scope" e "headers" para descrever relações mais complexas entre os dados. Técnicas para o ponto de verificação 5.2 5.3 Não utilizar tabelas para efeitos de disposição em página, a não ser que a tabela continue a fazer sentido depois de ser linearizada. Se não for o caso, fornecer um equivalente alternativo (que pode ser uma versão linearizada). [Prioridade 2] Nota: Até que os agentes do usuário passem a suportar o posicionamento por folhas de estilo, as tabelas não devem ser utilizadas para produzir uma determinada disposição na página. Ver também o ponto de verificação 3.3. Técnicas para o ponto de verificação 5.3 5.4 Se for utilizada uma tabela para efeitos de disposição em página, não utilizar qualquer marcação estrutural para efeitos de formatação visual. [Prioridade 2] Por exemplo, em HTML, não utilizar o elemento TH para fazer com que o conteúdo de uma célula (que não seja de cabeçalho de tabela) apareça centrado e em negrito. Técnicas para o ponto de verificação 5.4 5.5 Fornecer resumos das tabelas. [Prioridade 3] Por exemplo, em HTML, utilizar o atributo "summary" do elemento TABLE. Técnicas para o ponto de verificação 5.5 5.6 Fornecer abreviaturas para os rótulos de cabeçalho. [Prioridade 3] Por exemplo, em HTML, utilizar o atributo "abbr" no elemento TH. Técnicas para o ponto de verificação 5.6 Ver também o ponto de verificação 10.3. Recomendação 6 - Assegurar que as páginas dotadas de novas tecnologias sejam transformadas harmoniosamente Assegurar que as páginas são acessíveis mesmo quando as tecnologias mais recentes não forem suportadas ou tenham sido desativadas. Embora os criadores de conteúdo Web sejam encorajados a utilizar novas tecnologias para resolver problemas decorrentes dos mecanismos existentes, devem levar em consideração que as Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 60 de 79 UPP – Unidade de Prospecção e Padronização páginas que produzirem devem poder ser vistas com os navegadores mais antigos e pelos usuários que optem por desativar as novas funcionalidades. Pontos de verificação: 6.1 Organizar os documentos de tal forma que possam ser lidos sem recurso a folhas de estilo. Por exemplo, se um documento em HTML for reproduzido sem as folhas de estilo que lhe estão associadas, deve continuar a ser possível lê-lo. [Prioridade 1] Todo o conteúdo organizado de forma lógica deve ser apresentado em uma ordem compreensível, mesmo que tenha sido desativada a funcionalidade das folhas de estilo ou que esta não seja suportada. Técnicas para o ponto de verificação 6.1 6.2 Assegurar que os equivalentes de conteúdo dinâmico sejam atualizados sempre que esse conteúdo mudar. [Prioridade 1] Técnicas para o ponto de verificação 6.2 6.3 Assegurar que todas as páginas possam ser utilizadas mesmo que os programas interpretáveis, os applets ou outros objetos programados tenham sido desativados ou não sejam suportados. Se isso não for possível, fornecer informações equivalentes em uma página alternativa, acessível. [Prioridade 1] Por exemplo, assegurar que os links que desencadeiam programas interpretáveis funcionem mesmo quando estes tiverem sido desativados ou não forem suportados (por ex., não utilizar "javascript:" como destino do link). Se não for possível fazer com que a página seja utilizada sem programas interpretáveis, fornecer um equivalente textual com o elemento NOSCRIPT ou utilizar um programa interpretável presente no servidor em vez de no cliente, ou ainda fornecer uma página alternativa, de acordo com o disposto no ponto de verificação 11.4. Ver também a recomendação 1. Técnicas para o ponto de verificação 6.3 6.4 Em programas interpretáveis e applets, assegurar que a resposta a eventos seja independente do dispositivo de entrada. [Prioridade 2] Ver a definição de independente de dispositivos. Técnicas para o ponto de verificação 6.4 6.5 Assegurar a acessibilidade do conteúdo dinâmico ou fornecer apresentação ou página alternativas. [Prioridade 2] Por exemplo, em HTML utilizar NOFRAMES no final de cada conjunto de frames. Em determinadas aplicações, os programas interpretados no servidor podem ser de acesso mais fácil do que os interpretados no cliente. Técnicas para o ponto de verificação 6.5 Ver também o ponto de verificação 11.4. Recomendação 7 - Assegurar o controle do usuário sobre as alterações temporais do conteúdo Assegurar a possibilidade de interrupção momentânea ou definitiva do movimento, intermitência, transcurso ou atualização automática de objetos ou páginas. Algumas pessoas com deficiências cognitivas ou visuais não conseguem ler texto em movimento com a rapidez necessária ou podem mesmo não serem capazes de lê-lo. Além disso, para pessoas com deficiências cognitivas, o movimento pode ser uma fonte de distração que faz com que o resto da página se torne impossível de ler. Os leitores de tela não são capazes de ler texto em movimento; as pessoas com deficiências físicas podem não conseguir se moverem com a rapidez ou precisão que a interação com objetos em movimento exige. Nota: O conjunto dos pontos de verificação que se segue apela e depende exclusivamente da responsabilidade dos criadores de conteúdo até que os agentes do usuário ofereçam mecanismos adequados para o controle de funcionalidades. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 61 de 79 UPP – Unidade de Prospecção e Padronização Pontos de verificação: 7.1 Evitar concepções que possam provocar intermitência da tela, até que os agentes do usuário possibilitem o seu controle. [Prioridade 1] Nota: Uma intermitência ou pulsar na faixa de 4 a 59 pulsos por segundo (Hertz), sendo o pico de sensibilidade 20 pulsos por segundo, bem como uma rápida passagem de uma quase escuridão para uma iluminação excessiva (como a que ocorre nas luzes de tipo "strobe"), pode desencadear ataques ou ausências nas pessoas com epilepsia fotossensível. Técnicas para o ponto de verificação 7.1 7.2 Evitar situações que possam provocar o piscar do conteúdo das páginas (isto é, alterar a apresentação a intervalos regulares, como ligar e desligar), até que os agentes do usuário possibilitem o controle desse efeito. [Prioridade 2] Técnicas para o ponto de verificação 7.2 7.3 Evitar páginas contendo movimento, até que os agentes do usuário possibilitem a imobilização do conteúdo. [Prioridade 2] Sempre que uma página contiver movimento, fornecer (em programa interpretável ou applet) mecanismo para imobilizá-lo e impedir atualizações. A utilização de folhas de estilo dotadas de programas interpretáveis destinados à criação de movimento permite que os usuários tenham mais facilidade em desativá-las ou fazer com que os seus efeitos sejam anulados. Ver também a recomendação 8. Técnicas para o ponto de verificação 7.3 7.4 Não criar páginas de atualização automática periódica, até que os agentes do usuário possibilitem parar essa atualização. [Prioridade 2] Por exemplo, em HTML, não provocar a atualização automática das páginas por meio da inclusão de "HTTP-EQUIV=refresh", até que os agentes do usuário dêem aos usuários a possibilidade de desativarem essa funcionalidade. Técnicas para o ponto de verificação 7.4 7.5 Não utilizar marcações para redirecionar as páginas automaticamente, até que os agentes do usuário possibilitem parar o redirecionamento automático. Ao invés de utilizar marcações, configurar o servidor para que execute os redirecionamentos. [Prioridade 2] Técnicas para o ponto de verificação 7.5 Nota: Os elementos BLINK e MARQUEE não são definidos em qualquer especificação HTML do W3C, e não devem ser utilizados. Ver também a recomendação 11. Recomendação 8 - Assegurar a acessibilidade direta de interfaces do usuário integradas Assegurar que a interface do usuário obedeça a princípios de design para a acessibilidade: acesso independente de dispositivos, operacionalidade pelo teclado, emissão automática de voz (verbalização). Sempre que um objeto integrado tiver uma "interface própria", essa interface -- tal como a interface do próprio navegador -- deve ser acessível. Se a interface do objeto integrado não for acessível, deve ser fornecida uma solução alternativa. Nota: Para obter informações sobre interfaces acessíveis, devem ser consultados os documentos de recomendações para a acessibilidade de agentes do usuário([WAI-USERAGENT]) e de recomendações para a acessibilidade de ferramentas de criação de conteúdo ([WAI-AUTOOL]). Ponto de verificação: 8.1 Criar elementos de programação, tais como programas interpretáveis e applets, diretamente acessíveis pelas tecnologias de apoio ou com elas compatíveis [prioridade 1 se a funcionalidade for importante e não estiver presente em outro local; prioridade 2, se não for o caso]. Ver também a recomendação 6. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 62 de 79 UPP – Unidade de Prospecção e Padronização Técnicas para o ponto de verificação 8.1 Recomendação 9 - Projetar páginas considerando a independência de dispositivos Utilizar funções que permitam a ativação de elementos de página por meio de uma grande variedade de dispositivos de entrada de comandos. Acesso independente de dispositivos significa que o usuário pode interagir com o agente do usuário ou com o documento por meio do dispositivo de entrada (ou de saída) de comandos de sua preferência: mouse, teclado, voz, ponteiro de cabeça, ou outro. Se, por exemplo, um controle de formulário puder apenas ser acessado com o mouse, quem estiver usando a página sem vê-la, com comandos por voz ou com um teclado, ou quem estiver usando outro dispositivo apontador, não poderá utilizar o formulário. Nota: O fornecimento de equivalentes textuais de mapas de imagem ou de imagens utilizadas como links permite que os usuários interajam com eles sem necessidade de um dispositivo apontador. Ver também a recomendação 1. Geralmente, as páginas que permitem interação pelo teclado são também acessíveis por meio das interfaces de comando por voz ou de linha de comandos. Pontos de verificação: 9.1 Fornecer mapas de imagem armazenados no cliente ao invés de no servidor, exceto quando as regiões não puderem ser definidas por forma geométrica disponível. [Prioridade 1] Ver também o ponto de verificação 1.1, o ponto de verificação 1.2 e o ponto de verificação 1.5. Técnicas para o ponto de verificação 9.1 9.2 Assegurar que qualquer elemento dotado de interface própria possa funcionar de modo independente de dispositivos. [Prioridade 2] Ver a definição de independente de dispositivos. Ver também a recomendação 8. Técnicas para o ponto de verificação 9.2 9.3 Em programas interpretáveis, especificar respostas a eventos, preferindo-as a rotinas dependentes de dispositivos. [Prioridade 2] Técnicas para o ponto de verificação 9.3 9.4 Criar uma seqüência lógica de tabulação para percorrer links, controles de formulários e objetos. [Prioridade 3] Por exemplo, em HTML, especificar a ordem de tabulação por meio do atributo "tabindex" ou ter um design de página claro e lógico. Técnicas para o ponto de verificação 9.4 9.5 Fornecer atalhos por teclado que apontem para links importantes (incluindo os contidos em mapas de imagem armazenados no cliente), controles de formulários e grupo de controles de formulários. [Prioridade 3] Por exemplo, em HTML, especificar atalhos por meio do atributo "accesskey". Técnicas para o ponto de verificação 9.5 Recomendação 10 - Utilizar soluções de transição Utilizar soluções de acessibilidade transitórias, para que as tecnologias de apoio e os navegadores mais antigos funcionem corretamente. Por exemplo, os navegadores mais antigos não permitem que os usuários se posicionem em caixas de edição vazias. Os leitores de tela mais antigos lêem séries de links consecutivos como se fossem um único link. Esses elementos ativos são, por isso, de acesso difícil ou mesmo impossível. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 63 de 79 UPP – Unidade de Prospecção e Padronização Além disso, a mudança da janela atual ou o aparecimento repentino de novas janelas pode ser um fator de grande desorientação para os usuários que não conseguirem ver que foi isso que aconteceu. Nota: Os pontos de verificação que se seguem são aplicáveis até que os agentes do usuário (incluindo as tecnologias de apoio) abordem essas questões. Estes pontos de verificação são classificados como "provisórios", o que significa que o grupo de trabalho de recomendações para o conteúdo Web, no momento da publicação deste documento, os considera válidos e necessários em termos da acessibilidade da Web. No entanto, o mesmo grupo de trabalho não prevê que estes pontos sejam necessários no futuro, quando as tecnologias da Web tiverem incorporado funcionalidades ou capacidades que se antevêem. Pontos de verificação: 10.1 Não provocar o aparecimento de janelas de sobreposição ou outras quaisquer, e não fazer com que o conteúdo da janela atual seja modificado sem que o usuário seja informado disso, até que os agentes do usuário tornem possível a desativação de janelas secundárias. [Prioridade 2] Por exemplo, em HTML, evitar a utilização de frames cujo destino seja uma nova janela. Técnicas para o ponto de verificação 10.1 10.2 Assegurar o correto posicionamento de todos os controles de formulários que tenham rótulos implicitamente associados, até que os agentes do usuário venham a suportar associações explícitas entre rótulos e controles de formulários. [Prioridade 2] O rótulo deve estar imediatamente antes do respectivo controle, na mesma linha (permitindo mais de um controle/tabela por linha), ou na linha que precede o controle (com um único rótulo e um único controle por linha). Ver também o ponto de verificação 12.4. Técnicas para o ponto de verificação 10.2 10.3 Proporcionar uma alternativa de texto linear (na mesma ou em outra página), em relação a todas as tabelas que apresentem o texto em colunas paralelas e com translineação, até que os agentes do usuário (incluindo as tecnologias de apoio) reproduzam corretamente texto colocado lado a lado. [Prioridade 3] Nota: Ver a definição de tabela linearizada. Esse ponto de verificação beneficia as pessoas cujos agentes do usuário (como alguns leitores de tela) não são capazes de tratar blocos de texto apresentados lado a lado; esse ponto de verificação não deve de modo algum desencorajar os criadores de conteúdo Web a utilizar tabelas para representar informações tabulares. Técnicas para o ponto de verificação 10.3 10.4 Incluir caracteres predefinidos de preenchimento nas caixas de edição e nas áreas de texto, até que os agentes do usuário tratem corretamente os controles vazios. [Prioridade 3] Por exemplo, em HTML, isso pode ser feito com TEXTAREA e INPUT. Técnicas para o ponto de verificação 10.4 10.5 Inserir, entre links adjacentes, caracteres que não funcionem como link e sejam passíveis de impressão (com um espaço de início e outro de fim), até que os agentes do usuário (incluindo as tecnologias de apoio) reproduzam clara e distintamente os links adjacentes. [Prioridade 3] Técnicas para o ponto de verificação 10.5 Recomendação 11 - Utilizar tecnologias e recomendações do W3C Utilizar tecnologias do W3C (de acordo com suas especificações) e seguir as recomendações de acessibilidade. Quando não for possível utilizar tecnologia W3C, ou quando tal utilização produzir materiais que não possam ser objeto de transformação harmoniosa, fornecer uma versão alternativa, acessível, do conteúdo. As presentes recomendações recomendam tecnologias do W3C (por ex., HTML, CSS), por várias razões: • As tecnologias do W3C incluem funções de acessibilidade "integradas". Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 64 de 79 UPP – Unidade de Prospecção e Padronização As especificações do W3C são apreciadas nas fases iniciais dos projetos, para garantir que as questões de acessibilidade sejam levadas em conta na fase de criação. • As especificações do W3C são desenvolvidas segundo um processo aberto e consensual no setor de informática. • Muitos formatos não não desenvolvidos pelo W3C (por ex., , Shockwave, etc.) exigem suplementos, ou aplicações independentes. Freqüentemente não é possível ver esses formatos, nem navegar neles, com os agentes do usuário atuais (incluindo as tecnologias de apoio). Se forem evitadas funções não gerenciadas pelo W3C e funcionalidades não normalizadas (elementos, atributos, propriedades e extensões exclusivos de determinados fabricantes), as páginas tendem a se tornar mais acessíveis a um maior número de usuários de diversos equipamentos e programas. Quando for necessário recorrer a tecnologias não acessíveis (proprietárias ou não), devem ser fornecidas páginas acessíveis equivalentes. Mesmo quando se empregam tecnologias do W3C, seu uso deve observar as recomendações para a acessibilidade. Ao utilizar novas tecnologias, deve-se garantir que elas sejam passíveis de transformação harmoniosa (Ver também a recomendação 6.). Nota: A conversão de documentos (a partir de PDF, PostScript, ) para linguagens de marcação do W3C (como o HTML ou o ) nem sempre resulta em documentos acessíveis. Assim, cada uma das páginas deve ser validada, mediante a verificação da sua acessibilidade e facilidade de utilização, logo após o processo de conversão (consultar a seção sobre validação). Se uma página não for convertida pronta e convenientemente, é necessário rever o seu conteúdo até que a representação original seja adequadamente convertida, ou fornecer uma versão em HTML ou em texto simples. Pontos de verificação: 11.1 Utilizar tecnologias do W3C sempre disponíveis e adequadas a uma determinada tarefa; utilizar as versões mais recentes, desde que suportadas. [Prioridade 2] Para saber onde encontrar as mais recentes especificações do W3C e suporte relativo à interface do usuário de WAI (com informações sobre os agentes que suportam as especificações W3C), consultar a lista de referências. Técnicas para o ponto de verificação 11.1 11.2 Evitar funcionalidades desatualizadas de tecnologias do W3C. [Prioridade 2] Por exemplo, em HTML, não utilizar o elemento FONT, já desatualizado; utilizar, em seu lugar, folhas de estilo (por ex., a propriedade 'font' do CSS). Técnicas para o ponto de verificação 11.2 11.3 Fornecer informações que possibilitem aos usuários receber os documentos de acordo com as suas preferências (por ex., por idioma ou por tipo de conteúdo) [Prioridade 3] Nota: Sempre que possível, utilizar a negociação de conteúdo. Técnicas para o ponto de verificação 11.3 11.4 Se, apesar de todos os esforços, não for possível criar uma página acessível, fornecer um link a uma página alternativa que utilize tecnologias do W3C, seja acessível, contenha informações (ou funcionalidade) equivalentes e seja atualizada tão freqüentemente quanto a página original, considerada inacessível. [Prioridade 1] Técnicas para o ponto de verificação 11.4 Nota: Os criadores de conteúdo Web devem recorrer a páginas alternativas apenas no caso de falharem todas as outras soluções. Isso porque as páginas alternativas são atualizadas com menor freqüência do que as páginas originais. Uma página desatualizada pode ser tão frustrante quanto uma inacessível, já que, em ambos os casos, as informações apresentadas na página original não estão disponíveis. A geração automática de páginas alternativas pode conduzir a atualizações mais freqüentes, mas os criadores de conteúdo devem garantir que as páginas geradas façam sempre sentido e permitir que os usuários possam navegar em um site tendo como ponto de partida os links localizados nas páginas principais, nas alternativas ou em ambas. Antes de recorrer a uma página Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 65 de 79 UPP – Unidade de Prospecção e Padronização alternativa, deve-se reavaliar o design da página original. Torná-la acessível eqüivale a melhorá-la em benefício de todos os usuários, indistintamente. Recomendação 12 - Fornecer informações de contexto e orientações. Fornecer contexto e orientações para ajudar os usuários a compreenderem páginas ou elementos complexos. O agrupamento de elementos e o fornecimento de informações de contexto acerca da relação existente entre elementos pode ser de grande utilidade para todos os usuários. As relações complexas entre as diferentes partes de uma página podem ser difíceis de interpretar por pessoas com deficiências cognitivas ou de visão. Pontos de verificação: 12.1 Dar, a cada frame, um título que facilite a identificação dos frames e sua navegação. [Prioridade 1] Por exemplo, em HTML, utilizar o atributo "title" nos elementos FRAME. Técnicas para o ponto de verificação 12.1 12.2 Descrever a finalidade dos frames e o modo como se relacionam entre si, se isso não for óbvio a partir unicamente dos títulos. [Prioridade 2] Por exemplo, em HTML, utilizar "longdesc" ou um link descritivo. Técnicas para o ponto de verificação 12.2 12.3 Dividir grandes blocos de informação em grupos mais fáceis de gerenciar, sempre que for o caso. [Prioridade 2] Por exemplo, em HTML, utilizar OPTGROUP para agrupar elementos OPTION dentro de um SELECT; agrupar controles de formulários por meio de FIELDSET e de LEGEND; utilizar listas hierárquicas sempre que for adequado; utilizar cabeçalhos para estruturar documentos. Ver também a recomendação 3. Técnicas para o ponto de verificação 12.3 12.4 Associar explicitamente os rótulos aos respectivos controles. [Prioridade 2] Por exemplo, em HTML, utilizar LABEL e o respectivo atributo "for". Técnicas para o ponto de verificação 12.4 Recomendação 13 - Fornecer mecanismos de navegação claros Fornecer mecanismos de navegação coerentes e sistematizados -informações de orientação, barras de navegação, mapa do site -- para aumentar as probabilidades de uma pessoa encontrar o que procura em um dado site. A existência de mecanismos de navegação claros e coerentes é importante para as pessoas com deficiências cognitivas ou cegueira, e beneficia a todos os usuários. Pontos de verificação: 13.1 Identificar claramente o destino de cada link. [Prioridade 2] O texto do link deve ser suficientemente ilustrativo para fazer sentido quando for lido fora de contexto - isoladamente ou integrado em uma seqüência de links. O texto do link deve, além disso, ser conciso. Por exemplo, em HTML, escrever "Dados sobre a versão 4.3", em vez de "Clicar aqui". Além da clareza no texto do link, os criadores de conteúdo podem tornar o destino de um link ainda mais claro, utilizando um título de link informativo (por ex., em HTML, utilizando o atributo "title"). Técnicas para o ponto de verificação 13.1 13.2 Fornecer metadados para acrescentar informações semânticas a páginas ou sites. [Prioridade 2] Por exemplo, utilizar ([RDF]) para indicar a autoria de um documento, o tipo de conteúdo. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 66 de 79 UPP – Unidade de Prospecção e Padronização Nota: Alguns agentes do usuário para HTML são capazes de construir ferramentas de navegação a partir das relações existentes entre documentos, descritas pelo elemento LINK do HTML e pelos atributos "rel" ou "rev" (por ex., rel="seguinte", rel="anterior", rel="índice remissivo"). Ver também o ponto de verificação 13.5. Técnicas para o ponto de verificação 13.2 13.3 Dar informações sobre a organização geral de um site (por ex., por meio de um mapa do site ou de um sumário). [Prioridade 2] Ao descrever a organização de um site, destacar e explicar as funções de acessibilidade nele disponíveis. Técnicas para o ponto de verificação 13.3 13.4 Utilizar os mecanismos de navegação de maneira coerente e sistemática. [Prioridade 2] Técnicas para o ponto de verificação 13.4 13.5 Fornecer barras de navegação para destacar e dar acesso ao mecanismo de navegação. [Prioridade 3] Técnicas para o ponto de verificação 13.5 13.6 Agrupar links relacionados entre si, identificar o grupo (em benefício dos agentes do usuário) e, até que os agentes do usuário se encarreguem de tal função, fornecer um modo de contornar determinado grupo. [Prioridade 3] Técnicas para o ponto de verificação 13.6 13.7 Se forem oferecidas funções de pesquisa, ativar diferentes tipos de pesquisa de modo a corresponderem a diferentes níveis de competência e às preferências dos usuários. [Prioridade 3] Técnicas para o ponto de verificação 13.7 13.8 Colocar informações identificativas no início de cabeçalhos, parágrafos, listas. [Prioridade 3] Nota: Esta ação, a que se dá vulgarmente o nome de "carga inicial", é especialmente útil para pessoas que acessam informações a partir de dispositivos seqüenciais, como é o caso dos sintetizadores de voz. Técnicas para o ponto de verificação 13.8 13.9 Fornecer informações sobre coleções de documentos (isto é, documentos compostos por várias páginas). [Prioridade 3] Por exemplo, em HTML, especificar coleções de documentos por meio do elemento LINK e dos atributos "rel" e "rev". Outra maneira de criar uma coleção é construindo um arquivo (por ex., com zip, tar e gzip, stuffit) das diferentes páginas. Nota: A melhoria de desempenho obtida no processamento offline pode tornar a navegação menos dispendiosa para pessoas com deficiências ou que naveguem mais lentamente. Técnicas para o ponto de verificação 13.9 13.10 Fornecer meios para ignorar inserções de arte ASCII com várias linhas. [Prioridade 3] Ver o ponto de verificação 1.1 e o exemplo de arte ASCII apresentado no glossário. Técnicas para o ponto de verificação 13.10 Recomendação 14 - Assegurar a clareza e a simplicidade dos documentos. Assegurar a produção de documentos claros e simples, para que sejam mais fáceis de compreender. A utilização de paginação (disposição em página) coerente e sistemática, de gráficos reconhecíveis e de uma linguagem fácil de compreender beneficia a todos os usuários. Em particular, auxiliam as pessoas com deficiências cognitivas ou com dificuldades de leitura. (No entanto, é necessário garantir que as imagens tenham equivalentes textuais, para benefício dos cegos, pessoas com baixa visão ou quaisquer usuários que não tenham possibilidade de ver objetos gráficos ou tenham optado por não vê-los. Ver também a recomendação 1.) A utilização de uma linguagem clara e simples proporciona uma comunicação eficaz. O acesso a informações escritas pode ser difícil para pessoas com deficiências cognitivas ou de aprendizagem. Uma linguagem clara e simples beneficia também todas as pessoas cuja língua materna não seja a da página em questão, incluindo as pessoas que se comunicam por linguagem de sinais. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 67 de 79 UPP – Unidade de Prospecção e Padronização Pontos de verificação: 14.1 Utilizar linguagem a mais clara e simples possível, adequada ao conteúdo do site. [Prioridade 1] Técnicas para o ponto de verificação 14.1 14.2 Complementar o texto com apresentações gráficas ou sonoras, sempre que facilitarem a compreensão da página. [Prioridade 3] Ver também a recomendação 1. Técnicas para o ponto de verificação 14.2 14.3 Criar um estilo de apresentação coerente e sistemático, ao longo das diferentes páginas. [Prioridade 3] Técnicas para o ponto de verificação 14.3 Anexo A -- Validação A validação da acessibilidade deve ser feita por meio de ferramentas automáticas e da revisão direta. Os métodos automáticos são geralmente rápidos, mas não são capazes de identificar todas as nuances da acessibilidade. A avaliação humana pode ajudar a garantir a clareza da linguagem e a facilidade da navegação. Começar por métodos de validação nas fases iniciais do desenvolvimento. As questões de acessibilidade identificadas antecipadamente serão mais fáceis de evitar ou corrigir. Os métodos de validação que se seguem são abordados com mais profundidade na seção de validação de documentos do documento de técnicas. 1. Utilizar uma ferramenta de acessibilidade automatizada, e uma ferramenta de validação de navegadores. Vale lembrar que as ferramentas de software não incidem sobre todas as questões da acessibilidade, tais como clareza de um texto, aplicabilidade de um equivalente textual. 2. Validar a sintaxe (por ex., HTML, XML). 3. Validar as folhas de estilo (por ex., CSS). 4. Utilizar um navegador exclusivamente textual ou um emulador. 5. Utilizar vários navegadores gráficos, com: • som e gráficos ativos; 6. sem gráficos; 7. sem som; 8. sem mouse; 9. sem carregar frames, programas interpretáveis, folhas de estilo ou applets. 10.Utilizar vários navegadores, antigos e recentes. 11.Utilizar um navegador de emissão automática de fala, um leitor de tela, software de ampliação, uma tela de pequenas dimensões. 12.Utilizar corretores ortográficos e gramaticais. Uma pessoa que, para ler uma página, precisa de um sintetizador de voz, pode não ser capaz de decifrar a melhor aproximação do sintetizador a uma palavra que contém erro de ortografia. A eliminação de problemas gramaticais aumenta o grau de compreensão. 13.Rever o documento, verificando sua clareza e simplicidade. A estatística de legibilidade, como a que é gerada por alguns programas de tratamento de texto, pode ser um valioso indicador de clareza e simplicidade. O melhor ainda é pedir a um revisor experiente que reveja o conteúdo escrito e avalie a clareza da redação. Os revisores podem também melhorar a adequação de um documento, já que podem identificar questões culturais potencialmente delicadas provenientes do tipo de linguagem ou do emprego de ícones. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 68 de 79 UPP – Unidade de Prospecção e Padronização 14.Peça a pessoas com deficiências que revejam os documentos. Esses usuários, com ou sem experiência, são uma fonte inestimável de informações sobre o estado dos documentos, no que diz respeito ao seu grau de acessibilidade e de facilidade de utilização. Anexo B -- Glossário acessível Diz-se do conteúdo que pode ser acessado por alguém com alguma incapacidade ou deficiência. applet Programa inserido em uma página da Web. tecnologia de apoio (ou assistiva) Software ou hardware especificamente concebido para ajudar pessoas com incapacidades ou deficiências a executarem atividades do cotidiano. A tecnologia de apoio abrange cadeiras de rodas, máquinas de leitura, dispositivos de impressão. No domínio da acessibilidade da Web, as tecnologias de apoio abrangem leitores de tela, ampliadores de tela, sintetizadores de voz e software de comando por voz, que funcionam em conjunto com os navegadores gráficos convencionais ( além de outros agentes do usuário). As tecnologias de apoio por hardware incluem teclados e dispositivos apontadores alternativos. arte ASCII Designa a combinação de caracteres textuais e símbolos utilizados para criar uma imagem. Por exemplo, o é o "smiley". A ilustração a seguir é uma figura em ASCII que mostra a relação entre a freqüência de pulsos luminosos e a reação fotoconvulsiva de pacientes com os olhos abertos, e com os olhos fechados [ignorar a figura em ASCII ou consultar a descrição do gráfico]: % __ __ __ __ __ __ __ __ __ __ __ __ __ __ 100 | * | 90 | * * | 80 | * * | 70 | @ * | 60 | @ * | 50 | * @ * | 40 | @ * | 30 | * @ @ @ * | 20 | | 10 | @ @ @ @ @ | 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 Frequência dos pulsos (hertz) ferramenta de criação de conteúdo Editores de , ferramentas de conversão de documentos, ferramentas que geram conteúdo Web a partir de bases de dados são, todas elas, exemplos de ferramentas de criação de conteúdo. Para mais informações sobre o desenvolvimento de ferramentas destinadas a garantir a acessibilidade, consulte as recomendações para a construção de ferramentas de criação de conteúdo acessível, "Authoring Tool Accessibility Guidelines" ([WAI-AUTOOLS]). retrocompatibilidade Característica dos designs que continuam a funcionar com versões antigas de uma linguagem, programa. Braille Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 69 de 79 UPP – Unidade de Prospecção e Padronização O sistema Braille adota seis pontos salientes, em disposições diferentes, para representar letras e algarismos, para que os cegos possam ler com as pontas dos dedos. A palavra "accessible" (acessível, em inglês) é apresentada a seguir em notação Braille: Um monitor Braille, vulgarmente conhecido como "monitor dinâmico Braille", levanta ou abaixa padrões de pontos, por meio de comandos emitidos por um dispositivo eletrônico, normalmente um computador. Consegue-se, assim, uma linha de texto em Braille com conteúdo dinâmico, já que é constantemente alterado. Os atuais monitores Braille têm dimensões que vão desde uma única célula (de seis ou oito pontos) até linhas de 80 células. A maioria comporta entre doze e vinte células por linha. criador de conteúdo Autor de páginas ou grafismos para sites da Web. desatualizado Elemento ou atributo que foi substituído por outro mais recente. Os elementos desatualizados podem se tornar obsoletos (não funcionais) em futuras versões de HTML. O sumário de elementos e atributos de HTML contido no documento de técnicas indica quais os elementos e atributos que estão desatualizados em relação ao HTML 4.0. Os autores devem evitar utilizá-los. Os agentes do usuário devem continuar a suportá-los por razões de retrocompatibilidade. independente de dispositivos Os usuários devem ser capazes de interagir com um agente do usuário (e com o documento por ele apresentado), utilizando dispositivos de entrada e de saída suportados, de sua escolha e de acordo com suas necessidades. Entre os dispositivos de entrada encontram-se apontadores, teclados, dispositivos Braille, ponteiros de cabeça e microfones. Vale lembrar que "suporte independente de dispositivos" não significa que os agentes do usuário suportem todos os dispositivos de entrada ou saída. Os agentes do usuário devem proporcionar mecanismos redundantes de entrada e de saída em relação aos dispositivos que suportam. Assim, se um agente do usuário suportar entradas por teclado e por mouse, os usuários devem ser capazes de interagir com todas as funcionalidades que utilizem teclado ou mouse. conteúdo, estrutura e apresentação dos documentos O conteúdo de um documento designa aquilo que ele transmite ao usuário por meio de linguagem natural, imagens, sons, filmes, animações. A estrutura de um documento é o modo como ele está organizado em termos lógicos (por exemplo, por capítulos, com ou sem uma introdução e um sumário). Um elemento (por ex., P, STRONG, BLOCKQUOTE, em HTML) que especifica a estrutura do documento é denominado elemento estrutural. A apresentação de um documento é a forma como ele é reproduzido (por ex., como matéria impressa, como apresentação gráfica bidimensional, sob forma exclusivamente textual, como discurso sintetizado, em Braille). Um elemento que especifica o tipo de apresentação de um documento (por ex., B, FONT, CENTER) é denominado elemento de apresentação. Considere o caso do cabeçalho de um documento, por exemplo. O conteúdo do cabeçalho é aquilo que ele "diz" (por ex., "Veleiros"). Em HTML, o cabeçalho é um elemento estrutural, marcado com um elemento H2, por exemplo. Finalmente, a apresentação do cabeçalho pode ter a forma de um bloco de texto, em negrito, na margem; uma linha de texto centrada; um título falado com um determinado estilo de voz (equiparado a um tipo de fonte aplicado à voz). HTML dinâmico (DHTML) é um termo de marketing aplicado a uma série de normas, entre as quais se incluem o HTML, as folhas de estilo, o modelo de objetos para documentos (Document Object Model, [DOM1]) e a inserção, nas páginas, de programas interpretáveis. Não existe, todavia, qualquer especificação do W3C que defina formalmente o DHTML. A maioria das recomendações é aplicável a documentos que utilizam DHTML, e as que abaixo se referem enfocam questões relacionadas com programas Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 70 de 79 UPP – Unidade de Prospecção e Padronização interpretáveis e folhas de estilo: recomendação 1, recomendação 3, recomendação 6, recomendação 7 e recomendação 9. elemento Neste documento, o termo "elemento" é empregado no sentido estrito que possui em SGML (onde "elemento" designa "construção sintática"), ou no sentido mais genérico de "tipo de conteúdo" (como vídeo ou som) ou de "construção lógica" (caso de um cabeçalho ou de uma lista). O segundo sentido realça o fato de uma recomendação, inspirada pelo HTML, poder ser aplicada facilmente a outra linguagem de marcação. Observe que certos elementos (no sentido SGML) têm conteúdo passível de reprodução (por ex., os elementos P, LI ou TABLE, em HTML); outros são substituídos por conteúdo externo (por ex., IMG); outros ainda afetam o processamento (por ex., STYLE e SCRIPT, que fazem com que as informações sejam tratadas por uma folha de estilo ou por um interpretador de comandos). Um elemento que faz com que os caracteres de texto sejam integrados em um documento é denominado elemento textual. equivalente Um determinado conteúdo é equivalente a outro quando ambos preenchem, em essência, a mesma função ou finalidade, no momento de serem apresentados ao usuário. No contexto deste documento, o equivalente deve preencher a mesma função (qualquer que seja ela) em relação às pessoas com uma incapacidade ou deficiência (na medida do exeqüível, tendo em vista a natureza da deficiência e o avanço da tecnologia), tão adequadamente como o conteúdo principal preenche essa função em relação às pessoas sem qualquer incapacidade ou deficiência. Por exemplo, o texto "Lua cheia" pode transmitir os mesmos dados sobre uma imagem do que a contemplação da própria lua. Observe que as informações equivalentes enfocam o preenchimento da mesma função. Se a imagem fizer parte de um link e sua compreensão for essencial para "adivinhar" qual o destino do link, o equivalente deve dar, aos usuários, a idéia de que destino é esse. O fornecimento de informações equivalentes sobre conteúdo inacessível é um dos principais instrumentos à disposição dos autores para tornarem seus documentos acessíveis a pessoas com incapacidades ou deficiências. O cumprimento da mesma função de conteúdo por parte de um equivalente pode passar pela respectiva descrição (ou seja, dizendo com que se parece o conteúdo, ou qual o seu som). Por exemplo, para que os usuários possam compreender as informações transmitidas por um diagrama complexo, os autores devem descrever a informação transmitida visualmente pelo diagrama. Uma vez que o conteúdo de texto pode ser apresentado ao usuário sob a forma de discurso sintetizado, em Braille e em texto visível, essas recomendações exigem a presença de equivalentes textuais das informações gráficas e sonoras. Os equivalentes textuais devem ser redigidos de tal forma que veiculem todo o conteúdo essencial. Os equivalentes não textuais (por ex., uma descrição sonora de uma apresentação visual, o vídeo de uma pessoa relatando algo apenas com a linguagem de sinais, também contribuem para melhorar a acessibilidade de quem não consegue acessar informações visuais ou textos escritos, incluindo pessoas cegas, surdas, ou com deficiências cognitivas ou de aprendizagem. As informações equivalentes podem ser fornecidas de várias maneiras: por meio de atributos (por ex., um valor textual para o atributo "alt" em HTML e SMIL), como parte do conteúdo de um elemento (por ex., OBJET, em HTML), como parte da redação de um documento ou ainda por meio de um documento associado por link (por ex., o chamado atributo "longdesc", em HTML ou um link descritivo). Devido à complexidade do equivalente, pode ser necessário combinar técnicas (por ex., utilizar "alt" para um equivalente abreviado, útil para leitores familiarizados, além de "longdesc" para um link para informações mais completas, úteis para os leitores inexperientes). O documento de técnicas ([TECHNIQUES]) contém pormenores sobre quando e como fornecer informações equivalentes. Uma transcrição de texto é um equivalente textual de informações sonoras, que inclui palavras faladas e sons não falados (como, por exemplo, efeitos sonoros). As legendas são transcrições de texto que referenciam trilhas de áudio de apresentações de vídeo com sincronia de trilha de vídeo e áudio. As legendas são normalmente apresentadas graficamente por meio de sua sobreposição no vídeo, o que beneficia as pessoas surdas ou com deficiência auditiva, além de todas as pessoas que não possam, no momento, ouvir o áudio (por ex., por estarem em uma sala com ruído ambiente). Uma transcrição de texto agregada combina (agrega) legendas e texto descritivo de vídeo (descrições das alterações da ação, da linguagem corporal, das imagens e das cenas da trilha de vídeo). Esses equivalentes textuais tornam as apresentações acessíveis a surdos ou cegos e a Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 71 de 79 UPP – Unidade de Prospecção e Padronização pessoas que não podem obter a reprodução dos filmes, animações, etc. Além disso, oferecem informações aos mecanismos de busca. Um exemplo de equivalente não textual é a descrição sonora dos elementos-chave de uma apresentação. A descrição pode ser a pré-gravação da voz humana ou uma voz sintetizada (gravada, ou gerada em tempo real). A descrição sonora está em sincronia com a trilha de áudio da apresentação, normalmente recorrendo às pausas naturais que essa contém. As descrições sonoras incluem dados sobre alterações da ação, da linguagem corporal, das imagens e das cenas. imagem Qualquer representação gráfica. mapa de imagem Imagem que foi dividida em regiões, a que estão associadas ações. Clicar sobre uma região ativa desencadeia uma ação. Quando um usuário clica sobre uma região ativa de um mapa de imagem armazenado no cliente, o agente do usuário calcula em que região se deu o clique e segue o link associado. Um clique sobre uma região ativa de um mapa de imagem armazenado no servidor faz com que as coordenadas sejam enviadas para um servidor que, em seguida, executa determinada ação. Os criadores de conteúdo podem tornar acessíveis os mapas armazenados no cliente, fornecendo um acesso independente de dispositivos aos mesmos links associados às regiões do mapa de imagem. Os mapas de imagem armazenados no cliente permitem que o agente do usuário devolva imediatamente a informação se o ponteiro está ou não sobre uma região ativa. importante As informações contidas em um documento são importantes se a respectiva compreensão for essencial para a compreensão de todo o documento. tabela linearizada Processo de representação de uma tabela, em que o conteúdo das células se torna uma série de parágrafos (por ex., na vertical, ao longo da página). Os parágrafos surgem pela ordem de definição das células no código do documento. As células devem continuar a fazer sentido quando lidas em seqüência e devem incluir elementos estruturais (que criem parágrafos, cabeçalhos, listas), para que a página faça sentido após a linearização. texto de um link O conteúdo textual de um link, apresentado ao usuário. idioma e linguagem natural Além dos idiomas, como o português, o francês ou o inglês, ou ainda a linguagem de sinais, o termo "linguagem natural" engloba também a notação do sistema Braille. O conteúdo de linguagem natural pode ser indicado por meio dos atributos "lang", em HTML ([HTML40], seção 8.1) e "xml:lang", em XML ([XML], seção 2.12). mecanismo de navegação O meio pelo qual um usuário pode navegar em uma página ou site. São mecanismos típicos de navegação: barras de navegação Uma barra de navegação é um conjunto de links às principais partes de um documento ou de um site. mapas de site Um mapa de site dá um panorama da organização de uma página ou site. sumários Um sumário (ou lista de conteúdo, que não deve ser confundido com um índice remissivo) apresenta, regra geral, a lista dos capítulos ou seções mais importantes (e respectivos links) de um documento . assistente digital pessoal (PDA- Personal Digital Assistant) Um é um dispositivo computacional, pequeno e portátil, normalmente utilizado para acessar dados pessoais, tais como calendários, contatos e correio eletrônico. Cabe, geralmente, na palma da mão, e aceita a introdução de dados a partir de várias fontes. ampliador de tela Programa de computador que amplia uma porção da tela. Os ampliadores de tela são utilizados sobretudo por pessoas com baixa visão. Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 72 de 79 UPP – Unidade de Prospecção e Padronização leitor de tela Programa de computador que lê o conteúdo da tela em voz alta. Os leitores de tela são utilizados sobretudo por cegos. Normalmente, são capazes de ler apenas o texto impresso (não o desenhado) que aparece na tela. folha de estilo Uma folha de estilo é um conjunto de declarações que especificam a apresentação de um documento. As folhas de estilo podem ter três origens: ter sido escritas por fornecedores de conteúdo Web; criadas por usuários; ou estarem integradas nos agentes de usuário. Em CSS ([CSS2]), a interação de folhas de estilo dos fornecedores de conteúdo, do usuário e do agente do usuário tem o nome de cascata. marcação de apresentação Trata-se de uma marcação que proporciona efeitos de formatação (e não estruturais), tais como os elementos B ou I, em HTML. Observe que os elementos STRONG e EM não são considerados marcações de apresentação, já que transmitem informações independentes do tipo de fonte utilizado. informações tabulares Quando são utilizadas tabelas para representar relações lógicas entre dados -- texto, números, imagens --, diz-se que essas informações são "informações tabulares" e as tabelas tomam o nome de "tabelas de dados". As relações expressas por uma tabela podem ser apresentadas visualmente (habitualmente em uma grade bidimensional), em formato áudio (freqüentemente fazendo preceder as células de informações do respectivo cabeçalho) ou ainda em outros formatos. até que os agentes do usuário ... Na maioria dos pontos de verificação, pede-se aos criadores de conteúdo que verifiquem a acessibilidade de suas páginas e sites. Todavia, há necessidades de acesso que seriam mais completamente preenchidas pelos agentes do usuário (incluindo as tecnologias de apoio). No momento da publicação deste documento, nem todos os agentes do usuário, e nem todas as tecnologias de apoio, proporcionam os controles de acesso de que os usuários necessitam (por ex., alguns agentes do usuário não permitem aos usuários desligarem conteúdo intermitente, e alguns leitores de tela não conseguem tratar tabelas convenientemente). Os pontos de verificação que contêm a expressão "até que os agentes do usuário ..." são aqueles em relação aos quais os criadores de conteúdo são chamados a dar mais apoio, a fim de assegurar a acessibilidade. Isso enquanto os agentes do usuário não oferecerem, como norma, tais funcionalidades de acesso aos seus usuários. Nota: O site da WAI, do W3C (consultar [WAI-UA-SUPPORT]), dá informações sobre o suporte de funções de acessibilidade por parte dos agentes do usuário. Os criadores de conteúdo são aconselhados a consultar essa página, em permanente atualização. agente do usuário Software para acessar conteúdo Web e que inclui navegadores gráficos para estações de trabalho, navegadores de texto, navegadores de voz, navegadores de telefones celulares, leitores de multimídia, suplementos para os navegadores e software de tecnologia de apoio utilizado em conjunto com os navegadores como, por exemplo, os leitores de tela e os programas de reconhecimento de voz. Bibliografia e agradecimentos Co-direção do grupo de trabalho de recomendações para conteúdo da Web: Chuck Letourneau, da Starling Access Services Gregg Vanderheiden, da Trace Research and Development Equipe de contato da equipe do W3C: Judy Brewer e Daniel Dardailler Queremos agradecer a todos que contribuíram com o seu tempo e sugestões para a elaboração destas recomendações: Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 73 de 79 UPP – Unidade de Prospecção e Padronização Marja-Riitta Koivunen, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld e Jason White A redação original deste documento tem por base as recomendações unificadas para a acessibilidade de sites da Web, "The Unified Web Site Accessibility Guidelines" ([UWSAG]), compiladas por Trace R & D Center, da Universidade de Wisconsin (EUA). O referido documento contém a lista dos autores dos respectivos artigos. Referências Para obter a mais recente versão de qualquer especificação do W3C, deve-se consultar a lista de relatórios técnicos do W3C (W3C Technical Reports). [CSS1] "CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17 de Dezembro de 1996, revista em 11 de Janeiro de 1999. Recomendação CSS1: http://www.w3.org/TR/1999/REC-CSS1-19990111. A mais recente versão da CSS1 está disponível em: http://www.w3.org/TR/REC-CSS1. [CSS2] "CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, e I. Jacobs, eds., 12 de Maio de 1998. Recomendação CSS2: http://www.w3.org/TR/1998/REC-CSS2-19980512. A mais recente versão da CSS2 está disponível em: http://www.w3.org/TR/REC-CSS2. [DOM1] "Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson e L. Wood, eds., 1 de Outubro de 1998. Recomendação DOM Level 1: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001. A mais recente versão da DOM Level 1 está disponível em: http://www.w3.org/TR/REC-DOM-Level-1 [HTML40] "HTML 4.0 Recommendation", D. Raggett, A. Le Hors e I. Jacobs, eds., 17 de Dezembro de 1997, revisão de 24 de Abril de 1998. Recomendação HTML 4.0: http://www.w3.org/TR/1998/REC-html4019980424. A mais recente versão da HTML 4.0 está disponível em: http://www.w3.org/TR/REC-html40. [HTML32] "HTML 3.2 Recommendation", D. Raggett, ed., 14 de Janeiro de 1997. A mais recente versão da HTML 3.2 está disponível em: http://www.w3.org/TR/REC-html32. [MATHML] "Mathematical Markup Language", P. Ion e R. Miner, eds., 7 de Abril de 1998. Recomendação MathML 1.0: http://www.w3.org/TR/1998/REC-MathML-19980407. A mais recente versão da MathML 1.0 está disponível em: http://www.w3.org/TR/REC-MathML. [PNG] "PNG (Portable Network Graphics) Specification", T. Boutell, ed., com a colaboração de T. Lane, 1 de Outubro de 1996. A mais recente versão da PNG 1.0 é a seguinte: http://www.w3.org/TR/REC-png. [RDF] "Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 de Fevereiro de 1999. Recomendação RDF: http://www.w3.org/TR/1999/REC-rdf-syntax19990222. A mais recente versão da RDF 1.0 está disponível em: http://www.w3.org/TR/REC-rdf-syntax [RFC2068] "HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen e T. Berners-Lee, Janeiro de 1997. [SMIL] "Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 de Junho de 1998. Recomendação SMIL 1.0: http://www.w3.org/TR/1998/REC-smil-19980615 A mais recente versão da SMIL 1.0 está disponível em: http://www.w3.org/TR/REC-smil Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 74 de 79 UPP – Unidade de Prospecção e Padronização [TECHNIQUES] "Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. Esse documento explica como colocar em prática os pontos de verificação definidos em "Recomendações para a acessibilidade de conteúdo Web--1.0". A mais recente versão do documento de técnicas está disponível em: http://www.w3.org/TR/WAI-WEBCONTENT-TECHS [WAI-AUTOOLS] "Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. Essas recomendações incidem sobre a acessibilidade de ferramentas para criação de conteúdo Web. A mais recente redação provisória está disponível em: http://www.w3.org/TR/WAI-AUTOOLS/ [WAI-UA-SUPPORT] Essa página documenta o suporte de algumas funções de acesso oferecidas por agentes do usuário (incluindo as tecnologias de apoio). A página está disponível em: http://www.w3.org/WAI/Resources/WAI-UA-Support [WAI-USERAGENT] "User Agent Accessibility Guidelines", J. Gunderson e I. Jacobs, eds. Essas recomendações incidem sobre o design de agentes do usuário que promovam a acessibilidade. A mais recente redação provisória está disponível em: http://www.w3.org/TR/WAI-USERAGENT/ [WCAG-ICONS] Estão disponíveis, em http://www.w3.org/WAI/WCAG1-Conformance.html, informações acerca dos símbolos de conformidade com este documento e como utilizá-los. [UWSAG] "The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. As recomendações unificadas para sites da Web foram compiladas por Trace R & D Center da Universidade de Wisconsin (EUA), com subsídio do Instituto Nacional de Investigação da Reabilitação e da Deficiência, organismo tutelado pelo Ministério da Educação dos Estados Unidos (NIDRR National Institute on Disability and Rehabilitation Research, U.S. Dept. of Education). O documento está disponível em: http://www.tracecenter.org/docs/html_guidelines/version8.htm [XML] "Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 de Fevereiro de 1998. Recomendação XML 1.0: http://www.w3.org/TR/1998/REC-xml19980210. A mais recente versão da XML 1.0 está disponível em: http://www.w3.org/TR/REC-xml [sumário] [lista de verificação] PARTE 7 – Instrumentos e ferramentas para verificação automática de Acessibilidade WEB, e/ou de apoio a construção de páginas e sítios acessíveis. “Métodos e Ferramentas de Validação de Acessibilidade web.(W3C - WCAG)” Marco Antonio de Queiroz* (MAQ). Metodologia de Validação de Acessibilidade. A validação da acessibilidade deve ser feita por meio de ferramentas automáticas e da revisão direta. Os métodos automáticos são geralmente rápidos, mas não são capazes de identificar todas as vertentes da acessibilidade. A avaliação humana pode ajudar a garantir a clareza da linguagem e a facilidade da navegação. Deve-se começar por utilizar métodos de Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 75 de 79 UPP – Unidade de Prospecção e Padronização validação automáticos nas fases iniciais do desenvolvimento. As questões de acessibilidade identificadas anteriormente serão mais fáceis de evitar ou corrigir. Os importantes métodos de validação que se seguem são abordados com mais profundidade na seção de validação do documento de técnicas do WCAG 1.0, e são: 1. Utilizar uma ferramenta de acessibilidade automatizada. Note-se que as ferramentas automáticas não incidem sobre todas as questões da acessibilidade, como seja a clareza de um texto, a aplicabilidade de um equivalente textual, etc. 2. Validar a sintaxe(por ex., HTML, XML, etc., em: validador HTML do W3C). 3. Validar as folhas de estilo (por ex., CSS, valide em: Validador Css do W3C.). 4. Utilizar um navegador só de texto (Lynx ou Webvox) ou um emulador. 5. Utilizar vários navegadores gráficos, com: 1. o som e os gráficos ativos; 6. sem gráficos; 7. sem som; 8. sem mouse; 9. sem carregar frames, programas interpretáveis, folhas de estilo ou applets. 10.Utilizar vários navegadores, antigos e recentes. 11.Utilizar um navegador de emissão automática de fala, um leitor de tela, software de ampliação de tela, uma tela de pequenas dimensões, etc. 12.Utilizar corretores ortográficos e gramaticais. Uma pessoa que, para ler uma página, se sirva de um sintetizador de voz, pode não ser capaz de decifrar a melhor aproximação do sintetizador a uma palavra que contém um erro de ortografia. A eliminação dos problemas gramaticais aumenta o grau de compreensão da página. 13.Rever o documento, verificando-lhe a clareza e a simplicidade. O melhor é pedir a um revisor literário experiente que reveja o conteúdo escrito e avalie a clareza da redação. 14.Peça a pessoas com deficiências que revejam os documentos. Estes usuários , com ou sem experiência, são uma fonte inestimável de informações sobre o estado dos documentos, no que diz respeito ao seu grau de acessibilidade e de facilidade de utilização. Avaliadores de Acessibilidade - Validadores Automáticos. Os avaliadores ou validadores de acessibilidade, são ferramentas automáticas que fazem uma pesquisa no código de uma página emitindo relatórios onde indicam os erros de acessibilidade segundo as prioridades sugeridas nas ( Diretrizes para a Acessibilidade dos Conteúdos da Web - 1.0 O número de avisos em relatórios de acessibilidade normalmente supera em muito a quantidade de erros listados. Isso ocorre em razão da capacidade limitada das regras que podem ser testadas automaticamente por esses softwares. Existem diferenças relevantes entre as ferramentas de avaliação de acessibilidade, principalmente na sua aderência aos Web Standards (padrões Web), portanto, para obter um bom resultado, é mais garantido testarmos em mais de um desses softwares. É também bom lembrar que a metodologia para se fazer uma boa acessibilidade numa página não se resume na aprovação desses avaliadores automáticos, eles são tão somente referência para se chegar a uma acessibilidade de excelência, para descobrirmos erros muitas vezes imperceptíveis numa avaliação manual. Uma avaliação também só feita por Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 76 de 79 UPP – Unidade de Prospecção e Padronização pessoas com deficiência incorre no erro da página ficar acessível somente aquela deficiência, ou à tecnologia assistiva que ela esteja utilizando. Acessibilidade é se fazer algo o mais universal possível, para todas as pessoas com deficiência, para todos os tipos de acesso (rápidos ou lentos, banda larga ou discado) e para todos os tipos de dispositivos (leptops, celulares, de tecnologias assistivas, etc.). Aí estão os avaliadores mais conhecidos e utilizados: • • • • Hera (em português) Examinator (em português). (* Ver abaixo comentário de Sérgio F.Brandão) Cynthiasays - em inglês. DaSilva (em português) * baseado no ( Web Contents Accessibility Guidelines 1.0 (Diretrizes para a Acessibilidade dos Conteúdos da Web 1.0) Nota do autor: as Diretrizes Irlandesas de Acessibilidade na WEB são também uma excelente fonte de estudo e aprendizagem no desenvolvimento de páginas acessíveis na internet.” (* Comentário de Sérgio F.Brandão) – O Sr. Marco Antônio de Queiroz, reporta o Examinator (Em Português) como o validador automático de sua preferência atual, 2008. Vide orientação proposta neste documento, Parte 2 - Resumo Didático e Orientação de Uso desta Recomendação: de fazer revisão técnica manual e se empregar Pessoas com Deficiência para realizarem o trabalho de Revisores de Acessibilidade, e suas vantagens. (por Sérgio F.Brandão) PARTE 8 – Legislação sobre Acessibilidade, Inclusão e Tecnologias Assistivas que respaldam a definição SUGESTÕES DE ANTÔNIO MUNIZ DA SILVA – PRESIDENTE DA APEC. SFB8C30A Leis, Decretos e Convenções sobre a Pessoa com Deficiência, Acessibilidade, Inclusão e Tecnologias assistivas, relativas a Informação e à Comunicação, e contendo regulamentação sobre direitos das Pessoas com Deficiência e Obrigações dos Governos, Federal, Estadual e Municipal sobre o assinto. CONSTITUIÇÃO FEDERAL / 1988 - ÚLTIMA ATUALIZAÇÃO LEI 10098 / 2000 - ACESSIBILIDADE - Normas e critérios básicos para promoção da Acessibilidade para Pessoas com Deficiência -- Estabelece normas gerais e critérios básicos para a promoção da acessibilidade das pessoas portadoras de deficiência ou com mobilidade reduzida, e dá outras providências. DECRETO LEI 5296 / 2004 - ACESSIBILIDADE REGULAMENTA LEI 10098 E 10048 -Regulamenta as Leis nos 10.048, de 8 de novembro de 2000, que dá prioridade de atendimento às pessoas que especifica, e 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 portadoras de deficiência ou com mobilidade reduzida, e dá outras providências. Com atualização Dec 5.645/2005 - Dá Nova Redação Ao Art. 53 Do Decreto Nº 5.296, De 2 De Dezembro De 2004. CONVENÇÃO INTERNACIONAL DA PESSOA COM DEFICIÊNCIA - ONU / 2006 DECRETO LEI 6215 / 2007-09-26 - Cria Comitê Interministerial de Apoio a Pessoa com Deficiência -- Estabelece o Compromisso pela Inclusão das Pessoas com Deficiência, com vistas à implementação de ações de inclusão das pessoas com deficiência, por parte da União Federal, em Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 77 de 79 UPP – Unidade de Prospecção e Padronização regime de cooperação com Municípios, Estados e Distrito Federal, institui o Comitê Gestor de Políticas de Inclusão das Pessoas com Deficiência - CGPD, e dá outras providências. PARTE 9 – Fontes e Referências Bibliográficas. Esta recomendação propõe Acessibilidade WEB para sítios e páginas do Governo de PE, Versão 2.2 N.B. contém orientação para implementação de Nível Básico e foi baseada nas seguintes fontes que foram utilizadas, parcial ou integralmente para compor este documento, inclusive transcrição integral de documentos autorizados ou públicos, explicitamente citados ou entre aspas duplas “”. 1. W3C / WAI / WCAG-1.0 --- A tradução, manutenção e revisão deste documento é da responsabilidade de Cláudia Dias, auditora da tecnologia da informação do Tribunal de Contas da União (TCU). A reprodução e distribuição é livre, desde que cumpra os requisitos do documento do W3C sobre direitos de autor e copyright. http://www.geocities.com/claudiaad/acessibilidade_web.html 2. May 23, 2006 To Hell with WCAG 2 by Joe Clark 3. WCAG Samurai de Joe Clark --- 28 Fevereiro 2008 Publicada a versão 1.0 do WCAG Samurai para o WCAG 1.0 No último dia 26, foi publicada a versão 1.0 do WCAG Samurai para o WCAG 1.0 (em inglês). 4. Documentos, e recomendações várias contidos no Sitio “Bengala Legal” transcritos na íntegra, cedidos para este documento por seu autor Sr.Marco Antônio de Queiroz. http://www.bengalalegal.com 5. Diretrizes Irlandesas de Acessibilidade NDA --- na Irlanda, pela National Disability Authority (NDA) - Autoridade Nacional para a Deficiência, novas directrizes de acessibilidade para as tecnologias digitais. O NDA é o comité independente que supervisiona a política para a área da deficiência na Irlanda.As directrizes (http://accessit.nda.ie) 6. Critérios, Propostas e Orientações técnicas, sugeridas e/ou disponibilizada pelo Sr. Marco Antônio de Queiroz que alteram e/ou acrescentam conteúdos e mudanças de forma no uso das fontes referência citadas àcima. 7. Documento “Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco – Versão 1.0 / 2007” produzido pela UPP/ATI Denis Barbosa, Nilo Martins, Sérgio F.Brandão. 8. Documento “Padrão de Usabilidade e Acessibilidade para Sites do Governo de PE” – Flávio Ricardo Dias, Romero Guimarães, Zacharias Candeias Jr. 9. Documentos, e recomendações contidos no Sitio “Acessibilidade Legal” do Srl Marco Antônio de Queiroz. http://www.acessibilidadelegal.com Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 78 de 79 UPP – Unidade de Prospecção e Padronização CONCLUSÃO Esta recomendação, tem um caráter dinâmico, e deverá ser completada para incluir além do nivel Básico, o Intemediário e o Avançado; evoluir e adaptar-se às necessidades e possibilidades, a partir de sua aplicação na prática, com participação dos profissionais do Governo PE responsáveis pelos conteúdos, pelos desenvolvedores do próprio Estado, ou profissionais e empresas contratadas, de todos os usuários dos produtos e serviços públicos informatizados disponibilizados pela WEB para o cidadão pernambucano pelo Governo do Estado, pelas pessoas com deficiência e suas entidades representativas, diretamente ou com interveniência de outros poderes como o legislativo e o judiciário na formulação e aplicação das leis pertinentes, integrada em todas as esferas institucionais, Nacional, Estaduais e Municipais. Contato: [email protected] ou [email protected] FIM Recomendações para acessibilidade de páginas WEB a serem disponibilizadas pelo Governo de Pernambuco. Padrão para Acessibilidade WEB (contendo o Nível Básico) - Versão 2.2 N.B. / 2008, 06 de Junho – Pág 79 de 79 UPP – Unidade de Prospecção e Padronização