Respuesta breve: para las tiendas online, el texto clave de la normativa de accesibilidad web en Turquía es la circular de accesibilidad web (Circular Presidencial 2025/10). Obliga a los proveedores de servicios que realizan comercio electrónico conforme a la Ley n.º 6563, la ley turca de comercio electrónico, a adaptar sus sitios web y aplicaciones móviles a la “Lista de verificación – Nivel A” del Ministerio de Familia y Servicios Sociales y a las WCAG 2.2 a más tardar en junio de 2027. La lista convierte los 31 criterios de Nivel A de las WCAG 2.2 en 126 preguntas, y cada página web y cada pantalla de la app se evalúan por separado. La Directiva de aplicación (Yönerge) exige una Comisión de Revisión de al menos tres personas y una revisión en tres etapas: pruebas automatizadas, pruebas manuales y pruebas con personas con discapacidad. La circular no fija multas directas. Sin embargo, los resultados de la supervisión se harán públicos y un servicio digital inaccesible puede dar lugar a una denuncia por discriminación ante TİHEK, el organismo nacional de derechos humanos e igualdad.
Hemos escrito esta guía para propietarios, responsables de comercio electrónico y líderes de TI o de producto de empresas de venta en línea que gestionan su propia tienda web o app para iOS/Android. También se dirige a marcas internacionales que venden en Turquía o trabajan con socios turcos de comercio electrónico. Las organizaciones de la primera fase, como bancos y hospitales privados, cuyo plazo venció en junio de 2026, pueden seguir los mismos pasos. No nos hemos basado en resúmenes de prensa: hemos leído directamente la circular, la lista de verificación, la guía del logo, la Directiva, las leyes pertinentes y las fuentes de TİHEK y del W3C. El presente texto no constituye asesoramiento jurídico. Este artículo está actualizado a fecha de 31 de octubre de 2026.
¿Qué regula la normativa de accesibilidad web en Turquía? Cuatro documentos oficiales en una tabla
La base legal es la Ley n.º 5378 sobre Personas con Discapacidad:
“Se garantizará que los servicios de información y las tecnologías de la información y la comunicación sean accesibles para las personas con discapacidad.” (Ley n.º 5378, art. 7; traducción propia)
Cuatro documentos fijan los detalles:
| Documento | ¿Qué regula? | Qué implica para el comercio electrónico |
|---|---|---|
| Circular 2025/10 (Resmî Gazete, Boletín Oficial de Turquía, 21 de junio de 2025) | Ámbito y plazos; las Comisiones de Supervisión, Asesora y de Revisión; el derecho de uso del logo durante 2 años | Plazo de 2 años: junio de 2027 |
| Directiva sobre Procedimientos y Principios de Aplicación (sin fecha de aprobación indicada) | Comisiones, método de revisión, exenciones, procedimiento del logo | Una comisión de al menos 3 personas, pruebas en tres etapas |
| Lista de verificación – Nivel A (V2.2.30.01, Ankara 2026) | Los 31 criterios de Nivel A de las WCAG 2.2, en forma de 126 preguntas | Cada página y cada pantalla de la app se evalúan por separado |
| Guía de uso del logo de accesibilidad (modificada el 14 de abril de 2026) | Cómo se usa el logo en sitios web y aplicaciones móviles | Solo se usa en los sitios y las apps a los que se ha concedido el derecho |
Dos aspectos que suelen confundirse:
- La Circular 2026/1 no es un plan para la web. El Plan de Supervisión e Inspección de esta circular, fechada el 21 de enero de 2026, abarca solo edificios, espacios abiertos y vehículos de transporte público. A 31 de octubre de 2026 no hemos encontrado el Plan de Supervisión previsto para web y móvil en las páginas de accesibilidad y de legislación de EYHGM, la Dirección General de Servicios para Personas con Discapacidad y Personas Mayores del Ministerio. Es demasiado pronto para afirmar que “han comenzado las inspecciones al comercio electrónico”.
- Todo indica que aún no se ha publicado una guía de las WCAG 2.2 en turco. La guía anunciada en la circular no figura en la página de accesibilidad del Ministerio, y el W3C presenta la traducción autorizada al turco como “planificada” (notificación de intención: 5 de mayo de 2026). Use como referencia el texto en inglés de las WCAG 2.2 del W3C.
Una nota sobre la Directiva: el Ministerio incluye la Directiva en la página de Directivas (Yönergeler) de EYHGM. El 31 de octubre de 2026 el enlace al documento en esa página estaba vacío, pero el texto en PDF está disponible en el sitio web del Ministerio. El texto no lleva fecha de aprobación; según su artículo 19, entra en vigor en la fecha en que se aprueba. La información sobre la Directiva que sigue se basa en este texto, así que compruebe si el Ministerio publica actualizaciones.
¿A quién se aplica la circular en el comercio electrónico y hay multas por incumplirla?
Ámbito: quienes tienen su propio sitio o su propia app
La circular menciona a los proveedores de servicios que realizan comercio electrónico conforme a la Ley n.º 6563. No fija ningún umbral de tamaño ni exención para microempresas. Según la Ley n.º 6563, un proveedor de servicios es una persona física o jurídica que realiza comercio electrónico, y un entorno de comercio electrónico es un sitio web, un sitio móvil o una aplicación móvil. Una marca con tienda o app propias está claramente incluida. Hay dos situaciones poco claras:
- Vendedores que solo venden en marketplaces: la Ley n.º 6563 también considera “proveedores de servicios de comercio electrónico” a quienes venden en un marketplace. Sin embargo, el entorno de venta pertenece al marketplace y ninguna norma indica cómo se aplica la obligación al vendedor.
- Empresas individuales: la Directiva define la comisión en términos de “instituciones, organizaciones y personas jurídicas” y “al menos tres miembros del personal”, por lo que no está claro cómo se les aplica la norma.
Sobre estas cuestiones, solicite una opinión al Ministerio o a su asesoría jurídica. Para las organizaciones de la primera fase, como bancos, hospitales privados, centros de enseñanza privados y empresas de transporte de pasajeros, el plazo de 1 año venció en junio de 2026.
Sanciones: la circular no fija multas, pero el riesgo está en otra parte
- La circular y la Directiva no establecen multas administrativas. No obstante, el titular del Ministerio anunciará públicamente los resultados de la supervisión.
- Las multas de la Ley n.º 5378 no se refieren a los sitios web. Las multas de su artículo provisional 3 se refieren a edificios, espacios abiertos y transporte público. La cifra de “5000–25 000 TL (liras turcas) por hallazgo” que citan algunas guías es el rango que esta disposición fija para municipios y organismos públicos. Para las personas físicas y las personas jurídicas de derecho privado, el importe nominal en el texto de la ley es de 1000–5000 TL por hallazgo.
- La vía de TİHEK es un riesgo real. La Ley n.º 6701, que creó TİHEK, prohíbe la discriminación por motivos de discapacidad y considera discriminación la falta de ajustes razonables. También abarca a las personas físicas y a las personas jurídicas de derecho privado que ofrecen “servicios similares”. La multa administrativa del artículo 25, apartado 1, es de 17 052–256 357 TL en 2026, y el Consejo de TİHEK puede convertirla en una advertencia una sola vez. En la decisión 2024/403, TİHEK apreció una infracción porque partes de la banca por internet y móvil de un banco no podían leerse con un lector de pantalla.
- Si vende a consumidores en Alemania: la BFSG. La BFSG es la ley alemana que transpone el Acta Europea de Accesibilidad (Directiva (UE) 2019/882). Abarca los servicios de comercio electrónico ofrecidos a consumidores después del 28 de junio de 2025, y la multa por ofrecer un servicio no conforme puede alcanzar los 100 000 €. Están exentas las microempresas que prestan servicios: las que tienen menos de 10 personas empleadas y un volumen de negocios anual o un balance general anual de no más de 2 millones de euros.
¿Cómo se lee la lista de verificación de accesibilidad (Nivel A)?
La lista de verificación de 2026 del Ministerio (V2.2.30.01) convierte los 31 criterios de conformidad de los cuatro principios de las WCAG 2.2 en 126 preguntas numeradas. Aquí las citamos de P1 a P126. Hay tres tipos de pregunta:
- ★ (64 preguntas): condición obligatoria. Una respuesta “No” significa que hay que corregir algo.
- ★★ (3 preguntas): condición que no debe darse. Una respuesta “Sí” significa que hay que corregir algo: información transmitida solo mediante el color (P52), destellos por encima de los umbrales (P81) y un cambio de contexto cuando un componente simplemente recibe el foco (P106).
- Sin estrella (59 preguntas): derivación. Por ejemplo, una pregunta plantea si la página tiene un CAPTCHA, y la respuesta le indica a qué sección pasar.
La regla decisiva: las preguntas se responden por separado para cada página web y cada pantalla de la app. En una tienda con miles de páginas de producto, esto significa trabajar plantilla por plantilla: página de inicio, categoría, detalle del producto, carrito, pasos de pago, cuenta y páginas de campañas. Una corrección en una plantilla se traslada a todas las páginas que la usan. Según la Directiva, la Comisión de Supervisión decidirá cómo se muestrean las páginas durante la supervisión.
La lista solo abarca el Nivel A. El contraste de color (1.4.3), el foco visible (2.4.7) y el tamaño del objetivo (2.5.8) son criterios AA, por lo que quedan fuera del mínimo legal. Aun así, le recomendamos incorporarlos a su sistema de diseño desde el principio: en el análisis de 2026 de WebAIM, el bajo contraste es el error más común, presente en el 83,9 % de las páginas de inicio. La lista no puede reproducirse con fines comerciales, de modo que explicamos su lógica en lugar de copiar las preguntas. Descargue la versión vigente del sitio web del Ministerio.
¿Qué exige la Directiva de accesibilidad? Comisión, pruebas, exenciones y logo
Comisión de Revisión: al menos tres personas de su propio personal
Según el artículo 13 de la Directiva, cada institución y persona jurídica sujeta a supervisión crea una Comisión de Revisión (İnceleme Komisyonu) de al menos tres miembros del personal, de los cuales al menos uno trabaja en la unidad web/móvil. El consejo de algunas guías de que “basta con un equipo central de dos personas” contradice el artículo 13. El año en que su organización se incluya en el Plan de Supervisión (İzleme Planı), la comisión prepara un Informe de Revisión en el formato de ese plan y lo envía a la secretaría de EYHGM. También hace el seguimiento de las correcciones y prepara un informe actualizado para renovar el logo.
¿Cómo se realizan las pruebas de accesibilidad? Tres etapas
- Pruebas automatizadas: con herramientas que figuran en el sitio web del W3C. A 31 de octubre de 2026, la lista del W3C contiene 119 herramientas. Tiene filtros para Android e iOS, y WAVE y axe DevTools figuran en ella (el W3C no avala productos concretos).
- Pruebas manuales: formularios, controles de interfaz, cuadros de diálogo, confirmaciones de entrada de datos, mensajes de error, respuestas del sistema, teclado y contenido no textual como fotos, video, CAPTCHA y audio.
- Pruebas con personas con discapacidad: con la participación de personas con discapacidad visual (usuarios de lectores de pantalla y personas con baja visión), auditiva (personas sordas y con pérdida auditiva) y ortopédica (uso limitado del ratón y del teclado). También se recomienda hacer pruebas con personas con discapacidad cognitiva, personas dentro del espectro autista, personas con dificultades específicas de aprendizaje y personas con daltonismo.
¿Por qué no basta con un overlay de accesibilidad (plugin)?
La lista de verificación exige que la relación entre etiquetas y campos de formulario, así como la jerarquía de encabezados, se definan “mediante programación” en el código. También exige que la gestión del foco esté bien configurada. Un widget agregado a posteriori intenta corregir esto en el navegador a base de conjeturas. Puede romperse cuando cambian las plantillas y no llega en absoluto a las pantallas nativas de iOS o Android. Ninguno de los cuatro documentos contiene una disposición que considere un overlay como prueba de cumplimiento. Según la Directiva, las pruebas manuales y las pruebas con personas con discapacidad son obligatorias en todos los casos.
Conozca también los límites de las pruebas automatizadas. Según el análisis WebAIM Million 2026, el 95,9 % de las páginas de inicio del millón de sitios web más populares presenta errores WCAG detectados automáticamente. La media es de 56,1 errores por página, frente a 66,2 en las páginas en turco y 71,0 en la categoría de compras. En cambio, una trampa de teclado o un texto alternativo sin sentido suelen aparecer solo cuando el sitio lo prueban personas reales. Conectar las comprobaciones automáticas a su pipeline de CI/CD ayuda a evitar que los errores ya corregidos vuelvan en nuevas versiones.
Exenciones: ¿qué queda fuera del ámbito?
- Contenido agregado de forma dinámica y automática desde otras fuentes: la Directiva pone como ejemplos los anuncios dinámicos y las reseñas de compras. Lo que está exento es el propio contenido, no su formulario de reseñas ni su componente de valoración.
- Mapas en línea, siempre que la información esencial para la navegación se ofrezca de forma accesible.
- Retransmisiones en vivo; sin embargo, la grabación de la retransmisión que se conserve en el sitio debe hacerse accesible en un plazo de 14 días.
- Video y audio grabados antes de la circular, y el contenido de archivo que no se actualice en el plazo de un año desde la entrada en vigor de la circular y no sea necesario para los procesos administrativos. Para los nuevos videos de producto se aplican las preguntas sobre subtítulos, transcripciones y audiodescripción (P17–25).
La interpretación a lengua de señas turca (TİD) no es obligatoria para los contenidos de video y audio. Si la ofrece, quien la realice debe haber obtenido al menos 70 puntos en el Examen de Competencia en TİD.
¿Cómo se obtiene el logo de accesibilidad?
No puede agregar el logo por su cuenta. Puede solicitar a EYHGM el derecho a usarlo. La Comisión de Supervisión concede ese derecho durante 2 años, por separado para los sitios web accesibles y para las apps accesibles en cada sistema operativo móvil. La renovación exige un Informe de Revisión actualizado que siga el Plan de Supervisión vigente. Según la Guía, actualizada el 14 de abril de 2026, el logo solo puede usarse en el sitio o la app a los que se ha concedido el derecho. Al hacer clic en él debe llevar a la página de verificación del sitio web oficial de EYHGM, y no puede utilizarse para obtener beneficios comerciales.
Del escaparate al pago: los problemas más comunes en los sitios de comercio electrónico
Componentes habituales de una tienda y las preguntas relacionadas de la lista de verificación (numeradas como en V2.2.30.01):
| Componente | Preguntas | Qué hacer |
|---|---|---|
| Menú y bloques repetidos | P36–37, P65–66, P82–83 | Use <nav>. Un submenú que se abre con el ratón también debe abrirse con el teclado. Agregue un enlace “Saltar al contenido principal”. |
| Carrusel (slider) y banner promocional con desplazamiento | P75–78 | Un botón de pausa para el movimiento automático que dure más de 5 segundos. |
| Imágenes de producto | P1–5 | Un alt significativo para las imágenes que transmiten información; alt="" para las decorativas. |
| Selector de color y talla | P16, P51–53 | Indique el estado seleccionado o agotado con texto, además de con el color. Asigne a cada muestra de color un nombre accesible (“Azul marino”). |
| Filtros | P40–41, P107–108 | Agrupe las opciones con <fieldset> y <legend>. Si una selección recarga la página por sí sola, avíselo de antemano o agregue un botón “Aplicar”. |
| Botones +/− del carrito y botones de icono | P15–16, P124–126 | Nombres accesibles como “Aumentar cantidad” y “Agregar al carrito”; mantenga actualizado el valor de la cantidad mediante programación. |
| Vista rápida, banner de cookies, ventana emergente (pop-up) | P61–64, P69–70 | Use role="dialog" en la ventana modal. El foco debe pasar a la ventana, la tecla Escape debe cerrarla y, al cerrarse, el foco debe volver al botón que la abrió o a otro punto lógico. |
| Límites de tiempo de la sesión y del carrito | P73–74 | Permita desactivar el límite de tiempo o ampliarlo hasta al menos 10 veces su duración, o avise al menos 20 segundos antes de que termine y permita prolongarlo con una sola acción, al menos 10 veces. |
| Formularios | P38–39, P111–120 | El texto de ejemplo (placeholder) no sustituye a una etiqueta. Vincule el texto de error a su campo. Un asterisco sin explicación o un simple borde rojo no bastan. |
| Dirección de entrega y de facturación | P121–122 | Una opción “La dirección de facturación es la misma que la de entrega” y atributos autocomplete. |
| CAPTCHA | P10–12 | Un texto que explique su finalidad y una alternativa que no dependa de un solo sentido. Un CAPTCHA solo visual o solo auditivo no es suficiente. |
| Soporte en vivo, preguntas frecuentes, chatbot | P109–110 | El enlace de ayuda en el mismo lugar predecible de todas las páginas. |
Anunciar a los lectores de pantalla un mensaje “Agregado al carrito” (WCAG 4.1.3) es un criterio AA y no figura en la lista. Aun así, lo recomendamos como práctica habitual.
El paso de pago y 3D Secure
La pantalla de 3D Secure suele ser una página del banco o del proveedor de pagos, y usted no puede cambiar su contenido. No recomendamos confiar en la exención de la Directiva para el contenido agregado automáticamente. La Directiva da ejemplos como los anuncios y las reseñas de compras para esta exención y, en nuestra opinión, un flujo de compra no encaja en esa descripción. Refuerce la parte que controla:
- Asigne un
titlesignificativo al iframe que contiene los campos de pago o la pantalla de 3DS. Mueva el foco a su interior cuando se abra y al mensaje de resultado cuando se cierre. - Pruebe con un lector de pantalla las páginas de éxito y de error tras el regreso de 3DS. Si se produce un error, conserve los datos que haya escrito el usuario.
- Solicite a su proveedor de pagos información escrita sobre la accesibilidad del formulario de pago y de la pantalla de 3DS, y conviértala en un criterio al renovar el contrato.
Para conocer los detalles de integración, consulte nuestra guía de integración de POS virtual (pago en línea con tarjeta) y 3DS.
Accesibilidad en aplicaciones móviles: equivalencias en iOS, Android y React Native
La lista de verificación menciona las API de cada plataforma en sus ejemplos, y sus apps para iOS y Android se evalúan con las mismas preguntas, pantalla por pantalla. Equivalencias habituales:
| Necesidad (pregunta) | Android | iOS | React Native |
|---|---|---|---|
| Nombre accesible (P3, P16) | contentDescription | accessibilityLabel | accessibilityLabel |
| Ocultar un elemento decorativo (P5) | importantForAccessibility="no" | isAccessibilityElement = false | aria-hidden={true} |
| Encabezado (P28) | accessibilityHeading="true" | accessibilityTraits = .header | accessibilityRole="header" |
| Información de lista (P30) | CollectionInfo | accessibilityContainerType | role="list" |
| Modal y foco (P62, P70) | accessibilityPaneTitle | accessibilityViewIsModal | accessibilityViewIsModal (solo iOS) |
| Una acción en lugar de deslizar o arrastrar (P68, P96) | AccessibilityAction | accessibilityCustomActions | accessibilityActions |
| Autocompletado (P122) | autofillHints | textContentType | autoComplete |
En dos puntos de la columna de React Native nos hemos apartado de los ejemplos de la lista. “list” no es uno de los valores de accessibilityRole; el rol de lista se define con role="list". En Android, accessible={false} solo desactiva la posibilidad de recibir el foco; para ocultar un elemento decorativo a los lectores de pantalla en ambas plataformas, use aria-hidden. La lista no menciona Flutter; allí, la misma información se proporciona mediante las propiedades label, header, excludeSemantics y customSemanticsActions del widget Semantics. Agregue también una alternativa con botón para las acciones que solo funcionan deslizando, como quitar un artículo del carrito (P95–96), y una alternativa y una opción de desactivación para las funciones basadas en movimiento, como “agitar para deshacer” (P101–103). Vincule los mensajes de error al campo correspondiente (setError en Android). Como el derecho al logo se concede por separado para cada sistema operativo móvil, planifique iOS y Android como productos independientes. No califique una app de “accesible” hasta haberla probado con VoiceOver y TalkBack. Describimos nuestro enfoque en el lado nativo en nuestra página de desarrollo de aplicaciones móviles.
Hoja de ruta de 7 meses hasta junio de 2027, paso a paso
Una secuencia realista para un equipo que empieza en noviembre de 2026:
- Noviembre de 2026, organización e inventario: cree la Comisión de Revisión (al menos 3 personas, una de ellas de la unidad web/móvil). Haga una lista de sus plantillas web y pantallas de la app, y marque aparte los componentes de terceros, como las herramientas de pago, cookies y soporte en vivo.
- Diciembre de 2026, medición inicial: realice un análisis automatizado con herramientas de la lista del W3C y después revise la lista de verificación plantilla por plantilla. Convierta los hallazgos en una lista de tareas, con los elementos ★★ y el flujo de pago en primer lugar.
- Enero–marzo de 2027, correcciones de componentes: corrija botones, campos de formulario, ventanas modales, menús, carruseles y filtros en el sistema de diseño, y conecte las pruebas automatizadas al pipeline de CI.
- Marzo–abril de 2027, pago y apps: pago y regreso de 3DS, banner de cookies y widgets de terceros; correcciones en iOS y Android.
- Abril–mayo de 2027, pruebas manuales y pruebas con personas con discapacidad: pruebas con teclado, VoiceOver y TalkBack; sesiones con personas de los grupos de discapacidad que enumera la Directiva; borrador del Informe de Revisión.
- Junio de 2027 y después: cuando se publique el Plan de Supervisión para web y móvil, adapte el informe a su formato, valore la solicitud del logo y realice pruebas de regresión con cada versión.
Punto de decisión: si utiliza un tema prediseñado, parte de las correcciones depende de los proveedores de su tema y de sus plugins. Solicite al proveedor un calendario de accesibilidad por escrito. Si no lo consigue, valore cambiar de tema o pasar a un sitio web de diseño a medida antes de marzo de 2027. Con un diseño a medida, las correcciones se hacen en componentes compartidos y se trasladan a todas las páginas que los usan.
Cómo le ayuda Partnerfy
Resolvemos la accesibilidad en su origen, no con un overlay. Primero hacemos un inventario de sus plantillas y pantallas de la app, y las analizamos con herramientas de la lista del W3C. Después realizamos pruebas manuales con el teclado, VoiceOver y TalkBack. Corregimos los hallazgos en los componentes de su sistema de diseño y en el código nativo de iOS, Android o React Native, y conectamos las comprobaciones automáticas a su pipeline de CI. Para las pruebas con personas con discapacidad, preparamos los escenarios, le ayudamos a planificarlas con asociaciones y organizaciones que trabajan en este ámbito y elaboramos la documentación técnica para el informe de su Comisión de Revisión. La participación en la comisión y la evaluación jurídica siguen siendo responsabilidad suya. Si desea una evaluación inicial de su plataforma de comercio electrónico, contáctenos.
Fuentes
- Resmî Gazete: Circular 2025/10 (21 de junio de 2025, n.º 32933), en turco
- Ministerio de Familia y Servicios Sociales: Lista de verificación – Nivel A (V2.2.30.01), en turco
- EYHGM: página de Directivas y Directiva sobre Procedimientos y Principios de Aplicación (PDF), en turco
- EYHGM: Guía de uso del logo, Circular 2026/1 y página de accesibilidad, en turco
- Legislación: leyes n.º 5378, 6701 y 6563, en turco
- TİHEK: multas administrativas de 2026 y comunicado de prensa sobre la Circular 2025/10, en turco
- W3C: WCAG 2.2 y traducciones de las WCAG
- W3C: Web Accessibility Evaluation Tools List
- WebAIM: The WebAIM Million (2026)
- BFSG: § 1, § 2, § 3 y § 37, en alemán
- React Native: Accessibility y Flutter: clase Semantics