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
- Una página «funciona». ¿Es posible expresar mediante una magnitud numérica en qué grado lo hace?
- ¿Cómo utilizaría tu portfolio una persona que no percibe la pantalla?
- 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.ymlde 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.
Cierre
15 minutos · comprobación del resultado
Autoevaluación conceptual · sin consulta de apuntes
- ¿Qué diferencia existe entre una comprobación de resultado binario y un presupuesto de calidad?
- ¿Por qué la accesibilidad se evalúa en este módulo y la tipografía no?
- ¿Por qué el rendimiento se declara como advertencia y no como bloqueo?
- La puntuación ha alcanzado 96. ¿Por qué debe modificarse el archivo de configuración?
- ¿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
mainy 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.