Accessibility checklist para sa mga website ng kumpanya: careers, PDF, investor page at form

Bihirang direktang magbenta ang website ng isang kumpanya, kaya madaling makaligtaan ang mga problema sa accessibility nito. Pero dito nag-a-apply ng trabaho ang mga tao, nagbabasa ng annual report ang mga investor, naghahanap ng press release ang mga mamamahayag at naghahanap ng contact details ang mga customer, at bawat isa sa mga gawaing iyon ay maaaring harangan ng isang hadlang: job application na hindi matapos gamit ang keyboard, annual report na inilathala bilang untagged na PDF, video na walang caption, cookie banner na nagkukulong sa focus. Tinatalakay ng checklist na ito ang WCAG 2.2 Level AA ayon sa mga seksyong mayroon ang karamihan ng corporate site, kasama kung ano ang dapat suriin sa bawat isa.

Mga pangunahing punto

• Nakakita ang WebAIM ng nade-detect na WCAG failure sa 95.9% ng nangungunang isang milyong home page noong 2026; ang text na mababa ang contrast (83.9%) at kawalan ng alt text (53.1%) ang pinakakaraniwan (WebAIM (magbubukas sa bagong tab)).
• Saklaw ng WCAG ang mga dokumentong inilalathala sa isang site, gaya ng mga PDF, pati ang mga web page; naglalathala ang W3C ng mga technique para gawing accessible ang mga PDF (W3C (magbubukas sa bagong tab)).
• Kailangan ng prerecorded na video ang mga caption (1.2.2, Level A) at audio description kapag may impormasyon sa visual na wala sa audio (1.2.5, AA) (W3C (magbubukas sa bagong tab)).
• Sa isang gabay noong 2022, sinabi ng US Department of Justice na saklaw ng ADA ang mga web offering ng mga negosyong bukas sa publiko, nang hindi nagtatakda ng partikular na technical standard (ADA.gov (magbubukas sa bagong tab)).
• Nagbibigay ang W3C ng gabay at libreng generator para sa pagsulat ng accessibility statement (W3C (magbubukas sa bagong tab)).

Bakit mahalaga ang accessibility sa website ng isang kumpanya?

Dahil ang mga bisitang umaasa rito ay kadalasang ang mismong mga taong pinakagusto mong maabot: mga kandidato, customer, partner at investor. Tinatantiya ng World Health Organization na 1.3 bilyong tao, mga isa sa bawat anim, ang may makabuluhang kapansanan (WHO (magbubukas sa bagong tab)). Mas marami pa ang gumagamit ng keyboard sa halip na mouse, nag-zo-zoom ng text, o nagbabasa sa phone sa ilalim ng matinding liwanag.

May anggulo rin ng compliance, na nag-iiba ayon sa bansa at sa kung sino ang pinagsisilbihan ng site. Dapat sumunod sa Web Accessibility Directive ang mga ahensya ng pampublikong sektor sa EU; maaaring saklawin ng European Accessibility Act ang mga negosyong nagbebenta sa mga consumer sa EU; sa US, sinabi ng Department of Justice na saklaw ng ADA ang mga web offering ng mga negosyong bukas sa publiko (ADA.gov (magbubukas sa bagong tab)). Maaaring nasa labas ng ilan sa mga batas na ito ang isang purong business-to-business na site, pero dumarami ang malalaking customer na nagtatanong sa mga supplier tungkol sa accessibility. Ipinapaliwanag ng aming mga gabay sa European Accessibility Act at sa mga ADA demand letter ang konteksto; hindi ito legal na payo.

Ano ang dapat mong suriin sa bawat page?

Galing sa mga shared template ang mga problemang ito, kaya kapag inayos mo nang isang beses, naaayos ang buong site:

• Contrast: body text na hindi bababa sa 4.5:1 laban sa background nito, malaking text na 3:1 (1.4.3). Ang light gray na text at puting text sa mga kulay ng brand ang mga karaniwang failure. Tine-test ng color contrast checker ang anumang pares ng kulay.
• Keyboard: bawat link, menu at button na naaabot gamit ang Tab at nagagamit gamit ang Enter o Space, na may nakikitang focus indicator (2.1.1, 2.4.7). Madalas na problema ang mga mega menu at carousel.
• Skip link at mga landmark: paraan para lumaktaw sa header papunta sa pangunahing content (2.4.1), at mga header, nav, main at footer landmark.
• Mga heading: isang H1 bawat page at lohikal na istruktura ng heading (1.3.1), para ma-scan ng mga gumagamit ng screen reader ang page.
• Link text: mga link na may saysay kahit hiwalay sa konteksto, hindi “Read more” na inulit nang sampung beses (2.4.4).
• Wika: ang lang attribute sa bawat page, at sa mga bahaging nasa ibang wika (3.1.1, 3.1.2), para tama ang pagbigkas ng mga screen reader.
• Zoom at reflow: content na magagamit sa 200% na zoom at sa lapad na 320 pixel nang walang horizontal scrolling (1.4.4, 1.4.10).

Paano gagawing accessible ang mga careers page at job application?

Sa careers section pinakamalinaw ang epekto ng mga hadlang: hindi maisasaalang-alang ang kandidatong hindi makatapos ng application.

• Mga job listing: dapat gumana gamit ang keyboard ang mga filter at search at dapat nilang ianunsyo sa mga screen reader ang bilang ng mga resulta (4.1.3).
• Mga application form: kailangan ng bawat field ang nakikitang label (3.3.2), dapat ilarawan sa text ang mga error (3.3.1), at dapat may accessible name ang mga button sa pag-upload ng file.
• Mga time limit: kung nagta-time out ang form, babalaan ang mga tao at hayaan silang palawigin ang oras (2.2.1).
• Mga third-party applicant tracking system: maraming kumpanya ang gumagamit ng panlabas na system para sa mga application. Hingin sa vendor ang Accessibility Conformance Report nito, i-test mismo ang application flow gamit ang keyboard, at mag-alok ng alternatibong paraan ng pag-apply, gaya ng email, na nakalista sa careers page.
• Mga assessment at video interview: tiyaking sinusuportahan ng anumang online test o video interview tool ang mga screen reader, caption at dagdag na oras kapag hiniling.

Paano maglalathala ng mga accessible na PDF at annual report?

Kadalasang inilalathala bilang PDF lang ang mga annual report, sustainability report, brochure at policy document, at untagged ang marami sa mga ito: binabasa ito ng screen reader bilang iisang bloke ng text, o hindi talaga nababasa.

• Mas piliin ang HTML para sa mahahalagang content. Mas madaling gawing accessible ang isang web page, mas gumagana ito sa mga phone at mas madali itong hanapin.
• Kung maglalathala ka ng PDF, lagyan ito ng tag. Mag-export mula sa source document (Word, InDesign) nang naka-enable ang mga tag, para mapanatili ang mga heading, listahan, table at reading order. Itinatakda ng PDF/UA standard (ISO 14289) ang mga accessible na PDF.
• Suriin ang mga mahahalaga: document title, wika ng dokumento, alternative text para sa mga chart at larawan, totoong table header, at lohikal na reading order. May built-in na accessibility checker ang Adobe Acrobat Pro; libreng checker para sa Windows ang PAC.
• Ang mga na-scan na dokumento ay mga larawan ng text at nangangailangan ng OCR at tagging, o isang HTML na bersyon.
• Mga financial table: markahan ang mga header row at column; sa HTML, gamitin ang <th> na may scope.

Paano naman ang video, webcast at podcast?

• Mga caption para sa lahat ng prerecorded na video na may pananalita (1.2.2, A), at para sa mga live webcast (1.2.4, AA). Kailangang suriin ang mga automatic caption: madalas na mali ang mga pangalan, numero at technical term.
• Audio description kapag visual lang ang mahalagang impormasyon, gaya ng text sa mga slide na hindi binabasa ng speaker (1.2.5, AA). Kadalasan, ang pinakasimpleng ayos ay ilarawan ng speaker ang slide.
• Mga transcript para sa mga podcast at content na audio lang (1.2.1, A).
• Mga control ng player: dapat magamit gamit ang keyboard ang naka-embed na player, at kailangang may paraan para i-pause o ihinto ang tunog na awtomatikong tumutugtog nang higit sa tatlong segundo (1.4.2).

Saklaw ng gabay ng W3C sa paggawang accessible ng audio at video ang pagpaplano, mga caption at description (W3C (magbubukas sa bagong tab)).

Paano gagawing accessible ang mga contact form, mapa at lokasyon?

• Mga form: mga label, malinaw na error message, at walang CAPTCHA na umaasa lang sa pagbasa ng baluktot na text o paglutas ng puzzle; mag-alok ng alternatibo (W3C (magbubukas sa bagong tab)).
• Contact details bilang text: mga numero ng telepono, email address at address ng opisina na nakasulat sa page, hindi lang nasa larawan o mapa.
• Mga mapa: mahirap gamitin ang naka-embed na mapa gamit ang screen reader; ang address at direksyon sa text ang accessible na alternatibo.
• Mga chat widget: tiyaking nabubuksan, nagagamit at naisasara ang mga ito gamit ang keyboard, at hindi nila natatakpan ang naka-focus na content (2.4.11).

Nagdudulot ba ng problema sa accessibility ang mga cookie banner?

Madalas, dahil sila ang unang lumalabas at nakapatong sila sa lahat ng iba pa.

• Dapat naaabot at nagagamit gamit ang keyboard ang banner, at dapat kayang umalis dito ng Tab (2.1.2, No Keyboard Trap) (W3C (magbubukas sa bagong tab)).
• Kailangan ng mga button nito ang malinaw na pangalan at sapat na contrast; dapat kasingdaling hanapin ng “Accept” ang “Reject”.
• Hindi nito dapat itago ang naka-focus na elemento ng page sa likod nito (2.4.11).

Nagsisimula ang aming mga scan sa iyong home page habang nakalabas pa ang cookie banner, dahil iyon ang unang nasasalubong ng isang keyboard user, at nag-uulat ito ng focus trap kung hindi ito malampasan ng Tab.

Kailangan mo ba ng accessibility statement?

Dapat maglathala nito ang mga ahensya ng pampublikong sektor sa EU. Para sa mga kumpanya, kadalasang boluntaryo ito, bagama’t hinihingi ng European Accessibility Act na magbigay ang mga saklaw na serbisyo ng impormasyon kung paano nila natutugunan ang mga requirement nito. Sinasabi ng mahusay na statement kung aling standard ang tinatarget mo, ang mga alam na limitasyon, kung paano makakapag-ulat ng problema o makakahingi ng content sa ibang format ang mga tao, at kung kailan ito huling nirepaso. Naglalathala ang W3C ng gabay at libreng generator (W3C (magbubukas sa bagong tab)).

Isulat ito nang tapat: panganib na mismo ang pag-angkin ng buong compliance pagkatapos ng isang awtomatikong scan, dahil hindi kayang suriin ng mga awtomatikong test ang lahat.

Paano mo dapat i-test ang isang company website?

1. Magpatakbo ng awtomatikong scan sa home page, isang careers page, isang news article, ang contact page at anumang form. Tine-test ng aming libreng accessibility checker ang mga pangunahing page sa isang totoong browser ayon sa WCAG 2.2 A at AA, at inililista ng alt text checker ang bawat larawan sa isang page.
2. Mag-test gamit ang keyboard: i-navigate ang menu, mag-apply ng trabaho at i-submit ang contact form gamit lang ang keyboard.
3. Suriin ang mga dokumento: buksan ang pinakamahahalaga mong PDF gamit ang screen reader o isang PDF accessibility checker.
4. Panoorin ang iyong mga video nang naka-on ang caption at naka-off ang tunog.
5. Hilingin sa mga taong may kapansanan na subukan ang mga pangunahing gawain; naglalantad ito ng mga problemang hindi mahuhulaan ng anumang checklist.

Mga madalas itanong

Saklaw ba ng WCAG ang mga PDF?

Oo. Saklaw ng WCAG ang web content, kasama ang mga dokumentong inilalathala sa isang site. Naglalathala ang W3C ng mga partikular na technique para matugunan ang WCAG sa mga PDF file.

Third party ang nagpapatakbo ng aming careers site. Responsibilidad ba namin ito?

Mula sa pananaw ng kandidato, proseso mo ng application iyon. Hingin sa vendor ang Accessibility Conformance Report, i-test ang flow, at mag-alok ng alternatibong paraan ng pag-apply. Kung may legal na responsibilidad ka ay nakadepende sa iyong hurisdiksyon.

Natutugunan ba ng mga automatic caption ang WCAG?

Kung tumpak lang ang mga ito. Madalas magkamali ang mga automatic caption sa mga pangalan, numero at termino; repasuhin at itama ang mga ito bago umasa sa mga ito.

Sapat na ba ang isang accessibility overlay para sa isang corporate site?

Hindi. Hindi inaayos ng mga overlay ang pinagbabatayang code, mga dokumento o mga video. Tingnan ang aming gabay sa mga accessibility overlay at ang order ng FTC.

Aling standard ang dapat targetin ng isang company website?

Ang WCAG 2.2 Level AA ang kasalukuyang bersyon at ang karaniwang target; maraming batas at patakaran ang tumutukoy pa rin sa WCAG 2.1 AA, na natutugunan din ng site na tumutugon sa 2.2 AA.

Mga sanggunian

• WebAIM: The WebAIM Million (2026) (magbubukas sa bagong tab)
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (magbubukas sa bagong tab)
• W3C: Techniques for WCAG 2.2: PDF techniques (magbubukas sa bagong tab)
• W3C: Understanding 1.2.2 Captions (Prerecorded) (magbubukas sa bagong tab)
• W3C: Understanding 1.2.5 Audio Description (Prerecorded) (magbubukas sa bagong tab)
• W3C: Making audio and video media accessible (magbubukas sa bagong tab)
• W3C: Understanding 2.1.2 No Keyboard Trap (magbubukas sa bagong tab)
• W3C: Inaccessibility of CAPTCHA (magbubukas sa bagong tab)
• W3C: Developing an accessibility statement (magbubukas sa bagong tab)
• US Department of Justice: Guidance on web accessibility and the ADA (magbubukas sa bagong tab)
• World Health Organization: Fact sheet tungkol sa kapansanan (Disability fact sheet) (magbubukas sa bagong tab)