você está em: Página de entrada > FAQs [saltar para menu referências (2)] [saltar para corpo da página - alt 3]
FAQs
1. Questão: A utilização de iFrames para comportar imagens está de acordo com as regras de acessibilidades?
Por princípio os elementos iFrame e Frame são para comportar páginas Web, as quais deverão ser validadas como quaisquer páginas. As páginas que incorporam os iFrames/Frames devem ter todos os elementos que qualquer outra página. Ou seja uma estrutura do tipo:
<doctype ...
<html >
<head>... </head>
<body> ... </body>
</html>
O iFrame não foi criado para comportar imagens. Assim um dos primeiros erros que as ferramentas automáticas identificam é precisamente o facto de por exemplo uma "xxx.jpg" não ser uma página "xxx.htm".
Soluções:
1) Em vez de usar <iframe src="xxx.jpg"></iframe> usar <img src="xxx.jpg" alt="texto alternativo">
2) Se não for possível por alguma razão modificar de acordo com 1 a solução alternativa é:
<ifrmae src="xxx.htm">
<img src="xxx.jpg">
</iframe>
E o ficheiro “xxx.htm” terá quer ter o aspecto:
<doctype ....>
<html lang="pt">
<head>.... </head>
<body>
<img src="xxx.jpg">
</body>
</html>
Como se vê, o uso de iFrame para posicionar imagens é bem mais confuso que o uso do elemento <img>.
2. Questão: Na sequência da RCM nº 155/2007, a Secretaria-Geral do nosso Ministério instruíu todos os organismos a efectuarem a avaliação da acessibilidade dos seus sítios web com o CynthiaSays. No entanto, esta ferramenta online apenas valida página a página. Como posso efectuar a validação de várias páginas?
Solução:
A validação de várias páginas, em simultâneo, pode ser feita usando
ferramentas como:
- AccVerify, que corresponde ao CynthiaSays e que pode ser adquirida junto ao fabricante HiSoftware (http://www.hisoftware.com);
- TAW – Test Accesibilidad Web, que pode descarregar gratuitamente a partir do sítio Web da ferramenta (http://www.tawdis.net).
3. Questão: O nosso sítio web é bastante gráfico e dinâmico pelo que estamos a pensar construir uma versão à parte, específica para cidadãos com necessidades especiais em que se cumpram TODAS as regras de acessibilidade. Podemos fazê-lo?
Solução:
O facto do sítio web conter muitos elementos gráficos não implica necessariamente inacessibilidade. Existem várias técnicas disponíveis para dotar os elementos gráficos dos respectivos cuidados de acessibilidade.
A tentação de cumprir TODAS as regras de acessibilidade leva, não raras as vezes, a construir uma versão do sítio web “só de texto”. É preciso notar que um sítio “só de texto”, por si só, já é violador de um conjunto de regras de acessibilidade, quando esta é vista à luz das Directrizes de Acessibilidade para o Conteúdo da Web (WCAG1.0), ou seja como uma Concepção Universal (para Todos).
Atente-se nos seguintes pontos de verificação das WCAG1.0:
“Se, depois de todos os esforços, não conseguir criar uma página acessível, forneça um link para uma página alternativa que use as tecnologias W3C na sua versão acessível, com informação equivalente (ou com as mesmas funcionalidade), que seja actualizada tantas vezes quantas as páginas inacessíveis (originais).” (ponto de verificação 11.4; ponto de prioridade 1).
“Reforce a mensagem texto através de gráficos e/ou áudio na medida em que os mesmos facilitem a compreensão da página.” (ponto de verificação 14.2; ponto de prioridade 3).
4. Questão: Somos uma empresa responsável por diversos sites da administração pública, o nosso sistema é fornecido de raiz com um site paralelo cujo objectivo do mesmo é ser classificado AAA. Existe algum problema nesta abordagem?
Solução: Chamo a atenção para o seguinte ponto de verificação:
"11.4 - Se, depois de todos os esforços, não conseguir criar uma página acessível, forneça um link para uma página alternativa que use as tecnologias W3C na sua versão acessível, com informação equivalente (ou com as mesmas funcionalidade), que seja actualizada tantas vezes quantas as páginas inacessíveis (originais)."
Reforço a indicação "(...) todos os esforços". E também chamo a atenção que não é referido que a página alternativa seja uma página texto. Uma página texto, logo à partida, não está de acordo com o nível de conformidade AAA.
Veja-se por exemplo o ponto de verificação 14.2: Reforce a mensagem texto através de gráficos e/ou áudio na medida em que os mesmos facilitem a compreensão da página. (Prioridade 3)
Note que quando falamos na aplicação das WCAG 1.0 estamos a falar de Desenho Universal. Universal é mesmo 1 conteúdo para TODOS e não VÁRIOS conteúdos para servir cada UM.
5. Questão: No motor de avaliação Bobby que é o que a UMIC aconselha utilizar nas suas páginas os sites obtém a classificação pretendida?
Solução:
Chamo a atenção que aquilo que a UMIC, ou melhor a legislação portuguesa recomenda, é a conformidade para com as Directrizes de Acessibilidade para o Conteúdo Web na sua versão 1.0 do W3C (se quiser as WCAG 1.0 do W3C). Para que isso aconteça há que efectuar avaliações (manuais ou automáticas). Recordo que as ferramentas automáticas são apenas auxiliares de avaliação e não "veridictos finais". A metodologia de avaliação do W3C aconselha, por isso, o uso de mais do que uma ferramenta para o fazer.
6. Questão: O motor da firma Hi Software está a confundir a nosso ver o que é uma TAG ou atributo de HTML "deprecated" com "obsoleto". No 1º caso os browsers são obrigados a dar compatibilidade com as TAG ou atributos "deprecated", o que, portanto, não gera erro. O motor da Hi Software gera erros nestes casos.
Solução:
A indicação que a ferramenta vos está a dar é correcta. Uma regra importante a ter em conta em acessibilidade é separar integralmente o estilo da estrutura. Tudo o que é estrutura deve ficar no HTML e tudo o que é estilo deve ficar na CSS externa. No vosso caso a ferramenta está a dizer-vos que localizou estilo misturado na estrutura e está a informar que a vossa solução já está ultrapassada, obsoleta, deprecated. Não se trata de não existirem navegadores para descodificarem as soluções obsoletas, mas existem outros agentes de utilizador para além dos browsers, nomeadamente os utilizados por pessoas com deficiência, os quais se dão melhor com soluções em que separam integralmente o estilo da estrutura.
Por isso, mesmo sem ver a vossa página sou levado a concordar em absoluto com a indicação do CynthiaSays. O não cumprimento desse ponto de verificação é uma violação da conformidade das WCAG 1.0.
Em relação à obrigatoriedade de colocar texto por omissão nas TAG "input type=text". Temos um problema que não vemos solução para o mesmo.
7. Questão: Por exemplo, admita que possui um campo de formulário que tem que preencher a seguinte frase "Quantos filhos tem <campo de formulário>". Este campo é de preenchimento obrigatório. Se colocamos o valor zero ele vai já com um valor e o utilizador pode nem sequer olhar para ele e submeter o formulário com um dado errado, pois não foi forçado a passar pelo campo. Se colocamos um texto qualquer na caixa de texto a nossa aplicação dá erro, pois espera nele um campo numérico, para além de o utilizador ficar confundido de ver texto num campo numérico. Se não colocamos nada, que é o que temos vindo a fazer até hoje, a aplicação chumba no AAA aproved. Pergunto-lhe o que fazer nestas situações?
Solução:
Aconselho a colocar a <label> e a associá-la explicitamente ao campo de edição. <label for="xxx"><input id="xxx"> e já agora a colocar o alt em input. i.e. <input alt="Introduza o nº de xxx" id="xxx">
Se possível, coloque apenas o "value" no primeiro campo do form.
8. Questão No motor de avaliação Bobby que é o que a UMIC aconselha utilizar nas suas páginas os sites obtém a classificação pretendida.
Solução:
Chamo a atenção que aquilo que a UMIC, ou melhor a legislação portuguesa recomenda, é a conformidade para com as Directrizes de Acessibilidade para o Conteúdo Web na sua versão 1.0 do W3C (se quiser as WCAG 1.0 do W3C). Para que isso aconteça há que efectuar avaliações (manuais ou automáticas). Recordo que as ferramentas automáticas são apenas auxiliares de avaliação e não "veridictos finais". A metodologia de avaliação do W3C aconselha, por isso, o uso de mais do que uma ferramenta para o fazer.
9. Questão A ferramenta de validação do Hi Software parece-nos que está a confundir a nosso ver o que é uma TAG ou atributo de HTML "deprecated" com "obsoleto". No 1º caso os browsers são obrigados a dar compatibilidade com as TAG ou atributos "deprecated", o que, portanto, não gera erro. O motor da Hi Software gera erros nestes casos?
Solução:
A indicação que a ferramenta vos está a dar é correcta. Uma regra
importante a ter em conta em acessibilidade é separar integralmente
o estilo da estrutura. Tudo o que é estrutura deve ficar no HTML e
tudo o que é estilo deve ficar na CSS externa. No vosso caso a
ferramenta está a dizer-vos que localizou estilo misturado na
estrutura e está a informar que a vossa solução já está ultrapassada,
obsoleta, deprecated. Não se trata de não existirem navegadores para
descodificarem as soluções obsoletas, mas existem outros agentes de
utilizador para além dos browsers, nomeadamente os utilizados por
pessoas com deficiência, os quais se dão melhor com soluções em que
separam integralmente o estilo da estrutura.
Por isso, mesmo sem ver a vossa página sou levado a concordar em
absoluto com a indicação do CynthiaSays. O não cumprimento desse
ponto de verificação é uma violação da conformidade das WCAG 1.0.