Accesibilidad

Este sitio procura que sus artículos, guías, tablas y funciones puedan ser utilizados por la mayor cantidad posible de lectores, incluidas personas con limitaciones visuales, auditivas, motrices, cognitivas o neurológicas. La accesibilidad web implica que una persona pueda percibir, comprender, navegar e interactuar con el contenido mediante distintos dispositivos y tecnologías de asistencia.

Este documento explica el enfoque general de la redacción, los estándares que tomamos como referencia y las medidas que intentamos aplicar al diseñar y actualizar las páginas para la audiencia de Argentina. También indica cómo informar una barrera relacionada con la lectura, la navegación o el funcionamiento del formulario.

La accesibilidad es un objetivo continuo, no una declaración de perfección. Algunas páginas, imágenes o elementos externos pueden presentar limitaciones todavía no detectadas. Por eso, combinamos revisiones técnicas con comentarios de lectores y priorizamos las correcciones que impiden acceder a información esencial.

Por qué nos lo tomamos en serio

La accesibilidad no se considera una tarea que termina después de aprobar una revisión automática. Los contenidos cambian, se agregan nuevas tablas, se modifican plantillas y aparecen dispositivos o tecnologías de asistencia diferentes. Por ese motivo, cada actualización puede introducir barreras nuevas aunque la página anterior funcionara correctamente.

Para la audiencia argentina, este enfoque también debe contemplar condiciones reales de acceso. Algunas personas navegan desde celulares antiguos, redes móviles inestables o dispositivos compartidos con familiares. Otras utilizan lectores de pantalla, ampliación del sistema, navegación por teclado, control por voz o configuraciones personalizadas de contraste.

Nuestro trabajo se organiza alrededor de tres fuentes:

1. recomendaciones internacionales de accesibilidad;
2. pruebas automáticas y revisiones manuales;
3. comentarios enviados por lectores que encuentran un problema concreto.

Una herramienta automática puede detectar una imagen sin texto alternativo, pero no siempre puede determinar si la descripción es útil. Del mismo modo, una página puede superar controles técnicos y seguir siendo difícil de comprender. Por eso, la evaluación humana continúa siendo necesaria.

Principios que orientan las páginas

Intentamos que cada publicación cumpla cuatro principios básicos: que la información pueda percibirse, que la interfaz pueda operarse, que el lenguaje resulte comprensible y que el código mantenga compatibilidad razonable con tecnologías de asistencia.

Principio	Qué significa en la práctica	Ejemplo de aplicación
Perceptible	La información no depende de un único sentido	Texto alternativo y contraste suficiente
Operable	Las funciones pueden utilizarse de distintas maneras	Navegación mediante teclado
Comprensible	El contenido y las acciones son previsibles	Títulos claros e instrucciones directas
Robusto	La estructura puede interpretarse con tecnologías actuales	HTML semántico y etiquetas accesibles
Adaptable	La presentación responde a distintas pantallas	Diseño móvil y texto ampliable
Tolerante	Los errores pueden identificarse y corregirse	Mensajes claros en el formulario

Estos objetivos se aplican tanto a una guía extensa como a una página legal, una tabla comparativa o un formulario de contacto.

Estándares que perseguimos

El sitio toma como referencia las Web Content Accessibility Guidelines, conocidas como WCAG. Nuestro objetivo de trabajo es aproximarnos a los criterios de WCAG 2.1 nivel AA, sin afirmar que todas las páginas satisfacen permanentemente cada requisito.

WCAG 2.0, 2.1 y 2.2 continúan siendo estándares publicados. W3C recomienda utilizar la versión más reciente, aunque WCAG 2.2 mantiene compatibilidad hacia atrás con los criterios anteriores.

Las evaluaciones pueden combinar:

• Lighthouse para revisiones generales;
• axe DevTools para identificar problemas frecuentes;
• inspección manual del código;
• navegación exclusivamente con teclado;
• ampliación del contenido;
• comprobación de contraste;
• pruebas con NVDA;
• pruebas con VoiceOver;
• comprobaciones móviles con TalkBack;
• lectura humana del contenido y de los textos alternativos.

axe DevTools está diseñado para integrar pruebas automatizadas de accesibilidad en proyectos web y móviles. Sin embargo, ninguna herramienta automática puede comprobar por sí sola la totalidad de la experiencia.

Qué comprobamos

Área de revisión	Comprobación automática	Revisión manual
Contraste del texto	Sí	Sí
Imágenes sin alt	Sí	Sí
Calidad del texto alternativo	Parcial	Sí
Orden de encabezados	Sí	Sí
Navegación por teclado	Parcial	Sí
Claridad del lenguaje	No	Sí
Etiquetas de formularios	Sí	Sí
Lectura con screen reader	Parcial	Sí
Diseño móvil	Parcial	Sí
Comprensión de tablas	Parcial	Sí

Las herramientas se utilizan como apoyo. Un resultado positivo no debe interpretarse como garantía absoluta de accesibilidad.

Leer con visión reducida

Las necesidades visuales no son idénticas para todos los lectores. Algunas personas necesitan ampliar ligeramente el texto; otras utilizan un contraste elevado, un magnificador o un lector de pantalla. El diseño debe evitar que una sola forma de presentación sea indispensable para entender el contenido.

Procuramos que los textos permanezcan legibles al aumentar el zoom, que las columnas no obliguen a desplazarse horizontalmente de manera innecesaria y que la información importante no dependa únicamente del color.

Las imágenes informativas deberían incluir textos alternativos que expresen su función. Esto se aplica especialmente a:

• gráficos;
• diagramas;
• capturas de interfaces;
• infografías;
• iconos que comunican una acción;
• imágenes que contienen información no repetida en el texto.

Una imagen decorativa, en cambio, debería utilizar un atributo alternativo vacío para que el lector de pantalla pueda ignorarla. Describir cada fondo o adorno introduciría ruido y haría más lenta la navegación.

Cuando una imagen contiene una gran cantidad de información, el texto alternativo breve puede complementarse con una explicación dentro del artículo.

Zoom, contraste y elección de colores

El diseño procura utilizar unidades relativas como rem y em, de modo que el tamaño del texto pueda responder a las preferencias del navegador y del sistema. Una persona debería poder ampliar la página mediante las funciones de zoom sin perder información esencial o acceso a controles.

En una computadora, la ampliación suele realizarse con las opciones del navegador o con combinaciones como Ctrl y +. En macOS puede utilizarse Command y +. Los dispositivos móviles permiten ampliar mediante gestos o configuraciones del sistema.

Para el contraste tomamos como referencia el mínimo de WCAG nivel AA: una relación de 4.5:1 para texto normal y 3:1 para texto grande.

Además:

1. evitamos comunicar estados únicamente mediante rojo o verde;
2. procuramos subrayar o diferenciar visualmente los enlaces;
3. no colocamos texto importante sobre fondos complejos;
4. revisamos botones en estados normal, activo y enfocado;
5. evitamos combinaciones que puedan desaparecer con distintos tipos de daltonismo.

La legibilidad depende tanto del contraste como del tamaño, el espaciado y la claridad tipográfica.

Soporte a lectores de pantalla

La estructura de las páginas procura utilizar HTML semántico. Esto incluye un único encabezado principal, subtítulos ordenados, listas reales, tablas con encabezados y regiones identificables para navegación, contenido principal y pie de página.

Los lectores de pantalla como NVDA, JAWS, VoiceOver y TalkBack utilizan esa estructura para anunciar qué tipo de elemento se encuentra activo. VoiceOver, por ejemplo, permite experimentar y navegar una interfaz sin depender de la visión.

Intentamos que:

• los botones tengan nombres comprensibles;
• los enlaces expliquen su destino;
• las imágenes informativas cuenten con alt;
• los campos del formulario tengan etiquetas visibles;
• los errores se anuncien de forma textual;
• el orden de lectura siga el orden visual;
• los títulos no se utilicen únicamente para cambiar el tamaño del texto;
• los elementos interactivos puedan identificarse sin explorar toda la pantalla.

Las etiquetas ARIA pueden complementar el HTML, pero no deberían reemplazar elementos semánticos que ya cumplen la función necesaria.

Leer con fatiga cognitiva

Una página puede ser técnicamente accesible y seguir siendo difícil de procesar. La fatiga cognitiva puede afectar a personas con dislexia, TDAH, dificultades de memoria, estrés, enfermedades temporales o baja concentración. También puede afectar a quienes leen español como segundo idioma.

Para reducir esa carga procuramos:

• dividir el contenido en párrafos breves;
• utilizar subtítulos descriptivos;
• mantener una idea principal por sección;
• evitar animaciones innecesarias;
• no usar texto parpadeante;
• explicar términos especializados;
• mantener una estructura previsible;
• presentar instrucciones en orden;
• utilizar listas cuando aclaran procesos;
• evitar frases legales innecesariamente complejas.

Los términos habituales de la industria pueden conservarse cuando son necesarios, pero deberían explicarse en su primera aparición. Por ejemplo, wagering es un requisito de apuesta, RTP es el retorno teórico al jugador, KYC es la verificación de identidad y EDD es una revisión reforzada.

Las publicaciones extensas pueden comenzar con una introducción o resumen que permita entender el objetivo antes de leer cada detalle. Una tabla de contenidos también puede ayudar a saltar directamente a la sección necesaria.

Lenguaje y estructura editorial

Barrera posible	Enfoque editorial
Párrafos demasiado extensos	Dividir por idea principal
Uso excesivo de anglicismos	Explicar el término en español
Encabezados genéricos	Utilizar títulos que anticipen el contenido
Instrucciones ambiguas	Indicar acción, orden y resultado
Tablas demasiado densas	Reducir columnas o añadir explicación
Repetición innecesaria	Consolidar ideas relacionadas
Abreviaturas desconocidas	Definirlas en el primer uso
Información esencial solo en una imagen	Repetirla en texto

La simplificación no significa eliminar información importante. Significa organizarla para que resulte más fácil de encontrar y comprender.

Moverse sin ratón

Algunas personas no pueden usar un ratón o una pantalla táctil con precisión debido a temblores, movilidad limitada, lesiones temporales o el uso de dispositivos alternativos. Por eso, las funciones principales deberían estar disponibles desde el teclado.

La navegación habitual debe permitir avanzar con Tab, retroceder con Shift + Tab, activar controles con Enter o la barra espaciadora y utilizar las flechas cuando el componente lo requiera.

El elemento activo necesita una indicación visual clara. Procuramos no eliminar mediante CSS el contorno de foco sin proporcionar una alternativa igualmente visible. La persona debe poder reconocer en todo momento dónde se encuentra.

Las revisiones por teclado buscan confirmar que:

1. el orden de navegación sea lógico;
2. no existan elementos inaccesibles;
3. el foco no quede atrapado;
4. los menús puedan abrirse y cerrarse;
5. el formulario pueda completarse;
6. los enlaces puedan activarse;
7. las ventanas superpuestas devuelvan el foco al cerrarse;
8. no sea obligatorio arrastrar un objeto;
9. el contenido principal pueda alcanzarse sin pasar por decenas de enlaces;
10. las acciones no dependan únicamente de movimientos precisos.

Cuando se utiliza un enlace para saltar al contenido principal, este debe volverse visible al recibir el foco.

Formularios accesibles

El formulario de contacto debe poder comprenderse sin depender de marcadores de posición que desaparecen al escribir. Cada campo debería contar con una etiqueta visible y una instrucción cuando el formato esperado no resulte obvio.

Si aparece un error, el mensaje debería indicar qué ocurrió y cómo corregirlo. No alcanza con cambiar el borde a rojo porque algunas personas no perciben esa diferencia.

Situación	Tratamiento recomendado
Campo obligatorio vacío	Indicar el nombre del campo
Formato incorrecto	Mostrar un ejemplo válido
Mensaje no enviado	Explicar si puede intentarse nuevamente
Límite de caracteres	Informarlo antes de alcanzar el máximo
Confirmación correcta	Mostrar un mensaje textual
Prevención de spam	Evitar pruebas exclusivamente visuales
Sesión vencida	Conservar el contenido cuando sea posible

Los mecanismos de seguridad también deben evaluarse. Un CAPTCHA basado únicamente en identificar imágenes puede excluir a personas ciegas o con dificultades cognitivas.

Elecciones de audio que hicimos

El contenido del sitio es principalmente textual. Esto reduce la dependencia de audio o video para comprender las páginas y facilita el acceso desde conexiones lentas o tecnologías de asistencia.

No buscamos incorporar audio que se reproduzca automáticamente, videos emergentes con sonido ni efectos inesperados. El autoplay puede interferir con lectores de pantalla, dificultar la concentración, consumir datos móviles y exponer al usuario en un entorno compartido.

Cuando una publicación incluya contenido audiovisual en el futuro, procuraremos que disponga de:

• subtítulos sincronizados;
• transcripción textual;
• controles para pausar;
• control de volumen;
• ausencia de reproducción automática;
• identificación de sonidos relevantes;
• descripción de información visual esencial cuando resulte necesaria.

Un video no debería ser la única forma de acceder a instrucciones importantes. Siempre que sea posible, la información principal se ofrecerá también por escrito.

Los archivos de audio extensos deberían incluir una transcripción que permita buscar, copiar o revisar una sección concreta sin escuchar la grabación completa.

Realidad móvil en Argentina

Una parte importante de la audiencia argentina navega desde celulares y depende de redes móviles cuya velocidad y estabilidad varían según la localidad, el operador y el momento del día. La accesibilidad también incluye permitir que una página cargue y pueda utilizarse en esas condiciones.

Procuramos reducir el peso innecesario mediante:

• imágenes optimizadas;
• formatos modernos como WebP o AVIF cuando resultan compatibles;
• carga diferida de imágenes ubicadas fuera de la primera pantalla;
• dimensiones definidas para evitar movimientos inesperados;
• uso moderado de scripts externos;
• código reutilizable;
• fuentes limitadas;
• ausencia de videos automáticos;
• diseño adaptable a pantallas pequeñas.

Los controles táctiles deberían ser suficientemente grandes y mantener espacio entre sí. Como objetivo práctico, intentamos aproximarnos a áreas de interacción de alrededor de 44 × 44 píxeles cuando el diseño lo permite, especialmente en botones, menús y elementos que se usan con frecuencia.

La página no debería exigir una precisión extrema para cerrar un aviso, abrir el menú o seleccionar una opción.

Uso con distintas configuraciones móviles

Una página móvil debería seguir siendo utilizable cuando la persona:

1. aumenta el tamaño de fuente del sistema;
2. activa el modo de alto contraste;
3. utiliza TalkBack o VoiceOver;
4. gira el dispositivo;
5. navega con una sola mano;
6. desactiva animaciones;
7. utiliza una conexión lenta;
8. bloquea scripts no esenciales;
9. accede desde una pantalla pequeña;
10. utiliza control por voz.

TalkBack forma parte del conjunto de herramientas de accesibilidad de Android y proporciona respuesta hablada y navegación mediante gestos.

No podemos garantizar compatibilidad perfecta con cada combinación de dispositivo, navegador y configuración, pero los problemas reproducibles pueden incorporarse al proceso de revisión.

Qué no podemos cambiar en contenido externo

Los artículos pueden incluir capturas de MyStake u otros operadores, fragmentos de documentos regulatorios, gráficos externos, videos incrustados o enlaces hacia sitios de terceros. La redacción no controla el código, el contraste, los formularios ni las herramientas de accesibilidad del recurso externo.

Una captura de un casino puede mostrar:

• tipografía pequeña;
• botones con poco contraste;
• texto dentro de imágenes;
• información difícil de ampliar;
• controles que no cumplen nuestros criterios.

No podemos rediseñar la interfaz original del operador. Podemos, sin embargo, reducir la barrera mediante un texto alternativo, una explicación cercana o una descripción de la acción ilustrada.

Cuando se enlaza un PDF regulatorio, intentamos aclarar su contenido y propósito. No siempre podemos garantizar que el documento externo esté correctamente etiquetado para lectores de pantalla.

Un enlace hacia un tercero tampoco significa que aprobemos sus prácticas de accesibilidad. Después de abandonar nuestro dominio, la experiencia queda bajo la responsabilidad del sitio externo.

Cómo compensamos limitaciones externas

Cuando un elemento externo resulta necesario, podemos aplicar una o más de estas medidas:

• describir la imagen;
• resumir el documento;
• explicar qué encontrará el lector;
• evitar que la captura sea la única fuente;
• indicar el formato del archivo;
• advertir que el recurso abre otro sitio;
• proporcionar un enlace directo al documento;
• transcribir datos importantes;
• evitar incrustaciones que bloqueen la navegación;
• reemplazar elementos externos cuando existe una alternativa accesible.

La posibilidad de aplicar estas medidas depende de los derechos de uso, el formato y la información disponible.

Contarnos sobre las barreras

Si encontrás una dificultad para leer, navegar o utilizar una función, podés informarla mediante el formulario de contacto del sitio. Los avisos concretos ayudan a reproducir el problema y suelen revisarse con prioridad.

Al escribir, incluí cuando sea posible:

1. la URL de la página;
2. una descripción breve de la barrera;
3. el dispositivo utilizado;
4. el navegador y su versión aproximada;
5. la tecnología de asistencia;
6. la acción que intentabas realizar;
7. el resultado esperado;
8. lo que ocurrió realmente.

No hace falta enviar datos personales, documentos ni información de cuentas de casino. Una explicación como “el foco desaparece al abrir el menú con teclado” resulta más útil que un mensaje general indicando que la página no es accesible.

El formulario es editorial. No sirve para reportar barreras dentro de MyStake u otra plataforma externa.

Tipos de barreras que podés reportar

Problema	Ejemplo
Texto ilegible	Contraste insuficiente
Navegación inaccesible	Menú que no funciona con teclado
Imagen sin descripción	Infografía sin alt
Lectura incorrecta	Encabezados anunciados fuera de orden
Formulario confuso	Campo sin etiqueta
Diseño móvil	Botones demasiado cercanos
Movimiento inesperado	Contenido que cambia de posición
Problema cognitivo	Instrucción difícil de comprender
Multimedia	Video sin subtítulos
Documento externo	PDF imposible de leer con screen reader

Cuanto más precisa sea la descripción, más fácil será identificar la causa.

Nuestro ritmo de actualización

La accesibilidad se incorpora al mantenimiento general del sitio. Cuando se modifica una plantilla, se agrega una función o se reorganiza la navegación, procuramos comprobar que los cambios no hayan introducido nuevas barreras.

Las revisiones pueden realizarse en distintos momentos:

• durante la preparación de una página;
• antes de publicar un cambio importante;
• después de modificar plantillas;
• al recibir un reporte;
• durante auditorías periódicas;
• cuando cambia una recomendación técnica;
• después de actualizar componentes.

Los controles automáticos pueden ejecutarse con mayor frecuencia porque permiten detectar rápidamente errores básicos. Las evaluaciones manuales con teclado, zoom y lectores de pantalla requieren más tiempo y pueden realizarse en ciclos más amplios, por ejemplo después de un rediseño importante o dentro de una revisión anual.

No garantizamos una frecuencia idéntica para todas las páginas. Las prioridades dependen de la gravedad del problema, la cantidad de usuarios afectados y la importancia de la función bloqueada.

Cómo priorizamos las correcciones

Generalmente reciben mayor prioridad los problemas que:

1. impiden acceder al contenido principal;
2. bloquean el formulario;
3. atrapan el foco del teclado;
4. ocultan información esencial;
5. afectan varias páginas;
6. impiden usar un lector de pantalla;
7. provocan movimiento peligroso o inesperado;
8. dificultan tareas básicas desde el celular.

Los ajustes de estilo que no impiden el acceso también son importantes, pero pueden incorporarse en una actualización posterior.

Tu feedback en el circuito

Los comentarios sobre accesibilidad no se tratan únicamente como mensajes aislados. Una barrera específica puede revelar un problema repetido en una plantilla, una tabla o un tipo de imagen. Cuando eso ocurre, la corrección puede extenderse a varias páginas.

La redacción procura:

• confirmar que el mensaje fue comprendido;
• reproducir el problema;
• evaluar su impacto;
• identificar si afecta otras secciones;
• aplicar una corrección razonable;
• comprobar nuevamente la función;
• registrar el aprendizaje para futuros contenidos.

Cuando sea posible, podemos informar al lector que señaló el problema sobre el resultado de la revisión. Sin embargo, no se garantiza una respuesta individual ni un plazo exacto para cada ajuste.

También podés enviar una propuesta técnica concreta mediante el formulario, por ejemplo, una mejora en el orden del foco, una etiqueta más clara o una alternativa para una tabla. No hace falta utilizar lenguaje especializado: explicar qué barrera encontraste y qué necesitabas hacer ya aporta información valiosa.