{"id":38463,"date":"2019-10-31T22:23:52","date_gmt":"2019-10-31T19:23:52","guid":{"rendered":"https:\/\/prohoster.info\/blog\/po-napravleniyu-k-dostupnosti\/"},"modified":"2019-10-31T22:23:52","modified_gmt":"2019-10-31T19:23:52","slug":"po-napravleniyu-k-dostupnosti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/po-napravleniyu-k-dostupnosti","title":{"rendered":"Hacia la disponibilidad","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hacia
\n
\nViernes: el final de la jornada laboral. Las malas noticias siempre llegan el viernes al final del d\u00eda laboral.<\/p>\n

Est\u00e1s a punto de salir de la oficina, un 'ding' indica que ha llegado un nuevo correo sobre otra reestructuraci\u00f3n.<\/p>\n

Gracias xxxx, a partir de hoy, reportar\u00e1s a zzzz.
\n\u2026
\nY el equipo de Hugh garantizar\u00e1 la accesibilidad de nuestros productos para personas con discapacidad.<\/i>\n<\/p><\/blockquote>\n

\u00a1Oh, no! \u00bfPor qu\u00e9 merezco esto? \u00bfQuieren que me vaya? Prepararse para un trabajo ingrato y dif\u00edcil y tratar de corregir los errores de otras personas. Esto seguramente ser\u00e1 un fracaso...<\/p>\n

As\u00ed era la accesibilidad hace algunos a\u00f1os. Algunos desafortunados recib\u00edan trabajos de 'limpieza' de la interfaz de usuario para intentar hacerla accesible para personas con discapacidad.
\n<\/a><\/noindex>
\nLo que esto realmente significaba era bastante difuso: probablemente, si pod\u00edas ver el indicador de enfoque y navegar por los campos usando la tecla tab, tener alg\u00fan texto alternativo y un par de descripciones para los campos, eso se consideraba que tu aplicaci\u00f3n era accesible...<\/p>\n

Pero de repente, los 'bugs' comenzaron a multiplicarse a una velocidad alarmante.<\/p>\n

Diferentes lectores de pantalla (en.<\/i> Screen Readers) y navegadores se comportaban de manera completamente diferente.<\/p>\n

Los usuarios se quejaban de que la aplicaci\u00f3n no era usable.<\/p>\n

Una vez que se correg\u00eda un error en un lugar, aparec\u00eda otro en otro lugar.<\/p>\n

Y simplemente cambiar y corregir errores de la interfaz de usuario requer\u00eda un esfuerzo tit\u00e1nico.<\/p>\n

Estuve all\u00ed. Sobreviv\u00ed, pero no 'prosperamos': t\u00e9cnicamente limpiamos mucho, a\u00f1adimos muchas descripciones a los campos, roles y alcanzamos cierto nivel de cumplimiento, pero nadie estaba feliz. Los usuarios segu\u00edan quej\u00e1ndose de que no pod\u00edan navegar en la aplicaci\u00f3n. El gerente segu\u00eda quej\u00e1ndose del flujo constante de errores. Los ingenieros se quejaban de la mala formulaci\u00f3n del proyecto, sin una 'soluci\u00f3n correcta' claramente definida que funcionara en todos los casos.<\/p>\n

En mi camino hacia la comprensi\u00f3n de la accesibilidad, encontr\u00e9 algunos momentos claramente reveladores.
\nQuiz\u00e1 lo primero que comprend\u00ed fue que agregar funcionalidad de accesibilidad sobre un producto existente es complicado. Y a\u00fan m\u00e1s dif\u00edcil es convencer a los gerentes de que \u00a1es incre\u00edblemente complicado! No, no se trata solo de \"agregar algunas etiquetas\" y el interfaz de usuario funcionar\u00e1 perfectamente. No, no es posible terminarlo en tres semanas; incluso tres meses ser\u00e1n insuficientes.
\nMi pr\u00f3ximo momento de verdad lleg\u00f3 cuando vi de primera mano c\u00f3mo los usuarios ciegos realmente utilizan nuestra aplicaci\u00f3n. \u00a1Es TAN diferente a ver mensajes de error!<\/p>\n

Volver\u00e9 a esto una y otra vez, pero casi todas nuestras \"suposiciones\" sobre c\u00f3mo la gente usaba nuestra aplicaci\u00f3n resultaron ser incorrectas.<\/p>\n

Navegar por una interfaz de usuario compleja con teclas Tabulaci\u00f3n\/Shift+Tab<\/code> \u00a1es horrible! Necesitamos algo mejor. Combinaciones de teclas, encabezados.<\/p>\n

\u00bfLa p\u00e9rdida de foco al cambiar la UI no es un gran problema? Pensemos de nuevo: es incre\u00edblemente confuso.<\/p>\n

Continu\u00e9, trabaj\u00e9 un tiempo en diferentes proyectos, y luego comenzamos un nuevo proyecto, con una interfaz de usuario compleja y un claro objetivo de finalmente lograr una accesibilidad adecuada esta vez.<\/p>\n

Entonces, retrocedimos y buscamos c\u00f3mo podr\u00edamos implementar esto de otra manera y tener \u00e9xito, y asegurar que el proceso mismo no fuera aburrido.<\/p>\n

R\u00e1pidamente llegamos a algunas conclusiones:<\/p>\n

    \n
  1. No quer\u00edamos que las personas que desarrollaban la interfaz de usuario se ocuparan de las etiquetas\/rangos aria y, naturalmente, de la estructura HTML de los componentes. Necesit\u00e1bamos proporcionarles los componentes adecuados, en los que la accesibilidad estuviera implementada desde el primer momento.<\/li>\n
  2. Accesibilidad == Usabilidad \u2013 es decir, no solo es una tarea t\u00e9cnica. Necesit\u00e1bamos cambiar todo el proceso de dise\u00f1o y asegurarnos de que la accesibilidad se tome en cuenta y se discuta antes de iniciar el dise\u00f1o de la interfaz de usuario. Ten\u00edamos que pensar desde el principio en c\u00f3mo los usuarios podr\u00edan descubrir cualquier funcionalidad, c\u00f3mo se mover\u00edan y c\u00f3mo funcionar\u00eda el \"clic derecho\" del rat\u00f3n con el teclado. La accesibilidad debe ser una parte integral del proceso de dise\u00f1o; para algunos usuarios, es algo mucho m\u00e1s importante que la apariencia de la aplicaci\u00f3n.<\/li>\n
  3. Desde el principio quer\u00edamos obtener comentarios de personas ciegas y otros usuarios con discapacidades sobre la facilidad de uso de la aplicaci\u00f3n.<\/li>\n
  4. Necesit\u00e1bamos formas realmente efectivas de detectar regresiones en la accesibilidad.<\/li>\n<\/ol>\n

    \nDesde un punto de vista ingenieril, la primera parte sonaba bastante divertida: el desarrollo de la arquitectura y la implementaci\u00f3n de la biblioteca de componentes. Y realmente as\u00ed fue.<\/p>\n

    Al dar un paso atr\u00e1s, considerando ejemplos de ARIA<\/a><\/noindex> Y al considerar esto como un problema de dise\u00f1o, y no como un problema de \"adaptaci\u00f3n\", hemos introducido algunas abstracciones. El componente tiene una 'Estructura' (que consiste en elementos HTML) y un 'Comportamiento' (c\u00f3mo interact\u00faa con el usuario). Por ejemplo, en los fragmentos a continuaci\u00f3n, tenemos una simple lista no ordenada. Al a\u00f1adir 'comportamiento' a la lista, se a\u00f1aden roles correspondientes para que act\u00fae como una lista. Hacemos lo mismo para el men\u00fa.<\/p>\n

    \"Hacia
    \n
    \nDe hecho, aqu\u00ed se a\u00f1aden no solo roles, sino tambi\u00e9n manejadores de eventos para la navegaci\u00f3n a trav\u00e9s del teclado.<\/p>\n

    Esto ya se ve m\u00e1s ordenado. Si pudi\u00e9ramos obtener una separaci\u00f3n clara entre ellos, no importar\u00eda c\u00f3mo se cre\u00f3 la estructura; podr\u00edamos aplicar comportamientos y obtener la accesibilidad correcta.<\/p>\n

    Esto se puede ver en acci\u00f3n en https:\/\/stardust-ui.github.io\/react\/<\/a><\/noindex> \u2013 la biblioteca UX React<\/a><\/noindex>, que se proyecta y se implementa teniendo en cuenta la accesibilidad desde el principio.<\/p>\n

    La segunda parte, cambiar el enfoque y los procesos en torno al dise\u00f1o, me asustaba al principio: modestos ingenieros tratando de impulsar cambios organizativos, no siempre termina bien, pero result\u00f3 ser una de las \u00e1reas m\u00e1s interesantes en las que hicimos una contribuci\u00f3n significativa al proceso. En pocas palabras, ten\u00edamos el siguiente proceso: una nueva funcionalidad era desarrollada por un equipo, despu\u00e9s nuestra grupo de l\u00edderes analizaba\/iteraba la propuesta, y luego, tras su aprobaci\u00f3n, generalmente el dise\u00f1o se entregaba al equipo de ingenieros. En este caso, el equipo de ingenieros 'pose\u00eda' de hecho la funcionalidad de accesibilidad, ya que deb\u00eda resolver todos los problemas asociados.<\/p>\n

    Al principio, fue un trabajo bastante dif\u00edcil explicar que la accesibilidad y la facilidad de uso est\u00e1n intr\u00ednsecamente relacionadas y que esto deb\u00eda abordarse desde la etapa de dise\u00f1o, de lo contrario, se producir\u00edan cambios significativos y redefiniciones de algunos roles. Sin embargo, con el apoyo de la direcci\u00f3n y los actores clave, conseguimos comunicar esta idea y ponerla en marcha para que los dise\u00f1os se sometieran a pruebas de accesibilidad y usabilidad antes de ser presentados a la direcci\u00f3n.<\/p>\n

    Y estos comentarios fueron extremadamente valiosos para todos; fue fant\u00e1stico, como un ejercicio de intercambio de conocimientos\/informaci\u00f3n sobre c\u00f3mo los usuarios interact\u00faan con las aplicaciones web, identificamos numerosas \u00e1reas problem\u00e1ticas en la interfaz de usuario antes de que se construyeran. Actualmente, los equipos de desarrollo tienen especificaciones mucho mejores, no solo de los aspectos visuales, sino tambi\u00e9n de los aspectos conductuales del dise\u00f1o. Las discusiones reales son di\u00e1logos divertidos, en\u00e9rgicos y apasionados sobre aspectos t\u00e9cnicos y las interacciones.<\/p>\n

    Podr\u00edamos haber hecho este trabajo a\u00fan mejor si en estas (o futuras) reuniones hubieran participado usuarios ciegos y personas con discapacidades; fue complicado de organizar, pero ahora realmente estamos colaborando tanto con organizaciones locales de personas ciegas como con empresas que proporcionan pruebas externas para verificar el flujo de trabajo en las primeras etapas de desarrollo, tanto a nivel de componentes como a nivel de flujo de trabajo.<\/p>\n

    Ahora, los ingenieros tienen especificaciones bastante detalladas y componentes accesibles que pueden utilizar para implementar y verificar el flujo de trabajo. En parte, la experiencia nos ha ense\u00f1ado lo que constantemente pasamos por alto: c\u00f3mo podemos detener la regresi\u00f3n. De manera similar, las personas pueden utilizar pruebas de integraci\u00f3n o pruebas de extremo a extremo para verificar la funcionalidad que necesitamos para detectar cambios en las interacciones y flujos de trabajo, tanto visuales como conductuales.<\/p>\n

    La definici\u00f3n de la regresi\u00f3n visual es una tarea bastante espec\u00edfica, se puede agregar muy poco a este proceso, excepto, quiz\u00e1s, verificar si el foco es visible al navegar con el teclado. Son m\u00e1s interesantes dos tecnolog\u00edas relativamente nuevas para trabajar con la accesibilidad.<\/p>\n

      \n
    1. Accessibility Insights<\/a><\/noindex> es un conjunto de herramientas que pueden ejecutarse tanto en el navegador como dentro del ciclo de compilaci\u00f3n\/pruebas, para identificar problemas.<\/li>\n
    2. Verificar el correcto funcionamiento de los lectores de pantalla fue una tarea especialmente dif\u00edcil. Con la introducci\u00f3n del acceso a Accessibility DOM<\/b>, finalmente obtuvimos la capacidad de tomar instant\u00e1neas de la aplicaci\u00f3n desde el punto de vista de la accesibilidad, muy similar a c\u00f3mo lo hacemos para las pruebas visuales, y verificarlas para detectar regresiones.<\/li>\n<\/ol>\n

      \nAs\u00ed que, en la segunda parte de la historia, hemos pasado de editar el c\u00f3digo HTML a trabajar en un nivel m\u00e1s alto de abstracci\u00f3n, cambiando el proceso de desarrollo del dise\u00f1o e introduciendo pruebas rigurosas. Nuevos procesos, nuevas tecnolog\u00edas y nuevos niveles de abstracci\u00f3n han cambiado por completo nuestra comprensi\u00f3n de la accesibilidad y de lo que significa trabajar en este campo.
      \nPero esto es solo el comienzo.<\/p>\n

      La siguiente \u00abcomprensi\u00f3n\u00bb es que los usuarios ciegos impulsan tecnolog\u00edas innovadoras: ellos son quienes m\u00e1s se benefician, no solo de los cambios que hemos descrito anteriormente, sino tambi\u00e9n de que nuevos enfoques e ideas se hacen posibles con la ayuda de ML\/AI. Por ejemplo, la tecnolog\u00eda Immersive Reader permite a los usuarios entender el texto de manera m\u00e1s simple y clara. Puede leerse en voz alta, la estructura de las oraciones se divide gramaticalmente e incluso se representan gr\u00e1ficamente los significados de las palabras. Esto no encaja en la antigua comprensi\u00f3n de \u00abhacerlo accesible\u00bb: es una funci\u00f3n de usabilidad que ayudar\u00e1 a todos.<\/p>\n

      Con ML\/AI surgen formas completamente nuevas de interactuar y trabajar, y estamos contentos de ser parte de las siguientes etapas de este camino innovador. La innovaci\u00f3n se basa en un cambio de mentalidad: la humanidad ha existido durante milenios, las m\u00e1quinas durante cientos de a\u00f1os, los sitios web durante unas pocas d\u00e9cadas, y los tel\u00e9fonos inteligentes incluso menos; la tecnolog\u00eda debe adaptarse a las personas, y no al rev\u00e9s.<\/p>\n

      P.D. El art\u00edculo ha sido traducido con algunas desviaciones del original. Siendo coautor de este art\u00edculo, he acordado estas desviaciones con Hugh.<\/p>\n

      Solo los usuarios registrados pueden participar en la encuesta. Inicie sesi\u00f3n<\/a><\/noindex>, por favor.<\/p>\n

      \u00bfPresta atenci\u00f3n a la accesibilidad de sus aplicaciones?<\/h2>\n