1. La experiencia de proveedor

Es primordial que seleccionemos un proveedor con experiencia demostrable en el desarrollo y certificación de la accesibilidad web; certificación concedida por una tercera entidad independiente (AENOR) que asegure el cumplimiento de las pautas normalizadas sobre accesibilidad web (Norma UNE 139803:2004). Es importante que su propia página web esté certificada.

2. La toma de contacto

Es necesario elaborar un trabajo previo de contacto y determinación de los objetivos del cliente para su página web. El proveedor debe ser capaz de ofrecer para cada tipología de los contenidos (imágenes, textos, audio y vídeo) una solución que facilite la accesibilidad para todos (pautas de accesibilidad web, soluciones en Lengua de Signos Española –LSE-, criterios de usabilidad, transcripciones de audios y vídeos, tratamientos especiales de textos e imágenes, etc.).

• Establecimiento del contacto inicial.
• Análisis previo de la empresa o institución.
• Exposición inicial de necesidades e intenciones.
• Evaluación del caso.
• Elaboración de una propuesta comercial clara y detallada.
• Revisión y acuerdo de la propuesta.

3. La puesta en marcha

El intercambio de información debe ser fluido y continuo. Además, debemos exigir un responsable de proyecto que coordine personalmente, como interlocutor único, todo el proceso para evitar la distorsión o pérdida de información entre el cliente y el proveedor.

• Intercambio de información.
• Designación del responsable del proyecto (persona de contacto) y del equipo de trabajo.

4. El desarrollo

El proveedor debe ser capaz de ofrecer al cliente un diseño web atractivo, orientado a sus objetivos y, además, accesible para todo tipo de usuarios-clientes-públicos. Además, debe poder hacer accesibles los contenidos del sitio.

• Diseño de la imagen de la sede web.
• Aprobación del diseño.
• Verificación del cumplimiento de las pautas de accesibilidad por el diseño gráfico del sitio web.
• Inicio del desarrollo del sitio web.
• Publicación del sitio web en un servidor de pruebas.
• Verificación del cumplimiento de las pautas de accesibilidad por las páginas desarrolladas.
• Preparación y publicación de contenidos.

5. La revisión

El proveedor debe presentar el sitio web en pruebas para que el cliente dé su conformidad al proyecto ya terminado. Esto es esencial para evitar pasos atrás o interrupciones en el proceso. Al mismo tiempo, el proveedor debe realizar un control de calidad de todo el sitio web, prestando especial atención a su accesibilidad.

• Revisión del sitio web por parte del cliente.
• Verificación del cumplimiento de las pautas de accesibilidad por todo el sitio web en su conjunto.

6. La presentación

El proceso de desarrollo no ha terminado hasta que el cliente está totalmente satisfecho con el resultado. Una vez ha aprobado el proyecto, es cuando se puede hacer visible el sitio web.

• Aprobación de la sede web por el cliente.
• Presentación del sitio por el cliente.

7. El mantenimiento

El proveedor debe ofrecer al cliente la posibilidad de realizar actualizaciones de contenidos, revisiones periódicas que aseguren la accesibilidad de las páginas y opciones que aseguren la preservación y difusión del sitio web.

• Actualización.
• Revisión del cumplimiento de las pautas de accesibilidad por los nuevos contenidos incorporados.
• Realización de copias de seguridad e informes estadísticos de tráfico y posicionamiento.

8. Certificación de la accesibilidad web

AENOR es la única entidad independiente en España que certifica que una sede web cumple con las pautas de accesibilidad web establecidas por la Norma UNE 139803:2004. AENOR realiza una serie de auditorías sobre la sede web y su equipo de mantenimiento de contenidos, para comprobar que la estructura, contenidos y procedimientos para el mantenimiento y actualización de los mismos, aseguran la accesibilidad de la web.

Un proveedor que conoce y ha experimentado esta metodología, asegura mayor agilidad en este trámite, lo que supone un ahorro de tiempo y dinero.

En este sentido, el Taller Digital de la Universidad de Alicante ha sido partícipe, en primera instancia, de todo este proceso de actuación.

Ana López Díaz

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.

Existen muchas publicaciones sobre el tema de cómo crear un proyecto web de calidad. A veces, este tipo de proyectos tienen un plan detallado del procedimiento, que, según la opinión de los autores, permite crear una aplicación de alta calidad, ampliable, fácil de mantener y reutilizar. Pero en la realidad no siempre es así; aunque muchas de estas recomendaciones son útiles, otras no tienen ninguna aplicación práctica.

Como norma general, desde el momento de firmar un contrato de desarrollo hasta finalizar el trabajo, un proyecto pasa por las siguientes fases: análisis de requerimientos, proyecto previo, codificación, pruebas de funcionamiento y mantenimiento.

El análisis de requerimientos es la clave principal para todo el trabajo. El objetivo de esta etapa es hacer un modelo general del futuro sistema sin profundizar demasiado en los detalles técnicos de la realización. Lo ideal es que el análisis se transforme de forma natural en un análisis del comportamiento y de la interfaz.

Es muy importante preparar la lista de los requerimientos del proyecto con participación del responsable del grupo de desarrollo, ya que esto permite evitar el efecto del «teléfono roto», es decir, que la información cambie su sentido original tras pasar de un departamento a otro.

Para resolver el problema de una mala interpretación fueron creados los métodos especiales hasta los lenguajes formales, para describir requerimientos de un proyecto informático como, por ejemplo, «Use case diagram». Incluso en una conversación entre personas a veces surgen situaciones, cuando lo que dice uno y lo que oye el otro no es lo mismo. Un método sencillo para asegurarse de que el interlocutor ha entendido bien es pedirle que relate lo que ha oído.

La misma relación inversa debe existir entre el cliente y los desarrolladores. Esto evita el exceso de programación y permite concentrarse en el desarrollo de las funciones realmente necesarias para el cliente, descartando funciones secundarias, que habitualmente hacen gastar mucho tiempo pero luego casi nunca se utilizan.

La idea es recibir del cliente la mayor cantidad posible de información relacionada con su proyecto. Intentar ver el proyecto desde su punto de vista e intentar ponerse en su ámbito de trabajo. Luego es imprescindible recibir el visto bueno del modelo desarrollado y de la interfaz, no tanto en relación a su aspecto visual como a su contenido. Todos estos pasos preparan una buena base para desarrollar un modelo optimizado con una interfaz cómoda para el usuario. El resto lo dejamos para los diseñadores gráficos de la web, que se ocuparán de que el aspecto sea agradable.

Sergiy Bukuyemskyy

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.