Buscador

miércoles, 31 de diciembre de 2025

Predicciones sobre accesibilidad para el 2026

En 2026 Predictions: The Next Big Shifts in Web Accessibility se realizan las siguientes predicciones sobre accesibilidad para el año 2026:

  1. Se subraya que la inteligencia artificial mejorará las herramientas de accesibilidad, especialmente en eficiencia, detección de patrones y priorización de problemas, pero no sustituirá el juicio experto humano. La evaluación del significado, el contexto o la experiencia real de uso seguirá requiriendo revisión especializada.
  2. Se prevé que WCAG 2.2 se consolide como el estándar de referencia en contratación y evaluaciones, desplazando definitivamente a WCAG 2.1. Sus cambios no son disruptivos, pero sí responden a barreras reales y habituales para las personas usuarias.
  3. Se espera el retorno progresivo al uso de HTML nativo, reduciendo la dependencia de componentes personalizados complejos basados en JavaScript y ARIA. El uso de controles estándar mejora la interoperabilidad, la mantenibilidad y la accesibilidad de forma más fiable.
  4. Se cree que más organizaciones reconocerán el riesgo de la deuda de accesibilidad, entendida como la acumulación de problemas no resueltos a lo largo del tiempo. Cada vez más organizaciones la reconocerán como un riesgo empresarial, legal y reputacional, lo que impulsará enfoques de mantenimiento continuo en lugar de correcciones puntuales.
  5. Se destaca que la accesibilidad en aplicaciones nativas influirá cada vez más en la web, favoreciendo principios comunes como la previsibilidad, el orden lógico, las alternativas a gestos y la claridad en los controles.
  6. Se cree que aumentará la importancia de las preferencias del usuario (reducción de movimiento, alto contraste, modo oscuro, tamaño de texto, zoom). La accesibilidad dejará de entenderse como un diseño único y pasará a concebirse como la capacidad de adaptarse a configuraciones individuales.
  7. Finalmente, aunque WCAG 3 aún no esté publicada, su enfoque centrado en resultados, tareas y usabilidad ya está influyendo en la práctica profesional. Se dará más peso al impacto real, la severidad de los problemas y las consideraciones cognitivas.

lunes, 29 de diciembre de 2025

¿Qué se puede automatizar en la evaluación de la accesibilidad web?

Steve Faulkner analiza en mind the WCAG automation gap los criterios de WCAG que se pueden automatizar.

Por ejemplo, para SC 1.1.1 Non-text Content (A) indica:
Testability: ⚠️ Partial

Automation can:
Detect presence or absence of alt attributes.
Identify empty/missing alt on <img> elements.
Identify images using role="presentation" or aria-hidden="true".

Automation cannot:
Assess if alt text is meaningful or contextually accurate.
Confirm whether the alt conveys the image’s purpose.
Validate completeness of alternatives for complex content (e.g., charts).


Y para SC 2.4.3 Focus Order (A):
Testability: ⚠️ Partial

Automation can:
Read the DOM/tab order.
Flag unusual jumps or unreachable elements.

Automation cannot:
Evaluate whether the focus order matches visual/reading order.
Confirm whether users can complete tasks logically by keyboard.

lunes, 22 de diciembre de 2025

Guía panhispánica de lenguaje claro y accesible

La Guía panhispánica de lenguaje claro y accesible ofrece recursos, advertencias y recomendaciones para promover un uso del español claro, comprensible y accesible en todos los ámbitos comunicativos. El objetivo es promover una comunicación más clara, inclusiva y accesible para toda la ciudadanía.

miércoles, 17 de diciembre de 2025

Cinco razones por las que el cumplimiento de WCAG no asegura que tu sitio web sea realmente accesible

El artículo 5 reasons why WCAG AA compliance does not mean your website is accessible es una buena reflexión sobre qué significa realmente ser accesible. 

El artículo desmonta la idea extendida de que cumplir las WCAG 2.x en nivel AA garantiza que un sitio web sea accesible. Aunque este nivel suele considerarse el objetivo final, en realidad debería entenderse como un punto de partida mínimo, ya que es posible que un sitio web sea formalmente conforme y, aun así, resulte inaccesible o muy difícil de usar para la mayoría de las personas.

El motivo principal es que las WCAG no evalúan la calidad de la experiencia de usuario, sino que buscan evitar que las personas con discapacidad estén en desventaja respecto al resto. Por tanto, una experiencia puede ser objetivamente mala y seguir cumpliendo las WCAG, siempre que sea igual de mala para todas las personas.

El texto ilustra esta limitación con cinco ejemplos:

  1. Uso del color: el criterio solo se aplica cuando el color se utiliza para transmitir información. Si un enlace o un estado visual no se diferencia del texto normal ni siquiera mediante color, puede cumplir WCAG aunque nadie sea capaz de identificarlo como enlace, lo que genera una usabilidad muy deficiente.
  2. Tamaño de fuente: las WCAG no establecen un tamaño mínimo de texto. Teóricamente, se podría usar un texto extremadamente pequeño y cumplir los criterios de contraste y redimensionado, aunque resulte ilegible para cualquier persona.
  3. Velocidad de carga: los criterios sobre tiempos se centran en elementos temporizados de la interfaz, pero no contemplan problemas graves de rendimiento. Un sitio que tarda mucho en cargar puede ser prácticamente inutilizable y, aun así, cumplir WCAG AA.
  4. Complejidad del lenguaje: los requisitos sobre que el contenido sea realmente comprensible (nivel de lectura, uso de abreviaturas, claridad del lenguaje) pertenecen al nivel AAA y suelen ignorarse. En nivel AA basta con que el idioma esté correctamente definido y que títulos o enlaces describan su propósito, aunque el texto sea excesivamente técnico o difícil de entender.
  5. Calidad del audio: las WCAG exigen alternativas al audio, como transcripciones, pero no consideran la calidad sonora. Un audio ininteligible puede cumplir WCAG AA si existe una alternativa, aunque la experiencia sea pobre para todo el mundo.

Como conclusión, el autor subraya que las WCAG no pretenden medir la usabilidad ni la calidad global de un producto digital, sino garantizar la igualdad de acceso entre personas con y sin discapacidad. Por ello, describir un sitio como “totalmente accesible” solo por cumplir WCAG 2.2 AA es impreciso. Lo más adecuado es entender ese cumplimiento como una base mínima que reduce la probabilidad de discriminar a personas con discapacidad, pero que no garantiza, por sí sola, una buena experiencia de uso.

lunes, 15 de diciembre de 2025

¿Por qué son importantes los estilos alternativos en una página web?

 


Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y en este vídeo que forma parte del curso “Introducción al desarrollo web”, te voy a hablar de la importancia de ofrecer estilos alternativos en una página web.

Si se les pregunta a los usuarios de la Web cómo es una página web “buena”, probablemente la mayoría pensará en un diseño visual atractivo, con colores armónicos, tipografías modernas y animaciones, muchas animaciones. Y no les faltaría razón. Pero ¿qué pasa cuando este diseño, pensado para la mayoría, no funciona para todos?

A las páginas web acceden miles de millones de usuarios, muchos de ellos con necesidades, preferencias y contextos de uso diferentes. En especial, las personas con discapacidad muchas veces experimentan problemas, barreras, al navegar por las páginas web.

Por ejemplo, este artículo del prestigioso periódico The New York Times tiene un importante problema de contraste en el título del artículo y en la entradilla. [P] Una persona sin discapacidad seguramente leerá con algunos problemas el título y la entradilla. Pero una persona con discapacidad visual o discapacidad cognitiva quizás sea incapaz de leerlo y entenderlo.

Este problema es muy fácil de resolver.

Los diseñadores web del periódico The New York Times podrían simplemente añadir un fondo semitransparente al título y a la entradilla que aumentase el contraste entre el texto y la fotografía de fondo.

¿Y esto cómo se hace? Seguramente pensarás que es difícil o requiere mucho tiempo y por eso no lo han hecho. Bueno, en realidad, en lo que he tardado en sacarme un moco de la nariz he añadido el código necesario para resolver este problema.

Y entonces, ¿por qué no lo han hecho? Bueno, podemos pensar en muchas razones, pero por mi experiencia, normalmente, el propietario o el diseñador del sitio quiere que su sitio web se vea exactamente de una forma concreta, aunque eso sea negativo para muchos usuarios.

La solución a esta situación es sencilla, podemos diseñar nuestro sitio web con un estilo principal y con todas las mierdas que queramos, aunque nos estemos pegando un tiro en el pie.

Pero a la vez, también debemos ofrecer estilos alternativos para desarrollar una web verdaderamente universal y robusta.

Los estilos alternativos son versiones de nuestra hoja de estilos principal que ofrecen una experiencia de usuario diferente. No son un sitio web nuevo, sino una adaptación del mismo contenido. Los más comunes son:

Estilo oscuro: para reducir la fatiga visual en entornos con poca luz o por preferencia personal.

Estilo de alto contraste: para usuarios con baja visión.

Estilo texto grande: para usuarios con baja visión.

Estilo daltonismo: que ajusta la paleta de colores para garantizar que la información se perciba correctamente.

Estilo de lectura: que elimina elementos superfluos como menús y publicidad para concentrarse en el contenido principal.

Estilo para impresión: elimina elementos superfluos como menús y adapta el contenido al tamaño de una hoja de papel.

Hoy en día, muchos sitios web ofrecen algunos de estos estilos alternativos. Por ejemplo, en mi sitio web sobre accesibilidad web ofrezco una opción de configuración que permite que el usuario seleccione un estilo que se adapte mejor a sus necesidades: el estilo principal, dos estilos de alto contraste (amarillo sobre negro y verde sobre negro), colores de bajo contrate y estilos con diferentes tipos de letra.

Aquí tenemos otro ejemplo, la web de La Moncloa, que por defecto aparece con el modo claro, pero que tiene una opción para cambiar al modo oscuro.

¿Y cómo se ofrecen los estilos alternativos en un sitio web? Existen varias formas, en el vídeo “CSS: definición y uso de estilos alternativos” te explico una forma que se puede emplear en Mozilla Firefox, de forma nativa, y en otros navegadores web con alguna extensión. Pero en la mayoría de los casos, tendrás que proporciona un selector de estilos como el que hemos visto en la web de La Moncloa.

Sobre el estilo para impresión te recomiendo los siguientes vídeos. Por un lado, te recomiendo que veas el vídeo “CSS: hoja de estilo para impresión”, del estudiante Samuel López Brufal. En este vídeo se enseña a crear un CSS correcto para imprimir las páginas web.

Muchos diseñadores no optimizan las páginas web para impresión, lo que genera confusión al imprimir.

Samuel propone los siguientes consejos para una correcta hoja de estilo para impresión:

Diseño adaptativo para impresión.

Uso de tonos blancos y negros (o colores originales si es necesario).

Incluir las URLs visibles para referencia posterior.

Y aplicar filtros CSS para mejorar los resultados.

En el vídeo de Samuel también se explica que se deben evitar las divisiones en tablas y listas con las siguientes propiedades de CSS: page-break-inside, page-break-before y page-break-after.

En realidad, estas propiedades de CSS están obsoletas y en su lugar se deben emplear las propiedades break-after, break-before y break-inside.

El tema de evitar las divisiones en tablas y listas lo tienes desarrollado con más profundidad en los siguientes vídeos. “CSS: cómo controlar los puntos de corte cuando se imprime una página”, parte 1 y parte 2. Y con esto finaliza este vídeo en el que te he explicado la importancia de los estilos alternativos en las páginas web.

Recuerda que este vídeo forma parte del curso “Introducción al desarrollo web” que está disponible en la dirección idesweb.es.

Muchas gracias por tu atención.

lunes, 8 de diciembre de 2025

miércoles, 3 de diciembre de 2025

Día Internacional de las Personas con Discapacidad

Hoy 3 de diciembre se celebra el Día Internacional de las Personas con Discapacidad:

El Día Internacional de las Personas con Discapacidad fue declarado en 1992 por la Asamblea General de las Naciones Unidas mediante la resolución 47/3. El objetivo es promover los derechos y el bienestar de las personas con discapacidades en todos los ámbitos de la sociedad y el desarrollo, así como concienciar sobre su situación en todos los aspectos de la vida política, social, económica y cultural.

viernes, 28 de noviembre de 2025

¿El código que generan los LLM es accesible?

En AI will soon deliver code that will pass automatic testing by defaultA11y LLM Eval se explica una investigación que se ha realizado para verificar si los LLM generan páginas web accesibles.

Esta investigación ofrece los primeros indicadores comparativos sobre la accesibilidad del código generado por distintos modelos de inteligencia artificial. Aunque la metodología no exigía explícitamente producir resultados accesibles, los análisis mostraron resultados mejores de lo esperado.

Los resultados señalan que los errores de contraste de color siguen siendo los fallos más frecuentes. 

miércoles, 26 de noviembre de 2025

Orden de tabulación (deslizamiento) en iOS

En Accessible iOS design: how Forza Football included blind users se explica cómo modificar el orden de tabulación (deslizamiento, swipe) en iOS.

El mecanismo es similar al empleado en HTML, pero en vez de usar el atributo tabindex, se emplea la propiedad accessibilitySortPriority. En el artículo se incluyen algunos vídeos de demostración y también algunos fragmentos de código:

// Setting the reversed priorities

func playersByPosition() -> [[PlayerPrioritized]] {
  var players = awayLineup.reversed() // from forward to goalkeeper
  var sectors = [[PlayerPrioritized]]()
  var priority = viewSortingPriority

  for (i, sector) in formation.reversed().enumerated() {
    // creating inner array per formation sector
    sectors.append([PlayerPrioritized]())
    for _ in 0..<sector {
      // get and remove first player from list for next iteration
      let player = players.removeFirst()
      sectors[i].append(PlayerPrioritized(player: player, priority: priority))
      priority += 0.08 // increase priority to next player
     }
   }
  return sectors
}

// AwayTeamView

var body: some View {
  VStack {
    Text(away.lineUpHeading)
    ...
    // will be higher than first player
    .accessibilitySortPriority(viewSortingPriority + 0.95)
    ForEach(playersByPosition(), id: \.self) { sector in
      HStack {
        ForEach(sector, id: \.self) { player in 
          PlayerView(model: player)
          .accessibilitySortPriority(player.priority)
        }
      }
    }
  }
}

Y también:

// LineUps View

var body: some View {
  ScrollView {
    HomeTeamView(home: homeTeam)
    .accessibilitySortPriority(3)

    AwayTeamView(away: awayTeam,
    sortingPriority: 2)

    Text("Substitutes")
    .accessibilitySortPriority(1)

    HStack {
      BenchView(team: homeTeam)
      .accessibilitySortPriority(0.9)

      BenchView(team: awayTeam)
      .accessibilitySortPriority(0.8)
     }
  }
}

lunes, 24 de noviembre de 2025

Animaciones accesibles en páginas web



miércoles, 19 de noviembre de 2025

Un restaurante que tiene una declaración de accesibilidad mucho mejor que muchos sitios web de la administración pública

La Declaración de accesibilidad del sitio web del restaurante El Meloso es mucho mejor que la de muchos sitios web de la administración pública:



Por ejemplo, la Declaración de accesibilidad del Ayuntamiento de Albacete, que nombra las "pautas de Accesibilidad al Contenido del Web 1.0  (WCAG)":



La Declaración de accesibilidad del Ayuntamiento de Teruel, que nombra la "norma UNE 139803:2012":


lunes, 17 de noviembre de 2025

miércoles, 12 de noviembre de 2025

Una epifanía sobre la accesibilidad web

En LinkedIn podemos leer la siguiente epifanía que tuvo Mark Steadman hace unos años:
10 years ago, I was front-end web developer who was working directly on a map-module component that helped users find a specific location for insurance needs. While I built it at what I felt like was record time, I got to the end, ready to deliver and got a lovely hashtag#Accessibility audit sent to me. My initial thought? "What in the hell is this?!!". 

But that moment, was the moment that opened my eyes and my mind up to hashtag#A11y. After sitting with many users and getting mentored by many folks such as Birkir Gunnarsson and Tim Harshbarger (to name a few, there are so many more!) I realized how much my own code was causing people frustration and pain. 

I share this story because every year around this time, I am reminded how much that moment has changed me. My own personal mission has been to tell my story of my own stubborn, arrogant mind not realizing the impact of my own development and get more people to begin giving even the littlest bit of a damn about making their content accessible. 

As I always say, you accessibility folks are amazing. Keep fighting. Keep pushing. Accessibility always and forever!

Y traducido al español:
Hace 10 años, era desarrollador web front-end y trabajaba directamente en un módulo de mapas que ayudaba a los usuarios a encontrar una ubicación específica para sus necesidades de seguros. Aunque lo desarrollé en lo que yo consideraba un tiempo récord, al terminarlo, listo para su entrega, recibí una auditoría de accesibilidad (#Accessibility). ¿Mi primera reacción? "¿¡Qué demonios es esto!?".

Pero ese momento me abrió los ojos y me hizo comprender la importancia de la accesibilidad (#Accessibility). Tras reunirme con muchos usuarios y recibir mentoría de personas como Birkir Gunnarsson y Tim Harshbarger (por nombrar solo algunos, ¡hay muchísimos más!), me di cuenta de cuánta frustración y dificultades les causaba mi propio código.

Comparto esta historia porque cada año por estas fechas recuerdo cuánto me cambió ese momento. Mi misión personal ha sido contar mi historia sobre mi propia terquedad y arrogancia, que me impedía darme cuenta del impacto de mi propio desarrollo, y lograr que más personas se preocupen, aunque sea un poco, por hacer que su contenido sea accesible. Como siempre digo, ¡sois increíbles los que trabajáis por la accesibilidad! ¡Seguid luchando! ¡Seguid adelante! ¡Accesibilidad siempre y para siempre!

lunes, 10 de noviembre de 2025

¿Cómo pronuncia un lector de pantalla los emojis?

Los emojis cada vez se usan más y no solo en las conversaciones de WhatsApp y plataformas similares. Las páginas web, los correos electrónicos e incluso las comunicaciones institucionales cada vez tienen más emojis.

¿Los emojis plantean problemas de accesibilidad? Sí, unos cuantos.

En el caso de las personas con discapacidad que emplean un lector de pantalla, ¿qué anuncia el lector de pantalla cuando se encuentra un emoji?

En CSS to speech: alternative text for CSS-generated content, un excelente artículo sobre el contenido generado desde CSS y los problemas de accesibilidad que plantea, se explica lo siguiente sobre los emoji:

Where do screen readers get the alternative text for unicode characters from?

Steve Faulkner shares that the text alternatives for Unicode symbols are usually contained within a text file in screen reading software’s program files directory.

Emojis, like other unicode characters, also have default text alternatives that may differ slightly across platforms, as Steve demonstrates in his article.

The text alternatives of emojis usually describe what the emoji is, not necessarily what you might be using it for. As Craig Abbott mentions in his recent writeup about integrating AI into screen readers, the “red flag” emoji is actually announced as “triangular flag on post”, which does not usually provide enough context for the way that emoji is used in our culture.

Not to mention that the same emoji may be interpreted differently by different sighted users!

This is why using emojis to communicate meaningful information is generally not recommended.
Steve Faulkner tiene la página web Symbol text descriptions in NVDA en la que recoge lo que NVDA anuncia para más de 3900 símbolos.

Lo que NVDA anuncia para los símbolos se puede configurar a través de Preferencias > Pronunciación de Símbolos:





lunes, 3 de noviembre de 2025

Accesibilidad y posicionamiento web (SEO)


lunes, 27 de octubre de 2025

Optimización de GitHub Copilot para la accesibilidad con instrucciones personalizadas

En Optimizing GitHub Copilot for Accessibility with Custom Instructions se explica cómo emplear las "custom instructions" para adaptar el comportamiento de GitHub Copilot a las necesidades específicas de una organización o repositorio, garantizando que sus sugerencias se alineen con los estándares, flujos de trabajo y objetivos de accesibilidad del equipo. Para ello hay que tener en cuenta que existen tres niveles de configuración:
  1. Organización: define las directrices generales de accesibilidad que se aplican a todos los repositorios.
  2. Repositorio: permite establecer excepciones o requisitos específicos para un proyecto concreto.
  3. Personal: ajusta el comportamiento de Copilot Chat según las preferencias individuales, teniendo prioridad sobre las demás instrucciones.
En el artículo se explican buenas prácticas (Do’s) y malas prácticas (Don’ts).

viernes, 24 de octubre de 2025

¿Qué hacemos con WCAG 3?

Muy buena la reflexión de Karl Groves, gurú de la accesibilidad web a nivel mundial, sobre WCAG 3: Why Now Is Not the Time to Think About WCAG 3. Para mí, todo lo que explica se puede resumir en esto que dice:

WCAG 3 is basically still research.

[WCAG 3 sigue siendo básicamente investigación.]

Así que, básicamente mejor esperar a intentar realizar cualquier cambio.

miércoles, 22 de octubre de 2025

¿Por qué son importantes los estilos alternativos en una página web?

 


Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y en este vídeo que forma parte del curso “Introducción al desarrollo web”, te voy a hablar de la importancia de ofrecer estilos alternativos en una página web.

Si se les pregunta a los usuarios de la Web cómo es una página web “buena”, probablemente la mayoría pensará en un diseño visual atractivo, con colores armónicos, tipografías modernas y animaciones, muchas animaciones. Y no les faltaría razón. Pero ¿qué pasa cuando este diseño, pensado para la mayoría, no funciona para todos?

A las páginas web acceden miles de millones de usuarios, muchos de ellos con necesidades, preferencias y contextos de uso diferentes. En especial, las personas con discapacidad muchas veces experimentan problemas, barreras, al navegar por las páginas web.

Por ejemplo, este artículo del prestigioso periódico The New York Times tiene un importante problema de contraste en el título del artículo y en la entradilla. [P] Una persona sin discapacidad seguramente leerá con algunos problemas el título y la entradilla. Pero una persona con discapacidad visual o discapacidad cognitiva quizás sea incapaz de leerlo y entenderlo.

Este problema es muy fácil de resolver.

Los diseñadores web del periódico The New York Times podrían simplemente añadir un fondo semitransparente al título y a la entradilla que aumentase el contraste entre el texto y la fotografía de fondo.

¿Y esto cómo se hace? Seguramente pensarás que es difícil o requiere mucho tiempo y por eso no lo han hecho. Bueno, en realidad, en lo que he tardado en sacarme un moco de la nariz he añadido el código necesario para resolver este problema.

Y entonces, ¿por qué no lo han hecho? Bueno, podemos pensar en muchas razones, pero por mi experiencia, normalmente, el propietario o el diseñador del sitio quiere que su sitio web se vea exactamente de una forma concreta, aunque eso sea negativo para muchos usuarios.

La solución a esta situación es sencilla, podemos diseñar nuestro sitio web con un estilo principal y con todas las mierdas que queramos, aunque nos estemos pegando un tiro en el pie.

Pero a la vez, también debemos ofrecer estilos alternativos para desarrollar una web verdaderamente universal y robusta.

Los estilos alternativos son versiones de nuestra hoja de estilos principal que ofrecen una experiencia de usuario diferente. No son un sitio web nuevo, sino una adaptación del mismo contenido. Los más comunes son:

Estilo oscuro: para reducir la fatiga visual en entornos con poca luz o por preferencia personal.

Estilo de alto contraste: para usuarios con baja visión.

Estilo texto grande: para usuarios con baja visión.

Estilo daltonismo: que ajusta la paleta de colores para garantizar que la información se perciba correctamente.

Estilo de lectura: que elimina elementos superfluos como menús y publicidad para concentrarse en el contenido principal.

Estilo para impresión: elimina elementos superfluos como menús y adapta el contenido al tamaño de una hoja de papel.

Hoy en día, muchos sitios web ofrecen algunos de estos estilos alternativos. Por ejemplo, en mi sitio web sobre accesibilidad web ofrezco una opción de configuración que permite que el usuario seleccione un estilo que se adapte mejor a sus necesidades: el estilo principal, dos estilos de alto contraste (amarillo sobre negro y verde sobre negro), colores de bajo contrate y estilos con diferentes tipos de letra.

Aquí tenemos otro ejemplo, la web de La Moncloa, que por defecto aparece con el modo claro, pero que tiene una opción para cambiar al modo oscuro.

¿Y cómo se ofrecen los estilos alternativos en un sitio web? Existen varias formas, en el vídeo “CSS: definición y uso de estilos alternativos” te explico una forma que se puede emplear en Mozilla Firefox, de forma nativa, y en otros navegadores web con alguna extensión. Pero en la mayoría de los casos, tendrás que proporciona un selector de estilos como el que hemos visto en la web de La Moncloa.

Sobre el estilo para impresión te recomiendo los siguientes vídeos. Por un lado, te recomiendo que veas el vídeo “CSS: hoja de estilo para impresión”, del estudiante Samuel López Brufal. En este vídeo se enseña a crear un CSS correcto para imprimir las páginas web.

Muchos diseñadores no optimizan las páginas web para impresión, lo que genera confusión al imprimir.

Samuel propone los siguientes consejos para una correcta hoja de estilo para impresión:

Diseño adaptativo para impresión.

Uso de tonos blancos y negros (o colores originales si es necesario).

Incluir las URLs visibles para referencia posterior.

Y aplicar filtros CSS para mejorar los resultados.

En el vídeo de Samuel también se explica que se deben evitar las divisiones en tablas y listas con las siguientes propiedades de CSS: page-break-inside, page-break-before y page-break-after.

En realidad, estas propiedades de CSS están obsoletas y en su lugar se deben emplear las propiedades break-after, break-before y break-inside.

El tema de evitar las divisiones en tablas y listas lo tienes desarrollado con más profundidad en los siguientes vídeos. “CSS: cómo controlar los puntos de corte cuando se imprime una página”, parte 1 y parte 2. Y con esto finaliza este vídeo en el que te he explicado la importancia de los estilos alternativos en las páginas web.

Recuerda que este vídeo forma parte del curso “Introducción al desarrollo web” que está disponible en la dirección idesweb.es.

Muchas gracias por tu atención.

miércoles, 15 de octubre de 2025

ISO/IEC 40500:2025 publicado

 El pasado 24/09/2025 se publicó ISO/IEC 40500:2025 Information technology — W3C Web Content Accessibility Guidelines (WCAG) 2.2 que reemplaza ISO/IEC 40500:2012 Information technology — W3C Web Content Accessibility Guidelines (WCAG) 2.0.

La publicación de WCAG 2.2 como estándar ISO supone un importante respaldo para su implantación, ya que W3C no está reconocido como un organismo estandarizador, pero ISO sí que lo es.

Esperemos que este estándar ISO se convierta en un estándar UNE, con su correspondiente traducción al español, lo que ayudará a su empleo en España y muchos países de Latinoamérica.

Más información:

lunes, 13 de octubre de 2025

CAPTCHA: Análisis de su accesibilidad