Hola, soy Loïc Martínez Normand,
profesor de la Escuela Técnica Superior de Ingenieros Informáticos
de la Universidad Politécnica de Madrid.
En este vídeo os voy a explicar un árbol de decisión que facilita
la aplicación del estándar EN 301 549
a productos y servicios concretos.
Este estándar puede aplicarse
a productos y servicios TIC de cualquier tipo,
pero hay un problema importante:
¿cómo saber cuáles de los 279 requisitos y 11 recomendaciones
se aplican a cada caso concreto?
Cada requisito y recomendación tiene su propia precondición.
Así que, si un producto o servicio TIC cumple la precondición,
entonces, ese requisito se aplicaría.
Pero contestar a 290 preguntas detalladas sobre un producto
es inviable si el producto todavía está en desarrollo
y se desea saber qué requisitos deberá cumplir.
Y es muy poco eficiente si el producto ya existe
y lo que se desea es saber qué requisitos cumple.
Por ello se plantea una estrategia basada en un árbol de decisión.
El objetivo es reducir el número de 290 preguntas.
Para ello, cada pregunta del árbol afecta...
a bloques de varios requisitos.
Y, además, la respuesta a una pregunta
permite saber cuál es la siguiente pregunta.
Con eso, se reduce el número de preguntas necesarias.
Así, habrá que contestar como máximo 37 preguntas para cada caso concreto.
Se pierde algo de efectividad,
ya que el resultado del árbol de decisión
tendrá algunos requisitos que tal vez no se apliquen
si se analizan los detalles del producto.
Aun así, compensa la mejora de eficiencia.
A partir de ahora os voy a contar, poco a poco, el árbol de decisión,
empezando por los requisitos que hay que considerar...
para cualquier producto o servicio TIC.
Hay seis requisitos genéricos
que tienen que considerarse para cualquier producto o servicio.
Por ello, el árbol de decisión no contiene ninguna pregunta para ellos.
Algunos de estos requisitos son:
ofrecer alternativas para biométrica,
preservar la información de accesibilidad
y no obligar al usuario a realizar acciones simultáneas.
La primera pregunta del árbol tiene que ver con funcionalidad cerrada.
Veremos para cada pregunta su identificador, que empieza por "Q",
y que facilitará referencias posteriores,
una lista de requisitos que se aplican
si se responde afirmativamente a la pregunta
y la siguiente pregunta que hay que plantear.
Si el sistema tiene funcionalidad cerrada (pregunta Q1),
se aplican seis requisitos y se plantea la siguiente pregunta
sobre el acceso a información visual (Q2).
Si la respuesta a Q1 es negativa,
entonces no se aplica ningún requisito
del apartado 5.1 del estándar y se plantea la pregunta Q7,
que veremos más adelante.
Si se cumple Q1,
se pregunta si se requiere acceso a información visual (Q2),
con una pregunta adicional...
si el acceso no visual está basado en sonido (Q3),
y que veremos enseguida.
Por otro lado, también hay requisitos específicos
si hay que dar acceso al teclado (Q6).
Si el sistema cerrado proporciona información sonora
para facilitar el acceso no visual (pregunta Q3),
hay cinco requisitos aplicables
sobre la calidad de esa salida sonora,
un requisito más si se muestra información en pantalla (Q4),
y otros ocho requisitos sobre síntesis de voz,
si la salida sonora es de voz (pregunta Q5).
El siguiente bloque de preguntas trata sobre controles interactivos,
llamados elementos accionables en el estándar.
Si el sistema tiene elementos accionables (Q7),
se aplican dos requisitos sobre la forma de accionar esos botones
y la necesidad de que puedan ser detectados sin ser activados.
Y si alguno de esos controles tiene varios estados (Q8),
entonces se aplican requisitos relacionados
con la posibilidad de conocer su estado por varios canales.
El siguiente fragmento de árbol
trata con sistemas que permiten la comunicación por voz.
En ese caso, (pregunta Q9),
se aplican requisitos relacionados con la calidad de la comunicación
y con la obligación de ofrecer comunicación en texto
en tiempo real (RTT).
Para este tipo de comunicación
hay requisitos específicos que veremos enseguida (Q10).
Si el sistema proporciona además comunicación de vídeo (Q13),
entonces deberá cumplir con cinco requisitos,
necesarios para comunicación por lengua de signos
y para lectura labial.
También se incluye un requisito adicional
que depende de una pregunta que veremos en la parte de RTT (Q12).
En cuanto a la comunicación RTT (Q10),
deberá cumplir cuatro requisitos sobre presentación de información,
interoperabilidad y tiempos de respuesta.
Si el sistema puede enviar y recibir RTT (Q11),
tendrá que dar acceso a esa información visualmente
y, si no es cerrado, de forma programática.
Finalmente,
si el sistema proporciona información sobre el hablante (Q12),
entonces deberá informar sobre quién está comunicándose por RTT.
Esta es la primera vez
que se reutiliza la respuesta a la pregunta Q1 de funcionalidad cerrada.
Con ello se reduce el número de preguntas
que se plantean en el árbol.
Esto va a ocurrir varias veces en el árbol,
casi siempre con esta pregunta Q1.
Pasemos ahora a los sistemas con capacidades de vídeo.
Si el sistema TIC
puede reproducir, editar o grabar vídeos (pregunta Q14),
entonces se aplica un primer requisito sobre controles
para activar subtítulos y audiodescripción.
Si, además, el sistema reproduce vídeo con audio sincronizado (Q15),
entonces se aplican cuatro requisitos
relacionados con subtítulos y audiodescripción.
Y si el sistema muestra los subtítulos (Q16),
entonces hay dos requisitos adicionales.
Finalmente, si el sistema TIC transmite,
convierte o graba vídeo (Q17),
tendrá que preservar la información de subtítulos y audiodescripción.
El siguiente bloque de preguntas del árbol
está centrado en el hardware.
Si el sistema TIC es hardware o tiene hardware (pregunta Q18),
entonces se aplican dos requisitos genéricos de accesibilidad hardware.
Luego, hay tres requisitos aplicables
si el hardware permite reproducir voz,
como los altavoces o auriculares (Q19),
y dos más si está diseñado para estar cerca del oído (Q20),
como un teléfono.
Por otro lado, si se trata de un sistema estacionario,
es decir, que está fijado en el suelo o una pared
y no se puede mover (Q21),
habrá una serie de requisitos de accesibilidad
para personas con movilidad reducida, que veremos enseguida.
Y también hay cuatro requisitos específicos
si el sistema tiene elementos accionables de forma mecánica (Q27).
Con respecto a la accesibilidad para movilidad reducida,
hay primero tres requisitos que se aplican
si es un sistema estacionario (Q21),
y, luego, hay varios grupos de requisitos
que dependen de las características físicas del sistema estacionario.
Hay dos requisitos si el sistema no obstruye el acceso (Q22),
y cinco requisitos cuando el sistema tiene alguna obstrucción (Q23).
Y además hay dos requisitos
cuando hay obstáculos para pies o rodillas (Q24),
y dos requisitos adicionales que se aplican
cuando el sistema está diseñado para alcance lateral (Q25),
y presenta obstrucciones pequeñas (Q26).
Con esto terminan los requisitos relacionados con hardware,
y pasamos al siguiente fragmento del árbol de decisión,
que tiene que ver con la web y con documentos digitales.
Si se trata de contenido web (Q28),
entonces se aplican los requisitos equivalentes
al nivel AA de conformidad
de las pautas de accesibilidad web, WCAG 2.1,
organizados alrededor de sus cuatro principios:
perceptible, operable, comprensible y robusto.
Y también se incluyen los requisitos de conformidad de WCAG 2.1.
Algo muy similar ocurre con los documentos no web (pregunta Q29),
pero con algunos cambios en la redacción de los requisitos,
eliminando los requisitos de conformidad,
e incorporando dos recomendaciones adicionales
sobre subtítulos y audiodescripción.
Y así llegamos al fragmento del árbol relacionado con software.
Si el sistema es o tiene software (pregunta Q30),
entonces se aplica un requisito sobre productos de apoyo
y, si tuviera funcionalidad cerrada
es decir, si Q1 es cierto, hay un requisito adicional.
Si es software que proporciona una interfaz de usuario (Q31),
entonces se aplican requisitos
sobre interoperabilidad con productos de apoyo,
así como no alterar las características de accesibilidad
y las preferencias de usuario.
Si, además, se trata de software no web (Q32),
entonces se aplican requisitos derivados de WCAG 2.1.
Estos requisitos se organizan en cuatro grupos:
requisitos de WCAG para software de cualquier tipo,
requisitos para software que sea abierto, cuando Q1 es falso,
requisitos para software cerrado, cuando Q1 es cierto,
y requisitos para software cerrado
que muestra información en pantalla (Q4 es cierto).
Posteriormente se aplicarán o no requisitos
sobre software de plataforma, es decir, sistemas operativos (Q33),
y sobre las herramientas de autor,
que son productos software que permiten crear contenidos (Q34).
Y para terminar el árbol
ya sólo quedan los requisitos sobre documentación y servicios.
Las tres últimas preguntas del árbol definen los requisitos
que se aplican a la documentación del producto (Q35),
a los servicios de atención al cliente (Q36),
y a sistemas TIC que proporcionan servicios de intermediación (Q37).
Con esto hemos visto ya todas las preguntas del árbol de decisión.
Resumiendo, en este vídeo...
hemos visto que hay un problema para saber...
cuáles de los 279 requisitos y las 11 recomendaciones...
del estándar EN 301 549,
se aplican a un producto o servicio concreto.
La estrategia para resolver este problema
es usar un sistema de filtrado de requisitos,
basado en una estructura de árbol de decisión.
Así podremos decidir sobre la aplicación de requisitos
con un número relativamente bajo de preguntas,
que hemos descrito en este vídeo.
Finalmente, es importante no olvidar,
que lo habitual es que un producto o servicio TIC concreto,
tenga que cumplir con un conjunto bastante grande
de requisitos o recomendaciones,
en función de las características que ofrezca a sus usuarios.
Con esto, terminan los tres vídeos...
que he dedicado a mostraros el estándar EN 301 549.
Espero, que os hayan parecido interesantes. Hasta pronto.