WCAG 2.2 AA checklist para sa mga SaaS product at web app

May dalawang surface ng accessibility ang isang SaaS product: ang marketing site na nagbebenta nito at ang application na ginagamit ng mga tao araw-araw. Bumabagsak ang marketing site sa parehong paraan ng anumang website, sa mababang contrast, kawalan ng alt text at mga form na walang label. Nagdadagdag naman ang application ng sarili nitong mga problema: mga login flow na humaharang sa mga password manager, mga dialog na nagkukulong sa keyboard focus, single-page navigation na hindi napapansin ng mga screen reader, mga data table at chart na walang text, drag-and-drop na walang alternatibo, at mga session na nag-e-expire nang walang babala. Tinatalakay ng checklist na ito ang WCAG 2.2 Level AA ayon sa mga bahagi ng isang karaniwang SaaS product.

Mga pangunahing punto

• Naging W3C Recommendation ang WCAG 2.2 noong Oktubre 2023 at nagdagdag ito ng siyam na success criteria, anim sa mga ito ay nasa Level A o AA (W3C (magbubukas sa bagong tab)).
• Ibig sabihin ng Accessible Authentication (3.3.8, AA) na hindi puwedeng nakadepende ang login sa pag-alala o pagkopya ng password maliban kung puwede itong i-paste o gumamit ng password manager (W3C (magbubukas sa bagong tab)).
• Dapat hindi bababa sa 24 by 24 CSS pixel ang mga interactive target, o may sapat na espasyo sa paligid ng mga ito (2.5.8, AA) (W3C (magbubukas sa bagong tab)).
• Dapat makarating sa mga screen reader ang mga mensahe gaya ng “Saved” o “3 results” nang hindi inililipat ang focus (4.1.3, AA) (W3C (magbubukas sa bagong tab)).
• Madalas humingi ang mga buyer mula sa negosyo at pampublikong sektor ng Accessibility Conformance Report, na kadalasang isinusulat sa VPAT template ng Information Technology Industry Council (ITI (magbubukas sa bagong tab)).

Bakit mas mahalaga ang accessibility para sa SaaS kaysa sa isang brochure site?

Ginagamit ng mga tao ang isang SaaS product nang ilang oras, kadalasan dahil ang employer nila ang pumili nito. Nawawalan ka ng isang bisita kapag may hadlang sa isang marketing page; ang hadlang sa produkto ay maaaring pumigil sa isang tao na gawin ang trabaho niya. Kaya dumarami ang malalaking customer, unibersidad at pampublikong ahensya na nagtatanong tungkol sa accessibility bago bumili, at kaya kailangang saklawin ng sagot ang application, hindi lang ang website.

Mahalaga rin ito dahil bahagi lang ng problema ang nahuhuli ng mga awtomatikong test. Nahahanap ng mga tool gaya ng axe-core ang mga failure sa markup, gaya ng kulang na label at mababang contrast. Hindi nila masasabi kung ibinabalik ng isang dialog ang focus sa tamang lugar, kung available bilang text ang data ng isang chart, o kung matatapos gamit ang keyboard ang isang workflow. Kailangan ng isang application ang parehong awtomatikong check at manual testing.

Paano gagawing accessible ang sign-up at login?

Ang authentication ang bahagi kung saan idinagdag ng WCAG 2.2 ang pinakamahalagang bagong requirement para sa SaaS.

• Payagan ang paste at mga password manager (3.3.8, AA). Huwag harangan ang pag-paste sa mga password o code field, at gamitin ang autocomplete="username", autocomplete="current-password" at autocomplete="one-time-code" para mapunan ito ng mga browser at password manager.
• Iwasan ang mga puzzle bilang tanging paraan ng pagpasok. Ang CAPTCHA na nagpapakopya ng baluktot na text o nagpapalutas ng puzzle ay isang cognitive function test. Mag-alok ng alternatibo, at mas piliin ang mga check na hindi nangangailangan ng aksyon ng user (W3C (magbubukas sa bagong tab)).
• Lagyan ng label ang bawat field (1.3.1 at 3.3.2, A). Gumamit ng nakikitang <label> na nakakonekta sa input nito; nawawala ang placeholder text kapag nag-type ang tao at hindi ito label.
• Tukuyin ang mga error sa text (3.3.1, A) at magmungkahi ng ayos (3.3.3, AA). Nakakatulong ang “Dapat may hindi bababa sa 12 character ang password”; hindi sapat ang pulang border lang.
• Huwag magtanong nang dalawang beses (3.3.7, A). Kung naitanong na sa isang multi-step na sign-up ang pangalan ng kumpanya o address, punan ito o hayaang piliin ito ng tao sa halip na i-type ulit.
• Panatilihin sa iisang lugar ang tulong (3.2.6, A). Kung nag-aalok ka ng chat, help link o contact details, ilagay ang mga ito sa parehong relatibong posisyon sa bawat page ng flow.

Aling mga pattern ng form at error ang sanhi ng pinakamaraming failure?

Nasa mga form ang karamihan ng failure ng application. Nakita ng survey ng WebAIM noong 2026 sa isang milyong home page na may kulang na form label ang 51% ng mga ito (WebAIM (magbubukas sa bagong tab)), at mas marami nang malayo ang form ng mga application kaysa sa mga home page.

• Bigyan ang bawat input ng programmatic name, at igrupo ang magkakaugnay na control, gaya ng mga radio button, gamit ang <fieldset> at <legend>.
• Sabihin sa mga tao ang mga error kung saan nila ito mapapansin: ilipat ang focus sa isang error summary sa itaas ng form, o sa unang invalid na field, at i-link ang bawat item ng summary sa field nito.
• Markahan sa text ang mga required na field, hindi lang sa kulay (1.4.1, A).
• Huwag mag-submit o magpalit ng context kapag pumili lang ang tao ng isang opsyon (3.2.2, A); hintayin ang isang tahasang aksyon.

Paano dapat gumana ang mga dialog, menu at popover?

Sa mga custom component pinakamadalas nasisira ang suporta sa keyboard at screen reader. Inilalarawan ng WAI-ARIA Authoring Practices Guide ang inaasahang behavior para sa bawat pattern (W3C (magbubukas sa bagong tab)).

• Mga dialog: ilipat ang focus sa loob ng dialog kapag bumukas ito, panatilihin ang Tab sa loob nito habang bukas ito, isara ito gamit ang Escape, at ibalik ang focus sa control na nagbukas nito. Gamitin ang native na <dialog> element o role="dialog" na may aria-modal="true" at pangalan.
• Walang keyboard trap (2.1.2, A): dapat maiwan gamit ang keyboard ang bawat component.
• Nakikitang focus (2.4.7, AA) na hindi natatakpan ng mga sticky header, cookie banner o chat widget (2.4.11, AA, bago sa 2.2).
• Mga tooltip at popover (1.4.13, AA) na maisasara ng tao gamit ang Escape, matatapatan ng mouse nang hindi nawawala, at nananatili hanggang isara.
• Mga single-key shortcut (2.1.4, A): kung may aksyong nati-trigger sa pagpindot ng isang letter key, hayaang i-off o i-remap ng tao ang mga shortcut, o gawin itong aktibo lang kapag naka-focus ang kaugnay na component.

Paano hahawakan ang navigation sa isang single-page app?

Sa isang single-page app, nagbabago ang URL nang walang page load, kaya maaaring hindi ianunsyo ng mga screen reader na may nangyari.

• I-update ang document title sa bawat pagbabago ng route, para may naglalarawang title ang bawat view (2.4.2, A).
• Ilipat ang focus sa pangunahing heading ng bagong view, o ianunsyo ang pagbabago sa isang polite na live region; may kasamang route announcer para rito ang mga framework gaya ng Next.js.
• Panatilihin ang lohikal na focus order (2.4.3, A): pagkatapos mag-delete ng item, dapat mapunta ang focus sa isang makatwirang katabi, hindi pabalik sa itaas ng page.
• Magbigay ng paraan para lampasan ang paulit-ulit na navigation (2.4.1, A), gaya ng skip link o mga landmark.

Paano gagawing accessible ang mga dashboard, data table at chart?

• Mga table: gumamit ng totoong <table> markup na may <th> at scope para sa mga header, at isang caption (1.3.1, A). Ang mga grid na binuo mula sa mga <div> element ay nangangailangan ng buong ARIA grid pattern, na mas mahirap gawin nang tama.
• Mga chart: bigyan ang bawat chart ng text alternative na nagsasabi ng pangunahing punto nito, at ialok ang data bilang table (1.1.1, A). Huwag umasa sa kulay lang para mapag-iba ang mga series (1.4.1, A); magdagdag ng mga label o pattern.
• Contrast: kailangan ng text ang 4.5:1 (1.4.3, AA), at kailangan ng mga linya ng chart, icon at border ng input ang 3:1 laban sa background nila (1.4.11, AA). Hiwalay na suriin ang dark mode. Tine-test ng aming color contrast checker ang anumang pares ng kulay.
• Mga status message (4.1.3, AA): dapat gumamit ng role="status" o isang live region ang “Saved”, “Upload complete” at ang bilang ng mga resulta, para marinig ito ng mga screen reader nang hindi nawawala sa kanilang puwesto.

Ano ang binabago ng mga bagong criteria ng WCAG 2.2 para sa mga web app?

Inalis din ng WCAG 2.2 ang 4.1.1 Parsing, na wala nang praktikal na epekto sa accessibility (W3C (magbubukas sa bagong tab)).

Paano naman ang mga timeout, layout at zoom?

• Mga session timeout (2.2.1, A): babalaan ang mga tao bago mag-expire ang isang session at hayaan silang palawigin ito sa isang simpleng aksyon, maliban kung mahalaga ang time limit o lampas ito sa 20 oras. Naiiwasan ang pinakamasamang resulta kapag sine-save ang trabahong ginagawa pa.
• Reflow (1.4.10, AA): dapat gumana ang content sa lapad na 320 CSS pixel (katumbas ng pag-zoom sa 400% sa isang 1280-pixel na screen) nang hindi nag-i-scroll sa dalawang direksyon; exempted ang mga data table at katulad na content.
• Text spacing (1.4.12, AA): hindi dapat maputol ang text kapag nilakihan ang line height at letter spacing, na madalas mangyari sa mga container na fixed ang height.
• Orientation (1.3.4, AA): huwag i-lock ang app sa portrait o landscape maliban kung mahalaga ito.

Ano ang ACR, at kailangan mo ba nito?

Idinodokumento ng Accessibility Conformance Report (ACR) kung paano natutugunan ng isang produkto ang bawat accessibility criterion: supports, partially supports o does not support, na may mga remark. Karamihan ay isinusulat sa VPAT template na inilalathala ng Information Technology Industry Council, na may mga edisyon para sa WCAG, sa mga Section 508 standard ng US at sa European standard na EN 301 549 (ITI (magbubukas sa bagong tab)).

Dapat bumili ng accessible na teknolohiya ang mga federal agency ng US sa ilalim ng Section 508 (Section508.gov (magbubukas sa bagong tab)), at tumutukoy ang mga pampublikong ahensya sa EU sa EN 301 549, kaya madalas hingan ng ACR sa procurement ang mga B2B product na nagbebenta sa mga customer na ito. Mas kapaki-pakinabang sa mga buyer ang tapat na ACR, na nakalista ang mga alam na kakulangan, kaysa sa nagsasabing buo ang suporta. Dapat itong nakabatay sa pag-test ng produkto, kasama ang manual testing; hindi ito mapupunan ng awtomatikong scan lang.

Kung nagbebenta ka sa mga consumer sa EU, maaari ring sumaklaw ang European Accessibility Act sa paraan mo ng pagbebenta online; ipinapaliwanag ng aming gabay sa EAA ang saklaw nito. Hindi ito legal na payo.

Paano dapat mag-test ng accessibility ang isang SaaS team?

1. I-automate ang mga pangunahing bagay. Patakbuhin ang axe-core o katulad na engine sa iyong mga end-to-end test at sa marketing site, at pabagsakin ang mga build kapag may bagong violation. Pinapatakbo ng aming libreng accessibility checker ang parehong engine sa anumang pampublikong page.
2. Mag-test gamit ang keyboard. Tapusin ang iyong mga pangunahing workflow, gaya ng pag-sign up, paggawa ng record at pagbabago ng settings, gamit lang ang Tab, Shift+Tab, Enter, Space, Escape at ang mga arrow key.
3. Mag-test gamit ang screen reader. Libre ang NVDA sa Windows at ang VoiceOver sa macOS at iOS. Suriin kung inaanunsyo ang mga pangalan, role, state at mensahe.
4. Mag-zoom at mag-resize. Suriin ang 200% na text zoom at isang window na 320 pixel ang lapad.
5. Ayusin sa design system. Galing sa mga shared component ang karamihan ng failure; kapag inayos mo nang isang beses ang isang button o dialog, naaayos ito saanman.

Mga madalas itanong

Saklaw ba ng WCAG ang mga bahagi ng web app na nangangailangan ng login?

Saklaw ng WCAG ang anumang web content, kasama ang mga page sa likod ng login. Kung hinihingi ng batas na matugunan ito ng isang partikular na produkto ay nakadepende sa hurisdiksyon at sa customer, pero kadalasang ang buong produkto ang tinutukoy ng mga buyer na nagtatanong tungkol sa accessibility.

Kaya bang gawing accessible ng isang overlay ang isang SaaS product?

Hindi. Hindi binabago ng mga overlay ang pinagbabatayang code ng mga custom component, kung saan naroon ang mga failure ng application. Tinatalakay ng aming gabay sa mga accessibility overlay ang aksyon ng FTC laban sa isang nangungunang overlay vendor.

Gaano karami sa WCAG ang kayang i-check ng mga awtomatikong tool?

Bahagi lang nito. Maaasahang nahahanap ng mga awtomatikong rule ang mga kulang na pangalan at label at ang mga contrast failure, pero maraming criteria, gaya ng makabuluhang focus order, kapaki-pakinabang na alt text at mga error message na madaling maunawaan, ang nangangailangan ng tao para husgahan.

Aling bersyon ng WCAG ang dapat naming targetin?

Ang WCAG 2.2 Level AA ang kasalukuyang bersyon. Maraming batas at patakaran sa procurement ang tumutukoy pa rin sa WCAG 2.1 AA; natutugunan din ang 2.1 AA kapag natugunan ang 2.2 AA, maliban sa inalis na Parsing criterion.

Kailangan ba naming matugunan ang Level AAA?

Hindi inirerekomenda ng W3C na gawing requirement ang AAA para sa buong produkto, dahil may content na hindi kayang tumugon sa bawat AAA criterion. Level AA ang karaniwang target.

Mga sanggunian

• W3C: What's new in WCAG 2.2 (magbubukas sa bagong tab)
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (magbubukas sa bagong tab)
• W3C: Understanding 3.3.8 Accessible Authentication (Minimum) (magbubukas sa bagong tab)
• W3C: Understanding 2.5.8 Target Size (Minimum) (magbubukas sa bagong tab)
• W3C: Understanding 4.1.3 Status Messages (magbubukas sa bagong tab)
• W3C: ARIA Authoring Practices Guide: Dialog (modal) pattern (magbubukas sa bagong tab)
• W3C: Inaccessibility of CAPTCHA (magbubukas sa bagong tab)
• ITI: Voluntary Product Accessibility Template (VPAT) (magbubukas sa bagong tab)
• GSA: Section508.gov (magbubukas sa bagong tab)
• WebAIM: The WebAIM Million (2026) (magbubukas sa bagong tab)