Mga Pamantayan sa Web: Isang Malalim na Gabay sa Sanggunian

Disenyo/Arkitektura

WEB-27

WEB-27: Dapat ipakita ng lahat ng ahensya ang Commonwealth Banner na hindi binago at gaya ng tinukoy ng COV Design System. 

Pag-unawa sa WEB-27  

Ang Commonwealth Branding Bar ay tumutulong sa mga mamamayan na matukoy ang mga opisyal na website ng mga organisasyon ng pamahalaan sa Commonwealth of Virginia. Tinutulungan din nito ang mga bisita na maunawaan na ang site na kinaroroonan nila ay opisyal at secure. Ang bagong branding bar ay nagsisilbi rin bilang isang portal ng nabigasyon para sa mga bisita sa website upang madaling mag-navigate sa mga ahensya ng gobyerno at maghanap ng impormasyon sa buong Commonwealth, nang hindi kinakailangang mag-navigate pabalik sa Virginia.gov. 

Ang branding bar ay madaling i-install, at ang mga tagubilin at code ay makikita para sa mga ahensya na ilagay sa kanilang mga website sa ilalim ng Kunin ang Commonwealth Branding Bar. Ang page na ito ay naglatag ng sunud-sunod na mga tagubilin upang makabuo ng code na ilalagay sa head tag ng website ng isang ahensya. May pagpipilian din ang mga ahensya na pumili sa pagitan ng kulay abo at puti na mga bar sa pagba-brand para mas angkop sa kulay na tema ng kanilang mga website. 

Ang bawat branding bar na nabuo ay naglalaman ng: 

  • Ang logo ng estado ng Virginia 
  • Ang ahensya o pangalan ng entity ng pamahalaan ng Virginia, kung saan ang mga generator ay dapat baybayin nang buo ang pangalan 
  • Isang byline na nagsasaad, "Isang opisyal na website ng Commonwealth of Virginia" at isang drop down na nagsasabing "Narito kung paano mo malalaman." 
  • Ang drop down ay naglalaman ng impormasyon tungkol sa Commonwealth of Virginia logo at HTTPS certificate. 
  • Isang submenu na may label na "Maghanap ng Commonwealth Resource" na kapag na-click, ay nagbibigay-daan sa mga user na maghanap sa mga ahensya ng Virginia o mga entity ng pamahalaan, pati na rin ang mga karaniwang ginagamit na serbisyo at mapagkukunan ng Commonwealth na pinagsunod-sunod ayon sa lugar ng serbisyo ng ahensya. 

Ang nabuong code ay dapat gamitin kung ano-ano at hindi dapat baguhin sa anumang paraan. Anumang mga problema sa pag-install ay dapat ipadala sa Enterprise Web Services Team sa VITA sa pamamagitan ng pag-email Ang nabuong code ay dapat gamitin kung ano-ano at hindi dapat baguhin sa anumang paraan. Ang anumang mga problema sa pag-install ay dapat ipadala sa Enterprise Web Services Team sa VITA sa pamamagitan ng pag-email sa developer@vita.virginia.gov. 

WEB-28

WEB-28: Ang mga web system ng COV ay dapat magbigay ng box para sa paghahanap ng site ng ahensya na lilitaw sa bawat pahina at ipapakita alinsunod sa mga direktiba ng COV Design System. 

Pag-unawa sa WEB-28

Ang pagkakaroon ng box para sa paghahanap ng site sa buong ahensya sa bawat website at page ng ahensya ay nagbibigay-daan sa mga user na mas mabilis na ma-access ang impormasyon sa pamamagitan ng pag-type ng mga nauugnay na keyword at termino para sa paghahanap na nagdidirekta sa kanila sa isang listahan ng mga nauugnay na link.  Ang isang ahensya ay hindi maaaring umasa sa pangunahin o pangalawang nabigasyon lamang upang idirekta ang mga user sa may-katuturang impormasyon.  

Dahil lalong nagiging sentro ang mga search box para sa mga website na naglalaman ng malaking halaga ng nilalaman at impormasyon, partikular na kinasasangkutan ng mga patakaran, pamamaraan, o serbisyo ng mamamayan, dapat na kitang-kita ang mga search box sa bawat page at dapat na madaling mapansin ng mga user. 

Bilang karagdagan, ang mga box para sa paghahanap ay dapat sumunod sa mga sumusunod na pinakamahusay na kagawian: 

  • Ang paghahanap, kung saan posible, ay dapat magpanatili ng isang open-text na field ng query na may placeholder na text na may label na "paghahanap" o may higit pang mga tagubiling ayon sa konteksto na limitado sa ilang salita kung saan maaaring mag-type ng mga query ang user. 
  • Ang mga search box ay dapat na sinamahan ng magnifying glass na icon na may pinakamaliit na detalyes posible (simpleng lineart). Pangkalahatang kinikilala ng mga user ang magnifying glass bilang simbolo ng functionality ng paghahanap. 
  • Kapag posible, hindi dapat itago ng icon na ito ang functionality ng paghahanap dahil pinapataas nito ang halaga ng pakikipag-ugnayan (mas maraming pag-click) at ginagawang hindi gaanong naiiba ang functionality ng paghahanap. 
  • Kapag may pagdududa, gawin ito tulad ng Google. 
  • Dapat kumpirmahin ang mga query sa paghahanap sa pamamagitan ng pagpindot sa enter. Ang mga query sa paghahanap ay maaari ding kumpirmahin sa pamamagitan ng pagpindot sa pindutan ng kumpirmasyon kung ninanais, kahit na ang pakikipag-ugnayan ng pagpindot sa enter sa box para sa paghahanap ay dapat panatilihin. 
  • Kung nagdaragdag ng button ng kumpirmasyon, dapat itong sukatin at mailagay nang naaangkop (karaniwan ay ang taas ng mismong box para sa paghahanap, inilalagay sa kanan ng field ng open-text na query). Ang pindutan ng paghahanap na ito nang hindi bababa sa, ay kailangang 45 x 45 pixel sa laki upang matugunan ang pinakamahuhusay na kagawian sa pagiging naa-access. 
  • Ang input text box ay dapat na may sukat na lapad upang mahawakan ang humigit-kumulang 27 na) character ang haba sa pinakamababa (itakda gamit ang ems). 
  • Kung posible, dapat ilagay ang box para sa paghahanap sa kanang sulok sa itaas ng website ng ahensya, sa ilalim ng Commonwealth Branding Bar. 
  • Ang isang auto-suggestion na drop down field na mas mababa sa 10 na mga item ay makakatulong sa mga user na mas mabilis na mahanap ang kanilang hinahanap, gayunpaman, ang mga ahensyang gumagamit nito ay dapat tiyakin na ang mga suhestiyon na awtomatikong nabuo ng field ay dapat na may kaugnayan sa mga termino para sa paghahanap na na-type sa input field. 
  • Kapag pinindot ng user ang enter, ang orihinal na termino para sa paghahanap ay dapat manatili sa field maliban kung na-clear ng user at dapat ipakita sa user ang pahina ng mga resulta na nagpapakita ng mga resulta batay sa kanilang query sa paghahanap. 
  • Kung ang isang query sa paghahanap ay walang ibinalik na mga resulta, ang mga user ay dapat magpakita ng impormasyong malinaw na nagsasaad na walang katugmang mga resulta. 

WEB-29

WEB-29: Ang mga web system ng COV ay dapat magsama ng isang sitemap upang paganahin ang mga search engine na i-crawl ang isang website nang mas mahusay. Ang mga halimbawa ay ibibigay sa COV Design System.

Pag-unawa sa WEB-29

Ang sitemap ay isang file na nagbibigay-daan sa mga search engine na matuklasan ang karamihan sa iyong site sa pamamagitan ng pag-crawl sa nilalaman nito. 

Ang mga sitemap ay dapat nasa XML na format, na nagpapahintulot sa mga search engine na mag-index hindi lamang ng mga HTML na file, ngunit ang data tungkol sa mga larawan, video, nilalaman ng balita, at mga naka-localize na bersyon ng mga webpage ng ahensya. 

Upang matuto nang higit pa tungkol sa kung paano lumikha ng mga sitemap sa isang XML na format, pakibisita ang Sitemaps XML format na dokumentasyon sa sitemaps.org. 

Inirerekomenda ng VITA ang pagsunod sa mga sumusunod na pinakamahuhusay na kagawian sa sitemap na inilatag sa developers.google.com: 

  • Ang isang sitemap ay dapat na limitado sa 50MB na hindi naka-compress. Kung mas malaki ang sitemap file ng iyong ahensya, mangyaring hatiin ang iyong sitemap sa maramihang mga sitemap. 
  • Ang mga file ng sitemap ay dapat na naka-encode ng UTF-8 . 
  • Inirerekomenda na ang iyong mga sitemap ay naka-host sa ugat ng site. 
  • Gumamit ng ganap na kwalipikado, ganap na mga URL sa iyong sitemap, halimbawa, gamitin ang https://www.myvaagency.gov/agencypage.html sa halip na /agencypage.html. 

WEB-30

WEB-30: Titiyakin ng COV web system na ang bawat page ay may footer na naglalaman, sa pinakamababa, ng sumusunod na impormasyon: 

  • Pangalan ng ahensya 
  • Impormasyon sa copyright 
  • Text o isang aprubadong link ng icon na nagsasaad ng pagsunod sa Web Accessibility Initiative (WAI).
  • Link sa Internet Privacy Policy Statement ng ahensya.
  • Link sa FOIA Information
  • Pagtatatuwa sa Pagsasalin
  • Isang Pahina ng Makipag-ugnayan sa Amin
  • Iba pang mga item gaya ng tinukoy ng COV Design System 

Pag-unawa sa WEB-30

Ang footer ng website ay isang static na pattern ng UI na ipinapakita sa pinakailalim ng lahat ng page ng site ng ahensya. Inilalatag ng WEB-30 na ang mga sumusunod ay ipapakita sa footer ng bawat pahina: 

  • Pangalan ng ahensya: Dapat ipakita ang buong pangalan ng ahensya 
  • Impormasyon sa copyright: Ipinapakita bilang Copyright © Buong Pangalan ng Ahensya [Kasalukuyang Taon] 
  • Mahalagang magtrabaho ang mga ahensya upang matugunan ang pagsunod sa AA gaya ng inilatag sa WCAG 2.0 kapag ginagamit ang link na ito. 
  • Link sa Internet Privacy Policy Statement ng ahensya: Ang mga patakaran sa privacy ay partikular sa ahensya ngunit dapat na hindi bababa sa ipaliwanag kung paano ginagamit at kinokolekta ng isang ahensya ang impormasyon ng user kapag ina-access ang site, anong impormasyon ang kinokolekta, kung paano ito nauugnay sa batas ng Virginia, kung saan maaaring makipag-ugnayan ang user para sa higit pang impormasyon, patakaran sa cookie, at iba pang impormasyon na nauugnay sa paggamit ng data ng user. Ang isang halimbawa ay matatagpuan sa virginia.gov. 
  • Link sa FOIA Information: Ang impormasyon ng FOIA ay partikular sa ahensya at dapat maglaman ng impormasyon sa payak na wika sa Virginia Freedom of Information Act, mga karapatan sa FOIA ng isang user, kung paano maaaring humiling ang isang user ng mga talaan, kung saan ipapadala ang kahilingan, at mga responsibilidad ng isang ahensya kapag tumatanggap ng kahilingan. Higit pang impormasyon sa FOIA ay matatagpuan sa Code of Virginia, Kabanata 37. 
  • Disclaimer sa pagsasalin: Ang isang disclaimer sa pagsasalin ay nagsasaad na ang isang third party (karaniwan ay Google translate) ay magagamit upang i-localize ang mga pahina. Dapat na pangalanan ng disclaimer na ito ang third party, pati na rin ang verbiage na ang opsyon ay ibinigay para makatulong sa mga user sa pagbibigay ng website sa mga wika maliban sa English, ngunit walang automated na pagsasalin ang perpekto at ang third-party na serbisyo ay ibinibigay na "as-is." Ang isang halimbawa ay matatagpuan sa Pahina ng Pagtatanggi sa Pagsasalin ng VITA. 
  • Isang pahina ng Makipag-ugnay sa Amin: Ang isang pahina ng contact sa amin ay dapat na kasama sa footer. Mangyaring tingnan ang WEB-31 para sa karagdagang impormasyon. 

Bukod pa rito, inirerekomenda ng COV design system na ang lahat ng footer 

  • Magtrabaho sa mobile 
  • Na ang mga karagdagang link sa footer ay dapat mapili nang may layunin (madalas na ginagamit, mini sitemap, atbp) 
  • Maglaman ng mga link/icon sa social media, ngunit hindi buong social feed 
  • Malinaw at nababasa na may kaunti hanggang walang koleksyon ng imahe 
  • Panatilihing maikli ang call to action at may malinaw na direksyon at layunin kung ginamit. 

WEB-31

WEB-31: Ang mga web system ng COV ay dapat magbigay ng isang pahina ng Makipag-ugnay sa Amin na dapat magsama, sa pinakamababa, ng ahensya ng: 

  • Mailing address
  • Numero ng FAX, kung magagamit
  • Numero ng telepono, kabilang ang isang toll-free na numero at/o numero ng TTY kung available
  • Email link o contact form sa isang contact sa ahensya. 
  • Ang pahina ng Makipag-ugnay sa Amin ay maa-access mula sa footer ng pahina.  

Pag-unawa sa WEB-31

Tandaan Dapat gumamit ang mga ahensya ng mga generic na email address at iwasan ang pag-uugnay ng mga link sa pakikipag-ugnayan ng ahensya sa mga partikular na indibidwal. 

Ang pahina ng Makipag-ugnay sa Amin ay nagbibigay-daan sa mga user na makipag-ugnayan sa ahensya para sa anumang mga katanungan o alalahanin sa pamamagitan ng iba't ibang paraan upang ma-accommodate ang iba't ibang mga user. 

  • Ang mga mailing address ay dapat na pisikal na address ng isang ahensya at hindi isang PO box, na naka-format nang ganito: 
     Buong Pangalan ng Ahensya 
    123 Street Address Road, Suite Number 456 
    Lungsod, VA Zip code 
     
  • Fax number, kung available, naka-format nang ganito: 
    123-555-5555 (Fax)
  • Numero ng telepono, kabilang ang isang toll-free na numero at/o numero ng TTY kung available, na naka-format nang ganito: 
    1-123-555-5555 (Telepono) 
    1-800-555-5555 (Toll Free) 
    1-123-555-5555 (TTY) 
  • Maaaring magbigay ng karagdagang mga tagubilin kung kinakailangan kung paano gamitin ang mga serbisyo ng TTY o relay kung magagamit. 
  • Ang isang generic na link ng email ay dapat gamitin upang maiwasan ang pag-uugnay ng contact ng ahensya sa isang partikular na indibidwal at dapat na naka-format nang ganito: 
     
    contact@agency.virginia.gov 
     
    Ang isang form sa pakikipag-ugnayan sa isang contact ng ahensya ay isang kahalili sa isang email address. Kung gumagamit ng isang form, ang mga form ay dapat magkaroon ng hindi bababa sa mga sumusunod na field na kinakailangan para sa pagtugon, na may naaangkop na label:
  • Pangalan
  • Apelyido (? Kailangan ba talaga ang apelyido? Going on the principle of least)
  • Email o numero ng telepono
  • Patlang para sa mensahe o komento 

WEB-36

WEB-36: Ang mga web system ng platform ng COV, kabilang ang mga Commercial Off-the-Shelf (COTS) system, ay dapat suportahan ang white-labelling para sa tuluy-tuloy na paggamit ng Commonwealth Branding gaya ng tinukoy ng COV Design System.

Pag-unawa sa WEB-36

Ang mga platform web system ay tinukoy ng EA bilang: 

Anumang web system na nagbibigay ng mga kakayahan sa antas ng enterprise para sa largescale o multitenant na pagpapatupad, kabilang ang mga human resource management system (HRMS), Financial Management Solutions (FMS), supply chain management (SCM), customer relationship management (CRM), enterprise performance management (EPM), at Content Management Systems (CMS). 

Dapat bigyang-daan ng mga system na ito ang kakayahan ng mga ahensya ng COVA na muling i-brand ang kanilang hitsura upang umangkop sa hitsura ng EA at mga pamantayan ng sistema ng disenyo (kilala rin bilang white-labeling) kapag ipinakita sa labas o nakaharap sa publiko. Sa pinakamababa, dapat ipakita ng isang platform web system na maaaring ma-access ng mga pampublikong user ang Commonwealth Branding Bar sa itaas ng page. 

Accessibility

WEB-39

WEB-39: Ang mga web system ng COV ay dapat magbigay ng kinakailangang impormasyon sa pagiging naa-access na ipapakita alinsunod sa mga direktiba ng COV Design System, upang ang user ay magkaroon ng agarang kaalaman kung paano pinakamahusay na mag-navigate sa website.

Pag-unawa sa WEB-39

Ang mga web system ng COV ay dapat malinaw na mag-post ng pagsunod sa pagiging naa-access ng mga website bilang nakalistang WEB-30, sa partikular sa ipaalam sa mga gumagamit ang mga diskarte na kailangan upang mag-navigate sa website anuman ang kakayahan. Karagdaganpa, ang mga ahensya ay dapat magsama ng isang pahayag sa pagiging naa-access na kasama ang mga pagsisikap na ginagawa ng ahensya patungo sa pagbuo ng isang naa-access na website, kung paano nila sinusubaybayan ang pagiging naa-access, at kung kanino maaaring idirekta ng mga user ang mga alalahaning nauugnay sa accessibility.

WEB-40 – WEB-43

Mga kinakailangan sa visual (WEB-40 – WEB-43)

Pag-unawa sa WEB-40 – WEB-43

Ang gabay na may mataas na contrast na kulay ay batay sa Pamantayan ng Tagumpay ng WCAG 1.4.3 Contrast (Minimum), na nagsasaad ng: 

Ang biswal na pagtatanghal ng text at mga larawan ng teksto may a contrast ratio ng hindi bababa sa 4.5:1, maliban sa mga sumusunod: 

  • Malaking sukat ang teksto at mga larawan ng malakihang teksto ay may contrast ratio na hindi bababa sa 3:1;
  • Teksto o mga larawan ng teksto na bahagi ng isang hindi aktibo bahagi ng user interface, iyon ay puro palamuti, na hindi nakikita ng sinuman, o bahagi ng isang larawan na naglalaman ng makabuluhang iba pang visual na nilalaman, ay walang kinakailangang contrast.
  • Ang text na bahagi ng isang logo o pangalan ng brand ay walang kinakailangang contrast. 

Maaaring matukoy ang mga contrast ratio ng kulay sa pamamagitan ng paggamit ng tool sa pag-audit gaya ng SiteImprove o mga online checker gaya ng WebAIM. 

Ang gabay sa mga audio cue ay nakabatay sa Pamantayan ng Tagumpay ng WCAG 1.2.2 Mga Caption (Prerecorded), na nagsasaad ng: 

Ang mga caption ay ibinibigay para sa lahat ng naka-prerecord na nilalamang audio sa naka-synchronize na media, maliban kung ang media ay isang alternatibong media para sa teksto at malinaw na may label na ganoon. 

Ang gabay sa pinakamahuhusay na kagawian para sa pag-render ng captioning ay makikita sa Ang inirerekomendang site ng WCAG, joeclark.org at ang Website ng Described and Captioning Media Program. 

Bukod pa rito, hindi lahat ng user ay makakaunawa o makakaunawa ng kulay, koleksyon ng imahe, o iba pang mga visual na pahiwatig dahil sa mga kapansanan na nakakaapekto sa paningin gaya ng pagkabulag o pagkabulag ng kulay sa mga user kung hindi man nakakakita. Ang WEB-41 ay batay sa Pamantayan ng Tagumpay ng WCAG 1.4.1 Paggamit ng Kulay, na nagsasaad ng: 

Ang kulay ay hindi ginagamit bilang ang tanging visual na paraan ng paghahatid ng impormasyon, nagpapahiwatig ng isang aksyon, pag-udyok ng tugon, o pagkilala sa isang visual na elemento. 

Halimbawa, kung ang isang contact form ay may berdeng button para sa “submit” at isang gray na button para sa “clear form,”, ang parehong mga pindutan at ang mga tagubilin para sa pagsusumite ay dapat na malinaw na may label. Sa pagkakataong ito ang berdeng button ay dapat na may label na "isumite" at ang pulang pindutan ay dapat na may label na "malinaw.”. Dapat idirekta ng mga tagubilin ang mga user na “i-click ang button na isumite upang kumpirmahin ang pagsusumite ng form o i-click ang button na i-clear ang form upang i-clear ang form at magsimulang muli.” 

Ang pag-label ay dapat na malinaw at naglalarawan upang maiwasan ang pagkalito ng user, ngunit sapat na maikli para sa mga user upang mabilis na magbasa at upang matulungan ang mga user na may pagbabasa o iba pang mga kapansanan sa pag-iisip. 

Ang mga ahensya ay hindi dapat gumamit ng kulay lamang upang ipahiwatig ang mga hyperlink sa kanilang mga website. Ang mga ahensya ay dapat tumingin sa paggamit pare-pareho, madaling makilalang mga pattern ng disenyo upang tukuyin ang parehong panloob at panlabas na nakaharap na mga hyperlink, tulad ng sa pamamagitan ng pinagbabatayan, CSS hover states, at mga icon (lalo na sa kaso ng isang panlabas na nakaharap na hyperlink). 

Dagdag pa, ang mga field na minarkahan bilang kinakailangan o mga field na natutugunan ng mga error sa pag-input ay dapat ipakita ang impormasyong ito sa mga paraan na hindi lamang nakikilala sa pamamagitan ng paggamit ng kulay. Halimbawa, ang isang field ay hindi maaaring i-highlight lamang sa isang pulang hangganan o may pulang asterisk sa tabi nito. Sa halip, dapat isaalang-alang ng mga ahensya ang mga identifier gaya ng "Kailangan ng Pangalan" o "Pangalan*" at isang notifier na nagsasabing "* = Kinakailangang Field." 

Ang mga halimbawa ng visual at code ng mga kinakailangang pinakamahuhusay na kagawian sa field ay makikita sa Deque's The Anatomy of Accessible Forms: Required Form Fields page. 

Para sa mga error na nai-input ng user, dapat na madaling matukoy ang error na may malinaw at maigsi na paglalarawan ng error. Dapat ding matugunan ng bawat mensahe ng error ang sumusunod na pamantayan: 

  • tukuyin ang bawat field sa pagkakamali
  • magbigay ng mga mungkahi (kapag alam) upang itama ang mga pagkakamali,
  • maayos na ilantad ang impormasyong ito sa pantulong na teknolohiya. 

Para sa karagdagang impormasyon at mga halimbawa kung paano i-format ang mga naa-access na field ng form na may mga error, pakibisita Level Access'Paano Magbigay ng Naa-access na Form Error Identification page. 

Mga Kinakailangan sa ARIA

WEB-44 – WEB-53

WEB-44 – WEB-53: Mga kinakailangan sa ARIA

Pag-unawa sa WEB-44 – WEB-53

Ang HTML 5 ay naglalaman ng mas maraming iba't-ibang at mas mapaglarawang mga HTML na tag upang matulungan ang mga developer at naa-access na teknolohiya na mas madaling maunawaan ang istraktura, nilalaman, at organisasyon ng isang web page. Dapat tiyakin ng mga ahensya na ang kanilang mga website ay gumagamit ng semantic na HTML nang tama upang matulungan ang mga developer, user, at mga naa-access na teknolohiya na ma-access ang nilalaman ng kanilang website nang naaangkop. Dagdag pa, nakakatulong ang HTML5 semantic markup na limitahan ang paggamit ng ARIA sa HTML code. Para sa higit pang impormasyon sa semantic markup sa HTML 5 at ang papel nito sa naa-access, pakibisita HTML ng Mozilla  : Isang magandang batayan para sa webpage ng accessibility. 

Ang ARIA, o Accessible Rich Internet Applications ay isang hanay ng mga tungkulin at katangian na idinagdag sa HTML code upang gawing mas naa-access ang isang website sa mga user gamit ang mga pantulong na teknolohiya sa web. Kung mayroon kang opsyon na gumamit ng HTML element na may semantics at gawi na naka-built in na, gamitin ang HTML na elementong iyon sa halip na AIRA. Dapat gamitin ng mga ahensya ang ARIA na may HTML na elemento kung walang ibang HTML na elemento na natively semantically o behavioral na naglalarawan o gumagana kung ano ang ginagawa nito. Kapag pinili ng mga ahensya na gumamit ng ARIA, dapat nilang malaman na responsable sila sa paglikha ng naaangkop at katulad na katutubong karanasan para sa mga pantulong na teknolohiya sa web (gaya ng pagkakasunud-sunod ng tab sa keyboard). 

Ang WEB-44 – WEB-53 ay partikular na nagsasaad ng mga kinakailangan para sa paggamit ng ARIA sakaling makahanap ang mga ahensya ng sitwasyon kung saan walang katumbas na semantic markup. Maaaring i-reference ng mga developer ang W3C's Accessible Rich Internet Applications (WAI-ARIA) 1.3 para sa mas malalim na detalye para sa mga pamantayan ng ARIA, habang maaaring i-reference ng mga designer ang ARIA Authoring Practice Guide (APG) ng W3C para sa impormasyon sa mga karaniwang pattern ng disenyo at kung paano magdisenyo ng mga pakikipag-ugnayan na pinakamahusay na gumagana sa paggamit ng ARIA. 

Pakikipag-ugnayan ng User sa Layout

WEB-54 – WEB-102

WEB-54 – WEB-102: Pakikipag-ugnayan ng user sa layout

Pag-unawa sa WEB-54 – WEB-102

Kapag gumagawa ang mga ahensya ng mga website, dapat nilang isaalang-alang hindi lamang ang "pinakakaraniwang" user, ngunit isang disenyo para sa isang malawak na iba't ibang uri ng user at lived na karanasan. Ang mga pangkat na ito ay karaniwang nahahati sa mga sumusunod na kategorya: 

  • Visual
  • Auditory
  • Motor
  • Cognitive 

Dahil dito, dapat tiyakin ng mga ahensya na ang kanilang mga website ay may kakayahang ma-access at makipag-ugnayan sa limang pangkat ng user na ito at available ang mga alternatibong variation ng mga pakikipag-ugnayan ng kanilang website. Kung ang isang link ay naa-access gamit ang isang mouse pointer, halimbawa, ito ay dapat ding magagamit sa pamamagitan ng keyboard sa pamamagitan ng tab order, sa pamamagitan ng mga screen reader sa pamamagitan ng semantic markup, at biswal na tinutukoy hindi lamang sa pamamagitan ng kulay. Bukod pa rito, dapat isaalang-alang ng mga ahensya ang paglalarawan ng mga visual na medium (tulad ng mga larawan) sa pamamagitan ng alt text, at descriptive o iba pang katumbas na text para sa auditory cues.  

Dapat pahintulutan ng mga ahensya ang mga user ng ganap na kontrol sa web page kung naglalaman ito ng na-play na media (auditory at/o visual) at maiwasan ang pag-flash at pag-scroll ng imagery para sa mga user na maaaring magkaroon ng epilepsy o migraine trigger. 

Kapag nagdududa, panatilihin itong simple! 

Maaaring sumangguni ang mga developer at ahensya sa Mga pamantayan ng WCAG Web 2.1 para sa pinaka-up-to-date at naaprubahan na mga pamantayan sa web kung nais nilang sumisid nang mas malalim. gayunpaman, Pinagsama-sama ng Harvard University ang isang simple, madaling basahin na gabay sa nangungunang 10 mahahalagang bagay na dapat isaalang-alang ng mga developer na may accessibility na sumasaklaw sa karamihan ng mga paksang sakop sa WEB-54 – WEB-71. 

Ang WEB-72 – WEB-102 ay partikular na nakatuon sa paggawa ng mga website napapansin, nagagamit, at matatag. Ito ang tatlo sa apat na mga prinsipyo na nakadokumento sa Ang apat na prinsipyo ng WCAG sa pagiging naa-access. 

Ayon sa WCAG, ang apat na prinsipyong ito ay: 

  • Mahahalata - Dapat na presentable sa mga user ang impormasyon at mga bahagi ng user interface sa mga paraan na maaari nilang makita. Nangangahulugan ito na dapat na makita ng mga user ang impormasyong ipinakita (hindi ito makikita ng lahat ng kanilang mga pandama) 
  • Mapapatakbo - Ang mga bahagi ng user interface at nabigasyon ay dapat na gumagana. Nangangahulugan ito na ang mga user ay dapat na makapagpatakbo ng interface (ang interface ay hindi maaaring mangailangan ng pakikipag-ugnayan na hindi maaaring gawin ng isang user) 
  • Maiintindihan - Ang impormasyon at ang pagpapatakbo ng user interface ay dapat na maunawaan. Nangangahulugan ito na dapat na maunawaan ng mga user ang impormasyon pati na rin ang pagpapatakbo ng user interface (ang nilalaman o operasyon ay hindi maaaring lampasan ng kanilang pag-unawa) 
  • Matatag - Ang nilalaman ay dapat sapat na matatag na maaari itong bigyang-kahulugan nang mapagkakatiwalaan ng isang malawak na iba't ibang mga ahente ng gumagamit, kabilang ang mga pantulong na teknolohiya. Nangangahulugan ito na dapat ma-access ng mga user ang content habang umuunlad ang mga teknolohiya (habang nagbabago ang mga teknolohiya at user agent, dapat manatiling naa-access ang content) 

Ang apat na prinsipyong ito ang bumubuo sa backbone ng modernong mga pamantayan ng accessibility sa web. 

Bilang karagdagan, ang WEB-72 ay nagsasaad na ang mga website ng ahensya ay dapat maglaman ng hindi bababa sa dalawa ng mga sumusunod na item: 

  • Listahan ng mga kaugnay na pahina  
  • Talaan ng nilalaman 
  • Mapa ng site 
  • Maghanap 
  • Listahan ng lahat ng pahina 

Para sa higit pang impormasyon sa maikli at pinasimpleng paraan, maaaring sumangguni ang mga ahensya Mga Prinsipyo ng Harvard University mula sa kanilang website ng Digital Accessibility Initiative. 

Navigation ng User Device

WEB-103 – WEB-120

WEB-103 – WEB-120: Navigation ng device ng user

Pag-unawa sa WEB-103 – WEB-120

Ang WEB-103 – WEB-120 ay partikular na nakatuon sa mga alternatibong paraan upang mag-navigate sa isang website. Mahalagang matanto na hindi lahat ng user ay gumagamit ng input device na gumagamit ng mouse pointer. Maaaring kabilang sa mga alternatibong input device ang mga screen reader, voice command, mouth stick, sip at puff, at ang tab at enter key na makikita sa mga keyboard ng computer, upang pangalanan ang ilan. 

Ang mga ahensya ay maaaring matuto nang higit pa tungkol sa mga pantulong na teknolohiya sa Ang webpage ng Mga Uri ng Pantulong na Teknolohiya ng Unibersidad ng Berkeley. 

Bukod pa rito, tinutukoy din ng seksyong EA na ito ang motor control function ng mga potensyal na user sa mga mobile device, na nagsasaad na: 

Ang mga web system ng COV ay hindi mangangailangan ng multipoint o path-based na mga galaw, gaya ng pagkurot, pag-swipe, o pag-drag. para sa functionality maliban kung ang kilos ay mahalaga sa functionality. 

Nangangahulugan ito na sa mga touch screen device, ang mga user ay dapat na makapag-zoom, magpalaki ng text, o magsagawa ng mga pangunahing pakikipag-ugnayan sa isang webpage nang hindi nangangailangan ng kontrol sa kilos; at ang mga website ay dapat na binuo upang tumugon sa katutubong iba't ibang laki ng screen at device. 

Makakahanap ang mga ahensya ng breakdown ng mga karagdagang diskarte sa accessibility, kabilang ang mga nasa seksyon, sa Ang webpage ng Mga Pantulong na Teknolohiya ng Harvard University. 

Nilalaman ng AV

WEB-121 – WEB-128

AV content: WEB-121 – WEB-128

Pag-unawa sa WEB-121 – WEB-128

Ang lahat ng audio at visual na media ay dapat na naaangkop na naa-access at naka-format para sa mga user sa web. Ang seksyong ito sa EA ay partikular na tumutukoy sa WCAG Guideline 1.2 - Time-based na Media, na nagbabalangkas kung paano dapat gawing accessible ang nilalaman ng AV sa mga website. Mga Pamantayan 1.2.1 at 1.2.5 ay dapat na sanggunian, na sumusunod sa ibaba: 

  • Ang isang alternatibo para sa time-based na media ay ibinigay na nagpapakita ng katumbas na impormasyon para sa prerecorded audio-only o video-only na nilalaman.  
  • Ang mga caption ay ibinibigay para sa lahat ng naka-prerecord na nilalamang audio sa naka-synchronize na media. 
  • Isang alternatibo para sa time-based na media o audio na paglalarawan ng prerecorded na nilalaman ng video ay ibinigay para sa naka-synchronize na media, 
  • Ang mga caption ay ibinibigay para sa lahat ng live na audio na nilalaman sa naka-synchronize na media. 
  • Ang paglalarawan ng audio ay ibinigay para sa lahat ng na-prerecord na nilalaman ng video sa naka-synchronize na media. 

Bukod pa rito, ang lahat ng live na content, gaya ng mga webinar at webcast na naka-host sa mga website o application ng ahensya ay dapat ding magbigay ng tumpak at on-time na mga caption (tulad ng real-time na captioning at/o transkripsyon ng CART). 

Ang mga gumagamit ay dapat ding magkaroon ng kakayahang i-pause, i-play, at ihinto ang media anumang oras; at hindi dapat awtomatikong magpe-play ang media kapag binisita ng user ang page.