Cuando hablamos de accesibilidad digital solemos pensar en contraste, navegación mediante teclado, lectores de pantalla o HTML semántico. Todos estos aspectos son importantes, pero una interfaz técnicamente accesible puede seguir siendo difícil de utilizar si sus textos son ambiguos, demasiado técnicos o incompletos.
Aquí es donde entra en juego el microcopy accesible: los textos breves que orientan, informan y acompañan a las personas durante su interacción con una web o aplicación.
Botones, etiquetas, instrucciones, mensajes de ayuda, estados de carga, confirmaciones y textos de error forman parte del microcopy. Aunque ocupen poco espacio, tienen una responsabilidad considerable: explicar qué puede hacerse, qué información se necesita, qué está ocurriendo y cómo continuar.
Practicar un buen UX writing accesible no consiste únicamente en escribir frases cortas. También implica utilizar palabras comprensibles, ofrecer el contexto necesario, anticipar posibles dudas y redactar cada mensaje para que pueda entenderse sin depender exclusivamente de la presentación visual.
Qué es el microcopy accesible
El microcopy accesible es el conjunto de textos breves de una interfaz redactados para que las acciones, instrucciones y resultados sean comprensibles para el mayor número posible de personas.
Su objetivo no es simplificar todos los contenidos hasta eliminar cualquier matiz, sino reducir el esfuerzo necesario para interpretar la interfaz. Una persona debería poder responder con facilidad a estas preguntas:
- ¿Qué puedo hacer en esta pantalla?
- ¿Qué información tengo que introducir?
- ¿Qué ocurrirá cuando active este botón?
- ¿Se ha completado correctamente la acción?
- ¿Qué debo corregir si aparece un error?
Cuando una interfaz no responde con claridad, obliga a deducir, recordar o probar distintas opciones. Esa incertidumbre aumenta la carga cognitiva y puede convertirse en una barrera especialmente importante para personas con dificultades de comprensión, memoria o atención.
La accesibilidad también depende de la comprensión
Una interfaz puede tener controles correctamente etiquetados y continuar ofreciendo una experiencia confusa.
Imaginemos un formulario que muestra el siguiente mensaje:
Error de validación. El parámetro introducido no cumple el formato esperado.
El sistema informa de que existe un problema, pero no explica qué campo debe revisarse ni cómo solucionarlo.
Una alternativa más útil sería:
Introduce el número de teléfono con nueve cifras, sin espacios.
La segunda versión identifica la solución y permite actuar sin necesidad de interpretar terminología técnica.
El microcopy accesible convierte las respuestas internas de un sistema en información comprensible para las personas.
Quién se beneficia de unos textos de interfaz más claros
La redacción accesible puede resultar especialmente importante para personas que:
- utilizan lectores de pantalla o asistentes de voz;
- presentan dislexia o dificultades de comprensión lectora;
- tienen problemas de atención o memoria;
- utilizan la interfaz en un idioma que no dominan completamente;
- cuentan con poca experiencia digital;
- navegan desde una pantalla pequeña;
- se encuentran cansadas, preocupadas o bajo presión;
- necesitan completar una tarea con rapidez.
Estas situaciones muestran que la accesibilidad no beneficia únicamente a un grupo concreto. Cualquier persona puede experimentar una limitación temporal o contextual.
Una interfaz clara reduce errores, facilita la toma de decisiones y genera más confianza.
Cómo escribir botones accesibles
Los botones representan acciones. Por tanto, su texto debería explicar qué ocurrirá cuando se activen.
Etiquetas como «Aceptar», «Continuar», «Enviar» o «Confirmar» pueden funcionar cuando el contexto es muy evidente, pero en muchos casos resultan demasiado genéricas. La persona debe recordar qué estaba aceptando, enviando o confirmando.
Utiliza verbos que describan acciones concretas
Un botón accesible suele comenzar con un verbo y expresar el resultado esperado.
En lugar de utilizar:
- Aceptar.
- Continuar.
- Enviar.
- Confirmar.
- Sí.
Podemos escribir:
- Guardar cambios.
- Continuar al pago.
- Enviar solicitud.
- Confirmar reserva.
- Eliminar archivo.
La segunda opción exige menos interpretación. Además, las etiquetas continúan teniendo sentido cuando se leen fuera del contexto visual de la pantalla.
Este criterio también debe aplicarse a los enlaces. Expresiones como «haz clic aquí» o «más información» pierden sentido cuando una persona navega directamente por la lista de enlaces de una página. En el artículo sobre cómo escribir enlaces accesibles y descriptivos puedes ampliar esta parte del trabajo de redacción.
Evita botones que dependan del texto situado alrededor
Una tarjeta puede incluir un título, una descripción y un botón llamado «Leer más». Visualmente, quizá parezca evidente qué contenido abre. Sin embargo, una persona que utiliza un lector de pantalla puede navegar directamente entre botones o enlaces y escuchar una sucesión como esta:
- Leer más.
- Leer más.
- Leer más.
Sin el contenido circundante, las etiquetas dejan de ser útiles.
Una alternativa sería:
- Leer más sobre accesibilidad web.
- Leer más sobre testing frontend.
- Leer más sobre diseño responsive.
La etiqueta debe conservar su significado aunque se lea de forma aislada.
Mantén la coherencia entre pantallas
Una misma acción no debería cambiar de nombre sin una razón clara.
Si el botón utilizado para conservar la información se llama «Guardar cambios», conviene mantener esa expresión en todo el producto. Alternar entre «Guardar», «Aplicar», «Actualizar» y «Confirmar» puede hacer pensar que cada botón realiza una acción diferente.
La coherencia verbal reduce el esfuerzo de aprendizaje y ayuda a reconocer patrones.
Botones para acciones delicadas
Las acciones que afectan a pagos, publicaciones o eliminación de información necesitan etiquetas especialmente precisas.
Por ejemplo:
- Comprar por 29,90 €.
- Publicar comentario.
- Cancelar suscripción.
- Cerrar sesión.
- Eliminar cuenta definitivamente.
Cuando una acción no puede deshacerse, la interfaz debe indicarlo antes de ejecutarla.
En un cuadro de confirmación para eliminar un documento, es preferible mostrar:
- Cancelar.
- Eliminar documento.
En lugar de:
- No.
- Sí.
Los botones descriptivos evitan que la persona tenga que volver a leer toda la pregunta para recordar qué significa cada respuesta.
Qué ocurre con los botones que solo muestran un icono
Los iconos no siempre tienen un significado universal. Una papelera puede representar eliminar, vaciar o mover a la papelera. Un corazón puede significar guardar, reaccionar o añadir a favoritos.
Cuando un botón contiene únicamente un icono, necesita un nombre accesible que describa su función. Además, cuando el espacio lo permita, combinar icono y texto visible suele mejorar la comprensión.
Algunos ejemplos serían:
- Icono de papelera y texto «Eliminar archivo».
- Icono de flecha y texto «Descargar factura».
- Icono de corazón y texto «Añadir a favoritos».
El nombre accesible debe describir la acción, no el aspecto del símbolo. «Icono de papelera» no explica qué ocurrirá al activar el botón.
Puedes profundizar en esta implementación en la guía sobre iconos sin texto, aria-hidden y nombres accesibles.
Cómo redactar mensajes de ayuda útiles
Los mensajes de ayuda ofrecen información adicional para completar una tarea. Pueden aclarar el formato esperado, explicar por qué se solicita un dato o advertir sobre las consecuencias de una elección.
Una ayuda accesible no debería limitarse a repetir la etiqueta del campo. Debe aportar información que permita actuar correctamente.
Anticipa las condiciones antes de que aparezca el error
Una interfaz no debería esperar a que la persona se equivoque para explicar las reglas.
Si una contraseña necesita ocho caracteres, una mayúscula y un número, estos requisitos deberían mostrarse antes de enviar el formulario:
La contraseña debe incluir al menos ocho caracteres, una mayúscula y un número.
Una ayuda como «La contraseña debe cumplir los requisitos de seguridad» no resulta suficiente porque obliga a descubrir las condiciones mediante ensayo y error.
Las instrucciones preventivas reducen errores y evitan que la persona tenga que repetir una tarea.
Coloca la ayuda junto al elemento correspondiente
El texto debe aparecer cerca del campo o control que explica. Además, la relación no puede ser únicamente visual: también debe existir en el código para que las tecnologías de asistencia puedan anunciar la ayuda en el momento apropiado.
Por ejemplo:
Fecha de nacimiento
Utiliza el formato día, mes y año. Por ejemplo, 18/07/1990.
La indicación explica el formato y ofrece un ejemplo concreto. No obliga a interpretar una abreviatura ni a recordar una convención.
La asociación técnica puede realizarse mediante atributos como aria-describedby, siempre que el contenido y el componente estén correctamente estructurados.
No utilices el placeholder como única etiqueta
El placeholder es el texto temporal que aparece dentro de un campo y desaparece cuando se empieza a escribir. No debería sustituir a una etiqueta visible ni contener instrucciones esenciales.
Depender únicamente de este recurso provoca varios problemas:
- desaparece mientras se introduce la información;
- puede confundirse con una respuesta ya escrita;
- suele presentar un contraste reducido;
- obliga a recordar la indicación;
- no siempre se anuncia de forma consistente.
En lugar de colocar «Correo electrónico» únicamente dentro del campo, conviene utilizar una etiqueta visible y, cuando sea necesario, una ayuda adicional:
Correo electrónico
Utilizaremos esta dirección para enviarte la confirmación del pedido.
En la guía sobre formularios accesibles, etiquetas y validaciones encontrarás ejemplos técnicos para asociar correctamente etiquetas, campos y mensajes.
Explica por qué solicitas determinados datos
Cuando un formulario pide información personal, una explicación breve puede aumentar la confianza.
Por ejemplo:
Utilizaremos tu teléfono únicamente para avisarte de cambios en la entrega.
La persona entiende por qué se solicita el dato y puede tomar una decisión informada.
No es necesario añadir explicaciones extensas debajo de cada campo. La ayuda debe aparecer cuando resuelva una duda real o evite una posible preocupación.
Qué información debe permanecer visible
La información imprescindible para completar una tarea debe estar disponible desde el principio. Los iconos de interrogación, acordeones y textos desplegables pueden utilizarse para ampliar detalles, pero no deberían ocultar condiciones obligatorias.
Como regla general:
- la información esencial debe permanecer visible;
- la información complementaria puede desplegarse;
- las explicaciones extensas pueden enlazar a una página específica.
Cómo redactar textos de error accesibles
Los mensajes de error aparecen cuando la persona ya se ha encontrado con un obstáculo. Por ello, deben ayudar a resolverlo, no limitarse a informar de que algo ha fallado.
Un texto de error útil responde a tres cuestiones:
- Qué ha ocurrido.
- Dónde está el problema.
- Cómo puede solucionarse.
Identifica el problema de forma precisa
Mensajes como «Algo ha salido mal», «Datos incorrectos» o «Error de validación» ofrecen muy poca información.
Una alternativa más útil sería:
No hemos podido guardar los cambios porque se ha perdido la conexión. Comprueba tu conexión a internet e inténtalo de nuevo.
El mensaje explica el problema probable y propone una acción.
Cuando el sistema no conoce la causa exacta, no debería inventarla. Puede comunicar únicamente la información confirmada:
No hemos podido completar el pago. No se ha realizado ningún cargo. Inténtalo de nuevo o utiliza otro método de pago.
Esta redacción informa del fallo, aclara una consecuencia importante y ofrece alternativas.
Señala qué campo necesita atención
En un formulario extenso, un aviso genérico situado al principio de la página no es suficiente. La persona puede saber que existen errores, pero no dónde encontrarlos.
Lo recomendable es combinar:
- un resumen inicial;
- un mensaje junto a cada campo afectado;
- una señal visual que no dependa solo del color;
- una asociación técnica entre el campo y el error.
Por ejemplo:
Revisa los dos campos indicados antes de continuar.
Junto al campo de correo electrónico:
Introduce una dirección válida, como nombre@ejemplo.com.
Evita culpar a la persona
Los mensajes deberían centrarse en el problema, no en juzgar a quien utiliza la interfaz.
En lugar de escribir:
Has introducido mal la contraseña.
Podemos utilizar:
La contraseña no coincide. Inténtalo de nuevo.
Otros ejemplos adecuados serían:
- Falta completar el campo «Código postal».
- El archivo supera el tamaño máximo de 10 MB.
- La fecha debe ser posterior al 20 de julio de 2026.
- El código ha caducado. Solicita uno nuevo.
El tono puede ser cercano, pero debe mantener la claridad y el respeto.
No dependas únicamente del color rojo
El color puede reforzar el estado de error, pero no debería ser su único indicador. Algunas personas no distinguen determinados colores y otras acceden al contenido mediante una presentación no visual.
Además del cambio cromático, pueden utilizarse:
- la palabra «Error»;
- un icono acompañado de texto;
- un borde con una característica diferenciada;
- un resumen de errores;
- un mensaje descriptivo.
Por ejemplo:
Error: introduce una fecha posterior al 20 de julio de 2026.
El mensaje continúa siendo comprensible aunque el color no pueda percibirse.
Anuncia correctamente los errores dinámicos
En muchas aplicaciones, los errores aparecen sin recargar la página. Insertar visualmente un mensaje no garantiza que un lector de pantalla vaya a detectarlo.
Los cambios importantes deben anunciarse mediante una implementación adecuada, utilizando recursos como aria-live, role="alert" o role="status" según la prioridad y el tipo de mensaje.
El texto también debe poder entenderse al escucharse de forma independiente:
El código introducido ha caducado. Solicita un código nuevo.
Es mucho más informativo que anunciar únicamente:
No válido.
Para profundizar en los avisos dinámicos, puedes consultar la guía sobre toasts y notificaciones accesibles con aria-live.
Conserva la información que ya era correcta
Una buena experiencia de error no depende solo del mensaje. Si el formulario elimina todos los datos debido a un único campo incorrecto, la persona tendrá que repetir un trabajo que ya había completado.
Siempre que sea seguro, la interfaz debería conservar las respuestas válidas, identificar únicamente los campos problemáticos y situar el foco en una posición lógica.
Principios generales de UX writing accesible
Botones, ayudas y errores cumplen funciones diferentes, pero todos deberían seguir unos principios comunes.
Utiliza lenguaje directo
Las frases breves y directas suelen comprenderse mejor que las construcciones administrativas o excesivamente técnicas.
En lugar de:
Para proceder a la finalización del proceso de registro será necesaria la validación previa de la dirección de correo electrónico proporcionada.
Podemos escribir:
Revisa tu correo y confirma la dirección para completar el registro.
La segunda versión conserva la información y reduce el esfuerzo de lectura.
Coloca la información importante al principio
Las personas no siempre leen una interfaz palabra por palabra. Con frecuencia, escanean el contenido para localizar la información relevante.
Por eso conviene comenzar por el resultado principal:
Pago rechazado. Utiliza otra tarjeta o consulta con tu banco.
Es preferible a una frase larga que revele el problema al final.
Sustituye la terminología interna
Los códigos y términos utilizados por el equipo técnico no deberían aparecer como explicación principal.
Es preferible utilizar:
- Número de pedido en lugar de ID de transacción.
- Dirección de entrega en lugar de domicilio de expedición.
- Guardar borrador en lugar de persistir contenido.
- Página no encontrada en lugar de error HTTP 404.
El código técnico puede mostrarse como información secundaria cuando sea útil para soporte, pero no debe sustituir a la explicación.
Evita instrucciones basadas en la posición
Indicaciones como «pulsa el botón de la derecha», «selecciona la opción inferior» o «revisa los campos en rojo» dependen de la presentación visual.
La disposición puede cambiar en móvil, al ampliar el contenido o al navegar con tecnologías de asistencia.
Es preferible nombrar directamente el elemento:
- Selecciona «Guardar cambios».
- Revisa el campo «Correo electrónico».
- Abre la sección «Datos de facturación».
No utilices el humor para ocultar información
Un tono cercano puede formar parte de la identidad de una marca, pero el humor debe utilizarse con prudencia en situaciones relacionadas con pagos, privacidad, pérdida de información o errores.
Un mensaje como «¡Vaya, la hemos liado!» puede resultar simpático, pero no explica qué ha ocurrido.
Una alternativa con personalidad y utilidad sería:
No hemos podido publicar el artículo. El borrador está guardado, así que puedes intentarlo de nuevo.
La voz de marca puede acompañar al mensaje, pero nunca reemplazar la información necesaria.
Cómo revisar el microcopy antes de publicar
La revisión de los textos debería realizarse dentro del flujo completo. Una etiqueta que parece clara en una hoja de cálculo puede perder sentido cuando aparece junto a otras acciones.
Recorre las tareas principales
Prueba los procesos más importantes de la interfaz:
- crear una cuenta;
- iniciar sesión;
- recuperar una contraseña;
- completar un formulario;
- realizar una compra;
- guardar o eliminar información;
- cancelar una operación;
- introducir datos incorrectos;
- utilizar la aplicación sin conexión.
Durante la revisión, comprueba si cada pantalla explica qué está ocurriendo y qué opciones existen.
Lee botones y enlaces fuera de contexto
Extrae una lista con todas las etiquetas interactivas e intenta comprenderlas sin observar el diseño.
Si aparecen muchas expresiones como «Más», «Aceptar», «Continuar» o «Aquí», probablemente necesiten una revisión.
Esta prueba se aproxima a la experiencia de una persona que utiliza un lector de pantalla para navegar directamente entre controles.
Provoca errores deliberadamente
Los estados de error suelen recibir menos atención que el recorrido ideal. Para comprobarlos, introduce:
- campos vacíos;
- formatos incorrectos;
- contraseñas que no coinciden;
- archivos demasiado grandes;
- fechas no permitidas;
- datos duplicados;
- códigos caducados.
Cada error debería identificar el problema y ofrecer una solución posible.
Comprueba la experiencia con teclado
El texto de un botón puede ser claro, pero la experiencia seguirá siendo inaccesible si el control no puede alcanzarse o si el foco no resulta visible.
Conviene completar los principales recorridos utilizando únicamente Tab, Mayús + Tab, Enter, barra espaciadora y Escape. La guía sobre foco visible y navegación por teclado puede ayudarte a revisar esta parte de la interacción.
Crea una guía de estilo para los textos de interfaz
Una guía breve facilita la coherencia y evita resolver los mismos problemas en cada pantalla.
Puede definir:
- tono de voz;
- tratamiento de tú o usted;
- terminología preferida;
- verbos utilizados en botones;
- estructura de errores y confirmaciones;
- criterios de mayúsculas y puntuación;
- formato de fechas, horas y cantidades;
- expresiones que deben evitarse;
- requisitos básicos de accesibilidad.
Checklist de microcopy accesible
Antes de aprobar un texto, comprueba:
- ¿Describe claramente la acción o el estado?
- ¿Se entiende sin depender del diseño?
- ¿Utiliza palabras familiares para la audiencia?
- ¿Explica cómo solucionar el problema?
- ¿Evita culpar a la persona?
- ¿Mantiene la terminología utilizada en otras pantallas?
- ¿La información esencial aparece antes de realizar la acción?
- ¿El texto visible coincide con el nombre accesible?
- ¿Se entiende al escucharlo fuera de contexto?
- ¿Puede simplificarse sin perder información?
Preguntas frecuentes sobre microcopy accesible
¿Cuál es la diferencia entre microcopy y UX writing?
El microcopy está formado por los textos breves que aparecen dentro de una interfaz: botones, etiquetas, mensajes de ayuda, errores y confirmaciones.
El UX writing es una disciplina más amplia que planifica y redacta el contenido necesario para guiar a las personas a lo largo de toda la experiencia digital. El microcopy es, por tanto, una parte del UX writing.
Cuando hablamos de UX writing accesible, incorporamos criterios de comprensión, inclusión, coherencia y compatibilidad con tecnologías de asistencia.
¿Un botón con un icono necesita texto?
Necesita, como mínimo, un nombre accesible que identifique su función. El icono puede acompañarse de texto visible o disponer de una etiqueta accesible para lectores de pantalla.
Siempre que el espacio y el diseño lo permitan, combinar icono y texto suele ser más comprensible. La etiqueta debe describir la acción, como «Descargar factura», y no la apariencia del símbolo.
¿Cómo debe redactarse un buen mensaje de error?
Un buen texto de error debe indicar qué ha ocurrido, dónde se encuentra el problema y cómo solucionarlo.
También debería utilizar un tono neutral, evitar tecnicismos innecesarios y conservar los datos que ya eran correctos.
Por ejemplo:
El código postal debe contener cinco cifras. Revisa el campo «Código postal» e inténtalo de nuevo.
Este mensaje resulta mucho más útil que una expresión genérica como «Datos no válidos».
Las palabras también pueden eliminar barreras
La accesibilidad digital no termina cuando una interfaz puede recorrerse con el teclado o cuando sus componentes incluyen los atributos técnicos adecuados.
Una experiencia solo es verdaderamente accesible cuando las personas pueden comprender qué deben hacer, reconocer qué está ocurriendo y recuperarse cuando aparece un problema.
Los botones deben describir acciones. Los mensajes de ayuda tienen que anticipar dudas. Los textos de error deben ofrecer una salida, no limitarse a señalar un fallo.
Escribir microcopy accesible requiere precisión, empatía y colaboración entre diseño, contenido y desarrollo. También exige probar los textos en situaciones reales, escuchar cómo se anuncian mediante tecnologías de asistencia y observar si las instrucciones se entienden sin ayuda externa.
Una sola palabra ambigua puede impedir una compra, bloquear un formulario o provocar la pérdida de confianza. Del mismo modo, una indicación clara puede evitar un error y permitir que alguien complete una tarea con autonomía.
Cada texto de interfaz es una oportunidad para eliminar una barrera. Cuando redactamos pensando en diferentes capacidades, experiencias y contextos, no solo mejoramos la accesibilidad: creamos productos más comprensibles, seguros y humanos.