10. Verificación final y accesibilidad del portafolio UX/UI

¿Qué aprenderás?

En este tutorial realizaremos una verificación final del portafolio profesional UX/UI, desarrollado con WordPress, Blocksy y Gutenberg.

Nuestro objetivo será comprobar que el sitio no solamente tenga una presentación visual coherente, sino que también pueda utilizarse de manera comprensible en diferentes dispositivos y con distintos métodos de interacción.

Trabajaremos con principios de accesibilidad web, utilizando como referencia las Web Content Accessibility Guidelines (WCAG) 2.2 y las recomendaciones de W3C Web Accessibility Initiative.

También utilizaremos Chrome DevTools y Lighthouse para identificar problemas técnicos y documentar los resultados.

Objetivos de aprendizaje

Al finalizar esta lección podrás:

Comprender la diferencia entre usabilidad, accesibilidad y diseño responsivo.
Identificar criterios básicos de accesibilidad asociados a WCAG 2.2.
Planificar una revisión final del portafolio profesional.
Comprobar el comportamiento del sitio en diferentes tamaños de pantalla.
Verificar navegación por teclado, foco visible y menús móviles.
Revisar la jerarquía de encabezados y los títulos de página.
Evaluar la claridad y el funcionamiento de los enlaces.
Identificar textos alternativos adecuados para las imágenes.
Comprobar contraste de textos y componentes visuales.
Verificar ampliación de texto y reorganización del contenido.
Revisar formularios, instrucciones y mensajes de error.
Utilizar Lighthouse como herramienta complementaria.
Registrar incidencias, prioridades y resultados.
Preparar un informe de verificación final del portafolio.

Nivel: Inicial e intermedio.
Herramientas: WordPress, Blocksy, Gutenberg, Google Chrome y Lighthouse.
Requisito previo: Haber completado los tutoriales 01 al 09.
Proyecto: Portafolio profesional de un diseñador gráfico especializado en UX/UI.
Modalidad: Verificación práctica y documentación de resultados.
Plugins adicionales: No son necesarios para las verificaciones básicas.
Referencias: WCAG 2.2 y W3C Web Accessibility Initiative.

1. ¿Por qué debemos verificar nuestro sitio web?

Durante el desarrollo de un sitio podemos concentrarnos en que su apariencia coincida con el prototipo diseñado en Figma.

Sin embargo, un sitio visualmente atractivo también puede presentar dificultades de navegación y accesibilidad.

Por ejemplo:

Un enlace puede no funcionar.
Un menú móvil puede no abrirse mediante teclado.
Un texto puede tener contraste insuficiente.
Una imagen puede carecer de una descripción alternativa.
Un botón puede resultar difícil de seleccionar.
Un formulario puede no explicar sus errores.
Una sección puede desbordarse en pantallas pequeñas.

Por eso necesitamos comprobar el resultado antes de considerar terminada la implementación.

Tres conceptos relacionados

Diseño responsivo: capacidad de adaptar la presentación a diferentes tamaños y características de pantalla.

Usabilidad: facilidad con que las personas pueden comprender y utilizar la interfaz para completar sus objetivos.

Accesibilidad: posibilidad de utilizar el contenido y las funcionalidades por personas con diferentes capacidades y tecnologías de apoyo.

¿Son lo mismo?

No.

Un sitio puede ser responsivo y presentar barreras de accesibilidad.

También puede superar varias pruebas técnicas de accesibilidad y mantener problemas de usabilidad.

Por eso debemos evaluar estos aspectos de manera complementaria.

2. Introducción a WCAG 2.2

Las Web Content Accessibility Guidelines, conocidas como WCAG, reúnen recomendaciones para mejorar la accesibilidad del contenido web.

Son publicadas por W3C.

Principios fundamentales

WCAG organiza sus criterios en cuatro principios:

Principio	Significado
Perceptible	La información debe poder percibirse
Operable	La interfaz debe poder utilizarse
Comprensible	El contenido y su funcionamiento deben entenderse
Robusto	El contenido debe ser interpretable por diferentes tecnologías

Niveles de conformidad

WCAG establece tres niveles:

A.
AA.
AAA.

En este tutorial utilizaremos diferentes criterios de nivel A y AA como referencia para nuestras comprobaciones.

Una aclaración importante

Completar esta guía no constituye una certificación de conformidad con WCAG 2.2.

Realizaremos una revisión educativa inicial.

Una evaluación completa requiere revisar los criterios aplicables, las diferentes páginas y estados de interacción, y efectuar pruebas manuales adicionales.

Tampoco debemos considerar que obtener una puntuación alta en Lighthouse garantiza accesibilidad.

Documentación oficial

Web Content Accessibility Guidelines 2.2 — W3C

Easy Checks: A First Review of Web Accessibility — W3C

3. Planificar la revisión final

Antes de comenzar necesitamos definir qué páginas y funcionalidades serán evaluadas.

Para nuestro portafolio profesional UX/UI podemos utilizar:

Inicio.
Sobre mí.
Proyectos.
Una página individual de proyecto.
Contacto.

La estructura exacta dependerá de las páginas implementadas por el estudiante.

Qué debemos registrar

Elemento	Ejemplo
Página	Inicio
URL	Dirección de la página
Dispositivo	Móvil
Prueba	Navegación por teclado
Resultado	Correcto o incidencia
Observación	Descripción del hallazgo

Estados sugeridos

Correcto: la prueba realizada no detectó un problema.

Incidencia: encontramos una situación que requiere revisión.

No aplica: la funcionalidad evaluada no existe en esa página.

Pendiente: la comprobación todavía no se ha realizado.

Importante

Una prueba puede parecer correcta en una página y presentar problemas en otra.

Por eso seleccionaremos páginas representativas y registraremos el alcance de nuestra revisión.

Definir el alcance de la verificación

Abre el portafolio profesional en Google Chrome.

Identifica las páginas que forman parte del sitio.

Registra sus nombres y direcciones.

Marca qué páginas contienen:

Navegación principal.
Tarjetas de proyectos.
Imágenes.
Botones.
Formularios.
Contenido multimedia.

Prepara una tabla de verificación.

Indica también si estás trabajando en una instalación local, staging o un sitio publicado.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 01. Alcance de la verificaciónCaptura pendiente: tabla de páginas y funcionalidades del portafolio.

Resultado esperado:Dispones de una lista de páginas y funcionalidades que revisarás durante la actividad.

4. Registrar el estado inicial

Para evaluar una mejora necesitamos conocer el estado anterior del sitio.

Esto es especialmente importante si encontramos problemas que requieren modificaciones.

Recomendaciones

Conserva:

Referencias visuales de escritorio.
Referencias visuales de móvil.
URL de la página.
Ancho de pantalla utilizado.
Fecha de la prueba.
Descripción de los problemas detectados.

Diferencia entre verificar y corregir

Verificar: comprobar el comportamiento y registrar los hallazgos.

Corregir: aplicar una modificación para resolver una incidencia.

En esta etapa priorizaremos primero la verificación.

Las correcciones podrán realizarse utilizando los procedimientos aprendidos en los tutoriales anteriores.

Registrar una referencia inicial

Selecciona una página del portafolio.

Abre Chrome DevTools y establece un ancho de referencia.

Realiza una captura de la página.

Registra el ancho utilizado.

Repite el procedimiento en una vista de escritorio y una vista móvil.

Anota cualquier problema que resulte evidente.

Guarda las referencias en la carpeta o documento donde registrarás la actividad.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 02. Evidencia inicial del sitioCaptura pendiente: vistas de escritorio y móvil antes de la revisión.

Resultado esperado:Cuentas con evidencia del estado previo a la revisión final.

5. Comprobar el diseño responsivo

Una página debe mantener su contenido legible y sus funcionalidades disponibles cuando cambia el espacio de visualización.

Para nuestro ejercicio utilizaremos Chrome DevTools.

Anchos de referencia

Vista	Ancho de prueba
Móvil estrecho	320 px
Móvil habitual	360 px
Móvil amplio	390 px
Tableta	768 px
Escritorio	1280 px

Estos valores son dimensiones de prueba.

No representan necesariamente los breakpoints utilizados por Blocksy o Gutenberg.

Qué debemos comprobar

Que no existan elementos superpuestos.
Que las imágenes no oculten información relevante.
Que los títulos puedan leerse.
Que las columnas se reorganizen correctamente.
Que los botones mantengan suficiente espacio.
Que la navegación permanezca disponible.
Que no aparezcan desbordamientos horizontales innecesarios.

Comprobar el comportamiento en distintos anchos

Abre la página Inicio en Google Chrome.

Activa DevTools.

Selecciona el modo de dispositivos.

Configura un ancho de 320 píxeles.

Recorre la página completa, desde el header hasta el footer.

Comprueba los elementos principales.

Repite las pruebas con 360, 390, 768 y 1280 píxeles.

Cambia progresivamente el ancho para identificar problemas intermedios.

Registra los resultados.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 03. Pruebas de diseño responsivoCaptura pendiente: portafolio visualizado en diferentes anchos mediante DevTools.

Resultado esperado:Identificas si el portafolio presenta problemas de distribución en diferentes tamaños de pantalla.

Documentación oficial

Device Mode — Chrome DevTools

6. Comprobar la navegación por teclado

No todas las personas utilizan un mouse para interactuar con los sitios web.

Algunas utilizan teclado u otras tecnologías de asistencia.

Por eso los enlaces, botones, campos y menús deben poder utilizarse mediante mecanismos adecuados de navegación.

Teclas importantes

Tab: avanza entre controles interactivos.

Shift + Tab: retrocede entre controles.

Enter: activa enlaces y determinados controles.

Barra espaciadora: activa determinados botones y otros controles.

Escape: permite cerrar algunos paneles y diálogos cuando están implementados para responder a esa tecla.

Qué debemos comprobar

Que podamos alcanzar los enlaces.
Que los botones sean seleccionables.
Que el orden de navegación sea lógico.
Que exista una indicación visible del foco.
Que no quedemos atrapados en un componente.
Que las funcionalidades relevantes puedan ejecutarse sin mouse.

Consideración para macOS

Si el navegador no permite recorrer determinados controles mediante Tab, revisa la configuración de navegación por teclado del sistema o del navegador antes de concluir que existe un problema en el sitio.

Realizar una prueba completa con teclado

Abre la página del portafolio.

Deja de utilizar el mouse durante esta prueba.

Presiona Tab para recorrer los controles interactivos.

Observa el orden en que son seleccionados.

Prueba enlaces y botones con Enter.

Utiliza Shift + Tab para retroceder.

Comprueba si puedes llegar a:

Navegación principal.
Enlaces de proyectos.
Botones.
Contacto.
Enlaces del footer.

Registra cualquier elemento que no puedas alcanzar o activar.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 04. Navegación por tecladoCaptura pendiente: enlace o botón seleccionado mediante teclado.

Resultado esperado:Puedes identificar si los principales controles del sitio funcionan sin utilizar un mouse.

Documentación oficial

Easy Checks: Keyboard Access and Visual Focus — W3C

7. Verificar el menú móvil

En el Tutorial 06 configuramos la navegación móvil con Blocksy.

Ahora necesitamos comprobar su funcionamiento desde la perspectiva del usuario.

Elementos importantes

Logo.
Trigger.
Off Canvas Area.
Menu – Mobile.
Botón de cierre.
Enlaces de navegación.

Problemas que debemos detectar

El menú no se abre.
El Trigger no recibe foco.
El panel queda abierto sin posibilidad de cerrarlo.
Los enlaces no se pueden recorrer.
El foco continúa en contenido oculto de manera inapropiada.
Los enlaces conducen a páginas incorrectas.

Comprobar el menú móvil con teclado

Abre el sitio en una vista móvil.

Utiliza Tab hasta seleccionar el Trigger del menú.

Comprueba que puedas reconocer visualmente el control seleccionado.

Actívalo mediante teclado.

Verifica que el panel Off Canvas se abra.

Recorre los enlaces del menú.

Comprueba que puedas activarlos.

Utiliza el control de cierre para cerrar el panel.

Revisa también el comportamiento de Escape si el componente declara compatibilidad con esa interacción.

Registra las dificultades encontradas.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 05. Navegación móvil accesibleCaptura pendiente: menú Off Canvas abierto durante una prueba con teclado.

Resultado esperado:La navegación móvil puede abrirse, utilizarse y cerrarse correctamente.

Documentación oficial

Trigger — Blocksy

8. Comprobar el foco visible

Cuando utilizamos un teclado, necesitamos identificar qué elemento de la interfaz tiene el foco.

El foco puede indicarse mediante:

Un contorno.
Un cambio visual.
Un fondo.
Un subrayado.
Otro indicador perceptible.

¿Por qué es importante?

Si el foco no puede reconocerse, la persona puede perder la referencia de su posición en la página.

Dos problemas diferentes

Foco invisible: no podemos identificar el elemento seleccionado.

Foco oculto: otro elemento, como un encabezado fijo, tapa el control que recibió foco.

WCAG 2.2 contempla criterios para verificar estas situaciones.

Comprobar visibilidad y posición del foco

Abre el sitio en escritorio.

Recorre los enlaces y botones utilizando Tab.

Observa cómo aparece el foco.

Comprueba que no desaparezca al pasar por el header y el footer.

Repite la revisión en una vista móvil.

Si utilizas un encabezado fijo, comprueba que no tape completamente los controles seleccionados.

Registra los problemas encontrados.

Si una regla de estilos elimina el contorno del foco, revisa su origen antes de aplicar una corrección.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 06. Indicador de foco visibleCaptura pendiente: botón del portafolio con foco visible.

Resultado esperado:Los controles interactivos muestran un indicador de foco visible y no quedan completamente ocultos.

Documentación oficial

Focus Visible — WCAG 2.2

Focus Not Obscured — WCAG 2.2

9. Revisar títulos de página y jerarquía de encabezados

Los encabezados permiten organizar el contenido y reconocer la estructura de la página.

También ayudan a quienes utilizan tecnologías de asistencia a desplazarse entre secciones.

Encabezados HTML

Los niveles disponibles son:

Ejemplo de jerarquía

H1: Portafolio profesional UX/UI.

H2: Sobre mí.

H2: Proyectos destacados.

H3: Proyecto de aplicación móvil.

H3: Rediseño de una plataforma web.

H2: Contacto.

Recomendación importante

No debemos utilizar niveles de encabezado solamente para conseguir un tamaño visual.

El nivel debe representar la organización del contenido.

Además, las páginas deben disponer de un título de navegador que permita identificarlas.

Verificar títulos y jerarquía de encabezados

Abre una página del portafolio en Chrome.

Revisa el título que aparece en la pestaña del navegador.

Comprueba que permita identificar el contenido de la página.

Inspecciona sus principales encabezados.

Verifica que exista una jerarquía razonable.

Revisa si un bloque Encabezado de Gutenberg utiliza el nivel correspondiente.

Comprueba que los títulos visuales se hayan construido como encabezados reales cuando cumplen esa función.

Si encuentras niveles utilizados de manera incorrecta, registra la incidencia.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 07. Jerarquía de encabezadosCaptura pendiente: estructura H1, H2 y H3 de una página del portafolio.

Resultado esperado:La página presenta títulos comprensibles y una jerarquía semántica coherente.

Documentación oficial

Easy Checks: Page Title and Headings — W3C

10. Verificar enlaces y botones

Los enlaces y botones son fundamentales para la navegación.

Sus textos deben permitir comprender qué sucederá al utilizarlos.

Ejemplos

Poco descriptivo: Haz clic aquí.

Más descriptivo: Ver proyecto de diseño UX/UI.

Poco descriptivo: Más información.

Más descriptivo: Conocer los servicios de diseño.

Diferencia entre enlace y botón

Un enlace normalmente permite navegar hacia otro recurso o ubicación.

Un botón normalmente permite ejecutar una acción dentro de una interfaz.

Aunque Gutenberg utiliza el nombre Botón para sus bloques de llamadas a la acción, cuando esos elementos conducen a otra URL suelen renderizarse como enlaces.

Qué debemos comprobar

Etiqueta comprensible.
Destino correcto.
Estado de foco.
Contraste.
Funcionamiento.
Ausencia de enlaces vacíos.

Comprobar enlaces y llamadas a la acción

Recorre la página del portafolio.

Identifica sus enlaces principales.

Revisa sus textos.

Comprueba que indiquen el destino o la acción esperada.

Activa los enlaces de proyectos, contacto y navegación.

Confirma que lleguen a las páginas correctas.

Comprueba que los enlaces no estén vacíos.

Si existen botones sin función asignada, registra el problema.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 08. Verificación de enlacesCaptura pendiente: botón o enlace de proyecto con texto descriptivo y destino configurado.

Resultado esperado:Los enlaces del portafolio tienen destinos válidos y comunican su función.

Documentación oficial

Link Purpose (In Context) — WCAG 2.2

11. Revisar las imágenes y sus textos alternativos

Las imágenes de un portafolio pueden comunicar información importante.

Por ejemplo, una captura de interfaz puede mostrar el resultado de un proyecto UX/UI.

Debemos considerar cómo se comunicará esa información a las personas que no pueden percibir la imagen visualmente.

¿Qué es un texto alternativo?

Es una descripción textual que comunica la información o la función relevante de una imagen.

En HTML suele implementarse mediante el atributo alt.

Ejemplo

Imagen: interfaz de una aplicación de reservas.

Texto alternativo apropiado:

“Pantalla de reservas con calendario y selección de horarios disponibles”.

Imágenes decorativas

No todas las imágenes necesitan una descripción informativa.

Si una imagen es puramente decorativa, puede utilizar un texto alternativo vacío.

Imágenes funcionales

Si una imagen funciona como enlace y no existe otra etiqueta suficiente, su alternativa debe comunicar el destino o la función.

Recomendación

No repitas automáticamente frases como “imagen de” o “fotografía de”.

El texto alternativo debe responder al propósito de la imagen en su contexto.

Revisar los textos alternativos

Abre una página del portafolio en Gutenberg.

Selecciona una imagen de proyecto.

Revisa el campo de texto alternativo del bloque.

Comprueba que describa la información relevante.

Evita utilizar solamente el nombre del archivo.

Si la imagen es decorativa, revisa las opciones disponibles para marcarla como tal.

Repite la revisión con otras imágenes importantes.

Abre el sitio en Chrome DevTools y comprueba la información expuesta cuando sea necesario.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 09. Texto alternativo de imágenesCaptura pendiente: ajuste de texto alternativo del bloque Imagen de Gutenberg.

Resultado esperado:Puedes identificar cuáles imágenes necesitan una descripción y cuáles son decorativas.

Documentación oficial

Images Tutorial — W3C

An Alt Decision Tree — W3C

Image Block — WordPress

12. Comprobar el contraste de textos

La legibilidad depende, entre otros aspectos, del contraste entre el texto y su fondo.

Una combinación de colores puede resultar estéticamente atractiva, pero difícil de leer.

Valores de referencia para WCAG 2.2 AA

Tipo de texto	Contraste mínimo
Texto normal	4,5:1
Texto grande según WCAG	3:1

Existen excepciones específicas contempladas en el criterio.

Ejemplo

Un párrafo gris claro sobre fondo blanco puede tener un contraste insuficiente.

Un botón con texto claro sobre un fondo también claro puede resultar difícil de reconocer.

¿Dónde corregirlo?

Blocksy: colores globales, enlaces y textos generales.

Gutenberg: colores particulares de bloques y secciones.

Importante

No debemos depender únicamente de nuestra percepción visual para calcular el contraste.

Utilizaremos herramientas de inspección que permitan comprobar los valores.

Medir el contraste de los textos

Abre el portafolio en Google Chrome.

Activa Chrome DevTools.

Utiliza la herramienta de inspección para seleccionar un párrafo o enlace.

Revisa su color de texto y el fondo efectivo sobre el que aparece.

Utiliza las herramientas de contraste disponibles en Chrome para evaluar la combinación.

Compara el resultado con los valores de referencia de WCAG 2.2 AA.

Repite la revisión con:

Párrafos.
Encabezados.
Enlaces.
Botones.
Textos del footer.

Si detectas un problema, registra el elemento y sus colores.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 10. Evaluación de contrasteCaptura pendiente: comprobación del contraste de texto en Chrome DevTools.

Resultado esperado:Identificas combinaciones de texto y fondo que necesitan mejorar su contraste.

Documentación oficial

Contrast Minimum — WCAG 2.2

13. Comprobar controles e información no textual

La accesibilidad no depende solamente del contraste de los textos.

Los componentes de interfaz y los gráficos que transmiten información también necesitan ser reconocibles.

Ejemplos

Bordes de campos de formulario.
Iconos de navegación.
Indicadores de selección.
Elementos gráficos que comunican estados.
Controles necesarios para utilizar una interfaz.

Contraste no textual

WCAG 2.2 incluye el criterio de Non-text Contrast, con una referencia de 3:1 para información visual necesaria en componentes de interfaz y gráficos significativos, considerando las excepciones correspondientes.

No depender solamente del color

Imagina un formulario donde un error se indica únicamente cambiando el borde a rojo.

Algunas personas podrían no distinguir ese cambio.

Es preferible acompañarlo con una explicación visible.

Evaluar controles y señales visuales

Revisa los botones, enlaces e iconos del portafolio.

Identifica cuáles comunican información necesaria para utilizar la página.

Comprueba que se distingan visualmente de su entorno.

Revisa especialmente el Trigger del menú móvil.

Si existen campos de formulario, comprueba sus bordes y estados.

Observa si un error o estado importante se comunica únicamente por color.

Registra las situaciones que necesiten corrección.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 11. Contraste de componentesCaptura pendiente: comparación de un control poco visible con una versión de mayor contraste.

Resultado esperado:Reconoces si los controles y estados relevantes pueden identificarse de forma clara.

Documentación oficial

Non-text Contrast — WCAG 2.2

Use of Color — WCAG 2.2

14. Verificar tamaños y separación de controles

En pantallas táctiles, los elementos demasiado pequeños o cercanos pueden resultar difíciles de seleccionar.

Por ejemplo:

Dos iconos de redes sociales muy próximos.
Un botón de menú excesivamente pequeño.
Un enlace situado junto a otro control.
Botones comprimidos en el footer.

Referencia WCAG 2.2 AA

El criterio Target Size (Minimum) establece un tamaño general mínimo de 24 × 24 píxeles CSS para objetivos táctiles o de puntero, con varias excepciones, entre ellas separaciones suficientes y enlaces de texto integrados en párrafos.

Importante

No significa que todos los elementos visibles deban medir exactamente 24 × 24 píxeles.

Debemos evaluar el área interactiva real y las excepciones del criterio.

Para una mejor comodidad de uso, podemos diseñar controles mayores cuando sea apropiado.

Revisar el tamaño de los controles

Abre el sitio en una vista móvil.

Identifica los principales elementos interactivos.

Revisa el menú, botones y redes sociales.

Utiliza Chrome DevTools para inspeccionar sus dimensiones cuando sea necesario.

Comprueba el área que realmente puede seleccionarse.

Observa también la distancia respecto de otros controles.

Registra los elementos que requieran revisión.

Si puedes probar el sitio en un teléfono real, comprueba la facilidad de interacción táctil.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 12. Tamaños de controlesCaptura pendiente: inspección del área interactiva de botones e iconos en una vista móvil.

Resultado esperado:Identificas controles demasiado pequeños o próximos entre sí.

Documentación oficial

Target Size Minimum — WCAG 2.2

15. Comprobar ampliación del texto

Algunas personas necesitan ampliar considerablemente el texto para leerlo.

Por eso debemos comprobar que el sitio permita aumentar su tamaño sin perder información ni funcionalidad.

Criterio de referencia

WCAG 2.2 incluye Resize Text, que contempla aumentar el texto hasta un 200 % sin pérdida de contenido o funcionalidad, considerando las condiciones y excepciones del criterio.

Problemas que pueden aparecer

Títulos cortados.
Botones con texto oculto.
Menús superpuestos.
Tarjetas demasiado pequeñas.
Contenedores que impiden leer el contenido.

No es suficiente que el texto crezca

También debemos comprobar que siga siendo posible comprender y utilizar la página.

Probar la ampliación de texto

Abre una página del portafolio en Chrome.

Mantén una referencia de su presentación normal.

Aumenta progresivamente la ampliación del navegador hasta el 200 % para una revisión práctica inicial.

Observa cómo se reorganizan los textos y componentes.

Comprueba:

Encabezados.
Párrafos.
Botones.
Menús.
Tarjetas.
Footer.

Verifica que no desaparezca información importante.

Si encuentras un problema, registra el ancho de ventana, el nivel de zoom y el componente afectado.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 13. Prueba de ampliaciónCaptura pendiente: portafolio visualizado con ampliación y reorganización de contenido.

Resultado esperado:Identificas si la página conserva contenido y funcionalidades al ampliar el texto.

Documentación oficial

Resize Text — WCAG 2.2

16. Verificar la reorganización del contenido

La reorganización, conocida como reflow, permite que los contenidos se adapten a espacios estrechos o a niveles de ampliación altos.

WCAG incluye criterios específicos para comprobar este comportamiento.

¿Qué buscamos?

En contenido de desplazamiento vertical, queremos evitar que sea necesario desplazarse horizontal y verticalmente para leer información corriente, considerando las excepciones del criterio.

Referencia de prueba

Podemos utilizar un viewport de 320 píxeles CSS de ancho como una referencia de comprobación de reflow para contenido vertical.

Esto no significa que todos los elementos deban reorganizarse exactamente de la misma manera.

Determinados contenidos que requieren una presentación bidimensional pueden estar contemplados en las excepciones de WCAG.

Ejemplo aplicado

Tres tarjetas de proyectos pueden reorganizarse verticalmente.

Un párrafo debe conservar su legibilidad.

Los botones deben mantenerse disponibles.

Realizar una prueba de reflow

Abre la página en Chrome DevTools.

Activa el modo de dispositivos.

Configura un viewport de 320 píxeles CSS de ancho.

Recorre toda la página.

Comprueba que:

Los párrafos sean legibles.
Los títulos no se corten.
Las tarjetas se adapten.
Los botones permanezcan disponibles.
No aparezca desplazamiento horizontal injustificado.

Revisa las excepciones aplicables si existe contenido que necesita desplazamiento en dos dimensiones.

Registra los hallazgos.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 14. Reflow a 320 píxelesCaptura pendiente: página del portafolio reorganizada en un viewport estrecho.

Resultado esperado:Compruebas si el contenido principal puede leerse en una presentación estrecha sin desplazamiento horizontal innecesario.

Documentación oficial

Reflow — WCAG 2.2

17. Revisar formularios de contacto

Muchos portafolios utilizan formularios para facilitar la comunicación.

Sin embargo, un formulario puede presentar barreras de accesibilidad cuando sus campos no están identificados correctamente.

¿Qué debemos comprobar?

Etiquetas comprensibles.
Identificación de campos obligatorios.
Instrucciones claras.
Navegación por teclado.
Mensajes de error.
Confirmación de envío.
Orden lógico de los campos.

Consideración sobre WordPress

WordPress no incorpora necesariamente un formulario de contacto completo en todas sus instalaciones.

Si tu portafolio utiliza un formulario creado mediante una herramienta o plugin ya instalado, puedes realizar estas comprobaciones.

Si tu proyecto solamente utiliza un correo o enlace de contacto, registra esta prueba como No aplica.

No es necesario instalar un plugin de formularios para completar esta actividad.

Comprobar etiquetas e instrucciones del formulario

Abre la página Contacto.

Comprueba si contiene un formulario.

Si existe, revisa sus campos.

Verifica que cada campo tenga una etiqueta comprensible.

Comprueba que los campos obligatorios estén identificados.

Revisa las instrucciones.

Utiliza Tab para recorrer el formulario.

Comprueba que el orden sea lógico y que el foco sea visible.

Si no existe un formulario, registra No aplica y continúa con la siguiente comprobación.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 15. Accesibilidad del formularioCaptura pendiente: formulario de contacto con campos y etiquetas visibles.

Resultado esperado:Identificas si los campos del formulario pueden comprenderse y utilizarse.

Documentación oficial

Forms Tutorial — W3C

18. Verificar mensajes de error y confirmación

Un formulario debe comunicar claramente cuándo existe un problema.

Ejemplos de errores

Correo electrónico con formato incorrecto.
Campo obligatorio vacío.
Mensaje que supera un límite establecido.
Fallo de envío.

Recomendaciones

Un mensaje debe explicar qué ocurrió y cómo corregirlo cuando corresponda.

No debemos depender exclusivamente de un borde rojo.

La información debe poder ser comprendida por quienes utilizan tecnologías de asistencia.

Prueba segura

Realiza las pruebas en un entorno de desarrollo.

Evita enviar información personal real o mensajes innecesarios a destinatarios externos.

Comprobar errores y confirmaciones del formulario

Abre un formulario existente en el entorno de prueba.

Intenta enviarlo con un campo obligatorio vacío.

Observa el mensaje generado.

Comprueba si indica qué campo requiere atención.

Introduce un correo de prueba con formato incorrecto.

Revisa si aparece una explicación adecuada.

Comprueba que los campos puedan corregirse mediante teclado.

Si el entorno dispone de un mecanismo de envío de prueba seguro, verifica también el mensaje de confirmación.

Si no existe formulario, registra esta prueba como No aplica.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 16. Mensajes de validaciónCaptura pendiente: formulario mostrando un mensaje de error comprensible.

Resultado esperado:Puedes evaluar si el formulario comunica sus errores y resultados de manera comprensible.

Documentación oficial

Form Validation — W3C

19. Comprobar contenido multimedia y movimiento

Un portafolio puede incorporar:

Videos.
Animaciones.
Presentaciones.
Contenido en movimiento.
Interacciones visuales.

Estos recursos deben revisarse desde la perspectiva de accesibilidad.

Videos

Cuando corresponda, los videos necesitan alternativas apropiadas para su contenido, como subtítulos y otros recursos de accesibilidad.

Movimiento

Las animaciones no deben impedir comprender o utilizar la página.

Cuando exista movimiento no esencial que se active por interacciones, debemos considerar las preferencias de reducción de movimiento.

Contenido automático

No debemos asumir que una animación mejora la experiencia solamente porque resulta atractiva.

Es necesario evaluar su propósito y comportamiento.

Revisar videos y animaciones

Recorre las páginas del portafolio.

Identifica videos y animaciones.

Comprueba si los videos contienen voz u otra información sonora.

Revisa si existen subtítulos apropiados cuando sean necesarios.

Comprueba si alguna animación dificulta leer o utilizar el contenido.

Revisa si existen movimientos automáticos.

Cuando corresponda, evalúa cómo responde el sitio a la preferencia de reducir movimiento.

Si el sitio no contiene videos ni animaciones, registra No aplica.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 17. Revisión de contenido multimediaCaptura pendiente: contenido audiovisual o animado del portafolio en revisión.

Resultado esperado:Identificas contenido multimedia o movimiento que requiere medidas adicionales de accesibilidad.

Documentación oficial

Audio and Video — W3C

Animation from Interactions — WCAG 2.2

20. Realizar una auditoría automática con Lighthouse

Hasta ahora hemos realizado diferentes comprobaciones manuales.

Ahora utilizaremos Lighthouse, una herramienta de Google que permite analizar aspectos técnicos de una página.

¿Qué puede evaluar?

Lighthouse incorpora auditorías relacionadas con:

Accesibilidad.
Rendimiento.
Buenas prácticas.
SEO.

Para nuestro ejercicio prestaremos especial atención a las observaciones de accesibilidad.

¿Qué debemos comprender?

Lighthouse detecta automáticamente ciertos problemas.

Sin embargo, no puede determinar por sí solo si toda la experiencia de uso resulta accesible.

Por ejemplo, puede detectar algunos problemas de etiquetas o contraste, pero no reemplaza una revisión completa del significado de las imágenes, de la navegación o de los contenidos.

La puntuación no es una certificación

Una puntuación alta debe interpretarse como un resultado de las comprobaciones automatizadas disponibles.

No significa que todos los criterios WCAG hayan sido evaluados.

Ejecutar Lighthouse en Chrome

Abre una página del portafolio en Google Chrome.

Activa Chrome DevTools.

Busca la pestaña Lighthouse.

Si no aparece directamente, revisa las herramientas adicionales de DevTools.

Selecciona las categorías disponibles.

Para esta actividad, incluye Accessibility.

Inicia la auditoría.

Revisa el reporte generado.

Identifica las recomendaciones y los problemas detectados.

Registra sus resultados en la matriz de verificación.

No consideres que la ausencia de advertencias demuestra una conformidad completa con WCAG.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 18. Auditoría LighthouseCaptura pendiente: reporte Lighthouse con la categoría Accessibility.

Resultado esperado:Obtienes un reporte automático y puedes identificar incidencias que necesitan revisión.

Documentación oficial

Introduction to Lighthouse — Chrome for Developers

21. Revisar rendimiento básico

La experiencia de usuario también puede verse afectada por el tiempo de carga y el tamaño de los recursos.

Nuestro objetivo no será realizar una optimización avanzada, sino identificar problemas evidentes.

Aspectos que podemos revisar

Imágenes excesivamente grandes.
Archivos que no corresponden al tamaño necesario.
Recursos cargados innecesariamente.
Videos demasiado pesados.
Elementos que dificultan la carga inicial.

Ejemplo

Si una tarjeta muestra una imagen pequeña, pero WordPress carga un archivo mucho mayor de lo necesario, puede existir una oportunidad de optimización.

Debemos revisar las opciones de resolución e imagen proporcionadas por WordPress.

Cuidado

No debemos reducir tanto la calidad de una imagen que se vuelva ilegible.

En un portafolio UX/UI, las capturas de proyectos necesitan conservar los detalles visuales relevantes.

Identificar problemas básicos de rendimiento

Abre la página del portafolio.

Utiliza Lighthouse para revisar los hallazgos relacionados con rendimiento.

También puedes explorar el panel Network de Chrome DevTools.

Identifica recursos de gran tamaño.

Revisa especialmente las imágenes utilizadas en:

Hero.
Tarjetas de proyectos.
Galerías.
Secciones visuales.

Comprueba si la resolución utilizada corresponde al propósito de cada imagen.

Registra las oportunidades de mejora.

No modifiques los archivos originales sin conservar una referencia adecuada.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 19. Revisión de recursosCaptura pendiente: panel Network o informe Lighthouse con recursos de la página.

Resultado esperado:Reconoces recursos que podrían optimizarse sin comprometer el contenido visual.

Documentación oficial

Network Features Reference — Chrome DevTools

22. Elaborar la matriz final de verificación

Al terminar las pruebas necesitamos organizar los resultados.

La matriz permitirá identificar cuáles aspectos están correctos, cuáles necesitan corrección y cuáles no aplican al proyecto.

Modelo de tabla

ID	Comprobación	Resultado	Observación
V01	Diseño móvil	Correcto	Sin desbordamientos detectados
V02	Navegación por teclado	Incidencia	Foco poco visible
V03	Textos alternativos	Correcto	Imágenes revisadas
V04	Contraste	Pendiente	Revisar botones
V05	Formularios	No aplica	No existe formulario

Los resultados son ilustrativos y no describen el estado real del proyecto.

Prioridad de las incidencias

Podemos utilizar:

Alta: impide utilizar funciones importantes o acceder a contenido.

Media: genera dificultades significativas de lectura o navegación.

Baja: requiere un ajuste menor que no bloquea las tareas principales.

¿Cuándo damos por resuelta una incidencia?

Cuando:

Identificamos el problema.
Confirmamos su causa.
Aplicamos una corrección.
Repetimos la prueba.
Registramos el resultado.

No basta con modificar una configuración y asumir que el problema desapareció.

Completar el informe final de verificación

Abre la matriz de verificación preparada al inicio.

Revisa cada comprobación realizada.

Registra su resultado:

Correcto.
Incidencia.
No aplica.
Pendiente.

Cuando exista una incidencia, agrega:

Página afectada.
Descripción del problema.
Prioridad.
Herramienta utilizada.
Evidencia.
Recomendación de corrección.

Si realizaste una corrección, incluye el resultado de la nueva prueba.

Revisa que las evidencias correspondan a la página y al dispositivo registrado.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 20. Matriz final de verificaciónCaptura pendiente: tabla final con comprobaciones, estados e incidencias.

Resultado esperado:Dispones de un registro documentado de las pruebas, resultados y problemas pendientes.

23. Errores frecuentes durante la verificación

Revisar solamente la página Inicio

Problema: otras páginas pueden presentar incidencias diferentes.

Recomendación: seleccionar varias páginas representativas del portafolio.

Probar únicamente con mouse

Problema: podemos pasar por alto barreras que afectan la navegación mediante teclado.

Recomendación: realizar recorridos completos utilizando Tab, Shift + Tab y las teclas de activación correspondientes.

Considerar Lighthouse como una certificación

Problema: una herramienta automática no identifica todos los problemas de accesibilidad.

Recomendación: combinar sus resultados con pruebas manuales y referencias WCAG.

Utilizar textos alternativos genéricos

Problema: frases como “imagen de proyecto” pueden comunicar poca información.

Recomendación: describir el contenido o función relevante según el contexto.

Omitir la comprobación móvil

Problema: algunos problemas aparecen solamente en pantallas estrechas.

Recomendación: revisar distintos tamaños y configuraciones.

Modificar muchos elementos durante la revisión

Problema: podemos perder la referencia del problema original.

Recomendación: registrar primero y corregir cada incidencia de manera controlada.

No volver a verificar después de una corrección

Problema: una modificación puede solucionar un problema y generar otro.

Recomendación: repetir la comprobación y revisar también otras pantallas.

24. Actividad práctica 3.3 — Auditoría final del portafolio

Objetivo

Realizar una revisión práctica del portafolio UX/UI para identificar problemas de accesibilidad, navegación y presentación responsiva.

Parte A. Seleccionar las páginas

Elige las páginas representativas del proyecto.

Como referencia:

Inicio.
Sobre mí.
Proyectos.
Un proyecto individual.
Contacto.

Parte B. Realizar pruebas manuales

Comprueba:

Diseño responsivo.
Navegación por teclado.
Menú móvil.
Foco visible.
Jerarquía de encabezados.
Enlaces.
Imágenes y textos alternativos.
Contraste.
Tamaño de controles.
Ampliación y reflow.

Si existen formularios o contenido multimedia, incorpora las pruebas correspondientes.

Parte C. Ejecutar Lighthouse

Realiza una auditoría automática en una o más páginas representativas.

Registra los problemas detectados.

Diferencia claramente los resultados automáticos de las observaciones manuales.

Parte D. Clasificar las incidencias

Utiliza una matriz como la siguiente:

Comprobación	Página	Resultado	Prioridad	Acción
Navegación por teclado	Completar	Completar	Completar	Completar
Contraste	Completar	Completar	Completar	Completar
Textos alternativos	Completar	Completar	Completar	Completar
Reflow	Completar	Completar	Completar	Completar
Menú móvil	Completar	Completar	Completar	Completar

Parte E. Corregir y volver a comprobar

Selecciona las incidencias más importantes.

Utiliza las herramientas aprendidas:

Blocksy.
Gutenberg.
Chrome DevTools.

Aplica las correcciones necesarias.

Después repite las pruebas afectadas.

Parte F. Elaborar un informe breve

El informe debe contener:

1. Alcance

Páginas revisadas y entorno de prueba.

2. Herramientas

Navegador, DevTools, Lighthouse y WordPress.

3. Metodología

Pruebas realizadas y criterios utilizados.

4. Resultados

Tabla con comprobaciones e incidencias.

5. Correcciones

Cambios aplicados y evidencias.

6. Conclusión

Principales mejoras realizadas y aspectos pendientes.

Resultado esperado

Un portafolio con verificaciones documentadas, incidencias priorizadas y mejoras justificadas.

Importante

Esta actividad forma parte del proceso formativo de la Unidad III.

Los criterios de calificación y los entregables oficiales deben consultarse en la pauta académica correspondiente.

25. Lista de verificación

Lista de verificación

Marca las actividades que hayas completado.

Tu progreso0 de 20 completados

26. Documentación oficial

Las siguientes referencias permiten profundizar en cada área de verificación.

Cierre de la Semana 12

Con este tutorial completamos la secuencia de aprendizaje sobre diseño responsivo con WordPress, Blocksy y Gutenberg.

Durante el proceso aprendimos a:

Comprender las herramientas del ecosistema WordPress.
Configurar y utilizar Blocksy.
Analizar el comportamiento responsivo.
Diagnosticar problemas mediante Chrome DevTools.
Definir configuraciones visuales globales.
Construir encabezados y pies de página responsivos.
Organizar contenido utilizando Gutenberg.
Corregir diferencias entre Figma y WordPress.
Realizar verificaciones básicas de accesibilidad y funcionamiento.

El resultado de esta etapa es un portafolio profesional UX/UI más consistente, adaptable y preparado para continuar con nuevas mejoras.

Recuerda: el desarrollo web es un proceso iterativo. Un sitio puede seguir evolucionando a partir de las observaciones de sus usuarios y de nuevas pruebas técnicas.