Prieinamas DI pokalbių robotas: WCAG kontrolinis sąrašas svetainėms
DI pokalbių robotas padeda tik tada, kai juo gali naudotis visi. Šis WCAG pagrįstas kontrolinis sąrašas parodo, į ką svetainių komandos turėtų atkreipti dėmesį tikrindamos valdiklį, dialogą, klaviatūrą, mobiliuosius įrenginius ir perdavimą pagalbos komandai.
Svetainės pokalbių robotas dažnai yra labiausiai matomas interaktyvus elementas įmonės svetainėje. Jis atidaromas per paleidimo mygtuką, kaip dialogo langas uždengia turinį, apdoroja teksto įvestį, rodo atsakymų korteles ir geriausiu atveju suteikia galimybę perduoti pokalbį pagalbos ar pardavimų komandai. Būtent todėl nepakanka optimizuoti tik atsakymų kokybės. DI pokalbių robotas turi būti patogus naudoti ir žmonėms, kurie dirba klaviatūra, ekrano skaitytuvu, stipriu didinimu, turi ribotą motoriką arba naudojasi mažais mobiliaisiais ekranais.
Prieinamumas nėra atskiras projektas paskutiniam sprintui. Jis turi būti įtrauktas į produkto reikalavimus: ar paleidimo mygtukas pasiekiamas? Ar fokusas matomas? Ar pokalbį galima uždaryti nepakliūnant į klaviatūros spąstus? Ar klaidų pranešimai suprantami? Ar šaltiniai, priedai ir formos veikia ir tada, kai žmogus nenaudoja pelės? Šis kontrolinis sąrašas padeda svetainių valdytojams, pagalbos, rinkodaros ir produktų komandoms sistemingai patikrinti, ar DI pokalbių robotas yra prieinamas.
Kodėl prieinamumas pokalbių robotams yra ypač svarbus
Daugelis svetainių turi pavienių kliūčių, kurias naudotojai gali apeiti: sunkiai perskaitomą vaizdą, neaiškų žemėlapį arba prastai pažymėtą meniu. Pokalbių robotas veikia kitaip. Jis dažnai sutelkia pagrindines užduotis: užduoti klausimus, suprasti kainas, pasiruošti susitikimams, kvalifikuoti potencialius klientus, struktūruoti pagalbos užklausas arba rasti dokumentus. Jei šis valdiklis neprieinamas, naudinga automatizacija tampa prieigą blokuojančiu tašku.
WCAG 2.2 apibūdina saityno prieinamumą kaip platų testuojamų reikalavimų rinkinį skirtingoms negalioms ir įrenginiams. Pokalbių robotų komandoms čia svarbu tai: kalbama ne tik apie spalvą ir kontrastą. Kalbama apie valdomumą, nuspėjamumą, suprantamą turinį, aiškų klaidų tvarkymą ir patikimą techninę semantiką. Pokalbių robotas, kuris dalykiškai atsako gerai, bet praranda fokusą arba valdomas tik pele, savo tikslo nepasiekia.
Reguliacinis kontekstas taip pat tapo aktualesnis. Europos Komisija Europos prieinamumo akte tarp kitų sričių mini e. prekybą kaip vieną iš aprėpiamų sričių ir pabrėžia bendras prieinamumo taisykles ES rinkoje. Šis straipsnis nėra teisinė konsultacija; jame pateikiami praktiniai techniniai ir redakciniai patikros punktai, į kuriuos komandos turėtų rimtai žiūrėti nepriklausomai nuo konkrečios teisinės pareigos.
Pirmiausia WCAG klausimas: kas iš tikrųjų yra pokalbių roboto produktas?
Viena projektų klaida – testuoti tik mažą pokalbio burbulo mygtuką. Tačiau pokalbių robotas susideda iš kelių būsenų. Uždarytas paleidimo mygtukas yra valdymo elementas. Atidarytas langas dažnai yra dialogas. Žinučių sąrašas yra dinaminis turinys. Įvesties laukas yra forma. Šaltinių nuorodos, mygtukai, greitieji atsakymai, failų priedai ir eskalavimo parinktys yra kiti interaktyvūs elementai. Visos šios dalys turi veikti kartu.
Jei pokalbių robotą jau integruojate į savo svetainę, verta sudaryti techninį inventoriaus sąrašą. Straipsnyje DI pokalbių roboto integravimas į svetainę UX ir SEO aptariami bendrai. Prieinamumo patikrą papildykite konkrečiais priėmimo kriterijais: klaviatūros keliu, fokuso tvarka, semantiniais pavadinimais, mobiliųjų tikslinių sričių dydžiais, perskaitomais būsenos pranešimais ir prieinamu perdavimu žmogui.
Kontrolinis sąrašas: kaip DI pokalbių robotą padaryti prieinamesnį
1. Paleidimo mygtukas ir pokalbio langas turi veikti naudojant klaviatūrą
Pirmasis testas paprastas: padėkite pelę į šalį. Ar galite pasiekti paleidimo mygtuką Tab klavišu, jį atidaryti ir vėl uždaryti? Ar visada matote, kuris elementas šiuo metu turi fokusą? Ar iš įvesties lauko galite toliau pereiti prie greitųjų atsakymų, šaltinių, formos laukų ir uždarymo mygtuko? WAI savo paprastose patikrose rekomenduoja formas ir valdymo elementus tikslingai tikrinti dėl prieinamumo klaviatūra. Pokalbių robotams tai privaloma programa, nes pati įvestis yra forma.
Ypač atkreipkite dėmesį į pasirinktinius mygtukus. div elementas su paspaudimo apdorokliu gal ir atrodo kaip mygtukas, bet be tinkamos semantikos, pavadinimo ir klaviatūros įvykių dažnai nėra prieinamas. Kai tik įmanoma, naudokite natyviuosius mygtukus. Jei reikia savų komponentų, jų vaidmuo, pavadinimas, būsena ir valdymas klaviatūra turi būti aiškiai nustatyti ir teisingai veikti.
2. Tinkamai sutvarkykite fokusą, dialogo veikimą ir išėjimo kelius
Daugelis pokalbių robotų atsidaro kaip perdanga. Tada kyla tipiniai dialogo klausimai: kur nukeliauja fokusas atidarius? Ar Tab tvarka atidarytame dialoge išlieka logiška? Ar dialogą galima uždaryti aiškiu mygtuku? Ar po to fokusas grįžta į prasmingą vietą? WAI-ARIA dialogo šablone aprašoma, kad atidarius fokusas pereina į dialogą ir dialogo viduje juda kontroliuojamai.
Praktikoje tai reiškia: pokalbių robotas neturi staiga prarasti fokuso, kai ateina naujas DI atsakymas. Naujos žinutės turėtų tapti pastebimos nepertraukdamos aktyvios įvesties. Jei pokalbių robotas srautu pateikia ilgesnį atsakymą, sąsaja neturi šokinėti taip, kad mobiliuosiuose įrenginiuose arba naudojant didinimą žmonės prarastų orientaciją.
3. Tikrinkite mobiliųjų įrenginių tikslinių sričių dydžius ir atstumus
Mobiliosiose svetainėse pokalbių robotų valdikliai ypač linkę kelti problemų: paleidimo mygtukai yra prie krašto, slapukų reklamjuostės uždengia sritis, greitieji atsakymai virsta mažomis pasirinkimo žymomis, o įvesties laukas konkuruoja su ekranine klaviatūra. WCAG 2.2 kriterijus tikslinės srities dydis (minimumas) skirtas tikslinių sričių dydžiams naudojant žymeklio įvestį. Kaip praktinę apatinę ribą pokalbių robotų komandos turėtų labai sąmoningai tikrinti mažus uždarymo, siuntimo, priedo ir greitojo atsakymo mygtukus.
Testuokite ne tik didelį išmanųjį telefoną. Tikrinkite siaurus peržiūros langus, priartinimą, ilgus vokiškus žodžius, kelių eilučių atsakymus ir ekrane pasirodančias klaviatūras. Prieinamas pokalbių robotas lieka naudojamas, kai svetainė persitvarko iki 320 pikselių pločio, kai atsakymas ilgesnis nei tikėtasi ir kai mygtukai nesulimpa vienas šalia kito.
4. Atsakymus kurkite suprantamus, lengvai peržvelgiamus ir ne vien vizualius
Prieinamumas apima ir DI atsakymų kalbą. Pokalbių robotas turėtų būti ne tik techniškai pasiekiamas, bet ir pateikti aiškius, gerai struktūruotus atsakymus. Ilgus teksto blokus sunku peržvelgti. Geriau tinka trumpos pastraipos, sąrašai, aiškūs tolesni žingsniai ir matomos ribos: ką pokalbių robotas žino iš žinių bazės? Kas kelia abejonių? Kada turėtų perimti žmogus?
Tai tiesiogiai susiję su atsakymų kokybe. Jei pokalbių robotą mokote naudodami DUK, dokumentus ir svetainės turinį, kaip aprašyta įraše DI pokalbių roboto mokymas naudojant DUK ir dokumentus, taip pat turėtumėte palaikyti redakcines taisykles prieinamiems atsakymams. Tai apima paprastą kalbą, nereikalingų lentelių vengimą, atsakymų neteikimą vien paveikslu ir šaltinių nuorodas su suprantamu nuorodos tekstu.
5. Vaizdų, priedų ir šaltinių nelaikykite juodąja dėže
Jei pokalbių robotas apdoroja produktų vaizdus, dokumentus, ekrano kopijas ar įkėlimus, kiekvienas vizualus elementas turi turėti aiškų tikslą. WAI savo vaizdų vadove aiškina, kad vaizdams reikia tekstinių alternatyvų, perteikiančių informaciją arba funkciją; vien dekoratyvūs vaizdai gali turėti tuščius alternatyviuosius tekstus. Pokalbių roboto atsakymams tai reiškia: vien piktograma negali paaiškinti būsenos. Ekrano kopija negali būti vienintelis informacijos šaltinis. Atsisiuntimo nuoroda turėtų aprašyti, kas bus atsisiunčiama.
Šaltinių nurodymai taip pat yra prieinamumo dalis. Jei pokalbių robotas nukreipia į pagalbos puslapį, nuoroda neturėtų vadintis „čia“, bet, pavyzdžiui, „Atidaryti pristatymo sąlygas“. Tai padeda ekrano skaitytuvų naudotojams, gerina orientaciją ir mažina nesusipratimus pagalbos procese.
6. Užtikrinkite prieinamą perdavimą žmonėms
DI pokalbių robotas neprivalo išspręsti kiekvienos užklausos. Svarbu, kad perdavimas veiktų patikimai. Tai vienu metu susiję su pagalbos kokybe, duomenų apsauga ir prieinamumu. Perdavymo forma turėtų turėti matomas etiketes, aiškius klaidų pranešimus, suprantamą patvirtinimą ir alternatyvius kontaktų būdus, kartu nepateikdama išgalvotų telefono numerių ar nepatikrintų kontaktinių duomenų.
Jei renkami asmens duomenys, taip pat reikia tvarkingos duomenų apsaugos patikros. Įraše DI pokalbių robotas ir BDAR ši sritis aptariama išsamiau. Žvelgiant iš prieinamumo perspektyvos, lemiama tai: naudotojai turi galėti suprasti, kokių duomenų prašoma, kodėl jų prašoma ir kaip jie gali nutraukti procesą.
Pragmatiškas tikrinimo procesas svetainių komandoms
Pradėkite nuo testavimo matricos, o ne nuo abstraktaus kontrolinio sąrašo. Kiekvienai pokalbių roboto būsenai apibrėžkite, kas turi įvykti: uždaryta, atidaryta, pirmas klausimas, generuojamas atsakymas, šaltinių rodinys, klaidos pranešimas, potencialaus kliento forma, perdavimas, uždaryta baigus. Kiekvieną būseną tikrinkite klaviatūra, baziniu ekrano skaitytuvo testu, mobiliuoju peržiūros langu ir dideliu didinimu.
Tada suskirstykite nustatytas problemas į tris grupes. Pirma – blokuojančios problemos: pokalbis nepasiekiamas, jo negalima uždaryti arba jis trukdo naudotis puslapiu. Antra – kokybės klaidos: fokusas šokinėja, atsakymo struktūra neaiški, trūksta etikečių, nuorodų tekstai silpni. Trečia – patobulinimai: geresnės formuluotės, didesnės tikslinės sritys, nuoseklesni būsenos pranešimai. Blokuojančios problemos prieš paleidimą turi patekti į taisymo sprintą; kokybės klaidos neturėtų būti nustumtos į „vėliau“, nes jos tiesiogiai prisideda prie pagalbos ir konversijos tikslų.
Automatizuoti testai padeda, bet jie nepakeičia naudojimo testų. Lighthouse, axe ar panašūs įrankiai aptinka daug techninių problemų, tačiau jie nežino, ar DI atsakymas prasmingai struktūruotas, ar perdavimo eiga tikroms klientėms ir klientams išlieka suprantama. Todėl derinkite įrankių patikras su rankiniais klaviatūros keliais ir tikrais pagalbos scenarijais.
Ko turėtumėte vengti
Venkite pokalbių robotų, kurie automatiškai uždengia turinį nekontroliuodami fokuso. Venkite valdymo vien piktogramomis be prieinamų pavadinimų. Venkite mažyčių greitųjų atsakymų mobiliuosiuose įrenginiuose. Venkite atsakymų, kurie sudaro teisinio, medicininio ar sutartinio užtikrintumo įspūdį, kai pagrindinė žinių bazė tam nesuteikia pagrindo. Ir venkite neaiškaus eskalavimo: jei pokalbių robotas negali padėti, kitas žingsnis turi būti aiškus.
Aktualus straipsnis apie ES DI aktą svetainių pokalbių robotams papildomai parodo, kodėl skaidrumas ir aiškus pokalbių roboto žymėjimas yra svarbūs. Prieinamumas papildo šį skaidrumą: pranešimas padeda tik tada, kai jis yra pastebimas, suprantamas ir valdomas.
Išvada
Prieinamas DI pokalbių robotas nėra malonus priedas projekto pabaigoje. Jis lemia, ar automatizavimas iš tiesų sumažina krūvį, ar sukuria naujų kliūčių. Svarbiausi žingsniai aiškūs: pirmenybę teikti natyviesiems valdymo elementams, testuoti klaviatūros kelius, išlaikyti matomą fokusą, tvarkingai išspręsti dialogo būsenas, tikrinti mobiliųjų tikslinių sričių dydžius, suprantamai struktūruoti atsakymus ir padaryti perdavimą žmogui prieinamą.
Kas šiuos punktus suplanuoja anksti, pagerina ne tik prieinamumą. Tas pats pagrindas daro pokalbių robotą atsparesnį, suprantamesnį ir patikimesnį visiems svetainės lankytojams.
Šaltiniai ir papildomi standartai
Paverskite svetainės lankytojus geresniais pokalbiais
Sumažinkite pagalbos apkrovą išlaikydami nuoseklius atsakymus
Suteikite lankytojams akimirksnius svetainės palaikymą, nukreipkite išimtinius atvejus savo komandai ir užtikrinkite, kad kiekvienas atsakymas atitiktų jūsų patvirtintą žinių bazę.
Susiję straipsniai
Tęsti skaitymą
Kaip pridėti DI chatbotą prie svetainės nepažeidžiant UX ar SEO
Diegimo planas, kaip pridėti chatbotą prie jūsų svetainės, tuo pačiu išlaikant naudotojo kelią, puslapio greitį ir turinio struktūrą tvarkingus.
Kaip apmokyti dirbtinio intelekto pokalbių robotą su DUK, dokumentais ir svetainės turiniu
Ką svetainių komandos turi paruošti prieš paleidimą, kad pokalbių robotas išliktų tikslus, naudingas ir suderintas su patvirtinta verslo informacija.
AI pokalbių robotai ir BDAR: ką svetainių savininkai privalo patikrinti
Praktinis kontrolinis sąrašas komandoms, kurios nori naudoti AI pokalbių robotą savo svetainėje, neignoruojant privatumo, duomenų minimizavimo ir operacinės rizikos.