/* ==========================================================================
   ACCESIBILIDAD — reglas transversales WCAG 2.1 AA

   Hogar UNICO de las reglas a11y que aplican a TODAS las paginas. Se registra
   en etc/theme-config.php despues de skeleton.css: asi puede ganar en cascada
   sin recurrir a !important.

   El proyecto tiene el CSS plano (no hay preload/postload), de modo que todo
   lo del array de theme-config es render-blocking. La regla [T6] del
   procedimiento — "lo que oculta contenido en el primer paint NO puede ir
   diferido" — se cumple aqui por construccion.

   .sr-only NO vive aqui: ya esta definido en skeleton.css (fuente unica).
   ========================================================================== */


/* #Skip link (WCAG 2.4.1)
================================================== */
/* Primer elemento focusable del documento. Invisible hasta recibir el foco,
   momento en el que se ancla arriba del todo. El z-index tiene que superar a
   CUALQUIER capa del proyecto (menu hamburguesa y mascara de reservas), o el
   enlace se enfocaria por debajo de ellas y el usuario no lo veria. */
.skip-link {
	position: absolute;
	top: -100%;
	left: 0;
	z-index: 100000;
	/* FASE 02 WCAG (antipatron S1 de la ficha): barra de ANCHO COMPLETO con el texto
	   centrado, no un boton del ancho de su texto flotando en la esquina superior
	   izquierda -que es facil de no ver y era como estaba-. box-sizing:border-box
	   para que el padding cuente DENTRO del 100% y la barra no desborde a lo ancho. */
	width: 100%;
	box-sizing: border-box;
	text-align: center;
	padding: 0.5rem 1rem;
	background: #000;
	color: #fff;
	text-decoration: none;
	/* rem y no px: un font-size fijo no responde al zoom de texto del navegador
	   y dejaria el skip link ilegible a quien amplia la tipografia (WCAG 1.4.4). */
	font-size: 0.875rem;
	line-height: 1.4;
}
.skip-link:focus,
.skip-link:focus-visible {
	position: fixed;
	top: 0;
	outline: 2px solid #fff;
	outline-offset: -2px;
}

/* <main> recibe el foco por programa cuando se activa el skip link
   (tabindex="-1"), pero NO es un control operable por teclado: no entra en el
   orden de tabulacion, asi que anular su anillo no incumple 2.4.7. Sin esto,
   saltar al contenido pintaria un recuadro alrededor de media pagina. */
#middle:focus {
	outline: none;
}


/* #Elementos nuevos de formulario (WCAG 3.3.1 y 3.3.2)
==================================================
   Los dos elementos que anade el gate §5bis (bloque 2.6) al formulario de
   contacto y al de newsletter. Se maquetan AQUI, y no se dejan sin estilo, por la
   regla de la ficha: un elemento anadido por accesibilidad que hereda los estilos
   por defecto aparece como texto crudo flotando en mitad del formulario, y como
   NO existe en produccion, ninguna comparacion prod-vs-local lo detecta — su
   revision de diseno es responsabilidad exclusiva de esta fase.

   .field-error  -> mensaje anclado al campo que falla (P-inline-error). Nace
                    inexistente: form-validator.js lo CREA al fallar y lo borra al
                    corregir, asi que no hace falta ocultarlo por CSS.
   .form-required-note -> nota de obligatoriedad, permanente.

   Color #800033: el granate que el proyecto ya usa para el asterisco de campo
   obligatorio, no un rojo nuevo. Sobre el ambar del formulario de contacto da
   4,71:1 y sobre el blanco del newsletter 10,68:1 — por encima del 4,5:1 de texto
   normal en ambos. El mensaje NO depende del color: lleva su propio texto y el
   campo queda marcado con aria-invalid.
================================================== */
.field-error {
	display: block;
	margin: 0.375rem 0 0 0;
	font-size: 0.875rem;
	line-height: 1.25rem;
	color: #800033;
	font-weight: 600;
}

.form-required-note {
	margin: 0 0 1rem 0;
	font-size: 0.875rem;
	line-height: 1.25rem;
	color: #1A1A1A;
}


/* #Enlaces dentro de texto corrido del CMS (WCAG 1.4.3 y 1.4.1)
==================================================
   FASE 14, autorizada por el usuario el 13-ago-2026 y ACOTADA a este caso.

   La regla global 'a { color: #F4C670 }' (fenix-sevilla-hotel.css:82) funciona
   sobre los fondos oscuros del sitio, pero el contenido legal del CMS se pinta
   sobre BLANCO: ahi ese ambar da 1,6:1 -muy por debajo del 4,5:1 de texto
   normal- y ademas queda como UNICA senal de que algo es un enlace, sin
   subrayado ni cambio de peso. Falla 1.4.3 y 1.4.1 a la vez. No es una paleta
   mal elegida: es una regla global sin escopar.

   Dos cambios, los minimos:
     - color #800033, que YA es color del proyecto (asterisco de campo
       obligatorio) y da 10,7:1 sobre blanco. No se inventa un color nuevo.
     - subrayado, para que el enlace no dependa solo del color (1.4.1).

   Alcance deliberadamente estrecho: SOLO el texto corrido de los bloques que
   vuelcan contenido libre del CMS sobre fondo claro. Los enlaces de cabecera,
   pie, botones y CTAs conservan su color: ahi el ambar va sobre fondo oscuro y
   cumple.
================================================== */
/* AMPLIACION del 14-ago-2026, autorizada por el usuario, al bloque de datos de
   contacto de /contacto (#contactInfoSec): el telefono, el WhatsApp y el email
   viven dentro de <p><strong>Telefono:</strong> <a>+34 ...</a></p> y llegaban
   con EXACTAMENTE el mismo color que el texto que los rodea (#1A1A1A los dos) y
   sin subrayado. No es el caso clasico de 1.4.1 -el color no es el unico medio;
   es que no habia NINGUNO-, pero el enlace era indistinguible del texto: nada
   indica que ese numero se puede pulsar para llamar.

   Se les da el MISMO tratamiento que a los enlaces de texto corrido del CMS, en
   vez de inventar uno propio, para que el sitio tenga un solo lenguaje visual
   de "esto es un enlace dentro de texto sobre fondo claro": granate #800033
   (10,7:1 sobre el blanco de la seccion, y distinto del #1A1A1A del parrafo) mas
   subrayado. El <strong> del rotulo ("Telefono:", "E-mail:") no se toca.

   Sigue SIN afectar al widget de contacto de la home y las interiores: ese pinta
   sobre foto con velo oscuro, sus enlaces son blancos y no cuelgan de
   #contactInfoSec. */
#introductionSec .contentBox .description p a,
#introductionSec .contentBox .description li a,
#cookiePolicySec .policyBox p a,
#cookiePolicySec .policyBox li a,
#contactInfoSec .contactInfoBox ul.wayContactBox li p a {
	color: #800033;
	text-decoration: underline;
}


/* #Foco visible (WCAG 2.4.7 y 2.4.11)
==================================================
   El proyecto no tenia anillo de foco propio: el bootstrap del framework anula
   el outline en button:focus:not(:focus-visible), .form-control:focus,
   .accordion-button:focus, .btn:focus-visible y .btn-close:focus, asi que quien
   navegaba con teclado no veia donde estaba en casi ningun control.

   Anillo de DOS TONOS (oscuro + halo claro) para que se vea sobre los tres
   fondos del sitio sin depender del color de cada bloque: blanco de las
   secciones claras, negro corporativo del header y el footer, y las fotos del
   hero y del rooftop. Un anillo de un solo color siempre se pierde en uno de
   los tres.

   :focus-visible y NO :focus: el anillo solo debe aparecer con teclado, nunca
   al hacer click con el raton (es el criterio del propio navegador).

   Los colores son los de la paleta del proyecto (#1A1A1A y #ffffff), no colores
   nuevos inventados para la ocasion.
================================================== */
:root {
	--a11y-focus-oscuro: #1A1A1A;
	--a11y-focus-claro:  #ffffff;
}

a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible,
summary:focus-visible,
[tabindex]:not([tabindex="-1"]):focus-visible {
	outline: 2px solid var(--a11y-focus-oscuro);
	outline-offset: 2px;
	box-shadow: 0 0 0 4px var(--a11y-focus-claro);
	border-radius: 0.125rem;
}

/* Con raton o dedo NO se pinta anillo. El navegador ya lo evita con
   :focus-visible, pero bootstrap deja reglas :focus sueltas que si pintan. */
a:focus:not(:focus-visible),
button:focus:not(:focus-visible) {
	outline: none;
	box-shadow: none;
}

/* Sobre fondo OSCURO (cabecera, hero, menu hamburguesa y footer) se invierten
   los dos tonos: si no, el anillo negro desaparece contra el negro corporativo. */
header a:focus-visible,
header button:focus-visible,
nav.hamburgerNav a:focus-visible,
#footer a:focus-visible,
#footer button:focus-visible,
#footer input:focus-visible {
	outline-color: var(--a11y-focus-claro);
	box-shadow: 0 0 0 4px var(--a11y-focus-oscuro);
}

/* #Popover del NeoLoyaltyWidget ("Login Club Vibra"): tonos NORMALES pese a
   vivir dentro de HEADER (WD-14850, WCAG 2.4.7)
==================================================
   El NeoLoyaltyWidget (neo-loyalty.xsl) NO usa Shadow DOM: su popover se
   renderiza en LIGHT DOM dentro de #neo-loyalty-widget, que a su vez vive
   DENTRO de <header> (verificado en vivo: #reka-popover-content-v-1 cuelga
   de un div[data-reka-popper-content-wrapper] dentro de #neo-loyalty-widget
   dentro de #header). Pero el popover pinta su PROPIO fondo BLANCO
   (rgb(255,255,255), medido en vivo), igual que .footerNewsletter dentro de
   #footer mas arriba en este archivo. La regla de justo encima
   ("header button:focus-visible"), pensada para lo que SI esta sobre el
   negro corporativo (el boton disparador, que se deja intacto: sobre el
   negro del header un outline claro funciona bien), le llega tambien a los
   dos botones del popover -"Unete al club" e "Inicia sesion"- y les invierte
   los tonos. Resultado computado con Tab real: outline BLANCO solido 2px con
   offset 2px sobre un fondo BLANCO = CERO indicacion de foco. El halo oscuro
   del box-shadow tampoco salva nada: el propio widget fija en el boton un
   box-shadow decorativo PROPIO como estilo EN LINEA
   (verificado con getAttribute('style'):
   "...box-shadow: rgba(0, 0, 0, 0.2) 2px 2px 4px; ..."), y ese estilo en
   linea gana a cualquier box-shadow de esta hoja por especificidad.

   Selectores: las clases "neoloyalty-register-button" / "neoloyalty-login-
   button" NO son utilidades Tailwind internas del bundle (esas SI cambian
   sin aviso entre versiones del CDN, ver cabecera de neo-loyalty.xsl): son
   las clases SEMANTICAS que el propio widget expone para personalizacion,
   verificadas en vivo contra el bundle desplegado. Se escopan a
   #neo-loyalty-widget (el contenedor unico y estable del widget) en vez de
   subir mas en el arbol, para no acoplarse a la maqueta del header.

   Especificidades en competencia:
     header button:focus-visible                                        (0,1,2)
     #neo-loyalty-widget .neoloyalty-register-button:focus-visible,
     #neo-loyalty-widget .neoloyalty-login-button:focus-visible          (1,2,0)
   El ID del contenedor basta para ganar sin necesidad de !important en el
   outline (solo se toca outline-color: el ancho/estilo "2px solid" y el
   offset "2px" ya llegan correctos desde la regla generica de #Foco
   visible, no hace falta redeclararlos).

   El box-shadow SI necesita !important, y es INEVITABLE por la MISMA razon
   que el de WOW.js mas abajo en este archivo: gana a un estilo EN LINEA
   escrito por JS de terceros sobre el que no tenemos control (ver ese bloque
   para el porque no basta con especificidad). Es el SEGUNDO !important del
   proyecto, no el unico (ver nota actualizada junto al de WOW.js).
   El outline SI llega a verse porque no esta en linea: solo lo esta el
   box-shadow decorativo de base del boton. */
#neo-loyalty-widget .neoloyalty-register-button:focus-visible,
#neo-loyalty-widget .neoloyalty-login-button:focus-visible {
	outline-color: var(--a11y-focus-oscuro);
	box-shadow: 0 0 0 4px var(--a11y-focus-claro) !important;
}

/* FASE 08 WCAG (2.4.7, antipatron A1): los enlaces del menu hamburguesa llevan el
   anillo INSET. Su <ul> computa overflow-x:hidden y mide EXACTAMENTE lo mismo que
   los enlaces (467,19px de ancho, sin holgura lateral), asi que un anillo exterior
   se recorta por los dos lados y solo llegan a pintarse los dos trazos
   horizontales: medido con Tab real, con el anillo mutilado a izquierda y derecha.
   Inset lo mantiene entero dentro del enlace, con el mismo tono claro sobre el
   negro del panel (17,4:1). El halo exterior se queda: cae sobre el propio texto,
   no sobre el borde recortado. */
nav.hamburgerNav a:focus-visible {
	outline-offset: -2px;
}

/* Campos de formulario: la RAIZ por la que se quedaban sin anillo.
   La cascada compara especificidad POR PROPIEDAD y NO distingue estados, asi que
   una regla BASE mas especifica gana a una :focus-visible mas debil. Las tres que
   ganaban a las reglas de elemento de arriba -(0,1,1)- eran:
     bootstrap.min.css  .form-control:focus                                (0,2,0)  outline: 0
     fenix-sevilla-...  #searchForm .field .form-control                    (1,2,0)  box-shadow: none
     contact-page.css   #contactFormSec .formBox .form-group .form-control  (1,3,0)  outline: 0 + box-shadow: none
   Computado real en los 8 campos afectados: outline none 0px + box-shadow none, o
   sea CERO indicacion de foco (2.4.7) en la mascara de reservas -que vive en el
   header global, luego en TODAS las paginas- y en el formulario de contacto
   entero. Hasta ahora estaban parcheados a mano dos casos concretos (newsletter y
   acordeon) pero no la raiz.
   De ahi la longitud de los selectores: cada uno es el MINIMO que gana a su
   competidor sin recurrir a !important. Con contact-page.css hay que superarlo, no
   empatarlo: se emite desde su plantilla dentro de <main>, o sea DESPUES de este
   archivo, y a igual especificidad ganaria la ultima.
   El anillo se deja EXTERIOR (no inset) porque cabe: cada control tiene 12px
   libres dentro de su .field y 212px dentro de su .form-group, y el anillo solo
   ocupa 4px -no invade la celda vecina ni lo recorta ningun ancestro, asi que
   L08c-ring-overflow sigue en PASS-.
   Los dos disparadores de acordeon (#contactFaqSec y #faqsListSec) ya NO se
   listan aqui: sus modulos declaran su propio :focus-visible con la MISMA
   especificidad y se cargan despues, asi que desde aqui solo se les colaba el
   box-shadow y el outline lo seguia poniendo el modulo. El anillo se corrigio
   donde manda, en contact-faqs.css y faqs-list.css. */
#searchForm .field .form-control:focus-visible,                    /* (1,3,0) > (1,2,0) */
#contactFormSec .formBox .form-group .form-control:focus-visible,  /* (1,4,0) > (1,3,0) */
#subscribe-form .form-control:focus-visible {                      /* (1,2,0) > (0,2,0) */
	outline: 2px solid var(--a11y-focus-oscuro);
	outline-offset: 2px;
	box-shadow: 0 0 0 4px var(--a11y-focus-claro);
}

/* Y ademas hay que sacar el box-shadow de la transicion, o el halo del anillo se
   funde en vez de aparecer: bootstrap declara
   .form-control { transition: border-color .15s ease-in-out, box-shadow .15s ease-in-out }
   y el halo del anillo se pinta justamente con box-shadow, asi que crecia de 0 a 4px
   en 150ms (el outline si era instantaneo, porque bootstrap no lo anima). Es el
   mismo antipatron A4 / E-31 del `transition: all` del resto del proyecto, solo que
   aqui lo trae la libreria.
   Se declara SOLO transition-property y no la abreviatura a proposito: asi la
   duracion la sigue poniendo bootstrap, y su bloque de
   @media (prefers-reduced-motion: reduce) -que la baja a 0s- se mantiene efectivo.
   border-color es la unica otra propiedad que bootstrap animaba en estos campos,
   asi que la lista es su subconjunto exacto menos el box-shadow. */
.form-control {
	transition-property: border-color;
}

/* Los DOS checkboxes del formulario de contacto (privacidad y marketing) se
   quedaban igualmente sin anillo, y por la misma causa que los .form-control de
   arriba: no son .form-control, asi que solo les llegaba el 'input:focus-visible'
   generico (0,1,1), y su regla BASE
     #contactFormSec .formBox .form-group label.checkbox input   (1,3,2)  outline: 0
   -que existe porque el checkbox va con appearance:none y caja dibujada a mano-
   gana por especificidad en la propiedad 'outline'. Resultado computado: outline
   none, y del anillo solo sobrevivia el halo BLANCO del box-shadow — que sobre el
   ambar corporativo de la seccion (#F4C670, medido en vivo: es el fondo efectivo
   de estos checkboxes, NO blanco) apenas llega a 1,6:1. O sea, indicacion de foco
   inservible (2.4.7) en el consentimiento RGPD, que ademas es obligatorio para
   enviar el formulario.
   Con el outline restituido, el anillo oscuro sobre ese ambar da 10,7:1
   (verificado en vivo con el control enfocado y captura en claude-temp/wcag/
   evidencia/), asi que los tonos NORMALES son los correctos aqui.
   La regla de abajo es el MINIMO que gana a esa base -misma cadena + la
   pseudoclase, (1,4,2) > (1,3,2)- sin !important. Hace falta ganar por
   especificidad y no por orden: contact-page.css se emite desde su plantilla
   dentro de <main>, despues de este archivo. Anillo exterior como en el resto de
   campos del formulario: el checkbox mide 24x24 y su label deja hueco de sobra. */
#contactFormSec .formBox .form-group label.checkbox input:focus-visible {
	outline: 2px solid var(--a11y-focus-oscuro);
	outline-offset: 2px;
	box-shadow: 0 0 0 4px var(--a11y-focus-claro);
}

/* Checkbox de terminos de la newsletter. Anillo PEGADO (offset 1px) porque el
   control mide 16x16 y un offset de 2px lo duplicaria visualmente.

   TONOS NORMALES, no invertidos: el bloque .footerNewsletter pinta su PROPIO
   fondo BLANCO (fenix-sevilla-hotel.css) aunque viva dentro de #footer, que es
   negro. Medido en vivo sobre el DOM: el primer ancestro con fondo no
   transparente es DIV.footerNewsletter -> rgb(255,255,255). La version anterior
   de esta regla usaba los tonos invertidos "porque vive sobre el negro del
   footer", lo que dejaba un outline BLANCO sobre BLANCO -invisible- y solo
   salvaba el anillo el halo oscuro. Nadie lo detecto porque la regla ni siquiera
   llegaba a aplicarse (ver la nota de especificidad de abajo): al arreglar la
   especificidad afloro el color equivocado.
   OJO CON EL SELECTOR: la version anterior era '#subscribe-form
   input[type="checkbox"]:focus-visible' (1,2,1) y NO llegaba a pintar el outline.
   Su competidor es la regla base del checkbox dibujado a mano,
     #footer .footerNewsletter .newsform .form-group label input   (1,3,2)  outline: 0
   que gana en la propiedad 'outline'. Solo se colaba el box-shadow -halo OSCURO
   sobre el negro del footer-, o sea foco invisible (2.4.7). Se sube el selector
   a la MISMA cadena + [type] + la pseudoclase (1,5,2) para ganar sin !important. */
#footer .footerNewsletter .newsform .form-group label input[type="checkbox"]:focus-visible {
	outline: 2px solid var(--a11y-focus-oscuro);
	outline-offset: 1px;
	box-shadow: 0 0 0 3px var(--a11y-focus-claro);
}

/* Boton "Cerrar formulario de reservas" de la mascara. Mismo patron: su regla
   base #searchForm .searchFormClose (1,1,0) declara outline: 0 -parte del reset
   del <button> convertido en la Fase 03- y gana al 'button:focus-visible'
   generico (0,1,1) y al 'header button:focus-visible' (0,1,2), asi que el boton
   se quedaba sin anillo. En <=767px la mascara ocupa la pantalla completa y este
   es el unico control de salida, ademas del Escape.
   (1,2,0) es el minimo que gana. Tonos NORMALES (no los de header): la mascara
   pinta fondo claro propio, no hereda el negro de la cabecera. */
#searchForm .searchFormClose:focus-visible {
	outline: 2px solid var(--a11y-focus-oscuro);
	outline-offset: 2px;
	box-shadow: 0 0 0 4px var(--a11y-focus-claro);
}

/* Anillo INSET para focusables A RAS del borde de un ancestro con overflow:hidden
==================================================
   El anillo del proyecto es EXTERIOR (outline-offset:2px + box-shadow de 4px), asi
   que necesita 4px libres alrededor. Estos controles no los tienen: estan a margen
   0px del borde de un contenedor que recorta, de modo que del anillo solo asomaba
   el lado que si tenia hueco (verificado enfocando la primera miniatura del hero:
   una linea blanca abajo y nada arriba, izquierda ni derecha).

   La solucion NO es dar aire al contenedor -eso cambiaria el ancho y con el el
   diseno-: es dibujar el mismo anillo HACIA DENTRO, que es de coste cero en
   espacio. Con outline-offset:-2px el borde exterior del outline se mete 2px, asi
   que el outline de 2px ocupa exactamente la franja 0-2px por dentro del elemento;
   el box-shadow inset de 4px pinta por debajo la franja 2-4px. Resultado: anillo de
   4px, DOS TONOS, integramente dentro del elemento -nada que recortar-.

   Los dos tonos siguen siendo obligatorios aqui mas que en ningun otro sitio: el
   fondo de estos controles es una FOTO impredecible (miniaturas del hero y de cada
   habitacion, imagenes de la galeria), asi que un solo tono se pierde en la mitad
   de las imagenes. Se pone el CLARO fuera y el OSCURO dentro: el claro es el que
   sobrevive contra las zonas oscuras de la foto y contra el fondo del contenedor,
   y el oscuro el que sobrevive contra las zonas claras.

   Estas reglas van DESPUES del bloque generico de arriba a proposito: para un
   <div role="button" tabindex="0"> el selector que matchea alli es
   [tabindex]:not([tabindex="-1"]):focus-visible, que es (0,3,0) -la misma
   especificidad que .home-slider-thumb .swiper-slide:focus-visible-. Al empatar
   gana la ultima del archivo, asi que el orden dentro de este fichero es lo que
   hace que el inset se aplique. No hace falta subir especificidad ni !important. */
.home-slider-thumb .swiper-slide:focus-visible,
.inner-slider-thumb .swiper-slide:focus-visible,
.rooms-slider-thumb .swiper-slide:focus-visible,
a.masonry-item__link:focus-visible,
#faqsListSec .faqsMenu .catBtn:focus-visible {
	outline: 2px solid var(--a11y-focus-claro);
	outline-offset: -2px;
	box-shadow: inset 0 0 0 4px var(--a11y-focus-oscuro);
}

/* Flechas de carrusel. El caso medido es .benefits-slider, cuyo .swiperNav vive
   DENTRO del .swiper y deja la flecha apoyada justo en su borde inferior (margen
   0px). La regla se aplica a TODAS las flechas del proyecto y no solo a esa, porque
   es el mismo componente compartido (.swiperNav de swiper-bundle-controls.css,
   presente en hero, habitaciones, ventajas, inner-banner y galeria): dos aspectos
   distintos de anillo para el mismo control, segun donde este colgado su .swiperNav,
   se leeria como un descuido. Sobre el circulo casi negro de la flecha el tono claro
   del inset contrasta de sobra.
   border-radius:50% porque el circulo visible (el <span>) mide lo mismo que el
   boton: con el 2px del bloque generico de arriba el anillo saldria cuadrado
   alrededor de un circulo. Mismo motivo, ya documentado, por el que
   .js-motion-pause repite su 50% mas abajo. */
.swiperNav [class*="swiper-button-"]:focus-visible {
	outline: 2px solid var(--a11y-focus-claro);
	outline-offset: -2px;
	box-shadow: inset 0 0 0 4px var(--a11y-focus-oscuro);
	border-radius: 50%;
}
/* Los DOTS de paginacion, por el mismo motivo que las flechas de aqui arriba: su
   caja es un cuadrado de 24x24 -el minimo tactil de 2.5.8- pero lo que se ve dentro
   es un destello recortado con clip-path, asi que el anillo por defecto dibujaba un
   cuadrado alrededor de una forma que no lo es. Con el 50% el anillo acompana a la
   figura y la fila de dots se lee como un grupo de controles redondos.

   Van en su propia regla y no anadidos al selector de arriba porque NO cuelgan de
   un .swiperNav: Swiper los genera dentro de su .swiper-pagination, que es un
   contenedor distinto. Conservan el anillo generico -oscuro con halo claro- en vez
   del invertido de las flechas: los dots se pintan en blanco sobre la foto, y el
   anillo claro de las flechas se perderia sobre las imagenes claras. */
.swiper-pagination-bullet:focus-visible {
	border-radius: 50%;
}


/* Enlaces que envuelven una IMAGEN (logo del header)
==================================================
   El <a> del logo era display:inline y su unico hijo, la <img>, es display:block
   (reset del framework). Un elemento inline cuyo contenido es un bloque no genera
   caja de linea propia -el bloque va en una caja anonima-, asi que el navegador
   pintaba el anillo alrededor de una caja inline degenerada: un filete fino
   descolocado en vez del recuadro de la imagen. Lighthouse no lo detecta.
   Se fuerza display SIEMPRE, no solo en :focus, porque hacerlo solo al enfocar
   provocaria un salto de layout al tabular. Se usa block y no inline-block por lo
   mismo que ya hace el logo del footer (que nace block y por eso NO tiene este
   problema): con block el <a> no participa en la linea base ni arrastra el strut
   tipografico, asi que su alto es exactamente el de la imagen -43,41px, el mismo
   que ya media el .logo antes del cambio: no mueve nada-. */
#header .logo a {
	display: block;
}


/* NOTA: booking-mask.css define su propio :focus-visible para el calendario, el
   pop-up de huespedes y sus botones, con selectores #searchForm ... que ganan
   por especificidad a las reglas de elemento de arriba. Es deliberado: ese
   modulo es dueno de su propio foco y no se pisa desde aqui. */


/* #WOW.js sin sacar los interactivos del Tab (WCAG 2.1.1) — [T4] / P-wow-a11y
==================================================
   WOW.js escribe visibility:hidden INLINE en cada .wow y no lo retira hasta que
   el bloque entra en el viewport al hacer scroll. visibility:hidden saca el
   elemento Y TODO SU CONTENIDO del orden de tabulacion y del arbol de
   accesibilidad: en esta home eso dejaba 26 bloques ocultos con 53 controles
   interactivos dentro (enlaces, botones, pestanas) inalcanzables por teclado y
   para un lector de pantalla hasta que alguien hiciera scroll con el raton.

   La solucion es sustituir la ocultacion por opacity, que NO afecta al foco:
   el bloque sigue siendo invisible a la vista pero tabulable y anunciable.

   Son DOS piezas y las dos son obligatorias:
     1. html.js .wow { visibility: hidden; }  -> pre-ocultado en el PRIMER paint,
        antes de que cargue ningun JS. Sin esto los bloques se verian un instante
        y desaparecerian al arrancar WOW (FOUC). La clase 'js' la pone el primer
        <script> del <head> (head.xsl), y el <html> nace con 'no-js': sin
        JavaScript no se oculta nada (mejora progresiva).
     2. La clase 'wow-a11y' que anade a11y.js -> revela por opacity y neutraliza
        el visibility inline de WOW.

   El !important es INEVITABLE aqui y por eso va comentado: WOW escribe
   visibility:hidden como estilo EN LINEA, y un estilo en linea gana a cualquier
   selector de la hoja por especificidad. Es el PRIMERO de los DOS !important
   del proyecto (WD-14850): el mismo motivo -ganar a un estilo en linea de un
   script de terceros- justifica el segundo, en el bloque del popover del
   NeoLoyaltyWidget de la seccion #Foco visible, mas arriba. */
html.js .wow {
	visibility: hidden;
}
html.wow-a11y .wow {
	visibility: visible !important;
}
/* Antes de que WOW lo revele: invisible a la vista, pero focusable y en el arbol
   de accesibilidad. Es justo lo que visibility:hidden impedia. */
html.wow-a11y .wow:not(.wow-seen) {
	opacity: 0;
}
html.wow-a11y .wow.wow-seen {
	opacity: 1;
}
/* Quien pide menos movimiento ve el contenido directamente, sin fundido. */
@media (prefers-reduced-motion: reduce) {
	html.wow-a11y .wow:not(.wow-seen) {
		opacity: 1;
	}
}


/* #Pausar contenido en movimiento automatico (WCAG 2.2.2) — P-pause-2.2.2
==================================================
   El hero (#slider) y los 5 carruseles de habitaciones (.roomsSlider) avanzan
   solos cada 4-5s (temporizador propio en swiper-bundle-controls.js). El
   boton lo inyecta a11y.js como ULTIMO hijo de su contenedor (para que caiga
   en el Tab despues de las flechas, E-35). #slider y .roomsSlider ya son
   position:relative (fenix-sevilla-hotel.css y rooms-home.css): el boton no
   necesita tocar el posicionamiento de ninguno de los dos contenedores.

   Icono SVG INLINE (lo genera a11y.js, hereda color via currentColor): nunca
   una fuente de iconos, que en un tema rediseñado puede no cargar y dejar el
   boton sin icono visible (E-37).

   Fondo oscuro translucido: el MISMO tono que ya usa el proyecto para superponer
   texto sobre foto (thumb-progress, fenix-sevilla-hotel.css:1120 ). Colores de
   la paleta real (#1A1A1A / #ffffff), nada de tonos nuevos.
================================================== */
.js-motion-pause {
	position: absolute;
	right: 1rem;
	bottom: 1rem;
	z-index: 20;
	display: flex;
	align-items: center;
	justify-content: center;
	width: 44px;
	height: 44px;
	padding: 0;
	color: #ffffff;
	background: rgb(26 26 26 / 72%);
	border: none;
	border-radius: 50%;
	cursor: pointer;
	transition: background-color 200ms ease;
}
.js-motion-pause:hover {
	background: #1A1A1A;
}
.js-motion-pause svg {
	width: 18px;
	height: 18px;
	display: block;
}
/* El boton vive sobre foto (hero y carrusel de habitaciones): mismo anillo de
   dos tonos INVERTIDO que el resto del sitio sobre fondo oscuro (ver
   #Foco visible), para que se distinga tanto sobre imagenes claras como
   oscuras.
   border-radius:50% repetido a proposito: la regla generica de #Foco visible
   (button:focus-visible, mas arriba en este mismo archivo) pone border-radius:2px
   y por especificidad de atributo empataria con nuestro border-radius:50% base
   (una es 0,1,0 sin :focus, la otra 0,1,1 CON :focus-visible -> gana la de foco y
   el boton se veia una esquina redondeada en vez de circulo). Se repite aqui, con
   mayor especificidad (.js-motion-pause + :focus-visible), para que el circulo se
   mantenga tambien mientras esta enfocado. */
.js-motion-pause:focus-visible {
	outline: 2px solid var(--a11y-focus-claro);
	outline-offset: 2px;
	box-shadow: 0 0 0 4px var(--a11y-focus-oscuro);
	border-radius: 50%;
}
.js-motion-pause:focus:not(:focus-visible) {
	outline: none;
	box-shadow: none;
}

/* SEPARACION EN LOS DOS HEROES A SANGRE (#slider y #innerBanner).
   Los 16px de la regla base son la medida buena DENTRO de una tarjeta (el
   carrusel de cada habitacion), pero en los heroes el contenedor ocupa el
   viewport completo y esos 16px dejan el boton pegado al borde de la pantalla.
   Los valores no son nuevos: se toman de los dos elementos con los que el boton
   comparte eje, para que quede alineado con ellos y no "casi":
     right  76px -> MISMO eje que la columna de miniaturas del hero
                    (#slider .home-thumb-wrapper y #innerBanner
                    .inner-thumb-wrapper, ambas right:76px), que es tambien el
                    padding lateral del #caption.
     bottom 48px -> MISMA linea inferior que la mascara de reservas fija
                    (#searchForm, position:fixed; bottom:48px): el boton y la
                    mascara comparten banda, asi que sus bordes inferiores
                    coinciden en vez de quedar escalonados.
   Sigue sin solaparse con nada: la mascara es un bloque centrado que a 1600px
   termina en x=1240 y el boton arranca en x=1524.

   Va por TRAMOS y no como regla base porque los dos elementos de referencia
   cambian de sitio y hay que seguirlos:
     >=1501      miniaturas right:76 + mascara bottom:48 (valores base)
     1366-1500   miniaturas right:76 + mascara bottom:38 (skeleton.css:63)
     961-1365    miniaturas right:32 + mascara bottom:38 (skeleton.css:92/99,
                 inner-banner.css:228)
   Por debajo de 961px NO se toca a proposito y se queda el 16px de la regla
   base: ahi el boton pasa a estar centrado verticalmente en el lateral (ver el
   bloque de mas abajo) por los solapes con la mascara a pantalla completa y con
   la hamburguesa -regresion ya documentada-, las miniaturas dejan de estar en
   el lateral (pasan a una franja horizontal abajo) y 16px es el retranqueo
   normal de un control flotante en movil. Si esto fuese regla base sin media
   query, el right:76px se colaria en movil (el bloque de <=960px solo
   sobreescribe top/bottom) y el boton se meteria 76px dentro de la pantalla. */
@media (min-width: 1501px) {
	#slider .js-motion-pause,
	#innerBanner .js-motion-pause {
		right: 4.75rem;
		bottom: 3rem;
	}
}
@media (min-width: 1366px) and (max-width: 1500px) {
	#slider .js-motion-pause,
	#innerBanner .js-motion-pause {
		right: 4.75rem;
		bottom: 2.375rem;
	}
}
@media (min-width: 961px) and (max-width: 1365px) {
	#slider .js-motion-pause,
	#innerBanner .js-motion-pause {
		right: 2rem;
		bottom: 2.375rem;
	}
}

/* Habitaciones en mobile/tablet (<=960px): el rooms-thumb-wrapper (miniaturas +
   flechas) pasa de franja VERTICAL (derecha) a franja HORIZONTAL pegada abajo,
   ocupando la misma esquina donde vive el boton por defecto. Se sube
   arriba-derecha para no solaparse con la flecha derecha del carrusel de
   miniaturas. El hero no lo necesita: su home-thumb-wrapper nunca ocupa el borde
   inferior completo (skeleton.css).

   #roomsMainSec (listado de /habitaciones, rooms-list.css) sufre el MISMO cambio
   de franja vertical->horizontal en este mismo rango, y por eso comparte regla:
   asi no se solapa con la miniatura/flecha de SU carrusel (verificado en vivo a
   390x844: el boton pisaba la segunda miniatura y rozaba la flecha "siguiente").

   OJO CON LOS DOS SELECTORES, que YA NO son simetricos. Lo eran mientras los dos
   bloques compartian el DOM de pestanas (.roomsBox > .roomsCont > .items), pero
   en ago-2026 la home paso a maqueta de dos columnas y perdio el .roomsCont: su
   ruta es ahora .roomsBox > .items. Si se vuelven a igualar "por limpieza", el
   selector de la home deja de encajar y el boton se queda abajo, encima de las
   miniaturas -exactamente el solape que esta regla existe para evitar-, y sin
   ningun sintoma en escritorio. Se conserva el ancestro .items en los dos porque
   sigue existiendo en ambos bloques (en la home, con .show fija: ver
   rooms-home.xsl). */
@media (max-width: 960px) {
	#roomsSec .roomsBox .items .roomsSlider .js-motion-pause,
	#roomsMainSec .roomsBox .roomsCont .items .roomsSlider .js-motion-pause {
		top: 1rem;
		bottom: auto;
	}
}

/* Hero de paginas interiores en mobile/tablet (<=960px, inner-banner.css
   bloques 768-960 y max-767): el inner-thumb-wrapper sufre el MISMO cambio de
   franja VERTICAL (derecha) a franja HORIZONTAL pegada abajo que el
   rooms-thumb-wrapper de arriba, ocupando la misma esquina donde vive el
   boton por defecto (medido en vivo: solape real entre ambos rects a 500px).

   PERO subirlo a arriba-derecha (igual que el bloque de rooms de arriba) NO
   vale aqui: esa esquina esta ocupada TAMBIEN por el boton "Cerrar formulario de
   reservas" de la mascara (#searchForm .searchFormClose, fenix-sevilla-
   hotel.css, position:fixed;top:16px;right:16px), que en <=767 es la mascara
   a pantalla completa. Regresion real detectada en QA (ago 2026): con los dos
   en top:16/right:16, el boton de pausa (z-index:20) queda ENCIMA del cierre
   (z-index:1) e intercepta todos los toques -la mascara quedaba imposible de
   cerrar por click/touch en /contacto, /rooftop y /descubre-sevilla-.
   Ademas, en movil #innerBanner pasa a z-index:inherit (bloques 768-960 y
   max-767 de inner-banner.css) para no tapar nada: eso hace que el boton de
   pausa (z-index:20) escape del stacking context de #innerBanner y compita
   directamente con el del #header (z-index:5, fenix-sevilla-hotel.css) en el
   contexto superior -y gane-, tapando TAMBIEN el boton de hamburguesa del
   menu (verificado en vivo: elementFromPoint sobre el centro exacto del
   hamburguesa devolvia el boton de pausa). Subir z-index al cierre para
   "colarlo" por encima NO es opcion (dejaria el boton de pausa inalcanzable,
   el mismo bug al reves) y tampoco arregla lo del hamburguesa.

   Solucion: centrado vertical (top:50% + translateY, como ya hace el propio
   inner-thumb-wrapper en escritorio, inner-banner.css:119-121) en vez de
   pegado arriba. A media altura de un hero movil el boton queda SIEMPRE lejos
   de las tres franjas con las que puede chocar: el header (arriba, 68-104px
   segun el sub-rango), el cierre de la mascara (arriba, solo existe en
   <=767) y la franja de miniaturas (abajo). No depende de la altura exacta
   del header en cada sub-rango -que varia entre 768-960 y <=767-, asi que
   una sola regla vale para los dos. Verificado en vivo en /contacto,
   /rooftop y /descubre-sevilla a 390x844 y 900x800: sin solape con ninguno
   de los tres. */
/* FASE 13c WCAG (2.2.2): el hero de la HOME entra aqui con el mismo tratamiento
   que #innerBanner, y por la misma razon. Se habia quedado fuera: por debajo de
   961px conservaba el bottom:16px de la regla base, que es exactamente donde vive
   .bookBtnBox -la barra fija inferior del footer, position:fixed y a lo ancho
   completo-. Medido en vivo: a 390x844 el boton queda en (330,784,44,44) y
   elementFromPoint devuelve .bookNowBtn en los SEIS puntos probados (centro y
   esquinas); a 414x896 el solape es del 100%. Con teclado funcionaba -Tab lo
   alcanza y Enter/Espacio lo activan-, pero con dedo o raton era INALCANZABLE:
   quien navega tocando no tenia ninguna forma de parar el carrusel, que es
   justo lo que exige 2.2.2.
   Centrado vertical en el lateral, igual que el hero interior: ese borde queda
   libre en movil (las miniaturas pasan a una franja horizontal abajo). */
@media (max-width: 960px) {
	#slider .js-motion-pause,
	#innerBanner .js-motion-pause {
		top: 50%;
		bottom: auto;
		transform: translateY(-50%);
	}
}


/* #El foco no aterriza debajo de la barra fija inferior (WCAG 2.4.11)
==================================================
   Por debajo de 767px la maqueta pinta .bookBtnBox: una barra position:fixed
   pegada al borde inferior, a lo ancho completo, con el widget de fidelizacion
   y el boton RESERVAR.

   El problema no es la barra, es como se lleva con el teclado. Al TABULAR hacia
   abajo, el navegador sube cada control nuevo lo MINIMO imprescindible para que
   entre en pantalla, o sea lo deja pegado al borde inferior — que es justo donde
   esta la barra. El navegador no sabe que ahi hay algo fijo encima.

   Medido en vivo en la home a 390px: de los 95 elementos focusables de la
   pagina, 69 acaban solapando la barra al recibir el foco, muchos al 100%.
   Confirmado con TECLA REAL sobre la pestana "Single Deluxe": queda en 799-812
   con la barra en 792-844, tapada entera, y elementFromPoint sobre su centro
   devuelve .bookBtnBox. Con la regla puesta, los 69 pasan a 1 — y ese ultimo es
   un contenedor mas alto que el viewport, que no cabe en pantalla por
   definicion.

   POR QUE IMPORTA EN UNA MAQUETA "DE MOVIL", donde no hay tecla Tab: esta
   maqueta no se ve solo en telefonos. Se activa por debajo de 768px de ancho
   CSS, y ahi entra el ESCRITORIO CON ZOOM AL 400% -escenario explicito de
   1.4.10-, donde el usuario tiene teclado completo. Reproducido con user agent
   de escritorio y ventana estrecha, sin emular movil: mismo 100% de solape.
   Ademas el foco secuencial existe en movil por otras vias: teclado externo,
   control por interruptor (iOS/Android) y el cursor de VoiceOver/TalkBack, que
   tambien desplaza el elemento a la vista.

   80px = los 66 de la barra mas 14 de holgura.

   NO CAMBIA NADA VISUALMENTE: scroll-margin no mueve ningun elemento, solo le
   dice al navegador donde paran los desplazamientos que EL decide hacer para
   que algo sea visible. Y si un navegador no la soporta, el comportamiento es
   el de siempre: es mejora progresiva, no puede romper nada.

   No interfiere con la navegacion por anclas del proyecto: anchor-nav.js anima
   scrollTop a mano y mueve el foco con preventScroll:true, asi que ni consulta
   este valor. */
@media (max-width: 767px) {
	a[href],
	button,
	input,
	select,
	textarea,
	[tabindex]:not([tabindex="-1"]) {
		scroll-margin-bottom: 5rem;
	}
}