Articolul Ce trebuie să știți despre schimbările viitoare ale WCAG
Publicat: 2022-10-07În septembrie 2022, W3C a anunțat că următoarea versiune a WCAG a atins statutul de recomandare a candidaților. Cu excepția oricăror modificări din a unsprezecea oră, versiunea 2.2 a standardului ar trebui ratificată în curând. Modificările sunt relativ minore, dar orice persoană responsabilă pentru construcția sau întreținerea unui site web ar trebui să știe ce urmează.
Dacă sunteți deja familiarizat cu WCAG, puteți sări peste prezentarea generală și să treceți direct la detaliile tocilar, în caz contrar, citiți mai departe.
Ce sunt WCAG și de ce contează?
Ghidurile de accesibilitate a conținutului web (WCAG) cuprind un set de criterii concepute pentru a ajuta dezvoltatorii web, designerii și administratorii de conținut să se asigure că site-urile lor web sunt accesibile persoanelor cu o gamă largă de dizabilități. Echipa Web Accessibility Initiative a W3C este responsabilă pentru standard. W3C și WAI cuprind un consorțiu de lideri din industrie și experți în domeniu, concentrați pe a face web-ul mai accesibil.
WCAG este organizat pe patru principii de accesibilitate. Aceste principii afirmă că un site web trebuie să fie perceptibil, operabil, ușor de înțeles și robust. În fiecare dintre aceste principii există linii directoare care descriu obiectivele de bază. În fiecare ghid există criterii de succes care descriu un obiectiv specific, măsurabil, pe care dezvoltatorii de site-uri web ar trebui să-l îndeplinească pentru a fi conform WCAG.
Criteriile de succes au fiecare un indicator de nivel de conformitate A, AA sau AAA. Criteriile de nivel A sunt mai ușor îndeplinite, în timp ce AAA este cel mai strict.
Voi fi dat în judecată dacă site-ul meu nu este compatibil cu WCAG 2.2 AA?
Răspunsul definitiv este „poate”.
În SUA, legile sunt ambigue, iar ADA nu se adresează în mod explicit site-urilor web. Deși există legi foarte specifice cu privire la acomodarile care trebuie făcute într-un spațiu fizic, singurul lucru pe care ADA spune că poate fi aplicat direct pe site-uri web este că „facilitățile unei companii trebuie să fie accesibile”. Chiar și atunci, nu toate instanțele sunt de acord dacă un site web contează ca facilitate a unei companii și nicăieri nu există o definiție clară a termenului „accesibil”. Rețineți că vorbim despre site-urile web ale companiilor private și despre legile federale. Pentru site-urile web ale guvernelor federale și ale unor state, există legi care se aplică.
Deoarece nu există o definiție clară a termenului „accesibil”, ne uităm la WCAG pentru a ne spune ce să facem atunci când construim sau întreținem un site web. Nicio lege din SUA nu recomandă în mod specific vreo versiune a WCAG (sau orice alt standard) pentru site-urile web publice. Cu toate acestea, străduința de a îndeplini orice versiune a criteriilor de succes WCAG este un obiectiv bun. Ar trebui să conducă la un site care este rezonabil accesibil pentru toți.
Cum sunt dezvoltate standardele?
Contrar credinței populare, dezvoltarea standardelor nu este realizată într-un turn de fildeș de către o mână selectă de participanți. Deși o mare parte a muncii este efectuată de angajați ai organizațiilor membre, o mare parte a muncii provine de la experți invitați și alte persoane care sunt pasionate de subiect și sunt dispuși să-și dea timp. În plus, multe echipe de standardizare au forumuri publice deschise în care membrii comunității în general sunt încurajați să participe punând întrebări sau ridicând noi probleme.
Pentru WCAG, publicul poate citi despre standarde și poate comenta despre acestea, deschizând o nouă problemă, o cerere de extragere sau doar participând la discuțiile existente la depozitul WCAG de pe Github. Când veniți la grup cu o idee, este întotdeauna înțelept să căutați toate problemele existente și să obțineți solicitări pentru a vă asigura că ideea dvs. nu a fost deja adusă la masă. Dacă vă gândiți să contribuiți la WCAG cu o cerere de tragere, faceți-vă întotdeauna timp pentru a deschide o problemă și a discuta mai întâi ideea dvs. Există șanse foarte mari să vă economisiți ceva muncă inutilă.
Contribuția la standarde poate fi frustrantă și dificilă, dar este și foarte plină de satisfacții. În cea mai mare parte, participanții sunt foarte primitori și răbdători. Dacă îți faci timp să-ți cercetezi ideile, să-ți faci diligența cuvenită și ești politicos și respectuos cu ceilalți, atunci contribuțiile tale vor fi binevenite. Cel mai rău rezultat posibil este că te vei familiariza cu subiectul mai mult decât ai crezut vreodată că este posibil.
Ce se schimbă?
Un criteriu de succes existent s-a schimbat în WCAG 2.2 și au fost adăugate nouă criterii de succes noi. Aici ne vom limita doar la nivelurile A și AA, deoarece țintim rar AAA. Pentru a vedea toate noile criterii, consultați articolul complet de la W3C,
2.4.7 Focalizare vizibilă (A)
Acest criteriu s-a schimbat de la Nivelul AA la A, care este bara cea mai joasă pentru conformitatea cu WCAG. O parte din motivul pentru care există este că, în trecutul nu atât de îndepărtat, era o practică comună pentru persoanele care construiau site-uri web să elimine inelele de focalizare. La urma urmei, nu au făcut parte din design. Aceasta însemna că utilizatorii care navigau pe o pagină web cu tastatura lor nu puteau vedea unde se aflau pe o pagină. Este logic ca acest criteriu să fie mutat la single-A deoarece un număr atât de mare de utilizatori depind de navigarea cu tastatura, chiar și cei fără nicio formă de afectare.
Toate browserele web majore vor afișa inele de focalizare în mod implicit. Cerința cheie aici este să nu spargeți funcționalitatea încorporată.
W3C – Înțelegerea focalizării vizibile
2.4.11 Aspectul de focalizare (AA)
Acest nou criteriu definește câteva reguli clarificatoare cu privire la vizibilitatea inelelor de focalizare. Trebuie să aibă un raport de contrast de 3:1 cu pixelii din jur și cu pixelii pe care îi înlocuiesc. De asemenea, trebuie fie să includă elementul sau subcomponenta care este focalizată, fie să fie la fel de mare ca o linie groasă de 4 pixeli de-a lungul marginii celei mai scurte a elementului.
Din nou, inelele de focalizare implicite ale browserului vor îndeplini de obicei acest criteriu. Deoarece utilizatorii sunt obișnuiți cu valorile implicite, ar trebui să le înlocuiți numai dacă este necesar. Un exemplu ar putea fi dacă nu există un contrast de culoare insuficient între inelul de focalizare implicit și culoarea primară a mărcii dvs. De obicei, browserele folosesc inele de focalizare albastre, așa că dacă aveți albastru în paleta mărcii dvs., poate exista un conflict.
W3C – Înțelegerea aspectului focalizat
2.4.12 Focalizarea neascunsă (minimă) (AA)
Acest criteriu prevede că concentrarea nu trebuie să fie complet ascunsă de conținutul generat de utilizatori. Acest lucru este menit să împiedice conținutul stratificat, cum ar fi navigarea lipicioasă (o bară de meniu care rămâne în partea de sus a ferestrei în timp ce utilizatorul derulează), să acopere indicatorii de focalizare.
Cea mai ușoară soluție aici este pur și simplu să nu aveți elemente lipicioase. Cu toate acestea, site-urile web moderne folosesc în mod liberal navigarea lipicioasă și CTA-uri plutitoare, așa că probabil că aceasta nu este o opțiune. Există unele așteptări ca proprietățile CSS de scroll-padding și scroll-margin să ne permită într-o zi să definim un offset care să găzduiască navigarea lipicioasă. Deocamdată, acele proprietăți sunt folosite exclusiv pe elementele care folosesc aprinderea derulării.
Asta ne lasă cu JavaScript. În general, scopul nostru este să folosim JavaScript în browser numai atunci când este necesar. Această funcție StickyFix va monitoriza elementele focalizabile din interiorul elementului principal și, dacă acestea sunt ascunse de navigarea lipicioasă atunci când obțin focalizare, vor fi derulate în vizualizare.
Pentru a utiliza această funcție, includeți-o pur și simplu în fișierele JavaScript ale site-ului dvs.
/** * A minimal function that will detect if a focusable element is obscured by sticky navigation * This only works for sticky elements at the top of the page, but could be extended * @author Donovan Buck <[email protected]> * @param {string} selector - A valid CSS selector string for the sticky element * @param {number} offset - An additional offset for the focused element * * @see https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors * @tutorial https://www.brandextract.com/Insights/Articles/Changes-to-the-Web-Content-Accessibility-Guidelines/ * @license MIT */ function stickyFix(selector, offset = 0) { // Find the height of our sticky element const sticky = document.querySelector(selector); let stickyRect = sticky.getBoundingClientRect(); let stickyHeight = stickyRect.bottom - stickyRect.top; // Select all the focusable elements within the main element const focusables = document.querySelectorAll('main button:not([disabled]), main [href], main input:not([disabled]), main select:not([disabled]), main textarea:not([disabled]), main [tabindex]:not([tabindex="-1"]):not([disabled]), main details:not([disabled]), main summary:not(:disabled)'
); // Add a listener to each focusable element focusables.forEach(focusable => { focusable.addEventListener('focus', (event) => { const targetRect = event.target.getBoundingClientRect(); if(targetRect.top < stickyHeight + offset) { window.scrollTo({ top: targetRect.top + window.scrollY - stickyHeight - offset }); } }); }); };Apoi puteți apela funcția:
// Wait for the document to load document.addEventListener("DOMContentLoaded", function() { stickyFix('.sticky', 24); });Înțelegerea focalizării neascunse (minimum)
2.5.7 Mișcări de tragere (AA)
Acest criteriu afirmă că, dacă mișcările de glisare fac parte din interfața utilizatorului, atunci trebuie furnizată o metodă alternativă care să permită acțiuni simple de tip punct și clic. Un exemplu în acest sens ar putea fi un formular care permite utilizatorilor să tragă și să plaseze fișiere de pe computerul lor în browser pentru încărcare. Trebuie să vă asigurați că un utilizator poate folosi și dialogul de încărcare a fișierelor pentru a alege ce fișiere ar trebui să fie încărcate. Mișcările de tragere nu sunt, în general, necesare în majoritatea interfețelor de utilizare a site-urilor web, cu această excepție.
Înțelegerea mișcărilor de tragere
2.5.8 Dimensiunea țintei (minimă) (AA)
Orice țintă indicator trebuie să aibă cel puțin 24 x 24 de pixeli, cu excepția cazului în care ținta respectivă este la cel puțin 24 de pixeli distanță de fiecare țintă adiacentă sau ținta se află într-o propoziție sau bloc de text. Când verificați un design pentru acest criteriu, aveți mare grijă să verificați linkurile de partajare socială care folosesc doar pictograme și toate listele dvs. de navigare.
Înțelegerea dimensiunii țintei (minimum)
3.2.6 Ajutor constant (A)
Să presupunem că site-ul dvs. web conține detalii de contact, o opțiune de auto-ajutor sau orice mecanism de contact care apare pe mai multe pagini. În acest caz, acele elemente ar trebui să apară în aceeași ordine în raport cu conținutul altor pagini de pe site-ul dvs. Aceasta este în mare parte o funcție a unui design bun și consistent și acest criteriu nu ar trebui să fie dificil de îndeplinit.
Înțelegerea ajutorului consecvent
3.3.7 Autentificare accesibilă (AA)
Forțarea unui utilizator să-și amintească un nume de utilizator și o parolă poate crea o povară nejustificată pentru persoanele cu dizabilități cognitive. Din acest motiv, dezvoltatorii web nu ar trebui să creeze niciodată un proces de conectare care să interzică utilizarea managerilor de parole sau să copieze și să lipească. Acest criteriu permite metode alternative de autentificare, atâta timp cât acestea nu depind de un test al funcției cognitive, cum ar fi amintirea unei parole sau rezolvarea unui puzzle.
Înțelegerea autentificării accesibile
3.3.9 Intrare redundantă (A)
Acest criteriu prevede că orice informație introdusă anterior de utilizator în timpul aceluiași proces va fi auto-populată sau disponibilă pentru selectare de către utilizator, în loc să fie nevoie să reintroducă informațiile manual. Evident, aceasta ar trebui să fie o comoditate așteptată pentru oricine.
Înțelegerea intrării redundante
Referințe
- Ce este nou în WCAG 2.2 Draft
- Depozitul WCAG al W3C pe Github