Dialogurile modale continua sa fie componente UI deranjante pe intregul web. Lasand la o parte faptul ca sunt adesea utilizate gresit si arunca utilizatorii intr-o maniera care intrerupe sarcina lor curenta (rugandu-ma sa ma inscriu la buletinul tau, in timp ce ma aflu in mijlocul citirii unui articol, nu este misto), chiar folosit in mod corespunzator adesea, modalitatile au lipsa de considerente pentru accesibilitate.

Cu toate ca dialogul modal slab UX este inca comun, asta nu inseamna ca nu au existat pasi pentru a imbunatati aceste experiente. Efectuand o cautare pentru „dialog modal accesibil”, veti gasi ca multi dezvoltatori (eu insumi) au scris despre si au lansat scripturi de dialog personalizate gata de productie, iar constientizarea elementului de dialog a crescut. Dar pentru a obtine cu adevarat un control asupra starii actuale a accesibilitatii dialogului modal, ar trebui sa fim constienti de problemele actuale cu care se confrunta dialogurile modale atat native cat si personalizate (ARIA).

Elementul de dialog nativ, care este retinerea?

Am mentionat elementul de dialog intr-un articol pe care l-am scris pentru Smashing Magazine (2014), precum si in postarea mea de urmarire despre scriptul meu de dialog modal (2016). In momentul scrierii acestor articole, dialogul fusese cel putin partial implementat in Chrome si Firefox in spatele unui steag.

Au trecut aproape 4 ani (5ish daca reveniti la cea mai timpurie implementare a elementului de dialog in Chrome Canary), dar adoptarea elementului inca lipseste.

In ceea ce priveste o rundown rapid al diferitelor browsere:

  • Chrome 37+ si alte browsere bazate pe clipuri accepta elementul de dialog (de exemplu: Opera 24+, Opera Mobile 46, Android / Chrome Android 67).
  • Firefox (53+) necesita inca activarea manuala a dialogului.
  • Safari (macO-uri si iOS) nu accepta in prezent dialogul si au o solicitare de includere care dateaza din 2012
  • Microsoft Edge a marcat-o ca fiind „luata in considerare”.

    Array

  • In cele din urma, Internet Explorer, nu va suporta niciodata dialogul.

Desi implementarea browserului nu a evoluat prea mult in ultimii ani, au existat unele progrese interesante cu ARIA si metode suplimentare pentru a crea experiente mai bune pentru dialogurile modale personalizate.

O scurta recapitulare a comportamentului de dialog modal prevazut

Dar inainte de a intra in unele dintre piesele mai noi, sa facem o recapitulare rapida asupra a ceea ce ar trebui sa fie de asteptat pentru un dialog modal accesibil.

  1. Cand este activat un dialog modal, focalizarea trebuie sa fie mutata in dialog. In cazul in care focalizarea este plasata initial poate varia in functie de continutul dialogului, dar focalizarea dialogului in sine poate oferi o experienta de utilizator previzibila in mod constant.
  2. Un dialog modal trebuie sa aiba un nume accesibil, sa se anunte ca dialog si ar trebui sa ofere metode standard pentru utilizator sa il inchida. de exemplu printr-un buton de inchidere, folosind tasta esc, faceti clic pe mouse sau atingeti in afara dialogului si asigurati-va ca F6 va continua sa permita utilizatorului sa mute focalizarea tastaturii pe bara de adrese a browserului.
  3. In timp ce dialogul modal este activ, continutul ascuns de dialogul modal ar trebui sa fie inaccesibil tuturor utilizatorilor. Acest lucru inseamna ca tasta TAB si cursorul virtual al cititorului de ecran (tastele sageata) nu ar trebui sa fie lasate sa paraseasca dialogul modal si sa traverseze continutul in afara dialogului.
  4. Cand un dialog modal este inchis, focalizarea trebuie sa revina la controlul care a activat initial dialogul. Acest lucru va permite utilizatorilor tastaturii si cititorilor de ecran sa continue sa analizeze documentul de unde au plecat.

    Daca un dialog modal nu a fost initiat printr-o actiune de utilizator (boo) intentionata sau elementul care a activat dialogul nu mai este in DOM, atunci inchiderea dialogului ar trebui sa plaseze accentul utilizatorului intr-o locatie logica. de exemplu, daca s-a deschis un dialog pe incarcarea paginii, atunci se poate pune accent pe corp sau pe elementul principal. Daca declansatorul ar fi fost eliminat din DOM, atunci plasarea focalizarii este cat mai aproape de locatia DOM a declansatorului ar fi ideala.

OK, acum ca asta e patrat, sa revenim la noua fierbinte …

Actualizari la ARIA si folosire inerta

De la lansarea scriptului meu anterior, atributul aria-modal a fost introdus si care permite „dialogul” ca valoare pentru aria-haspopup au fost adaugate la ARIA 1.1. Aceste adaugiri ar fi un ajutor urias pentru ca dialogurile modale sa fie mai accesibile, daca nu pentru urmatoarele operatiuni de implementare:

Aria-modal

aria-modal este menita sa indice cititorilor de ecran ca numai continutul continut intr-un dialog cu aria-modal = „adevarat” ar trebui sa fie accesibil utilizatorului.

Acest atribut este o afacere destul de mare si un plus foarte binevenit la specificatii. Atributul aria-modal va ajuta la ingrijirea unuia dintre cele mai mari obstacole cu dialoguri modale personalizate; pastrarea unui cititor de ecran in dialogul activ, deoarece crearea unei capcane JavaScript pentru focalizarea standard a tastaturii nu este suficienta pentru a reduce un cursor virtual ratacitor.

Testand pe diferite perechi de cititor de ecran si browser, acest atribut functioneaza in mare masura asa cum este de asteptat atunci cand valoarea este setata pe adevarat, cu o exceptie nefericita. Safari + VoiceOver atat pe macOS, cat si pe iOS au probleme legate de transformarea continutului static intr-un dialog modal inaccesibil (vezi bug WebKit inregistrat).

In plus, aria-modal = „false” nu functioneaza asa cum este de asteptat in unele legaturi de browser si cititor de ecran. Aceasta problema este mult mai putin grava, intrucat pur si simplu s-ar putea pur si simplu sa nu se foloseasca aria-modal = „fals”, deoarece setarea la false ar trebui sa transmita aceleasi informatii ca si cum atributul nu ar fi fost deloc prezent.

Aria-haspopup

In momentul scrierii acestui lucru, majoritatea cititorilor de ecran nu accepta inca aria-haspopup = „dialog”. Adesea, ei nu vor face nicio mentiune despre asocierea unui control cu ​​un dialog, iar unii vor reveni la anuntarea controlului ca la deschiderea unui meniu (deoarece originile haspopup-ului erau asociate cu meniurile), ceea ce ar duce la o experienta neasteptata pentru utilizatori.

Pana cand suportul pentru valoarea dialogului are o implementare mai buna, este cel mai bine sa nu utilizati aria-haspopup pe elementul care deschide dialogul modal. Intre timp, s-ar putea adauga un fel de indicator vizual si / sau ascuns vizual (pictograma si / sau text) pentru a informa utilizatorii ca se va deschide un dialog modal.

inert imperecheat cu aria-ascuns = „adevarat”

In cazul in care aria-modala mai are cateva kink-uri pentru a lucra cu WebKit, suportul de polifilare inerta imbunatatit (Google inert sau WICG inert) poate fi asociat cu aria-ascuns = „adevarat” pe elementele din afara unui dialog modal pentru a asigura focalizarea si ecranul tastaturii cursoarele virtuale ale cititorului vor avea mai putin sanse sa interactioneze cu continutul ascuns printr-un dialog modal activ.

De exemplu, un utilizator ar trebui sa poata lasa documentul curent pentru a accesa cromul browserului (de exemplu, prin utilizarea tastei F6 pentru a muta focalizarea la bara de adrese a browserului). Atunci cand acest utilizator incearca sa reintre in document, inert si aria-ascuns = „adevarat” va impiedica focalizarea lor sa aterizeze pe elemente ascunse de dialogul modal si sa asigure singurul loc in care se va concentra focalizarea utilizatorului, va fi la continutul dialogului.

Adaugarea aria-ascuns = „adevarat” la elementele din afara dialogului modal activ asigura ca elementele care nu se afla in dialogul modal activ nu vor fi afisate daca un utilizator deschide o lista de elemente de citire a ecranului (titluri, controale de formular, repere etc.) in document. Acesta ar fi ceva de care ar avea grija aria-modal = „adevarat”, in asteptarea rezolvarii problemelor actuale cu VoiceOver.

In cele din urma, utilizarea de aria-ascuns = „adevarat” si inert impreuna anuleaza capacitatea utilizatorilor VoiceOver de a scapa de un dialog modal atunci cand citesc linie cu linie (prin utilizarea tastelor sageata sus si jos, fara cheia modificatorului VO). Majoritatea dialogurilor modale personalizate pe care le-am vazut in salbaticie nu tin cont de aceasta navigare de tip.

Trebuie sa aveti grija suplimentara de Gotchas

Dincolo de problemele mentionate mai sus, cu aria-modal si aria-haspopup = „dialog”, exista alte cateva lucruri pe care le-am descoperit in testarea dialogurilor modale care trebuie notate:

Nu setati dialoguri care sa fie afisate: nimeni in mod implicit.

Exista o problema cu iOS Safari + VoiceOver in cazul in care, daca un element este initial setat sa fie afisat: niciunul;, chiar si atunci cand este actualizat pentru a afisa: bloc; VoiceOver nu va muta focalizarea catre element, chiar daca focalizarea este setata programatic. Am gasit sa ocolesc aceasta eroare, CSS pentru dialoguri ar trebui sa foloseasca in schimb vizibilitate: ascunsa; pentru starea lor inactiva si vizibilitate: vizibile; cand sunt afisate. Intrucat un dialog trebuie setat in pozitie: fix; sau in unele situatii absolute, efectul secundar comun al vizibilitatii: elementele ascunse care inca ocupa spatiul fizic in ordinea DOM, vor fi evitate. Suplimentar util, avand un dialog de modalitate setat la vizibilitate: ascuns, mai degraba decat afisare: nimic nu inseamna ca va fi posibila utilizarea tranzitiilor CSS.

Daca utilizati atributul ascuns pentru a ascunde dialogurile in starea lor implicita (ceea ce va asigura ca daca CSS este vreodata blocat, dialogurile nu vor deveni vizibile – utile pentru modul de citire al unui browser), atributul ascuns poate avea CSS-ul sau modificat pentru a contabiliza eroarea mentionata mai sus:

[rol = „dialog”] [ascuns] {display: bloc; vizibilitate: ascuns; }

afisare: bloc anuleaza afisarea implicita a atributului ascuns: niciun CSS, in timp ce vizibilitatea: ascunsa ascunde dialogul pentru starea sa inactiva.

Anunturi NVDA prea excesive

La testarea cu NVDA, setarea focalizarii pe un element care nu poate fi focalizat (de exemplu, o rubrica cu tabindex = „- 1”) poate duce la anuntarea redusa a elementului focalizat si a continutului dialogului de mai multe ori.

Deoarece focalizarea pe primul element focalizabil al unui dialog modal poate duce la puncte de pornire inconsistente si chiar nefavorabile pentru un utilizator cititor de ecran (de exemplu, daca primul element focalizabil este butonul de inchidere de la sfarsitul unui dialog cu continut greu, sau o intrare la punctul intermediar al continutului unui dialog in care continutul anterior il putea lipsi) cel mai bine este sa focalizati elementul de dialog in sine si sa permiteti utilizatorului sa navigheze dialogul in ordine secventiala, asa cum ar fi un document standard.

IE11 are nevoie ca primul element al dialogului modal sa fie titlul sau

Primul element al unui dialog modal trebuie sa fie titlul sau (care ofera numele accesibil). Aceasta cerinta consta in compensarea specifica a Internet Explorer 11 + JAWS. Cu aceasta imperechere, setarea focalizarii catre elementul de dialog in sine va anunta numele accesibil al dialogului, rolul de dialog, apoi JAWS va anunta din nou numele accesibil al dialogului si rolul primului element copil al dialogului.

De exemplu, daca rubrica de dialog furnizeaza numele accesibil pentru dialog, atunci JAWS + IE11 va anunta „text de titlu, dialog. titlu text, nivel de titlu # ”. Cu toate acestea, daca primul copil este un alt element care nu se potriveste cu numele accesibil al dialogului, cum ar fi un buton cu textul „inchide”, acesta va fi anuntat ca: „text de titlu, dialog. titlu, buton ”

NVDA nu va anunta rolul de dialog atunci cand dialogul in sine primeste focalizarea

Testand cu NVDA, rolul de dialog nu va fi anuntat atunci cand focalizarea este setata la elementul de dialog in sine. De exemplu, in NVDA + IE11, va anunta pur si simplu numele accesibil al dialogului si nimic mai mult. In mai multe perechi de browser standard precum Firefox sau Chrome, numele accesibil al dialogului va fi anuntat, apoi continutul dialogului va incepe sa fie anuntat, fara a mentiona vreodata rolul de dialog.

Inveliti

Pana cand dialogurile native vor fi omniprezente in toate browserele principale, vom continua sa avem nevoie de ARIA pentru a ne ajuta sa ne asiguram ca dialogurile modale sunt accesibile. Dar, retineti, unele functii ARIA sunt, de asemenea, relativ noi si necesita, de asemenea, ceva timp pentru a obtine suport complet atat cu browserele, cat si cu cititorii de ecran.

Pana cand fie dialogurile native sau proprietatile ARIA ajung la suport complet, este responsabilitatea noastra sa continuam sa testam nu numai dialogurile noastre modale, ci orice componenta pe care o construim, pentru a ne asigura (si continua sa ofere) o experienta accesibila pentru utilizator.

Navigatoarele, cititorii de ecran si chiar ghidul / specificatiile de autorizare pot necesita modificari, chiar si cele de rupere, in timp. Astfel, are sens pentru noi sa analizam aceste modele din nou si din nou si sa ne asiguram ca functioneaza in continuare asa cum au fost conturate si ca functioneaza cel mai bine pentru toti utilizatorii.

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR