accesskey_mod_content

Estándares

Non, non é estritamente necesario. Validar a corrección gramatical do código non é un requisito imprescindible en WCAG 2.0, aínda que si é altamente recomendable para asegurar a compatibilidade do mesmo entre diferentes navegadores.

Como requisito mínimo, o código das páxinas debe ser procesable. É dicir, non debe haber erros no código que poidan causar problemas de interpretación aos diferentes navegadores e aplicacións de usuario.

Para que o código sexa procesable hase de cumprir que polo menos estea ben formado. A apertura e peche das etiquetas debe seguir a especificación. Deben existir etiquetas de peche para todos os elementos que as requiran e non deben existir para aqueles elementos nos que estean prohibidas. As etiquetas de apertura e de peche deben estar aniñadas correctamente para todos os elementos. O valor dos atributos debe estar correctamente entre comiñas e non se deben repetir valores naqueles atributos que requiran un valor único (por exemplo, os ide).

Se se cumpre o anterior minimízase o risco de que o código sexa procesado de forma incorrecta por algunha aplicación de usuario. Con todo, a mellor opción e máis recomendable é validar sempre o código segundo a gramática formal usada. A principal vantaxe de validar o código é a eliminación de todas as ambigüidades que se poidan producir polo uso de código incorrecto.

Se ao realizar a validación dunha páxina, o validador de HTML devolve erros do tipo cannot generate system identifier for xeral entity, son debidos a que para utilizar caracteres especiais nas rutas URL débese facer uso das súas entidades. No caso do carácter &, a entidade correspondente é &.

 Exemplo de código

Inicio

 

A maneira máis accesible e recomendable para realizar unha redirección é que se faga de maneira transparente ao usuario. Para iso pódense empregar redirecciones ao lado do servidor en lugar de usar redirecciones no cliente. En caso de usar redirecciones no cliente estas han de ser inmediatas, sen límite de tempo, para que sexan transparentes para os usuarios.

No caso das redirecciones de servidor terase que configurar este de forma adecuada para indicar o código de estado HTTP adecuado (301). A modo de exemplo, no servidor web Apache úsase a directiva redirect.

Exemplo de directiva en apache
redirect /paxina_antiga.html /paxina_nova.html

 

Sempre é preferible usar redirecciones de servidor. Con todo, se é necesario facer redirecciones de cliente (por exemplo, porque non se teña acceso á configuración do servidor) estas han de ser instantáneas de forma que sexan transparentes para os usuarios.

Exemplo de código

 

Non, non é obrigatorio. As pautas de accesibilidade non esixen usar unha determinada gramática. A única esixencia é que o código sexa correcto de forma que se asegure a compatibilidade entre os diferentes navegadores e produtos de apoio. Cumpliéndo o anterior, poderase usar tanto xHTML, como HTML5 como versións anteriores de HTML.

No referente a que tipo de gramática utilizar, e aínda que non sexa un requisito, recoméndase empregar gramáticas estritas.

Para que un documento PDF considérese accesible debe estar etiquetaxe e estruturado, con alternativas a todo elemento non textual, con marcado de idioma e orde de lectura apropiado e, no caso de estar protexido, con seguridade accesible.

Para conseguir este marcado accesible existen dúas vías:

  • Crear un documento accesible mediante un procesador de texto e exportar a PDF etiquetaxe (non todas as ferramentas permiten esta exportación).
  • Exportar o documento a PDF e posteriormente etiquetarlo de maneira manual (mediante Adobe Acrobat Profesional).

Ademais, é necesario que se proporcione nas páxinas onde se inclúen as ligazóns aos documentos PDF, un esquema ou resumo, con formato (X)HTML+CSS accesible, da información que estea contida no PDF.

Para ampliar a información sobre o proceso de construción de PDF accesibles pode consultar a "Guía de Accesibilidade en Documentos PDF” dispoñible na apartado "Accesibilidade en PDFs" da área de documentación.