← Que lo compruebe la máquina

Sesión 5

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.

Evaluación inicial · sin apuntes

  1. Una página «funciona». ¿Es posible expresar mediante una magnitud numérica en qué grado lo hace?
  2. ¿Cómo utilizaría tu portfolio una persona que no percibe la pantalla?
  3. Si se estableciera una puntuación mínima de accesibilidad, ¿la superaría tu página en su estado actual?

Se explica

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

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

Las cuatro comprobaciones implementadas hasta ahora emiten un resultado binario. Queda fuera de su alcance la pregunta que formula cualquier cliente y que el pipeline todavía no responde: en qué grado.

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.

El presupuesto acordado para el portfolio es el siguiente:

Categoría Umbral mínimo Fundamento del valor
Accesibilidad 90 Alcanzable en un sitio estático; por debajo de ese valor existen barreras de uso reales
SEO 90 Un portfolio no indexable no cumple su función de difusión profesional
Buenas prácticas 90 Evalúa mayoritariamente defectos cuya corrección no implica coste de desarrollo
Rendimiento advertencia La puntuación depende de la capacidad de la máquina que ejecuta la medición; informa, pero no bloquea la integración

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 una excepción fundamentada en tres razones: es objetiva, al expresarse mediante métricas verificables de forma automática; es exigible legalmente en los productos destinados al sector público, conforme al Real Decreto 1112/2018 y a la norma EN 301 549, que adopta como referencia técnica las pautas WCAG 2.1 en nivel AA; y la mayoría de los defectos que reducen su puntuación son omisiones cuya corrección es inmediata.

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.
Idioma del documento no declarado
El sintetizador de voz aplica la fonética del idioma por defecto al texto en español. Corrección: un atributo.
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.

Ninguno de los cinco defectos depende de una apreciación subjetiva y todos son detectables de forma automatizada.


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. Los cinco defectos siguientes aparecen en la práctica totalidad de los portfolios y su fundamento se ha expuesto 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.

Cada corrección se registra en su propio commit. 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.

Elevación del umbral tras alcanzar la mejora

Si la puntuación de accesibilidad alcanza 96, el mínimo declarado en el archivo debe elevarse a 95 e integrarse ese cambio. El principio aplicable es que toda mejora conseguida se protege mediante el umbral: mantenerlo en 90 permite que una incorporación posterior —una imagen sin texto alternativo, por ejemplo— degrade la puntuación hasta 92 sin que ninguna comprobación lo detecte. Un presupuesto situado por debajo del estado real del producto no ejerce ninguna función de control.

Bloque D · Cierre del primer proyecto

Trabajo individual, última pull request de la unidad

Trabajo esperado de la unidad

  • Portfolio con cabecera, presentación, proyectos y contacto, publicado y con estilos propios.
  • Un archivo ci.yml de elaboración propia con cuatro jobs: marcado, enlaces, formato y calidad.
  • Las cuatro comprobaciones declaradas como obligatorias en el ruleset de la rama principal.
  • Puntuación de accesibilidad superior a 90, con el umbral del archivo ajustado al valor alcanzado.
  • La totalidad del contenido de estas tres semanas incorporado mediante pull request, ninguna fusionada sin revisión previa de la pareja asignada.
Objetivo mínimoLos cuatro jobs en estado correcto y el portfolio publicado con contenido definitivo.
AmpliaciónEl umbral de accesibilidad elevado al valor alcanzado y justificado en la descripción de la pull request.
RetoIncorporar al presupuesto una aserción sobre el peso total de la página e identificar qué recurso concentra la mayor parte de ese peso.

Cierre

15 minutos · comprobación del resultado

Autoevaluación conceptual · sin consulta de apuntes

  1. ¿Qué diferencia existe entre una comprobación de resultado binario y un presupuesto de calidad?
  2. ¿Por qué la accesibilidad se evalúa en este módulo y la tipografía no?
  3. ¿Por qué el rendimiento se declara como advertencia y no como bloqueo?
  4. La puntuación ha alcanzado 96. ¿Por qué debe modificarse el archivo de configuración?
  5. ¿Qué función cumple la directiva staticDistDir?
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 mínimo acordado previamente.

2 · Porque es objetiva, cuantificable y jurídicamente exigible en el sector público. La tipografía responde a criterio profesional, y ese criterio se evalúa en el módulo que lo imparte.

3 · Porque la puntuación depende de la capacidad de la máquina que ejecuta la medición, de modo que bloquearía la integración por causas ajenas al código evaluado.

4 · Porque una mejora que no se protege mediante el umbral puede perderse sin detección: con el mínimo en 90 caben sucesivas degradaciones inadvertidas.

5 · 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.

Antes de la sesión 6

  • Las cuatro comprobaciones en estado correcto sobre main y el portfolio publicado con el contenido de la unidad.
  • Cuatro revisiones propias registradas en el repositorio de la pareja asignada a lo largo de estas tres semanas.
  • Un registro escrito de qué se mostraría a una persona que accede al repositorio sin conocer el proyecto: la sesión 6 se dedica a la redacción del README y a la publicación de la primera versión etiquetada.