O venres remata a xornada laboral. As malas noticias sempre chegan ao final da xornada laboral do venres.
Está a piques de saír da oficina, acaba de chegar no correo unha nova carta sobre outra reorganización.
Grazas xxxx, yyy dende hoxe denunciarás zzzz
...
E o equipo de Hugh asegurarase que os nosos produtos sexan accesibles para persoas con discapacidade.
Ai non! Por que merecía isto? Queren que me marche? Prepárate para un traballo duro ingrato e intenta corrixir os erros dos demais. Definitivamente isto é un fracaso...
Esta era a dispoñibilidade hai uns anos. Algunhas pobres almas recibiron o traballo de "limpar" a IU para tentar facelo accesible ás persoas con discapacidade.
O que isto significaba en realidade era bastante vago: presumiblemente, se puideses ver un indicador de foco e unha pestana a través dos campos, ter algún texto alternativo e un par de descricións de campos, consideraríase que a túa aplicación é accesible...
Pero de súpeto os "bichos" comezaron a multiplicarse á velocidade dunha avalancha.
Varios lectores de pantalla (inglés Lectores de pantalla) e os navegadores comportáronse de forma completamente diferente.
Os usuarios queixáronse de que a aplicación non se pode utilizar.
En canto se corrixiu un erro nun lugar, outro aparecía noutro.
E simplemente cambiar e corrixir os erros da interface de usuario requiriu esforzos herculinos.
Estaba alí. Sobrevivín, pero non o "conseguimos": tecnicamente limpamos moito, engadimos moitas descricións de campo, roles e conseguimos algún nivel de cumprimento, pero ninguén estaba contento. Os usuarios aínda queixáronse de que non podían navegar pola aplicación. O director aínda se queixaba da constante corrente de erros. Os enxeñeiros queixáronse de que o problema se plantexou incorrectamente, sen unha solución "correcta" claramente definida que funcionase en todos os casos.
Houbo algúns momentos decididamente reveladores ao longo da miña viaxe para comprender a accesibilidade.
Quizais o primeiro foi entender que engadir funcionalidades de accesibilidade a un produto acabado era difícil. E aínda é máis difícil convencer aos xestores de que é incriblemente difícil! Non, non é só "engadir algunhas etiquetas" e a IU funcionará ben. Non, isto non se pode completar en tres semanas nin sequera tres meses serán suficientes.
O meu seguinte momento de verdade chegou cando vin de primeira man como usaban realmente a nosa aplicación os usuarios cegos. Isto é moi diferente de mirar as mensaxes de erro.
Volverei sobre isto unha e outra vez, pero case todas as nosas "suposicións" sobre como a xente utilizaba a nosa aplicación eran incorrectas.
Navegación por unha interface de usuario complexa usando teclas Tab/Shift+Tab - isto é unha merda! Necesitamos algo mellor. Atallos de teclado, cabeceiras.
Perder o foco ao cambiar a IU non é un gran problema, non é? Pensemos de novo: isto é incriblemente confuso.
Seguín, traballei en diferentes proxectos durante un tempo, e despois comezamos un novo proxecto, cunha interface de usuario complexa e unha instalación clara, para por fin conseguir a accesibilidade esta vez.
Entón, demos un paso atrás e miramos como podíamos implementar isto de forma diferente e ter éxito, e facer que o proceso fose menos aburrido.
Moi rápido chegamos a algunhas conclusións:
- Non queriamos que as persoas que desenvolven a interface de usuario se metan coas etiquetas/roles de aria e, por suposto, coa estrutura HTML dos compoñentes. Necesitabamos proporcionarlles os compoñentes axeitados que creasen accesibilidade desde a caixa.
- Accesibilidade == Facilidade de uso, é dicir. Este non é só un reto técnico. Necesitabamos cambiar todo o proceso de deseño e asegurarnos de que a accesibilidade se tivera en conta e se discutise antes de comezar o deseño da IU. Debes pensar cedo en como descubrirán os usuarios calquera funcionalidade, como navegarán e como funcionará ao facer clic co botón dereito do rato no teclado. A accesibilidade debería ser parte integrante do proceso de deseño; para algúns usuarios, é moito máis que a aparencia da aplicación.
- Dende o principio, queriamos recibir comentarios de usuarios cegos e outros con discapacidade sobre a facilidade de uso da aplicación.
- Necesitabamos formas moi boas de detectar regresións de accesibilidade.
Ben, dende o punto de vista da enxeñaría, a primeira parte soou bastante divertida: desenvolver unha arquitectura e implementar unha biblioteca de compoñentes. E efectivamente foi así.
Dar un paso atrás, mirar e ao pensar nisto como un problema de deseño e non como un problema de "encaixamento", introducimos algunhas abstraccións. Un compoñente ten unha 'Estrutura' (consta de elementos HTML) e un 'Comportamento' (como interactúa co usuario). Por exemplo, nos fragmentos de abaixo temos unha lista sinxela sen ordenar. Ao engadir "comportamentos" engádense os roles correspondentes á lista para que actúe como unha lista. Facemos o mesmo co menú.
De feito, aquí non só se engaden roles, senón tamén controladores de eventos para a navegación por teclado.
Isto parece máis ordenado. Se puidésemos conseguir unha separación clara entre eles, non importaría como se crease a estrutura, poderiamos aplicarlle comportamentos e conseguir a accesibilidade correcta.
Podes ver isto en acción en - Biblioteca UX , que está deseñado e implementado pensando na accesibilidade desde o principio.
A segunda parte: cambiar o enfoque e os procesos en torno ao deseño inicialmente asustoume: os enxeñeiros humildes que intentan impulsar o cambio organizativo non sempre acaban ben, pero resultou ser unha das áreas máis interesantes nas que fixemos contribucións significativas ao proceso. . En poucas palabras, o noso proceso foi o seguinte: unha nova funcionalidade sería desenvolvida por un equipo, despois o noso equipo de liderado revisaría/iteraría a proposta e despois, unha vez aprobada, o deseño normalmente sería entregado ao equipo de enxeñería. Neste caso, o equipo de enxeñería era "propietario" da funcionalidade de accesibilidade porque era a súa responsabilidade solucionar calquera problema asociado a ela.
Ao principio, foi un traballo bastante difícil explicar que accesibilidade e usabilidade están indisolublemente ligadas e que iso tiña que facerse na fase de deseño, se non, provocaría grandes cambios e redefinicións dalgúns roles. Non obstante, co apoio da dirección e dos principais actores, tomamos a idea e poñémola en marcha para que os deseños fosen probados para a accesibilidade e usabilidade antes de ser presentados á dirección.
E este feedback foi moi valioso para todos: foi fantástico como exercicio de intercambio de coñecemento/comunicación sobre como interactúan os usuarios coas aplicacións web, identificamos numerosas áreas problemáticas da IU antes de que se creasen, os equipos de desenvolvemento agora teñen especificacións moito mellores de non. só aspectos visuais, pero tamén de comportamento do deseño. As discusións reais son discusións divertidas, enérxicas e apaixonadas sobre aspectos técnicos e interaccións.
Poderíamos facelo aínda mellor se tivésemos usuarios cegos e discapacitados nestas reunións (ou posteriores); isto era difícil de organizar, pero agora traballamos con organizacións locais de cegos e empresas , que proporcionan probas externas para verificar o fluxo de execución no inicio. desenvolvemento, tanto a nivel de compoñente como de fluxo de execución.
Os enxeñeiros teñen agora especificacións bastante detalladas, compoñentes dispoñibles que poden usar para implementar e unha forma de validar o fluxo de execución. Parte do que a experiencia nos ensinou é o que nos botamos de menos: como podemos deter a regresión. Así mesmo, as persoas poden utilizar probas de integración ou de extremo a extremo para probar a funcionalidade, que necesitamos para detectar cambios nas interaccións e nos fluxos de execución, tanto visuais como de comportamento.
Determinar a regresión visual é unha tarefa bastante definida, hai moi pouco que se pode engadir ao proceso, ademais de comprobar se o foco é visible ao navegar co teclado. Máis interesantes son dúas tecnoloxías relativamente novas para traballar a accesibilidade.
- é un conxunto de ferramentas que se poden executar tanto no navegador como como parte do ciclo de compilación/proba para identificar problemas.
- Verificar que os lectores de pantalla funcionan correctamente foi unha tarefa especialmente desafiante. Coa introdución do acceso a Accesibilidade DOM, por fin podemos tomar instantáneas de accesibilidade da aplicación, ao igual que facemos coas probas visuais, e probalas para a regresión.
Entón, na segunda parte da historia, pasamos da edición de código HTML a traballar nun nivel máis alto de abstracción, cambiamos o proceso de desenvolvemento do deseño e introducimos probas exhaustivas. Os novos procesos, as novas tecnoloxías e os novos niveis de abstracción cambiaron por completo o panorama da accesibilidade e o que significa traballar neste espazo.
Pero isto é só o comezo.
O seguinte "comprensión" é que os usuarios cegos impulsan tecnoloxía de punta: son os que máis se benefician non só dos cambios que describimos anteriormente, senón tamén de que o ML/AI posibilita novos enfoques e ideas. Por exemplo, a tecnoloxía Immersive Reader permite aos usuarios presentar o texto con máis facilidade e claridade. Pódese ler en voz alta, a estrutura da frase desgrázase gramaticalmente e mesmo os significados das palabras móstranse gráficamente. Isto non encaixa en absoluto coa antiga mentalidade de "facelo accesible": é unha función de usabilidade que axudará a todos.
ML/AI está a permitir formas totalmente novas de interactuar e traballar, e estamos encantados de formar parte das próximas etapas desta viaxe de vangarda. A innovación está impulsada por un cambio de pensamento: a humanidade existe desde hai milenios, as máquinas durante centos de anos, os sitios web durante varias décadas e os teléfonos intelixentes aínda menos, a tecnoloxía debe adaptarse ás persoas, e non á inversa.
PS O artigo foi traducido con pequenas desviacións do orixinal. Como coautor deste artigo, coincidín con Hugh nestas digresións.
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Prestas atención á accesibilidade das túas aplicacións?
-
Si
-
Non
-
Esta é a primeira vez que escoito falar da accesibilidade das aplicacións.
Votaron 17 usuarios. 5 usuarios abstivéronse.
Fonte: www.habr.com