El presente documento es la traducción al castellano del documento original (en inglés) titulado «Web Standards Switch».
La única versión normativa es la versión original en inglés, en los términos por ella especificados.
Esta traducción puede contener errores. Puede enviar cualquier comentario sobre esta traducción y los errores que pueda contener a la siguiente dirección de correo electrónico ferguweb@sidar.org.
Gracias.
Fernando Gutiérrez Ferrerías
Introducción· Decidir· Analizar· Organizar· Mejorar· Revisar· Mantener·
QA Página de inicio· Últimas Noticias· QA Recursos· QA IG· QA WG· QA Calendario·
Este artículo ha sido producido como parte del trabajo del Grupo de Trabajo de Aseguramiento de la Calidad del W3C. Por favor, envíe cualquier comentario público sobre el mismo a la lista de correo archivada públicamente public-evangelist@w3.org o para comentarios privados a Karl Dubost karl@w3.org.
El autor reconoce a las personas que han dedicado tiempo para revisar y aportar ideas.
Es bienvenida la traducción de este documento. Sin embargo, antes de iniciar una traducción de este documento, asegúrate de leer la información sobre traducciones, en nuestra Copyright FAQ, y revisa la lista de traducciones existentes de este documento (disponible en http://www.w3.org/QA/translations#switch).
Tanto si eres un gestor, un desarrollador Web, un miembro de un equipo de Marqueting o de Comunicaciones, o quizá un Web master individual, habrás leído de diversas fuentes sobre el interés en los estándares Web. Has comprendido que los estándares son beneficiosos para tu sitio Web en términos de ahorro de costes, facilidad de gestión y aprovechamiento, y por tanto has decidido cambiar - y emplear estándares en tu sitio Web.
Desafortunadamente, no has encontrado una guía que explique los procesos de cómo empezar y cómo organizar esta transición de tu sitio Web para convertirlo en acorde a los estándares. Podrías pensar que tener un gran sitio Web convierte este objetivo en inalcanzable. Si no estás seguro de qué son los estándares Web, te animamos a leer sobre lo que los estándares Web significan en realidad [WEB-QUALITY], cómo comprar y desarrollar un sitio Web de calidad [REQ-WEBAGENCY], y porqué un sitio Web accessible [WAI-PROFIT] es beneficioso.
El método que proponemos en este documento es válido para sitios Web de cualquier dimensión; satisfará tus necesidades tanto si gestionas un sitio Web personal, de un pequeño negocio o de una gran corporación.
Te guiaremos a través de pasos individuales - cada uno de los cuales serás capaz de completar individualmente - desde el análisis de tu existente sitio Web hasta la organización de tu nuevo sitio Web. Cada uno de estos pasos ha sido diseñado de forma separada, y puede ser emprendido en diferentes ocasiones, diferentes niveles o por diferentes personas, con independencia de su nivel de conocimientos, pero de acuerdo a un flujo de trabajo.
Grande o pequeño, tu sitio Web tiene que ser inicialmente evaluado frente a los estándares; probablemente haya un considerable número de páginas que no cumplen los criterios establecidos para la calidad de tu sitio Web.
Reúne a tus equipos de comunicación, técnico, márqueting y gestión para crear una lista de todas las cosas que querrías evaluar en tu sitio Web. En este estadio, no hay necesidad de priorizar lo que querrías arreglar, pero te animamos a que, como mínimo, compruebes la validez (HTML y CSS), la accesibilidad y la internacionalización de tu sitio Web. Encontrarás algunas explicaciones sobre tales técnicas más adelante en este artículo.
Este artículo describe un método para mejorar tu sitio Web de acuerdo con los estándares del W3C, pero también puedes usar esta estrategia para otros requerimientos que tu sitio Web debería cumplir. Aquí proponemos una lista no exhaustiva:
A veces, tú o tu equipo podeis no tener las habilidades o el conocimiento sobre las cuestiones concernientes a tu sitio Web; si éste es el caso — pide ayuda. Invita a un especialista en accessibilidad o internacionalización a formar parte de tu equipo. Por ejemplo, con respecto a la accesibilidad (cómo de bien pueden acceder a tu sitio Web las personas con discapacidades), puedes pedir ayuda a una asociación local, como la Asociación Pro Ciegos — en muchos casos, estarán más que contentos de ayudarte. Si eres parte de una gran organización, es más que probable que tengas personas con discapacidades en tu compañía. Solícitalo a tu departamento de recursos humanos y sugiere su participación en este proyecto.
Ahora que ya sabes lo que quieres someter a prueba, debes determinar los problemas que existen en tu sitio Web en la actualidad. Una buena manera de hacerlo es crear, en primer lugar, una lista completa de URIs que pertenecen a tu sitio. Este no es un proceso complicado — es suficiente con una sencilla araña que siga los enlaces de la página, y los añada a un fichero de texto plano (e.g. una URI en cada línea).
Podría ser que las tecnologías usadas en tu sitio Web no fueran accesibles para el motor de una araña; ello podría ser una forma de identificar el número de páginas Web que son inaccesibles. Básicamente, este ejercicio te mostrará qué páginas no son capaces de ser indexadas por los motores de búsqueda, lo cual significa que, efectivamente, estás bloqueando tráfico hacia tu sitio.
Una vez hayas hecho la lista, puedes usarla con LogValidator [LOG-VALIDATOR], que es un programa diseñado específicamente para ayudar en el proceso de prueba. LogValidator toma una lista de URIs y las analiza de acuerdo con el módulo que has elegido cargar cuando comienzas el proceso de pruebas. (Esto será parte del trabajo de tu equipo técnico, discute con ellos cómo implementarlo para la configuración de tu sitio.) Para cada URI, aplicará una serie de pruebas y te devolverá el resultado correspondiente.
Después de los primeros análisis, tendrás un mapa de la salud de tu sitio Web, y serás capaz de adoptar una estrategia para organizar el trabajo necesario y arreglar las páginas que tienen fallos. Puedes tener un considerable número de páginas que no cumplen tus criterios. Por ejemplo, todas tus páginas Web podrían ser HTML o XHTML inválidas. Pero no te preocupes — de hecho, ¡son buenas noticias! ¿Por qué? Porque si estás usando un motor de plantillas o un sistema gestor de contenidos para generar tu sitio Web, esto significa que ciertamente tienes errores en tus plantillas.
La solución es sencilla; simplemente corrige tu plantilla y vuelve a ejecutar el test completo de nuevo; deberías obtener menos errores, quizás ninguno. Si no eres el desarrollador del motor de plantillas, solicita a la persona o personas que crearon el CMS para tu sitio Web que lo corrijan. En el futuro, cuando llegue el momento de rediseñar tu sitio Web, sigue la recomendaciones del documento Compra sitios Web que cumplan los estándares [REQ-WEBAGENCY].
Si aún tienes errores en tus páginas Web tras la primera pasada, no te preocupes — esta guía está aquí para ayudarte a corregirlos.
Un beneficio adicional de este primer paso es que obtiene una idea concreta de todas las páginas Web que contiene tu sitio, es decir, que si quieres mover una página, o eliminar una sección de tu sitio Web, tendrás una mejor idea de cómo redirigir a tus visitantes a las nuevas páginas y por tanto no perderás tráfico proveniente de enlaces externos (como los provenientes de otros sitios Web y de los motores de búsqueda). Recuerda, las URIs guays no se rompen.
Ahora tienes una lista de todas las páginas Web que no validan, o tienen otros problemas o errores. No importa si esta lista es larga o corta, ello no variará el método aquí explicado. El primer principio es simple: "¡No arregles! Mejora - organiza tu trabajo"
No es necesario arreglar todo tu sitio Web de una vez, por dos razones principalmente:
Adicionalmente, no intentes corregir únicamente una categoria de problemas en particular, abandonando el resto de problemas hasta haber terminado con la primera. Por ejemplo, si quieres convertir tus páginas html en válidas, y también hacerlas accesibles — haz ambas cosas al mismo tiempo. Si las haces una tras otra, en un ciclo de arreglos posterior, puedes introducir nuevos problemas y afectar negativamente a los buenos resultados obtenidos en el primer ciclo.
Por consiguiente: No arregles todo de una vez, No corrijas problemas por ciclos — mejora tu proceso.
La clave del éxito de este método consiste en ser realista a la hora de tomar decisiones, y asegurarse que servirán para conseguir resultados efectivos. Si quieres mejorar tus páginas Web, debes determinar cuánto tiempo por página te llevará resolver todos los problemas que has identificado. Prueba con una muestra de páginas Web de tu sitio que tengan problemas comunes, y considera las personas con la capacitación adecuada y recursos necesarios en el flujo de trabajo de tu sitio Web.
Una vez que hayas determinado la cantidad de tiempo necesaria para unas pocas páginas, podrás decidir con mayor precisión cuantos recursos y personas destinar a esta tarea, y también cuántas páginas podrás, en realidad, corregir cada dia.
Te animamos a corregir en base a un día en lugar de en base a una semana o un mes . Será más fácil para el responsable de esta tarea planificar el tiempo para este proceso, y llevará menos tiempo por día que por semana. Es más fácil y menos agobiante arreglar 5 páginas en un día que 25 páginas en un día a lo largo de una semana.
Mantén, de forma regular, reuniones con el equipo al cargo de la realización de estas tareas; recoge sus opiniones, argumentos y sus experiencias. Ello te ayudará a determinar si surgen problemas recurrentes del CMS, o el proceso utilizado para editar tus páginas Web. Podrás mejorar el proceso y la calidad de las herramientas que usas de una sola vez.
Después de algún tiempo, y con la experiencia ganada gracias a la implementación de este método, podrás fijar metas. Por ejemplo, el 50% del tráfico que viene a tu sitio Web llega a páginas que cumplen con los criterios que has decidido. Cuando este objetivo esté cumplido, puedes aumentarlo al 60%. Sea lo que sea que tú decidas probar o conseguir, haz que sea razonable y pequeño; este método trata de hacer progresos y mejoras continuos pero asequibles.
Para ser un proyecto verdaderamente exitoso, tendrás que integrar en esta tarea a todas las personas que forman parte del proceso de publicación. Comprender las herramientas, los métodos que se están usando te ayudará a identificar dónde están surgiendo los problemas — ¿existe un problema con la herramienta, o existe un problema con la persona que usa la herramienta? Cuando una herramienta de autor está introduciendo errores en tus páginas, será de ayuda recabar comentarios, y negociar con los creadores de la herramienta para que puedan mejorar su software. Esto es particularmente cierto en el contexto de una gran compañía donde tienes gran número de usuarios; esta es la forma más ingeniosa de asegurar que las mejoras pueden realizarse.
Publica las mejoras — al menos a tu equipo, si no públicamente. Servirá para mostrar vuestro progreso y los animará a continuar. Si ha identificado los problemas que existen en tu sistema de publicación, sólo puedes mejorar desde aquí.
LogValidator [LOG-VALIDATOR], que ya ha sido citado en este artículo, te ayudará a mejorar tu sitio identificando las partes de tu sitio Web que tienen fallos. En su modo por defecto, esta herramienta ha sido diseñada para comprobar progresivamente la validez HTML de documentos. Su principio básico es bastante directo: a partir de un fichero log de un servidor, compila los resultados para ordenar las páginas de mayor número de accesos diarios, y toma las primeras n páginas del orden resultante (donde n es el número que tú especifiques), y las envía al Validador de Marcado del W3C. Tras lo cual, te devolverá los resultados de esta validación.
¿Cuáles son los beneficios? De esta forma, puedes corregir en primer lugar las páginas más accedidas y evaluar la calidad de tu sitio Web según este criterio — no en términos de número absoluto de páginas.
LogValidator tiene una arquitectura abierta y modular escrita en Perl, y puedes desarrollar los módulos que desees añadir según tus propias necesidades. Por ejemplo, puedes desarrollar un corrector ortográfico, o un módulo que compruebe si el logo y la información del pie es correcta en todas tus páginas, o quizás podrías tener un módulo que comprobase enlaces rotos dentro de tu sitio. También es una herramienta fácil de instalar y forma parte del archivo CPAN.
El número de posibilidades es interminable, por tanto lo mejor es ser realista en los términos de tus objetivos.
Habiendo adoptado el uso de LogValidator, existen diferentes maneras de proceder y analizar los resultados devueltos por LogValidator. Por ejemplo, podrías configurar una lista de correo interna en la que tu nuevo equipo de aseguramiento de la calidad del sitio Web reciba, cada mañana, una lista de URIs que necesitan atención, y tu equipo tendrá que corregir el contenido o bien informar si el origen del problema está en otro lugar.
Este método paso a paso te ayuda a mantener la calidad de tu sitio Web, pero aún debes verificar de forma regular si los problemas vuelven a producirse
Cada cierto tiempo (cada 3 meses, por ejemplo), vuelve a ejecutar el análisis completo, ello te ayudará a saber si has realizado progresos en la calidad general de tu sitio Web, y también a determinar qué problemas hay con tu motor de plantillas. También te será de ayuda para cumplir los objetivos que te fijaste al inicio. Si la calidad de tu sitio Web no se incrementa, tendrás algo que corregir en tu proceso.
Finalmente, recompensará el trabajo de tu equipo, las perosnas involucradas en este esfuerzo, mostrándoles el progreso que han hecho. Poco a poco, ganarás experiencia que será beneficiosa para tu organización. Al mismo tiempo que realizas tu revisión, compila una lista de todo lo realizado y házla pública. Este será el manual actualizado sobre la calidad de tu sitio Web.
A menudo, existe una guía de estilo en tu compañía que define la política sobre los colores corporativos y su logo. Incorpora a esta guía las sencillas técnicas que ayudarán a la gente a mejorar el sitio Web cuando se detecte un error.
El método descrito en esta guía es dinámico y no está ligado a algo concreto; tiene que evolucionar con tus necesidades. Si tu proceso de publicaciónThe method described in this guide is dynamic and not sealed in concrete; it has to evolve with your needs. If your publishing process have requirements which are no longer relevant, or new requirements have been added, it will be necessary to adjust your publishing process, and therefore your quality assurance process.
La solución para evaluar y mejorar la calidad que hemos propuesto aquí está dividida en componentes que no interfieren unos con otros, por lo tanto puedes prescindir de aquellas partes que no necesites, y añadir nuevos componentes si es preciso.
Podrías estar en el caso en que un problema no tenga una solución práctica inmediata porque te sea imposible remediarlo por tí mismo. Por ejemplo, puedes estar utilizando una herramienta de publicación, una herramienta de autor que no genera código válido. Has probado varios métodos, has intentado rodearlo, pero nada ha funcionado. Es absolutamente necesario recoger esta información y enviársela a la compañía creadora del producto, no a título individual, sino en nombre de tu compañía. Representas un segmento del mercado, por tanto la compañía creadora de la herramienta de autor te prestará atención.
Para mantener la calidad de tu sitio, tendrás que recompensar los buenos autores internos y ayudar a aquellos que tienen más dificultades. No habrá éxito si tus usuarios no ven los beneficios del método que has elegido. Invítalos, anímalos a informar sobre cualquier problema en el proceso, con las herramientas, etc. ello mejorará la organización entera.
Este método es sencillo y ha sido aplicado durante años en el W3c sólo para la parte de HTML, ayudándonos a mantener la validez de todas las páginas Web. Este método puede ser muy potente si lo utilizas en tu propia compañía o equipo.
Gracias a las personas que han revisado este artículo: Olivier Théreaux, Stephanie Troeth, Denis Boudreau y la gente de la lista de correo public-evangelist.