Declaración de Accesibilidad: Objetivos WCAG 2.1 AA + Excepciones
Declaración de accesibilidad en lenguaje claro: objetivo WCAG 2.1 AA, pipeline axe-core + Lighthouse, una excepción de color de marca documentada. Reporta una barrera.
La mayoría de las declaraciones de accesibilidad de este sector o mienten de plano ("¡100% conforme con WCAG AA!") o pegan una plantilla genérica que entierra cada excepción conocida tras una cortina de humo de jerga de conformidad. Esta es más corta, está organizada en torno a lo que de verdad necesitas saber, y es franca sobre la única excepción documentada que aceptamos. La escribí como me gustaría que me la escribieran a mí si yo fuera quien la lee.
bestgirlfriend.ai es un comparador editorial que cubre apps de novia virtual IA, apps de novio virtual IA, sitios de cam, creadores de modelos reales y juegos para adultos. La accesibilidad es parte de la base editorial, no una función que se añade a última hora en el lanzamiento. Esta página documenta los estándares con los que construimos, las técnicas que usamos, la única excepción que aceptamos y por qué, los vacíos que aún tenemos pendientes, y el canal para reportar una barrera.
Esta declaración se alinea con la refundición de la Section 508 de EE. UU. (29 U.S.C. §794d, armonizada con la WCAG 2.0 AA mediante la ICT Refresh de 2018), el estándar armonizado europeo EN 301 549 v3.2.1 (referenciado por la Directiva de Accesibilidad Web 2016/2102 y el European Accessibility Act 2019/882, exigible desde el 28 de junio de 2025), las Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 del Reino Unido, y la Accessibility for Ontarians with Disabilities Act, 2005 y su Integrated Accessibility Standards Regulation. Somos un editor privado, no un organismo del sector público, pero nos exigimos el mismo nivel de conformidad porque el mínimo legal es el punto de partida correcto.
¿bestgirlfriend.ai cumple con la WCAG?
Nuestro objetivo es la WCAG 2.1 nivel AA en cada página pública y cumplimos el objetivo en todos los criterios de éxito salvo una excepción documentada: el color de marca #E94B6A sobre crema #FAF7F2 produce un contraste de 3,46:1, por debajo del mínimo AA de 4,5:1 para el texto del cuerpo. El coral está restringido a botones, distintivos, enlaces y acentos decorativos (la superficie de 3:1 según WCAG 1.4.11), nunca se usa para la prosa del cuerpo. Todos los demás criterios de éxito se cumplen, y la excepción queda registrada con sus mediciones en nuestro sistema de diseño.
Última revisión: 2026
La conformidad es algo que sigues haciendo, no una casilla que marcas una vez. El sitio está construido con WCAG 2.1 AA, los cuatro principios (perceptible, operable, comprensible, robusto) están integrados en cómo se diseñan las páginas, y cada commit pasa las comprobaciones automáticas antes de fusionarse. El único compromiso que aceptamos es el contraste del color de marca en el acento coral, y lo decimos de entrada en vez de esconderlo en una nota de conformidad parcial al final de la página. El resto de esta página documenta qué significa eso en concreto.
¿Qué estándares seguimos?
La WCAG 2.1 nivel AA es nuestro objetivo de ingeniería. La referencian la Section 508 de EE. UU. (ICT Refresh 2018), el estándar armonizado europeo EN 301 549 v3.2.1, la Directiva de Accesibilidad Web 2016/2102 de la UE, el European Accessibility Act 2019/882 (exigible desde el 28 de junio de 2025), las Public Sector Bodies Accessibility Regulations 2018 del Reino Unido, y el Integrated Accessibility Standards Regulation de la AODA de Ontario.
La WCAG 2.1 AA es la lengua franca global de la accesibilidad digital [Source: W3C, Pautas de Accesibilidad para el Contenido Web 2.1, Recomendación del W3C del 5 de junio de 2018 · verified 2026-05-26]. La Section 508 la referencia mediante la ICT Refresh de EE. UU. [Source: Section 508 de EE. UU., estándares de la ICT Refresh · verified 2026-05-26]. La EN 301 549 la referencia como el estándar europeo armonizado [Source: ETSI EN 301 549, requisitos de accesibilidad para productos y servicios TIC · verified 2026-05-26]. Las regulaciones británicas de 2018 la nombran de forma explícita. La AODA la referencia mediante el Integrated Accessibility Standards Regulation.
Elegir AA significa que satisfacemos los cinco regímenes desde un solo objetivo de ingeniería. Vigilamos la WCAG 2.2 (publicada en octubre de 2023) y vamos incorporando sus criterios de éxito donde no chocan con la 2.1. Moveremos nuestra declaración pública de conformidad a 2.2 AA cuando los estándares de contratación de nuestros mercados clave la citen.
El panorama de estándares converge en la WCAG 2.1 AA como el objetivo de ingeniería verificable. Los cinco regímenes que rigen nuestros mercados, cada uno enlazado a su referencia canónica:
| Estándar | Región | Nivel de cumplimiento | Nuestro estado | Referencia |
|---|---|---|---|---|
| WCAG 2.1 AA | Global (W3C) | Nivel AA | Objetivo (1 excepción documentada) | Recomendación del W3C, 5 de junio de 2018 |
| EN 301 549 v3.2.1 | Unión Europea | Estándar armonizado, AA | Objetivo (1 excepción documentada) | ETSI, marzo de 2021; referenciado por la WAD 2016/2102 y el EAA 2019/882 |
| Section 508 (ICT Refresh) | Estados Unidos | WCAG 2.0 AA armonizada; AA | Objetivo (con delta WCAG 2.1 AA, 1 excepción documentada) | 36 CFR Part 1194, U.S. Access Board 2018 |
| Public Sector Bodies Accessibility Regulations 2018 del Reino Unido | Reino Unido | WCAG 2.1 AA | Objetivo (editor privado; voluntario) | SI 2018/952 |
| AODA / IASR | Ontario, Canadá | WCAG 2.0 AA (IASR §14) | Objetivo (con delta WCAG 2.1 AA, 1 excepción documentada) | O. Reg. 191/11, Integrated Accessibility Standards |
¿Cuáles son las excepciones de accesibilidad conocidas?
Dos. (1) Excepción de contraste del color de marca: el coral #E94B6A sobre crema #FAF7F2 produce 3,46:1, por debajo del mínimo AA de 4,5:1 para el texto del cuerpo. El coral está restringido a botones, distintivos, enlaces y acentos decorativos (la superficie de 3:1 según WCAG 1.4.11), nunca se usa para la prosa del cuerpo. (2) Las imágenes de Open Graph para compartir en algunas páginas de listas carecen de texto alternativo descriptivo para lectores de pantalla cuando aparecen dentro de las vistas previas sociales de terceros (cosmético; en remediación). El chatbot AI Concierge aún no ha completado su auditoría completa y no se publicará hasta que lo haga.
Listar las excepciones conocidas en público es la contraparte honesta de una declaración de conformidad. La conformidad WCAG es binaria a nivel de criterio de éxito: una página cumple el criterio o no lo cumple. No mezclamos una nota de conformidad parcial dentro del cuerpo de la página; las excepciones viven aquí, en lenguaje claro, con su justificación y su estado de remediación.
La excepción del color de marca, en detalle. Nuestro color de acento principal (#E94B6A, el coral de botones y distintivos) sobre nuestro fondo editorial (#FAF7F2, el crema cálido) produce una ratio de contraste de 3,46:1. La WCAG 2.1 AA exige 4,5:1 para el texto normal del cuerpo (SC 1.4.3) y 3:1 para el texto grande y para los componentes de interfaz y objetos gráficos (SC 1.4.11). La ratio de 3,46:1 satisface el mínimo de 3:1 para la superficie de interfaz y texto grande, y se queda corta ante el mínimo de 4,5:1 para la prosa del cuerpo.
Tomamos la decisión de aceptar el compromiso solo para la superficie del acento de marca. El coral aparece en los botones de llamada a la acción, los subrayados de enlaces, los distintivos, la barra fija de promoción y los acentos decorativos, todas superficies donde aplica el mínimo de 3:1. La prosa del cuerpo, los encabezados y el resto del texto usan #1A1A1A, un casi negro sobre el crema, que supera 4,5:1 con holgura. La decisión está documentada en nuestro sistema de diseño junto con las mediciones de contraste, así que el compromiso es revisable en vez de invisible.
La mayoría de las webs de reseñas de este sector ni siquiera saca a la luz este tipo de compromiso de marca. Declaran conformidad AA completa, y la auditoría nunca pilla el déficit del color de acento porque la auditoría nunca se hizo. Nosotras hacemos la auditoría, registramos el resultado y te lo contamos. Esa es la diferencia entre una declaración de accesibilidad de verdad y una plantilla copiada y pegada.
Problemas abiertos:
| ID | Problema | Severidad | Estado | Corrección objetivo |
|---|---|---|---|---|
| A11Y-001 | Color de marca (#E94B6A) sobre crema (#FAF7F2) = 3,46:1, por debajo del mínimo AA de 4,5:1 para texto del cuerpo | Excepción aceptada (solo interfaz/acento; la prosa del cuerpo no se ve afectada) | Documentado en los tokens de diseño | Sin corrección prevista sin un cambio de color de marca |
| A11Y-002 | Texto alternativo de imagen Open Graph en las vistas previas sociales de páginas de listas | Cosmético (no afecta a la lectura en el sitio) | En remediación | T3 2026 |
| A11Y-003 | Auditoría completa WCAG 2.1 AA del chatbot AI Concierge | Bloqueante (el chatbot no se publicará hasta superarla) | Auditoría pendiente antes de la publicación | Antes de publicar |
Si encuentras un problema que no está en esta lista, repórtalo, por favor. La lista se actualiza cada vez que se descubre un problema nuevo o se cierra uno existente.
¿Cómo reporto un problema de accesibilidad?
Escribe a [email protected] con la URL de la página, tu navegador y tu tecnología de asistencia, y una breve descripción de la barrera. Acusamos recibo de cada reporte en 2 días hábiles y, para los problemas bloqueantes, ponemos como objetivo una resolución o una solución alternativa en 7 días hábiles. Los problemas que no pueden cumplir el objetivo de 7 días reciben una mitigación provisional pública más una fecha objetivo de corrección en el registro de Problemas Conocidos de esta página.
El buzón dedicado es [email protected]. Para ayudarnos a reproducir y corregir más rápido, incluye en la medida de lo posible:
- La URL de la página donde te topaste con la barrera.
- Tu sistema operativo y navegador (y la versión).
- La tecnología de asistencia que usaste (lector de pantalla, conmutador, magnificador, control por voz, etc.) y su versión.
- Una breve descripción de qué esperabas y qué pasó en su lugar.
- Una captura de pantalla o una grabación, si la tienes a mano y te sientes cómoda compartiéndola.
También puedes pedir esta declaración, un resumen de auditoría o una corrección concreta en un formato alternativo (letra grande, correo en texto plano, una llamada de vuelta) escribiendo a la misma dirección. No exigimos ninguno de estos datos para investigar; solo nos ayudan a reproducir el problema.
El acuerdo de nivel de servicio es voluntario y se publica aquí precisamente para que sea verificable. Si incumplimos el acuse de 2 días o el objetivo de 7 días en un problema bloqueante, eso ya es un fallo documentado y lo documentaremos en esta página. Las vías legales de escalado, por ejemplo, las quejas ante la Equality and Human Rights Commission del Reino Unido, la línea de la ADA del Departamento de Justicia de EE. UU. o el equivalente de tu país, están disponibles independientemente de cómo gestionemos el reporte internamente.
¿Qué hay del soporte para lectores de pantalla?
Probamos con NVDA y JAWS en Windows, VoiceOver en macOS e iOS, y TalkBack en Android. Los encabezados, las regiones y las listas se anuncian correctamente. Los campos de formulario llevan etiquetas visibles y programáticas. Los iconos decorativos usan alt vacío o aria-hidden. Las imágenes editoriales llevan texto alternativo escrito por editores, no por desarrolladores, así que el alt refleja la intención.
Los lectores de pantalla no ven lo que ven las personas videntes; analizan el árbol del documento. Por eso el HTML semántico, y no el ARIA, carga el primer peso de la accesibilidad aquí. Añadimos ARIA solo donde la semántica nativa del HTML se queda corta (regiones dinámicas en el contenido que cambia, roles de diálogo en las ventanas modales, estados de expansión en los widgets de revelado), según la primera regla del ARIA: si un elemento nativo aporta la semántica, úsalo. La cobertura de lectores de pantalla se vuelve a probar en cada versión mayor, y guardamos las transcripciones de las pruebas en archivo.
¿Cómo se soporta la navegación por teclado?
Cada elemento interactivo se puede operar con teclado. Un enlace para saltar al contenido principal es el primer elemento enfocable de cada página. El orden de tabulación sigue el orden de lectura visual. Los indicadores de foco cumplen 3:1 de contraste en modo claro y oscuro. El cajón móvil y la ventana de idiomas atrapan el foco cuando se abren y lo restauran al cerrarse, así que quien solo usa teclado nunca se queda atrapado.
El contrato del teclado es la superficie que probamos con más dureza, porque hace de sustituto de cualquier tecnología de asistencia que emule un teclado, incluidos los conmutadores y los teclados en pantalla. Los enlaces de salto satisfacen la WCAG 2.4.1 Evitar bloques, los indicadores de foco visibles satisfacen la WCAG 2.4.7 Foco visible, y la regla de no atrapar el teclado satisface la WCAG 2.1.2. El comportamiento de atrapado de foco en las ventanas modales sigue el patrón de diálogo de la Guía de Prácticas de Autoría ARIA del W3C, con el foco restaurado al elemento que lo disparó al cerrarse.
¿Qué funciones de accesibilidad vienen integradas?
Entre las funciones integradas hay HTML semántico (header, nav, main, footer, article, aside), jerarquía estricta de encabezados con un solo H1 por página, texto alternativo descriptivo en las ilustraciones editoriales, imágenes decorativas marcadas con alt="", títulos de tabla con encabezados con ámbito, transcripciones en cada vídeo incrustado, soporte de prefers-reduced-motion e indicadores de foco visibles que cumplen 3:1 de contraste en los temas claro y oscuro.
El inventario completo de funciones, mapeado a su criterio de éxito WCAG subyacente:
- Regiones semánticas (
<header>,<nav>,<main>,<footer>,<article>,<aside>), WCAG 1.3.1 Información y relaciones. - Un solo H1 por página, jerarquía estricta H2/H3, sin saltarse niveles, WCAG 2.4.6 Encabezados y etiquetas.
- Saltar al contenido principal como primer elemento enfocable, WCAG 2.4.1.
- Texto alternativo descriptivo escrito por la redacción, no autogenerado; la imaginería decorativa usa
alt="", WCAG 1.1.1 Contenido no textual. - Las tablas llevan
<caption>y<th scope="col" | "row">, WCAG 1.3.1. - El vídeo incrustado usa
youtube-nocookie.com, se publica con transcripción en la página, nunca se reproduce solo, WCAG 1.2.1, 1.2.2, 1.2.3. - Movimiento reducido:
@media (prefers-reduced-motion: reduce)desactiva el parallax, los carruseles de desplazamiento automático y las transiciones decorativas, WCAG 2.3.3 Animación a partir de interacciones. - Contraste de color: 4,5:1 en el cuerpo, 3:1 en el texto grande y la interfaz en ambos modos (WCAG 1.4.3 Contraste mínimo, 1.4.11 Contraste no textual), con la única excepción documentada del acento de marca señalada arriba.
- Ningún significado transmitido solo por color, WCAG 1.4.1 Uso del color.
- Redimensionar el texto hasta el 200% sin pérdida de contenido, WCAG 1.4.4.
- Reflujo a 320 píxeles CSS sin desplazamiento horizontal, WCAG 1.4.10.
- Etiquetas de formulario, identificación de errores, sugerencia ante errores, WCAG 1.3.1, 3.3.1, 3.3.3.
- Los títulos de página describen el tema o el propósito, WCAG 2.4.2.
- El idioma de la página se declara mediante el atributo
langdel elemento HTML raíz; las anulaciones por sección, mediante atributoslangen línea, WCAG 3.1.1, 3.1.2.
¿Cómo se gestiona el texto de derecha a izquierda?
Las páginas en árabe (ar) y hebreo (he-IL) se renderizan en disposición de derecha a izquierda mediante propiedades lógicas de CSS (margin-inline-start, padding-inline-end) en lugar de valores fijos de izquierda y derecha. Cada componente, incluidos el encabezado, la navegación, las llamadas a la acción, el pie de página, la barra móvil fija y las ventanas modales, se refleja correctamente. Hicimos una prueba de estrés del cromo completo en una plantilla AR dedicada antes del lanzamiento y documentamos el resultado en nuestro sistema de diseño.
El soporte de derecha a izquierda no es un asunto de traducción; es un asunto de disposición. Cambiar el atributo dir del documento a "rtl" voltea el inicio y el fin en línea por toda la disposición, porque cada espaciado, alineación y flotación se expresa en propiedades lógicas. El contenido bidireccional (URLs en alfabeto latino dentro de prosa en árabe, por ejemplo) se envuelve en elementos <bdi> de HTML para que el algoritmo bidireccional se renderice de forma predecible. Mantenemos una auditoría completa de derecha a izquierda en una página de prueba en árabe dedicada y la volvemos a pasar antes de cada versión.
¿Cómo interactúa el modo oscuro con la accesibilidad?
El modo oscuro es un interruptor manual en el encabezado y respeta prefers-color-scheme en la primera visita. El texto del cuerpo se mantiene en 4,5:1 o más en ambos modos; el texto grande y los componentes de interfaz se quedan por encima de 3:1 (con la excepción documentada del acento de marca). El color nunca es el único portador de significado, así que las personas con deficiencia de visión cromática o en entornos monocromáticos no pierden información al cambiar de modo.
Última revisión: 2026
El modo oscuro se implementa mediante un atributo data-theme="dark" en el elemento raíz del documento, que cambia las propiedades personalizadas de CSS en la raíz. El interruptor guarda la elección del usuario en localStorage, y si el usuario no ha elegido, seguimos prefers-color-scheme. Ambas paletas se auditan de forma independiente contra los mínimos de contraste WCAG 1.4.3 y 1.4.11. El modo oscuro va más allá del gusto estético. Las Human Interface Guidelines de Apple y la accesibilidad de GOV.UK lo reconocen como una adaptación para la fotofobia, la migraña y la baja visión, así que la garantía de contraste aplica en ambas direcciones.
¿Los vídeos están transcritos?
Sí. Cada vídeo incrustado usa el dominio youtube-nocookie.com y se publica con una transcripción escrita en la página, debajo del vídeo. Los subtítulos están activados en la fuente de YouTube. Los vídeos no se reproducen solos, no se repiten en bucle y ofrecen controles de pausa y parada. Cuando faltan los subtítulos de la fuente, añadimos una transcripción manual antes de publicar.
Las transcripciones no son opcionales aquí. Sirven a los lectores sordos y con dificultades auditivas (el público para el que se escriben), a los lectores en entornos con el sonido apagado como el trabajo o el transporte, a quienes aprenden idiomas y se apoyan en el texto que refuerza el audio, y a los motores de búsqueda y rastreadores de IA que pueden leer el contenido legible por máquina que los píxeles del vídeo no exponen. Un solo artefacto, cuatro beneficios.
¿Cómo gestionan el movimiento reducido?
El sitio respeta la consulta de medios CSS prefers-reduced-motion. Cuando un usuario tiene el movimiento reducido activado a nivel del sistema operativo, desactivamos el parallax, los carruseles de desplazamiento automático, las animaciones que se reproducen solas y las transiciones decorativas. El movimiento esencial de la interfaz (indicadores de foco, despliegues de menús) se mantiene porque comunica estado. Nada en el sitio parpadea más de tres veces por segundo.
El umbral de los tres destellos satisface la WCAG 2.3.1 Tres destellos o por debajo del umbral, el criterio de prevención de convulsiones. El cumplimiento del movimiento reducido atiende los trastornos vestibulares, las náuseas inducidas por movimiento y las necesidades de accesibilidad relacionadas con la atención documentadas en la literatura del grupo de trabajo de Accesibilidad Cognitiva del W3C. La implementación es una sola consulta de medios, aplicada en la capa de tokens de diseño; no hace falta JavaScript para que la preferencia del usuario surta efecto.
¿Con qué frecuencia hacen pruebas?
En tiempo de compilación: axe-core se ejecuta contra cada historia de componente y cada captura de página en CI. Las compilaciones fallan ante violaciones graves o críticas. Antes de fusionar: las solicitudes de incorporación de cambios llevan un mínimo de puntuación de Lighthouse Accessibility de 95 y la GitHub Action bloquea las fusiones por debajo de eso. Las pasadas manuales de lector de pantalla (NVDA, JAWS, VoiceOver, TalkBack) se hacen cada trimestre sobre un conjunto representativo de páginas y ad hoc en cualquier plantilla nueva.
Las pruebas van por capas: automáticas donde la herramienta es fiable, manuales donde las personas siguen siendo la única señal que importa.
- En tiempo de compilación:
axe-corese ejecuta contra cada historia de componente y cada captura de página en CI. Las compilaciones fallan ante violaciones graves o críticas. - Antes de fusionar: las solicitudes de incorporación de cambios llevan un mínimo de puntuación de Lighthouse Accessibility de 95 y la GitHub Action bloquea las fusiones por debajo de eso.
- Pasadas manuales de lector de pantalla: NVDA, JAWS, VoiceOver (macOS + iOS), TalkBack, cada trimestre sobre un conjunto representativo de páginas, ad hoc en cualquier plantilla nueva.
- Pasada solo con teclado: cada tipo de página nuevo se navega de principio a fin con teclado antes de fusionarse, y el registro de la prueba se archiva junto al cambio.
- Auditoría del orden de lectura: el orden de tabulación se compara con el orden de lectura visual en cada plantilla.
- Simulación de daltonismo: Sim Daltonism y el panel de renderizado de Chrome DevTools simulan la protanopia, la deuteranopia y la tritanopia en cada paleta publicada. La excepción de contraste del color de marca se registra aquí.
- Comentarios de usuarios reales: cada barrera reportada a
[email protected]se archiva como un ticket y se sigue de forma pública en la tabla de Problemas Conocidos de esta página.
La combinación sigue la guía de pruebas de accesibilidad de GOV.UK: las herramientas automáticas pillan aproximadamente entre el 30 y el 40% de los problemas, y el resto solo sale cuando las personas usan tecnología de asistencia en condiciones realistas.
¿Cuál es el acuerdo de nivel de servicio para las quejas de accesibilidad?
Acusamos recibo de las quejas de accesibilidad en 2 días hábiles en [email protected]. Las barreras bloqueantes (una función inutilizable con tecnología de asistencia) tienen un objetivo de resolución de 7 días hábiles. Los problemas no bloqueantes reciben una fecha objetivo de corrección documentada y aparecen en el registro de Problemas Conocidos hasta que se cierran. Los derechos legales de escalado siguen disponibles por debajo de este acuerdo de nivel de servicio voluntario.
El acuerdo de nivel de servicio es voluntario y se publica aquí precisamente para que sea verificable. Si incumplimos el acuse de 2 días o el objetivo de 7 días en un problema bloqueante, eso ya es un fallo documentado y lo documentaremos en esta página. Las vías legales de escalado, por ejemplo, las quejas ante la Equality and Human Rights Commission del Reino Unido, la línea de la ADA del Departamento de Justicia de EE. UU. o el equivalente de tu país, están disponibles independientemente de cómo gestionemos el reporte internamente.
¿Cómo gestiona la accesibilidad el chatbot AI Concierge?
El chatbot AI Concierge (antes de publicarse) no se publicará hasta que supere una auditoría completa WCAG 2.1 AA que cubra la operabilidad por teclado, los anuncios de lector de pantalla (región dinámica para las respuestas en streaming), la gestión del foco al abrir y cerrar el panel, y el cumplimiento del movimiento reducido. Hasta entonces, todo el contenido editorial es accesible sin el chatbot mediante los acordeones de preguntas frecuentes de la página.
Las interfaces conversacionales ponen a prueba la accesibilidad de maneras en que las páginas estáticas no lo hacen. El texto en streaming necesita regiones dinámicas ARIA corteses, el foco tiene que moverse de forma predecible entre el disparador, el panel y el cierre, quien usa teclado necesita una salida documentada, y quien usa movimiento reducido necesita que se respeten sus preferencias en la transición del panel. La auditoría del Concierge seguirá el patrón de diálogo de la APG ARIA del W3C para el comportamiento del panel y la guía de regiones dinámicas WAI-ARIA para las respuestas en streaming. Adjuntaremos la transcripción completa de la auditoría a esta página cuando el chatbot se publique.
¿Qué son la Section 508 y el European Accessibility Act 2025?
La Section 508 de la Rehabilitation Act de EE. UU. (29 U.S.C. §794d, ICT Refresh 2018) obliga a las agencias federales y a los contratistas federales a contratar y mantener tecnología de la información accesible, armonizada con la WCAG 2.0 AA mediante el 36 CFR Part 1194. El European Accessibility Act (Directiva 2019/882, exigible desde el 28 de junio de 2025) extiende los deberes de accesibilidad a una amplia gama de productos y servicios del sector privado, también armonizados con la WCAG 2.1 AA mediante la EN 301 549.
Ambos regímenes convergen en el mismo objetivo de ingeniería. Por eso una sola postura de conformidad satisface a los dos, y por eso elegimos la barra aplicable más alta (WCAG 2.1 AA mediante la EN 301 549 v3.2.1) y la tratamos como el mínimo en cada página pública del sitio, no solo en las superficies tocadas por contratos federales de EE. UU. u obligaciones de servicio de la UE.
La fecha de exigibilidad del 28 de junio de 2025 del EAA importa para editores privados como nosotras. Es el momento en que "declaración de accesibilidad en la web" deja de ser una cortesía y se convierte en un artefacto verificable por el regulador en los estados miembros que han transpuesto la directiva. Publicamos esta declaración bastante antes de esa fecha, con la única excepción documentada de arriba, porque preferimos tener la conversación sobre nuestro compromiso de color de marca ahora que tener que responder por él más tarde.
Cómo citar esta página
Si referencias esta declaración en un trabajo académico, regulatorio o periodístico, cítala así:
Joly, A. (2026). Declaración de Accesibilidad: Objetivos WCAG 2.1 AA, Excepciones y Reportes para bestgirlfriend.ai. bestgirlfriend.ai. https://bestgirlfriend.ai/es/accessibility
Hay un resumen legible por máquina publicado en /llms.txt para la ingesta de los rastreadores de búsqueda con IA.
Preguntas frecuentes
Última revisión: 2026.
¿bestgirlfriend.ai cumple con la WCAG?
Nuestro objetivo son las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.1 nivel AA en cada página pública. Cumplimos el objetivo en todos los criterios de éxito salvo una excepción documentada: nuestro color de marca #E94B6A sobre crema #FAF7F2 da una ratio de contraste de 3,46:1, por debajo del mínimo AA de 4,5:1 para el texto del cuerpo. Usamos el color de marca solo en botones, distintivos y acentos decorativos (tratados como texto grande y elementos de interfaz según WCAG 1.4.11), nunca para la prosa del cuerpo. Nuestra alineación con los estándares mapea a la Section 508 de EE. UU., la EN 301 549 de la UE, las Public Sector Bodies Accessibility Regulations 2018 del Reino Unido y la AODA de Ontario.
¿Qué estándares seguimos?
La WCAG 2.1 nivel AA es nuestro objetivo de ingeniería. La referencian la Section 508 de EE. UU. (ICT Refresh 2018), el estándar armonizado europeo EN 301 549 v3.2.1, la Directiva de Accesibilidad Web 2016/2102 de la UE, el European Accessibility Act 2019/882 (exigible desde el 28 de junio de 2025), las Public Sector Bodies Accessibility Regulations 2018 del Reino Unido y el Integrated Accessibility Standards Regulation de la AODA de Ontario. Seguimos los criterios de éxito de la WCAG 2.2 como meta de compatibilidad futura, pero nuestra declaración pública de conformidad se mantiene en 2.1 AA hasta que la 2.2 entre en las leyes regionales de contratación pública.
¿Cuáles son las excepciones de accesibilidad conocidas?
Dos. (1) Excepción de color de marca: el coral #E94B6A sobre crema #FAF7F2 da 3,46:1, por debajo del mínimo AA de 4,5:1 para el texto del cuerpo. Restringimos el coral a botones, distintivos, enlaces y acentos decorativos (donde aplica el mínimo de 3:1 para interfaz y texto grande según WCAG 1.4.11), nunca para la prosa del cuerpo; el compromiso está documentado en nuestro sistema de diseño. (2) Algunas imágenes de Open Graph para compartir en páginas de listas carecen de texto alternativo descriptivo para lectores de pantalla cuando aparecen dentro de las vistas previas sociales de terceros (cosmético; en remediación). El chatbot no se publicará hasta que supere una auditoría completa de teclado y lector de pantalla.
¿Cómo reporto un problema de accesibilidad?
Escribe a [email protected] con la URL de la página, la versión de tu navegador y de tu tecnología de asistencia, y una breve descripción de la barrera. Acusamos recibo de cada reporte en 2 días hábiles. Las barreras bloqueantes (una función queda inutilizable con tecnología de asistencia) tienen un objetivo de resolución de 7 días hábiles. Los problemas no bloqueantes reciben una fecha objetivo de corrección documentada y aparecen en la tabla de Problemas Conocidos de esta página hasta que se cierran. Los derechos legales de escalado siguen disponibles independientemente de nuestro acuerdo de nivel de servicio interno.
¿Qué hay del soporte para lectores de pantalla?
Probamos con NVDA en Windows, JAWS en Windows, VoiceOver en macOS e iOS, y TalkBack en Android. Los encabezados, las regiones y las listas se anuncian correctamente. Los campos de formulario llevan etiquetas visibles y programáticas. Los iconos decorativos usan alt vacío o aria-hidden. Las imágenes editoriales llevan texto alternativo descriptivo escrito por editores, no por desarrolladores, así que el alt refleja la intención. El HTML semántico es nuestra primera línea de defensa; el ARIA se añade solo donde la semántica nativa del HTML no basta, según la primera regla del ARIA.
¿Cómo se soporta la navegación por teclado?
Cada elemento interactivo de bestgirlfriend.ai se puede operar con teclado. Un enlace para saltar al contenido principal es el primer elemento enfocable de cada página. El orden de tabulación sigue el orden de lectura visual. Los indicadores de foco tienen al menos 3:1 de contraste en modo claro y oscuro. El cajón móvil y la ventana de idiomas atrapan el foco cuando se abren y lo restauran al cerrarse, así que quien solo usa teclado nunca se queda atrapado. El comportamiento de atrapado de foco sigue el patrón de diálogo de la Guía de Prácticas de Autoría ARIA del W3C.
¿Cómo se gestiona el texto de derecha a izquierda?
Las páginas en árabe (ar) y hebreo (he-IL) se renderizan en disposición de derecha a izquierda mediante propiedades lógicas de CSS (margin-inline-start, padding-inline-end) en lugar de valores fijos de izquierda y derecha. Cada componente, incluidos el encabezado, la navegación, las llamadas a la acción, el pie de página, la barra móvil fija y las ventanas modales, se refleja correctamente. Hicimos una prueba de estrés del cromo completo en una plantilla AR dedicada antes del lanzamiento y documentamos el resultado en nuestro sistema de diseño.
¿Cómo interactúa el modo oscuro con la accesibilidad?
El modo oscuro se ofrece como un interruptor manual en el encabezado y respeta la preferencia de sistema prefers-color-scheme del usuario en la primera visita. El contraste del texto del cuerpo se mantiene en 4,5:1 o más en ambos modos para la superficie de prosa. El color nunca es el único portador de significado, así que las personas con deficiencia de visión cromática o en entornos monocromáticos no pierden información al cambiar de modo. La excepción de contraste del acento coral de marca aplica en ambos modos.
¿Los vídeos están transcritos?
Sí. Cada vídeo incrustado en bestgirlfriend.ai usa el dominio youtube-nocookie y se publica con una transcripción escrita directamente en la página debajo del vídeo. Los subtítulos están activados en la fuente de YouTube. Los vídeos no se reproducen solos, no se repiten en bucle y ofrecen controles de pausa y parada. Cuando los subtítulos no están disponibles en la fuente original, añadimos una transcripción manual antes de publicar.
¿Cómo gestionan el movimiento reducido?
El sitio respeta la consulta de medios CSS prefers-reduced-motion. Cuando un usuario tiene el movimiento reducido activado a nivel del sistema operativo, desactivamos el parallax, los carruseles de desplazamiento automático, las animaciones que se reproducen solas y las transiciones decorativas. El movimiento esencial de la interfaz (indicadores de foco, despliegues de menús) se mantiene porque comunica estado. Nada en el sitio parpadea más de tres veces por segundo, lo que cumple el criterio de prevención de convulsiones.
¿Con qué frecuencia hacen pruebas?
axe-core se ejecuta contra cada historia de componente y cada captura de página en CI; las compilaciones fallan ante violaciones graves o críticas. Las solicitudes de incorporación de cambios llevan un mínimo de puntuación de Lighthouse Accessibility de 95 y la GitHub Action bloquea las fusiones por debajo de eso. Las pasadas manuales de lector de pantalla con NVDA, JAWS, VoiceOver y TalkBack se hacen cada trimestre sobre un conjunto representativo de páginas y ad hoc en cualquier plantilla nueva. Cada plantilla nueva se navega de principio a fin con teclado antes de fusionarse.
¿Cuál es el acuerdo de nivel de servicio para las quejas de accesibilidad?
Acusamos recibo de las quejas de accesibilidad en 2 días hábiles en [email protected]. Las barreras bloqueantes (una función inutilizable con tecnología de asistencia) tienen un objetivo de resolución de 7 días hábiles. Los problemas no bloqueantes reciben una fecha objetivo de corrección documentada y aparecen en el registro de Problemas Conocidos hasta que se cierran. Los lectores de la UE y del Reino Unido conservan sus derechos legales de escalado independientemente de cómo gestionemos el reporte internamente.
¿Cómo gestiona la accesibilidad el chatbot AI Concierge?
El chatbot AI Concierge (antes de publicarse) no se publicará hasta que supere una auditoría completa WCAG 2.1 AA que cubra la operabilidad por teclado, los anuncios de lector de pantalla (región dinámica para las respuestas en streaming), la gestión del foco al abrir y cerrar el panel, y el cumplimiento del movimiento reducido. Hasta entonces, todo el contenido editorial es accesible sin el chatbot, y las respuestas equivalentes están al alcance mediante los acordeones de preguntas frecuentes de la página. La auditoría seguirá el patrón de diálogo de la APG ARIA del W3C para el comportamiento del panel y la guía de regiones dinámicas WAI-ARIA para las respuestas en streaming.
¿Qué son la Section 508 y el European Accessibility Act 2025?
La Section 508 de la Rehabilitation Act de EE. UU. (29 U.S.C. §794d, ICT Refresh 2018) obliga a las agencias federales y a los contratistas federales a contratar y mantener tecnología de la información accesible, armonizada con la WCAG 2.0 AA mediante el 36 CFR Part 1194. El European Accessibility Act (Directiva 2019/882, exigible desde el 28 de junio de 2025) extiende los deberes de accesibilidad a una amplia gama de productos y servicios del sector privado, también armonizados con la WCAG 2.1 AA mediante la EN 301 549. Ambos regímenes convergen en el mismo objetivo de ingeniería, y por eso una sola postura de conformidad satisface a los dos.
Fuentes
Los estándares, las leyes y las guías citadas en esta página se listan abajo en el orden en que aparecen, con URLs estables. Vueltas a verificar en 2026.
- [Source: W3C, Pautas de Accesibilidad para el Contenido Web (WCAG) 2.1, Recomendación del W3C del 5 de junio de 2018 · verified 2026-05-26]
- [Source: W3C, Pautas de Accesibilidad para el Contenido Web (WCAG) 2.2, Recomendación del W3C del 5 de octubre de 2023 · verified 2026-05-26]
- [Source: ETSI, EN 301 549 v3.2.1, Requisitos de accesibilidad para productos y servicios TIC (marzo de 2021) · verified 2026-05-26]
- [Source: Directiva de Accesibilidad Web de la UE 2016/2102 · verified 2026-05-26]
- [Source: European Accessibility Act de la UE, Directiva 2019/882 (exigible el 28 de junio de 2025) · verified 2026-05-26]
- [Source: Section 508 de la Rehabilitation Act de EE. UU., ICT Refresh (2018) · verified 2026-05-26]
- [Source: Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 del Reino Unido (SI 2018/952) · verified 2026-05-26]
- [Source: Accessibility for Ontarians with Disabilities Act, 2005 (AODA) e Integrated Accessibility Standards Regulation O. Reg. 191/11 · verified 2026-05-26]
- [Source: GOV.UK Service Manual, Pruebas de accesibilidad · verified 2026-05-26]
- [Source: Apple Developer, Human Interface Guidelines, Accesibilidad · verified 2026-05-26]
- [Source: Guía de Prácticas de Autoría ARIA del W3C, Patrón de diálogo (modal) · verified 2026-05-26]
- [Source: Deque Systems, axe-core, motor de pruebas de accesibilidad de código abierto · verified 2026-05-26]
- [Source: Google Chrome Developers, puntuación de Lighthouse Accessibility · verified 2026-05-26]
- [Source: WebAIM, investigación de accesibilidad y pruebas con lectores de pantalla · verified 2026-05-26]
Páginas editoriales de confianza relacionadas
- Página de metodología, los estándares editoriales detrás de cada puntuación en bestgirlfriend.ai.
- Proceso editorial, cómo se escriben, verifican y actualizan las reseñas.
- Política de privacidad, qué datos recogemos y tus derechos bajo el RGPD, la CCPA y equivalentes.
- Términos de uso, el contrato que rige tu uso del sitio.
- Divulgación de afiliación, cómo ganamos dinero y por qué no influye en las clasificaciones.
- Sobre Alexandra Joly, perfil de la Editora Sénior, credenciales y contacto directo.
- Contacto, canal de contacto general para consultas que no sean de accesibilidad.
Aviso por jurisdicción
Última verificación en 2026 · Consulta el registro de erratas para cualquier corrección posterior a la publicación · Editora: Alexandra Joly · Metodología · Proceso editorial · Divulgación de afiliación