La accesibilidad no es una comprobación que se hace una sola vez al final de un proyecto. Depende de la estructura HTML, los contenidos, los componentes interactivos, las apps, las actualizaciones del tema y los recorridos reales que utilizan las personas.
Esta página explica cómo trabajo en ifgecommerce.com y qué referencias utilizo. No es una certificación de conformidad ni sustituye un análisis legal o una auditoría formal de todo el sitio.
La referencia técnica: WCAG 2.2
Utilizo las Web Content Accessibility Guidelines (WCAG) 2.2 del W3C como referencia técnica principal para diseño y verificación. WCAG 2.2 es una W3C Recommendation y organiza la accesibilidad en cuatro principios: contenido perceptible, interfaces operables, información comprensible e implementación robusta.
Seguir WCAG no demuestra automáticamente todas las obligaciones legales que puedan resultar aplicables. Un estándar técnico y un requisito normativo son capas distintas y deben reconciliarse con el operador, el servicio, el mercado y la legislación aplicable.
El marco europeo e italiano
La Directiva (UE) 2019/882, conocida como European Accessibility Act, establece requisitos de accesibilidad para determinados productos y servicios. En Italia fue transpuesta mediante el Decreto Legislativo de 27 de mayo de 2022, n.º 82, aplicable a los productos y servicios cubiertos puestos en el mercado o prestados a partir del 28 de junio de 2025.
El artículo 4.5 de la Directiva también exime a las microempresas que prestan servicios de los requisitos de accesibilidad contemplados por esa Directiva. Este dato, por sí solo, no determina todas las obligaciones de accesibilidad que puedan afectar a un sitio concreto: la aplicabilidad debe evaluarse según el operador y el servicio reales.
Qué compruebo en el sitio
1. Estructura semántica
Compruebo que encabezados, landmarks, listas, enlaces, botones y controles utilicen elementos y roles coherentes con su función real. Una página puede verse correctamente y seguir siendo confusa para las tecnologías de asistencia si la estructura subyacente no representa lo que aparece en pantalla.
2. Navegación por teclado y foco
Menús, modales, filtros, selectores, formularios y otros componentes interactivos deben poder utilizarse sin ratón cuando la función lo requiere. Compruebo orden de tabulación, foco visible, apertura y cierre de componentes y retorno del foco en las interacciones importantes.
3. Texto, contraste y redimensionamiento
Evalúo contraste, legibilidad, jerarquía tipográfica y comportamiento cuando se amplía el texto o se reduce la viewport. El contenido no debería volverse inutilizable simplemente porque una persona use zoom o una pantalla pequeña.
4. Imágenes y contenido no textual
Las imágenes informativas necesitan alternativas textuales útiles; las decorativas no deberían añadir ruido a quien utiliza un lector de pantalla. El texto alternativo se escribe según la función de la imagen en el contexto, no copiando automáticamente el nombre del archivo o el título del producto.
5. Formularios, errores y estados
Compruebo etiquetas, instrucciones, mensajes de error, campos obligatorios y cambios de estado. Un error no debería comunicarse solo mediante color y una acción completada debería proporcionar un feedback comprensible sin depender exclusivamente de señales visuales.
6. Componentes Shopify y apps de terceros
En Shopify los problemas de accesibilidad no provienen solo del tema. Search, opciones de producto, cart drawer, popups, reseñas, cookie banners y app embeds pueden introducir componentes con semántica o gestión del foco incorrectas. Por eso la revisión debe cubrir también lo que terceras partes inyectan o actualizan.
Automatización y pruebas manuales son necesarias
Los escáneres automáticos son útiles para detectar rápidamente categorías de errores, pero no pueden demostrar por sí solos que un recorrido sea accesible. Muchos problemas requieren interacción real: si el foco llega al lugar correcto, si una etiqueta tiene sentido, si una modal gestiona correctamente el teclado o si el orden de lectura resulta comprensible.
Por eso combino controles automáticos con pruebas manuales de los recorridos importantes y, cuando corresponde, verificaciones con tecnologías de asistencia.
La accesibilidad puede cambiar con el tiempo
Un sitio que hoy no presenta un problema puede introducirlo mañana mediante una nueva app, un cambio de tema, contenido editorial, un vídeo sin alternativa o una actualización de un componente externo. Por eso considero la accesibilidad una práctica de mantenimiento, no un estado permanente conseguido con una sola prueba.
Contenidos históricos, documentos, integraciones y componentes de terceros pueden necesitar revisiones específicas y no se consideran automáticamente conformes solo porque se haya corregido el template principal.
Estado actual de ifgecommerce.com
No declaro una conformidad total del sitio sin una auditoría formal completa y actualizada de toda la superficie pública. Corrijo progresivamente los problemas observados y trato las barreras notificadas como findings que deben verificarse en su contexto real.
Notificar una barrera
Si encuentras contenido o una función difícil de utilizar, escribe a info@ifgecommerce.com. Para acelerar la verificación, indica la URL correspondiente, qué intentabas hacer, dispositivo/navegador y, cuando proceda, la tecnología de asistencia utilizada.
Referencias
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2;
- EUR-Lex — Directiva (UE) 2019/882;
- Normattiva — Decreto Legislativo italiano de 27 de mayo de 2022, n.º 82.
Última actualización: 20 de septiembre de 2026.
