Skip to content

Kako sprovesti testiranje pristupačnosti: praktični vodič sa AI promptovima

Testiranje pristupačnosti (accessibility testing) procenjuje da li digitalni proizvod mogu efektivno koristiti osobe sa invaliditetom, uključujući one koji se oslanjaju na asistivne tehnologije kao što su čitači ekrana, navigacija tastaturom, prekidači i lupe ekrana. Metod kombinuje automatizovano skeniranje prema Smernicama za pristupačnost veb sadržaja (WCAG) sa ručnim ekspertskim pregledom i testnim sesijama sa pravim korisnicima koji imaju invaliditet, proizvodeći prioritizovanu listu prepreka koje sprečavaju ravnopravan pristup. Prema izveštaju WebAIM Million iz 2025. godine, 94,8% od milion najposećenijih sajtova ne prolazi osnovne provere pristupačnosti, što testiranje pristupačnosti čini jednim od najpotrebnijih evaluativnih metoda u UX istraživanju.

Na koje pitanje odgovara ovaj metod?

  • Može li slepa osoba koja koristi čitač ekrana da završi osnovne zadatke na ovom proizvodu (registracija, kupovina, navigacija) bez blokirajućih prepreka?
  • Da li redosled navigacije tastaturom prati logičan tok, ili fokus nepredvidivo skače između elemenata?
  • Da li svi interaktivni elementi (dugmad, linkovi, polja formi, meniji) imaju dovoljne oznake, odnose kontrasta i indikatore fokusa da zadovolje kriterijume WCAG 2.1 AA?
  • Koje konkretne kriterijume uspeha WCAG proizvod trenutno ne ispunjava, i kolika je ozbiljnost svakog kršenja?
  • Nakon otklanjanja identifikovanih prepreka, da li ispravke zaista funkcionišu u praksi za korisnike sa različitim tipovima invaliditeta?

Kada koristiti

  • Pre lansiranja novog proizvoda ili velike funkcionalnosti, da se identifikuju i otklone prepreke pristupačnosti dok su promene još jeftine — naknadno dodavanje pristupačnosti nakon lansiranja košta značajno više.
  • Prilikom pripreme za zakonske zahteve kao što su Zakon o Amerikancima sa invaliditetom (ADA), Evropski akt o pristupačnosti (EAA) ili Sekcija 508 u SAD.
  • Nakon redizajna ili migracije platforme, da se verifikuje da nova implementacija nije uvela regresije — čest problem prilikom prelaska između frejmvorka ili dizajn sistema.
  • Na redovnoj osnovi (kvartalno ili polugodišnje) kao deo kontinuiranog programa pristupačnosti, jer se sajtovi neprekidno menjaju i nove prepreke se pojavljuju sa svakim deploy-om.
  • Kada podaci korisničke podrške ukazuju da osobe sa invaliditetom prijavljuju probleme ili napuštaju određene tokove češće od opšte populacije.

Metod nije pravi izbor kada se pitanje tiče emocionalne privlačnosti, percepcije brenda ili opštih preferencija upotrebljivosti — studije poželjnosti, testiranje preferencija ili standardno testiranje upotrebljivosti su bolji izbori. Testiranje pristupačnosti se specifično fokusira na to da li osobe sa invaliditetom mogu pristupiti proizvodu i koristiti ga. Pri tom, testiranje pristupačnosti ne bi trebalo da postoji izolovano: pristupačan ali neupotrebljiv proizvod ne služi nikome. Kombinujte testiranje pristupačnosti sa testiranjem upotrebljivosti.

Šta dobijate (rezultati)

  • Izveštaj WCAG audita: detaljan dokument sa svakim testiranim kriterijumom uspeha WCAG, rezultatom (prošao/nije prošao), ozbiljnošću kršenja i pogođenim elementima.
  • Prioritizovani beklog problema: rangirani spisak prepreka pristupačnosti organizovan po ozbiljnosti i uloženom trudu, spreman za uvoz u Jira, GitHub Issues ili drugi alat.
  • Matrica kompatibilnosti asistivnih tehnologija: tabela koja prikazuje koje su kombinacije čitača ekrana, pretraživača i uređaja testirane.
  • Snimci i beleške korisničkih sesija: video snimci (uz saglasnost) i anotirane beleške iz sesija sa učesnicima sa invaliditetom.
  • Uputstvo za otklanjanje: za svaku prepreku — opis potrebnih promena sa primerima koda.
  • Osnovna ocena za longitudinalno praćenje: merljiv presek koji služi kao referentna tačka za buduće audite.

Učesnici i trajanje

  • Učesnici: 3-5 po kategoriji invaliditeta (vizuelna, motorna, kognitivna, slušna). Tipična studija uključuje 8-15 učesnika. Automatizovana skeniranja i ručni ekspertski pregled ne zahtevaju učesnike.
  • Trajanje sesije: Automatizovana skeniranja traju minutima. Ručni ekspertski pregled — 2-5 dana. Korisničke sesije — 45-60 minuta po učesniku.
  • Vreme pripreme: 1-2 dana za definisanje obima, izbor alata, pripremu scenarija i regrutaciju učesnika (regrutacija može trajati 1-2 nedelje).
  • Vreme analize: 1-3 dana za automatizovane + ručne rezultate. Analiza korisničkog testiranja dodaje 2-3 dana.
  • Ukupni rok: 2-4 nedelje za kompletan ciklus. Jednostavno automatizovano skeniranje može se završiti za jedan dan.

Kako sprovesti testiranje pristupačnosti (korak po korak)

1. Definišite obim, standard i kriterijume uspeha

Odredite koje stranice, korisničke tokove i komponente ćete testirati. Za prvi audit, fokusirajte se na najposećenije stranice i kritične korisničke puteve (početna, prijava, kupovina, pretraga). Izaberite standard — WCAG 2.1 AA je najšire usvojen i pravno referentni. Ustanovite šta znači „prolaz” pre početka testiranja.

2. Pokrenite automatizovano skeniranje

Koristite automatizovane alate (axe DevTools, WAVE, Lighthouse, Pa11y) za skeniranje odabranih stranica. Ovi alati otkrivaju oko 30-40% WCAG problema — pre svega nedostajući alt tekst, nedovoljan kontrast, nedostajuće oznake formi. Skenirajte u više interaktivnih stanja (otvoreni meniji, vidljivi modali, stanja grešaka).

3. Sprovedite ručni ekspertski pregled

Obučeni specijalista za pristupačnost ručno testira stranice koristeći navigaciju samo tastaturom, čitače ekrana (NVDA na Windows, VoiceOver na macOS/iOS, TalkBack na Android) i uvećanje ekrana. Ekspert proverava ono što automatizovani alati propuštaju: logičan redosled čitanja, hijerarhiju naslova, ispravne ARIA atribute, ponašanje prilagođenih vidžeta. Ovaj korak otkriva preostalih 60-70% problema.

4. Regrutujte učesnike sa invaliditetom i pripremite sesije

Regrutujte 8-15 učesnika po kategorijama: korisnici čitača ekrana (slepi ili slabovidi), korisnici samo tastature (motorna oštećenja), osobe sa kognitivnim teškoćama, gluvi ili nagluvi (za multimedijalni sadržaj). Koristite specijalizovane servise za regrutaciju (Fable, AbilityNet, lokalne organizacije osoba sa invaliditetom). Pripremite scenarije zasnovane na realnim ciljevima. Obezbedite da su obrasci saglasnosti pristupačni.

5. Sprovedite korisničke sesije

Vodite moderirane sesije (poželjno na daljinu, jer učesnici koriste sopstvene uređaje i podešavanja asistivnih tehnologija). Tokom sesija: ne govorite preko čitača ekrana, dozvolite učesnicima da pokušaju zadatke na svoj način, dokumentujte ne samo uspeh/neuspeh već i putanju. Snimajte sesije (uz saglasnost).

6. Konsolidujte nalaze i prioritizujte

Objedinite rezultate sva tri nivoa testiranja. Uklonite duplikate. Dodelite svakom problemu prioritet: kritičan (potpuno blokira zadatak), visok (zadatak izvodljiv ali sa značajnom teškoćom), nizak (nelagodnost koja ne blokira korišćenje). Povežite svaki problem sa WCAG kriterijumom.

7. Napišite izveštaj i plan otklanjanja

Strukturirajte izveštaj za više publika: rezime za rukovodstvo sa ukupnom slikom usklađenosti i poslovnim rizicima; detaljan deo sa snimcima ekrana, WCAG referencama i uputstvima za ispravku koda; prioritizovani beklog za planiranje sprinta. Uključite kratke video klipove korisnika koji nailaze na kritične prepreke.

8. Otklonite, ponovo testirajte, pratite

Nakon što razvojni tim reši najprioritetnije probleme, pokrenite ciljano ponovno testiranje. Podesite kontinuirani monitoring sa automatizovanim skeniranjem po rasporedu (nedeljno ili pri svakom deploy-u) za rano otkrivanje regresija.

Kako AI menja ovaj metod

AI kompatibilnost: delimična — AI alati mogu automatizovati otkrivanje šireg spektra WCAG kršenja, a LLM-ovi pomažu u generisanju alt teksta, proceni čitljivosti i izradi uputstava za otklanjanje. Međutim, realno testiranje sa osobama sa invaliditetom ostaje nezamenljivo.

Šta AI može da uradi

  • Proširi pokrivenost automatizovanog skeniranja: AI alati (axe AI, UserWay) otkrivaju probleme izvan tradicionalnih provera — npr. razlikuju informativne od dekorativnih slika.
  • Generiše i proceni alt tekst: LLM može kreirati nacrt alt teksta koji čovek recenzent koriguje na tačnost i kontekstualnost.
  • Proceni nivo čitljivosti i kognitivnu pristupačnost: AI analizira sadržaj na složenost (Flesch-Kincaid, SMOG), identifikuje žargon i predlaže pojednostavljenja — direktna podrška WCAG kriterijumu 3.1.5.
  • Izradi uputstva za otklanjanje: po listi WCAG kršenja LLM generiše konkretne ispravke koda.
  • Sumira nalaze korisničkog testiranja: nakon sesija LLM može obraditi transkripte, klasterizovati probleme po WCAG kriterijumima i izraditi nacrt rezimea izveštaja.

Šta zahteva istraživača-čoveka

  • Testiranje sa realnim korisnicima asistivnih tehnologija: nikakav AI ne može replicirati iskustvo slepe osobe koja navigira sa JAWS, osobe sa tremorom koja koristi prekidač, ili osobe sa ADHD-om koja pokušava da popuni višestepenu formu.
  • Procena da li je sadržaj zaista pristupačan u kontekstu: AI može proveriti da alt tekst postoji, ali čovek mora proceniti da li je „slika grafikona” korisna ili podatke treba pružiti kao tabelu.
  • Testiranje prilagođenih interaktivnih komponenti: padajući meniji, birači datuma, harmonike i drag-and-drop interfejsi često se nepredvidivo ponašaju sa asistivnim tehnologijama.
  • Moderiranje sesija sa učesnicima sa invaliditetom: istraživač se mora prilagođavati u realnom vremenu — praviti pauzu kada čitač ekrana govori, nuditi alternativne puteve i čitati neverbalne signale.

Radni tok sa AI

Pre AI, pisanje alt teksta za veliki sajt — recimo 500 slika — trajalo je 2-3 radna dana. Sa LLM, istraživač može paketno generisati nacrt alt teksta za manje od sat vremena, a preostalo vreme utrošiti na pregled i uređivanje. Ovo smanjuje ukupni trud za oko 70%.

Tradicionalni automatizovani skeneri otkrivali su oko 30% WCAG problema. Skeneri sa AI (axe AI) povećavaju to na 50-60%. Ručni ekspertski pregled ostaje neophodan ali polazi od kompletnije osnove, smanjujući ukupno vreme audita za 1-2 dana.

Generisanje izveštaja značajno profitira od AI. Nakon ručnog pregleda i korisničkih sesija, LLM može izraditi nacrt strukturiranog izveštaja — organizovati nalaze po WCAG kriterijumima, generisati predloge ispravki koda i napisati rezime za rukovodstvo. Specijalista za pristupačnost pregleda i dorađuje nacrt.

Alati

Automatizovano skeniranje:

  • axe DevTools (Deque) — ekstenzija pretraživača i CI/CD integracija za WCAG skeniranje; axe-core motor je industrijski standard.
  • WAVE (WebAIM) — vizuelna ekstenzija pretraživača koja prikazuje greške pristupačnosti na stranici.
  • Google Lighthouse — ugrađen u Chrome DevTools; uključuje sekciju audita pristupačnosti.
  • Pa11y — alat otvorenog koda za automatizovano testiranje pristupačnosti.

Ručno testiranje i čitači ekrana:

  • NVDA — besplatan čitač ekrana otvorenog koda za Windows.
  • VoiceOver — ugrađeni čitač ekrana na macOS i iOS.
  • JAWS (Freedom Scientific) — komercijalni čitač ekrana za Windows.
  • Colour Contrast Analyser (TPGi) — alat za proveru odnosa kontrasta boja.

Korisničko testiranje sa osobama sa invaliditetom:

  • Fable — platforma koja povezuje produktne timove sa osobama sa invaliditetom.
  • AbilityNet — organizacija koja pruža usluge testiranja sa testerima sa invaliditetom.
  • Level Access — sveobuhvatan audit pristupačnosti i integracija korisničkog testiranja.

Uz pomoć AI:

  • axe AI (Deque) — AI sloj iznad axe-core za otkrivanje poluautomatizovanih problema.
  • ChatGPT / Claude — za generisanje alt teksta, analizu čitljivosti, uputstva za otklanjanje i izradu izveštaja.

Dobro se kombinuje sa

  • Moderirano testiranje upotrebljivosti (Ut): Sprovođenje testiranja pristupačnosti uporedo sa sesijama testiranja upotrebljivosti omogućava evaluaciju istih korisničkih tokova za opštu upotrebljivost i prepreke pristupačnosti u jednom istraživačkom ciklusu.
  • First Click Testing (Fc): Poređenje gde videći korisnici kliknu prvo sa tim gde korisnici čitača ekrana završe otkriva pretpostavke dizajna navigacije.
  • Benčmarking (Bm): Benčmarking pristupačnosti uspostavlja osnovnu ocenu usklađenosti koja se može pratiti tokom vremena i porediti sa konkurencijom.
  • Journey Mapping (Jm): Mape putovanja koje uključuju tačke kontakta pristupačnosti čine prepreke vidljivim za ceo tim.
  • Intervju sa zainteresovanim stranama (Si): Intervjuisanje vlasnika proizvoda, programera i pravnog tima pre audita pomaže istraživaču da razume ograničenja, rokove usklađenosti i istoriju napora.

Primer iz prakse

Srednja evropska e-commerce kompanija dobila je žalbu od slepog kupca koji nije mogao da završi kupovinu koristeći JAWS u Firefox-u. Kupac je napustio proces naručivanja nakon što čitač ekrana nije najavio obavezna polja i nije mogao da navigira formom za plaćanje. Pravni tim kompanije je označio žalbu kao potencijalni rizik prema Evropskom aktu o pristupačnosti.

Istraživački tim sproveo je tronivovski audit: automatizovano axe skeniranje je označilo 87 problema na 12 ključnih stranica. Ručni ekspertski pregled otkrio je još 34 problema — uključujući potpuno nepristupačan birač datuma putem tastature, indikator napretka naručivanja bez povratne informacije za čitače ekrana i greške validacije formi koje su se prikazivale vizuelno ali nisu bile najavljene. Korisničko testiranje sa 10 učesnika (3 korisnika čitača ekrana, 3 samo tastature, 2 sa kognitivnim teškoćama, 2 slabovida) otkrilo je da su 4 od 5 kritičnih korisničkih tokova imali bar jednu blokirajuću prepreku.

Tim za otklanjanje je rešio 12 kritičnih problema u dva sprinta (4 nedelje), ciljajući prvo na tok naručivanja. Ponovno testiranje potvrdilo je rešavanje svih blokera — korisnici čitača ekrana su sada mogli da završe kupovinu od početka do kraja. Preostali problemi raspoređeni su na sledeća dva kvartala. Šest meseci kasnije, monitoring pristupačnosti pokazao je smanjenje ukupnog broja WCAG kršenja za 73%, a tiketi korisničke podrške od korisnika sa invaliditetom smanjeni su za 61%.

Greške početnika

Oslanjanje samo na automatizovana skeniranja

Automatizovani alati otkrivaju oko 30-40% WCAG problema. Početnici često pokrenu Lighthouse ili WAVE, vide ocenu „prolaz” i zaključe da je sajt pristupačan. Preostalih 60-70% problema može se otkriti samo ručnim testiranjem i realnim korisničkim sesijama.

Testiranje bez osoba sa invaliditetom

Čak i tri sesije sa korisnicima čitača ekrana otkriće probleme koje nijedna čeklista audita ne može uhvatiti. Specijalista za pristupačnost koji vidi i koristi miš ne doživljava proizvod na isti način kao slepa osoba sa JAWS-om.

Popravljanje simptoma umesto sistemskih uzroka

Kada skeniranje prijavi 47 slika bez alt teksta, početnik može dodati alt tekst tim slikama. Pravo pitanje je zašto te slike nemaju alt tekst: da li CMS ne traži unos? Da li komponenta renderuje slike bez alt atributa? Popravljanje šablona jednom sprečava ponavljanje problema.

Tretiranje pristupačnosti kao jednokratnog projekta

Svaki deploy, ažuriranje sadržaja i dizajnerska promena može uvesti nove prepreke. Podesite automatizovani monitoring pri svakom deploy-u i planirajte ručne ponovne audite kvartalno.

Ignorisanje kognitivne pristupačnosti

Većina testiranja se fokusira na čitače ekrana i tastaturu — to je važno, ali nepotpuno. WCAG takođe pokriva kognitivnu pristupačnost: jasan jezik, doslednu navigaciju, prevenciju grešaka i dovoljno vremena. Uključujte učesnike sa kognitivnim teškoćama i procenjujte nivo čitljivosti.

AI prompti za ovaj metod

4 spremnih AI prompta sa placeholderima — kopirajte i popunite svojim kontekstom. Svi prompti za testiranje pristupačnosti →.