/**
 * CIDID - Correcciones de accesibilidad (P0-P2).
 * Ver wp-content/mu-plugins/cidid-accessibility-fixes.php y correcciones.md
 */

/* P0-1: el disparador del selector de idioma de Weglot ahora es focoable
   (ver cidid-a11y.js); aseguramos que el foco se vea con claridad. */
.weglot_switcher [role="combobox"]:focus-visible {
	outline: 3px solid #2b1661;
	outline-offset: 2px;
}

/* Contraste insuficiente en los puntos de paginación del carrusel (Owl
   Carousel, usado por el widget de imágenes de Pagelayer - reportado por el
   usuario en la página "Call for papers", pero el carrusel es el mismo en
   cualquier página que use este widget). Los colores por defecto del propio
   plugin (owl.theme.default.min.css: "#D6D6D6" para el punto inactivo,
   "#869791" para el activo/hover) dan un contraste de solo 1.06:1 y 2.24:1
   contra el fondo del sitio (#e0dcd1) - muy por debajo del 3:1 mínimo que
   exige WCAG 2.2 1.4.11 (Contraste no textual) para componentes de interfaz
   como estos. Se sustituyen por un gris más oscuro (3.32:1) para el punto
   inactivo y el color de acento del propio sitio (#2b1661, 11:1) para el
   activo/hover - de paso, distingue mejor visualmente qué diapositiva está
   activa. La regla del plugin no lleva "!important" y esta hoja de estilos
   carga después en la página, pero se añade "!important" de todas formas
   para que la corrección sea robusta ante cambios de orden de carga. */
.pagelayer-owl-theme .pagelayer-owl-dots .pagelayer-owl-dot span {
	background: #767676 !important;
}
.pagelayer-owl-theme .pagelayer-owl-dots .pagelayer-owl-dot.active span,
.pagelayer-owl-theme .pagelayer-owl-dots .pagelayer-owl-dot:hover span {
	background: #2b1661 !important;
}

/* P2-1: enlace de "saltar al contenido" (inyectado en PHP, ver
   cidid-accessibility-fixes.php, ya que la plantilla de cabecera propia de
   Pagelayer sustituye el header.php del tema -y con el, su propio
   skip-link-). Oculto visualmente hasta que recibe el foco, igual que el
   patron estandar de WordPress (.screen-reader-text). */
.cidid-skip-link {
	position: absolute;
	top: -999px;
	left: 0;
	z-index: 100000;
	padding: 12px 20px;
	background: #ffffff;
	color: #2b1661;
	font-weight: bold;
	text-decoration: underline;
}
.cidid-skip-link:focus {
	top: 0;
	outline: 3px solid #2b1661;
	outline-offset: 2px;
}

/* P1-1 / P2-2: contraste insuficiente en los botones "REGISTER NOW"/"INSCRÍBETE"
   (id de widget eda2504) y "DONATE" (id de widget agq6658) en la Home ES/EN.
   El color visible (#ffffff sobre #867999, 4.03:1) no es un valor propio del
   widget: sale de la variable de color de acento global del tema combinada con
   una superposición de la fila ("pagelayer-background-overlay"), así que en vez
   de tocar esa variable global (afectaría a otros elementos del sitio) se fija
   un fondo opaco propio solo en estos dos botones conocidos, con contraste de
   sobra (~6:1) y un estado de foco visible para el criterio 2.4.7.
   Nota tecnica: Pagelayer genera para cada widget un <style> propio incrustado
   en el cuerpo de la pagina (con la misma especificidad ".p-ID .clase" y sin
   !important), que por ir despues en el documento gana el empate de cascada
   frente a una hoja de estilos normal enlazada en el <head>. Para ganar de
   forma fiable, sea cual sea el orden, se duplica la clase (sube la
   especificidad) y se usa !important. */
.p-eda2504.p-eda2504 .pagelayer-btn-holder.pagelayer-btn-holder,
.p-agq6658.p-agq6658 .pagelayer-btn-holder.pagelayer-btn-holder {
	background-color: #000000 !important;
}
.p-eda2504.p-eda2504 .pagelayer-btn-holder.pagelayer-btn-holder:focus-visible,
.p-agq6658.p-agq6658 .pagelayer-btn-holder.pagelayer-btn-holder:focus-visible {
	outline: 3px solid #2b1661 !important;
	outline-offset: 2px;
}

/* P1-2: enlaces dentro de un bloque de texto que solo se distinguen por el
   color (ej. "the JACCES website" en Call for Papers, azul #0000ee por
   defecto del navegador, sin ningún estilo propio, 2.23:1 de contraste).
   Un enlace muy oscuro sobre texto negro nunca llega a 3:1 solo por color, así
   que la vía fiable es el subrayado (el otro criterio que exige la regla):
   se usa !important y clase duplicada por el mismo motivo que en los botones
   de arriba, para que el subrayado no lo pisen los estilos propios del tema.
   Cubre los widgets de contenido de Pagelayer donde ha aparecido este mismo
   patrón hasta ahora: el widget de texto (.pagelayer-text-holder, ej. el
   enlace a JACCES en Call for Papers) y el widget de lista
   (.pagelayer-list-item, ej. el enlace a ORCID en Presentación). Si aparece
   en otro widget de contenido nuevo, añadir aquí su clase contenedora. */
.pagelayer-text-holder a,
.pagelayer-list-item a {
	color: #0645ad;
	text-decoration: underline !important;
}
.pagelayer-text-holder a:focus-visible,
.pagelayer-text-holder a:hover,
.pagelayer-list-item a:focus-visible,
.pagelayer-list-item a:hover {
	outline: 2px solid #2b1661;
	outline-offset: 2px;
}

/* P0-4 (reportado por el usuario) / Lector de pantalla #4 (evolucion
   posterior, a peticion del usuario): los submenus del menu principal
   (widget "wp_menu" de Pagelayer, en cabecera, pie y version movil) llevan
   "display:none" por defecto (wp-content/plugins/pagelayer/css/
   pagelayer-frontend.css:3157-3159) y solo se muestran con ":hover" (raton)
   o añadiendo la clase "pagelayer-active-sub-menu" (linea 3309 de ese mismo
   CSS del plugin, sin tocar) al elemento de menu.
   La primera version de esta correccion (P0-4) mostraba el submenu con
   ":focus-within" en cuanto el foco de teclado entraba en el enlace padre,
   antes de que existiera un boton dedicado. Ahora que el punto 4 añade un
   <button class="cidid-submenu-toggle"> real que ya alterna esa misma clase
   "pagelayer-active-sub-menu" al activarlo (ver cidid-a11y.js), ese
   ":focus-within" ya no hace falta - y ademas hacia que el submenu se
   abriera solo con tabular hasta el enlace padre, sin ninguna accion
   explicita, lo cual el usuario pidio evitar (el patron "disclosure" de
   WAI-ARIA recomienda que sea el propio boton, y solo el, quien controle la
   visibilidad). Se retira esta regla: ahora la visibilidad del submenu por
   teclado depende exclusivamente de esa clase, que solo cambia el boton (o,
   para cerrar, la tecla Escape - ver cidid-a11y.js). */

/* Lector de pantalla #4: el <a> de los elementos de menu con submenu ya no
   necesita la flecha que el propio JS de Pagelayer sigue añadiendo dentro de
   el (ver pagelayer_primary_menu() en su combined.js) - esa funcion la
   cumple ahora el <button class="cidid-submenu-toggle"> propio, hermano del
   enlace, asi que se oculta la flecha vieja para no duplicar el indicador. */
.pagelayer-wp-menu-container li.menu-item-has-children > a > .after-icon {
	display: none;
}

.cidid-submenu-toggle {
	background: none;
	border: none;
	cursor: pointer;
	padding: 4px 8px;
	color: inherit;
	font-size: inherit;
}
.cidid-submenu-toggle:focus-visible {
	outline: 2px solid #2b1661;
	outline-offset: 2px;
}

/* Lector de pantalla #4 (regresion visual detectada por el usuario): el
   propio Pagelayer pone el <a> de cada item de menu en "display:flex"
   (pagelayer-frontend.css, regla ".pagelayer-wp-menu-container
   .pagelayer-wp_menu-ul li.menu-item>a") - un flex EN BLOQUE, que por tanto
   ocupa el ancho completo de su <li>. Mientras el <a> era el unico hijo no
   se notaba, pero el <button class="cidid-submenu-toggle"> añadido justo
   despues (punto 4) es su hermano, y al no caber en esa misma "linea" que el
   <a> ya ocupa entera, se veia empujado a la linea de abajo - con foco
   incluido, ya que sigue siendo un control real, solo que mal colocado
   visualmente.
   Se acota a ".pagelayer-wp_menu-ul" (el <ul> del NIVEL SUPERIOR del menu,
   una clase distinta de ".sub-menu" que usan los submenus anidados) para no
   afectar a como se ven las propias filas de un submenu ya desplegado, que
   si deben ocupar el ancho completo de su fila. Al pasar a "inline-flex"
   (en linea, no en bloque), el <a> deja de forzar el salto de linea y el
   boton puede colocarse justo a su lado, en la misma fila, en las 3
   variantes del menu (escritorio, movil y pie). */
.pagelayer-wp-menu-container .pagelayer-wp_menu-ul > li.menu-item-has-children > a {
	display: inline-flex !important;
}

/* Lector de pantalla #13: el <span class="cookieadmin_show_pref_cookies">
   original (icono de expandir/contraer categoria de cookies) pasa a
   <button> en PHP; se anula el aspecto por defecto que el navegador da a un
   <button> (fondo, borde, padding) para conservar el mismo aspecto visual
   que ya tenia como <span> (ver .cookieadmin_show_pref_cookies en
   consent.css del propio plugin: solo cursor y tamaño/familia de letra). */
button.cookieadmin_show_pref_cookies {
	background: none;
	border: none;
	padding: 0;
	color: inherit;
}
button.cookieadmin_show_pref_cookies:focus-visible {
	outline: 2px solid #2b1661;
	outline-offset: 2px;
}

/* Lector de pantalla #15: "CALL FOR PAPERS"/"Ampliamos plazo"/"hasta el 15 de
   septiembre" (widget de texto "zfa8817") pasan de <h2> a <p> en PHP, ya que
   no introducen ninguna sección propia. Ese widget no fija ningún tamaño ni
   grosor de letra propio en su <style>, así que el tamaño/grosor que tenía
   dependía por completo de otra regla del tema - al quitar la etiqueta de
   encabezado se perdía tambien eso.
   El valor exacto (45px/700/line-height 1.2) lo confirmó el usuario mirando
   la pestaña "Computed" del inspector del navegador sobre la web con el
   aspecto correcto: la regla que de verdad coincide ahi es
   "body.pagelayer-body h1" (no la de <h2>, que es la que se habia usado en
   los dos intentos anteriores, con 32px/400 y luego 40px/700 a ojo, ninguno
   de los dos correcto) - pese a que el propio contenido guardado usa <h2>
   para este bloque, visualmente se disena como un h1.
   (El color y el centrado de este mismo bloque, en cambio, NO tienen que
   ver con este cambio de etiqueta - ver la nota mas abajo, "Bug de Pagelayer
   ...", que los repone junto con el resto del texto de toda la sección.)
   Nota tecnica: el tema fija una regla global "body.pagelayer-body p" (mas
   especifica que un simple ".p-zfa8817 p") que fuerza otro tamaño/grosor en
   todos los parrafos del sitio - hace falta la misma tecnica que en el aviso
   de contraste de mas arriba (duplicar la clase para subir la especificidad
   y usar !important) para ganarle de forma fiable. */
.p-zfa8817.p-zfa8817 p {
	font-family: Raleway;
	font-size: 45px !important;
	font-weight: 700 !important;
	line-height: 1.2;
	text-align: center;
}
@media (max-width: 768px) {
	.p-zfa8817.p-zfa8817 p {
		font-size: 40px !important;
	}
}
@media (max-width: 500px) {
	.p-zfa8817.p-zfa8817 p {
		font-size: 40px !important;
	}
}

/* Lector de pantalla #15: el subtítulo "Repensar la investigación desde la
   discapacidad..." (widget de texto "l2h6106") pasa de <h2> a <p> en PHP.
   Igual que "CALL FOR PAPERS" (arriba), no fija ningún tamaño de letra
   propio - dependía del tamaño por defecto del tema para <h2>, que se
   repone aquí con el mismo valor. La negrita no hace falta reponerla en
   CSS: el propio texto guardado ya envuelve el subtítulo en un <strong>,
   así que se ve en negrita de forma nativa en cuanto el tamaño es correcto. */
.p-l2h6106.p-l2h6106 p {
	font-family: Raleway;
	font-size: 32px !important;
	font-weight: 400 !important;
	line-height: 1;
}
@media (max-width: 768px) {
	.p-l2h6106.p-l2h6106 p {
		font-size: 28px !important;
	}
}
@media (max-width: 500px) {
	.p-l2h6106.p-l2h6106 p {
		font-size: 26px !important;
	}
}

/* Bug de Pagelayer (no relacionado con ninguna de nuestras correcciones de
   accesibilidad - detectado al comparar con una captura de la web con el
   aspecto correcto) que vacía los atributos "style"/"color" en linea del
   texto de los widgets "Texto" de esta sección (la portada con la foto del
   auditorio) al renderizarlos para visitantes normales.
   Verificado comparando el contenido tal cual está guardado en la base de
   datos (con el HTML real, ej. <span style="color:#ffffff">) contra el HTML
   que Pagelayer sirve finalmente (con esos mismos atributos ya vacíos,
   style="" / color="") - el propio filtro "the_content" de Pagelayer
   (wp-content/plugins/pagelayer/main/live.php) es quien los vacía; no
   interviene SpeedyCache, Weglot ni ningún código nuestro (comprobado
   desactivando cada uno por separado). Afecta a los 7 bloques de texto de
   esta sección: el aviso "CALL FOR PAPERS", el título "CIDID 2026", el
   subtítulo "Repensar la investigación..." y los 4 párrafos de presentación
   - todos ellos debían mostrarse en blanco (y el aviso, además, centrado),
   tal cual sigue guardado en la base de datos.
   Se repone aquí ese mismo color en todo el texto de la sección (acotado por
   el "pagelayer-id" de la fila, "9ic6500", estable aunque cambie el
   contenido) en vez de arreglar el plugin de terceros directamente, para que
   la corrección sobreviva a sus actualizaciones. */
.p-9ic6500 h1 {
	color: #ffffff !important;
}
.p-9ic6500 .pagelayer-text-holder,
.p-9ic6500 .pagelayer-text-holder * {
	color: #ffffff !important;
}

/* Lector de pantalla #15: "Facultad de Ciencias de la Información"/
   "UNIVERSIDAD COMPLUTENSE DE MADRID"/"5 y 6 de octubre 2026" (widget de
   texto "ios4136") pasan de <h3> a <p> en PHP. A diferencia del bloque de
   arriba, este widget NO lleva ningún color en su texto guardado en la base
   de datos (no es el mismo bug de Pagelayer) - su tamaño y color dependían
   simplemente de la regla global del tema para <h3> ("body.pagelayer-body
   h3": 28px/400/line-height 1.2/color #2b1661, valores confirmados por el
   usuario en el inspector), que se pierden al dejar de ser un encabezado.
   El "font-size: 18px !important" que fija el propio widget en su <style>
   (".p-ios4136") no llega a afectar a esto: se aplica al contenedor, pero
   tanto <h3> como <p> tienen su propia regla directa de tamaño en el tema
   -y una regla que afecta directamente a un elemento siempre gana sobre lo
   heredado de un antecesor, tenga o no !important-, así que ese texto nunca
   dependió realmente del tamaño del widget. Se repone aquí el tamaño/grosor
   real de <h3>, con sus mismos puntos de corte responsive. */
.p-ios4136.p-ios4136 p {
	font-family: Raleway;
	font-size: 28px !important;
	font-weight: 400 !important;
	line-height: 1.2;
	color: #2b1661;
}
@media (max-width: 768px) {
	.p-ios4136.p-ios4136 p {
		font-size: 26px !important;
	}
}
@media (max-width: 500px) {
	.p-ios4136.p-ios4136 p {
		font-size: 24px !important;
	}
}

/* Mismo bug de Pagelayer que el bloque "Bug de Pagelayer..." de mas arriba
   (vacia atributos "style" en linea al renderizar los widgets de texto para
   un visitante normal), detectado aqui por el usuario al comparar contra la
   web con el aspecto correcto: el titulo "Dona por una ciencia desde la
   discapacidad" (widget "svo4075", que no ha sido tocado por ninguna
   correccion - sigue siendo un <h2>) guarda en la base de datos
   <h2 style="text-align: center">, pero ese "text-align" llega vacio al
   HTML final. Se repone aqui igual que los demas casos, acotado por el
   "pagelayer-id" propio del widget. */
.p-svo4075 h2 {
	text-align: center;
}

/* Mismo bug de Pagelayer, ahora en el widget "Service" (no el widget
   "Texto") de las 2 tarjetas de "CIDID en medios" (ver tambien el punto 16,
   mas abajo, que convierte estos mismos titulares de <div> a <h3>): el
   titular guardado en la base de datos envuelve el texto en
   <span style="color:#2b1661ff">, y el texto de fuente/fecha en
   <font color="#2b1661"> (o simplemente hereda ese color) - ambos se vacian
   al renderizar, dejando solo el color de respaldo mas claro que el propio
   widget define aparte ("service_heading_color":"#0986c0") para el titular,
   y el negro por defecto para el texto de fuente/fecha.
   El propio widget ya trae su color de respaldo en un <style> embebido en el
   cuerpo de la pagina (sin !important) - hace falta la misma tecnica de
   siempre (duplicar la clase para subir la especificidad, ademas de
   !important) para ganarle de forma fiable, ya que ese <style> del widget
   aparece despues en el documento que esta hoja de estilos. */
.p-b7g6692.p-b7g6692 h3.pagelayer-service-heading,
.p-qnv5933.p-qnv5933 h3.pagelayer-service-heading {
	color: #2b1661 !important;
}
.p-b7g6692 p.pagelayer-service-text,
.p-qnv5933 p.pagelayer-service-text {
	color: #2b1661;
}

/* Mismos widgets de arriba ("CIDID en medios"): al pasar de <div> a <h3>/<p>
   (punto 16), el titular y el texto de fuente/fecha ganan el margen vertical
   que el navegador da por defecto a esas etiquetas (los <div> originales no
   llevaban ninguno - el espaciado lo daba solo el padding propio del
   widget), separando mas las lineas de lo que se veia antes. Se quita aqui,
   acotado a estas 2 tarjetas en concreto (no un reset global de <h3>/<p>). */
.p-b7g6692 .pagelayer-service-heading,
.p-qnv5933 .pagelayer-service-heading,
.p-b7g6692 .pagelayer-service-text,
.p-qnv5933 .pagelayer-service-text {
	margin: 0;
}

/* Mismos widgets: comparando el inspector sobre la web original (que sigue
   usando <div>, sin la correccion del punto 16), el usuario detecto que
   "font-family" y "line-height" tampoco coinciden. Causa: el propio widget
   fija esas dos propiedades con un valor vacio en su <style> (p.ej.
   "font-family: ; line-height: em !important;"), lo que el navegador
   ignora por completo, así que un <div> las heredaba sin mas del contexto
   (Arial, el tipo de letra base del sitio). Al convertir a <h3>/<p> (punto
   16), esas etiquetas pasan a tener su propia regla directa en el tema
   ("body.pagelayer-body h3/p": familia Raleway, interlineado 1.2/1.3) que
   ya no se hereda del contexto, sin que ninguna de las correcciones
   anteriores (color, tamaño, margen) la afectase. Se fuerza aqui a heredar
   del contexto igual que antes. */
.p-b7g6692 .pagelayer-service-heading,
.p-qnv5933 .pagelayer-service-heading,
.p-b7g6692 .pagelayer-service-text,
.p-qnv5933 .pagelayer-service-text {
	font-family: inherit;
	line-height: inherit;
}

/* Mismo bug de Pagelayer una vez mas: el texto "SERVIMEDIA |" (tarjeta
   "b7g6692") y los dos tramos de texto de la tarjeta "qnv5933"
   ("Centro Español..." y el separador "|") guardan en la base de datos su
   propio <span style="font-size: 18px..."> (el texto de fuente/fecha no
   tiene, a diferencia del titular, ningun tamaño de respaldo a nivel de
   widget) - se vacia igual que el resto y se repone aqui. */
.p-b7g6692 .pagelayer-service-text span {
	font-size: 18px;
	font-weight: 600;
}
.p-qnv5933 .pagelayer-service-text span {
	font-size: 18px;
}
.p-qnv5933 .pagelayer-service-text span:last-of-type {
	font-weight: 600;
}

/* El texto guardado lleva un "&nbsp;" justo despues del "|" (separador
   entre la fuente/titular y la fecha), pero a ese tamaño/grosor concretos
   (18px, negrita) se ve demasiado pegado a la fecha que viene justo
   despues. Se añade un pequeño margen para separarlo con claridad. */
.p-b7g6692 .pagelayer-service-text span,
.p-qnv5933 .pagelayer-service-text span:last-of-type {
	margin-right: 0.25em;
}

/* Mismo bug de Pagelayer, ahora en el span interior del propio titular (ver
   la nota "color:#2b1661ff" de mas arriba): junto al color, ese titular
   guarda tambien <span style="font-weight: normal"> en un span anidado
   dentro del que lleva el color - el texto real del titular esta dentro de
   este span interior. El widget fija "font-weight: 600 !important" en
   ".pagelayer-service-heading" (el <h3>, ver mas arriba), pero eso es solo
   el valor HEREDADO por sus descendientes; una regla que afecta
   directamente a un elemento (este span) siempre gana sobre lo heredado de
   un antecesor, aunque el antecesor tenga !important - por eso hace falta
   reponer esto explicitamente para que el titular vuelva a verse en peso
   normal (no en negrita) como en la web original, mientras que el texto de
   fuente/fecha de al lado si sigue en negrita. */
.p-b7g6692 .pagelayer-service-heading > span > span,
.p-qnv5933 .pagelayer-service-heading > span > span {
	font-weight: normal;
}

/* Mismo bug de Pagelayer de siempre, ahora en la página Contacto: el título
   "CONTACTA" y el correo debajo (widget de texto "3je6631") guardan en la
   base de datos <h1 style="text-align: center">/<h4 style="text-align:
   center">, pero ese "text-align" llega vacío al HTML final, dejando el
   texto sin centrar. Se repone aquí, acotado a este widget. */
.p-3je6631 h1,
.p-3je6631 h4 {
	text-align: center;
}