accesskey_mod_content

Estándares

No, no es estrictamente necesario. Validar la corrección gramatical del código no es un requisito imprescindible en WCAG 2.0, aunque sí es altamente recomendable para asegurar la compatibilidad del mismo entre diferentes navegadores.

Como requisito mínimo, el código de las páginas debe ser procesable. Es decir, no debe haber errores en el código que puedan causar problemas de interpretación a los diferentes navegadores y aplicaciones de usuario.

Para que el código sea procesable se ha de cumplir que al menos esté bien formado. La apertura y cierre de las etiquetas debe seguir la especificación. Deben existir etiquetas de cierre para todos los elementos que las requieran y no deben existir para aquellos elementos en los que estén prohibidas. Las etiquetas de apertura y de cierre deben estar anidadas correctamente para todos los elementos. El valor de los atributos debe estar correctamente entrecomillado y no se deben repetir valores en aquellos atributos que requieran un valor único (por ejemplo, los id).

Si se cumple lo anterior se minimiza el riesgo de que el código sea procesado de forma incorrecta por alguna aplicación de usuario. Sin embargo, la mejor opción y más recomendable es validar siempre el código según la gramática formal usada. La principal ventaja de validar el código es la eliminación de todas las ambigüedades que se puedan producir por el uso de código incorrecto.

Si al realizar la validación de una página, el validador de HTML devuelve errores del tipo cannot generate system identifier for general entity, son debidos a que para utilizar caracteres especiales en las rutas URL se debe hacer uso de sus entidades. En el caso del carácter &, la entidad correspondiente es &.

 Ejemplo de código

<a href=”menu.php?inicio=0&lenguaje=es”>Inicio</a>

 

La manera más accesible y recomendable para realizar una redirección es que se haga de manera transparente al usuario. Para ello se pueden emplear redirecciones del lado del servidor en lugar de usar redirecciones en el cliente. En caso de usar redirecciones en el cliente éstas han de ser inmediatas, sin límite de tiempo, para que sean transparentes para los usuarios.

En el caso de las redirecciones de servidor se tendrá que configurar éste de forma adecuada para indicar el código de estado HTTP adecuado (301). A modo de ejemplo, en el servidor web Apache se usa la directiva redirect.

Ejemplo de directiva en apache
redirect /pagina_antigua.html /pagina_nueva.html

 

Siempre es preferible usar redirecciones de servidor. Sin embargo, si es necesario hacer redirecciones de cliente (por ejemplo, porque no se tenga acceso a la configuración del servidor) éstas han de ser instantáneas de forma que sean transparentes para los usuarios.

Ejemplo de código
<meta http-equiv="refresh" content="0;URL='pagina_nueva.html'" />

 

No, no es obligatorio. Las pautas de accesibilidad no exigen usar una determinada gramática. La única exigencia es que el código sea correcto de forma que se asegure la compatibilidad entre los diferentes navegadores y productos de apoyo. Cumpliéndo lo anterior, se podrá usar tanto xHTML, como HTML5 como versiones anteriores de HTML.

En lo referente a qué tipo de gramática utilizar, y aunque no sea un requisito, se recomienda emplear gramáticas estrictas.

Para que un documento PDF se considere accesible debe estar etiquetado y estructurado, con alternativas a todo elemento no textual, con marcado de idioma y orden de lectura apropiado y, en el caso de estar protegido, con seguridad accesible.

Para conseguir este marcado accesible existen dos vías:

  • Crear un documento accesible mediante un procesador de texto y exportar a PDF etiquetado (no todas las herramientas permiten esta exportación).
  • Exportar el documento a PDF y posteriormente etiquetarlo de manera manual (mediante Adobe Acrobat Profesional).

Además, es necesario que se proporcione en las páginas donde se incluyen los enlaces a los documentos PDF, un esquema o resumen, con formato (X)HTML+CSS accesible, de la información que esté contenida en los PDF.

Para ampliar la información sobre el proceso de construcción de PDF accesibles puede consultar la "Guía de Accesibilidad en Documentos PDF” disponible en el apartado "Accesibilidad en PDFs" del área de documentación.

Punto de Acceso General
Punto de Acceso General