Paano Gawing Accessible ang Iyong Website: Panimulang Gabay sa WCAG 2.2

Para gawing accessible ang website, itayo ito para magamit ng tao gamit ang keyboard, screen reader, zoom, o switch device at hindi lang ang mouse: gumamit ng totoong HTML element para sa button, link, heading, at label ng form; bigyan ng makabuluhang alt text ang mga larawan; panatilihing mataas ang contrast ng text at nakikita ang focus. Ang pamantayang dapat abutin ay WCAG 2.2 Level AA. Nahuhuli ng mga automated checker ang bahagi ng problema; ang sampung minutong pagsubok gamit ang keyboard at screen reader ang nakakahuli ng malaking bahagi ng iba.

Ano ang ibig sabihin ng "accessible" sa praktika

Tungkol sa tao ang accessibility: ang bulag na gumagamit ng screen reader, ang may panginginig na nag-navigate gamit ang keyboard, ang may mahinang paningin na nag-zoom sa 200%, ang nagbabasa sa matinding sikat ng araw, ang may pansamantalang sirang pulso. Kadalasang nagpapaganda ang mahusay na accessibility sa site para sa lahat: mas malinaw na istruktura, nababasang text, at mga form na nagpapaliwanag ng kanilang mga error.

Ang pamantayang sinusunod ay ang Web Content Accessibility Guidelines (WCAG) ng W3C. Pagsapit ng Setyembre 2026, ang kasalukuyang bersyon ay WCAG 2.2 (inilathala noong Oktubre 2023, na-update noong Disyembre 2024); maaga pa lang ang WCAG 3 at nasa draft. Nakaayos ang WCAG sa apat na prinsipyo: dapat maramdaman, magamit, maunawaan, at maaasahan ang nilalaman. May tatlong antas ng conformance ito:

May mga batas sa ilang lugar na tumutukoy sa WCAG, halimbawa ang European Accessibility Act, na nalalapat sa maraming digital na serbisyong para sa konsyumer sa EU mula Hunyo 2025. Nakasalalay sa kung saan ka nag-o-operate at kung ano ang ibinebenta mo kung aling mga patakaran ang nalalapat; kumonsulta sa tagapayo kung hindi ka sigurado. Sakop ng gabay na ito ang praktikal na gawain.

Mga opsyon: paano makarating doon

Para sa karamihan ng maliliit na site, sapat na ang unang dalawa: sabihin sa AI na buuing accessible mula sa simula, saka mag-audit bago ilunsad.

Ang mga pag-aayos na pinakamahalaga

Gamitin ang tamang HTML element

Kasama na sa tamang HTML ang karamihan ng accessibility. Nafo-focus ang <button>, gumagana sa Enter at Space, at binibigkas bilang button. Ang <div> na may click handler ay wala sa alinman sa mga iyon. Madalas gumamit ang code na gawa ng AI ng mga naka-istilong div para sa lahat; humingi ng semantic na element:

• <button> para sa mga aksyon, <a href> para sa navigation
• Isang <h1> kada page, saka <h2>, <h3> nang maayos ang pagkakasunod; tumatalon ang mga gumagamit ng screen reader sa pagitan ng mga heading
• Mga landmark: <header>, <nav>, <main>, <footer>
• <label> na nakakabit sa bawat field ng form
• Ang wika ng page sa <html lang="en">

Gamitin lang ang mga ARIA attribute kapag walang native na element na angkop; halimbawa para sa custom na set ng tab o combobox. Mas masama ang maling ARIA kaysa wala.

Keyboard access at nakikitang focus

Dapat magawa gamit lang ang keyboard ang lahat ng kaya mong gawin sa mouse (WCAG 2.1.1). Pindutin ang Tab sa buong page: dapat maabot ang bawat link, button, at field sa maayos na pagkakasunod, at laging makikita kung nasaan ang focus (2.4.7 Focus Visible). Idinagdag ng WCAG 2.2 na hindi dapat ganap na natatakpan ng sticky header o cookie banner ang nakatutok na elemento (2.4.11, Level AA).

Karaniwang pumapalya: mga menu na bumubukas lang kapag hinovera, mga modal na hindi nagki-kulong ng focus o hindi nagsasara gamit ang Escape, at outline: none sa CSS na walang kapalit.

Mga alternatibong text

Kailangan ng bawat makabuluhang larawan ng alt text na nagsasabi kung ano ang ipinapakita nito sa konteksto ("Chef na naghahain ng tasting menu", hindi "image1.jpg"). Bigyan ng walang lamang alt="" ang mga pandekorasyong larawan para lampasan ng screen reader ang mga ito. Kailangan ng accessible na pangalan ang mga icon-only na button ("Close", "Search"). Kailangan ng caption ang mga video; kailangan ng transcript ang audio.

Kulay at contrast

Hinihingi ng WCAG 2.2 AA ang contrast ratio na hindi bababa sa 4.5:1 para sa normal na text at 3:1 para sa malaking text (1.4.3), at 3:1 para sa mga bahagi ng interface gaya ng border ng input at mga makabuluhang icon (1.4.11). Ang light-grey na placeholder text at maputlang button ang karaniwang pumapalya. Huwag ding gamitin lang ang kulay para magdala ng kahulugan; ang pulang border sa hindi wastong field ay kailangan ding may mensahe ng error.

Pag-resize at reflow

Dapat manatiling magagamit ang text kapag na-zoom sa 200% (1.4.4), at dapat gumana ang nilalaman sa lapad na 320 CSS pixel nang walang sideways na pag-scroll (1.4.10). Malaki ang naitutulong ng isang responsive na layout dito.

Target na sukat, mga form, at error

• Sukat ng target: hinihingi ng WCAG 2.2 AA ang mga pointer target na hindi bababa sa 24 by 24 CSS pixel, o sapat na espasyo sa paligid ng mas maliliit (2.5.8). Mas mabuti ang mas malaki para sa mga phone.
• Mga form: nakikitang label (hindi lang placeholder), malinaw na tagubilin, at mga mensahe ng error na nagsasabi kung ano ang mali at paano ito aayusin, nasa tabi ng field.
• Login: huwag pahirapan ang tao sa puzzle o pag-transcribe ng code nang walang alternatibo; payagan ang password manager at pag-paste (3.3.8 Accessible Authentication).

Mga prompt na gumagana

Buuin ang site na ito para matugunan ang WCAG 2.2 Level AA: semantic HTML landmark, isang h1 kada page na may mga heading na maayos ang pagkakasunod, totoong button at link element, label sa bawat field ng form, nakikitang focus style, text contrast na hindi bababa sa 4.5:1, alt text sa mga makabuluhang larawan at alt="" sa mga pandekorasyon, at naka-set na html lang.

I-audit ang mga pahinang /signup at /checkout para sa accessibility. Suriin ang paggamit gamit lang ang keyboard, focus order, nakikitang focus, label, mensahe ng error, contrast, at pangalan para sa screen reader ng mga icon button. Ilista ang bawat problema kasama ang WCAG criterion, saka ayusin ang mga ito nang hindi binabago ang visual na disenyo nang higit sa kailangan.

Hindi magamit gamit ang keyboard ang mobile menu. Gawin itong button na may aria-expanded, ilipat ang focus sa loob ng menu kapag bumukas ito, isara ito gamit ang Escape, at ibalik ang focus sa button.

Hakbang-hakbang

1. Magpatakbo ng automated na check. Ang seksyong Accessibility ng Lighthouse sa Chrome DevTools, o ang axe browser extension, sa bawat pangunahing page. Ayusin ang lahat ng iniulat nito.
2. Tanggalin ang mouse. I-Tab ang bawat page at kumpletuhin ang bawat pangunahing gawain: mag-sign up, maghanap, mag-checkout. Itala ang anumang hindi mo maabot, hindi makita ang focus, o hindi mo malabasan.
3. I-zoom sa 200% at paliitin ang window sa lapad ng phone. Walang dapat maputol o mangailangan ng sideways na pag-scroll.
4. Subukan ang screen reader nang sampung minuto: VoiceOver sa Mac at iPhone, TalkBack sa Android, o NVDA sa Windows (libre). Pakinggan ang mga heading, link, at field ng form. Ang "Button" na walang pangalan, o "link, click here", ay trabahong kailangang ayusin.
5. I-check ang contrast ng text, button, at input gamit ang contrast checker.
6. Ayusin, saka subukan ulit ang parehong gawain.
7. Mag-publish ng accessibility statement na nagsasabi kung anong pamantayan ang tinatarget mo at kung paano iulat ang mga problema, at sagutin ang mga ulat na iyon.

Mga karaniwang pagkakamali

• Pag-asa sa overlay widget sa halip na pag-aayos ng code.
• Pagtanggal ng focus outline dahil mukhang magulo, nang walang kapalit.
• Placeholder text bilang nag-iisang label. Nawawala ito kapag nagsimulang mag-type ang tao at madalas mababa ang contrast.
• "Click here" at "Read more" na link. Kapag nasa labas ng konteksto, paulit-ulit na link ang naririnig ng gumagamit ng screen reader.
• Alt text na puno ng keyword. Para sa tao ang alt text; ilarawan ang larawan.
• Isang beses lang sinusubukan. Maaaring masira ng bawat bagong feature ang keyboard access. Magdagdag ng pagsusuri gamit ang keyboard sa iyong pagsubok bago ilunsad.

Checklist ng accessibility

• Malinis ang automated check (Lighthouse o axe) sa mga pangunahing page
• Makukumpleto ang bawat gawain gamit lang ang keyboard
• Laging nakikita ang focus at hindi natatakpan ng sticky na elemento
• Semantic na heading, landmark, button, at link; naka-set ang lang
• Makabuluhang alt text; alt="" sa mga pandekorasyong larawan; caption sa video
• Text contrast na ≥ 4.5:1 (malaking text ≥ 3:1); mga bahagi ng UI ≥ 3:1
• Gumagana sa 200% zoom at 320 px na lapad
• May nakikitang label at malinaw na mensahe ng error ang bawat field ng form
• May accessibility statement na may paraan para mag-ulat ng problema

Para sa mga konseptong nasa likod nito, basahin ang ano ang web accessibility. Malaki ang magkakapatong ng accessible na disenyo at magandang disenyo; sakop ng paano gumawa ng magandang app gamit ang AI ang bahaging biswal.

Accessibility sa Mythex

Gumagawa ang Mythex ayon sa pamantayang hinihingi mo, kaya ilagay ang "WCAG 2.2 AA" sa unang prompt mo at sa mga follow-up. Puwede mong gamitin ang phone-size frame ng Preview para suriin ang maliliit na screen (Preview and Code), pero mas maayos gumagana ang mga pagsubok sa keyboard, zoom, at screen reader sa na-publish na URL o sa preview na nakabukas sa sarili nitong tab. Hilingin sa agent na i-audit ang isang page, ayusin ang nakita nito, at pagkatapos ay ikaw mismo ang sumubok ng mga ayos; ang automated na pagsusuri ay simula pa lang, hindi pangwakas na pag-apruba.

Mga tanong