AccesibilidadLimita

Zoom y escalado: cuando tu web impide agrandar la letra

Este hallazgo aparece cuando tu página impide ampliarla con los dedos, o limita tanto la ampliación que no sirve de nada. Wakaris lo detecta revisando cómo declara tu web la ventana visible en el móvil. Es una barrera directa para quien necesita agrandar el texto para poder leerlo.

Por Juan Ignacio FrancoActualizado: 8 de septiembre de 20267 min de lectura

En resumen

Qué mide

si tu página declara algo que bloquea o limita la ampliación en el móvil.

Cuándo salta

en cuanto encuentra uno de esos ajustes, sin tramos. Severidad: Importante.

Referencia

las WCAG piden que el texto se amplíe hasta el 200 % sin perder nada (nivel AA).

Dato de Wakaris

el 24,6 % de las páginas analizadas falla en este hallazgo.

Dos dedos separándose sobre la pantalla de un móvil que muestra una web cuyo texto no se agranda
El gesto de siempre, sobre una página que ha decidido no responder a él.

Qué es y qué mide este hallazgo

Cuando abres una web en el móvil y quieres ver mejor una letra pequeña, separas dos dedos sobre la pantalla y la página se agranda. Ese gesto se puede desactivar desde el código de la página, y este hallazgo aparece cuando tu web lo hace.

El control está en una sola línea del encabezado: la que le dice al navegador cómo encajar la página en la pantalla del móvil. Esa línea admite tres ajustes que afectan a la ampliación: uno que la permite o la prohíbe, otro que fija cuánto es lo máximo que se puede ampliar y otro que fija el mínimo. Según MDN, el primero acepta los valores sí o no y por defecto vale sí, mientras que los de escala máxima y mínima aceptan números entre 0,0 y 10,0.

Con cualquiera de los tres se puede dejar la página congelada: prohibiendo el gesto directamente, o permitiéndolo con un techo tan bajo que el visitante no gana ni un milímetro de letra.

Cómo se mide

Wakaris lee el encabezado de tu página, localiza esa declaración de ventana visible y comprueba si alguno de sus ajustes impide o limita la ampliación. Es la vía directa para saberlo, sin instalar nada ni crear cuenta, y llega junto al resultado del resto de áreas.

La comprobación se hace sobre el código que tu web sirve para la URL analizada, y ahí está su alcance: mira lo que declaras, no lo que acaba haciendo un teléfono concreto. La distinción importa, porque MDN advierte que la configuración del navegador puede ignorar estos ajustes y que iOS 10 y posteriores los ignoran por defecto. En algunos móviles, por tanto, tu visitante podrá ampliar aunque tu código diga que no.

Eso no vuelve irrelevante el hallazgo: la declaración sigue ahí, sigue aplicándose en los navegadores que la respetan y es la parte que tú controlas. El resultado es un único recuento, sin tramos: o hay algo que bloquea o limita la ampliación, o no lo hay.

Por qué importa

Importa porque toca una necesidad básica y muy repartida: leer.

El criterio 1.4.4 de las WCAG, de nivel AA, pide que el texto se pueda ampliar hasta el 200 % sin pérdida de contenido ni de funcionalidad, con la excepción de los subtítulos y las imágenes de texto. Su intención, según el W3C, es que el texto visible —incluidos los controles y las etiquetas— se pueda agrandar para leerlo con más facilidad, sin necesidad de una ayuda técnica como un magnificador de pantalla. MDN lo dice sin rodeos: desactivar la ampliación impide leer y entender el contenido a las personas con baja visión, y añade que la buena práctica es permitir hasta cinco aumentos.

Hay un segundo frente. El criterio 1.4.10, también AA, pide que el contenido se reorganice sin obligar a desplazarse en dos direcciones a un ancho equivalente a 320 píxeles CSS, que el W3C equipara a una ventana de 1.280 píxeles ampliada al 400 %. Quien no puede ampliar no llega nunca a esa situación: se queda antes, con la letra del tamaño que tú decidiste.

Causas comunes

Casi nunca hay una decisión deliberada de estorbar a nadie: hay una línea copiada.

La causa más frecuente es la plantilla. Muchos temas y generadores de sitios traen esa declaración ya escrita, con la ampliación desactivada, y quien monta la web no la toca porque ni sabe que está ahí. Se hereda sin verla.

La segunda es querer que la web «parezca una aplicación». Cuando se busca una sensación nativa, prohibir la ampliación evita que un doble toque descoloque la pantalla, y el efecto secundario se acepta sin medirlo.

La tercera es un parche a un problema de maquetación. Si la página se desborda a lo ancho en móvil, congelar la escala oculta el síntoma: ya no se puede mover la página de lado, así que el desbordamiento deja de notarse. El fallo sigue, tapado.

Y la cuarta es un techo heredado: la escala máxima puesta en un valor bajo, que no prohíbe ampliar pero deja el margen en casi nada. Nadie lo escribió con mala intención; venía en el ejemplo del que se copió.

Cómo solucionarlo

El arreglo es de los más baratos de todo el análisis, porque casi siempre consiste en borrar texto.

Empieza por confirmar qué tienes: Wakaris te dice si tu página declara algo que bloquea o limita la ampliación, y en qué URL, así que sabes de entrada si te toca.

Después localiza esa declaración de ventana visible en el encabezado de tu plantilla y quítale el ajuste que prohíbe ampliar y el que fija una escala máxima. Lo que debe quedar es la parte que adapta el ancho a la pantalla y fija la escala inicial; lo demás sobra. Si tu plantilla no deja editar el encabezado, busca en su panel una opción de zoom o de escala en móvil.

Si en su día bloqueaste la ampliación para tapar un desbordamiento a lo ancho, ahora reaparecerá, y ese es el trabajo de verdad: arreglar el elemento que se sale, que suele ser una tabla, una imagen con ancho fijo o un bloque medido en píxeles.

Cuando termines, vuelve a pasar la página por Wakaris y comprueba que el hallazgo ha desaparecido.

Pregúntale a tu IA

Estos dos prompts están pensados para pegarlos tal cual en tu asistente de IA. Elige el que corresponda a tu situación: el primero si ya has medido tu web y quieres quitar el bloqueo; el segundo si has llegado aquí sin medir nada y quieres saber si te afecta.

Prompt A

A. Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo

Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada.

Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema en el lenguaje de cada rol de un equipo. El hallazgo es: Zoom y escalado. Mi página declara algo que impide o limita ampliarla con los dedos en el móvil (referencia: el hallazgo aparece en cuanto se detecta uno de esos ajustes, sin tramos; las WCAG piden poder ampliar el texto hasta el 200 % sin perder contenido ni funcionalidad).

Reglas que debes seguir en todo momento:

1. No asumas nada sobre mi web ni sobre mi plantilla. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo.
2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber de dónde sale el bloqueo y quién puede quitarlo:
   a) Pega aquí el resultado de Wakaris: la página analizada y lo que te diga sobre el zoom. Si no lo tienes, mide tu web con Wakaris y vuelve con el resultado; sin saber qué declara tu página no se puede orientar nada.
   b) ¿En qué plataforma está tu web y sobre qué plantilla o tema?
   c) ¿Puedes editar el encabezado de la plantilla, o solo tienes el panel de administración?
   d) En el móvil, ¿se te desborda algo a lo ancho: una tabla, una imagen, un bloque?
   e) ¿Sabes si alguien bloqueó el zoom a propósito y por qué motivo?
   f) Si hay que tocar la plantilla, ¿lo harías tú, un técnico interno o una agencia?
3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me propones editar algo, explícame qué efecto tendrá en mi caso.
4. Marca siempre tu nivel de certeza. Tú no ves mi página ni su código: si algo es una hipótesis, dilo.
5. No me propongas cambios técnicos irreversibles o de riesgo (editar ficheros del tema, tocar la plantilla en producción) sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba.
6. Si necesitas un dato que solo se obtiene midiendo la web (qué declara realmente mi página, o si el arreglo funcionó), dímelo y recomiéndame volver a pasarla por Wakaris: eso se mide, no se adivina.
7. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí.
8. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo (propio o un técnico que yo designe), ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Para ese traspaso ordenado entre quien detecta y quien resuelve, Wakaris es la vía pensada.

Fuente de este contexto: https://www.wakaris.com/es/guias/accesibilidad/zoom-y-escalado
Para (re)analizar mi web: https://www.wakaris.com/

Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Pégalo en la IA que uses.
Prompt B

B. Aún no lo he medido y quiero comprobar si mi web tiene este problema

Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho.

Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema en el lenguaje de cada rol de un equipo. El problema que quiero investigar es: Zoom y escalado. Consiste en que mi página declare algo que impida ampliarla con los dedos en el móvil, o que fije un techo de ampliación tan bajo que no sirva de nada. Todavía NO sé si es mi caso: quiero averiguarlo.

Reglas que debes seguir en todo momento:

1. Lo primero y más importante: esto se comprueba leyendo lo que declara el encabezado de mi página, y tú no puedes leer mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente.
2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga este problema:
   a) Abre tu web en el móvil y separa dos dedos sobre el texto: ¿se agranda, se agranda muy poco o no se mueve nada?
   b) ¿En qué plataforma está tu web y con qué plantilla o tema?
   c) ¿La montó una agencia, la compraste hecha o la hiciste tú?
   d) ¿Te ha comentado alguien que le costaba leerla en el móvil?
   e) En el móvil, ¿hay algo que se salga a lo ancho de la pantalla?
3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico.
4. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dirá qué declara mi página y de paso el estado de las otras áreas. Preséntalo como la respuesta a mi pregunta, no como una venta.
5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes: explícame que la prueba de los dos dedos en el móvil da una pista, pero recuérdame que puede engañar, porque algunos navegadores ignoran ese ajuste, y que Wakaris me dice lo que mi página declara de verdad, con el resto del análisis incluido.
6. Si al comprobarlo resulta que sí lo tengo, dime que el siguiente paso es mirar si el bloqueo estaba tapando un problema de maquetación en móvil.
7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme.

Fuente de este contexto: https://www.wakaris.com/es/guias/accesibilidad/zoom-y-escalado
Para analizar mi web: https://www.wakaris.com/

Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Pégalo en la IA que uses.

Preguntas frecuentes

¿Bloquear el zoom incumple las WCAG? +

El criterio 1.4.4, de nivel AA, exige que el texto se pueda ampliar hasta el 200 % sin perder contenido ni funcionalidad. Impedir la ampliación en el móvil retira la vía normal de conseguirlo, así que compromete ese criterio salvo que tu página ofrezca otra manera equivalente de agrandar el texto.

Si algunos móviles lo ignoran, ¿me tengo que preocupar? +

Sí. MDN advierte que la configuración del navegador puede ignorar estos ajustes y que iOS 10 y posteriores lo hacen por defecto, pero no todos los navegadores ni todas las versiones se comportan igual. La declaración sigue afectando a parte de tus visitantes y es la parte que tú controlas.

¿Puedo dejar un límite de ampliación en lugar de quitarlo? +

Puedes, pero que sea generoso. MDN señala que la buena práctica es permitir hasta cinco aumentos, bastante por encima del mínimo que piden las WCAG. Un techo bajo produce el mismo hallazgo que prohibir la ampliación, porque para quien necesita agrandar la letra el efecto es parecido.

¿Esto es lo mismo que tener una web adaptada al móvil? +

No. Adaptarse al tamaño de la pantalla y dejarse ampliar son cosas distintas. Una web perfectamente adaptada puede tener la ampliación bloqueada, y una que se amplía sin problema puede desbordarse a lo ancho. Wakaris las revisa por separado, en dos hallazgos diferentes.

Fuentes citadas

  • developer.mozilla.orgViewport meta tag — MDN — developer.mozilla.org
  • w3.orgUnderstanding SC 1.4.4: Resize Text — W3C — w3.org
  • w3.orgUnderstanding SC 1.4.10: Reflow — W3C — w3.org
Retrato de Juan Ignacio Franco

Juan Ignacio FrancoAnalista de datos · Bitanube

Juan Ignacio Franco es analista de datos en Bitanube. Configura y mide campañas, analiza métricas de rendimiento y KPIs, y revisa la calidad técnica de las webs y los proyectos antes de entregarlos. Los hallazgos de estas guías son los que aparecen en ese trabajo.

Actualizado: 8 de septiembre de 2026.

Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.

Compartir esta guía
Empieza ahora

Tu web tiene mucho que contarte
Y por fin vas a entenderla

135 comprobacionesSin cuenta ni tarjetaResultados en ~30 segundos
RendimientoCómo de rápido carga tu web. Si tarda, pierdes visitas y ventas antes de que te vean.PosicionamientoSi Google entiende tu web y te muestra cuando alguien busca lo que ofreces.SeguridadSi tu web está protegida. Un fallo aquí espanta a clientes y a Google por igual.PresenciaCómo apareces en Google, redes y mapas. Es la primera imagen que das antes de que te contacten.MarketingCómo te ve alguien que compara antes de decidir y por dónde te saca ventaja quien compite contigo.Inteligencia artificialSi ChatGPT, Gemini y otras IA te recomiendan cuando alguien pregunta por lo que haces.ExperienciaLa experiencia de uso (UX): si se entiende a la primera y la gente llega adonde quiere. Una web confusa se abandona aunque cargue rápido.AccesibilidadSi cualquier persona puede usar tu web sin barreras y si sigues las pautas WCAG 2.2. Más público que te entiende.LegalSi cumples con cookies y protección de datos. Evita sanciones y multas que duelen.

Suri

Asistente de Wakaris