Categoría: Metodología y filosofía

Artículos, pensamientos y experiencias vitales

Los Cuatro Principios de WCAG

Publicado el

La accesibilidad web es un componente fundamental del desarrollo de software inclusivo. Para garantizar que todas las personas, incluidas las personas con discapacidad, puedan acceder y usar los sitios web de manera efectiva, se han desarrollado estándares como las Pautas de Accesibilidad para el Contenido Web (WCAG, por sus siglas en inglés).

Estas pautas están organizadas en torno a cuatro principios fundamentales: Perceptible, Operable, Comprensible y Robusto.

Perceptible: Hacer el contenido visible y comprensible para todos

El principio de perceptibilidad establece que la información y los componentes de la interfaz de usuario deben ser presentados de manera que todos los usuarios puedan percibirlos, independientemente de sus capacidades sensoriales.

Muchas personas con discapacidad dependen de tecnologías de asistencia, como lectores de pantalla, para acceder a la web. Sin alternativas textuales o contenido adaptable, podrían perder información crítica.

¿Qué implica este principio?

El contenido visual debe ser accesible para personas con discapacidad visual parcial o total.
El contenido auditivo debe ser accesible para personas con discapacidad auditiva.
La información no debe depender exclusivamente de un solo sentido (por ejemplo, solo de la vista o del oído).

Pautas clave para este principio

Las WCAG establecen varias pautas para cumplir este principio:

Alternativas textuales: Todo contenido no textual, como imágenes, botones y gráficos, debe tener descripciones en texto que transmitan la misma información o funcionalidad.
Contenido adaptable: La presentación del contenido no debe depender exclusivamente de un diseño fijo y debe poder adaptarse a diferentes configuraciones.
Distinguibilidad: Los usuarios deben poder ver y oír el contenido claramente, evitando combinaciones de colores con un bajo nivel de contraste y asegurando que el texto sea legible.

Operable: Garantizar que los usuarios puedan interactuar con la interfaz

El principio de operabilidad se centra en que los usuarios puedan navegar, interactuar y utilizar todas las funciones de un sitio web sin barreras.

Las personas con discapacidad motora pueden ser incapaces de usar un ratón, por lo que necesitan opciones alternativas de navegación. Además, un diseño operable mejora la experiencia para todas las personas, incluyendo aquellas con limitaciones temporales o dispositivos distintos (como móviles o tabletas).

¿Qué implica este principio?

Los usuarios deben poder navegar por el contenido mediante distintos métodos de entrada (teclado, voz, dispositivos de asistencia, etc.).
La interfaz debe evitar elementos que provoquen convulsiones o reacciones adversas.
Se debe proporcionar suficiente tiempo para completar tareas sin restricciones de tiempo o de capacidades físicas o sensoriales.

Pautas clave para este principio

Las WCAG incluyen las siguientes pautas:

Accesible desde el teclado: Todos los elementos interactivos deben ser operables sin necesidad de un ratón.
Tiempo suficiente: Se debe permitir a los usuarios extender o eliminar los límites de tiempo para completar tareas.
Evitar contenido que cause convulsiones: No debe haber destellos ni parpadeos excesivos.
Navegabilidad mejorada: Se deben proporcionar mecanismos de navegación clara y estructura lógica en la página.

Comprensible: Asegurar que el contenido sea claro y predecible

El principio de comprensibilidad establece que la información y el manejo de la interfaz deben ser fáciles de entender para todos los usuarios.

Las personas con discapacidad cognitiva o dificultades de aprendizaje pueden tener problemas para comprender textos complejos o instrucciones ambiguas. Además, una interfaz clara y predecible beneficia a todas las personas, reduciendo la fricción en la experiencia de navegación.

¿Qué implica este principio?

El lenguaje debe ser claro y conciso.
La navegación y el diseño de la interfaz deben seguir patrones predecibles.
Se deben proporcionar ayudas cuando sea necesario (como sugerencias en formularios).

Pautas clave para este principio

Las WCAG proponen:

Lenguaje legible y comprensible: Se recomienda usar un lenguaje claro, evitar jerga técnica y proporcionar definiciones cuando sea necesario.
Previsibilidad: Los elementos interactivos deben comportarse de manera consistente en todas las páginas.
Asistencia para la entrada de datos: Se deben incluir etiquetas claras, instrucciones y mensajes de error comprensibles.

Robusto: Asegurar la compatibilidad con diferentes tecnologías y futuros desarrollos

El principio de robustez se refiere a la necesidad de que el contenido web sea compatible con una amplia variedad de tecnologías actuales y futuras.

Las herramientas de asistencia dependen de estándares bien definidos para acceder al contenido web. Si un sitio web usa código incorrecto o elementos no estándar, puede volverse inaccesible para algunas personas que utilicen estas herramientas de asistencia. Además, la robustez permite que el contenido siga siendo accesible a medida que las tecnologías evolucionan.

¿Qué implica este principio?

El contenido debe poder interpretarse correctamente en distintos navegadores, dispositivos y tecnologías de asistencia.
El código debe seguir estándares accesibles y ser semánticamente correcto.

Pautas clave para este principio

Las WCAG incluyen:

Compatibilidad con tecnologías de asistencia: Se deben utilizar estándares accesibles y etiquetas semánticas adecuadas (como el uso correcto de HTML y ARIA).
Uso correcto del marcado: El código debe estar bien estructurado para evitar errores de interpretación.

Qué es WCAG(Web Content Accessibility Guidelines)

Publicado el

La accesibilidad en la Web es un aspecto esencial para garantizar que todas las personas, independientemente de sus habilidades o necesidades especiales, puedan participar en la sociedad de la información. Para promover esta inclusividad, nacieron las WCAG, o Pautas de Accesibilidad para el Contenido Web (Web Content Accessibility Guidelines).
WCAG es un conjunto de pautas internacionales diseñadas para mejorar la accesibilidad web. Estas pautas proporcionan recomendaciones para que sitios web, aplicaciones y contenidos digitales sean accesibles a personas con discapacidad.
WCAG fue desarrollada por el World Wide Web Consortium (W3C), una organización internacional que trabaja en la estandarización de las tecnologías para la Web.
Dentro del W3C, el Web Accessibility Initiative (WAI) lidera los esfuerzos relacionados con la accesibilidad web.
Los perfiles de discapacidad incluidos en WCAG son la discapacidad visual, auditiva, motriz y cognitiva.
Las WCAG son ampliamente utilizadas por desarrolladores, diseñadores, empresas y gobiernos para garantizar que sus plataformas digitales sean inclusivas. También sirven como referencia para cumplir con legislaciones y normativas de accesibilidad en varios países.

Objetivo de las WCAG

El objetivo principal de las WCAG es garantizar que la web sea accesible para todos.

La inclusión digital no solo es un derecho humano fundamental, sino que también beneficia a las empresas y a la sociedad en general. Los sitios web accesibles pueden llegar a una audiencia más amplia, mejorar el SEO y reducir riesgos legales.
Además, las WCAG ofrecen una guía clara y estructurada para abordar las barreras más comunes en la web, asegurando que los desarrolladores y diseñadores puedan crear experiencias más igualitarias para todas las personas.

En los años 90, cuando internet comenzó a masificarse, se hizo evidente que las tecnologías digitales podían ser una barrera significativa para las personas con discapacidad.
Por ello, en 1999 se publicó la primera versión de WCAG (WCAG 1.0). Desde entonces, ha evolucionado para reflejar los cambios en las tecnologías y las necesidades de los usuarios, con WCAG 2.1 como la versión actual y que se utiliza como referencia para leyes y normativas para la accesibilidad digital.

Estructura de las WCAG

Las WCAG están organizadas en torno a cuatro principios fundamentales, conocidos como los principios POUR: perceptible, operable, comprensible y robusto.

Principios

Estos son los cuatro principios de WCAG:
• Perceptible: La información y los componentes de la interfaz de usuario deben ser presentados de forma que los usuarios puedan percibirlos. Por ejemplo, ofrecer alternativas textuales para contenido visual o auditivo.
• Operable: Los usuarios deben poder navegar y usar los elementos de la interfaz. Esto incluye garantizar que se pueda interactuar con el contenido utilizando un teclado y ofrecer suficiente tiempo para leer e interactuar con el contenido.
• Comprensible: La información y el funcionamiento de la interfaz deben ser comprensibles. Por ejemplo, utilizar un lenguaje claro y proporcionar ayuda para la corrección de errores.
• Robusto: El contenido debe ser suficientemente robusto para ser interpretado de manera confiable por diferentes herramientas, incluidas las herramientas de asistencia como lectores de pantalla o sistemas de control por voz.

Pautas en las WCAG

Cada uno de los principios POUR incluye una serie de pautas que tratan aspectos específicos de accesibilidad.

Cada pauta proporciona orientación concreta mediante técnicas y ejemplos que permiten a los desarrolladores implementar accesibilidad de manera efectiva evitando la creación de barreras de accesibilidad.

Criterios de éxito

Dentro de cada pauta hay varios criterios de éxito relacionados con esa pauta.

Los criterios de éxito son los estándares medibles que determinan si un sitio o aplicación cumple con las pautas. Estos criterios se dividen en tres niveles de conformidad.

Un ejemplo específico de criterio de éxito es el requisito de que todo contenido de video tenga subtítulos sincronizados (Nivel A) o que los mecanismos  de navegación deben ser consistentes en todas las páginas de un sitio web (Nivel AA).
Los criterios de éxito están diseñados para ser verificables mediante pruebas automáticas o evaluaciones manuales, facilitando el proceso de validación de accesibilidad.

Niveles de conformidad

Estos son los tres niveles de conformidad de los criterios de éxito en las WCAG:
• Nivel A: El mínimo indispensable para la accesibilidad simple. Este nivel es insuficiente en la mayoría de marcos legales del mundo.
• Nivel AA: Un nivel de accesibilidad recomendado y generalmente aceptado como suficiente en la mayoría de marcos legales en el mundo.
• Nivel AAA: El nivel más alto de accesibilidad, alcanzable en contextos específicos.

La importancia de conocer la ley para defender los derechos de las personas con discapacidad

Publicado el

En europa existen normativas y tratados internacionales diseñados para garantizar la igualdad y la inclusión de las personas con discapacidad. Sin embargo, estas herramientas legales son poco efectivas si no se conocen y aplican de manera adecuada.
A pesar de los avances legislativos, la discriminación sigue siendo una barrera cotidiana. Situaciones como la falta de accesibilidad en espacios públicos, la negación de empleo por discapacidad, o el acceso limitado a información en formatos accesibles son ejemplos comunes de vulneración de derechos. Estos actos no solo representan injusticias individuales, sino que perpetúan estructuras de exclusión social.
Según datos recientes, un alto porcentaje de delitos de odio en España están relacionados con la discapacidad. Estos incluyen desde agresiones físicas hasta formas más sutiles de violencia, como el discurso de odio. El impacto emocional y psicológico en las víctimas es grave, resaltando la necesidad de un sistema de apoyo sólido y de acceso efectivo a la justicia.

Herramientas legales para defender nuestros derechos

Dentro del conjunto de normativas y leyes para defender los derechos de las personas con discapacidad encontramos:

• La Convención sobre los Derechos de las Personas con Discapacidad: Este tratado internacional, ratificado por España, es un pilar fundamental en la defensa de derechos. Garantiza igualdad de condiciones, accesibilidad universal, y la autonomía personal de las personas con discapacidad. 

• La Ley General de Derechos de las Personas con Discapacidad y de su Inclusión Social: Esta ley consolida normativas previas, promoviendo la igualdad de oportunidades y sancionando la discriminación en ámbitos como el empleo, la educación y el acceso a servicios básicos.

• La Constitución Española: En su artículo 49, establece que los poderes públicos deben garantizar la plena integración de las personas con discapacidad.

La autodefensa: un acto de empoderamiento

La autodefensa implica conocer los derechos y actuar para protegerlos. Es crucial que las personas con discapacidad desarrollen habilidades para identificar actos discriminatorios y sepan cómo denunciarlos. Existen dos vías principales para interponer reclamaciones:
• Reclamos administrativos: Recursos gratuitos en los que la persona puede presentar su caso directamente ante las autoridades competentes.
• Acción judicial: En caso de discriminación grave, se puede acudir a los tribunales. En estas situaciones, es fundamental contar con asistencia jurídica, la cual puede ser gratuita para quienes cumplen ciertos criterios económicos o sociales.

Además, herramientas como el servicio de orientación jurídica del CERMI pueden ayudar a simplificar el proceso de denuncia.

Más allá de la ley

El conocimiento de la ley debe ir acompañado de un cambio cultural. La difusión en redes sociales, las campañas de incidencia política, y la formación de alianzas con organizaciones de derechos humanos son estrategias complementarias para promover una sociedad más inclusiva. Estas acciones no solo empoderan a las personas con discapacidad, sino que también sensibilizan al resto de la sociedad sobre la importancia de la igualdad.

Conocer y aplicar la ley es una herramienta esencial para las personas con discapacidad. Sin embargo, el verdadero cambio requiere un esfuerzo colectivo que combine la aplicación de la normativa con un compromiso social por la inclusión. Solo así podremos construir un entorno donde todas las personas, independientemente de sus necesidades y características, puedan vivir con dignidad y autonomía.

Los Beneficios y Desafíos de la Accesibilidad en Herramientas Low-Code y No-Code para la Creación de Software

Publicado el

En los últimos años, el auge de las herramientas low-code y no-code ha revolucionado la manera de desarrollar software. Estas plataformas han permitido el acceso al desarrollo de software, permitiendo que personas sin conocimientos avanzados de programación puedan crear sus propias aplicaciones, automatizaciones y sitios web. Sin embargo, para personas con discapacidad, estas herramientas presentan barreras significativas de accesibilidad.

¿Qué son las Herramientas Low-Code y No-Code?

Las herramientas low-code y no-code son paquetes de aplicaciones que permiten crear aplicaciones mediante interfaces gráficas y flujos visuales, reduciendo o eliminando la necesidad de escribir código manualmente. Estas plataformas están diseñadas para ser intuitivas, ofreciendo funciones como arrastrar y soltar (drag-and-drop), plantillas preconstruidas y bloques modulares para construir aplicaciones rápidamente.
Herramientas de lowCode como OutSystems, o Mendix presentan interfaces visualmente sencillas pero que contienen multitud de barreras de accesibilidad que impiden que un producto de apoyo como un lector de pantallas pueda transmitir la información a la persona ciega o interactuar con los elementos de la herramienta para colocar los componentes que darán forma al nuevo software.
Pero, además, herramientas noCode como Webflow o Bubble, enfocadas en la creación de aplicaciones y sitios web, además de resultar inaccesibles para personas que utilicen productos de apoyo, crean contenidos web que presentan barreras de accesibilidad perpetuando así el problema de una Web no accesible.

Beneficios de las Herramientas Low-Code y No-Code

Uno de los mayores beneficios es la posibilidad de que personas sin experiencia técnica puedan materializar sus ideas tecnológicas. Ya no es necesario depender exclusivamente de desarrolladores o equipos técnicos para crear prototipos o soluciones funcionales.
Además, la velocidad con la que se puede pasar de la idea a un producto mínimo viable (MVP) es uno de los mayores atractivos de estas plataformas. Las empresas pueden lanzar productos en menos tiempo, respondiendo más rápido a las necesidades del mercado.

Un gran poder conlleva una gran responsabilidad

La posibilidad de crear rápidamente y sin demasiados conocimientos nuevas experiencias y contenidos digitales es algo muy atractivo para muchas personas que bien no pueden o no quieren invertir mucho tiempo y esfuerzo en aprender aspectos del desarrollo de software. El problema es que este tipo de herramientas no permiten modificar la forma en que se generan esos contenidos y experiencias y en muchos casos lo hacen incluyendo barreras de accesibilidad. No está claro quién es la persona responsable de solucionar este problema: la persona que utiliza la herramienta pero no puede o no quiere aprender a desarrollar software o la empresa que ha creado la herramienta pero que no quiere complicar la experiencia de creación incluyendo aspectos de accesibilidad para así resultar una herramienta más atractiva a personas que no se quieren complicar con aspectos técnicos del desarrollo de software.

Iniciativas para Mejorar la Accesibilidad

Afortunadamente, algunas plataformas están comenzando a abordar estos desafíos. Por ejemplo, Webflow ha incorporado herramientas que permiten a los diseñadores agregar etiquetas y descripciones accesibles a los elementos. Bubble ofrece cierta flexibilidad para personalizar cómo se presentan los componentes en una aplicación para que sean más accesibles. Sin embargo, aún queda un largo camino por recorrer para garantizar que estas herramientas sean completamente inclusivas para todos los usuarios en esos contenidos web generados sin ninguna línea de código por parte de la persona que los crea.
Además, estas soluciones y parches siempre están enfocadas en el software generado y no en el uso de la propia herramienta por lo que los creadores de estas herramientas sólo piensan en personas con discapacidad como posibles clientes y no como posibles trabajadores o creadores.
Los hechos mencionados en el artículo publicado en el 2010 con el título La accesibilidad en crisis para los desarrolladores ciegos parece que siguen presentes en la sociedad actual.

Uso de hints en las interfaces de usuario

Publicado el

Al diseñar una interfaz de usuario la mahyor parte del peso de comunicación entre la interfaz y el usuario es a través del canal visual. Mediante un vistazo a una pantalla se puede intuir cómo utilizar ciertos elementos de la interfaz. Pero como no todas las personas tienen la misma capacidad de intuición ni la misma posibilidad de echar un vistazo a la pantalla debemos hacer uso de los distintos elementos de accesibilidad para hacer que la misma interfaz de usuario sea comprensible y usable para todas las personas.
A veces el uso de un control sólo se puede entender de forma visual como puede ser un interruptor deslizante para seleccionar un elemento más a la izquierda o más a la derecha, un botón de 3 estados o un cuadro de edición auto completable que permite realizar ciertas operaciones mientras se edita ese campo. En todos esos casos las personas con discapacidad visual pueden encontrar problemas a la hora de entender cómo utilizar dicho control. Para ayudar a este perfil de usuario la capa de accesibilidad permite incluir al control un texto de ayuda para entender cómo utilizar el control. Es lo que se conoce como hint o pista.

¿Qué son los Hints de Accesibilidad?

Los hints de accesibilidad son textos adicionales que proporcionan información contextual sobre un control de interfaz. Para los usuarios de lectores de pantalla. Estos hints pueden ser la diferencia entre una experiencia fluida y una frustrante. Por ejemplo, en una aplicación de banca móvil, un botón que simplemente dice «Enviar» podría no ser suficiente. Un hint podría agregar: «Enviar transferencia bancaria», proporcionando un contexto claro y específico.
Otro ejemplo podría ser un botón de tres estados cuyo hint podría indicar «pulse este botón para cambiar entre aceptado, pendiente y rechazado para actualizar el estado del pedido».

Implementación de Hints en Diferentes Plataformas

iOS

En iOS, los hints de accesibilidad se implementan utilizando el atributo accessibilityHint. Este atributo permite a los desarrolladores definir una cadena de texto que será leída por VoiceOver, el lector de pantallas de Apple, al final de toda la información del control.

Por ejemplo, un botón que tiene un icono de lápiz para editar puede no ser claro para todos los usuarios, pero al añadir un AccessibilitHint con el valor «Pulsa dos veces para modificar el valor de este campo»”, se proporciona la información necesaria para el usuario.

Android

En Android, los hints de accesibilidad se consiguen con el atributo android:hint en el fichero XML de la actividad. Este hint proporciona una descripción de lo que un control hace o lo que se espera que el usuario haga con él. Por ejemplo, un campo de entrada de texto puede tener un hint como “Introduce tu nombre completo”, lo cual es leído por TalkBack (el lector de pantalla de Android) para guiar al usuario.

HTML

En HTML, los hints se implementan con los atributos aria-description y aria-describedby.

El atributo aria-description proporciona una descripción directa del elemento, mientras que aria-describedby hace referencia a otro elemento en la página que contiene una descripción más detallada. Por ejemplo, un botón de búsqueda podría tener un aria-description=»Use este botón para buscar en todo el sitio web», y aria-describedby podría apuntar a un párrafo cercano al campo de búsqueda que explique cómo funciona la búsqueda en el sitio web.

Importancia de los Hints en la Accesibilidad

Estos atributos impactan en la accesibilidad de la interfaz de la siguiente forma:

  1. Claridad y Contexto: Los hints proporcionan información adicional que ayuda a los usuarios a entender la función de un control. Esto es especialmente importante para controles que solo tienen iconos o textos ambiguos.
  2. Mejora de la Usabilidad: Al proporcionar instrucciones claras sobre cómo utilizar un control, se mejora la usabilidad de la aplicación o sitio web, haciendo que la experiencia sea más intuitiva y menos frustrante para los usuarios con discapacidades visuales.
  3. Inclusión: Al implementar hints de accesibilidad, los desarrolladores están tomando pasos activos hacia la inclusión digital, asegurándose de que sus productos sean utilizables por el mayor número posible de personas.

Problemas Comunes con los Hints

A pesar de su importancia, los hints de accesibilidad no están exentos de problemas. Algunos de los desafíos más comunes incluyen:

  1. Hints Redundantes: A veces, los desarrolladores añaden hints que repiten información que ya está clara en el contexto visual, lo que puede resultar en una sobrecarga de información para el usuario de un lector de pantalla. Por ejemplo, un botón con un texto visible “Buscar” no necesita un hint adicional que diga “Botón de búsqueda”.
  2. Falta de Actualización: Los hints pueden volverse obsoletos si no se actualizan junto con cambios en la interfaz. Esto puede llevar a confusión si un hint describe una funcionalidad que ya no existe o que ha cambiado.
  3. Hints Incompletos: No proporcionar suficiente información es otro problema. Un hint demasiado breve puede no dar el contexto necesario. Por ejemplo, un hint que solo dice “Enviar” sin más detalles podría no ser útil en una aplicación con múltiples funcionalidades de envío.
  4. Uso Incorrecto de los Atributos: En HTML, confundir aria-description con aria-describedby puede llevar a que los usuarios de lectores de pantalla no reciban la información adecuada. Es crucial usar cada atributo de forma correcta para asegurarse de que la información se transmite adecuadamente.
  5. Problemas de personalización del lector de pantallas: algunos usuarios ciegos deshabilitan la lectura de estos elementos para dar mayor agilidad a su experiencia de uso. Esto implica que en el hint sólo se debe incluir la información relacionada con el control para evitar que el usuario pierda información vital de otra parte de la interfaz.

Buenas Prácticas para el Uso de Hints

Para maximizar la efectividad de los hints de accesibilidad, es importante seguir algunas buenas prácticas:

  1. Ser Claro y Conciso: Proporcionar descripciones claras y directas que sean fáciles de entender. Evitar la jerga técnica y centrarse en el propósito del control.
  2. Actualizar Regularmente: Asegurarse de que los hints se actualizan junto con cualquier cambio en la interfaz de usuario para evitar descripciones obsoletas.
  3. Consistencia: Mantener una terminología y un estilo consistentes en todos los hints para evitar confusión.
  4. Seguir los estilos definidos en la guía de interfaces del fabricante: Apple y Google tienen recomendaciones sobre el estilo de lenguaje a emplear en los hints.

Cómo notificar de forma apropiada un error en una aplicación o servicio

Publicado el

A la hora de mejorar y mantener un producto software los desarrolladores utilizan el feedback proporcionado por los usuarios a través de lo que se conoce como bug report o feedback report. Un bug report es un mensaje de un usuario al desarrollador indicando que hay un problema en una aplicación.

Este mensaje se puede enviar a través de correo electrónico, mediante una plataforma web de gestión de errores, a través de chat o a través del canal que el desarrollador haya proporcionado para la comunicación con los usuarios.

Un bug report efectivo

En muchas ocasiones los reportes de error enviados por los usuarios son totalmente inútiles y poco efectivos ya que se limitan a mensajes del tipo la app no funciona. Es evidente que si se envía un reporte de error es porque el usuario ha encontrado que algo no funciona pero los desarrolladores, por ahora, no podemos leer el pensamiento de los usuarios por lo que es necesario dar más detalles sobre qué no funciona para encontrar respuesta a la pregunta de por qué no funciona y cómo hace el usuario para que no funcione ya que los desarrolladores antes de publicar sus aplicaciones realizan multitud de pruebas de uso y puede que conocer cómo utilizan su aplicación otras personas les permita mejorar el uso de la misma.

Además, decir que la app no funciona es algo muy general. Una app pequeña tiene entre 4 y 15 pantallas por lo que es de agradecer un poco más de información.

Qué incluir en un reporte de error

A la hora de enviar un reporte de error es muy recomendable incluir los siguientes apartados:

Descripción breve del problema

En un par de párrafos describir qué error sucede. Se recomienda incluir el nombre de la aplicación, en qué pantalla sucede y cómo llegó a esa pantalla.

Paso a paso

Incluir una lista de pasos desde que se abre la aplicación hasta que se obtiene el error o el comportamiento no esperado.

También se debe incluir un paso indicando que se activa el lector de pantallas, el magnificador o cualquier otro producto de apoyo que se esté utilizando ya que a veces los errores sólo suceden con un producto de apoyo.

Además, si el producto de apoyo o la aplicación tiene alguna personalización o ajuste especial que provoque el problema también es necesario indicarlo.

Resultados esperados y resultados obtenidos

Este apartado sirve para indicar qué esperaba el usuario que sucediese y qué es lo que sucede realmente. A veces el problema no es de software sino de lenguaje empleado. El usuario entendió que debería pasar una cosa pero el desarrollador no se explicó bien en el manual o las instrucciones en la aplicación. Este tipo de informes de error permiten solucionar este tipo de problemas de malentendidos o para comprender qué experiencia de uso tienen los usuarios ante ciertas situaciones provocadas por sus aplicaciones.

Los resultados esperados y resultados obtenidos suelen ser un par de párrafos describiendo ambos elementos.

Observaciones

Este apartado suele ser un texto beve donde el usuario puede aportar más información sobre, por ejemplo, si está utilizando el dispositivo con una configuración determinada (por ejemplo un iPhone configurado en Español de USA con modo oscuro y con auriculares), el modelo de su dispositivo o si tenía algún dispositivo más conectado.

Adjuntos al reporte

Adjunto al reporte de errores es recomendable incluir un adjunto con un informe de comportamiento o fichero de log que permita al desarrollador ver el comportamiento interno de la aplicación cuando sucedía el problema.

Si el apartado de paso a paso es muy detallado no es necesario incluir ningún adjunto a menos que el problema lo tenga un usuario en concreto y pueda ser por una configuración muy concreta o un fallo colateral en ese dispositivo concreto. Estos ficheros de log permiten encontrar esa información tan concreta que no es evidente ni para el usuario ni para el desarrollador. 

En la mayoría de ocasiones se piden estos ficheros en una segunda comunicación sólo si el desarrollador no ha podido reproducir el problema reportado por el usuario y tras seguir el paso a paso indicado.

Siempre con educación

Es algo que puede parecer evidente cuando nos comunicamos con otra persona pero es algo que muchas veces se olvida. Si un usuario espera que otra persona atienda a su mensaje con buena disposición es necesario un trato cordial y sin caer en insultos o palabras despectivas hacia la persona que desarrolla el software, su inteligencia o su progenie.

En varias ocasiones he desechado o ignorado reportes de error por estar mal estructurados, no aportar información suficiente o utilizar un lenguaje inapropiado. Y como yo conozco a muchos desarrolladores que hacen lo mismo ya que se considera que ese tipo de feddback no es beneficioso para el software.

Buscando el entendimiento

A veces también hay un problema de comunicación entre el usuario y el desarrollador por el lenguaje empleado. Puede que el usuario no sepa hablar francés y el desarrollador no sepa hablar japonés. En estos casos siempre es recomendable utilizar un idioma neutral, siendo el más común en el desarrollo de software utilizar inglés, y utilizando una herramienta de traducción incluir dentro del texto un aviso indicando que la persona habla en un idioma concreto y que este texto ha sido traducido al inglés gracias a una herramienta de traducción. Esto permite a ambas partes estar atentos a posibles malentendidos a causa de un error en la traducción.