Cómo llegan las correcciones de accesibilidad a un tema de Shopify, Shopware, WooCommerce o Magento

Cuando el fallo lo produce el tema, la corrección va en el archivo que genera el marcado, el estilo o el texto defectuoso: una plantilla, una hoja de estilos, un script o un archivo de traducción del tema de la tienda. Cada plataforma guarda esos archivos con su propia estructura y su propio lenguaje de plantillas, así que el mismo fallo, por ejemplo un botón sin nombre, puede estar en un archivo Liquid en Shopify, en un archivo Twig en Shopware, en un archivo PHP en WooCommerce y en un archivo .phtml en Magento.

Una corrección en el tema cambia el código que sirve la propia tienda. Un desarrollador puede leerla como un diff antes de que salga a producción y revertirla como cualquier otro cambio del código. Un overlay de accesibilidad es distinto: es un script que cambia las páginas de la tienda en el navegador del visitante, mientras que el tema queda como estaba, salvo la referencia que carga el script. Qué cambian los overlays y qué dejan como estaba

Una actualización del tema puede deshacer una corrección de accesibilidad cuando la corrección está en un archivo que la actualización reemplaza o cuando la actualización no puede trasladar la edición, y en algunas plataformas otros cambios pueden ocultar una corrección. Las plataformas lo documentan de maneras distintas.

• WooCommerce. Los cambios hechos directamente en un plugin o en un tema padre «desaparecerán cuando el plugin o el tema se actualice; un proceso que elimina por completo la versión anterior y la sustituye por una copia nueva y actualizada» (WooCommerce sobre la estructura de plantillas). WooCommerce recomienda en su lugar un tema hijo con plantillas que sobrescriben las originales. Esas plantillas no se actualizan cuando se actualizan las plantillas del núcleo de WooCommerce, y el informe «Estado del sistema» de WooCommerce puede mostrar un aviso de que una de ellas está desactualizada.
• Temas de bloques de WordPress. Una plantilla que alguien ha modificado en el Editor del sitio se guarda en la base de datos del sitio y tiene prioridad sobre los archivos de plantilla del tema y de un tema hijo (el Theme Handbook de WordPress sobre las plantillas y sobre la jerarquía de plantillas). Una corrección en el archivo de una plantilla así no es entonces lo que ven los visitantes.
• Magento Open Source y Adobe Commerce. Adobe «recomienda encarecidamente» no modificar los archivos de los temas Luma y Blank ni las plantillas predeterminadas, porque las actualizaciones de versión pueden sobrescribirlos (Adobe sobre los temas, Adobe sobre las plantillas). El lugar que Adobe recomienda para los cambios es un tema personalizado, que puede heredar de Luma o de Blank.
• Shopware 6. Un tema que hereda de un tema comprado deja intacto el código de ese tema, como se ha descrito más arriba. Shopware advierte de que un tema que sobrescribe variables de un tema de terceros puede dejar de compilarse si ese tema cambia más tarde el nombre de esas variables o las elimina (Shopware sobre la configuración de temas).
• Shopify. El Centro de ayuda de Shopify sobre la actualización de temas dice que las ediciones de código que no entran en conflicto con una actualización del tema se trasladan a la copia actualizada. Si son incompatibles con la actualización, se eliminan todos los cambios de código de la copia actualizada, y conservarlos significa copiarlos a la nueva versión. La actualización llega como un tema en borrador cuyo nombre empieza por «Updated copy of».

Las correcciones de Validiscan son ediciones de los archivos del código fuente del tema que recibe. Cuál es ese código fuente, el tema en uso, su tema hijo o un tema que hereda, es por tanto una pregunta para el desarrollador de la tienda antes de empezar el trabajo. Cuando un tema de WooCommerce llega a Validiscan como ZIP, el portal del cliente pide la carpeta del tema «con el tema hijo incluido si utiliza uno». La protección contra regresiones, un servicio aparte de facturación mensual después de un proyecto, vuelve a escanear la tienda cada semana o cada mes y compara cada revisión con el escaneo de referencia. Cuando se vuelve a encontrar un fallo que estaba corregido, por ejemplo tras una actualización del tema, el hallazgo se reabre y se notifica como una regresión. Un nuevo escaneo solo encuentra lo que las comprobaciones automáticas pueden encontrar en las páginas a las que llega.

Validiscan prepara las correcciones sobre una copia del código fuente del tema, que obtiene de una de estas tres maneras. Aplica las correcciones en una carpeta de trabajo temporal, que se elimina después de cada entrega.

• Un repositorio de GitHub, en las cuatro plataformas. La tienda instala la GitHub App de Validiscan en el repositorio o le da a Validiscan un token de acceso. La configuración de Validiscan especifica los permisos de la App como acceso de escritura al contenido y a los pull requests del repositorio y acceso de lectura a sus metadatos, y nada más.
• Una contraseña de Theme Access, solo en Shopify. La aplicación Theme Access de Shopify crea contraseñas que dan acceso de escritura únicamente a los temas (el ámbito de acceso write_themes). Para configurar la aplicación hace falta ser el propietario de la tienda, o un miembro del personal o un colaborador con el permiso Temas. A fecha de 6 de octubre de 2026, la documentación de Shopify dice que el enlace a la contraseña caduca a los 7 días o en cuanto se ha visto, y que eliminar la contraseña revoca el acceso.
• Un ZIP del tema, en las cuatro plataformas, para un paquete de parches, que se sube en el portal del cliente como un solo archivo de hasta 100 MB. El portal pide la carpeta del plugin del tema en custom/plugins en Shopware, la carpeta del tema en wp-content/themes en WooCommerce, la carpeta del tema en app/design/frontend en Magento y el archivo del tema descargado desde el panel de control de Shopify en Shopify.

Sin ninguna de las tres, Validiscan no tiene código que cambiar y no se prepara ninguna corrección.

Validiscan entrega las correcciones aprobadas como un pull request, como una copia sin publicar del tema de Shopify o como un paquete de parches. El modo de entrega se fija por tienda, no por plataforma, y el paquete de parches es el predeterminado. Ninguno de los tres modifica el tema publicado de la tienda ni la rama predeterminada del repositorio.

La lista de comprobación del pull request de Validiscan pide al desarrollador que revise las correcciones como cualquier otro cambio del tema y que, además, utilice los elementos modificados con el teclado y, si es posible, con un lector de pantalla. Enumera estos pasos:

1. Leer el diff de cada commit.
2. Desplegar la rama en un entorno de vista previa o de preproducción, no en la tienda en producción.
3. Abrir las páginas afectadas y comprobar que se ven y funcionan como antes.
4. Manejar los elementos modificados solo con el teclado: todo debe poder alcanzarse y el foco debe ser visible.
5. Si es posible, comprobar los elementos modificados con un lector de pantalla, por ejemplo NVDA o VoiceOver.
6. Fusionar cuando el resultado sea satisfactorio. Validiscan comprueba entonces las páginas afectadas con un escaneo de verificación.

Los documentos de la entrega (el texto del pull request, PATCH.md y el README) están redactados en inglés o en alemán. Los clientes cuyo idioma está configurado en danés, francés o español reciben la versión en inglés.

Cada página de plataforma describe qué cambian las correcciones en esa plataforma y qué aporta el comerciante: correcciones de accesibilidad para temas de Shopify, para temas de Shopware, para temas de WooCommerce y para temas de Magento.

En Shopify, Shopware, WooCommerce y Magento, Validiscan prepara correcciones en el propio código del tema de la tienda para los fallos cuya corrección pertenece a ese código, y las entrega de las tres formas descritas arriba. Los hallazgos de nivel MANUAL reciben solo orientación, no un cambio de código. Cuando los cambios están en producción, un escaneo de verificación vuelve a comprobar las páginas afectadas. El Remediation Evidence Package registra entonces qué se probó, qué se cambió y qué encontró el escaneo de verificación, con la fecha de cada escaneo. Es evidencia de una evaluación y de un trabajo de corrección, no un certificado. Cómo se desarrolla un proyecto, paso a paso