El presupuesto de calidad

Antes de empezar. El portfolio dispone ya de validación automática de marcado, enlaces y formato. En esta sesión se define y se verifica un umbral cuantitativo de calidad.

---

Se explica

25 minutos · explicación conceptual y demostración técnica

De la verificación binaria a la métrica cuantitativa

Las comprobaciones implementadas hasta ahora funcionan de forma binaria:

• HTML válido: ¿cumple la especificación? → sí / no
• Enlaces vivos: ¿responden los destinos? → sí / no
• Formato: ¿se ajusta a la convención? → sí / no

Sin embargo, hay dimensiones de calidad que no se reducen a un simple sí o no. Por ejemplo: ¿qué nivel de accesibilidad ofrece el documento? ¿Presenta omisiones básicas que dificulten su indexación en buscadores? Para responder a estas cuestiones, el pipeline pasa de la comprobación binaria a evaluar qué nivel alcanza en determinadas dimensiones de calidad que sí pueden auditarse automáticamente.

Lighthouse

Herramienta de auditoría automatizada que carga el documento en una instancia de navegador, ejecuta sobre él un conjunto de comprobaciones y emite cuatro puntuaciones normalizadas de 0 a 100: rendimiento, accesibilidad, buenas prácticas y posicionamiento (SEO). Junto a cada puntuación detalla las comprobaciones incumplidas, con la ubicación exacta del defecto en el documento.

El presupuesto de calidad como umbral acordado

Presupuesto de calidad (quality budget)

Valor mínimo pactado con antelación al desarrollo y declarado en un archivo de configuración versionado. Un resultado inferior impide la fusión. Su formalización numérica y su registro en el repositorio son precisamente lo que evita el aplazamiento indefinido de las correcciones de calidad.

La puntuación mínima de Lighthouse es un criterio interno de calidad del proyecto; no constituye una certificación de conformidad con WCAG ni de cumplimiento legal.

El presupuesto acordado para el portfolio es el siguiente:

Fundamento de la evaluación de la accesibilidad

La UD1 estableció que el diseño gráfico no forma parte del alcance evaluativo de este módulo, criterio que se mantiene. La accesibilidad constituye un área técnica que cuenta con criterios medibles y estándares de referencia (como las pautas WCAG 2.1 y la norma EN 301 549, vinculada en el sector público al Real Decreto 1112/2018).

Entre los defectos más habituales que detecta la herramienta se encuentran los siguientes:

Imagen sin texto alternativo

Un lector de pantalla anuncia únicamente la existencia de una imagen, sin información sobre su contenido. Corrección: un atributo alt.

Idioma del documento no declarado

El sintetizador de voz aplica la fonética del idioma por defecto al texto en español. Corrección: atributo lang en html.

Enlace cuyo texto es «aquí»

La navegación secuencial por enlaces, habitual con lector de pantalla, produce una lista de destinos indistinguibles entre sí. Corrección: reformular el texto del enlace.

Contraste insuficiente entre texto y fondo

El texto resulta ilegible con iluminación intensa o con baja visión. La WCAG establece una ratio mínima de 4,5:1 para el texto normal. Corrección: ajustar un color.

Salto de un encabezado de nivel 1 a uno de nivel 3

La estructura jerárquica del documento queda inconsistente para quien navega mediante encabezados. Corrección: ajustar el nivel.

Estos defectos contienen aspectos verificables automáticamente, aunque una auditoría automática no garantiza por sí sola la accesibilidad completa del sitio. Por ejemplo, la herramienta comprueba que exista el atributo alt, pero no puede determinar de forma autónoma si la descripción redactada transmite con precisión el significado de la imagen.

---

Se trabaja

140 minutos · trabajo práctico guiado sobre el proyecto base

Bloque A · Medición inicial de referencia

Trabajo individual, en el navegador

Antes de automatizar la auditoría, conviene ejecutarla manualmente una vez. Abre el portfolio publicado, accede a las herramientas de desarrollo, selecciona la pestaña Lighthouse en modo escritorio y ejecuta Analizar.

Registra las cuatro puntuaciones obtenidas sin aplicar corrección alguna. Constituyen la medición de referencia con la que se compararán los resultados al final de la sesión.

Rendimiento / Accesibilidad / Buenas prácticas / SEO

Las tres incidencias de accesibilidad con mayor prioridad en el informe

Bloque B · Declaración del presupuesto en el repositorio

Trabajo individual, con issue y rama previas

1 · Archivo de configuración. Crea en la raíz el archivo lighthouserc.json:

{
  "ci": {
    "collect": {
      "staticDistDir": "./"
    },
    "assert": {
      "assertions": {
        "categories:accessibility": ["error", { "minScore": 0.9 }],
        "categories:seo": ["error", { "minScore": 0.9 }],
        "categories:best-practices": ["error", { "minScore": 0.9 }],
        "categories:performance": ["warn", { "minScore": 0.8 }]
      }
    }
  }
}

La directiva staticDistDir declara que el sitio consiste en archivos estáticos ubicados en esa ruta: la propia herramienta los sirve durante la auditoría, por lo que la medición no requiere que la página esté desplegada. El nivel error bloquea la integración; el nivel warn únicamente informa.

2 · Definición del job. Incorpora a ci.yml, al mismo nivel que los tres anteriores:

  calidad:
    name: Presupuesto de calidad
    runs-on: ubuntu-latest
    steps:
      - name: Descargar el repositorio
        uses: actions/checkout@v4

      - name: Auditar con Lighthouse
        uses: treosh/lighthouse-ci-action@v12
        with:
          configPath: ./lighthouserc.json
          uploadArtifacts: true

3 · Ejecución y recuperación del informe. Abre la pull request. La duración de este job es superior a la de los anteriores, dado que instancia un navegador completo para auditar el documento. Al finalizar, accede a la ejecución y descarga el informe desde la sección de artefactos: es equivalente al obtenido en el navegador, pero generado en un entorno reproducible.

Bloque C · Corrección de los defectos detectados

Trabajo individual, con puesta en común de los defectos que resulten frecuentes en el grupo

Recorre la relación de incidencias de accesibilidad del informe en orden de prioridad y aplica las correcciones. Entre los defectos más habituales se encuentran los expuestos en la parte teórica:

• Imágenes sin texto alternativo. En las imágenes decorativas el atributo se declara vacío, pero debe declararse.
• Idioma no declarado en la etiqueta raíz del documento.
• Enlaces cuyo texto no identifica el destino.
• Contraste insuficiente entre el texto y su fondo.
• Encabezados que omiten un nivel de la jerarquía.

Agrupa las correcciones en commits pequeños y coherentes. Evita mezclar modificaciones no relacionadas en una misma confirmación. Durante esta actividad, realiza al menos dos correcciones por separado para observar su efecto sobre la auditoría. Cuando el informe deje de señalar incidencias, repite la auditoría en el navegador y compara el resultado con la medición de referencia del bloque A.

Bloque D · Cierre del primer proyecto

Trabajo individual, última pull request de la unidad

---

Cierre

15 minutos · comprobación del resultado

Ver respuestas

1 · La primera verifica el cumplimiento de una condición y responde sí o no; el segundo mide una magnitud y la contrasta con un umbral acordado previamente.

2 · Porque existen criterios técnicos de accesibilidad verificables automáticamente y estándares de referencia, mientras que muchas decisiones estéticas requieren valoración profesional y quedan fuera del alcance de este módulo.

3 · No. Lighthouse comprueba automáticamente un subconjunto de criterios. Una evaluación completa requiere también comprobaciones manuales y, en determinados casos, pruebas con tecnologías de asistencia.

4 · Porque la puntuación depende de la capacidad y carga de la máquina que ejecuta la medición, lo que provocaría fallos intermitentes por causas ajenas al código evaluado.

5 · Para evitar que el proyecto sufra regresiones inadvertidas. Se aplica una política con margen de tolerancia (por ejemplo, umbral en 95 ante un 96 observado) para absorber la variabilidad técnica entre ejecuciones.

6 · Declara que la herramienta debe servir por sí misma los archivos estáticos de esa ruta, lo que permite auditar el sitio sin haberlo desplegado previamente.