7.4.2.2. Accesibilidad de la interfaz del estudiante

Lo siguiente a valorar es la accesibilidad de la plataforma para los estudiantes, una vez puesta en funcionamiento y con contenidos reales. En algunos casos, esto puede ser lo más difícil y costoso. Para realizarlo correctamente debemos tener a acceso, con un identificador y contraseña de una cuenta de estudiante inscrito en un curso, en algún sitio web de demostración o, mejor aun, en otra instalación ya existente de la misma plataforma.

Hay que valorar que normalmente la plataforma viene con varias plantillas o temas que pueden aplicarse para presentar gráficamente las herramientas y contenidos y que unos pueden ser más accesibles que otros.

Se trata por tanto de revisar la accesibilidad del sitio web que genera la plataforma desde el punto de vista del estudiante.  En este tema debemos remitir al lector para documentarse a otras fuentes como Sidar (2006b), ya que la extensión necesaria para presentarlo correctamente excede con mucho del espacio disponible en este informe.

Además de los aspectos habituales en este tipo de revisión, como por ejemplo la existencia de texto alternativo para todos los elementos gráficos, la validez formal del código (X)HTML o la correcta navegación mediante el uso del teclado, indicamos a continuación y de manera sucinta algunos aspectos a los que conviene prestar especial atención dada la particularidad de este tipo de sitios web, comprobando que cumplen los correspondientes puntos de verificación de las directrices WCAG.

En general, una plataforma educativa es un sitio con un alto grado de interactividad y deberemos garantizar que todos los usuarios puedan, no sólo navegar y acceder a los contenidos, sino también interactuar con los distintos módulos y funcionalidades existentes. En concreto:

• Formularios donde se identifican los usuarios para acceder al sitio.
• Formularios que se generan para la realización de exámenes y pruebas de autoevaluación
• Formularios usados por los estudiantes para subir sus propios contenidos a la plataforma.
• Módulos para la comunicación: sistemas de mensajería, aplicaciones de chat y mensajería instantánea, módulo de videoconferencias y similares.

Otros aspectos a prestar especial atención son:

• ¿Funciona correctamente el sitio web al desactivar Javascript y el soporte de conectores (en inglés plugin), particularmente Flash?
• ¿Las listas y tablas generadas automáticamente están correctamente marcadas en HTML para garantizar su accesibilidad?
• ¿Existen atajos de teclado para ir a las secciones más relevantes del entorno de usuario?
• ¿Se posicionan los distintos contenidos y módulos en pantalla mediante hojas de estilo CSS o se usan tablas? Esta última práctica está desaconsejada por las Directrices WCAG.

Por otro lado, en muchos casos, la institución opta por desarrollar sus propias plantillas para presentar los contenidos de una manera más acorde a su imagen institucional. O también desarrolla sus propios componentes complementarios de los existentes en la versión suministrada. Por ejemplo, en la plataforma .LRN la institución debe realizar un importante esfuerzo de programación para integrar la plataforma básica en su versión pública final. En este caso gran parte de la responsabilidad sobre la accesibilidad final del producto recae sobre los desarrolladores de la institución implicada y debemos asegurarnos de que se dispone de la adecuada formación y recursos para esta difícil tarea.

7.4.2.3. Accesibilidad de la interfaz de administración

No debemos olvidar revisar también la accesibilidad del sitio web que genera la plataforma desde el punto de vista del profesor o tutor que tiene que subir los contenidos a la plataforma y realizar posteriormente el seguimiento de los alumnos implicados. 

Para poder evaluar este aspecto deberemos acceder a la plataforma con una cuenta de profesor y realizar las comprobaciones oportunas. Casi todos los puntos propuestos en la sección anterior son de aplicación también aquí.

Un aspecto a mirar con particular detalle es el soporte de accesibilidad de las herramientas disponibles para generar los contenidos. Prácticamente todas las plataformas llevan integrada una herramienta para generar contenidos HTML, de manera amigable con un interfaz similar a un editor de texto, que luego se integran con el resto de contenidos del curso. Pues bien, es fundamental que esta herramienta genere código accesible y promueva las buenas prácticas en los profesores que van a generar estos contenidos. Por ejemplo, el editor de HTML debe solicitar un texto alternativo cada vez que se introduzca una imagen y avisar de la ausencia del mismo en su caso. Otro ejemplo es el uso de encabezados, que deben marcarse correctamente según la especificación HTML (H1, H2, H3…) y no sólo de manera gráfica. Como último ejemplo, si hay una utilidad para incluir tablas de datos, debe facilitarse la identificación de las celdas que serán cabeceras de filas o columnas.

En realidad, en su función de herramienta para la generación de contenido la plataforma deberá cumplir con las Directrices de Accesibilidad para las Herramientas de Autor (W3C, 2000) ya presentadas anteriormente.

Por otro lado, como también se ha comentado antes, es muy importante formar a los profesores que van a introducir los contenidos en la plataforma para que lo hagan de manera que se favorezca la accesibilidad. Además de utilizar adecuadamente el editor de contenidos HTML, los profesores deben aprender como preparar los documentos de presentación de contenidos que se ofrecen para descargar en formatos como Word, PDF, PowerPoint, o similares de manera accesible. Un recurso interesante en este sentido es Illinois (2006), una aplicación que permite generar contenidos HTML accesibles a partir de documentos Word y PowerPoint.

7.4.2.4. Accesibilidad de los componentes de terceros

Un aspecto a valorar especialmente en las plataformas de código abierto es la accesibilidad de los componentes desarrollados por terceros. Al estar el trabajo de desarrollo distribuido entre distintos grupos es posible que los estándares de accesibilidad sean satisfactorios en los componentes centrales de la plataforma, pero no en los componentes desarrollados por terceros.

Por ello una vez elegida la plataforma principal, si se van a instalar otros componentes desarrollados por terceros, es fundamental que dichos componentes también sean accesibles. Es más probable que esto sea así si el grupo central de desarrolladores impulsor de la plataforma hace hincapié en el soporte de la accesibilidad en las guías y documentación publicada en su sitio web para el desarrollo de estos módulos.

7.4.2.5. Implicación de los usuarios en la evolución de la plataforma

Por último, queremos indicar que si pertenecemos a una institución que ya ha está usando una plataforma educativa, sea un producto externo o de desarrollo propio, también podemos influir para que la plataforma soporte mejor la accesibilidad en el futuro. Las plataformas van evolucionando en sucesivas versiones y las mejoras que se introducen vienen determinadas en parte por las necesidades y expectativas detectadas en los usuarios. Por ello, es muy importante informar a los responsables o desarrolladores de la plataforma de los fallos de accesibilidad que detectemos para que vayan subsanándolos en las versiones siguientes o en la versión actual mediante parches de programación
.
Estas recomendaciones tendrán más fuerza si vienen avaladas por los testimonios de usuarios reales con discapacidad que han encontrado problemas de navegación y utilización de los recursos.  También se puede recurrir a entidades externas con experiencia en la materia para que realicen auditorías de accesibilidad de la plataforma en cuestión.

A la hora de definir las acciones correctoras habrá que distinguir muy bien si los problemas detectados son debidos a la falta de accesibilidad de la plataforma en sí, o de los contenidos educativos incluidos en la misma con posterioridad.