Accesibilitate aplicații mobile

Accesibilitatea aplicațiilor mobile: audit pentru iOS și Android, conform WCAG, EN 301 549 și Legii nr. 232/2022

Pentru mulți clienți, aplicația mobilă a devenit principalul canal de relație cu o companie: acolo își verifică contul, comandă, își cumpără biletul sau cer ajutor. Dacă aplicația nu poate fi folosită cu un cititor de ecran, cu textul mărit sau fără sunet, o parte dintre clienți rămân pe dinafară. Din 28 iunie 2025, pentru multe companii, asta înseamnă și o problemă de conformitate.

Vă oferim audit de accesibilitate pentru aplicații mobile: testare pe dispozitive reale, cu VoiceOver și TalkBack, testare cu persoane cu dizabilități și un raport cu recomandări concrete pentru echipa sau furnizorul care dezvoltă aplicația. Auditul poate fi plătit prin mecanismul unităților protejate.

Ce cere legea pentru aplicațiile mobile

Legea nr. 232/2022

Actul european privind accesibilitatea, transpus prin Legea nr. 232/2022, se aplică din 28 iunie 2025 și cere ca serviciile vizate să fie accesibile pe toate canalele, inclusiv pe dispozitive mobile și prin aplicații mobile. Sunt vizate, printre altele:

• aplicațiile de internet banking și de plată pentru consumatori;
• aplicațiile magazinelor online și ale platformelor de comerț electronic;
• aplicațiile operatorilor de transport de pasageri, cu bilete electronice și informații de călătorie;
• aplicațiile operatorilor de telecomunicații;
• aplicațiile pentru cărți electronice și cele care oferă acces la conținut audiovizual.

Microîntreprinderile care furnizează servicii sunt în principiu exceptate. Pentru celelalte companii, amenzile pot ajunge la 15.000 de lei pentru o abatere, iar autoritățile pot dispune și măsuri complementare.

Aplicațiile instituțiilor publice

OUG nr. 112/2018 cere ca site-urile și aplicațiile mobile ale organismelor din sectorul public să fie accesibile, iar pentru aplicațiile mobile obligația se aplică încă din 2021. În plus, Legea nr. 448/2006 (art. 71) le cere instituțiilor publice să țină cont de criteriul de accesibilitate atunci când cumpără echipamente și software. Dacă dezvoltați aplicații pentru sectorul public, accesibilitatea face parte din ce vi se poate cere la recepție.

Ce standard se aplică

Pentru aplicațiile native, referința este capitolul despre software din standardul european EN 301 549, care preia criteriile WCAG 2.1 de nivel AA și le adaptează pentru aplicații. Le completăm cu ghidurile de accesibilitate ale Apple și Google, ca recomandările să se potrivească fiecărei platforme. La cerere, verificăm și criteriile noi din WCAG 2.2, multe dintre ele foarte relevante pe mobil, cum ar fi dimensiunea minimă a zonelor de atingere sau alternativele la tragere.

Cum audităm o aplicație mobilă

1. Stabilim scopul. Alegem împreună platformele, versiunile de sistem și fluxurile importante: instalarea și prima pornire, crearea contului și autentificarea, căutarea, coșul și plata, profilul, notificările și contactul cu suportul.
2. Primim o versiune de test. De regulă, un build prin TestFlight pentru iOS și unul de testare internă pentru Android, plus conturi de test. Putem audita și versiunea publicată în magazinele de aplicații.
3. Verificări automate de bază. Folosim instrumente precum Accessibility Inspector din Xcode și Accessibility Scanner pentru Android. Ele prind doar o parte din probleme, așa că sunt doar punctul de plecare.
4. Audit manual pe dispozitive reale. Parcurgem fiecare flux cu VoiceOver și TalkBack, cu mărirea ecranului și cu textul la dimensiunile cele mai mari, în ambele orientări, cu o tastatură externă și cu comenzi vocale, și verificăm contrastul și ordinea focusului.
5. Testare cu persoane cu dizabilități. Utilizatori cu dizabilități folosesc aplicația așa cum o fac zilnic.
6. Raport și recomandări. Documentăm fiecare problemă și o legăm de criteriul WCAG și de capitolul corespunzător din EN 301 549.
7. Retestare. După ce echipa dumneavoastră corectează problemele, verificăm din nou și confirmăm ce s-a rezolvat.

Ce verificăm pe fiecare ecran

• dacă fiecare element are un nume, un rol și o stare corecte pentru VoiceOver și TalkBack;
• dacă titlurile secțiunilor sunt marcate, ca utilizatorul să poată sări între ele cu rotorul sau cu meniul de navigare al cititorului de ecran;
• dacă focusul ajunge unde trebuie după deschiderea unei ferestre, după o eroare sau după trecerea la alt ecran;
• dacă schimbările dinamice, precum încărcarea, confirmarea sau eroarea, sunt anunțate;
• dacă textul rămâne lizibil și complet la cele mai mari dimensiuni de font și cu textul îngroșat;
• dacă numele vizibil al unui buton apare și în numele lui accesibil, ca să poată fi activat prin comenzi vocale (2.5.3);
• dacă aplicația respectă setările pentru reducerea animațiilor și pentru contrast mărit;
• dacă modul întunecat păstrează contrastul cerut.

Ce primiți în raportul de audit

• un rezumat pentru management: nivelul actual de accesibilitate, riscurile principale și prioritățile;
• lista problemelor pe ecrane și fluxuri, cu pașii de reproducere și capturi de ecran;
• criteriul încălcat din WCAG și din EN 301 549, pentru fiecare problemă;
• gravitatea: critică, majoră sau minoră, ca echipa să știe ce rezolvă întâi;
• recomandări specifice platformei, de exemplu accessibilityLabel și trăsăturile de accesibilitate pe iOS, contentDescription și labelFor pe Android, proprietățile de accesibilitate din React Native sau widgetul Semantics din Flutter;
• constatările testerilor cu dizabilități;
• informațiile de care aveți nevoie pentru declarația de accesibilitate sau pentru obligația de informare din Legea nr. 232/2022.

Pentru aplicații, serviciul nostru este auditul. Corecțiile le face echipa dumneavoastră sau furnizorul aplicației, iar raportul este scris pentru ei: concret, pe ecrane, cu indicații tehnice acolo unde ajută.

Accesibilitatea, încă din faza de design

Cel mai ieftin moment pentru accesibilitate este înainte de prima linie de cod. Câteva recomandări pentru echipele care construiesc sau comandă o aplicație:

• includeți cerințele EN 301 549 în caietul de sarcini și în criteriile de recepție, mai ales când aplicația este făcută de un furnizor extern;
• folosiți un sistem de design cu componente accesibile, culori cu contrast verificat și dimensiuni minime pentru zonele de atingere;
• susțineți setările de text mare ale sistemului (Dynamic Type pe iOS, mărimea fontului pe Android) încă de la machete;
• dați un nume accesibil fiecărei iconițe și fiecărui buton grafic;
• oferiți întotdeauna o alternativă simplă la gesturile complexe;
• testați fiecare funcționalitate nouă cu VoiceOver și TalkBack înainte de lansare și includeți accesibilitatea în definiția de „gata” a echipei;
• planificați un audit înainte de lansare și după schimbările mari de interfață.

Problemele găsite devreme costă mult mai puțin decât corecțiile făcute după publicare, când fiecare modificare trece din nou prin testare și prin aprobarea magazinelor de aplicații.