Listă de verificare a accesibilității pentru firme mici și magazine

Imaginați-vă un client care folosește un cititor de ecran. Găsește pantofii sport pe care îi vrea, alege mărimea și apasă pe ce crede că este butonul de coș. Cititorul de ecran spune „buton”. Atât. Pe pagină sunt trei astfel de butoane, niciunul cu nume, așa că pleacă, iar dumneavoastră nu aflați niciodată de ce.

Cele mai multe probleme de accesibilitate de pe site-urile firmelor mici arată așa: invizibile pentru proprietar, o fundătură pentru client. Lista de față este pentru cei care au un site pe Shopify, WooCommerce, Wix sau Squarespace fără un dezvoltator în echipă.

Trebuie să fie accesibil site-ul unei firme mici?

Dacă vindeți consumatorilor din UE, probabil că da. Actul european privind accesibilitatea (se deschide într-o filă nouă) (European Accessibility Act) acoperă serviciile de comerț electronic din 28 iunie 2025. Principala scutire este pentru microîntreprinderile care furnizează servicii: firme cu sub 10 angajați și o cifră de afaceri anuală sau un total al bilanțului anual de cel mult 2 milioane de euro.

Comerțul electronic înseamnă aici vânzarea la distanță, printr-un site sau o aplicație, „la solicitarea individuală a unui consumator în vederea încheierii unui contract de consum” (articolul 3 punctul 30). Un magazin online sau un motor de rezervări se încadrează. Scutirea acoperă doar serviciile: vânzarea de produse vizate, cum ar fi cititoarele de cărți electronice, atrage în continuare regulile pentru produse (articolul 4 alineatul (5)). Nici faptul că sunteți în afara UE nu ajută, pentru că un magazin din Regatul Unit care vinde clienților din Franța este acoperit pentru acești clienți (articolul 3 punctul 4). Ghidul nostru despre Actul european privind accesibilitatea prezintă legile naționale și amenzile.

Equality Act 2010 (se deschide într-o filă nouă) din Regatul Unit cere adaptări rezonabile pentru persoanele cu dizabilități, dar nu stabilește un standard tehnic pentru site-uri. În SUA, ghidul Departamentului de Justiție din martie 2022 (se deschide într-o filă nouă) spune că firmele deschise publicului trebuie să facă accesibil ceea ce oferă online și că standarde precum WCAG „oferă îndrumări utile”. Orice ar spune legea, un client care nu poate finaliza comanda nu cumpără.

Care sunt cele mai frecvente probleme de accesibilitate de pe site-uri?

Domină șase erori. În WebAIM Million 2026 (se deschide într-o filă nouă), o scanare automată a primelor un milion de pagini principale, făcută în februarie 2026, 95,9% dintre pagini aveau erori WCAG detectate, în medie 56,1 erori pe pagină. Textul cu contrast scăzut a fost cea mai frecventă problemă, prezentă pe 83,9% dintre paginile principale.

WCAG, Ghidul pentru accesibilitatea conținutului web, este standardul din spatele acestor verificări; majoritatea legilor trimit la nivelul său AA, iar ghidul nostru despre WCAG 2.2 explică cea mai recentă versiune. Mai multe verificări de mai jos sunt lucruri pe care niciun scanner nu le poate evalua.

Poate toată lumea să vă citească textele și să vă înțeleagă imaginile?

Începeți de aici, pentru că aceste corecturi sunt ieftine și le puteți face în mare parte chiar dumneavoastră, în editorul site-ului. Textul are nevoie de contrast suficient, imaginile care transmit informații au nevoie de text alternativ și nimic nu ar trebui să se bazeze doar pe culoare. Aproximativ 1 din 12 bărbați și 1 din 200 de femei au o deficiență de vedere a culorilor, potrivit Colour Blind Awareness (se deschide într-o filă nouă).

• Contrast. Textul normal are nevoie de un raport de contrast de cel puțin 4,5:1 (se deschide într-o filă nouă) față de fundal, iar textul mare de cel puțin 3:1. Testați-vă culorile, inclusiv textul peste fotografiile din bannere, într-un verificator gratuit. Ghidul nostru despre contrastul culorilor arată corecturi care vă păstrează identitatea vizuală.
• Textul alternativ al produselor. Descrieți ce trebuie să știe cumpărătorul: „Pulover bleumarin din lână, cu guler înalt răsfrânt, tricotat în coaste, vedere din față” spune mult mai mult decât „imagine produs 1”. Începeți cu cele mai vândute zece produse.
• Imaginile decorative. Un ornament de fundal ar trebui să aibă textul alternativ gol, ca cititoarele de ecran să îl sară. Unele platforme completează un câmp alt gol cu numele fișierului, așa că verificați-o pe a dumneavoastră.
• Doar culoarea. „Stoc epuizat” indicat doar printr-o mostră de culoare estompată sau un câmp obligatoriu marcat doar cu roșu nu ajunge la toată lumea. Priviți pagina cu filtrul de tonuri de gri al telefonului și adăugați un cuvânt sau o pictogramă oriunde se pierde sensul.
• Zoom. La un zoom de 200% în browser, textul ar trebui să se mărească fără să se suprapună sau să fie tăiat, iar meniul ar trebui să funcționeze în continuare.
• Limba paginii. Orice verificator gratuit semnalează lipsa declarației de limbă. Este o setare a temei sau o modificare de un rând în șablon.

Se poate folosi site-ul dumneavoastră cu tastatura?

Mulți oameni navighează fără mouse: utilizatorii de cititoare de ecran, persoanele cu tremor sau cu mișcări limitate ale mâinii și oricine tocmai a rămas cu touchpadul stricat. Lăsați mouse-ul deoparte și apăsați Tab. Ar trebui să ajungeți la fiecare link, buton și câmp de formular într-o ordine logică, să vedeți mereu unde vă aflați și să nu vă blocați niciodată.

• Focalizare vizibilă. Un contur ar trebui să arate care element este activ, iar un antet fix sau o bulă de chat nu are voie să îl acopere (criteriul 2.4.11 Focalizare neacoperită din WCAG 2.2). Multe teme elimină conturul din motive estetice; un dezvoltator îl poate readuce.
• Fără capcane. Deschideți de la tastatură meniul, selectorul de mărime, ferestrele pop-up și galeria de imagini, alegeți ceva, apoi încercați să ieșiți. Tasta Escape ar trebui să închidă ferestrele pop-up.
• Nume pentru pictograme. Fiecare link și buton cu pictogramă are nevoie de un nume pe care un cititor de ecran îl poate anunța, de exemplu „Coș, 2 produse”. Înlocuiți „Click aici” cu cuvinte care spun unde duce linkul.
• Link de salt și titluri. Ideal, prima apăsare pe Tab afișează un link „Salt la conținut”. În sondajul WebAIM din 2024 despre cititoarele de ecran (se deschide într-o filă nouă), 71,6% dintre respondenți au spus că se orientează într-o pagină lungă mai întâi după titluri, așa că folosiți niveluri reale de titlu, nu text îngroșat.
• Ținte de atingere. WCAG 2.2 cere ținte de cel puțin 24 pe 24 de pixeli CSS sau suficient spațiu în jurul lor (criteriul de succes 2.5.8 (se deschide într-o filă nouă)).

Poate toată lumea să treacă prin formulare, coș și finalizarea comenzii?

La finalizarea comenzii, problemele de accesibilitate vă costă direct bani, așa că testați-o de la început până la sfârșit, inclusiv ce se întâmplă când ceva merge prost. Fiecare câmp are nevoie de o etichetă vizibilă, erorile trebuie să explice problema în cuvinte, iar autentificarea nu ar trebui să depindă de teste de memorie sau de puzzle-uri. Contează și paginile furnizorului de plăți.

• Etichete, nu texte substituente. Textul substituent dispare imediat ce cineva începe să tasteze și este adesea prea palid ca să poată fi citit. Fiecare câmp are nevoie de o etichetă care rămâne vizibilă.
• Mesaje de eroare. Trimiteți formularul gol. Fiecare eroare ar trebui să fie scrisă explicit („Introduceți un cod poștal, de exemplu 010011”), să stea lângă câmpul ei și să fie anunțată, nu doar să coloreze o margine în roșu.
• Nu cereți de două ori. Oferiți opțiunea „Adresa de facturare este aceeași” în loc să îi puneți pe oameni să tasteze din nou adresa de livrare. WCAG 2.2 a făcut din asta o cerință de nivel A, 3.3.7 Introducere redundantă.
• Autentificarea. Permiteți lipirea parolelor și a codurilor unice și folosirea managerelor de parole. Blocarea lipirii încalcă criteriul Autentificare accesibilă (se deschide într-o filă nouă) din WCAG 2.2, dacă nu oferiți o altă cale de acces.
• CAPTCHA. În sondajul WebAIM din 2024, utilizatorii de cititoare de ecran au clasat CAPTCHA drept cel mai problematic element de pe web. Dacă aveți nevoie de protecție împotriva roboților, evitați puzzle-urile vizuale și oferiți întotdeauna o alternativă nevizuală.
• Limite de timp. Dacă un coș sau o rezervare temporară expiră, avertizați oamenii și permiteți-le să prelungească timpul.

Dacă anumite părți ale finalizării comenzii aparțin platformei sau furnizorului de plăți, testați-le oricum, raportați problemele și treceți-le pe lista problemelor cunoscute.

Ce faceți cu bannerele pentru cookie-uri, ferestrele pop-up și widgeturile de chat?

Pentru clienții dumneavoastră, scripturile de la terți fac parte din site. Un banner pentru cookie-uri care nu poate fi închis cu tastatura blochează fiecare pagină, iar o fereastră pop-up de newsletter care preia focalizarea în mijlocul finalizării comenzii poate opri o vânzare. Testați fiecare script pe care l-ați adăugat și întrebați furnizorii despre accesibilitate înainte să instalați unul nou.

• Bannerul pentru cookie-uri. Puteți ajunge cu Tab la butoanele de acceptare și de refuz, le puteți citi la un zoom de 200% și puteți continua apoi de unde ați rămas?
• Ferestrele pop-up. Focalizarea ar trebui să intre în fereastră, să rămână acolo până la închidere, apoi să revină. Tasta Escape ar trebui să o închidă.
• Widgeturile de chat. Butonul are nevoie de un nume, fereastra ar trebui să se deschidă și să se închidă de la tastatură, iar pe telefon nu ar trebui să acopere butonul „Plătește acum”.
• Caruselele. Tot ce se mișcă automat mai mult de cinci secunde are nevoie de o modalitate de a fi pus pe pauză, oprit sau ascuns (WCAG 2.2 (se deschide într-o filă nouă), criteriul de succes 2.2.2).
• Elementele încorporate. Widgeturile de recenzii, hărțile și instrumentele de rezervare stau tot pe pagina dumneavoastră. Semnalați erorile furnizorului.

Funcționează videoclipurile, fișierele PDF și meniurile pentru toată lumea?

Videoclipurile au nevoie de subtitrări, înregistrările audio de transcrieri, iar informațiile importante nu ar trebui să existe doar într-un PDF sau într-o imagine. Un restaurant al cărui meniu este un PDF scanat sau un magazin al cărui ghid de mărimi este fotografia unui tabel îi exclude pe utilizatorii de cititoare de ecran și pe oricine are nevoie să mărească pagina pe telefon.

• Subtitrări și transcrieri. Corectați subtitrările automate înainte de publicare. Podcasturile au nevoie de o versiune text.
• Text în imagini. Puneți meniurile, listele de prețuri, ghidurile de mărimi și programul de funcționare pe o pagină web obișnuită. Dacă trebuie neapărat să folosiți un PDF, exportați-l din editorul de text cu titluri și etichete, în loc să scanați o pagină tipărită.
• Fișierele mai vechi. EAA nu vă obligă să corectați documentele de birou sau conținutul audio și video preînregistrat publicate înainte de 28 iunie 2025 ori arhivele pe care nu le mai actualizați (articolul 2 alineatul (4)). Fișierele noi intră sub incidența actului.

Ce pot corecta singur și când am nevoie de un dezvoltator sau de un audit?

Cele mai multe probleme de conținut le puteți corecta chiar dumneavoastră în CMS: textul alternativ, titlurile, textul linkurilor, culorile, subtitrările și multe etichete de formular. Problemele de la nivelul temei, cum ar fi lipsa stilurilor de focalizare, capcanele de tastatură și meniurile derulante personalizate, cer un dezvoltator. Un audit este cel mai util după ce ați rezolvat elementele de bază sau înainte de lansarea unui site reproiectat.

Unde își are locul un widget ca al nostru? Un panou pentru vizitatori, cum ar fi SiteAccessible, le permite oamenilor să crească contrastul, să mărească textul sau să activeze un ghid de citire. Asta îi ajută pe unii vizitatori, dar nu bifează nimic de pe această listă: un buton fără nume rămâne fără nume, iar o capcană de tastatură rămâne o capcană. Corectați mai întâi site-ul și tratați widgetul ca pe un plus.

Cum consemnez ce am făcut?

Țineți un jurnal simplu cu ce ați testat, când, ce ați corectat și ce nu funcționează încă, apoi publicați un rezumat onest într-o declarație de accesibilitate. Dacă EAA vi se aplică, trebuie să publicați și informații despre modul în care serviciul dumneavoastră îndeplinește cerințele de accesibilitate, de obicei în termenii și condițiile generale sau într-un document echivalent.

A doua obligație vine din anexa V a directivei; forma o stabilește legea națională. Ghidul nostru despre redactarea unei declarații de accesibilitate include un model pe care îl puteți adapta. Apoi păstrați rutina:

1. Aplicați lista pe cele trei pagini-cheie și faceți o captură de ecran pentru fiecare eroare.
2. Corectați chiar dumneavoastră elementele de conținut, încă de săptămâna aceasta.
3. Dați-i unui dezvoltator sarcinile legate de temă și de finalizarea comenzii, începând cu cele mai grave.
4. Retestați fiecare corectură atât cu tastatura, cât și cu un verificator.
5. Publicați sau actualizați declarația, cu data la zi.
6. Repetați de fiecare dată când adăugați o aplicație, schimbați tema sau lansați o pagină de destinație nouă.