HTML5: consideraciones de accesibilidad web
AWS | accesibilidad,diseño web,web 3.0,web semantica | Jueves junio 17 2010
En el portal especializado en temas de accesibilidad web, WebAim, se han publicado varios artículos relacionados con la accesibilidad Web y el futuro del nuevo estándar HTML5.
Los temas que tratan varían desde las características del elemento video hasta los elementos semánticos de HTML5, pasando por otras propiedades de esta nueva revisión del estándar.
Accesibilidad web y HTML. Aspectos destacados:
HTML5: Accesibilidad de la etiqueta <video>
Hasta este momento, el método para incluir vídeo en un sitio web ha requerido un plugin de terceros, dependiendo la calidad, la interfaz de usuario y la accesibilidad, del plugin de video utilizado. Con el HTML5 viene una etiqueta estándar <video>.
Respecto a la accesibilidad de la futura etiqueta <video>, y a la espera de las especificaciones de la misma y las implementaciones de los distintos navegadores, es posible que resuelva dos de los mayores problemas que se presentan en la actualidad: la accesibilidad del teclado y el soporte de subtítulos.
Control del teclado
De forma predeterminada, la etiqueta <video> de HTML5 utiliza los controles de reproducción que proporciona el navegador, que debe permitir la navegación con el teclado. Aunque es todavía demasiado pronto para saber si todos los fabricantes de navegadores incorporarán esta funcionalidad correctamente, es probable que sea una gran mejora con respecto lo que habitualmente vemos hoy.
Subtítulos
La etiqueta <video> en HTML5 no contiene ningún mecanismo integrado para la subtitulación, la descripción, las transcripciones, u otras alternativas sincronizado medios de comunicación. El actual proyecto del pliego de condiciones dice:
“Para hacer el contenido de vídeo accesibles a los ciegos, sordos y personas con otras discapacidades físicas o cognitivas, los autores deben proveer medios alternativos y / o integrar ayudas de accesibilidad … “
En otras palabras, los desarrolladores que quieran incluir video con subtítulos no recibirá ninguna ayuda de HTML5 directamente. Ahora bien, esto no es peor que la situación que tenemos hoy, y, parece ser que, en los grupos de Accesibilidad del W3C están buscando alguna forma de solventar el tema con el nuevo estándar.
HTML5: Accesibilidad de los elementos semánticos
HTML5 introduce varios elementos semánticos que representan secciones lógicas o componentes de una aplicación web o un documento: <section>, <nav>, <article>, <aside>, <hgroup>, <header>, <footer>, así como nuevas reglas para el uso de las etiquetas de cabecera <h1>-<h6> y los elementos <dirección>. Las nuevas etiquetas proporcionan una forma más sencilla para los desarrolladores a la hora de definir las distintas partes de un documento.
En general, todo esto tiene un importante potencial para mejorar la accesibilidad, sobre todo si los lectores de pantalla y otras tecnologías de asistencia comienzan a utilizar la información asociada.
En algunos casos una etiqueta específica o el uso que de ella se hace, podría crear una oportunidad única o un problema para la accesibilidad (o con bastante frecuencia, ambas a la vez).
Uso exclusivo de <h1> en <section> y <article>
En las versiones actuales de HTML, la única forma de definir las secciones y la jerarquía del esquema de un documento es el uso de la <h1>-<h6> en una estructura plana. Esto es muy beneficioso para la accesibilidad, pero puede ser un poco incómodo para los desarrolladores de páginas web. HTML5 introduce dos nuevos elementos, <section> y <article>, que definen secciones lógicas y artículos para organizar el contenido y los niveles de jerarquía de lo mismo.
Esta solución puede originar algunos problemas de accesibilidad durante la fase de transición hacia el estándar, haciendo necesario que continuemos usando etiquetas de encabezados aunque estén anidadas dentro de bloques <section> y <article>.
El elemento <nav>
El elemento <nav> en HTML5 proporciona una forma de especificar de forma explícita los elementos de navegación en las páginas. Al igual que antes, esto será relamente destacable cuando las tecnologías de asistencia (y los navegadores web estándar) ofrezcan e a los usuarios la capacidad de tomar ventaja del estándar directamente.
Accessible Rich Internet Applications (WAI-ARIA)
La especificación HTML 5 contiene una sección sobre WAI-ARIA (Accessible Rich Internet Applications) que se ocupa de cómo las diferentes funciones se pueden aplicar a los elementos HTML5. En algunos casos, HTML5 requiere agentes de usuario para usar automáticamente las funciones específicas de ARIA sobre ciertos elementos. En otros casos, HTML5 requiere que los agentes de usuario proporcionen funciones por defecto “razonables” a ciertos elementos, pero permite que éstas sean reemplazadas por el desarrollador, al menos dentro de ciertos límites.
HTML5: Accesibilidad de los nuevos tipos para la etiqueta <input> y sus extensiones
HTML5 define 13 nuevos valores para el elemento <input> (búsqueda, teléfono, url, correo electrónico, fecha y hora, fecha, mes, semana, tiempo, fecha y hora local, número, intervalo y color). En la Mozilla Wiki se puede encontrar información sobre ellos (color date, email, number, range, search, tel y url).
Si bien queda por ver cómo cada uno de los nuevos tipos de entrada se representará o será utilizada por los navegadores web. Estos son campos de texto utilizados por secuencias de comandos y se enviarán por GET y POST como tal. En algunos casos (como la fecha y la hora ) HTML5 dicta que los datos se almacenarán internamente o serán representados de manera específica, de forma que los cambios en su manera de ser utilizados será mínimos.
Por defecto, para un elemento <input> en HTML se le asigna un type = “text”, así que esté es un cambio perfectamente compatible con versiones anteriores, y no debería causar ningún problema (de accesibilidad o de otro tipo).
Tipo de entrada Search
El tipo de entrada de búsqueda representa un campo de texto que funciona como una caja de búsqueda (ver la especificación de HTML5). Respecto a este nuevo tipo su utilidad y los beneficios para la accesibilidad son bastante grandes, ya que permitiría a las tecnologías de asistencia proporcionar, mediante un solo comando o pulsaciones de teclas, acceder a la casilla de búsqueda de la página actual, independientemente de dónde se encuentre en el contenido.
Tipos de entrada tel, url y email
Mediante estos nuevos tipos, el desarrollador tiene una ayuda para la validación de entrada de los datos, de forma que se puede exigir que el texto introducido cumpla las especificaciones del formato URL o de direcciones de correo. Además, existe la posibilidad de integración con otras fuentes de datos, mediante lo cual, por ejemplo, los agentes de usuario podrían proporcionar un mecanismo para obtener direcciones de email o números de teléfono de un navegador o de la libreta de direcciones y cumplimentar de esta forma los campos de entrada.
La accesibilidad de estas interacciones basadas en el navegador será responsabilidad de los proveedores de navegadores.
Tipos de entrada date y time
Seis de los nuevos tipos de entrada están relacionados con fechas y horas en una u otra forma: datetime, date, month, week, time y datetime-local.
Es de esperar que los navegadores web y otras aplicaciones de usuario presentará estos campos de entrada como, quizá, calendarios o relojes implementados con popups para permitir una fácil lectura y una selección sencilla de los valores apropiados. Esto se puede esperar que genere un significativo aumento de la accesibilidad , ya que estos reproductores suministrados por los navegadores es probable que sean muy accesibles, mientras que los códigos actuales, basados habitualmente en JavaScript, suelen tener deficiencias en cuanto a accesibilidad. Además, el uso de una interfaz única para la selección de fechas y horas, reducirá la curva de aprendizaje para los usuarios ya que tendrá un formato similar en todos los sitios web.
Durante el período de transición, cuando algunos usuarios cuenten con navegadores con soporten HTML5 y otros no, los sitios que actualmente utilizan códigos desarrollados tendrán que buscar alguna forma de determinar las capacidades del navegador y solo hacer uso de estas etiquetas HTML5 si el browser las soporta. Actualmente sólo las versiones más recientes de Opera soportan oficialmente los tipos de entrada date y time, aunque se espera que otros navegadores las soporten en breve.
Tipos de entrada numéricos
Los tipos de entrada number y range se utilizarán para la entrada de valores numéricos, y, lo más probable, es que sea presentado por los navegadores como spinboxes y controles deslizantes, respectivamente. Dado que estos reproductores se corresponden directamente con funcionalidades nativas de la plataforma y estas suelen incluir funciones de accesibilidad, esta se supone que será elevada. La conversión de los campos de entrada de texto para estos campos numéricos no debe crear un nuevo problemas de accesibilidad.
Tipo de entrada Color
El tipo de entrada color se debe al creciente número de aplicaciones de edición de fotografías en la web.
Extensiones para la etiqueta <input>
Además de los nuevos tipos <input>, HTML5 también añade cuatro nuevos atributos a todos los elementos de entrada que tienen un impacto potencial de la accesibilidad: autofocus, placeholder, required y pattern. Todos ellos implementan características y funciones que se han estado utilizando en aplicaciones web desde hace años a través de secuencias de comandos, pero ahora el estándar nos permite ser codificadas directamente en HTML.
Los navegadores, exceptuando Internet Explorer, admiten estas extensiones en mayor o menor medida, pero se espera que las implementen en todas sus funcionalidades en breve. Mientras tanto, las soluciones basadas en scripts se puede utilizar junto con los atributos de HTML5, con la incorporación de algunas utilidades para determinar el user-agent del navegador del usuario.
-
Enfoque automático (autofocus)
El atributo de enfoque automático permite a los desarrolladores especificar que un elemento, de forma particular, debe recibir el foco de entrada tan pronto como la página que lo contiene se carga, de modo que puede empezar a escribir de inmediato sin tener que hacer click específicamente en ese control. Las capacidades de autofoco basado en scripts son muy utilizadas en la actualidad, pero conllevan una serie de problemas, incluyendo el hecho de que no hay forma de deshabilitarlas. Con el atributo autofocus los navegadores web y otras aplicaciones de usuario puede permitir la capacidad de deshabilitar esta característica, ya sea en un sitio web específico o para toda la Web.
Tenga en cuenta que existen algunos problemas de acceso con el enfoque automático , y esto no cambiará con el nuevo estándar, pero en los casos los que queramos utilizar esta característica, el atributo de enfoque automático en HTML5 proporciona una manera más fácil y más simple realizarlo.
-
Marcador de posición de texto (placeholder)
El marcador de posición de texto en los campos de entrada en HTML está considerado como un requisito de accesibilidad. Actualmente se implementa con un texto por defecto que contiene la entrada o el área de texto del los formularios, siendo, este texto, eliminado automáticamente por un script cuando se incluye texto por parte del usuario.
El atributo placeholder de HTML5 permite a los desarroladores web especificar el marcador de posición del texto directamente en el código del formulario. Esto ahorra el desarrollador el problema de tener que utilizar una solución basada en scripts , y permite a los proveedores de navegadores incluir tecnologías para ayuda de una manera consistente. Además, el uso generalizado del atributo (en lugar de secuencias de comandos existentes) nos asegura que el texto del marcador de posición tendrá un aspecto y comportamiento, a lo largo de la Web, uniforme, incrementando la accesibilidad y facilitando el aprendizaje de uso de los sitios web.
Hay que tener en cuenta que está explícitamente prohibido por la especificación HTML5 dejar sin etiquetas explicitas los marcadores de posición de texto.
-
Campos requeridos (required)
La capacidad de indicar que un campo es requerido ha sido posible con ARIA desde hace algún tiempo, e incluso se apoyó en los navegadores más modernos y los lectores de pantalla. Esta solución es mucho mejor que la comúnmente utilizada de “añadir un asterisco al texto de la etiqueta” ya que permite a los agentes de usuario y tecnologías de apoyo informar al usuario de que un campo en particular se requiere. HTML5 va un paso más allá añadiendo una característica directamente a la sintaxis HTML (no requiere ARIA), con la idea de que el navegador no sólo mostrará los elementos requeridos de forma diferente , sino que proporcionará automáticamente los mensajes de error (en una forma accesible, suponemos) cuando alguien intenta enviar un formulario sin haber llenado en todos los valores requeridos.
-
Patrones (pattern)
El atributo pattern de HTML5 incrementa las capacidades del atributo required al indicar que un campo de entrada particular debe tener un valor que coincide con una cierta expresión regular definida por el desarrollador. Esto permite recibir los datos estrictamente con un formato predefinido (por ejemplo, en el caso de los números de tarjetas de crédito) de forma que, la validación automática del lado del cliente, permite reportar errores.
La especificación exige que, cuando se utiliza el atributo patrón, también se añada un título que explique los detalles del modelo que se verificará.
Si este atributo no nos cubre todas las necesidades de nuestra aplicación, HTML5 proporciona una interfaz para acceder a las funciones de validación de formularios a través de secuencias de comandos (código de demostración).
Listado de los artículos en la web de WebAim:
- Future Web Accessibility: HTML5 <video>
- Future Web Accessibility: HTML5 Semantic Elements
- Future Web Accessibility: New <input> Types in HTML5
- Future Web Accessibility: HTML5 <input> Extensions
Otros artículos de interés:
- Autofocusing a form control – HTML5 [whatwg.org]
- The placeholder attribute – HTML5 [whatwg.org]
- The required attribute – HTML5 [whatwg.org]
- The pattern attribute – HTML5 [whatwg.org]
- A Form of Madness – Dive Into HTML5 [diveintohtml5.org]
- The accessibility of HTML 5 autofocus – Bruce Lawson [brucelawson.co.uk]
- States of the type attribute – HTML5 [whatwg.org]
- A Form of Madness – Dive Into HTML5 [diveintohtml5.org]
- HTML5 Input Types | 456 Berea Street [456bereastreet.com]
- Sections – HTML5 [whatwg.org]
- New Semantic Elements in HTML5 – Dive Into HTML5 [diveintohtml5.org]
- HTML5 articles and sections: what’s the difference? – Bruce Lawson [brucelawson.co.uk]
- HTML5 and the myth of WAI-ARIA redundance [paciellogroup.com]
- Annotations for assistive technology products (ARIA) [whatwg.org]
- The video element – HTML5 [whatwg.org]
- Multimedia Accessibility <Audio> <Video> [w3.org]
- Video on the Web – Dive Into HTML5 [diveintohtml5.org]
- Introduction to HTML5 video [opera.com]
- Everything you need to know about HTML5 video and audio [opera.com]
Contenidos relacionados
