Categoría: Metodología y filosofía

Artículos, pensamientos y experiencias vitales

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.

Tests dentro de la ingeniería del software

Publicado el

Dentro de la mayoría de metodologías de diseño y desarrollo de software existe un apartado enfocado a las comprobaciones de las funciones, aspecto y comportamiento de una aplicación. Es lo que se conoce como testing dentro del proyecto.

Beneficios del testing

Dentro de la multitud beneficios que aporta realizar testing en nuestro proyecto se encuentran los siguientes.

  • Se pueden realizar pruebas específicas y generales del comportamiento de clases y funciones de nuestro proyecto. De esta forma podemos validar que las funciones y clases que desarrollamos dentro de nuestro proyecto cumplen los requisitos definidos por el documento de análisis.
  • Se pueden realizar pruebas completas de una experiencia de usuario. De esta forma podemos verificar que nada se ha roto cuando añadimos algún elemento nuevo a nuestro proyecto.
  • Las pruebas de uso de la aplicación se pueden automatizar para que nuestro ordenador compruebe que la aplicación funciona como se espera.
  • Además permite automatizar otros procesos que pueden resultar laboriosos o tediosos como la toma de capturas de pantalla, validación del aspecto visual de cada pantalla de la aplicación e incluso se pueden crear comprobaciones de accesibilidad en algunas plataformas para la detección temprana de barreras de accesibilidad.

Problemas del testing

Incluir testing en nuestro proyecto implica la aparición de los siguientes problemas, sobre todo si el equipo de desarrollo no está acostumbrado al uso de testing:

  • Incremento en los costes de organización y tiempo. Las pruebas o tests no se planifican ni se escriben solas. Es necesario organizar el plan de trabajo para que el testing sea correctamente incluido en la metodología de trabajo utilizada por el equipo dentro del proyecto.
  • Prevención de falsos errores. Cuando se realizan cambios visuales o funcionales dentro de una ventana o una sección de nuestra aplicación todos los tests relacionados con dicha pantalla fallarán. Es necesario que algún miembro del equipo actualice esos tests para que acepten los nuevos cambios y validar cuales son los nuevos comportamientos y aspectos válidos para el proyecto.
  • No existe la fiabilidad al completo. Aunque podamos pensar que un proyecto software siempre se comportará igual en cualquier situación cuando el proyecto es complejo también aumenta la complejidad para cubrir todos los posibles casos de uso con los tests. Incluso así es posible que nuestro conjunto de tests no detecte algún posible error o problema de funcionamiento de nuestra aplicación. Cuando esto sucede es necesario ampliar el número de tests para verificar que el error detectado no vuelva a ocurrir.

Tipos de testing

Dentro de la creación y mantenimiento de un proyecto de software existen distintas necesidades de comprobación por esta razón existen diversos tipos de testing.

Cada tipo de testing tiene un objetivo claro que ayuda a detectar y solucionar un tipo de problema específico del proyecto.

Tests funcionales

Este tipo de test comprueba si la funcionalidad de un método o función se adapta al comportamiento esperado. De esta forma podemos comprobar si una función de conversión de divisas funciona como se espera o si el cálculo de el total del precio de un pedido no comete errores.

Dentro de este tipo de tests encontramos los tests unitarios, tests de aceptación, tests de integración y tests de regresión.

Tests no funcionales

Este tipo de test representa  las pruebas que se realizan en la aplicación o producto y que no están relacionadas con el código del proyecto.

Algunas de estas pruebas son las pruebas de rendimiento, las pruebas de carga y las pruebas de estrés.

Regla YAGNI – You aren’t gonna need it

Publicado el

La última de las 5 reglas para escribir software simple y robusto es la regla de YAGNI. Su acrónimo traducido dice: no lo vas a necesitar.

En muchas ocasiones cometemos el error de hacer sobreingeniería en un proyecto. Esto significa que el cliente nos ha pedido una calculadora para hacer sumas y terminamos desarrollando una hoja de cálculo con soporte para funciones y un lenguaje propio de scripting. Esto provoca que el mantenimiento y el esfuerzo para desarrollar y mantener el proyecto se ha sobredimensionado de forma incontrolada e innecesaria.

Para evitar caer en este código innecesario o código YAGNI debemos centrarnos en los requerimientos del producto final, no desarrollar código que no se esté utilizando en el proyecto, eliminar el código comentado (Si está comentado es que no es necesario) y utilizar ciertos patrones de trabajo como TDD (Test Driven Development) o trabajar con PullRequests pequeñas enfocadas en aspectos muy específicos de un requerimiento o característica del proyecto. También realizar procesos de refactorización del código al terminar un plazo de entrega o el desarrollo de un módulo facilita la desaparición de código YAGNI.