Iššokantys pranešimai: Prieinamų, vartotojui draugiškų laikinųjų pranešimų kūrimas

Sparčiai besivystančiame skaitmeninių sąsajų pasaulyje komunikacija tarp sistemos ir jos vartotojo yra nepaprastai svarbi. Mes pasikliaujame vizualinėmis užuominomis, kad suprastume savo veiksmų rezultatus. Vienas iš labiausiai paplitusių UI modelių šiam grįžtamajam ryšiui yra „toast“ pranešimas – mažas, ne modalinis iššokantis langas, teikiantis laikiną informaciją. Nesvarbu, ar tai patvirtinimas „Žinutė išsiųsta“, pranešimas „Failas įkeltas“, ar įspėjimas „Praradote ryšį“, iššokantys pranešimai yra subtilūs vartotojo grįžtamojo ryšio darbiniai arkliai.

Tačiau jų laikinas ir subtilus pobūdis yra dviašmenis kardas. Nors kai kuriems vartotojams jie yra minimaliai įkyrūs, būtent ši savybė dažnai juos paverčia visiškai neprieinamais kitiems, ypač tiems, kurie pasikliauja pagalbinėmis technologijomis, pavyzdžiui, ekrano skaitytuvais. Neprieinamas iššokantis pranešimas yra ne tik menkas nepatogumas; tai tyli nesėkmė, paliekanti vartotojus neaiškume ir nusivylusius. Vartotojas, kuris negali suvokti pranešimo „Nustatymai išsaugoti“, gali bandyti juos išsaugoti dar kartą arba tiesiog išeiti iš programos, nebūdamas tikras, ar jo pakeitimai buvo sėkmingi.

Šis išsamus vadovas skirtas programuotojams, UX/UI dizaineriams ir produktų vadovams, norintiems kurti tikrai įtraukius skaitmeninius produktus. Mes išnagrinėsime iššokančių pranešimų prieinamumo iššūkius, gilinsimės į techninius sprendimus naudojant ARIA (Accessible Rich Internet Applications) ir apibrėšime dizaino geriausias praktikas, kurios naudingos visiems. Išmokime, kaip padaryti šiuos laikinuosius pranešimus nuolatine prieinamos vartotojo patirties dalimi.

Iššokančių pranešimų prieinamumo iššūkis

Norėdami suprasti sprendimą, pirmiausia turime giliai suprasti problemą. Tradiciniai iššokantys pranešimai dažnai neatitinka kelių prieinamumo reikalavimų dėl savo pagrindinių dizaino principų.

1. Jie yra trumpalaikiai ir priklauso nuo laiko

Pagrindinė iššokančio pranešimo savybė yra jo trumpalaikis egzistavimas. Jis pasirodo kelioms sekundėms ir tada grakščiai išnyksta. Matančiam vartotojui tai paprastai yra pakankamai laiko perskaityti pranešimą. Tačiau ekrano skaitytuvo vartotojui tai yra didelė kliūtis. Ekrano skaitytuvas skelbia turinį nuosekliai. Jei vartotojas yra susitelkęs į formos laukelį ar klauso kito skaitomo turinio, pranešimas gali pasirodyti ir išnykti anksčiau, nei ekrano skaitytuvas jį pasieks. Tai sukuria informacijos spragą, pažeidžiančią pagrindinį prieinamumo principą: informacija turi būti suvokiama.

2. Jie negauna fokuso

Iššokantys pranešimai sukurti taip, kad būtų neįkyrūs. Jie sąmoningai neatima fokuso nuo dabartinės vartotojo užduoties. Matantis vartotojas gali toliau rašyti teksto laukelyje, kol pasirodo pranešimas „Juodraštis išsaugotas“. Tačiau vartotojams, kurie naudojasi tik klaviatūra, ir ekrano skaitytuvų vartotojams, fokusas yra pagrindinis naršymo ir sąveikos metodas. Kadangi iššokantis pranešimas niekada nepatenka į fokuso eilę, jis yra nematomas linijiniam naršymo keliui. Vartotojas turėtų rankiniu būdu ieškoti visame puslapyje pranešimo, apie kurio egzistavimą jis net nežino.

3. Jie atsiranda be konteksto

Iššokantys pranešimai dažnai atsiranda atskiroje ekrano srityje, pavyzdžiui, viršutiniame dešiniajame ar apatiniame kairiajame kampe, toli nuo elemento, kuris juos sukėlė (pvz., „Išsaugoti“ mygtuko formos viduryje). Šį erdvinį atskyrimą lengvai įveikia rega, tačiau jis pažeidžia loginę seką ekrano skaitytuvams. Pranešimas, jei jis apskritai įvyksta, gali atrodyti atsitiktinis ir nesusijęs su paskutiniu vartotojo veiksmu, sukeldamas painiavą.

Sąsaja su WCAG: keturi prieinamumo ramsčiai

Žiniatinklio turinio prieinamumo gairės (WCAG) remiasi keturiais principais. Neprieinami iššokantys pranešimai pažeidžia kelis iš jų.

• Suvokiamas: Jei vartotojas su regos negalia negali suvokti pranešimo, nes jo ekrano skaitytuvas jo nepaskelbia, arba jei vartotojas su kognityvine negalia neturi pakankamai laiko jį perskaityti, informacija nėra suvokiama. Tai susiję su WCAG sėkmės kriterijumi 2.2.1 Laiko reguliavimas, kuris reikalauja, kad vartotojams būtų suteikta pakankamai laiko perskaityti ir naudoti turinį.
• Valdomas: Jei iššokančiame pranešime yra veiksmas, pavyzdžiui, „Uždaryti“ mygtukas, jis turi būti fokusuojamas ir valdomas klaviatūra. Net jei jis yra informacinis, vartotojas turėtų turėti galimybę jį valdyti, pavyzdžiui, rankiniu būdu jį atmesti.
• Suprantamas: Iššokančio pranešimo turinys turi būti aiškus ir glaustas. Jei ekrano skaitytuvas paskelbia pranešimą be konteksto, jo prasmė gali būti nesuprantama. Tai taip pat susiję su WCAG 4.1.2 Pavadinimas, rolė, vertė, kuris reikalauja, kad UI komponento paskirtis būtų programiškai nustatoma.
• Patikimas: Pranešimas turi būti įgyvendintas naudojant standartines žiniatinklio technologijas taip, kad būtų suderinamas su dabartiniais ir būsimais vartotojų agentais, įskaitant pagalbines technologijas. Individualiai sukurtas iššokantis pranešimas, ignoruojantis ARIA standartus, nėra patikimas.

Techninis sprendimas: ARIA „Live Regions“ į pagalbą

Raktas į prieinamų iššokančių pranešimų kūrimą slypi galingoje ARIA specifikacijos dalyje: „live regions“ (gyvosiose srityse). ARIA „live region“ yra puslapio elementas, kurį jūs pažymite kaip „gyvą“. Tai nurodo pagalbinėms technologijoms stebėti šį elementą dėl bet kokių jo turinio pakeitimų ir pranešti apie tuos pakeitimus vartotojui, neperkeliant jo fokuso.

Apgaubdami savo iššokančius pranešimus „live region“ sritimi, galime užtikrinti, kad jų turinys bus paskelbtas ekrano skaitytuvų, kai tik jis pasirodys, nepriklausomai nuo to, kur yra vartotojo fokusas.

Pagrindiniai ARIA atributai iššokantiems pranešimams

Trys pagrindiniai atributai veikia kartu, kad sukurtų veiksmingą „live region“ iššokantiems pranešimams:

1. Atributas role

Atributas `role` apibrėžia semantinę elemento paskirtį. Kalbant apie „live regions“, reikia atsižvelgti į tris pagrindines roles:

• role="status": Tai dažniausiai naudojama ir tinkamiausia rolė iššokantiems pranešimams. Ji naudojama informaciniams pranešimams, kurie yra svarbūs, bet ne skubūs. Ji atitinka aria-live="polite", o tai reiškia, kad ekrano skaitytuvas palauks neaktyvumo momento (pavyzdžiui, sakinio pabaigos) prieš paskelbdamas pranešimą, užtikrindamas, kad vartotojas nebūtų pertrauktas viduryje užduoties. Naudokite tai patvirtinimams, tokiems kaip „Profilis atnaujintas“, „Prekė įdėta į krepšelį“ arba „Žinutė išsiųsta“.
• role="alert": Ši rolė skirta skubiems, laiko atžvilgiu jautriems pranešimams, reikalaujantiems neatidėliotino vartotojo dėmesio. Ji atitinka aria-live="assertive", kuris nedelsiant pertrauks ekrano skaitytuvą, kad pateiktų pranešimą. Naudokite tai itin atsargiai, nes tai gali būti labai trikdantis. Tinka klaidų pranešimams, tokiems kaip „Jūsų sesija netrukus baigsis“ arba kritiniams įspėjimams, pavyzdžiui, „Ryšys prarastas“. Pernelyg dažnas role="alert" naudojimas yra tarsi rėkimas ant savo vartotojų.
• role="log": Tai rečiau naudojama rolė, skirta informacijos žurnalui kurti, kur nauji pranešimai pridedami pabaigoje, pavyzdžiui, pokalbių žurnalai ar klaidų konsolės. Paprastai tai nėra geriausias pasirinkimas tipiškiems iššokantiems pranešimams.

2. Atributas aria-live

Nors `role` atributas dažnai numato tam tikrą `aria-live` elgseną, galite jį nustatyti aiškiai, kad turėtumėte daugiau kontrolės. Jis nurodo ekrano skaitytuvui, *kaip* pranešti apie pakeitimą.

• aria-live="polite": Ekrano skaitytuvas praneša apie pakeitimą, kai vartotojas yra neaktyvus. Tai yra numatytoji reikšmė role="status" ir pageidaujamas nustatymas daugumai iššokančių pranešimų.
• aria-live="assertive": Ekrano skaitytuvas pertraukia viską, ką daro, ir nedelsiant praneša apie pakeitimą. Tai yra numatytoji reikšmė role="alert".
• aria-live="off": Ekrano skaitytuvas nepraneš apie pakeitimus. Tai yra numatytoji reikšmė daugumai elementų.

3. Atributas aria-atomic

Šis atributas nurodo ekrano skaitytuvui, ar pranešti visą „live region“ turinį, ar tik tas dalis, kurios pasikeitė.

• aria-atomic="true": Kai pasikeičia bet kuri „live region“ turinio dalis, ekrano skaitytuvas perskaitys visą elemento turinį. Tai beveik visada yra tai, ko norite iššokančiam pranešimui, užtikrinant, kad visas pranešimas būtų perskaitytas kontekste.
• aria-atomic="false": Ekrano skaitytuvas praneš tik apie pridėtą ar pakeistą mazgą. Tai gali sukelti fragmentiškus ir painius pranešimus iššokantiems pranešimams.

Viską sujungiame: kodo pavyzdžiai

Pažiūrėkime, kaip tai įgyvendinti. Geriausia praktika yra turėti specialų iššokančių pranešimų konteinerio elementą, esantį DOM'e nuo puslapio įkėlimo. Tada dinamiškai įterpiate ir pašalinate atskirus pranešimus šiame konteineryje.

HTML struktūra

Įdėkite šį konteinerį savo `` žymės pabaigoje. Jis vizualiai pozicionuojamas su CSS, tačiau jo vieta DOM'e neturi reikšmės ekrano skaitytuvo pranešimams.

<!-- Mandagi „live region“ standartiniams pranešimams -->
<div id=\"toast-container-polite\" 
     role=\"status\" 
     aria-live=\"polite\" 
     aria-atomic=\"true\">
  <!-- Iššokantys pranešimai bus dinamiškai įterpiami čia -->
</div>

<!-- Atkakli „live region“ skubiems įspėjimams -->
<div id=\"toast-container-assertive\" 
     role=\"alert\" 
     aria-live=\"assertive\" 
     aria-atomic=\"true\">
  <!-- Skubūs pranešimai bus dinamiškai įterpiami čia -->
</div>

„JavaScript“ kodas mandagiam pranešimui

Štai „vanilla JavaScript“ funkcija, rodanti mandagų iššokantį pranešimą. Ji sukuria pranešimo elementą, prideda jį į mandagų konteinerį ir nustato laiko limitą jam pašalinti.

function showPoliteToast(message, duration = 5000) {
  const container = document.getElementById('toast-container-polite');

  // Sukurti pranešimo elementą
  const toast = document.createElement('div');
  toast.className = 'toast';
  toast.textContent = message;

  // Pridėti pranešimą į konteinerį
  container.appendChild(toast);

  // Nustatyti laiko limitą pranešimui pašalinti
  setTimeout(() => {
    container.removeChild(toast);
  }, duration);
}

// Naudojimo pavyzdys:
document.getElementById('save-button').addEventListener('click', () => {
  // ... išsaugojimo logika ...
  showPoliteToast('Jūsų nustatymai sėkmingai išsaugoti.');
});

Kai šis kodas įvykdomas, `div` su `role="status"` yra atnaujinamas. Ekrano skaitytuvas, stebintis puslapį, aptiks šį pakeitimą ir praneš: „Jūsų nustatymai sėkmingai išsaugoti“, nepertraukdamas vartotojo darbo eigos.

Dizaino ir UX geriausios praktikos tikrai įtraukiems iššokantiems pranešimams

Techninis įgyvendinimas su ARIA yra pagrindas, tačiau puiki vartotojo patirtis reikalauja apgalvoto dizaino. Prieinamas iššokantis pranešimas taip pat yra patogesnis visiems.

1. Laikas yra viskas: suteikite vartotojams kontrolę

3 sekundžių trukmės pranešimas gali būti tinkamas kai kuriems, tačiau jis yra per trumpas vartotojams su silpnu regėjimu, kuriems reikia daugiau laiko skaityti, arba vartotojams su kognityvinėmis negaliomis, kuriems reikia daugiau laiko apdoroti informaciją.

• Ilgesnė numatytoji trukmė: Siekite minimalios 5-7 sekundžių trukmės. Tai suteikia patogesnį skaitymo langą platesniam vartotojų ratui.
• Įtraukite „Uždaryti“ mygtuką: Visada pateikite aiškiai matomą ir klaviatūra pasiekiamą mygtuką, skirtą rankiniu būdu atmesti pranešimą. Tai suteikia vartotojams visišką kontrolę ir neleidžia pranešimui išnykti, kol jie su juo nebaigė. Šis mygtukas turėtų turėti prieinamą etiketę, pavyzdžiui, `<button aria-label=\"Uždaryti pranešimą\">X</button>`.
• Pristabdyti užvedus pelę / sufokusavus: Atmetimo laikmatis turėtų sustoti, kai vartotojas užveda pelės žymeklį ant pranešimo arba sufokusuoja jį klaviatūra. Tai yra esminis WCAG laiko reguliavimo kriterijaus aspektas.

2. Vizualinis aiškumas ir išdėstymas

Kaip atrodo ir kur pasirodo iššokantis pranešimas, labai veikia jo efektyvumą.

• Aukštas kontrastas: Užtikrinkite, kad pranešimo tekstas ir fonas turėtų pakankamą spalvų kontrasto santykį, atitinkantį WCAG AA standartus (4.5:1 normaliam tekstui). Naudokite įrankius savo spalvų deriniams patikrinti.
• Aiškios piktogramos: Naudokite visuotinai suprantamas piktogramas (pavyzdžiui, varnelę sėkmei, „i“ informacijai arba šauktuką įspėjimui) kartu su tekstu. Šios piktogramos suteikia greitą vizualinę užuominą, bet nepasikliaukite vien jomis. Visada įtraukite tekstą.
• Nuoseklus išdėstymas: Pasirinkite nuoseklią vietą savo pranešimams (pvz., viršuje dešinėje) ir laikykitės jos visoje savo programoje. Tai sukuria nuspėjamumą vartotojams. Venkite dėti pranešimų ten, kur jie galėtų uždengti svarbius UI elementus.

3. Rašykite aiškius ir glaustus mikrotekstus

Pats pranešimas yra pranešimo esmė. Pasirūpinkite, kad jis būtų vertingas.

• Būkite tiesmuki: Eikite tiesiai prie esmės. Vietoj „Operacija buvo sėkmingai užbaigta“, naudokite „Profilis atnaujintas“.
• Venkite žargono: Naudokite paprastą, aiškią kalbą, kurią pasaulinė auditorija galėtų lengvai suprasti. Tai ypač svarbu tarptautinėms programoms, kurių turinys bus verčiamas. Sudėtingos idiomos ar techniniai terminai gali pradingti vertime.
• Žmogiškas tonas: Rašykite paslaugiu, pokalbio tonu. Pranešimas turėtų skambėti taip, lyg jį siųstų paslaugus asistentas, o ne šalta mašina.

4. Nenaudokite iššokančių pranešimų kritinei informacijai

Tai yra auksinė taisyklė. Jei vartotojas *privalo* pamatyti pranešimą ar su juo sąveikauti, nenaudokite iššokančio pranešimo. Iššokantys pranešimai skirti papildomam, ne kritiniam grįžtamajam ryšiui. Kritinėms klaidoms, patvirtinimo pranešimams, reikalaujantiems vartotojo veiksmo, arba patvirtinimams dėl destruktyvių veiksmų (pavyzdžiui, failo ištrynimo), naudokite patikimesnį modelį, pavyzdžiui, modalinį dialogo langą arba įterptąjį įspėjimą, kuris gauna fokusą.

Prieinamų iššokančių pranešimų testavimas

Negalite būti tikri, kad jūsų įgyvendinimas yra prieinamas, neišbandę jo su įrankiais, kuriuos jūsų vartotojai iš tikrųjų naudoja. Rankinis testavimas yra privalomas dinamiškiems komponentams, tokiems kaip iššokantys pranešimai.

1. Testavimas su ekrano skaitytuvu

Susipažinkite su populiariausiais ekrano skaitytuvais: NVDA (nemokamas, skirtas „Windows“), JAWS (mokamas, skirtas „Windows“) ir „VoiceOver“ (įdiegtas, skirtas „macOS“ ir „iOS“). Įjunkite ekrano skaitytuvą ir atlikite veiksmus, kurie sukelia jūsų iššokančius pranešimus.

Paklauskite savęs:

• Ar pranešimas buvo paskelbtas? Tai yra pats pagrindinis testas.
• Ar jis buvo paskelbtas teisingai? Ar buvo perskaitytas visas pranešimas?
• Ar laikas buvo tinkamas? Mandagiam pranešimui, ar jis palaukė natūralios pauzės? Atkakliam įspėjimui, ar jis nedelsiant pertraukė?
• Ar patirtis buvo trikdanti? Ar `role="alert"` naudojimas yra pateisinamas, ar tai tiesiog erzina?

2. Testavimas tik klaviatūra

Atjunkite pelę ir naršykite savo svetainėje naudodami tik klaviatūrą („Tab“, „Shift+Tab“, „Enter“, „Spacebar“).

• Jei jūsų pranešime yra „Uždaryti“ mygtukas ar bet koks kitas interaktyvus elementas, ar galite prie jo pereiti naudodami „Tab“ klavišą?
• Ar galite aktyvuoti mygtuką naudodami „Enter“ arba „Spacebar“?
• Ar fokusas grįžta į logišką vietą programoje po to, kai pranešimas yra atmetamas?

3. Vizualiniai ir naudojamumo patikrinimai

• Patikrinkite spalvų kontrastą su naršyklės plėtiniu ar internetiniu įrankiu.
• Pabandykite keisti naršyklės lango dydį arba peržiūrėti skirtinguose įrenginiuose. Ar pranešimas vis dar pasirodo priimtinoje vietoje, neuždengdamas kito turinio?
• Paprašykite ko nors, kas nėra susipažinęs su programa, ja pasinaudoti. Ar jie supranta, ką reiškia iššokantys pranešimai?

Išvada: kuriame įtraukesnį internetą, po vieną pranešimą

Iššokantys pranešimai yra maža, bet reikšminga vartotojo patirties dalis. Daugelį metų jie buvo dažna aklavietė žiniatinklio prieinamume, sukurianti varginančią patirtį pagalbinių technologijų vartotojams. Bet taip neturi būti.

Pasitelkdami ARIA „live regions“ galią ir laikydamiesi apgalvotų dizaino principų, galime paversti šiuos trumpalaikius pranešimus iš kliūčių į tiltus. Prieinamas iššokantis pranešimas yra ne tik techninis langelio pažymėjimas; tai įsipareigojimas aiškiai bendrauti su *visais* vartotojais. Tai užtikrina, kad kiekvienas, nepriklausomai nuo jo gebėjimų, gautų tą patį svarbų grįžtamąjį ryšį ir galėtų naudotis mūsų programomis su pasitikėjimu ir efektyvumu.

Padarykime prieinamus pranešimus pramonės standartu. Įtraukdami šias praktikas į savo dizaino sistemas ir kūrimo darbo eigas, galime sukurti įtraukesnį, patikimesnį ir vartotojui draugiškesnį internetą tikrai pasaulinei auditorijai.