Ano ang Web Accessibility? WCAG at Inclusive Design, Ipinaliwanag

Ang web accessibility ay pagbuo ng mga website at app para magamit ang mga ito ng mga taong may kapansanan — bulag at gumagamit ng screen reader, hindi kayang gumamit ng mouse, mahina ang paningin o color blind, bingi, o may kapansanan sa pag-iisip o pag-aaral. Sa praktika, nauuwi ito sa mga bagay gaya ng text alternative para sa mga larawan, sapat na color contrast, mga form na may tamang label, at lahat ng gumagana gamit lamang ang keyboard. Ang pandaigdigang pamantayan para dito ay ang WCAG, ang Web Content Accessibility Guidelines ng W3C.

Madalas paikliin ang accessibility bilang a11y — "a," saka 11 letra, saka "y."

Bakit mahalaga ang accessibility kapag gumagawa ka gamit ang AI

Magaling ang mga AI builder sa paggawa ng app na mukhang tama. Ang accessibility ay higit sa lahat tungkol sa mga bagay na hindi makikita sa screenshot: kung ang button ay tunay na button, kung may label ang input na kayang banggitin ng screen reader, kung maaabot ang menu gamit ang Tab key.

Kaya mahalagang itanong ito:

• Madaling makaligtaan. Maaaring magmukhang perpekto ang custom na dropdown pero imposibleng gamitin nang walang mouse. Hindi mo ito mapapansin maliban kung susubukan mo.
• Mas mura itong tama mula sa simula. Ang paghingi ng accessible na components sa unang prompt ay halos walang gastos. Ang pag-aayos ng tapos na app ay nangangailangan ng pagbabago sa bawat screen.
• Nakakatulong ito sa lahat. Nakakatulong ang captions sa maingay na lugar, ang magandang contrast sa mga telepono sa ilalim ng araw, at ang malinaw na label sa lahat na mas mabilis mapunan ang mga form.
• Nagkakapatong ito sa SEO. Ang tamang heading, mapaglarawang link, at alt text ay tumutulong din sa search engines na maintindihan ang mga page mo — tingnan ang SEO para sa mga website na gawa ng AI.
• Maaaring kailanganin ito ng batas. Depende sa lugar na pinapatakbuhan mo at sa pinaglilingkuran mo, maaaring maging legal na obligasyon ang accessibility.

Isang pang-araw-araw na halimbawa

Isipin ang pasukan ng isang gusali.

Gumagana ang hagdan para sa maraming tao. Ang rampa ay gumagana para sa mga gumagamit ng wheelchair — at pati sa mga magulang na may stroller, mga delivery worker na may kariton, at mga biyaherong may maleta. Ang automatic na pinto, malinaw na signage, braille sa mga button ng elevator, at magandang ilaw ay bawat isa ay nag-aalis ng isang harang para sa isang tao.

Pareho ang ideya ng web accessibility para sa digital na espasyo: ang mga rampa, signage, at handrail ng app mo. At gaya ng gusali, mas madaling isama ang rampa sa plano kaysa idagdag ito pagkatapos tumigas ang semento.

WCAG sa madaling salita

Inilalathala ang WCAG ng Web Accessibility Initiative ng W3C. Ang kasalukuyang bersyon ay WCAG 2.2, unang inilathala noong Oktubre 2023. Backwards compatible ito: ang content na sumusunod sa WCAG 2.2 ay sumusunod din sa 2.1 at 2.0, at hinihikayat ng W3C ang paggamit ng pinakabagong bersyon. Naaprubahan din ang WCAG 2.2 bilang pandaigdigang pamantayan, ISO/IEC 40500:2025. Ang lubhang ibang WCAG 3 ay nasa ilalim ng pagbuo bilang maagang draft, hindi tapos na pamantayan.

Nakaayos ang WCAG sa apat na prinsipyo, na kadalasang tinatandaan bilang POUR:

May nasusubok na success criteria ang bawat guideline sa tatlong antas:

• Level A — ang minimum. Ang pagkabigo rito ay ganap na humaharang sa ilang tao.
• Level AA — ang karaniwang target, at ang antas na itinuturo ng karamihan sa mga batas at patakaran.
• Level AAA — ang pinakamataas na antas. Mainam itong puntiryahin sa ilang bahagi, pero hindi inirerekomenda ng W3C na gawing kinakailangan para sa buong site, dahil may ilang content na hindi ito kayang abutin.

Nagdagdag ang WCAG 2.2 ng siyam na success criteria sa 2.1, kabilang ang Target Size (Minimum) sa antas AA — ang mga pindutin na target ay dapat sa pangkalahatan ay hindi bababa sa 24 by 24 CSS pixels, may mga eksepsiyon — at ang Accessible Authentication (Minimum), na naglilimita sa mga hakbang sa login na umaasa sa alaala o palaisipan, gaya ng pagta-type muli ng password nang hindi pinapayagang i-paste ito. Inalis din nito ang lumang "Parsing" criterion dahil luma na ito.

Isang halimbawa: sign-up form

Narito ang isang sign-up form na maaaring gawin ng AI, at ang nakikita ng accessibility check:

Hindi gaanong binabago ng alinman sa mga ayos na ito ang itsura ng form. Ang lahat ng ito ay nagbabago kung makakagamit ba ng form ang ilang tao.

Mga pangunahing termino

Mga karaniwang maling akala

• "Para lang sa mga bulag na user ang accessibility." Sakop nito ang kapansanan sa paningin, galaw, pandinig, pananalita, at pag-iisip, pati na pansamantalang kalagayan gaya ng nabaling braso.
• "Mukhang payak ang mga accessible na site." Naglilimita ang accessibility sa ilang bagay — contrast, focus style, laki ng text — pero karaniwan ang magaganda at accessible na site, hindi ang eksepsiyon.
• "Sinabi ng automated checker na 100, kaya tapos na tayo." Nahuhuli lamang ng automated tools ang ilang isyu. Kailangan ng tao para tingnan kung makabuluhan talaga ang alt text, o kung makatuwiran ang daloy para sa screen reader.
• "Gagawing compliant kami ng overlay widget." Hindi kayang ayusin ng mga toolbar na idinikit sa ibabaw ang nawawalang label o sirang keyboard access sa code mo. Ayusin ang pinagmulan.
• "Walang may kapansanang user kami." Maaaring hindi mo lang alam. Maraming kapansanan ang hindi nakikita, at ang mga taong tumatama sa harang ay kadalasang umaalis na lang.

Ano ang hihilingin sa iyong AI builder

• "Buuin ito para matugunan ang WCAG 2.2 level AA."
• "Gumamit ng semantic HTML: totoong button, link, heading na nasa tamang ayos, at label para sa bawat form field."
• "Siguraduhing gumagana ang bawat interactive na elemento gamit lamang ang keyboard at may nakikitang focus style."
• "I-check ang contrast ng lahat ng kulay ng text at icon — 4.5:1 para sa karaniwang text, 3:1 para sa malaking text at icon."
• "Magdagdag ng makabuluhang alt text sa mga nagbibigay-impormasyong larawan at walang lamang alt text sa mga dekoratibo."
• "Ipakita ang mga error sa form bilang text, naka-link sa field, hindi lamang sa kulay."
• "Igalang ang reduced-motion setting ng user para sa mga animation."
• "Magpatakbo ng automated accessibility check at ilista ang hindi nito kayang subukan, para ma-check ko iyon nang manu-mano."

Pagkatapos, subukan mo mismo: itabi ang mouse at subukang tapusin ang pangunahing daloy gamit lamang ang Tab, Shift+Tab, Enter, at Space. Subukan ang built-in na screen reader ng telepono mo sa pangunahing page. I-zoom ang browser sa 200% at tingnan kung may masisira.

Accessibility sa Mythex

Walang nakalaang accessibility checker ang Mythex, kaya ituring ang accessibility bilang bahagi ng mga prompt at pagsubok mo. Humiling ng WCAG 2.2 AA mula sa unang prompt, i-check ang resulta sa Preview gamit ang keyboard, at gamitin ang /test para ipa-click ng agent ang pangunahing daloy mo bago mag-publish — tingnan ang App Testing. Humihingi rin ang SEO recipe ng semantic heading at makabuluhang alt text, na nagsisilbi sa parehong layunin.

Para sa hands-on na checklist, tingnan ang paano gawing accessible ang website mo. Para sa design, basahin ang paano magdisenyo ng magandang app gamit ang AI, at bago ilunsad, ang paano subukan ang app mo bago ilunsad. Ang sariling WCAG overview ng W3C ang tunay na pinagmulan.

Mga tanong