Categoría: Accesibilidad

Artículos sobre accesibilidad y diseño para todos

Eliminar todas las descargas de iCloud drive en MacOS

Publicado el

El servicio de almacenamiento en la nube incluido en los dispositivos de Apple, más conocido como iCloud drive, ofrece una completa integración en todo el entorno Apple. Incluso permite el acceso desde la Web.

Cuando se activa iCloud Drive en macOS, el sistema puede conservar una copia local de los archivos para un acceso más rápido, o dejar solo un enlace a ese archivo y mantener el contenido real en la nube para ahorrar espacio.
En ocasiones podemos querer forzar que macOS elimine las copias descargadas en el disco sin borrar nada de iCloud para recuperar espacio en nuestro Mac.

Podemos abrir la carpeta de iCloud en el Finder e ir uno a uno por cada archivo, abrir el menú contextual y activar la opción eliminar descarga. Pero esta tarea se puede complicar si tenemos multitud de carpetas y sub carpetas y miles de archivos almacenados en iCloud.

La Terminal al rescate

Desde la Terminal de MacOS podemos realizar operaciones complejas que no tienen forma de ser realizadas desde la interfaz gráfica de MacOS.

Si abrimos la Terminal de MacOS y ejecutamos el siguiente comando se realizará esa limpieza de todos los archivos de iCloud de nuestro equipo:

brctl evict ~/Library/Mobile\ Documents/com~apple~CloudDocs

Comando brctl

brctl (abreviatura de bird control) es una utilidad incluida en macOS que permite interactuar con los servicios de iCloud a bajo nivel.

El subcomando evict solicita al servicio que “evacúe” (evict) las copias locales de los archivos indicados: el archivo local se sustituye por un marcador que representa el ítem en iCloud, y el contenido real queda solo en la nube.

Desde el punto de vista del usuario, el archivo sigue apareciendo en Finder, pero macOS no mantiene su contenido en disco; si se abre de nuevo, el sistema lo descargará cuando sea necesario.

Aún más fácil con AppleScript

Puede que abrir la Terminal no sea del agrado de todos los usuarios por su aparente complejidad. Para evitar esto podemos crear un AppleScript con el siguiente contenido:

on run
    set icloudPath to POSIX path of (path to library folder from user domain) & "Mobile Documents/com~apple~CloudDocs"
    set command to "brctl evict " & quoted form of icloudPath
    do shell script command
end run

Ejecutando este AppleScript evitaremos usar la Terminal. Además, lo podemos convertir en una aplicación para crear automatizaciones.

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

Publicado el

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.

Mantenimiento para MacOS con Onyx

Publicado el

Cuando hablamos de macOS, a menudo se escucha decir que “no necesita mantenimiento”, que el sistema se cuida solo. En cierta medida, eso es cierto: Apple ha diseñado macOS con mecanismos internos de mantenimiento. Pero como cualquier sistema complejo, con el tiempo pueden acumularse residuos (cachés corruptas, índices desalineados, archivos temporales huérfanos) que afectan al rendimiento, la estabilidad o simplemente a la fluidez del equipo.

Realizar el mantenimiento del sistema sin ninguna herramienta de apoyo es posible pero esta tarea comprende multitud de mini tareas y requiere de bastante conocimiento de la Terminal de MacOS. Por esta razón existen herramientas como Onyx.

¿Qué es Onyx?

OnyX es una utilidad multifunción para macOS que permite verificar la estructura del volumen de arranque, realizar tareas de mantenimiento, limpiar cachés de sistema/aplicaciones, reconstruir índices o bases de datos, configurar parámetros ocultos del sistema, eliminar archivos problemáticos y mucho más.

La aplicación Onyx se distribuye como  software “donationware”: es gratuita para su uso, pero el desarrollador acepta donaciones para su mantenimiento.

OnyX pone a disposición del usuario muchas de las funciones internas de mantenimiento y optimización de macOS, agrupándolas en una interfaz gráfica simple y accesible.

Procesos que Onyx puede realizar

Al abrir OnyX, lo primero que hace es verificar la estructura del volumen de arranque (filesystem). Si hay inconsistencias, las reporta. Esta verificación puede tomar tiempo por lo que puede ser interesante realizarla de forma manual.

Otra recomendación es la de cerrar el resto de aplicaciones para que Onyx pueda realizar todas sus tareas sin ningún tipo de bloqueo del sistema.

La aplicación organiza sus funciones en varias pestañas o secciones.

En la pestaña de mantenimiento se encuentran tareas como ejecutar scripts periódicos (diarios, semanales, mensuales), reconstruir servicios, reparar permisos (en versiones antiguas), limpiar logs del sistema, etc. Es recomendable ejecutar estas tareas de mantenimiento una vez al mes.

En la pestaña herramientas podemos encontrar Acceso a funciones ocultas del sistema como ver apps o servicios que normalmente están escondidos, activar o desactivar elementos del Dock, del Finder, diagnósticos de red, funciones adicionales del sistema o programar tareas como el apagado automático, tareas de mantenimiento o ejecuciones de servicios.

La pestaña archivos ofrece procesos para el borrado definitivo de ficheros, limpieza de papeleras, desinstalación limpia de aplicaciones y paquetes así como modificar la visibilidad de ficheros o verificar su integridad.

La pestaña de seguridad permite gestionar los servicios de seguridad del sistema como el firewall de MacOS, FileVault o Gatekeeper.

El resto de pestañas, como búsqueda, información y parámetros, permiten ajustar o utilizar herramientas del propio sistema operativo pero en una interfaz más amigable que la Terminal.

Precaución con el uso de Onyx
Es una herramienta muy potente que nos permite ajustar nuestro hardware a parámetros muy específicos. Esto permite la aparición de cambios en el comportamiento de servicios y aplicaciones instaladas por lo que es muy recomendable documentarse antes de cambiar un parámetro o ajuste de Onyx en las tareas de mantenimiento y hacer un backUp del sistema si vamos a utilizar una herramienta de Onyx sin conocer los efectos secundarios.

Problemas con la actualización de Onyx

Cada versión de Onyx está optimizada para una versión específica de MacOS. Es habitual que tras una actualización de MacOS Onyx deje de funcionar o no permita auto actualizarse. Para evitar este problema es recomendable que, sin desinstalar Onyx de nuestro equipo, bajemos de nuevo el paquete de instalación de Onyx y la volvamos a reinstalar sobreescribiendo la versión anterior y sin borrar nada. Debemos asegurarnos de bajar la versión correcta para nuestra versión de MacOS.

Es obligatorio que, siempre, bajemos el instalador de Onyx de su sitio oficial. De esta forma evitaremos posible Malware o fraudes.

Código de programación más accesible con SIMAE

Publicado el

En el mundo de las tecnologías de apoyo para personas con discapacidad visual, pocas iniciativas resultan tan innovadoras y útiles como SIMAE, el Sistema de Marcado Estructural de Código Fuente para Programadores con Discapacidad Visual. Desarrollado en la UTN Facultad Regional Santa Fe, este proyecto de I+D está pensado para brindar contexto y estructura al código, aumentando la accesibilidad para quienes dependen de lectores de pantalla.

SIMAE nace en 2016, cuando un alumno ciego ingresó en Ingeniería en Sistemas. La necesidad de facilitar su experiencia de aprendizaje motivó a docentes e investigadores a diseñar una herramienta que transformara la forma de programar en algo más accesible.

Su función principal es insertar información contextual en el código fuente, para ello incorpora información extra en la semántica del código. Por ejemplo, se agregan marcadores para señalar el comienzo y fin de bloques buscando ayudar a ubicarse al programador dentro del código; una extensión para VSCode que permite detectar las marcas semánticas en los hints del código y utilizar atajos de teclado especiales para moverse por la estructura del código.

Soporta múltiples lenguajes (C++, Java, Python y también C#) y funciona en español e inglés.

Este proyecto demuestra que las tiflotecnologías pueden elevar significativamente la experiencia de programación para personas con discapacidad visual. Al convertir el código en algo estructurado y navegable no solo visible, la herramienta abre caminos hacia una programación más autónoma, inclusiva y eficiente. Su enfoque dual (standalone y extensión) ofrece flexibilidad según el entorno de trabajo del usuario.

Cómo etiquetar imágenes y componentes visuales en Android con Content Description

Publicado el

En el desarrollo de aplicaciones para Android, la accesibilidad es un aspecto que no puede dejarse de lado. Uno de los errores más comunes en las interfaces de aplicaciones móviles es utilizar iconos o imágenes sin acompañarlos de una descripción accesible. Para los usuarios que dependen de TalkBack u otros lectores de pantalla, estos elementos pueden convertirse en barreras de accesibilidad muy severas si no cuentan con la información adecuada para identificar la funcionalidad de dichos botones o elementos visuales.

La propiedad contentDescription permite añadir una etiqueta textual a cualquier componente visual, de forma que TalkBack la anuncie en lugar de limitarse a leer un nombre técnico como “ic_send” o a ignorar la imagen por completo.

Ejemplo básico en XML

Un caso clásico es un botón con un icono de avión de papel que representa la acción de enviar un mensaje. Visualmente resulta evidente, pero sin descripción accesible no es comprensible para quien no puede ver la pantalla:

<ImageButton
  android:id="@+id/sendButton"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:src="@drawable/ic_send"
  android:contentDescription="Enviar mensaje" 
/>

En este ejemplo, TalkBack leerá “Enviar mensaje” al situarse sobre el botón, en lugar de un nombre de archivo técnico.

Ejemplo con Jetpack Compose

En Compose, la accesibilidad se maneja mediante modificadores de semántica. El equivalente a contentDescription sería:

IconButton(
  onClick = { /* Acción para enviar */ },
  modifier = Modifier.semantics { contentDescription = "Enviar mensaje" }
) {
  Icon(
    imageVector = Icons.Default.Send,
    contentDescription = null // Evitamos redundancia
  )
}

En este ejemplo el botón anuncia la etiqueta “Enviar mensaje” al interactuar con TalkBack. El icono interno no necesita contentDescription porque ya se ha definido en el contenedor.

Buenas prácticas

La propiedad contentDescription es sencilla de usar, pero conviene aplicarla con criterio:

  1. Priorizar la función: un icono de engranaje para un botón para ir a los ajustes de la app no debería describirse como “rueda dentada”, sino como “Ajustes”, que es la acción real.
  2. Ser breve y claro: descripciones cortas facilitan la navegación. Un botón que abre un chat debe decir “Abrir chat”, no “Icono de burbuja de diálogo para iniciar conversación”.
  3. Evitar redundancias: si un TextView ya tiene texto visible, no es necesario repetirlo en contentDescription. TalkBack lo leerá automáticamente.
  4. Ocultar lo decorativo: para imágenes que solo son decorativas, se debe establecer android:contentDescription=»@null» en XML o contentDescription = null en Compose. De esta forma TalkBack las ignora.

Etiquetar adecuadamente los componentes visuales no solo es una buena práctica de desarrollo, sino un compromiso con la inclusión digital. Al igual que ocurre con cualquier aspecto del diseño, dedicar unos segundos a escribir una descripción accesible marca la diferencia entre una app usable y otra que excluye a parte de sus usuarios. La propiedad contentDescription es una de las herramientas más simples y a la vez más poderosas que Android pone en manos de los desarrolladores para mejorar la accesibilidad. Añadir una descripción clara y precisa a imágenes e iconos garantiza que los usuarios con lectores de pantalla comprendan e interactúen con la interfaz en igualdad de condiciones.

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

Publicado el

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.