Participación en A11yConf 2025 sobre Accesibilidad práctica en SwiftUI

El próximo 29 de noviembre se celebrará una nueva edición de A11yConf, la conferencia de referencia en el mundo hispanohablante dedicada íntegramente a la accesibilidad digital.
El evento reunirá a profesionales del diseño, el desarrollo, la investigación y la comunicación comprometidos con la creación de experiencias digitales inclusivas.
A11yConf es un punto de encuentro fundamental para quienes creemos que la accesibilidad no es un añadido, sino una parte esencial del diseño y desarrollo responsable. Asistir al evento es una oportunidad para aprender de referentes del sector, descubrir nuevas perspectivas y reforzar el compromiso colectivo con la inclusión digital.

Toda la información sobre el programa, los ponentes y las inscripciones están disponible en la web oficial del evento.

Accesibilidad y SwiftUI

En esta edición participaré con una charla práctica sobre la resolución de barreras de accesibilidad en interfaces desarrolladas con SwiftUI. Durante la sesión se mostrarán ejemplos reales y técnicas concretas para la detección y solución de problemas de accesibilidad en aplicaciones para iPhone, iPad, Mac y otros dispositivos del ecosistema Apple.

La ponencia abordará desde los errores más comunes que aparecen en componentes visuales y gestuales hasta estrategias avanzadas para ofrecer una experiencia completa a personas usuarias de VoiceOver, braille y tecnologías de asistencia.

Cómo etiquetar imágenes y componentes visuales en iOS y MacOS con SwiftUI

El desarrollo de interfaces con SwiftUI ofrece muchas ventajas en simplicidad y expresividad, pero también implica una responsabilidad clara: garantizar que todos los componentes sean accesibles. En este sentido, el modificador accessibilityLabel juega un papel fundamental, ya que permite proporcionar descripciones comprensibles para los usuarios que navegan mediante VoiceOver u otros productos de apoyo.

En una aplicación móvil, es habitual encontrar botones representados solo con iconos, imágenes decorativas o gráficos complejos que transmiten información de manera visual. Si estos elementos no cuentan con una etiqueta accesible, el lector de pantalla se limitará a leer su nombre interno por ejemplo, “paperplane.fill” o incluso no los anunciará, lo que genera una experiencia frustrante y excluyente.

El modificador accessibilityLabel resuelve este problema al ofrecer un texto alternativo que describe la función o el significado del elemento. La idea es que, al interactuar con el componente, VoiceOver verbalice la etiqueta definida en lugar del nombre interno o el contenido gráfico.

Ejemplo básico

Un caso típico es un botón con un icono de avión de papel para enviar un mensaje. Visualmente resulta evidente, pero sin una etiqueta accesible el usuario ciego no comprendería su propósito:

Button(action: {
// Acción para enviar
}) {
Image(systemName: "paperplane.fill")
.font(.largeTitle)
}
.accessibilityLabel("Enviar mensaje")

Al añadir .accessibilityLabel(«Enviar mensaje»), VoiceOver anuncia esa frase, y la acción del botón se vuelve comprensible y usable para todas las personas.

Además, no sólo se benefician los usuarios ciegos, también el sistema de Voice control para iOS y MacOS utilizará ese texto para localizar el botón y poderlo pulsar de forma más cómoda para el usuario.

Más allá de los iconos

El uso de accessibilityLabel no se limita a los botones. También puede aplicarse a imágenes que transmiten información importante. Una fotografía, un logotipo o un gráfico que refuerce la identidad de una app debería llevar una etiqueta adecuada.

Image("company_logo")
.resizable()
.frame(width: 120, height: 120)
.accessibilityLabel("Logotipo de la empresa Ejemplo")

En este caso, el lector de pantalla transmitirá la descripción de la imagen en lugar de identificar un elemento inaccesible o verbalizar el nombre del fichero del logotipo de la empresa.

Buenas prácticas

La potencia de accessibilityLabel reside en su sencillez, pero eso no significa que se deba aplicarlo sin reflexión. Es importante tener en cuenta algunas recomendaciones:

  1. Claridad antes que detalle: las etiquetas deben ser breves y concretas. No conviene describir minuciosamente una imagen si con dos palabras es suficiente para transmitir la idea.
  2. Función antes que forma: en un botón, es más importante describir la acción que detallar el icono. Por ejemplo, “Abrir ajustes” comunica más que “Engranaje”.
  3. Evitar redundancias: si un elemento ya tiene un texto visible, añadir un accessibilityLabel idéntico puede resultar repetitivo. En esos casos, lo mejor es dejar que VoiceOver lea directamente el texto.
  4. No etiquetar lo decorativo: si una imagen es meramente estética y no aporta información, lo correcto es marcarla como ignorada con .accessibilityHidden(true).

Etiquetar imágenes y componentes visuales no es un añadido opcional, sino un paso esencial para construir apps accesibles, usables y respetuosas con la diversidad de las personas que las utilizan. El modificador accessibilityLabel es un elemento sencillo y que ayuda a solucionar barreras severas de accesibilidad con un mínimo esfuerzo. Con unas pocas líneas de código, es posible transformar una interfaz visual en una experiencia inclusiva, asegurando que todos los usuarios, independientemente de cómo interactúen con su dispositivo, comprendan y disfruten la aplicación.

SwiftUI en Playgrounds para MacOS

En el artículo anterior se explicó cómo utilizar Playgrounds para MacOS y creamos nuestro primer Playground en el que saludábamos a todo el mundo.

En este artículo seguiremos saludando a todo el mundo pero con SwiftUI.

¿Qué es SwiftUI?

SwiftUI es la nueva librería de Apple para crear interfaces de usuario de forma declarativa. Esto implica que a diferencia de AppKit o UIKit, las librerías anteriores para crear interfaces de usuario para MacOS e iOS, el que sea declarativa facilita muchísimo la creación de estas interfaces.

En SwiftUI todos los elementos visibles se denominan vistas. Ventanas, botones, etiquetas de texto o casillas de verificación son vistas. Estas vistas se codifican como structs en Swift en la que cada struct tiene un cuerpo (body) en el que se declara cómo se verá la vista o qué vistas serán contenidas por esa vista que estamos declarando.

El código

A continuación se muestra el código para nuestro Playground.

import PlaygroundSupport
import SwiftUI

struct ContentView: View {
var body: some View {
Text("¡Hola mundo!")
}
}

PlaygroundPage.current.setLiveView(ContentView())

Lo más importante de este código para Playgrounds es la primera línea, en la que importamos un módulo para realizar operaciones para Playgrounds y la última línea donde indicamos al controlador de páginas de Playground qué vista de SwiftUI queremos mostrar en la pantalla.

El resto del código es SwiftUI estándar.

Conclusión

Con este simple Playground se nos abre la posibilidad de poder empezar a aprender SwiftUI y crear nuestras propias interfaces de usuario.