Reseña: Monográfico "Accesibilidad Web" de la revista Novática

Editores invitados: Emmanuelle Gutiérrez y Restrepo, María del Carmen Ugarte García y Loïc Martínez Normand

Autores: Miguel Ángel Valero (entrevista), Terrill Thompson, Olga Revilla, Olga Carreras, Andy Heath, Rory Heap, Lisa Seeman, Shadi Abou-Zahra, Fernando Machicado Martín, José Ángel Martínez Usero y más.

Nº páginas: 86

Idioma: español

Formato: versión digital

Fecha de publicación: 2015

Revista: Monográfico "Accesibilidad Web", revista Novática, nº 232, abril-junio 2015 (PDF, 4MB)

 

Novática es la revista de la Asociación de Técnicos de Informática (ATI), decana de la prensa informática española, creada en 1975 y de periodicidad trimestral (más información sobre la revista Novática).

El número 232 (abril-junio 2015) es un monográfico sobre "Accesibilidad Web" con tres editores invitados de lujo: Emmanuelle Gutiérrez y Restrepo (Patrona y Directora General de Fundación Sidar), María del Carmen Ugarte García (socia sénior de ATI) y Loïc Martínez Normand (profesor de la Universidad Politécnica de Madrid y presidente de Fundación Sidar).

He tenido el placer de poder colaborar en el monográfico con el artículo "Documentos electrónicos accesibles". En él explico las buenas prácticas, -sencillas y al alcance de todos-, que podemos seguir en los documentos que creamos y divulgamos para favorecer que sean accesibles para todos.

La revista está disponible solo en formato digital. En la web de la revista podéis encontrar el sumario completo y el resumen de cada artículo: "Monografía: Accesibilidad web", revista Novática, nº 232, abril-junio 2015.

A continuación voy a reseñar los 9 artículos que componen propiamente la monografía sobre Accesibilidad Web.

Presentación. Accesibilidad Web: Tendencias de Futuro

Autores: Emmanuelle Gutiérrez y Restrepo, María del Carmen Ugarte García y Loïc Martínez Normand.

En la presentación se introduce qué es la accesibilidad web y los diferentes artículos que se incluyen en la monografía, cuyo objetivo es ofrecer información actualizada y relevante sobre las tendencias de futuro en el campo de la Accesibilidad Web.

De la presentación me quedo con este párrafo:

Hoy en día debería ser natural considerar que un buen profesional del diseño y desarrollo web debe ser capaz de desarrollar sitios web accesibles, de la misma forma que se preocupa de otros aspectos como la eficiencia, la seguridad y la privacidad. Por lo tanto, las técnicas de diseño y desarrollo accesible deben formar parte de la “caja de herramienta” que los diseñadores y desarrolladores tienen a su alcance para realizar correctamente su trabajo.

No obstante, al día de hoy, la accesibilidad sigue considerándose un plus, algo que puede distinguir nuestro trabajo frente a otros, y por supuesto es deseo de estos editores el que esta diferencia desaparezca lo antes posible.

CEAPAT: El diseño para todos como objetivo fundamental

Entrevista a Miguel Ángel Valero, director de CEAPAT (Centro de Referencia Estatal de Autonomía Personal y Ayudas Técnicas)

Es una entrevista extensa y muy interesante. Parte de qué es el CEAPAT y cuáles son sus programas de acción:

Es frecuente que vengan investigadores del área TIC, tanto nacionales como de proyectos europeos, en busca de asesoramiento por parte del CEAPAT con el fin de no reinventar la rueda

Hace hincapié en lo relevante que es la formación, no solo en las carreras técnicas, sino también la formación para los profesores y educadores, donde se enmarca por ejemplo la publicación "Diseño para todos en educación" (PDF), 2015.

Miguel Ángel Valero también reflexiona sobre la situación actual de la accesibilidad web en España o sobre las razones que subyacen tras la falta de accesibilidad en los sitios web.

Una parte muy interesante de la entrevista es la que versa sobre las denuncias, sanciones y el proceso de resolución de quejas así como el papel que en ellas tiene el CEAPAT. Aunque la labor del CEAPAT es más formativa y divulgativa, están haciendo informes técnicos cuando las denuncias llegan al CENTAC, en quien ha delegado Red.es, que es quién lo gestiona y hace la canalización técnica:

Cuando llegan a nosotros esas denuncias es porque la accesibilidad de esas webs ha sido certificada previamente por entidades privadas, y a lo mejor sí lo era el diseño pero no la implementación. Entonces nosotros aconsejamos cómo hacerlo bien, no tanto qué es lo que está mal, porque lo que está mal con validadores o peritajes técnicos es suficiente.

En los casos que conozco de cerca encuentro rigor técnico en la ejecución de los informes, pero hay plazos demasiado largos en las entidades denunciadas para que procedan a su ejecución.

[...]

Entonces el papel del CEAPAT es más formativo, el papel del CERMI y otras entidades es más de denuncia y el de Red.es es la canalización técnica para que se cumpla, y está bien que estemos separados, para que no haya un efecto “juez y parte”.

También comenta que las entidades se suelen aferrar a la norma antigua WCAG 1.0. Por último reflexiona extensamente sobre el futuro de la accesibilidad web, la accesibilidad móvil, la accesibilidad en redes sociales o la accesibilidad para las personas mayores.

El concepto de accesibilidad llega al gran público cuando se da cuenta de que su producto no es solo útil para él, sino también para otros con alguna limitación en su capacidad funcional y para él mismo, caso de que la tuviera. La accesibilidad llega cuando se comprende que un producto no solo te beneficia a ti mismo, sino también a los que te rodean y a tu entorno.

Deberíamos dar a conocer como diseñando para todas las personas se diseña para cada uno y no a la inversa, pues se entendería mejor la accesibilidad universal. Es imprescindible que la gente comprenda que la necesidad también es tuya, porque el gran público, una vez que comprende, colabora.

Vídeos accesibles para todos

Autor: Terrill Thompson, especialista en accesibilidad tecnológica en la Universidad de Washington.

Comienza con una introducción sobre la importancia de hacer vídeos accesibles, y los estándares del W3C relacionados:

• las WCAG 2.0, donde podemos encontrar los criterios de conformidad que han de cumplir;
• HTML 5,
  • con sus nuevos elementos vídeo y track que permiten insertar vídeo usando solo HTML y sincronizar con ellos ficheros de texto marcados con tiempo,
  • o con su API multimedia que permite construir reproductores propios usando JavaScript para controlar los elementos multimedia;
• WebVTT (Web Video Timed Text), formato para las pistas de texto marcadas con tiempo.

En el grueso del artículo repasa las soluciones para hacer más accesibles los vídeos. Además de explicar cada una de ellas, repasa el soporte actual de las mismas:

• Subtítulos para personas sordas (captions) y subtítulos para traducción (subtitles), y el soporte de track y su atributo kind="captions" y kind="subtitles". Habla también de herramientas libres para incluir subtítulos, de experiencias de crowdsourcing para crear subtítulos (como el proyecto OpenTranslation de TED) o de la tecnología ASR (Automatic Speech Recognition) que usa Youtube. Me parece interesante su reflexión, en la que no reparamos a menudo: la mayor barrera que impide el acceso a la información es el idioma, "la mayor parte del contenido en Internet está únicamente en inglés, idioma que habla solo el 14% de la población mundial".
• Audiodescripción y el soporte de track y su atributo kind="descriptions" (donde se referencia al fichero WebVTT para que sea leído por el navegador o el lector de pantalla del usuario).
• Transcripciones, reflexiona sobre la importancia de las transcripciones, no solo para las personas con discapacidad, sino también para las personas que disponen de poco ancho de banda (habitual en los países en desarrollo) o incluso para las personas muy ocupadas, que pueden echar un vistazo a la transcripción sin tener que visualizar todo el texto o que pueden buscar en el mismo.
• Lengua de señas (HTML5 no facilita un mecanismo específico).
• Reproducción a velocidad variable, y como HTML5 incluye la posibilidad de modificar la velocidad de reproducción a través de la API.
• Controles de reproducción accesibles, y repasa criterios de las WCAG 2.0
• Preferencias del usuario

Al final del artículo aborda el tema de los reproductores de vídeo HTML5 nativos frente a los reproductores de terceros. Incluye un listado de reproductores multimedia HTML5 con soporte para accesibilidad (lista completa disponible en Media Player Accessibility Comparisons).

Destaca claramente el reproductor Able Player, disponible en castellano, puesto que incluye soporte para subtítulos para sordos, subtítulos de traducción, audiodescripción, lengua de señas y reproducción a velocidad variable, además de que ha sido cuidadosamente diseñado para asegurar que sus botones y controles sean accesibles para cualquiera usuario.

En definitiva, un artículo muy interesante que merece la pena leerlo detenidamente.

WAI-ARIA, el gran desconocido de la accesibilidad web

Autor: Olga Revilla, autora de "WCAG 2.0 made easy" que reseñé en su día en el blog.

El artículo resume qué es WAI-ARIA, para qué sirve y a quién beneficia o cómo se implementa, incluyendo varios ejemplos. Creo que consigue sintetizar de manera muy clara todo ello, intentando demostrar, como dice, que la complejidad de su implementación es más aparente que real.

La autora reflexiona también sobre las razones que hacen de WAI-ARIA una de las tecnologías menos conocidas e implementadas por los desarrolladores, algo con lo que estoy de acuerdo y por lo cual me parece muy importante que haya artículos como este.

Le agradezco la referencia a mi post "WAI-ARIA. Introducción, referencias, ejemplos, herramientas", que se enmarca en ese esfuerzo por difundir la especificación WAI-ARIA en español.

Documentos electrónicos accesibles

Autor: Olga Carreras.

Le agradezco a Emmanuelle Gutiérrez y Restrepo que haya contado conmigo para divulgar las buenas prácticas que se han se seguir para crear documentos electrónicos más accesibles.

Incluyo el resumen formal del artículo, que espero poder publicar para su libre descarga a corto plazo.

Todos los días se generan y comparten millones de documentos electrónicos, pero por desgracia, la mayoría de estos documentos presentan barreras de accesibilidad. Esto impide que muchas personas puedan participar en la Sociedad de la Información y del Conocimiento con igualdad de oportunidades.

La accesibilidad es un derecho de todos, pero también una responsabilidad compartida. Como creadores y divulgadores de contenidos en formato digital, está en nuestras manos favorecer que todas las personas puedan percibirlos, entenderlos e interactuar con ellos de forma satisfactoria.

Para lograrlo, vamos a repasar una serie de buenas prácticas, sencillas y al alcance de todos, que puedes aplicar a cualquier tipo de documento electrónico en tu día a día.

Texto, imágenes y traducción en Facebook

Autores: Andy Heath, autor y colaborador de muchos estándares internacionales técnicos de soporte a la accesibilidad; y Rory Heap, coordinador de accesibilidad en la Consumer and Public Interest Network dentro del British Standards Institution (BSI).

Gran parte de las publicaciones en Facebook son o incluyen imágenes como parte del contenido. Sin embargo, pocas de estas imágenes son accesibles para las personas que, por cualquier razón, no pueden acceder al contenido visual, o bien necesitan traducir el texto que incluyen; y para demostrarlo exponen los resultados de un estudio informal.

El grueso del artículo, y el objetivo final del mismo, trata sobre la descripción de una solución usable que permita a los usuarios incluir alternativas textuales a las imágenes que publican en Facebook.

En este artículo argumentaremos que la integración del soporte OCR en una interfaz simple, invocada en tiempo de publicación de la imagen, combinada con el soporte de herramientas de autor para la inclusión de un texto alternativo que describa el contenido de las imágenes mejoraría significativamente la accesibilidad y enriquecería la audiencia de muchos posts en Facebook.

Repasan diferentes casuísticas que se pueden dar: imagen informativa, imagen cuyo contenido se describe en el post, imagen decorativa no relevante para la compresión del post (caso muy raro en Facebook) o imagen en la que desvelar el texto alternativo podría interferir con el propósito de publicar la imagen o del propio post (por ejemplo un chiste visual).

La solución que proponen abarca no solo la publicación sino también cuando se comparte un post ya existente que contiene una imagen, ayudando a corregir la falta de texto alternativo a las misma si dicho texto no se está proporcionando ya.

Por otra parte, en la implementación se tiene también en cuenta la usabilidad, mediante un procedimiento no intrusivo, que no ralentice al usuario y que no le suponga mucho trabajo adicional, pues de lo contrario lo más probable es que no use el procedimiento.

En el artículo "Texto, imágenes y traducción en Facebook" (PDF) podéis consultar la propuesta detallada con imágenes que lo ilustran.

Grupo de Trabajo de Accesibilidad para Discapacidades Cognitivas y Dificultades de Aprendizaje (COGA)

Autor: Lisa Seeman, coordinadora del grupo de trabajo COGA del W3C

El objetivo del grupo de trabajo Cognitive A11Y TF consiste en mejorar la accesibilidad de la web para las personas con discapacidades cognitivas y dificultades de aprendizaje. Este trabajo forma parte de las WCAG y de la Iniciativa de Accesibilidad Web (WAI) del W3C.

La autora explica los progresos y primeros borradores (ya comenté en "Pautas de accesibilidad que benefician a las personas con discapacidad cognitiva" que su principal documento es Cognitive Accessibility User Research), o en qué están trabajando. Como dice la autora, conforme la población va envejeciendo encontrar soluciones en este campo es algo cada vez más urgente desde una perspectiva humana, económica y empresarial.

Me quedo con una reflexión muy interesante que hace en el artículo:

Las dificultades de aprendizaje y las discapacidades cognitivas están entre las deficiencias menos comprendidas por los profesionales de la accesibilidad

[...]

La mayoría de las necesidades que debemos satisfacer respecto a la accesibilidad hacen referencia a las discapacidades sensoriales o físicas [...], que representan aproximadamente un 0,4 % de un mercado impulsado fundamentalmente por las denuncias de grandes grupos de defensa internacionales.

No obstante, aunque los usuarios con discapacidades cognitivas representan entre el 6,3 % y el 11 % del mercado en los Estados Unidos, la accesibilidad apenas ha prestado atención a dichas discapacidades y eso que esta cifra no incluye a las personas con un deterioro cognitivo leve debido a la edad.

Evaluación de la accesibilidad de los sitios web

Autor: Shadi Abou-Zahra, líder de la Oficina Internacional de Programas de la W3C Web Accessibility Initiative (WAI)

El artículo es una descripción detallada de la Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0, el documento del W3C que proporciona una metodología armonizada internacionalmente para la evaluación de todo tipo de sitios web.

Traduje en 2012 el documento al español Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM) (y lo he ido actualizando a medida que el documento evolucionaba) por la importancia que creo que tiene.

Debido a que generalmente no es factible evaluar cada una de las páginas de un sitio web, resulta fundamental emplear un método fiable para determinar el nivel de accesibilidad, de forma global, de un sitio web completo.

La WCAG-EM 1.0 especifica los pasos concretos, y ofrece orientación sobre las buenas prácticas para definir el alcance de la evaluación, explorar el sitio, seleccionar una muestra representativa cuando no es factible evaluar todo el sitio, auditar la muestra seleccionada y reportar los resultados de la evaluación mediante informes estructurados y uniformes.

El artículo termina con un apartado dedicado a WCAG-EM Report Tool, herramienta de software libre, que no es un validador sino un generador de informes que guía a los evaluadores por todos los pasos descritos en la WCAG-EM 1.0 (lo reseñé en WCAG-EM Report Tool. Herramienta de generación de informes de una evaluación de accesibilidad).

El autor también comenta que se está rediseñando y actualizando How to Meet WCAG 2.0 para hacerlo más dinámico y personalizable, y que se pretende integrarlo en la WCAG-EM Report Tool para facilitar el paso de la inspección del proceso de evaluación.

Las compras públicas como motor de una mayor accesibilidad TIC en Europa

Autores: Fernando Machicado Martín, de AENOR, secretario de varios comités de normalización relacionados con la accesibilidad y que participó como secretario en las fases finales de los trabajos del Mandato 376 de la Comisión Europea; y José Ángel Martínez Usero, responsable de Asuntos Internacionales de Funka, una empresa sueca especializada en accesibilidad

Se introduce el contexto internacional y europeo en materia de accesibilidad TIC, y se presentan los principales resultados del Mandato 376 de la Comisión Europea sobre la accesibilidad en la contratación pública de productos y servicios TIC. En particular, la norma UNE-EN 301 549 y la herramienta web para facilitar las compras públicas de productos y servicios TIC accesibles (toolkit).

La contratación pública de bienes y servicios supone alrededor del 18% del PIB de la Unión Europea (UE). Este hecho le da la fuerza para ser un sector estratégico con capacidad de hacer de palanca para la implementación de medidas efectivas de accesibilidad, así como para la concienciación de la sociedad.

Por ello, la Comisión Europea lanzó dos mandatos (M/376 y M/420) para elaborar normas técnicas que impulsaran la accesibilidad en las compras públicas, y que fomenta que la industria desarrolle productos más accesibles, más baratos y más eficientes. Ambos mandatos dan soporte técnico a las políticas europeas de accesibilidad y a la futura y esperada Ley europea de accesibilidad (Accessibility Act).

El documento principal resultante del mandato M/376 es la Norma EN 301 549 ‘Requisitos de accesibilidad adecuados para la contratación pública de productos y servicios TIC en Europa’, primera norma europea de accesibilidad para productos y servicios de TIC considerados de modo global, aplicable a las compras públicas, y redactada bajo este enfoque pero no de modo limitativo.

Esta norma establece los requisitos funcionales que garantizarán que los productos y servicios TIC sean accesibles para todas las personas; por ejemplo, desde un teléfono móvil y ordenadores, pasando por páginas web hasta servicios en la nube. Los requisitos para la web se basan en las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.0

Reseñé la norma en el artículo EN 301 549: primera norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC)

También habla de la herramienta desarrollada para facilitar la aplicación de la norma: “Herramienta web para las compras públicas de productos y servicios ICT accesibles”

Por último termina con una reflexión sobre si las WCAG 2.0, de 2008, se adaptan a los tiempos, por ejemplo al acceso mediante dispositivos móviles o a si cubren todos los aspectos de la discapacidad cognitiva. O de la importancia de superar las limitaciones de las legislaciones nacionales que establecen los mínimos requisitos a cumplir pero no el objetivo final que se desea: satisfacer las necesidades de los usuarios, ser competitivos y desarrollar productos de calidad y hacer felices a los usuarios ("Why WCAG is not enough", Funka).

Una posible receta para diseño web accesible orientado a las tendencias del mercado actual, podría ser:

• Usar tecnologías de desarrollo avanzadas: web reactiva.
• Seguir la norma UNE 139803 (WCAG 2.0) como base.
• Utilizar guías profesionales para un diseño accesible sofisticado.
• Considerar los aspectos de accesibilidad que más afectan a los usuarios finales y cubrir esos aspectos con requisitos extra.
• Probar el servicio/producto con usuarios finales

Podéis consultar más reseñas de libros o publicaciones en: "Libros y reseñas"

Otras reseñas del monográfico:

• Loïc Martínez Normand editor de la monografía sobre "Accesibilidad Web" en Novática, en la ETSI

Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales. Documento del W3C y checklist.

El objetivo de este artículo es divulgar el documento del W3C: "Media Accessibility User Requirements".

Este documento repasa los requisitos de accesibilidad que deben cumplir los contenidos audiovisuales para cubrir las necesidades de las personas con discapacidad.

Explica los diferentes tipos de contenidos alternativos que se pueden ofrecer, a quiénes benefician y los requisitos que deben cumplir; recoge asimismo los que debería cumplir el sistema, abarcando el proceso de producción o los agentes de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia).

Es un documento íntimamente relacionado con las WCAG y las UAAG, por ello, al final del documento tenemos una checklist con todos los requisitos donde, entre otras cosas, se indica si están relacionados con criterios de conformidad de las WCAG y las UAAG.

Hay que tener en cuenta que está todavía en fase borrador de trabajo, se lleva trabajando en él desde el año 2012. Actualmente la última versión es Editor Draft del 09 de octubre de 2015, y es en la que me voy a basar para presentarlo y resumirlo. Iré actualizando el artículo a medida que el documento evolucione.

Estructura del documento

El documento está estructurado fundamentalmente en cuatro grandes apartados:

• Resumen de los requisitos de accesibilidad de los medios audiovisuales por tipo de discapacidad.

  En este apartado se proporciona una introducción a las necesidades de los usuarios con discapacidad (ceguera, baja visión, daltonismo, sordera, problemas de audición, sordoceguera, discapacidad física y discapacidad cognitiva) en relación con el contenido audiovisual.

• Tecnologías para proporcionar contenido alternativo.

  En esta sección se explican los diferentes tipos de contenidos alternativos que se pueden proporcionar para ayudar a los usuarios con una discapacidad sensorial a acceder al contenido audiovisual. Por cada uno de ellos se incluye un listado de los requisitos que deben satisfacer en el contexto de un desarrollo HTML5 (pero no se entra en aspectos técnicos o de desarrollo concretos).

• Requisitos del sistema

  En este apartado se explica cómo las tecnologías para proporcionar contenido alternativo al vídeo y audio encajan en el panorama más amplio de la accesibilidad, tanto técnicamente, desde de un punto de vista del agente de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia) como desde un punto de vista del proceso de producción. Por ello, los requisitos listados en este apartado están en su mayoría más relacionados con las UAAG que con las WCAG.

• Checklist "Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales"

  Este es un apartado muy útil porque recoge la checklist con todos los requisitos listados en el documento.

  La checklist está en formato tabla, con una fila para cada requisito y diversas columnas para indicar:

  • su categorización respecto a la tecnología (si ya está en la especificación de HTML 5, si es un nuevo requisito de la especificación, etc.)
  • su relación con criterios de conformidad de las WCAG y las UAAG. Cuando se incluye el signo "+" se está indicando que el requisito de este documento se define con más precisión que en las WCAG o en las UAAG. De hecho, el grupo de trabajo de las UAAG (se está trabajando en las UAAG 2.0 actualmente) ha indicado que revisarán algunos de sus requisitos en base a esta checklist.
  • su prioridad (Must, Should o May)

  Esta checklist se puede consultar también individualmente en la wiki del W3C Media Accessibility Checklist

Resumen de los requisitos de accesibilidad de los medios audiovisuales por tipo de discapacidad

En este apartado se proporciona una introducción a las necesidades de los usuarios con discapacidad para poder percibir, interactuar y comprender los contenidos audiovisuales.

Para una información más amplia sobre cómo las personas con discapacidad interactúan con el contenido web recomienda el documento imprescindible del W3C: How People with Disabilities Use the Web.

Ceguera

Las personas ciegas no pueden acceder a la información visual presente en los vídeos, los controles de los reproductores o los indicadores de estado. Por ello necesitan que la información se presente de forma alternativa mediante texto o audio.

Hay que tener en cuenta que las personas ciegas utilizan un lector de pantalla y/o una línea braille, por tanto necesitan que los medios audiovisuales sean operables cuando se utilizan estos productos de apoyo.

Baja visión

Las personas con baja visión, en función de su capacidad visual, puede ser que tengan problemas específicos, como dificultad para discriminar la información de primer plano de la información de fondo, para discriminar colores, o les pueden deslumbrar los contenidos muy brillantes.

Por otra parte, quizás no puedan reaccionar rápidamente a la información que se presenta en pantalla durante un tiempo limitado. Pueden tener un ángulo de visión estrecho que no les permita detectar la información clave presentada temporalmente si no están mirando en esa dirección, o si el texto se está moviendo o desplazando.

Estas personas utilizarán probablemente un magnificador de pantalla, así que solo estarán viendo una parte de la pantalla, por ello se debe poder gestionar el contenido audiovisual a través de su producto de apoyo.

Las personas con baja visión pueden tener dificultad para leer el texto demasiado pequeño, con poco contraste, con un determinado tipo de fuente o con efectos. Por otra parte, si el texto es una imagen, se verá pixelada al ampliarse.

Pueden estar utilizando un producto de apoyo que modifique los colores, por ejemplo que los invierta, de modo que los contenidos audiovisuales deben ser visibles también en este contexto.

Por último, los usuarios con baja visión a menudo se benefician también de los textos e instrucciones que algunas veces los autores ocultan visualmente (por ejemplo colocándolos fuera de pantalla) dirigidos a los usuarios de lector de pantalla o línea braille.

Percepción del color

Las personas con problemas en la percepción del color (daltonismo) pueden tener dificultades para discriminar entre diferentes colores, o pueden perderse información clave cuando la información se proporciona solo mediante el color, por ejemplo en los controles del audio/vídeo o en las superposiciones de texto.

Sordera

Las personas sordas no podrán escuchar el audio, por tanto será necesaria una alternativa, normalmente a través de subtítulos sincronizados y/o traducción en lengua de signos.

Problemas de audición

Las personas con problemas de audición podrían no ser capaces de discriminar cierto tipo de sonidos, y por tanto pueden perderse información presente en el audio si tiene frecuencias que no pueden oír, o bien a causa del ruido de fondo o la distorsión.

También pueden perderse información si el audio es demasiado bajo o de mala calidad, o si las personas hablan demasiado rápido y no se puede reproducir el audio más lento.

La información que se presenta mediante audio multicanal puede no ser percibida por las personas sordas de un oído.

Por último, las personas con un implante coclear pueden no tener problemas con el volumen del audio, pero la comprensión puede ser difícil si la experiencia multimedia es abrumadora.

Sordoceguera

Según su nivel de ceguera y sordera, las personas sordociegas podrían necesitar: subtítulos y la posibilidad de ampliarlos; cambiar a colores de alto contraste (u otra combinación de colores); subtítulos y/o descripción del vídeo expuestos por su producto de apoyo; o una transcripción que cada usuario pueda leer a su ritmo, es decir, que no esté basada en el tiempo.

Discapacidad física

Algunas personas con discapacidad física, como aquellas con un control muscular limitado (temblores, falta de coordinación, parálisis), con dolor que les impida el movimiento o con la falta de alguna extremidad, no podrán utilizar el teclado o el ratón para interactuar con el contenido y los controles.

El reproductor de los contenidos audiovisuales tiene que poder ser operable solo con el teclado (sin ratón), lo cual incluye el acceso a todos los controles y métodos de selección del contenido alternativo.

Discapacidad cognitiva

Autismo, dislexia, discalculia, trastorno de déficit de atención, problemas de memoria, ... la extensa gama de condiciones que abarca hace que los requisitos de accesibilidad también varíen ampliamente.

Algunas personas podrán procesar la información auditiva mejor que la lectura del texto, por tanto, la información que se presenta como texto embebido en el vídeo también deberá estar disponible como descripciones de audio.

Otras personas pueden necesitar reducir las distracciones o flashes en las presentaciones de vídeo.

En general, la experiencia multimedia para las personas con trastornos del espectro autista debe ser personalizable y estar bien diseñada para no resultar abrumadora.

Se debe tener cuidado en presentar la experiencia multimedia focalizada en el propósito del contenido y proporcionar alternativas al contenido de una manera clara y concisa.

Tecnologías para proporcionar contenido alternativo

En esta sección se explican los diferentes tipos de contenidos alternativos que se pueden proporcionar para ayudar a los usuarios con una discapacidad sensorial a acceder al contenido audiovisual. Por cada uno de ellos se incluye un listado de los requisitos que deben satisfacer en el contexto de un desarrollo HTML5 (pero no se entra en aspectos técnicos o de desarrollo concretos).

Audiodescripción

Una audiodescripción contiene una narración descriptiva de los elementos visuales clave para hacerlos accesibles a las personas ciegas o con una discapacidad visual. Se incluyen acciones, vestuario, gestos, cambios de escena o cualquier otra información visual relevante que alguien que no puede ver la pantalla podría perderse.

Las audiodescripciones son grabaciones de audio que se insertan en las pausas naturales del mismo, aunque a veces pueden oscurecer brevemente la pista de audio principal (ir a audiodescripción ampliada).

Pueden ser de dos tipos:

• Abiertas, se fusionan con la pista de audio y no pueden ser desactivadas por el usuario.
• Cerradas, el usuario puede activarlas o desactivarlas. Puede ser una pista separada, puede estar programada para reproducirse en puntos específicos de la línea de tiempo y en paralelo con la pista de audio principal.

Algunas descripciones pueden ser entregadas como un canal de audio independiente que se mezcla en el reproductor. Otra opción es tener una pista de "texto a voz" generada por ordenador, que se trata en la siguiente sección (ir a audiodescripciones en formato texto).

Las audiodescripciones no solo benefician a las personas ciegas o con problemas de visión. Por ejemplo, pueden beneficiar a los estudiantes que lidian con materiales o conceptos difíciles, puesto que la audiodescripción puede dar información complementaria acerca de lo que se está viendo en pantalla (la estructura de una ecuación, la complejidad de una pintura, etc.).

Hay programas de televisión y salas de cine de EEUU (y otros países) que ofrecen audiodescripciones. Las regulaciones en EEUU y Europa se están centrando cada vez más en ellas, en especial en el ámbito de la televisión, lo que refleja su importancia para las personas con discapacidad visual.

La tecnología necesaria para crear y ofrecer audiodescripciones es sencilla, pero es necesario que los reproductores sean compatibles con varios canales de audio.

Hay que tener en cuenta que las descripciones también podrán después proporcionarse en formato texto para que puedan ser indexadas y ser susceptibles de búsquedas.

El apartado termina con el listado de los 13 requisitos. Se pueden consultar en la tabla resumen (que como ya hemos comentado, incluye su relación con las WCAG y las UAAG): Media Accessibility Checklist.

Audiodescripciones en formato texto

Cuando la audiodescripción se proporciona en formato texto, en vez de en formato voz grabada, se presentan unos requisitos específicos.

Las audiodescripciones en formato texto (TVDs) se entregan al cliente como texto y son renderizadas localmente por los productos de apoyo (lector de pantalla o línea braille). Los ficheros de texto se proporcionan como archivos de texto que contienen los tiempos de comienzo de cada descripción. Las ventajas son que el usuario de lector de pantalla puede tener un control total sobre la voz, la velocidad del habla u otras opciones.

Sin embargo, como consecuencia de todo ello, no podemos saber cuánto tardará en leerlo el lector de pantalla (el usuario ha podido ralentizar o acelerar la voz respecto a lo que hemos estimado; o la descripción de una escena complicada puede requerir más tiempo), y por tanto no sabemos si oscurecerá el audio principal u otra descripción.

Por otra parte, las personas con baja visión también pueden beneficiarse de tener acceso a la audiodescripción en texto.

El apartado termina con el listado de 5 requisitos (Media Accessibility Checklist).

Audiodescripciones ampliadas

Las audiodescripciones se suelen introducir en las pausas naturales del diálogo o la narración. Pero en algunos casos no hay tiempo suficiente. Las audiodescripciones ampliadas (EVD) trabajan pausando el vídeo y el audio en momentos clave para reproducir la audiodescripción extensa, y una vez que termina reanudan la reproducción.

Las audiodescripciones ampliadas benefician por ejemplo a las personas con el síndrome de Asperger u otras personas con trastornos del espectro autista, ya que en ellas se puede explicar conexiones entre la causa y el efecto, se puede señalar lo que es más importante, o explicar los estados de ánimo.

En este caso se incluye un listado de 3 requisitos (Media Accessibility Checklist).

Clean audio

Un desarrollo relativamente reciente en la accesibilidad en televisión es el concepto de "audio limpio", que aprovecha el audio multicanal.

Beneficia especialmente a las personas con problemas de audición. Consiste en aislar el canal de audio que contiene los diálogos o la información relevante que así puede amplificarse (o modificarse de otro modo), mientras que los canales que tienen la música o los sonidos ambientales pueden atenuarse. Esto permite usar filtros y adaptar el audio a las necesidades del usuario, ya que la pérdida de audición es típicamente dependiente de la frecuencia.

Se listan 4 requisitos (Media Accessibility Checklist).

Navegación por el contenido a través de la estructura del contenido

La mayoría de los usuarios están familiarizados con el avance rápido y el rebobinado en el contenido audiovisual. Sin embargo, esta manera de explorar el contenido, basada en el tiempo, es bastante ineficaz y perjudica especialmente a las personas con discapacidad.

Afortunadamente, la mayoría de los contenidos tienen una estructura (los audiolibros tienen capítulos, las películas actos y escenas, los programas de televisión secciones, etc.). Un marcado adecuado puede exponer su estructura en los controles para avanzar y rebobinar.

Sin embargo, una navegación efectiva por la jerarquía de su estructura requeriría un control adicional que no suele estar disponible en los reproductores multimedia actuales. Este mecanismo (que llaman "granularity-level control") permitiría al usuario ajustar el nivel de granularidad aplicado a los controles "siguiente" y "anterior". La personalización sería necesaria porque puede ser muy engorroso acceder a todos los nodos de la jerarquía o insatisfactorio acceder solo a los del nivel superior de la jerarquía.

Se ponen varios ejemplos. Uno de ellos es el de un telediario. Las grandes secciones serían noticias, tiempo o deportes. El segundo nivel serían las noticias individuales de cada sección. Si dispusieras de este "granularity-level control" podrías ajustar el nivel de granularidad de los controles "siguiente" y "anterior" para saltar de sección en sección, o de noticia en noticia.

A continuación se habla de la navegación a través de contenidos auxiliares, como anuncios, resúmenes de noticias, notas al pie de un libro, etc. que interrumpen el "programa" primario, y que el usuario puede querer saltarlos (o tal vez ir directamente a ellos).

Se listan para terminar 10 requisitos (Media Accessibility Checklist).

Subtítulos

Para las personas sordas o con problemas de audición, los subtítulos son la principal alternativa al audio.

A diferencia de los subtítulos para personas cuyo idioma no es el del contenido, el subtitulado para sordos (captioning) no solo debe transcribir el diálogo o la narración, sino también la información importante como efectos de sonido, risas, etc., y debe estar en el mismo idioma que la pista de audio principal.

Los subtítulos pueden ser cerrados, es decir, pueden ser activados o desactivados por el usuario; o abiertos, que están siempre visibles, fusionados con la pista de vídeo y no pueden desactivarse.

Aunque lo ideal es que sea una transcripción literal del audio, a veces se editan por adecuarlos, por ejemplo, a la velocidad de lectura. Si se editan debería indicarse y debería proporcionarse una versión textual completa.

No es estrictamente necesario que el texto del subtítulo coincida con el movimiento de la boca, a veces pueden adelantarse o extender un poco.

Cuando hablan varias personas, en el texto de los subtítulos se debe distinguir a los oradores, por ejemplo indicando el nombre de la persona ("Ana:") antes del texto que representa lo que dice en el audio.

Los subtítulos también son muy útiles para que los clientes de bares, gimnasios, etc. sigan el programa en la televisión (yo añadiría que también para las personas que por el contexto no pueden activar o escuchar el audio y/o no tienen auriculares) o para las personas que no dominan el idioma. Por otra parte, los subtítulos tienen capacidad de búsqueda, lo que permite localizar un vídeo o un punto exacto del mismo.

Se listan por último 28 requisitos para que los formatos de subtítulos (Media Accessibility Checklist).

Subtítulos enriquecidos

Pueden tenerse varias pistas de subtítulos, por ejemplo uno adecuado para cada rango de edad.

Los subtítulos también pueden enriquecerse con más información, por ejemplo con un glosario (podría ser un enlace que pausa el contenido principal y permite acceso al material explicativo). Proporcionar información relevante adicional permite mejorar la comprensión de los elementos esenciales tanto para los usuarios de productos de apoyo como para las personas con dificultad en la lectura.

En este caso son 5 los requisitos que se listan (Media Accessibility Checklist).

Interpretación en lengua de signos

La lengua de signos no es universal, por tanto debe adecuarse a la audiencia. Es importante que la cara, los brazos, manos y gestos corporales se vean claramente, con suficiente resolución para que sean legibles. Por otra parte es preferible una persona que un avatar animado, al menos por el momento.

Igual que los subtítulos, pueden ser abiertos (siempre visibles) o cerrados (se puede activar/desactivar su visualización).

No todos los dispositivos podrán manejar múltiples flujos de vídeo, así que este debería ser un requisito del navegador. En las situaciones en las que no se soporte, por ejemplo en dispositivos móviles, los autores podrían ofrecer dos versiones, una de ellas con la interpretación en lengua de signos insertada en el vídeo. La selección de diferentes pistas de lengua de signos se haría de la misma manera que se manejan diferentes subtítulos.

Se listan 5 requisitos (Media Accessibility Checklist).

Transcripciones

Hay personas a las que no les es posible o les resulta difícil seguir los subtítulos sincronizados, como las personas sordociegas, las personas con problemas cognitivos o con dificultad en la lectura. Incluso las personas que sí pueden seguirlos podrían perderse información al dividir la atención entre lo que ocurre en pantalla y el texto de los subtítulos.

Por tanto, la transcripción completa ayuda a las personas con diferentes necesidades y no es un sustituto de los subtítulos. La transcripción se puede presentar simultáneamente con el contenido audiovisual, pero debería estar también disponible independientemente.

El contenido que se incluye en la transcripción es tanto el de los subtítulos como el de la audiodescripción (y las opciones interactivas si tiene), y es por tanto una representación completa del material.

Se listan 3 requisitos (Media Accessibility Checklist).

Requisitos del sistema

En este apartado se explica cómo las tecnologías para proporcionar contenido alternativo al vídeo y audio encajan en el panorama más amplio de la accesibilidad, tanto técnicamente desde de un punto de vista del agente de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia) como desde un punto de vista del proceso de producción.

Por ello, los requisitos listados en este apartado (se pueden consultar en Media Accessibility Checklist) están en su mayoría más relacionados con las UAAG que con las WCAG.

Acceso a los controles y menús interactivos

Todas las posibilidades de interacción deben estar disponibles para todos los usuarios. Por tanto deben ser independientes del dispositivo de entrada (teclado, ratón, habla, etc.) y ser expuestas a los productos de apoyo. Las posibilidades de interacción deben ser lo suficientemente ricas para un control detallado de la reproducción del contenido.

Se incluyen 6 requisitos.

Control del nivel de granularidad para la navegación por la estructura del contenido

Como se explicó en Navegación por el contenido a través de la estructura del contenido los usuarios deben ser capaces de establecer el rango o alcance de los controles "siguiente" y "anterior" en tiempo real, ajustando en qué nivel de la estructura del contenido quieren navegar con dichos controles.

Se incluyen 4 requisitos.

Modificación de la escala de tiempo

Por ejemplo en muchos reproductores de audiolibros, desde hace años, se puede acelerar o ralentizar la lectura del contenido sin alterar el tono del audio.

Se incluyen 5 requisitos.

Requisitos de la producción y los resultados

En este apartado se habla del desafío que supone la falta de un sistema universal de acceso, la convivencia de sistemas incompatibles, o la falta de formatos comunes que permita el intercambio de datos. Trata también de los recursos que se aportan por separado, pues los contenidos alternativos son a menudo creados por entidades diferentes a las que crean el contenido audiovisual, así como de las posibilidades de edición.

Se incluyen 4 requisitos.

Descubrimiento y activación/desactivación del contenido alternativo por parte del usuario

Se han descrito diferentes tipos de contenido alternativos que permitirán que las personas puedan percibir, interactuar y comprender el contenido audiovisual. Estas alternativas pueden ser parte del contenido, activarse o desactivarse o estar vinculadas al contenido original.

El usuario se enfrenta al reto de poder descubrir y reconocer que se proporcionan estos contenidos alternativos.

Se incluyen 9 requisitos.

Requisitos relativos a hacer que las propiedades estén disponibles para la API de accesibilidad

Los usuarios necesitan acceder a los contenidos, controlar su reproducción y activar las opciones de accesibilidad. Para que los agentes de usuario apoyen la API de accesibilidad implementada para una plataforma, los controles del reproductor tienen que exponer la información, en caso contrario hay que proporcionar la información en formatos alternativos.

Por ello la existencia de pistas de contenido alternativo debe ser expuesta al agente de usuario y la API de accesibilidad debe tener acceso a las mismas.

Se incluyen 3 requisitos.

Requisitos sobre el uso del visor de vídeo

El visor de vídeo juega un papel importante en lo que se refiere a los contenidos alternativos. Ofrece una caja delimitada para muchas de las alternativas que se ofrecen visualmente (subtítulos, lengua de signos, etc.), aunque no todas se basan en una ventana (como las transcripciones completas).

Hay que recordar que un tercio del vídeo será ocupado por el texto de los subtítulos. Los usuarios esperan encontrarlos en un lugar estándar y poder hacer movimientos oculares rápidos entre los mismos y el contenido del vídeo. Por tanto no se debe ocupar este espacio con otras cosas y se debe evitar la superposición con el contenido importante del vídeo.

Los requisitos de este apartado también hacen referencia a la relación entre el tamaño de la ventana de visualización, la posición de contenido audiovisual y la del contenido alternativo.

Por último se tratan las opciones de personalización por parte del usuario: del brillo y el contraste; de las características del texto (por ejemplo de los subtítulos) tamaño, color, etc.; o el ajuste del tamaño de visualización pero preservando la relación y evitando recortes.

Se incluyen 5 requisitos.

Requisitos sobre las pantallas secundarias y otros dispositivos

El término "second screen" hace referencia a que cuando vemos o consumimos contenido (por ejemplo en la televisión), la información contextual adicional o el propio contenido se puede visualizar en un dispositivo complementario (como una tablet o un móvil). Se llama "second screen" a pesar de que puede haber más de dos y a pesar de que no todos los dispositivos secundarios son pantallas de vídeo.

Hay que asumir que muchos usuarios tendrán un dispositivo de visualización adicional y/o un dispositivo de audio adicional (como unos auriculares) conectado al dispositivo de visualización principal. Por tanto debe ser posible configurar ciertos tipos de contenidos para su presentación en dispositivos específicos.

Se incluyen 7 requisitos.

Checklist de los Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales

Este es un apartado muy útil porque recoge la checklist con todos los requisitos listados en el documento.

La checklist está en formato tabla, con una fila para cada requisito y diversas columnas para indicar:

• su categorización respecto a la tecnología (si ya está en la especificación de HTML 5, si es un nuevo requisito de la especificación, etc.)
• su relación con criterios de conformidad de las WCAG y las UAAG. Cuando se incluye el signo "+" se está indicando que el requisito de este documento se define con más precisión que en las WCAG o en las UAAG. De hecho, el grupo de trabajo de las UAAG (se está trabajando en las UAAG 2.0 actualmente) ha indicado que revisarán algunos de sus requisitos en base a esta checklist.
• su prioridad (Must, Should o May)

Esta checklist se puede consultar también individualmente en la wiki del W3C Media Accessibility Checklist

Artículos relacionados

• Videos accesibles para todos, reseña del artículo de Terrill Thompson (en el monográfico "Accesibilidad web" de la revista Novática) donde el autor repasa las soluciones en HTML5 y su soporte actual.
• Tabla resumen de los requisitos de accesibilidad para los medios tempodependientes según las WCAG 2.0
• Reseña: "Accesibilidad a los contenidos audiovisuales en la web"

Un proyecto sobre HTML5 y accesibilidad a los contenidos audiovisuales ha ganado el premio Universia-Vodafone

Hace unos meses os recomendaba en el artículo "HTML 5 y accesibilidad" el trabajo fin de carrera de Alberto Sánchez-Heredero Pérez, tutorizado por Lourdes Moreno López ⁽¹⁾, "Accesibilidad a los contenidos audiovisuales en la Web a través de HTML5" (PDF, 2MB)

Ya entonces me pareció un trabajo muy bueno. Hoy me ha informado Alberto de que su proyecto ha sido el ganador del premio Fundación Universia-Fundación Vodafone España por favorecer la accesibilidad en el ámbito de las Tecnologías de la Información y la Comunicación (TIC).

Enhorabuena!

Se puede ver el visor en HTML 5 support for an accessible user-video-interaction on the Web. ACCESSIBLE HTML5 MEDIA PLAYER

(1) Ver Reseña: "Accesibilidad a los contenidos audiovisuales en la web" .

Tabla resumen de los requisitos de accesibilidad para los medios tempodependientes según las WCAG 2.1

En la pauta 1.2 "Medios tempodependientes: Proporcionar alternativas para los medios tempodependientes" de las WCAG 2.0/2.1 se especifican los requisitos de accesibilidad que deben cumplir los contenidos "solo audio" (1), "solo vídeo" (2) y "multimedia sincronizado" (3), según si dicho contenido es "grabado" (4) o "en directo" (5).

A continuación os dejo una tabla resumen que os puede ser de gran utilidad para identificar con rapidez las alternativas que debéis proporcionar en función del nivel de conformidad deseado.

	A		AA		AAA
	Grabado	En directo	Grabado	En directo	Grabado	En directo
Solo audio	Transcripción textual (6)	-	Transcripción textual	-	Transcripción textual	Transcripción textual
Solo vídeo	Transcripción textual o Alternativa en audio (7)	-	Transcripción textual o Alternativa en audio	-	Transcripción textual	-
Multimedia sincronizado	Subtítulos (8) + Transcripción textual o Audiodescripción (9)	-	Subtítulos + Audiodescripción	Subtítulos	Subtítulos + Audiodescripción + Interpretación en lengua de signos (10) + Audiodescripción ampliada (11) + Transcripción textual	Subtítulos

Hay que tener en cuenta que la pauta 1.2 indica que sólo son necesarias estas alternativas si el contenido tempodependiente no ofrece más información que la que ya se está ofreciendo mediante texto o alternativas textuales.

Ver ejemplo: Multimedia accesible

Notas

(1) Solo audio: una presentación basada en el tiempo que contine únicamente audio (sin vídeo y sin interacción)

(2) Solo vídeo: una presentación basada en el tiempo que contine únicamente imágenes (vídeo), sin sonidos (audio) ni interacción

(3) Multimedia sincronizado: el audio o vídeo sincronizado con otro formato para presentar información y/o con componentes interactivos basados en el tiempo, excepto cuando se trata de un contenido multimedia alternativo al texto y está claramente identificado como tal (por ejemplo una película con vídeo y audio; un juego que aunque solo tenga vídeo o audio incluye interacción, etc.)

(4) Grabado: información que no es en directo

(5) En directo: la información capturada de un evento de la vida real y transmitida al receptor sin más demora que el retardo intencional de la emisión. El retardo intencional es una demora corta (generalmente automatizada) que se usa, por ejemplo, para dar tiempo al órgano de difusión de censurar el audio (o vídeo) transmitido, pero no suficiente para permitir trabajos de edición significativos. Si la información es generada completamente por una computadora no es en directo.

(6) Transcripción textual: (en las WCAG se denomina "alternativa para los medios tempodependientes") documento que incluye una secuencia correcta de descripciones textuales de la información visual y auditiva tempodependiente, y que proporciona los medios para lograr los resultados de cualquier interacción basada en el tiempo. El guión empleado para crear el contenido multimedia sincronizado podría satisfacer esta definición sólo si ha sido corregido para representar con precisión el contenido multimedia sincronizado resultante tras la edición.

(7) Alternativa en audio: pista sonora que presenta información equivalente al contenido del medio de sólo vídeo grabado.

(8) Subtítulos: alternativa visual y/o alternativa textual, sincronizada, para la información sonora necesaria para comprender el contenido multimedia, que puede ser tanto hablada como no hablada. Los subtítulos para sordos son similares a los subtítulos que presentan sólo los diálogos, excepto por que los subtítulos para sordos transmiten no sólo el contenido de los diálogos sino también equivalentes para la información sonora que no es diálogo y que es necesaria para comprender el contenido del programa, incluyendo efectos sonoros, música, risas, identificación del hablante y localización.

(9) Audiodescripción: la narración agregada a la pista de sonido para describir los detalles visuales importantes que no se pueden entender sólo con la banda de sonido principal. La audiodescripción del vídeo proporciona información sobre las acciones, personajes, cambios de escena, textos que aparecen en pantalla y otros contenidos visuales. En las audiodescripciones estándares, la narración se añade durante las pausas existentes en el diálogo. Cuando toda la información sobre el vídeo ya se proporciona en el audio de la presentación, no es necesaria ninguna audiodescripción adicional. En inglés también se la denomina "video description" (descripción de vídeo) o "descriptive narration" (narración descriptiva).

(10) Interpretación en lengua de signos: La traducción de un idioma, generalmente un idioma hablado, a lengua de signos. Las lenguas de signos auténticas son idiomas independientes que no están relacionados con las lenguas habladas del mismo país o región.

(11) Audiodescripción ampliada: audiodescripción que se agrega a una presentación audiovisual poniendo en pausa el vídeo, de manera que haya tiempo suficiente para agregar una descripción adicional. Esta técnica se emplea sólo cuando el sentido del vídeo se perdería sin el añadido de una audiodescripción y las pausas entre el diálogo o la narración son demasiado cortas.

Artículo relacionado:

• Reseña: "Accesibilidad a los contenidos audiovisuales en la web"
• Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online
• Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales. Documento del W3C y checklist.

Incluir vídeos de YouTube de forma accesible

Artículos relacionados
[12.04.09] Reseña: "Accesibilidad a los contenidos audiovisuales ..."
[20.11.07] Accesibilidad web y discapacidad auditiva

Insertar el vídeo mediante código válido

YouTube te indica para cada vídeo cuál es su URL y cuál es el código que se ha de insertar en una página para verlo en línea. El código que proporciona es como el que sigue:

<object width="425" height="344">
<param name="movie"
value="http://www.youtube.com/elvideo"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always">
</param>
<embed src="http://www.youtube.com/elvideo"
type="application/x-shockwave-flash"
allowscriptaccess="always"  
allowfullscreen="true" 
width="425" height="344">
</object> 

El problema de insertar el vídeo mediante ese código es que la página no será XHTML válida. El vídeo se debe insertar con el código que incluyo a continuación, de esta manera el resultado es el mismo pero la página es válida, gramaticalmente correcta.

<object type="application/x-shockwave-flash"
data="http://www.youtube.com/elvideo"
width="425" height="350">
<param name="movie"
value="http://www.youtube.com/elvideo" />
<param name="autostart" value="true" />
<param name="wmode" value="transparent" />
</object>

Recordemos que crear documentos que "estén validados por las gramáticas formales publicadas" (Punto de verificación 3.2 de las WCAG 1.0) es un requisito imprescindible para alcanzar el nivel de adecuación Doble-A.

Nota: es importante mantener los párametros WIDTH y HEIGHT, si sólo se incluye uno de los dos, en Firefox el vídeo no se ve.

Subtítulos

Otro requisito imprescindible para alcanzar el nivel de adecuación Doble-A es proporcionar subtítulos que describan todo el audio presente (Punto de verificación 1.4 de las WCAG 1.0).

Gracias a los subtítulos aquellos usuarios que no puedan oír el audio podrán leerlo:

• Usuarios con problemas de audición.
• Usuarios en ambientes ruidosos.
• Usuarios con dispositivos sin tarjeta de sonido.
• Usuarios con el audio desactivado (por ejemplo si no quieren que se entere toda la oficina de lo que están viendo [sonrisa])
• etc.

Hay que tener en cuenta que otra ventaja de añadir subtítulos es que ahora que YouTube los va a traducir automáticamente, nuestros vídeos tendrán una audiencia significativamente mayor.

YouTube ya dispone de subtitulado automático en algunos canales y pronto estará disponible para todos los vídeos, aunque no podemos esperar que sea 100% fiable.

YouTube también permite incluir manualmente subtítulos en los vídeos. Como se ve en la siguiente imagen, en el apartado "Títulos y subtítulos" puedes subir uno o varios (en diferentes idiomas) ficheros de subtítulos:

 

Se han de subir ficheros ".srt" o ".sub".

Estos ficheros se pueden crear de forma muy sencilla con la herramienta online CaptionsTube, que te permite seleccionar el vídeo de YouTube, crear y editar los subtítulos y después descargarlos.

 

YouTube proporciona también desde hace poco tiempo la opción de subir un fichero con la transcripción completa del audio. De forma automática, por reconomiento de voz, incluirá cada subtítulo donde le corresponde. Está todavía en beta y sólo disponible en inglés (y tampoco podemos esperar que sea 100% fiable).

La transcripción se sube desde la misma pantalla de "Títulos y subtítulos" que veíamos antes, seleccionando la opción "Archivo de transcripción (sólo en inglés) beta" como se explica en este vídeo:

[Insertado con el código modificado]

[Insertado con el código habitual]

Transcripción completa

Por último, otro requisito que hay que cumplir para alcanzar el nivel de adecuación Doble-A es incluir una transcripción que transmita de forma completa toda la información: información de los personajes, trascripción completa, acciones, lenguaje corporal, contexto y cambios de escena, etc. (Punto de verificación 1.4 de las WCAG 1.0)

Gracias a la transcripción:

• Los usuarios con problemas de visión podrán acceder a una descripción de lo que se ve en el vídeo.
• Los usuarios que no puedan visualizar el vídeo, por el dispositivo que utilizan o su configuración, podrán acceder a su contenido.
• Los motores de búsqueda indexaran el contenido del vídeo y se podrán realizar búsquedas en él.
• Facilita el acceso al contenido a las personas que no hablan el idioma del vídeo.
• etc.

La transcripción puedes hacerla tú mismo, pagar para que te la hagan o realizarla mediante software de reconocimiento de voz.

La opción más práctica y que asegura un resultado de mayor calidad es sin duda contratar a una empresa especializada que haga la transcripicón, puesto que los precios son suficientemente razonables (se puede encontrar por 60 euros la hora de audio). Hay empresas que te hacen los subtítulos, la transcripción y las traducciones a los idiomas que desees con descuentos interesantes.

La forma de incluir la transcripción puede ser mediante un enlace que lleve a un fichero de texto o HTML donde se incluya la transcripción, incluirlo directamente en la página o recurrir a otras prácticas llamativas como la que vemos en The New York Times o en su versión en rtve.es [visto en Sortega]

Sin entrar en la accesibilidad de este visor implementado en Flash, sí que es interesante ver como muestran la transcripción al lado del vídeo, la posibilidad de buscar palabras clave, el índice de temas y duración, o en la versión original la línea de tiempo.

Controles accesibles por teclado

Leer el artículo Keyboard Accessible YouTube Controls

Reseña: "Accesibilidad a los contenidos audiovisuales en la web"

Título: Accesibilidad a los contenidos audiovisuales en la web. Una panorámica sobre legislación, tecnologías y estándares (WCAG 1.0 y WCAG 2.0).

Autores: Lourdes Moreno, Belén Ruiz, Paloma Martínez, Juan Manuel Carrero y Juan Ramón Martínez.

Fecha: noviembre de 2008 (primera edición)

Nº páginas: 102

Editado por: Real Patronato sobre Discapacidad

Descarga gratuita: "Accesibilidad a los contenidos audiovisuales en la web" en formato PDF (3MB)

Es uno de esos libros imprescindibles que recomiendo tener a mano. Resulta de especial utilidad las checklist de comprobación de un contenido audiovisual así como la "Tabla Resumen (WCAG 1.0/WCAG 2.0) de la accesibilidad a los contenidos audiovisuales en la web" (acceso al libro en ventana nueva, PDF de 3MB)

El libro se estructura en tres partes:

Parte 1. Introducción

Este apartado es una introducción a los conceptos básicos relacionados con la accesibilidad. Se incluye un resumen de la legislación vigente en España y una aproximación a las metodologías y certificaciones de accesibilidad.

No resumiré este apartado porque dicha información se encuentra mucho más desarrollada en diversos artículos de este blog [1]

En cualquier caso es una gran introducción a la accesibilidad web donde se recoge de manera muy clara y completa los conceptos y la información básica sobre el tema.

Parte 2. La cadena de accesibilidad de los contenidos audiovisuales en la web

Para proveer de accesibilidad a los contenidos multimedia audiovisuales hay distintos componentes de desarrollo web e interacción que deben trabajar conjuntamente para conseguirlo, es lo que denominan "cadena de accesibilidad de los contenidos audiovisuales en la Web", cadena que consta de los siguientes eslabones:

• Contenido en sí: el contenido en sí mismo debe ser accesible, lo que significa proveer de alternativas sincronizadas como el subtitulado, la audiodescripción o la transcripción, entre otros, que cumplan con lo establecido en las WCAG.
• Cómo llegar al contenido: el acceso al contenido debe ser accesible, puesto que según cómo se implemente este acceso puede provocar barreras de accesibilidad.
• Visualización del contenido: hay que ofrecer alternativas atendiendo a las preferencias del usuario, y la interacción para acceder al contenido debe ser usable. El acceso al contenido ha de ser, además de posible, intuitivo en la interacción, por lo que hay que ofrecer usabilidad, aportando accesibilidad en cómo mostrar al usuario la información de acceso y control.

Primer eslabón: el contenido ha de ser accesible

En este apartado se citan las pautas de las WCAG 1.0 y de las WCAG 2.0 relacionadas con la accesibilidad de los contenidos audiovisuales, su correspondencia, y las técnicas de las WCAG 2.0 y SMIL asociadas.

• Consultar la "Tabla resumen 2: Correspondencia de las pautas WCAG 1.0 con las WCAG 2.0 en relación a los contenidos multimedia" (acceso al libro en ventana nueva, PDF de 3MB )
• Consultar la "Tabla resumen 3: Técnicas del WCAG 2.0 y SMIL para la pauta 1.2" (acceso al libro en ventana nueva, PDF de 3MB )
• Consultar la "Tabla Resumen (WCAG 1.0/WCAG 2.0) de la accesibilidad a los contenidos audiovisuales en la web" (acceso al libro en ventana nueva, PDF de 3MB )

A continuación tratan el tema de las herramientas de autor, entre las que hay que distinguir:

• Lenguajes y formatos para sincronizar: QuickTime, SMIL, SAMI, Timed Text.
• Reproductores: Real Media, QuickTime, Windows Media.
• Editores de subtitulado y/o audiodescripción para contenidos audiovisuales: MAGpie, Hi-Caption Studio, Captionmenow.
• Reproductores para contenidos multimedia realizados con Flash accesible de Adobe.

Se incluye un "Anexo: Listado de herramientas" (acceso al libro en ventana nueva, PDF de 3MB donde se realiza una breve descripción de estas y otras herramientas.

El apartado dedicado al primer eslabón termina con una serie de buenas prácticas:

Buenas prácticas de subtitulado

El documento de referencia son las "Buenas prácticas de subtitulado" del CESyA, basadas en la "Norma UNE 153.010 Subtitulado para personas sordas y personas con discapacidad auditiva. Subtitulado a través del teletexto."

También destacan las "Best practices in online captioning" de Joe Clark.

En el libro se hace un pequeño resumen donde se tratan temas como el color de los subtítulos, la localización en pantalla, la alineación, el número de líneas, la velocidad, consejos ortográficos y gramaticales, etc.

Buenas prácticas de audiodescripción

El documento de referencia son las "Buenas prácticas de audiodescripción" del CESyA, basadas en la "Norma UNE 153.020 Audiodescripción para personas con discapacidad visual. Requisitos para la audiodescripción y elaboración de audioguías".

La audiodescripción permite compensar la falta de percepción de imágenes con descripciones sonoras complementarias (sobre situación espacial, vestuario, gestos, actitudes, paisajes, etc.)

Si no has oído nunca una audiodescripción, puedes consultar el siguiente ejemplo: "Nicolás" (serie de dibujos animados), ejemplo de contenido multimedia accesible disponible en el portal del CESyA.

En dicho portal puedes consultar otros contenidos multimedia accesibles.

En este apartado del libro repasan los seis requisitos necesarios para audiodescribir.

Buenas prácticas para la lengua de signos española

El documento de referencia es la "Norma UNE 139804:2007. Requisitos para el uso de la Lengua de Signos Española en redes informáticas".

En este apartado se trata la presentación del vídeo (tamaño, calidad, tipo de ventana) así como aspectos relativos al propio vídeo (encuadre, apariencia del signante, etc.)

Segundo eslabón: el acceso al contenido multimedia debe ser accesible

Se repasan las distintas formas de ofrecer un contenido multimedia audiovisual en la Web:

• Mediante descarga directa.
  

  Es la opción más accesible siempre y cuando se proporcionen todos los elementos necesarios en la descarga (por ejemplo los subtítulos y la audiodescripción si no vienen integrados en el vídeo) y siempre y cuando se elabore adecuadamente el enlace que activa la descarga y su etiquetado.

  A pesar de ser la opción más accesible no es la más utilizada, pues es más usable, más sencillo para el usuario, que la difusión del contenido se haga a través de un reproductor, integrándolo en la propia página.

• Emisión en descarga progresiva (falso streaming) y streaming [2]
  

  En ambos casos se puede implementar mediante la activación de un enlace o integrándolo mediante el elemento OBJECT.

  En el primer caso habrá que etiquetar adecuadamente el enlace.

  
  

  En el segundo caso se nos presenta el problema de que usando OBJECT la página no puede ser validada de acuerdo al estándar XHTML, puesto que es necesario utilizarlo junto con EMBED.

  Para solucionar el problema se cita el célebre artículo de Elizabeth Castro "Bye Bye Embed".

  Destacan como reproductor CC Player, que es gratuito, accesible desde teclado, compatible con lectores de pantalla, permite asociar audiodescripciones y varios ficheros de subtitulado con idiomas distintos o distintas versiones.

  También hacen especial mención del estándar del W3C Synchronized Multimedia Integration Language (SMIL)

  En relación con SMIL es necesario destacar el artículo "Subtitulado y Audiodescripción en Páginas Web Accesibles" de Lourdes Moreno, Ana Mª Iglesias, Juan Manuel Carrero y Paloma Martínez, en el cual se expone el caso práctico de un vídeo con audiodescripción y subtitulado abiertos [3], implementado con SMIL según las recomendaciones del W3C.

  Hay que puntualizar que la opción XHTML+SMIL sólo es compatible hoy en día con Explorer.

  Para profundizar en SMIL te recomiendo "SMIL. Un leguaje para la multimedia en Internet" de A.L.Delgado y "Guía Breve de Subtitulado y Sincronización de Vídeos con SMIL" de INTECO (incluye ejemplos).

Tercer eslabón: ofrecer alternativas atendiendo a preferencias del usuario y la interacción del usuario al acceder al contenido debe ser usable

El acceso al vídeo debe ser, además de posible, intuitivo en la interacción, para lo cual habrá que realizar un diseño centrado en el usuario, utilizar un lenguaje claro y sencillo y los usuarios deberán tener acceso a la reproducción del vídeo de acuerdo a sus características y preferencias.

El tipo de información que se ha de mostrar dependerá de la modalidad elegida al servir el contenido, tal y como se ve en la "Tabla 4: Información a presentar al usuario" (acceso al libro en ventana nueva, PDF de 3MB).

Parte 3. Listado de puntos de verificación de la accesibilidad a los contenidos audiovisuales en la web

Este apartado es un recurso imprescindible para cualquier evaluador o desarrollador a la hora de revisar la accesibilidad de los contenidos audiovisuales incluidos en una web.

Se ofrece una serie de checklists diferentes para evaluar los contenidos en función de si la validación se realiza teniendo en cuenta las WCAG 1.0, la Norma UNE 139803:2004 o las WCAG 2.0 (recomendable, puesto que las WCAG 1.0 están obsoletas respecto a la tecnología actual, no olvidemos que datan de 1999); y si el contenido audiovisual se proporciona mediante streaming, descarga progresiva (falso streaming) o descarga directa.

Checklist de comprobación de un contenido audiovisual (acceso al libro en ventana nueva, PDF de 3MB).

Otras referencias de interés

• "Multimedia Accessibility FAQ" del W3C
• Poster: "La cadena de accesibilidad en los contenidos audiovisuales en Web"
• "Accesibilidad a los medios audiovisuales para personas con discapacidad AMADIS ‘07" (PDF, 3MB)
• "La accesibilidad universal en los medios audiovisuales de comunicación", de Francisco Bariffi, Mª del Carmen Barranco, Lourdes Moreno, Agustina Palacios, Francisco Utray y José Vida (PDF, 2.30MB)
• "Accesibilidad a los medios audiovisuales para personas con discapacidad AMADIS´ 06" (PDF, 5.62MB)
• "El contenido audiovisual: otro reto para la accesibilidad web", Ramón Voces Merayo.
• "Comprobación de la Accesibilidad: Multimedia", INTECO (PDF, 356 KB)
• "Guía Breve de Subtitulado y Sincronización de Vídeos con SMIL", INTECO (incluye ejemplos)
• SMIL Techniques for WCAG 2.0

Notas

[1] Consultar por ejemplo:

• "Referencia sobre legislación española relacionada con la accesibilidad web"
• "Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España"
• "Diferencias de prioridad entre los requisitos UNE 139803:2004 y los puntos de control de las WCAG 1.0"
• WCAG 2.0
• Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0
• Seminario "Introducción a la eAccesibilidad"
• Accesibilidad web y discapacidad auditiva

[2]

Emisión de descarga progresiva (falso streaming): el contenido se va descargando en el equipo del usuario y cuando alcanza un porcentaje determinado de descarga se empieza a reproducir.

Streaming: es una descarga del contenido bajo demanda. El usuario puede manejar completamente los controles de reproducción desde un principio y no es necesario almacenar el vídeo en el equipo del usuario.

[3]

Existen varios tipos de subtítulos. De manera ideal siempre deberían incluirse aquellos denominados closed, cuya característica principal es que se pueden activar y desactivar. En su defecto, se deben incluir subtítulos del tipo open que están pregrabados con el vídeo o el audio y que se muestran siempre al reproducir el recurso.

Artículos relacionados

• Tabla resumen de los requisitos de accesibilidad para los medios tempodependientes según las WCAG 2.0
• Reseña: "Cómo escribir para la Web" de Guillermo Franco
• Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales. Documento del W3C y checklist.

Tu web en la televisión (1 de 3)

Este artículo tiene tres páginas: estás en la Página 1 (Introducción y TDT).

• Ir a la Página 2 (Televisión como dispositivo de salida)
• Ir a la Página 3 (WebTV y Conclusiones y recomendaciones finales)

Existen diversas posibilidades de que un usuario acabe viendo tu web en una televisión, posibilidades que desde mi punto de vista se pueden dividir en dos tipos:

• TDT interactiva, (página 1)
• Televisión como dispositivo de salida de:
  • Un ordenador personal o portátil (página 2)
  • Media Center: Windows Media Center, LinuxMCE, XBMC (Xbox Media Center), Apple TV, etc. (página 2)
  • Una consola: Nintendo Wii, PlayStation, etc. (página 2)
  • WebTV (página 3)

Este artículo comenta todas estas posibilidades, con mayor profundidad en unos casos que en otros porque hay temas que se merecen artículos independientes.

He estado muchos días documentándome y mis objetivos han ido variando a medida que este monstruo crecía.

Finalmente, el objetivo último ha sido, además de sintetizar esta información de la manera más sencilla posible, concluir una serie de recomendaciones de accesibilidad que sirvan para todas ellas (página 3), puesto que al final todas comparten características comunes: dispositivo de salida la televisión, interacción mediante mando a distancia, etc.

1. TDT interactiva

1.1 Qué es

La Televisión Digital Terrestre (TDT) es una nueva tecnología para difundir señales de televisión, también por el aire como la analógica, que la sustituirá por completo en 2010 (el llamado apagón analógico del 3 de abril de 2010).

En marzo de 2007 la TDT tenía una penetración de mercado del 17,6% y en noviembre de 2006 una cobertura nacional del 80,45 % (Impulsa TDT).

De forma resumida, su funcionamiento es el siguiente:

[...] el sonido y las imágenes de los radiodifusores se digitalizan y convierten en bits de información que posteriormente se transmiten a través del aire desde los centros emisores. Esta señal se recibe desde las antenas de nuestras viviendas para finalmente ser convertida de nuevo en sonido e imágenes por los sintonizadores TDT (descodificadores o televisores integrados) que debemos instalar en nuestras casas.

[En Impulsa TDT]

La digitalización de la señal y el aprovechamiento del ancho de banda permite (además de una mejor calidad de la imagen y el sonido, la emisión en Dolby o en formato cine 16:9) que las televisiones puedan ofrecer nuevas funcionalidades de interactividad a través del mando a distancia del receptor:

• EPG (Guía electrónica de programación)
• Teletexto digital
• Servicios interactivos: juegos, chats, votaciones
• Subtitulado digital
• Etc.

Hay distintos tipos de decodificadores (también llamados sintonizador digital de TDT, descodificador o decodificador TDT, STB (Set Top-Box) o “zapper” para los no interactivos) de la señal digital, cuyo uso no deja de ser una fase intermedia hasta que todas las televisiones lleven el chip descodificador integrado.

Para poder acceder a la interactividad es necesario tener un decodificador de gama alta, con el estándar europeo MHP (Multimedia Home Platform), con conexión al canal de retorno (los más comunes son Ethernet, RTC o ADSL) para enviar datos. También los hay con disco duro y con soporte para lector de Smart Cards.

Los equipos con MHP incluyen un pequeño ordenador programable con aplicaciones que se descargan on-line y que en próximas versiones incluirán persistencia. Los que incluyen lector de tarjeta chip podrán permitir servicios interactivos con el DNI electrónico. Para ello es muy importante conectar el canal de retorno a la línea telefónica, lo que rara vez se lleva a cabo.

[En "Todo es electrónico"]

1.2 Desarrollos TDT interactivos

Los servicios MHP se irán implantando progresivamente, según vaya progresando adecuadamente la implantación de la Televisión Digital Terrestre. Esto significa que seguramente comenzarán a ofrecerse después del "apagón analógico", el 3 de abril de 2010. Todo dependerá de la rapidez de implantación de la TDT.

[En "Pixels y Chips"]

En la actualidad, los servicios interactivos que se ofrecen por TDT son desarrollos específicos. Hoy por hoy en España, y que yo sepa, no se puede acceder a la web desde la TDT.

Desde el año pasado cada vez son más los desarrollos que se hacen para TDT.

La Agencia Tributaria ha comenzado este año a prestar ciertos servicios relacionados con la Campaña de la Renta a través de la Televisión Digital Terrestre (TDT) interactiva, como la solicitud a través de este nuevo canal del borrador de la declaración de la Renta tecleando el número de identificación fiscal (NIF) y la cantidad que aparece en la casilla 681 de la declaración del año pasado.

En noviembre de 2006 se celebró en Zaragoza el primer foro sobre Aplicaciones Interactivas en Televisión, en el cual participó el alcalde de Alcazar de San Juan (Ciudad Real), ciudad que a mediados de 2006 se convirtió en el primer municipio de España y el sur de Europa en disponer de servicios interactivos (1):

Entre ellos, destaca la posibilidad de realizar gestiones municipales, reserva de cita para el médico o consulta de servicios del ayuntamiento, y de la Junta de Comunidades de Castilla-La Mancha, banca electrónica (Caja Castilla-La Mancha), televenta o servicios sociales básicos o especializados.

[En Hispavista]

Las entidades bancarias también comienzan a ofrecer servicios financieros por TDT, por ejemplo Caja Navarra a partir de junio de este año:

[…] podrán conocer la posición de sus cuentas, consultar sus saldos y los últimos movimientos, informarse sobre los productos y servicios de Caja Navarra y bucear entre los centenares de proyectos sociales que las asociaciones sin ánimo de lucro han puesto a disposición de los clientes para ser elegidos.

[…] Para interactuar con la entidad bancaria será necesaria el alta en la banca on line o Clavenet y un decodificador de TDT con el sistema @mhp, que incorpora la tecnología necesaria para que la relación entre Caja Navarra y sus clientes sea, ahora también, televisiva.

[En "El mundo financiero"]

La Diputación de Huesca, desde octubre de 2006, también ofrece la “T-Administración”, que permite a los ciudadanos realizar sus gestiones a través de la televisión digital.

Se trata de la primera aplicación nacional de gestión con la administración pública a través de la plataforma interactiva de Televisión Digital Terrestre. Cualquier usuario que disponga de un decodificador sobre el estándar MHP (Multimedia Home Platform) podrá acceder a todo el contenido del portal de la Diputación a través del mando a distancia del televisor, consultar información e incluso acceder a servicios interactivos y realizar trámites a través de la TV. […]

La navegación por la página es sumamente sencilla e intuitiva. En la parte superior izquierda aparece el menú con las secciones principales (La Diputación, La provincia, Servicios y Trámites) y que estará siempre accesible con el objetivo de facilitar la navegación a los telespectadores. En la parte inferior se reflejan los botones de colores que se asignan a cada acción: salida de la aplicación, ayuda, navegación a determinada sección y vuelta al inicio de la página.

[En Diputación de Huesca]

1.3 DVB-HTML

Como comentaba, hoy por hoy en España no se puede acceder a la web desde la TDT, es decir, no puedes poner, por ejemplo, http://www.google.com y acceder al buscador, sino que son siempre desarrollos específicos.

El estándar MHP (Multimedia Home Plataform) ha abierto la vía para que los proveedores de servicio puedan proporcionar aplicaciones de TV interactivas que los usuarios descargan y ejecutan en el receptor de TV digital, independientemente de su tecnología y de la red de difusión.

Las especificaciones MHP definen la arquitectura del receptor, los protocolos de transporte y señalización para los canales de difusión e interacción, y los tipos de aplicaciones que pueden ser distribuidas.

MHP 1.1 specifies the Internet Access profile, in which applications can control the basic operations of Open Internet resident clients (Web broswer, e-mail and news client).

To add, and indeed complement the DVB-J application format, MHP 1.1 defined a new optional application type: DVB-HTML

The figure below outlines the basic architecture of MHP 1.1 and the relationship between the DVB-HTML optional application type and the DVB-J application type.

[En mhp.org]

Un terminal MHP va a aceptar determinado tipo de aplicaciones en determinados lenguajes (DVB-J y DVB-HTML) y va incluir una API o conjunto de funciones que las aplicaciones pueden utilizar.

Estas aplicaciones son:

• DVB-J (Xlet), son aplicaciones programadas en Java (se compilan), que pueden ser descargadas, lanzadas, interrumpidas y destruidas por el usuario desde su receptor de televisión. MHP permite que puedan coexistir múltiples aplicaciones en el receptor.
• DVB-HTML (Digital Video Broadcast HyperText Markup Language) es un lenguaje declarativo que se interpreta y está basado en estándares de Internet. Se trata de páginas en formato XHTML que son presentadas por el receptor de TV al estilo de lo que realiza un navegador de Internet.

[…] is a standard for allowing digital televisions to access internet content. It is an optional part of the larger MHP1.1 standard of DVB.

The specification is based around a modularized version of XHTML 1.1, and also includes Cascading Style Sheets (CSS) 2.0, Document Object Model (DOM) 2.0, and ECMAScript (also known as JavaScript).

[En Wikipedia]

La extensión de estos documentos es .html y su cabecera:

<!DOCTYPE html PUBLIC "-//DVB//DTD XHTML DVB-HTML 1.0//EN" "http://www.dvb.org/mhp/dtd/dvbhtml-1-0.dtd">

En 2002, Nionex lanzó el primer navegador DVB-HTML del mundo para MHP (Multimedia Home Platform): Pontegra.

El proyecto STB-DVB-MHP (2004) de la Universidad de Vigo trabaja también en un navegador web para TDT, entre cuyos objetivos están los siguientes:

• Gestión de formularios.
• Ejecución de applets y JavaScript.
• Permitir la integración de plug-ins.
• Servir de aplicación soporte a documentos DVB-HTML.
• Cumplir la norma MHP 1.1 en los puntos que afectan a los clientes de acceso a Internet.

Podemos hablar también de Ortikon Ace Browser:

ORTIKON ACE® Browser is a compact MHP-based DVB-HTML browser application (total size, zipped ~260 kB), and it runs on any STB supporting MHP-version 1.0.2 or later.

Ortikon ACE Publisher es la herramienta de creación de contenidos y Ortikon ACE Browser Emulator el emulador para PC:

ORTIKON ACE Browser Emulator is a PC application for quick, easy and efficient content production. It can be used for previewing purposes in the PC content authoring environment simultaneously with designing. The tool is a WYSIWYG application. So the DTV display screen will be exactly the same as that of the designer's PC. The content will be transferable directly from PC to DTV. With the virtual remote controller the designer tests the technical functioning and usability of the content.

[Ortokon Interactive Ltd]

En digitv.ortikon.com puedes ver páginas de ejemplo teniendo en cuenta que:

These pages are optimized for ORTIKON ACE® DVB-HTML Browser. Because DVB-HTML is the format for digital-TV they use some features not used in PC world (such as MPEG2 I-frame backgrounds), and thus the layout does not look as they were originally designed on PC. By watching these pages with PC browsers you anyhow get the idea what features our current DVB-HTML Browser support.

Opera también soporta DVB-HTML, anunciando en 2006 que:

Opera Software today announces that Telsey Telecommunications, a leading manufacturer of IP set-top boxes, has selected the Opera browser once again to provide full-featured Internet browsing on the company's WAVES set-top boxes.

[En opera.com]

Puedes ampliar información sobre DVB-HTML en las direcciones que incluyo en el apartado de referencias.

1.4 Consideraciones de usabilidad y accesibilidad

Me hace gracia este comentario:

[...] la potencialidad del TDT como medio para navegar por Internet se ve recortada por el hecho de que muchos contenidos no están adaptados para los televisores, por lo que no se visualizan correctamente.

[En noticiasdot.com]

... vaya, eso me suena en contextos más habituales y cotidianos...

Como todavía no se puede acceder a la web desde la TDT, no vamos a poder validar nuestra páginas en este entorno, lo mejor que podemos hacer es como siempre acatar los estándares y cumplir con las Pautas de Accesibilidad de la WAI, y te aconsejo que seguir mis conclusiones y recomendaciones finales.

Si te hayas involucrado en uno de los desarrollos específicos para TDT interactiva, evidentemente sí que podrás y deberás validar la usabilidad y accesibilidad del servicio. Pero esto ya sería motivo de un artículo diferente. Os dejo aquí unos pantallazas del portal de la Diputación de Huesca para TDT, que a mi parecer reflejan un buen hacer en este sentido.

  

[En León Ciudad Digital]

Referencias

"Infraestructuras para servicios multimedia" de Telefónica

Amplia descripción de todas las tecnologías implicadas en el desarrollo de las comunicaciones multimedia. Muy recomendable.

"Tecnologías y actividades de estandarización para la interconexión de Home Networks" de Fundación AUNA

Descripción de tecnologías para middleware, software y pasarelas residenciales.

Impulsa TDT

Portal de la Asociación para la Implantación y el Desarrollo de la Televisión Digital Terrestre en España.

Sintonizador Digital TDT

Guía fácil divulgativa sobre la TDT.

mhp.org

MHP: especificaciones, foros, noticias, países donde se está adoptado, etc.

"MHP" en Televisión Digital

Descripción del estándar MHP.

Sistema de Recepción Digital Multimedia

Portal del Proyecto STB-DVB-MHP del Departamento de Ingeniería Telemática de la Universidad de Vigo.

Documentación de Sistemas de Imagen del GPI-RV de la Universidad de Vigo

Artículos sobre DVB, MHP, TDT, etc.

"Decodificadores TDT con MHP y lector de tarjeta chip" de Todo es electrónico

Artículo de marzo de 2007 sobre los distintos decodificadores. Incluye lista de modelos de TDT con MHP y tarjeta chip.

"DVB-HTML" de Pablo Cesar

Breve presentación de DVB-HTML en diapositivas.

DVB-HTML Applications

Buena introducción a DVB-HTML que incluye mención a los "triggers".

"DVB-HTML an optional declarative language within MHP 1.1" de Philippe Perrot

Buena introducción a DVB-HTML.

"Guidelines for creating DVB-HTML Content" de Ortikon

Extenso manual de DVB-HTML ejemplificado con las páginas de ejemplo de digitv.ortikon.coma

"Companies working with MHP" en Interactive TV Web

Listado de herramientas de autor, aplicaciones, decodificadores, servicios, etc.

NOTAS

(1) Aunque es curiosa la opinión de los vecinos sobre el tema.

Este artículo tiene tres páginas: estás en la Página 1 (Introducción y TDT).

• Ir a la Página 2 (Televisión como dispositivo de salida)
• Ir a la Página 3 (WebTV y Conclusiones y recomendaciones finales)>