Quick answer
No pregunte si el rediseño se ve listo. Pregunte si cada bloqueador de lanzamiento tiene evidencia verificable, un propietario y una ruta de retroceso o monitoreo. La velocidad es valiosa sólo cuando la liberación permanece observable y reversible.
Last reviewed: 2026-10-09T18:16:03.273Z35-point redesign launch checklist
Progress is stored only in this browser. “Complete” means you have the evidence named in the row—not that someone remembers checking it.
1. Overall completion donut
Takeaway: launch confidence depends on evidence-backed completion, especially blockers.
2. Category progress bars
Takeaway: uneven category progress exposes handoff gaps before launch.
3. Severity × completion heatmap
Takeaway: unresolved blockers deserve attention before medium-priority polish.
| Status | Check | Category | Severity | Owner | Evidence of done | Recheck cadence |
|---|---|---|---|---|---|---|
| Map every changed URL to an intentional destination | SEO | Blocker | SEO + Engineering | Exported redirect map + sampled 301 tests | Launch + after URL changes | |
| Validate self-canonicals and intentional cross-canonicals | SEO | Blocker | SEO + Engineering | Crawler export showing canonical target/status | Launch + monthly | |
| Remove staging/noindex/robots blocks from production scope | Critical | Blocker | Engineering + SEO | Production robots.txt + meta/X-Robots audit | Launch | |
| Regenerate sitemap with only canonical indexable URLs | SEO | High | SEO + Engineering | Sitemap fetch + URL sample | Launch + automated | |
| Verify analytics loads on production and excludes internal/test traffic where configured | Analytics | Blocker | Data + Marketing | Realtime/debug event screenshot | Launch + monthly | |
| Test primary lead/purchase conversion events end to end | Analytics | Blocker | Data + Marketing | Test conversion IDs and destination records | Launch + monthly | |
| Confirm consent mode / cookie controls match the deployed trackers | Security | High | Legal/Privacy + Engineering | Consent-state network test | Launch + tracker changes | |
| Submit every business-critical form and verify routing/validation | UX | Blocker | QA + Marketing | Successful test submissions in destination | Launch + release | |
| Complete checkout or equivalent money path on production/safe test mode | Critical | Blocker | QA + Engineering | Recorded test transaction/order | Launch + release | |
| Test sign-in, password reset and protected-route behavior where applicable | Security | High | Engineering + QA | Test account flow recording | Launch + auth changes | |
| Verify custom 404, removed URL behavior and no soft-404 regressions | SEO | High | SEO + Engineering | Known-missing URL response + rendered page | Launch | |
| Check important pages return intended HTTP status codes | Technical | Blocker | Engineering + SEO | Crawler status-code export | Launch + monthly | |
| Test navigation, menus and sticky UI on small mobile viewport | UX | High | Design + QA | 390px browser screenshots | Launch + navigation changes | |
| Check layouts at common mobile/tablet/desktop breakpoints | UX | High | Design + QA | Breakpoint QA matrix | Launch + component changes | |
| Complete critical paths with keyboard only | UX | High | QA + Design | Keyboard walkthrough notes | Launch + interaction changes | |
| Confirm visible focus states and logical focus order | UX | High | Design + Engineering | Focus-state screenshots | Launch | |
| Verify form labels, errors and accessible names | UX | High | QA + Engineering | Accessibility audit + manual sample | Launch | |
| Review meaningful image alt text and decorative-image handling | Content | Medium | Content + QA | CMS/export spot check | Launch + content publishing | |
| Validate page H1/H2 hierarchy and avoid heading-as-decoration | Content | Medium | Content + SEO | Heading outline sample | Launch | |
| Confirm unique titles and descriptions for priority pages | SEO | High | SEO + Content | Crawler metadata export | Launch + quarterly | |
| Validate structured data matches visible page content | SEO | High | SEO + Engineering | JSON-LD parse + rich result/schema validator | Launch + template changes | |
| Test social share title, description and image | Content | Medium | Marketing | Share-debug preview | Launch | |
| Check LCP on representative high-traffic templates | Technical | High | Engineering | Field/lab report with tested URL | Launch + monthly | |
| Check interaction responsiveness and heavy client work | Technical | High | Engineering | Performance trace / field report | Launch + monthly | |
| Check layout stability for images, embeds, banners and fonts | Technical | High | Engineering | Performance trace with shift sources | Launch + monthly | |
| Verify responsive image sizing, modern formats and dimensions | Technical | Medium | Engineering + Design | Network/image audit | Launch + template changes | |
| Check font loading, fallback behavior and unused weights | Technical | Medium | Engineering + Design | Network waterfall | Launch | |
| Review security headers appropriate to the stack | Security | High | Engineering + Security | Header capture/scanner result | Launch + infrastructure changes | |
| Confirm HTTPS, mixed-content absence and certificate validity | Security | Blocker | Engineering | TLS/browser network test | Launch + certificate automation | |
| Reconcile final approved content against production | Content | High | Content + Marketing | Signed-off page inventory | Launch | |
| Check priority internal links and navigation targets | SEO | High | SEO + Content | Broken-link crawl + priority path sample | Launch + monthly | |
| Test onsite search/filtering if present | UX | Medium | QA + Product | Query test set | Launch + search changes | |
| Configure uptime/error monitoring and alert ownership | Technical | High | Engineering | Monitor dashboard + test alert | Launch + quarterly drill | |
| Document CMS publishing, rollback and incident owners | Critical | High | Product + Engineering | Handoff/runbook link | Launch + ownership changes | |
| Schedule 7/14/30-day traffic, errors, rankings and conversion review | Analytics | High | Marketing + SEO + Data | Calendar/report owner + baseline snapshot | Post-launch |
Source/assumption note: the checklist is a WebDesignK operational launch framework. Google redirect and Core Web Vitals guidance cited below support specific SEO/performance checks; your stack and regulatory context may require additional controls.
Tables built for the buying decision
Primary decision table
| Inicio de dominio | ¿Qué puede fallar? | Pruebas requeridas | Propietario | Puerta |
|---|---|---|---|---|
| Búsqueda/indexación | URLs modificadas, canónicas, robots, mapa del sitio | Exportación de Crawler + respuestas de producción de muestras | SEO + Ingeniería | Bloqueo si no se resuelve |
| Conversión | Formularios, checkout, auth | Pruebas exitosas de producción a fin | QA + Marketing/Producto | Bloquear si falla el camino de ingresos/carretera |
| Medición | Eventos de análisis y conversión | Eventos en tiempo real/debug en destino | Datos + Marketing | Bloqueo si las decisiones se quedan ciegas |
| Experiencia | Móvil, teclado, enfoque, diseño sensible | 390px capturas de pantalla + guía de teclado | Diseño + QA | Severidad alta |
| Operaciones | Vigilancia, reversión, propiedad | Runbook + alerta de prueba + desplegar SHA | Ingeniería/Producto | Bloqueo si no hay ruta de recuperación |
Remarque cadencia por tipo de control
| Control | En el lanzamiento | Cadencia recurrente | Trigger para la revisión inmediata |
|---|---|---|---|
| Redirectos/canónicos | Arrastre completo | Muestra mensual | URL/templa migración |
| Conversiones básicas | Final a final | Mensual / lanzamiento | Cambio de integración de formularios/salida |
| Ejecución | Plantillas representativas | Examen mensual del terreno | Cambio de media/script/templato |
| Seguridad y privación de libertad | Examen de la producción | Trimestralmente/de base normativa | Nuevo procesador, austeridad o infraestructura |
| Análisis | Depuración + destino | Mensual | Cambio de etiqueta/consentimiento/CRM |
Turn this planning result into a scoped review.
Send the assumptions, constraints and result summary. WebDesignK can review the architecture/content/implementation boundary, identify missing discovery inputs and return a prioritized next-step scope.
- Bring: current site/product, constraints, integrations and your tool result.
- You get: a scoped recommendation, open questions and implementation priorities.
Foto de la decisión: tratar un rediseño como una migración controlada, no un lanzamiento visual
Un rediseño de sitios web es más seguro cuando el equipo puede probar lo que cambió, quién posee cada riesgo, y cómo la nueva experiencia de producción preserva las rutas de búsqueda, medición y conversión. La decisión de lanzamiento no debe ser “¿se ve terminada?” Debe ser “¿podemos mostrar evidencia de que cada bloqueador está controlado, cada URL importante tiene un resultado intencional, y cada ruta crítica del cliente funciona en la producción?” El mayor tradeoff es la velocidad versus la reversibilidad: cuanto más rápido se lanza sin evidencia, más caro se convierte en diagnosticar tráfico, datos o pérdida de ingresos después del hecho.
Lo que decidirá: qué cheques pueden bloquear el lanzamiento, qué propietario debe proporcionar evidencia, qué controles son una vez contra recurrente, y qué debe ser observado durante 30 días después de la liberación.
Cómo utilizar la lista de verificación y definir “hacho”
Comience convirtiendo la lista de verificación en un artefacto de liberación compartido, no una nota privada de QA. Cada fila tiene un propietario, gravedad, campo de evidencia y reprueba cadencia. “Done” significa que existe la evidencia nombrada y otra persona puede inspeccionarla. Para una redireccion, eso podría ser una exportación de rastreadores más las solicitudes de producción de muestras. Para la analítica, no es suficiente ver una etiqueta de script; probar que el evento esperado llega al destino con los parámetros esperados. Para un formulario, envíelo y verifique el plomo aparece donde las operaciones realmente lo procesarán.
La lista de verificación interactiva anterior almacena progreso localmente para que un revisor pueda filtrar bloqueadores de lanzamiento, marcar una categoría completa después de que se revise la evidencia, copiar un resumen de estado e imprimir/exportar la página para un desvío. Los gráficos de progreso utilizan deliberadamente sólo el estado de lista de verificación; no pretenden que un porcentaje por sí solo equivale a la preparación de lanzamiento. Un sitio al 95% puede ser inseguro si el 5% restante contiene indización, pagos o bloqueadores de medición.
Utilizar pruebas como unidad de terminación
Las imágenes son útiles cuando el requisito es visual, pero prefieren las pruebas legibles de máquina cuando sea posible: exportaciones de rastreadores, trazas de red, respuestas HTTP, IDs de orden de prueba, eventos de depuración analítica, alertas de monitoreo y registros de implementación. Almacene enlaces a esos artefactos en el ticket de liberación o el runbook para que las investigaciones posteriores al lanzamiento no dependan de la memoria.
Comprobaciones de preluz crítica
Preflight es donde se detienen los errores irreversibles o de alto costo antes de que el tráfico llegue a la nueva pila. Confirme el nombre de host de producción, certificado, variables ambientales, directivas de robots, host canónico, sitemap endpoint y comportamiento redireccionado. Si el rediseño cambia la estructura URL, construye el mapa redireccionado del inventario de producción antiguo, no de lo que el nuevo CMS sabe. Los documentos de Google se redirige como el mecanismo para señalar que una URL se ha movido; por eso la planificación redireccionada pertenece a la trayectoria crítica en lugar de en una huella de limpieza.
Prueba las rutas críticas de negocios utilizando datos y permisos similares a la producción. Si el sitio vende, ejecute una compra segura o una salida de extremo a extremo en el modo de prueba disponible. Si genera leads, envíe cada formulario de alto valor y compruebe el destino de CRM, correo electrónico o webhook de abajo. Si la autenticación importa, haga ejercicio de entrada, reajuste y rutas protegidas. Un hermoso lanzamiento que lleva silenciosamente es un lanzamiento fallido.
Define una puerta de lanzamiento, no un estado de ánimo de lanzamiento
Una puerta práctica dice: todos los bloqueadores completan; artículos de alta perseverancia sin resolver han nombrado propietarios y riesgo aceptado; pasos de retroceso se documentan; monitoreo es activo; y las personas que pueden aprobar una decisión de go/no-go están presentes. Esto hace visible la urgencia sin esconder el riesgo.
Verificación de la estrategia y el contenido
Un rediseño a menudo falla estratégicamente cuando el nuevo sistema visual naves, pero la arquitectura de la información pierde las razones por las que vino la gente. Compare el nuevo inventario de página con las viejas páginas de aterrizaje orgánicas, las páginas de aterrizaje pagadas, las URL de habilitación de ventas y los destinos de soporte al cliente. Tomar una decisión explícita para cada página de alto valor: preservar, consolidar, redirigir, reemplazar o retirar. Evite “recrear eso más tarde” para páginas que actualmente adquieren tráfico calificado.
Compruebe si la nueva navegación refleja las tareas reales de los compradores en lugar de los nombres de los departamentos internos. Validar la intención de nivel de página: cada página importante debe tener una audiencia primaria, trabajo a hacer, evidencia establecida y próxima acción. Luego reconciliar la copia aprobada final contra la producción. Las ediciones CMS tardías son una fuente común de secciones desaparecidas, reclamaciones de estatura y contenido accidental de marcadores de posición.
Proteger la prueba y el contexto comercial
Preserve evidencia de caso, limitaciones de producto, clasificadores de precios, atribución de autor y responsabilidades legales que llevan significado. Un rediseño debe mejorar la presentación sin eliminar la prueba que hizo creíble la antigua página.
UX y cheques de conversión
Mobile QA debe ser real, no inferido desde una vista previa de escritorio sensible. Prueba en un mirador estrecho como 390px, inspeccionar elementos pegajosos, menús, acordeones, tablas, modales y teclados de forma, y asegúrese de que nada crea el flujo de página horizontal. Completar la ruta de conversión primaria con teclado solamente y verificar el enfoque visible, orden lógico, etiquetas de formulario y manejo de errores. El trabajo de accesibilidad no es una sola puntuación automatizada; la herramienta automatizada es un filtro rápido, mientras que el teclado, el enfoque, la semántica y el contenido requieren controles manuales.
Conversión QA debe verificar la intención así como la mecánica. Confirme el CTA principal en cada plantilla de alta intención conduce al destino esperado, lleva el contexto necesario y no se obsesiona con banners de cookies, la navegación pegajosa o capas de animación. En cuanto a formularios, éxito de prueba, fallo, estados requeridos, entrada inválida, comportamiento de red lento y protección de la presentación duplicada cuando sea relevante.
Ver las regresiones específicas para el diseño
Nuevos sistemas de animación pueden ocultar contenido, crear bloques gigantes invisibles o interacciones de demora. Verificar contenido importante se hace visiblemente antes de depender de observadores de intersección o efectos de movimiento. Un componente existente en el DOM no es evidencia de que un visitante móvil pueda verlo.
Comprobaciones técnicas y de rendimiento
Utilice plantillas representativas en lugar de una puntuación de página principal. Prueba una página de aterrizaje pesada, un artículo, un formulario de conversión, una página de producto/detalles cuando sea aplicable y cualquier plantilla que use interacciones con el corazón cliente. Los Vitales Web Core se centran en LCP, INP y CLS; utilizan datos de campo donde se encuentran disponibles y rastros de laboratorio para identificar causas concretas. El objetivo no es perseguir un número de vanidad, es prevenir las regresiones causadas por medios de comunicación sobredimensionados, bloquear los scripts, trabajar de hidratación, trazado inestable o etiquetas de terceros.
Inspeccione las dimensiones de la imagen, sensiblesrcsetcomportamiento, carga perezosa debajo del pliegue, solicitudes de fuentes y pesos no utilizados. Confirme los encabezados de caché y la compresión en activos estáticos. Verifique la consola y fallas de red después de navegar a través de páginas importantes, no sólo en la primera carga.
Comportamiento de falla validada
Solicitar URLs desaparecidas conocidas, contenido vencido y combinaciones de consulta malformadas. El sistema debe devolver códigos de estado intencionales y una experiencia útil en lugar de una página blanda 404, en blanco o una excepción sin manipular.
Controles de SEO y indexación
Estadificación y producción de arrastre por separado, luego compare. Las comprobaciones prioritarias incluyen códigos de estado, objetivos canónicos, indexabilidad, títulos, meta descripciones, epígrafes, membresía de mapas, enlaces internos y destinos redireccionados. Quitar el estancamientonoindexo robots bloquean sólo cuando la liberación de producción está lista; no "fix" indexación abriendo un nombre de host en el escenario a los motores de búsqueda.
Para URLs modificadas, evite reglas de redireccionamiento amplias que envían muchas páginas no relacionadas a la página principal. Preservar equivalencia tópica cuando existe un reemplazo relevante. Compruebe que las URL canónicas resuelven directamente sin cadenas redireccionables y que las entradas de mapa de sitio coinciden con el host canónico. Los datos estructurados deben describir el contenido visible; no deje atrás FAQ o marcación de producto después de que se removió la sección visible.
Establecer una base de referencia antes/después
Exportar las importantes páginas de aterrizaje orgánico del sitio antiguo, grupos de consulta y URL indexadas antes del lanzamiento. Después del lanzamiento, compare la cobertura, clics y comportamiento de rastreo contra esa base de referencia. Esto convierte “SEO parece abajo” en un conjunto de cambios de nivel de página diagnosticable.
Controles de análisis y medición
Tratar la medición como dependencia de productos. Enumerar las decisiones que el equipo espera que la analítica apoye —volúmenes de carga, conversión calificada, terminación de la comprobación, uso de características, atribución de la campaña— y luego probar los eventos necesarios para esas decisiones. Verifique los nombres de eventos, parámetros, estado de consentimiento y recepción de destino. Una etiqueta disparando en el navegador pero ser descartado o malclasificado aguas abajo no es completo.
Cree un marcador de lanzamiento o de lanzamiento y capture una línea de referencia pre-lanzamiento para el tráfico, conversiones y tasas de error. Mantenga una lista corta de métricas que deben moverse inmediatamente debido al despliegue y métricas que no deben interpretarse demasiado rápido. Los ciclos de búsqueda y ventas orgánicos pueden disminuir; los picos de error y las conversiones rotas no deben.
Controles de seguridad, accesibilidad y cumplimiento
Revise HTTPS y contenido mixto, importantes cabeceras de seguridad, flujos de autenticación, secretos/configuración de entorno y scripts de terceros. Los requisitos de seguridad difieren por la pila y el perfil de riesgo, por lo que la lista de verificación es un punto de partida, no un sustituto de una revisión de seguridad calificada. Si el rediseño añade nuevos procesadores, embeds, herramientas de análisis o marketing, asegúrese de que la implementación de privacidad/consentimiento y las revelaciones reflejen lo que la producción realmente carga.
Para la accesibilidad, valide la estructura semántica, etiquetas, nombres, enfoque, uso del teclado, zoom/reflujo y texto alternativo significativo. WCAG 2.2 es la Recomendación W3C actual que se hace referencia a continuación; la pregunta de lanzamiento práctico es si las personas pueden completar tareas clave con restricciones de asistencia, no si una sola herramienta produjo una placa verde.
Lanzamiento y validación de la entrega
Una liberación es incompleta hasta que alguien pueda operarla mañana. Documento CMS publicación, reversión, propiedad de dominios/DNS, monitoreo, respaldos, servicios de terceros y contactos de emergencia. Dar a los equipos de marketing y contenidos una guía corta “publicación segura”: requisitos de imagen, reglas de encabezado, prácticas de enlace, componentes reutilizables y qué cambios requieren revisión de ingeniería.
Ejecute la prueba final de humo contra el verdadero nombre de host público después de su despliegue. Verifique que las secciones autor/herramienta/cart/table de hecho se desplacen en el móvil, no sólo localhost. Capturar la versión SHA, URL de producción y evidencia QA crítica en el asunto antes de cerrarla.
Vigilancia post-lanzamiento de 30 días
Planifique el primer mes antes del lanzamiento. El primer día es para disponibilidad, errores, conversiones, indexabilidad y fallos de redireccionamiento importantes. La primera semana es para el comportamiento de las páginas de aterrizaje orgánicas, la calidad de la forma, las regresiones de la velocidad de página y el apoyo a la retroalimentación. Alrededor de los días 14 y 30, compare la base acordada: clics de búsqueda, importantes clasificaciones/familias de compras, conversiones, ingresos o tubería calificada, tasas de error y participación de nivel de página donde esas métricas son realmente útiles.
No responda a cada pequeña fluctuación cambiando el sitio de nuevo. Use umbrales y evidencias de nivel de página. Fijar fallos duros inmediatamente, investigar desviaciones persistentes y mantener un registro de decisiones para los cambios realizados durante la ventana de monitoreo. Eso le da al equipo una historia causal limpia en lugar de apilar el rediseño, SEO y cambios de contenido encima de uno al otro.
Construye un paquete de liberación que sobrevive a la entrega
Un paquete de lanzamiento de rediseño útil debe contener más que una captura de pantalla de lista de verificación. Adjuntar el inventario final de URL, redireccionar mapa, comparación de los rastreos, mapa de eventos analíticos, pruebas de prueba de ritmo crítico, lista de riesgo conocido, notas de rebote y propietarios de monitoreo. Mantenga el paquete en el mismo sistema donde se rastrea el despliegue para que la ingeniería, marketing y SEO puedan encontrar la evidencia exacta después de que la reunión de lanzamiento termine. Si un tercero posee parte de la pila, registra contactos de escalada y el límite entre lo que su equipo puede arreglar directamente y lo que requiere soporte para proveedores.
El paquete de liberación también crea una línea limpia entre defectos de lanzamiento y trabajo de optimización posterior. Un defecto es una forma de redireccionamiento, fracturada o componente móvil invisible. Un nuevo experimento de titularidad o una jerarquía revisada de CTA es la optimización. Mezclando los dos hace más difícil la respuesta de incidentes porque los equipos no pueden saber si un cambio de conversión vino del rediseño en sí o de experimentos añadidos durante la estabilización.
Tratar la producción como un entorno diferente, no una copia de estadificación
El apilamiento puede probar el diseño y el comportamiento de la aplicación, pero rara vez reproduce cada dependencia de producción. El nombre de host público tiene DNS real, reglas CDN, ajustes de consentimiento, etiquetas de terceros, credenciales de producción, comportamiento de caché, puntos finales de pago y exposición de Search-engine. Ejecutar una verificación de producción corta pero deliberada después del despliegue. Esto incluye la URL canónica real, certificado, comportamiento redireccionado, formas críticas, recibo de analítica, robots/indexabilidad, renderización móvil y monitoreo. El control de producción es donde las diferencias de entorno ocultas superficiales.
Para cambios de alto riesgo, definir un patrón de liberación reversible. Los mecanismos de rebobinado de imagen azul/verde, canario o rápido difieren por la pila, pero el principio es el mismo: conoce el comando exacto o artefacto de despliegue que restaura la versión conocida-buena anterior. Un plan de reversión que existe sólo como “podemos redistribuir el código antiguo” es incompleto si nadie conoce la imagen anterior, compatibilidad de la base de datos o quién tiene acceso a ejecutarla.
Decide qué no arreglar antes del lanzamiento
Una puerta de lanzamiento disciplinada no significa que cada imperfección de la prioridad media debe bloquear la liberación. Defectos separados que amenazan la adquisición, los ingresos, la accesibilidad, la seguridad o la observabilidad del pulido que se puede programar. Documento aceptado riesgo con un propietario y fecha de destino. Esto impide que el plazo de trabajo sea “no importante” y que los detalles de estilo de bajo impacto impidan retrasar un lanzamiento seguro.
Preguntas frecuentes
¿Cuál es el cheque de rediseño más importante del sitio web?
No hay un único cheque universal, pero el manejo de URL cambiado, la indexabilidad de la producción, las rutas de conversión de núcleo y la medición son bloqueadores de lanzamiento comunes porque los fallos pueden causar tráfico inmediato o pérdida de ingresos.
¿Debería redirigir cada URL vieja?
No. URLs redirigidas que se movieron o tienen un reemplazo relevante. El contenido eliminado sin un destino equivalente puede necesitar una respuesta adecuada 404/410 en lugar de una redirección irrelevante.
¿Cuánto tiempo debe continuar la vigilancia post-lanzamiento?
Utilice un control intensivo inmediatamente después del lanzamiento y compare las bases de referencia acordadas a través de al menos los primeros 30 días; controles recurrentes como el tiempo de trabajo, análisis y rendimiento continúan más allá de eso.
¿Puede QA automatizado reemplazar los controles manuales de movilidad y accesibilidad?
No. La automatización es útil para la amplitud, pero los caminos críticos, el comportamiento del teclado, el enfoque, la distribución visual, el consentimiento y los resultados empresariales necesitan verificación manual.
Sources and assumption boundaries
Fast-changing platform, pricing and search claims were reviewed on 2026-10-09T18:16:03.273Z. Interactive scores and scenarios are clearly labeled planning models, not sourced market benchmarks.
- Google Search Central - Redes y búsqueda de Google Orientación oficial de redireccionamiento; revisado 16 de septiembre de 2026.
- web.dev — umbrales de la Web básica Google/web.dev explicación de los umbrales LCP, INP y CLS; revisado 16 de septiembre de 2026.
- W3C — Directrices de accesibilidad del contenido web (WCAG) 2.2 W3C Recomendación sobre requisitos de accesibilidad; revisado 16 de septiembre de 2026.
