Como todos sabéis, HTML no es un lenguaje de programación, sino de representación y comunicación de información. Por ello, no se compila, sino que es interpretado por unos programas especiales a los que llamamos navegadores (aunque Microsoft intentó que los llamásemos exploradores). La cuestión es que este hecho de ser interpretado, y no compilado, le otorga una de sus principales ventajas y desventajas:
En lo positivo, no es necesario que una página esté escrita perfectamente para poder ser interpretada. Un error no va a provocar que no cargue la página, sino que en el peor de los casos hará que una zona se vea mal, o incluso puede que pase desapercibido porque nuestro navegador lo ignore.
En la parte negativa, esta libertad de los navegadores para ignorar o interpretar a su antojo ciertos campos, ha propiciado que cada uno haya querido cambiar el lenguaje a su gusto, y que a menudo una página varíe dependiendo del navegador utilizado para mostrarla.
El por qué de la validación
Con estas premisas, parece fácil averiguar la necesidad de la validación: si conseguimos implementar a rajatabla las directrices del World Wide Web Consortium (W3C) acerca del lenguaje, habremos hecho todo lo que está en nuestra mano para que la página se vea bien en cualquier dispositivo, y ya será responsabilidad de cada navegador el mostrarla conforme a lo establecido en los estándares del lenguaje.
En ese sentido, por el mero hecho de hacer bien nuestro trabajo, nos puede interesar que nuestros documentos cumplan con el formato que dicen tener. Por eso es importante que nuestro documento empiece siempre indicando la definición del DOCTYPE al que corresponde.
Pero más allá de nuestra propia exigencia, hay ciertos tipos de clientes o situaciones que requieren que seamos más estrictos a la hora de crear webs:
Cuando se quiere compatibilidad con dispositivos móviles.
Cuando se necesita que la página se pueda ver en navegadores antiguos.
Cuando el cliente pertenece a una administración pública.
Cuando la página va a mostrar contenido médico, y por ende es susceptible de ser visitada por personas con minusvalías.
Etc.
Pero cuidado, el hecho de que nuestra web cumpla con los requisitos del W3C no implica que el resultado sea de calidad. Sólo nos asegura que, salvo pequeñas excepciones, se va a ver igual de bien o igual de mal en todos los navegadores.
Cuándo realizar la validación
Antes de nada, vamos a recordar la versión de Ingeniería del Software del Principio de Pareto:
El 80% del esfuerzo de desarrollo (en tiempo y recursos) produce el 20% del código, mientras que el 80% restante es producido con tan sólo un 20% del esfuerzo.
Aunque si sois más pesimistas, existe otra versión más sarcástica:
El primer 90% del código ocupa el 90% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% de tiempo de desarrollo.
En cualquier caso, sea cual sea la versión que apoyáis, debéis entender que la validación forma parte del segundo bloque: no es parte de la lógica de negocio, sino de la representación. Es más, puede que su resultado apenas sea perceptible, por lo que no conviene dedicarle de primeras el tiempo que no tenemos.
Quien conoce el ciclo de vida de un proyecto, sabe que los requisitos casi nunca están congelados y que a menudo hay que cambiar código que probablemente ya estaba refinado. Por eso, es importante centrar nuestra mayor parte del tiempo en la funcionalidad: que la página haga lo que tenga que hacer. Más adelante nos encargaremos de la presentación: que lo haga de forma agradable y bonita. Y por último, de la homogeneidad: que sea igual de agradable y bonito en cualquier navegador.
Sin embargo, dejarlo para el final de proceso de desarrollo no significa tenerlo olvidado. Si evitamos las malas prácticas desde un comienzo, será mucho más fácil conseguir que el código resultante sea válido, ya que el proceso de obtención de la validación no es más que el pulir una joya para que brille al máximo. Es importante tener esa joya sin impurezas si no queremos acabar puliendo un trozo de carbón.
Cómo validar el código
Vale, ya hemos entendido por qué queremos validar y hemos llegado a esa etapa final en la que disponemos del tiempo y los recursos para hacerlo. ¿Por dónde empezar?
Como decíamos antes, va a ser fundamental definir el DOCTYPE que nuestro código va a respetar, ya que un HTML que sea perfectamente válido desde la óptica del XHTML 1.1 probablemente presente multitud de fallos si lo validamos contra HTML 4.01 Strict, por ejemplo.
Mi consejo es que si estáis acostumbrados a usar XML, optéis por XHTML 1.0 Transitional, que tiene características comunes a XML, como que todos los tags que no tienen etiquetas diferenciadas de apertura y cierre han de incluir la barra / antes de finalizar. Si no, con HTML 4.01 Transitional os debería bastar.
En cuanto al hecho de usar una definición Transitional en lugar de Strict, como el propio nombre dice se debe a que el primero es un modelo de transición entre el que era el estado del arte antes de aprobar esa versión de HTML y el estricto. Realmente el Transitional suele incluir duplicidades que ya no son aceptadas en el Strict, como por ejemplo:
<script language="JavaScript" type="text/javascript">Esa apertura del tag script sería válida en Transitional, pero no ya en el Strict, donde language desaparece en beneficio de un único atributo type.
Sea cual sea el DOCTYPE elegido, o incluso para nuestras hojas CSS o imágenes SVG, la herramienta a utilizar es el validatdor del W3C. Al introducir nuestra URL (o el código a pelo, si la página aún no está abierta al público), nos avisará de la cantidad de errores que impiden que nuestro código sea válido y de advertencias sobre detalles que deberíamos mejorar. No os preocupéis si el número en principio es alto: incluso una página tan simple y a la vez tan importante como la home de Google, presenta una cuarentena de errores:
Google suspende en el validador de HTML5
Además, el propio validador nos avisa de en qué línea se produce cada error, señalando la regla que contraviene y su probable resolución, por lo que el proceso se suele basar en una consecución de pequeñas correcciones y vuelta a pasar por el validador.
Una vez que el resultado sea positivo, el propio validador nos instará a utilizar los iconos correspondientes para presumir de que nuestra página es válida.
Un paso más allá de la validación: la accesibilidad
Hasta ahora nos hemos centrado únicamente en hacer un documento que todos los navegadores entiendan igual de bien, pero desde un punto de vista humano es más importante conseguir que sean las personas las que puedan acceder de una misma manera al contenido, independientemente de cualquier tipo de incapacidad que puedan tener. Por eso, al hacer una página válida habremos dado el primer paso para llegar a la accesibilidad, pero aún faltarán otros tantos.
Dado que la inaccesibilidad de una página sólo puede medirse por las dificultades que una persona tenga para navegar por ella, no existe un método automático de medirla, sino unas directivas a seguir para al menos intentar conseguirla. Del mismo modo, no hay una verificación de que una página es accesible, pero sí un compromiso por parte del creador de que la página intenta ser accesible en uno de estos tres niveles:
Nivel A: Un desarrollador web debe satisfacer estos requisitos. De modo contrario, para uno o más grupos de usuarios sería imposible acceder a la información del documento.
Nivel AA: Un desarrollador web debería satisfacer estos requisitos. De modo contrario, para uno o más grupos de usuarios sería difícil acceder a la información del documento.
Nivel AAA: Un desarrollador web podría satisfacer estos requisitos. De modo contrario, uno o más grupos de usuarios encontraría algunas dificultades a la hora de acceder a la información del documento.
Estos niveles se consiguen superando todos los requisitos de prioridad 1, 2 y 3 fijados por el WCAG, y que a su vez se pueden dividir en requisitos de revisión automática o manual. Con tests como el TAW Monitor podremos descubrir todos los problemas de resolución automática y señalar aquellos puntos donde hará falta una revisión manual.
Por ejemplo, una imagen que no contenga texto alternativo para los usuarios invidentes, o un iframe que no tenga una versión alternativa para navegadores antiguos darán un fallo automático, mientras que una imagen con texto alternativo “” o una tabla usada para maquetar en vez de para mostrar información tabulada darán un fallo manual, ya que el algoritmo no puede saber si ese texto vacío o esa tabla es necesario que se modifiquen para que un usuario discapacitado no pierda información.
Es por esto que los niveles de accesibilidad no se pueden verificar por completo de forma automática, y el hecho de mostrar su sello en una página sólo muestra el compromiso por parte de los creadores de hacerla accesible a todo el mundo, sin confirmar que lo hayan conseguido.
Pero, como siempre, podemos ir más allá y buscar más herramientas que nos ayuden a conocer los impedimentos que nuestras páginas puedan presentar para determinados grupos de usuarios. Por ejemplo, en Colorblind web page filter podemos ver cómo percibirían la página los afectados por distintos tipos de daltonismo. ¿Conocéis algún otro ejemplo con el que ponernos en la piel de un usuario con discapacidades?
Genbeta Dev vista por un usuario con protanopia (daltonismo sin conos para el color rojo)
Validador del W3C | validator.w3.org
Más información | Guía de accesibilidad web
En Genbeta | TAW3 online, test de accesibilidad de nuestra web