Accesibilitate Web în 2026: De Ce Widget-urile Overlay Nu Te Salvează de un Proces
Procesele federale de accesibilitate din SUA au ajuns la 3.117 în 2025, cu 27% mai multe decât anul anterior, iar European Accessibility Act e acum aplicat activ. Widget-ul bolt-on pe care majoritatea site-urilor l-a instalat ca să fie cu un pas înainte nu funcționează, și instanțele încep să o spună.
Accesibilitatea obișnuia să stea pe lista de „ar fi bine să avem”, undeva sub termenul de lansare și deasupra redesign-ului blogului. Lista aia nu mai descrie realitatea. În SUA, procesele federale de accesibilitate digitală au ajuns la 3.117 în 2025, cu 27% mai multe față de cele 2.452 din anul anterior, și peste 5.000 dacă numeri și procesele din instanțele statale. În UE, European Accessibility Act este aplicat activ din 28 iunie 2025, iar 2026 este primul an complet în care autoritățile naționale verifică efectiv. Ambele direcții indică spre același loc: orice e live pe domeniul tău chiar acum.
Procesele nu încetinesc
Cifra principală subestimează tendința, pentru că filările federale spun doar o parte din poveste: aproape 80% din plângerile de accesibilitate provin acum din instanțe statale, care nici nu apar în numărătoarea federală. E-commerce-ul poartă cea mai mare expunere, reprezentând aproximativ 70% din cazurile ADA web, dar nicio industrie nu e scutită: orice business care colectează un email, ia o rezervare sau vinde online e o țintă plauzibilă. Motivul pentru care cifrele continuă să crească nu e un mister. Audituri independente arată că doar 2% din paginile web trec de 70% sau mai mult din criteriile WCAG testabile, iar 95,9% din homepage-urile de top eșuează complet. Bazinul de site-uri neconforme e enorm, și e exact bazinul prin care lucrează firmele de avocatură specializate.
Europa a prins din urmă, și se aplică mai larg decât cred oamenii
European Accessibility Act (Directiva (UE) 2019/882) își fixează standardul tehnic prin EN 301 549, care se mapează direct pe WCAG 2.1 Nivel AA. Aplicarea a început la mijlocul lui 2025, iar până în 2026 efectul practic e vizibil: echipe de achiziții care cer furnizorilor dovezi de conformitate, autorități de supraveghere a pieței care solicită audituri și declarații de accesibilitate verificate atent, nu doar bifate din oficiu. Penalitățile variază pe stat membru, dar pot ajunge la 3.000.000 €, iar sfera nu se limitează la companiile cu sediul în UE: dacă vinzi către consumatori din UE, obligația urmează clientul, nu adresa biroului tău. O companie din SUA sau UK cu trafic european intră sub incidență chiar dacă nu s-a gândit niciodată la sine ca fiind o companie „din UE”.
De ce widget-ul rapid înrăutățește lucrurile, nu le rezolvă
Sub presiunea asta, mii de proprietari de site-uri au instalat un accessibility overlay: un fragment JavaScript care promite conformitate instant printr-un widget plutitor care ajustează contrastul, dimensiunea fontului și câteva atribute ARIA la runtime. E un shortcut atrăgător, și eșuează exact așa cum au avertizat criticii. Peste 1.000 de afaceri, mai mult de 25% din toate procesele de accesibilitate digitală depuse, au fost date în judecată deși aveau un overlay instalat; doar în mai 2025, 119 pârâți care foloseau overlay au fost numiți în procese noi. În aprilie 2025, FTC a obligat unul dintre cei mai mari furnizori de overlay să plătească 1 milion de dolari pentru afirmații false că tool-ul lui bazat pe AI poate face orice site conform WCAG.
| Widget Overlay | Accesibilitate Inginerită (Built-In) | |
|---|---|---|
| Ce atinge | DOM la runtime, după încărcarea paginii | HTML-ul / markup-ul sursă în sine |
| Ce văd scanerele & screen readerele | Adesea codul de bază neschimbat | Fixul real, de fiecare dată |
| Poziție legală | Citat în 25%+ din procesele din 2025, deși instalat | Adresează criteriile WCAG verificate de instanțe |
| Poziția FTC/reglementatorilor (2025-26) | Un furnizor major amendat cu 1M$ pentru afirmații false | Nu există shortcut de dezinformat |
| Mentenanță | Versiune nouă de widget, aceleași goluri de bază | Reparat o dată, rezistă pe măsură ce site-ul evoluează |
Motivul tehnic e simplu odată ce îl vezi: overlay-urile modifică pagina pe care browser-ul o randează după fapt, dar scanerele automate și majoritatea tehnologiilor asistive citesc HTML-ul de bază pe care serverul îl trimite de fapt. Un widget care reordonează vizual focus-ul sau injectează o etichetă ARIA la runtime adesea nu schimbă cu nimic markup-ul pe care un scaner (sau un screen reader care parsează DOM-ul înainte ca scriptul să termine) îl întâlnește de fapt. Mai rău, mai multe decizii de instanță tratează acum un overlay instalat ca dovadă că proprietarul site-ului știa că accesibilitatea e o problemă și a ales o soluție superficială în loc de una reală, ceea ce avocații reclamanților citesc ca o poziție mai slabă decât dacă n-ar fi făcut nimic.
Ce chiar trece: e o problemă de cod, nu de plugin
Conformitatea WCAG 2.1 AA e o listă de cerințe testabile și specifice, iar aproape toate țin de felul în care e construită pagina, nu de ce se adaugă ulterior pe deasupra: HTML semantic, ca un screen reader să poată identifica titluri, liste și landmark-uri în loc să ghicească din layout-ul vizual; operabilitate completă de la tastatură, adică fiecare element interactiv (meniuri, modale, slidere custom) funcționează fără mouse și nu blochează niciodată focus-ul; rapoarte de contrast de culoare de cel puțin 4,5:1 pentru text de bază; text alt relevant pe imaginile informative și atribute alt goale pe cele decorative; și câmpuri de formular cu etichete programatice reale, nu text placeholder care ține loc de una. Nimic din toate astea nu poate fi peticit printr-un script care rulează după ce pagina se încarcă. Trebuie să fie adevărat despre markup-ul în sine.
De ce asta favorizează site-urile inginerite față de șabloane și widget-uri
E același tipar care apare la Core Web Vitals și la datele structurate pentru căutarea AI: munca ce trebuie să se întâmple la nivel de cod e ușoară pe o bază de cod construită cu intenție și grea pe una asamblată din setările implicite ale altcuiva. Pe un build custom Next.js, structura semantică, comportamentul de la tastatură și contrastul sunt decizii de design și inginerie luate o singură dată, revizuite ca orice altă bucată de cod și consistente pe fiecare pagină pentru că există o singură librărie de componente, nu un teanc de widget-uri terțe care fac fiecare propriile presupuneri. Pe un site pe page builder sau șablon, accesibilitatea e de obicei tratată la fel ca SEO-ul: printr-un plugin care încearcă să ghicească intenția dintr-un markup care nu a fost organizat cu intenția aia în minte, exact golul pe care overlay-urile există ca să-l acopere și exact golul care continuă să eșueze în instanță.
Ce verifici acum
Pornește de la o bază onestă, nu de la un badge de conformitate al unui furnizor: rulează un scaner automat precum axe sau WAVE pe paginile tale principale, apoi completează-l cu o trecere reală doar de la tastatură, pentru că tool-urile automate prind cel mult o treime din problemele WCAG și ratează aproape toate problemele de tastatură și screen reader. Repară ce găsești la nivel de markup, publică o declarație de accesibilitate care descrie conformitatea reală, actuală, nu un limbaj aspirațional, și tratează paginile noi ca vinovate până se dovedește conformitatea, nu ca pe ceva de retrofit-uit o dată pe an. Nimic din toate astea nu e muncă exotică, și nimic nu mai e opțional. Site-urile care absorb valul actual de procese și acțiuni de aplicare sunt, aproape fără excepție, cele care au încercat să cumpere o cale pe lângă cerință, în loc să construiască pentru ea.