SOLID: Principio de abierto/cerrado u Open/closed principle

Como vimos en el artículo de los principios SOLID este es el segundo principio.

Significado

Este principio Establece que las clases deben estar abiertas para su extensión, pero cerradas para su modificación.

Ejemplo

Siguiendo con el ejemplo de la clase Persona que vimos en el artículo del principio de responsabilidad única imaginemos que tenemos una lista de personas(array) y queremos imprimir por pantalla las personas que tengan la edad suficiente para conducir un vehículo. Pero debemos tener en cuenta que según el país esta edad puede ser distinta. Para completar este programa crearemos una clase ListaDePersonasMayoresDeEdad que resolverá este problema con la función imprimeConductores().

Para el ejemplo de código en lugar de cargar los datos de personas de la base de datos tendremos una lista que se rellenará en el constructor de la clase ListaDePersonasMayoresDeEdad.

El código de ejemplo quedaría así:

 

class Persona {
    propiedad nombre
    propiedad apellidos
    propiedad nacionalidad

    propiedad fechaDeNacimiento

funcion calculaEdad()
}

 

class ListaDePersonasMayoresDeEdad {

    propiedad listaDePersonas

 

    funcion Constructor() {

        listaDePersonas = [

            Persona(“Fulano”, “De tal”, Español, 1/5/1981),

            Persona(“Mengano”, “De cual”, Mejicano, 3/12/1992),

            Persona(“John”, “Doe”, Norteamericano, 13/2/2012),

            Persona(“Boris”, “Stalin”, Ruso, 20/9/1999)

        ]

    }

 

    funcion imprimeConductores() {

        bucle personaDeLaLista en listaDePersonas {

            Si personaDeLaLista.nacionalidad = Español Y personaDeLaLista.calculaEdad() >= 18

            entonces imprime(personaDeLaLista)

            Si personaDeLaLista.nacionalidad = Norteamericano Y personaDeLaLista.calculaEdad() >= 16

            entonces imprime(personaDeLaLista)

            Si personaDeLaLista.nacionalidad = Ruso Y personaDeLaLista.calculaEdad() >= 18

            entonces imprime(personaDeLaLista)

        }

    }

}

 

Este programa no cumple el principio de abierto/cerrado por la sencilla razón de la necesidad de modificar la clase ListaDePersonasMayoresDeEdad cada vez que haya una nacionalidad nueva en nuestra base de datos. La función imprimeConductores() tendría que ser modificada cada vez que en la base de datos apareciese un usuario con una nueva nacionalidad.

Solución

Dependiendo de las características y las capacidades del lenguaje de programación que estemos utilizando la solución puede crearse mediante clases abstractas, protocolos o empleando una solución generalista como la creación de una clase nacionalidad que encapsule ciertos requisitos en la base de datos.

El objetivo de la solución se enfoca en evitar tener que modificar una función o clase en el futuro simplemente porque se agreguen nuevos datos a la base de datos.

Recordemos que este principio nos mueve a extender una clase para evitar estar modificando otra constantemente. Por esa razón podemos extender la clase Persona gracias a la nueva clase Nacionalidad

Veamos el código de esta solución.

 

class Persona {
    propiedad nombre
    propiedad apellidos
    propiedad nacionalidad

    propiedad fechaDeNacimiento

funcion calculaEdad()
}

 

class Nacionalidad {

    propiedad nombreDeNacionalidad

    propiedad edadParaConducir

}

 

class ListaDePersonasMayoresDeEdad {

    propiedad listaDePersonas

    propiedad nacionalidades 

    funcion Constructor() {

        nacionalidades = [

            Nacionalidad(Español , 18),

            Nacionalidad(Norteamericano , 21),

            Nacionalidad(Mejicano , 15),

            Nacionalidad(Ruso , 18),

        ]

 

        listaDePersonas = [

            Persona(“Fulano”, “De tal”, Español, 1/5/1981),

            Persona(“Mengano”, “De cual”, Mejicano, 3/12/1992),

            Persona(“John”, “Doe”, Norteamericano, 13/2/2012),

            Persona(“Boris”, “Stalin”, Ruso, 20/9/1999)

        ]

    }

 

    funcion imprimeConductores() {

        bucle personaDeLaLista en listaDePersonas {

            Si personaDeLaLista.calculaEdad() >= personaDeLaLista.nacionalidad.edadParaConducir

            entonces imprime(personaDeLaLista)

        }

    }

 

}

 

Ahora el bucle que hay en la función imprimeConductores() se ha reducido y es más legible.

Esta solución es más fácil de mantener y facilita que la clase Nacionalidad pueda incorporar más información interesante para nuestra aplicación y su mantenimiento ha mejorado al no existir la necesidad de modificar eternamente una función de una clase concreta dependiendo de qué datos hay en la base de datos.

SOLID: Principio de responsabilidad única o Single responsibility principle

Como vimos en el artículo de los principios SOLID este es el primero de los principio SOLID.

Significado

Este principio establece que una clase o componente debe ser responsable de una sola cosa.

Este principio está alineado con el término de desacoplamiento o decoupled utilizado en muchas metodologías de desarrollo.

Cuando se codifica una clase que sólo posee una responsabilidad o función es fácil diseñar tests para comprobar que funciona correctamente y además facilita que esa clase pueda ser reutilizada en futuros proyectos.

Ejemplo

Imaginemos el siguiente ejemplo en el que tenemos una clase Persona que contiene los datos de un usuario.

El código de nuestra clase podría ser algo como:

 

class Persona {
    propiedad nombre
    propiedad apellidos
    propiedad nacionalidad
    propiedad fechaDeNacimiento

funcion calculaEdad()
    funcion guardaEnBaseDeDatos()
    funcion cargaDesdeBaseDeDatos()
}

Este ejemplo viola el principio de responsabilidad única.

Esto se debe a que la clase Persona además de guardar la información de una persona también se encarga de almacenar y recuperar la información de una base de datos.

Imaginemos que nuestra aplicación está utilizando MySQL pero en una futura versión queremos incluir soporte para la base de datos RealM manteniendo la opción de MySQL. Los cambios que tendríamos que hacer a nuestra clase persona complicarían enormemente el código.

En cambio si creamos una clase Persona que almacene los datos de un usuario y otra clase PersonaMySQL que se encargue de recuperar y almacenar los datos en nuestra base de datos MySQL permitiría fácilmente la codificación de una nueva clase PersonaRealM que haga lo mismo que la clase PersonaMySQL pero adaptando el código a la base de datos RealM.

 

class Persona {
    propiedad nombre
    propiedad apellidos
    propiedad nacionalidad
    propiedad fechaDeNacimiento

funcion calculaEdad()
}

class PersonaMySQL {
    funcion guardaEnBaseDeDatos()
    funcion cargaDesdeBaseDeDatos()
}

class PersonaRealM {
    funcion guardaEnBaseDeDatos()
    funcion cargaDesdeBaseDeDatos()
}

Nuestro programa será mucho más cohesivo y estará más encapsulado aplicando este principio. Siguiendo esta forma de agrupar funciones y propiedades en nuestras clases se simplifica las operaciones de mantenimiento como localizar dónde hay un error o ampliar la funcionalidad de nuestra aplicación agregando soporte a otras bases de datos.

Principios de programación SOLID

En el diseño y desarrollo de software el paradigma de la programación orientada a objetos (POO) es el paradigma más utilizado a la hora de desarrollar software.

En la programación orientada a objetos podemos dividir un programa en muchas entidades con propiedades y funciones que se relacionan entre ellas.

La persona encargada de codificar cada una de estas clases y relaciones tiene total libertad a la hora de definir quién, cómo y dónde se resuelve cada mini problema.

Esta libertad de codificación facilita la resolución de los problemas que debe resolver una aplicación pero cuando el proyecto es grande la complejidad en el mantenimiento y ampliación de una aplicación crece notablemente haciendo muy dificultoso utilizar programación orientada a objetos de forma libre en proyectos de gran envergadura. 

Esto se debe a que las clases encargadas de un problema se vuelve demasiado grandes y las relaciones y dependencias entre clases cada vez son más complejas.

Principios para mantener el orden en nuestro código

A principios de la década de los 2000 Robert C. Martin propuso una metodología de codificación basada en 5 principios.

Tomando la primera letra de cada uno de esos principios sale el nombre de esta metodología que conocemos por principios SOLID.

Estos principios son:

  • S: Single responsibility principle o Principio de responsabilidad única
  • O: Open/closed principle o Principio de abierto/cerrado
  • L: Liskov substitution principle o Principio de sustitución de Liskov
  • I: Interface segregation principle o Principio de segregación de la interfaz
  • D: Dependency inversion principle o Principio de inversión de dependencia

Razones para utilizar SOLID

Aplicando estos principios a la hora de codificar un proyecto software mejorará su legibilidad y su mantenimiento tanto por desarrolladores individuales como por equipos de desarrollo.

En la industria actual del software el trabajo en equipo es algo imprescindible para un buen profesional y saber codificar un proyecto para que tenga un buen nivel de mantenimiento para incorporar nuevas características o localizar y resolver problemas en el código es una habilidad muy solicitada por los equipos de desarrollo de software. 

Veremos cada uno de estos principios en futuros artículos publicados en este blog.

Un mundo más inteligente puede ser un mundo más accesible

En los últimos años la revolución de los dispositivos móviles está cambiando tanto los hábitos tecnológicos de las personas como la forma de comunicarse. Incluso los hábitos de la salud, el deporte y las actividades comerciales y de ocio están siendo afectados gracias a la conectividad permanente de las personas a Internet y sus servicios a través de los dispositivos móviles.

El smartphone como extensión de la persona

Los actuales teléfonos inteligentes o smartphones poseen multitud de funciones, sensores y canales de comunicación que nos permiten interactuar en algunas formas con nuestro entorno.

Su conexión a Internet casi permanente nos permite participar en redes sociales, consultar precios y contenidos así como buscar información sobre lugares turísticos, restaurantes y áreas comerciales. Todo esto buscando enriquecer la experiencia de vivir en la ciudad.

Los sensores que incorporan la mayoría de smartphones permiten identificar el lugar en el que se encuentra el usuario, la posición del teléfono y algunos datos del entorno. Todo esto permite a las aplicaciones móviles instaladas en el teléfono ofrecer experiencias de usuario más precisas y completas.

Esto está provocando una evolución tecnológica en ciudades y negocios. Conceptos como las smart cities (ciudades inteligentes) ya no se entienden sin usuarios con dispositivos conectados a Internet.

Los avances tecnológicos de los smartphones han provocado también una evolución tecnológica en el uso de sensores. La domótica y los wearables (prendas inteligentes) son un ejemplo de esta evolución. Actualmente podemos encontrar multitud de elementos tecnológicos y sensibles por la ciudad, el trabajo y el hogar. Incluso sobre nosotros mismos.

Entornos inteligentes

Cuando una habitación, un edificio o una ciudad utiliza elementos tecnológicos para obtener información del ambiente podemos empezar a hablar de entornos inteligentes .

Detectores de presencia, termómetros o estaciones climáticas son ejemplos ya habituales en ciudades y edificios.

Toda esta funcionalidad y sensibilidad del entorno que nos rodea actualmente, en muchos casos y por desgracia, no suele comunicarse con personas o dispositivos móviles pero eso está cambiando. La razón es simple: un entorno controlable y controlado es más confortable para las personas.

Algo confortable puede ser más usable , más eficaz y más accesible para todas las personas.

El smartphone no es suficiente

En muchas ocasiones el teléfono no tiene los suficientes recursos como para ofrecer un servicio o experiencia completa.

La precisión y la capacidad de los sensores de un smartphone, en muchos casos, puede ser muy limitada o bien no incluir los suficientes sensores para que el servicio o la aplicación puedan ayudar al usuario.

También la posición del smartphone puede dificultar la actividad del sensor. Por ejemplo, si el smartphone siempre va en el bolsillo del usuario no se puede hacer uso de sensores de ruido, luminosidad y temperatura ambiente ya que los datos obtenidos no serán reales para el entorno en el que se mueve el usuario.

La solución más inmediata pasa por ampliar la capacidad sensorial del smartphone conectando otros sensores o dispositivos del entorno del usuario. Este tipo de dispositivo puede ser una prenda o elemento que lleve el propio usuario como unas gafas, unos zapatos, un sombrero o las propias prendas de vestir. Es lo que se conoce como prendas inteligentes o wearables.

Pero un wearable también puede ser un dispositivo que no posea la forma de un objeto o prenda de vestir. Puede ser una pequeña caja o dispositivo que nos permita usarlo o colocarlo en distintos elementos de nuestro entorno o sobre nosotros mismos.

Estos wearables hacen que un smartphone pueda acceder a sensores más precisos, colocados en un lugar más idóneo y, además, ahorrar en batería y potencia del procesador de nuestro smartphone ya que la gestión y mantenimiento de estos nuevos sensores queda delegado al dispositivo wearable.

Tech4Freedom

El proyecto Tech4Freedom está desarrollando una extensión sensorial para nuestros smartphones buscando ofrecer servicios a personas con discapacidad para superar barreras físicas, sociales y mentales.

Este dispositivo incorpora sensores para detectar la temperatura ambiente, obstáculos, comunicarse con elementos del entorno y diversas funciones más que permiten a los desarrolladores de aplicaciones móviles crear nuevos servicios a través de un smartphone comunicándose con el dispositivo de Tech4Fredom para alcanzar un mayor conocimiento del entorno.

Puedes ver un vídeo descriptivo de Tech4Freedom en inglés para conocer sus posibilidades.

La accesibilidad en este contexto

Toda esta tecnología en nuestra mano, nuestra ropa y nuestro alrededor puede beneficiar notablemente la autonomía personal de las personas con discapacidad y la accesibilidad del entorno para todo el mundo.

Esta tecnología permitiría crear habitaciones que controlen de forma automática la luz ambiental, la temperatura o la música ambiental dependiendo de si hay alguien en la habitación o la persona o personas que están en la habitación necesitan más luz, no les gusta los ambientes húmedos o ruidosos.

También permitiría controlar si una persona entra o sale de un área delimitada por sensores. Por ejemplo, padres ciegos pueden controlar si sus hijos salen de una habitación o personas ciegas pueden jugar en áreas de juego delimitadas mediante sensores.

Los sensores en la ropa pueden ayudar a la detección de obstáculos, un mejor posicionamiento en la ciudad y en interiores de edificios así como facilitar la asistencia médica ante accidentes a personas con necesidades especiales detectando si han sufrido una caida, su presión arterial es baja o sufren de una hipoglucemia.

La tecnología sigue demostrando que es el camino para un mundo más accesible e inclusivo.

Esto no pasaba con Jobs

Hoy, 5 de octubre, es el aniversario de la muerte de Steve Jobs. Algunos lo identificaban como un genio y un visionario, otros como un loco o un tirano. Quizás todos esos adjetivos sean aplicable a su persona pero en este artículo intentaré exponer una realidad tras su falta: Apple ha dejado de ser tan perfeccionista como lo era antes.

Personalmente opino que gran parte del brillo con el que se rodea a la figura de Jobs pertenece a su genial equipo humano: desarrolladores, diseñadores, analistas, psicólogos y demás profesionales que interpretaban las palabras y deseos de Jobs para crear productos de alta calidad con muy buena experiencia de usuario.

Publicación de iOS6 con errores reportados

Apple suele ofrecer a los desarrolladores una versión previa y en desarrollo del futuro sistema operativo para que vayan adaptando sus aplicaciones y, además reporten los errores y anomalías encontradas. Para esta última tarea los desarrolladores utilizan el portal de Apple bug report en el cual el desarrollador rellena una ficha técnica del error especificando los pasos para reproducir el error, los resultados obtenidos y los resultados esperados. Con esta información los ingenieros de Apple solucionan aquellos fallos reportados en el sistema.

Cuando salió la beta 4 de iOS6 muchos desarrolladores esperamos que fuese el último empujón para que resolviesen los errores reportados. Pues Apple reparó lo que pudo hasta la fecha y el día de publicación se respetó. Steve Jobs retrasó el lanzamiento de varios productos porque consideró que no estaban lo suficientemente pulidos. Ahora Apple cumple las fechas porque el mercado las impone.

Carencias en accesibilidad

La accesibilidad de iOS6 también ha sufrido esta nueva filosofía de Apple de publicar cuando toque esté como esté el producto.

Más de 40 errores reportados han quedado sin solución en esta versión 6.0 del sistema operativo para dispositivos móviles de Apple.

Servicios publicados con errores

Junto a la publicación de iOS6 han aparecido nuevos servicios para el sistema, como la aplicación de mapas, o nuevas versiones de los servicios, como Siri. Estos servicios han sido publicados con errores en sus datos, como sucede con mapas, o con funcionalidad limitada, como sucede con Siri.

En el caso de Siri gran parte de esta limitación se origina a la falta de catalogación de servicios de restauración, hostelería y ocio en España y otros países de habla hispana pero otras limitaciones se debe a que Apple no ha traducido por completo el módulo de comprensión del lenguaje el cual permite mantener una conversación más o menos coherente con Siri.

Maltrato a los desarrolladores

A la hora de salir un nuevo dispositivo de Apple se suele notificar con suficiente antelación a los desarrolladores para que adapten sus aplicaciones a las nuevas características del dispositivo. Con la aparición del iPhone 5 los desarrolladores sólo tuvimos a nuestra disposición las herramientas y documentación necesaria una semana antes de su venta al público. Algunos defensores de Apple indican que esto ha sido por motivos de seguridad para evitar filtrar el nuevo dispositivo. Se ha demostrado que el torturar a los desarrolladores limitando su tiempo de adaptación al nuevo formato no evita que se hable del futuro dispositivo semanas antes debido a que la seguridad falla en las fábricas donde se ensambla el dispositivo o en otros eslabones de la cadena.

La Apple sin Jobs

Este primer año sin Steve Jobs para Apple y la gente que estamos relacionados con ella está siendo un poco frenético por los cambios tanto dentro de Apple como en el mercado global. Apple está empezando a cometer los mismos errores que cometió Microsoft en su día: sacar el producto en la fecha y luego se repara, los desarrolladores están ahí para nuestra plataforma y el mercado manda.

Pero gran parte del actual éxito de Apple se debe a los usuarios y desarrolladores que utilizamos sus productos, trabajamos con y para sus plataformas y pensamos que la experiencia de usuario es satisfactoria frente a otras posibilidades. Debemos comunicar a Apple que deben cambiar el rumbo y volver a seguir la filosofía de perfección, mejora de la experiencia del usuario y filosofía de trato al cliente y al desarrollador. Podemos reportar los errores, en inglés al departamento de accesibilidad de Apple o utilizar el teléfono de atención al cliente de Apple en nuestro país para transmitir nuestras quejas y sugerencias.

Si queremos que Apple siga en el rumbo que dejó Jobs y su equipo debemos hacernos oir ya que, aparentemente, ahora Apple está controlada por accionistas y el mercado.

Ventajas y peligros de la accesibilidad

La Web se ha convertido en el medio donde el conocimiento de la humanidad se comparte de forma más global, accesible y efectiva. Muchos defendemos la neutralidad de Internet pero hay otros peligros que rodean a la Web.

La accesibilidad en la Web

En el principio la Web era principalmente texto y enlaces. Esto limitaba los problemas de accesibilidad a ciertos perfiles de discapacidad fácilmente superables con un equipo informático adaptado que permitiese el acceso al texto. Con el tiempo aparecieron imágenes, formularios y otros elementos visuales para proporcionar mayor vistosidad al contenido. Posteriormente aparecieron vídeos, sonido, contenidos dinámicos y tecnologías externas al propio HTML como Javascript, Flash y Applets Java. Todas estas mejoras beneficiaron a la mayoría de usuarios de Internet pero provocó la aparición de multitud de barreras de accesibilidad.

El W3C observó que existía un total desconocimiento de las necesidades de las personas con discapacidad en la Web y que no existían criterios que permitiesen a los creadores de contenidos satisfacer estas necesidades. De todo esto surge la WAI (Web Accessibility Initiative) que busca proporcionar criterios y técnicas para que la Web sea accesible y evitar la tendencia de que por cada nueva tecnología o característica que aparezca en la Web se creen nuevas barreras de accesibilidad.

Aunque esta tendencia de nuevas barreras por cada nueva tecnología aún persiste en nuestros días hay que reconocer que gracias a la WAI, los usuarios y la progresiva concienciación global de los usuarios de Internet hoy podemos disfrutar de una Web más inclusiva, aunque aún no es suficiente.

Las pautas y técnicas ofrecidas por la WAI permitió a los desarrolladores de productos de apoyo definir un modelo más claro sobre cómo acceder a los contenidos de una página web y cómo acceder a los servicios y funciones ofrecidos en ella. También permitió avanzar en formatos y estándares y definir marcos legales para comprender el concepto de una página web accesible para que legisladores, diseñadores y fabricantes de tecnología tuviesen un mismo punto de partida.

La realidad de la accesibilidad legal

Muchos gobiernos han definido y están definiendo hoy día sus marcos legales para la Web a partir de los criterios indicados por la WAI. Aunque esto sea satisfactorio en muchos casos es cierto que el utilizar los criterios definidos por la WAI no garantizan una página web accesible ya que, como todo en la vida, cualquier elemento tiene un uso correcto y muchos incorrectos. Además, aunque la WAI ha ido actualizando sus criterios y técnicas las leyes suelen ir siempre por detrás por lo que encontramos que muchas leyes definen requisitos de accesibilidad para la Web con criterios concebidos hace más de 14 años. Pero lo importante de estas leyes es que apoyan los estándares por encima de soluciones específicas y describen las necesidades de diversos perfiles de discapacidad para acceder a los distintos contenidos definiendo el concepto de web accesible para todos.

Todo esto hace pensar que la ley es insuficiente para garantizar la accesibilidad real en la Web. Pero debemos entender que las leyes son necesarias como incentivo para los creadores de contenidos que hacen bien su trabajo y como herramienta para obligar a empresas y organismos para crear páginas de forma responsable.

Guetos digitales

Las empresas, los organismos, los diseñadores y los responsables de muchos sitios web al conocer el hecho de que sus páginas web no son accesibles optan por crear un sitio web alternativo al que llaman versión accesible. Un sitio web con pocas o ninguna imagen, con pocas o ninguna función de la llamada Web 2.0 y que suele ser actualizada más tarde que la versión oficial o, en algunos casos, olvidada por los propios creadores. Esta versión accesible, creada por aquellos que confunden la accesibilidad de la Web por algo visualmente feo, dedicado a aquellos que la sociedad ha olvidado por sus necesidades especiales y que, por tanto, es algo que también se puede olvidar. La versión accesible de un sitio web es un lugar virtual donde confinar a aquellos que no cumplen esos requisitos físicos, sensoriales o cognitivos necesarios para acceder al sitio oficial. Aquellos que deben ser ovlidados en un patio trasero para que no molesten a los que visitan al sitio oficial y, además, deben estar agradecidos por ofrecerles este gueto donde acceder a las migajas de contenidos y servicios de esa página web.

Esta versión accesible es confundida por estos creadores con el concepto de alternativa. En lugar de ofrecer una alternativa a las imágenes, sonidos y tecnologías no compatibles con la accesibilidad se opta por dar un camino alternativo al contenido, un camino más oscuro, más feo, más limitado y más discriminatorio.

Soluciones específicas

Algunos fabricantes y desarrolladores relacionados con la accesibilidad han creado productos de apoyo y servicios específicos para satisfacer las necesidades de unos pocos perfiles de discapacidad para proporcionar un método de comunicación entre el usuario y el dispositivo compatible con las necesidades del usuario.

En el caso de barreras de accesibilidad al hardware o al software, como pueden ser lectores de pantalla, magnificadores, teclados adaptados o virtuales, reconocedores del habla o apuntadores; su objetivo es dar un acceso general a los contenidos y funciones de un dispositivo informático. Estas soluciones, en muchos casos, son tan específicas para el perfil de discapacidad que su uso provoca la aparición de barreras de accesibilidad para aquellas personas que no posean dicho perfil de discapacidad. Por ejemplo existen lectores de pantalla que desactivan el funcionamiento habitual del teclado o ratón, muchas personas sin discapacidad visual se sienten incapaces de utilizar un equipo informático cuya pantalla muestra una porción mínima de la pantalla de forma aumentada.

La Web se ha entendido como un nuevo medio de actividad virtual. Esto ha provocado que algunos fabricantes hayan decidido ignorar la presencia de estos productos de apoyo para el hardware y el software y, en su lugar, crear aplicaciones web o navegadores web que satisfagan las necesidades de algunos perfiles de discapacidad. Ejemplos como navegadores web para niños autistas, como ZacBrowser, o personas ciegas como el IBM home page reader han demostrado ser soluciones que dan un acceso parcial a los contenidos y funciones que ofrece una web completa.

Otras soluciones como Web anywhere, ReadSpeak o Inclusite consisten en una aplicación Java, Flash u otra tecnología similar que proporcionan un método de acceso alternativo a los contenidos y funcionalidades de una web.

En el caso de Readspeak se confunde accesibilidad con mejor experiencia del usuario ya que el servicio consiste en una función para que el navegador nos lea la página web que estamos visitando por si no nos apetece hacerlo ya que una persona ciega que haya accedido a esa página de forma autónoma no necesita dicho servicio ya que disfruta de la voz ofrecida por su lector de pantallas.

Pero en el caso de Web anywhere e Inclusite su función va más allá ya que intentan sustituir al producto de apoyo habitual del usuario ya que, en muchos casos, estos servicios son incompatibles con algunos lectores de pantalla o sistemas de reconocimiento del habla dejando al usuario con discapacidad en un limbo de indefensión en el momento de pasar al uso de su producto de apoyo al de estos servicios ya que, aunque estos servicios satisfagan las necesidades de algunos usuarios no contemplan una serie de problemas básicos:

  • Si el usuario desactiva su producto de apoyo para acceder al servicio de WebAnywhere o Inclusite aparece el problema de que el usuario está utilizando un equipo informático sin adaptación y necesita abrir un navegador web y acceder a la página de WebAnywhere o Inclusite. Estas operaciones pueden ser realizadas de forma autónoma por aquellos usuarios que conozcan y hayan personalizado su sistema, como puede suceder en el caso de personas ciegas. Pero es totalmente imposible para aquellos usuarios incapaces de acceder al teclado y al ratón. Es como si a una persona en silla de ruedas se le proporciona una rampa de acceso a un edificio pero, a cambio, se la obliga a acceder al edificio avandonando por unos instantes su silla de ruedas para sentarse en otra nueva y específica para recorrer dicho edificio. Una persona con movilidad en sus brazos puede intentar realizar la operación pero otras personas con menor movilidad serán incapaces de hacerlo de forma autónoma.
  • Estos servicios, como es el caso de Inclusite, suelen dar acceso sólo a un número muy concreto de sitios web y funciones de dichos sitios. Esto provoca que los usuarios de estos servicios no puedan salir de las páginas web compatibles creando un nuevo concepto de gueto digital. Ahora los discapacitados no se quedan en el patio trasero de algunos edificios sino que se les invita a quedarse en edificios diseñados específicamente para ellos.
  • Estos servicios, como sucede en WebAnywhere, no dan acceso completo a las funciones de un sitio web sino que se limitan a ofrecer algunos de ellos que si resultan compatibles con el modelo de uso definido por ellos. Es como si al usuario se le ofreciese una mesa llena de multitud de alimentos pero se le atasen las manos con cuerdas de una determinada medida para que sólo tuviese acceso a algunos de dichos platos.
  • Estos servicios se diseñan para satisfacer, como es el caso de Inclusite, las necesidades de unos perfiles de discapacidad concretos provocando la aparición de barreras de accesibilidad para otros perfiles. Por ejemplo, Inclusite da sólo soporte a personas ciegas que utilicen síntesis de voz pero olvida a aquellas que utilicen dispositivos de lectura braille dejando fuera a personas sordociegas.
  • Estos servicios utilizan tecnologías que no están disponibles para todas las plataformas y usuarios. Por ejemplo, Inclusite actualmente utiliza tecnología Flash por lo que el usuario debe instalar dicho soporte. Si el usuario utiliza un smartphone o un tablet esta operación es imposible pero si utiliza OSX, Linux o Windows se puede encontrar con un instalador poco o nada accesible.

Estos servicios proporcionan un método de acceso más que suficiente para algunas personas ya que satisfacen sus necesidades por completo pero no solucionan las necesidades de todos los usuarios.

Todos estos servicios, actualmente, deben aceptarse como una alternativa opcional para algunas personas con discapacidad. En ningún caso deben presentarse como soluciones completas y reales para conseguir una web accesible.

Un sitio web accesible

Una web accesible es aquella que presenta sus contenidos y funciones utilizando los estándares y siguiendo las pautas de accesibilidad de forma apropiada proporcionando alternativas accesibles para aquellos contenidos y funciones que presenten barreras de acceso para algunos perfiles de discapacidad. Pueden incorporar alguno de los servicios anteriores como valor añadido pero nunca y bajo ningún concepto deben utilizarse como garantía de que el sitio web es accesible tan sólo por incorporar dichos servicios.

Una accesibilidad a la web mal entendida puede crear muchas más barreras de acceso. Debemos apostar por el diseño para todos en lugar del diseño para algunos, lgunos que puedan ver, algunos que puedan usar el teclado, algunos que puedan usar una tecnología o algunos que tengan una determinada discapacidad.

Un sitio web accesible debe ser aquel que presente sus contenidos de forma comprensible proporcionando mecanismos para acceder al significado de dichos contenidos a través del canal más apropiado para cada persona, textos para ciegos, imágenes para sordos, pictogramas y aclaraciones dinámicas para personas mayores y personas con discapacidad cognitiva, uso de teclado o ratón a voluntad del usuario y respeto de los estándares tecnológicos. Pero también debe ofrecer una estructura de navegación que permita una experiencia de usuario satisfactoria.

Esto se puede conseguir incorporando el concepto de accesibilidad al principio del proyecto. No debemos conformarnos con parches, sean estos versiones alternativas, feas y limitadas de un sitio oficial o servicios específicos para acceder a sitios concretos y que son incompatibles con otras soluciones de la accesibilidad.

Las personas con o sin discapacidad no queremos estar en guetos digitales o depender de otras personas para superar barreras de accesibilidad. Internet debe ser de todos, por todos y para todos.