Magsimula sa mga gawain at maliit na information architecture
Ang information architecture ay kung paano pinagsasama, pinapangalanan, at pinag-uugnay ang nilalaman at mga function. Ilahad ang mga gawain ng bisita, pagkatapos i-map ang panimulang pahina ng bawat gawain, ang susunod na pahina, at ang matagumpay na end state. Ipinapakita nito kung kapaki-pakinabang ang isang menu item o kung isang internal na label na kailangang i-decode ng mga bisita. Panatilihing nakatutok ang primary navigation sa mga seksyong nagsisimula ng mga gawaring iyon.
Ang nabigasyon ay hindi isang site map. Pinapayuhan ng GOV.UK ang paglista ng mga kapaki-pakinabang na top-level na seksyon sa halip na bawat bahagi ng isang serbisyo. Kapag may kinakailangang pagkakasunod ang isang paglalakbay, ipakita ito sa nilalaman o sa isang task list sa halip na ipaghinuha ng mga tao mula sa global menu.
Pagsamahin ang mga pahina kapag inaasahan ng mga bisita ang parehong sagot o gawain, hindi dahil isa lang ang may-ari na koponan nila.
Gumamit ng landing pages at contextual links para sa detalye sa halip na isang masiksik na header.
Gumamit ng mga label na nagbibigay-asang tutungo sa destinasyon
Ang label ay isang pangako tungkol sa susunod na haharapin. Mas piliin ang pamilyar na mga pangalan tulad ng “Pricing”, “Documentation”, “Get support”, o “Manage account” kapag tumutugma ito sa destinasyon. Iwasan ang malabo at malawak na label tulad ng “Resources” o “Explore” maliban kung maaring hulaan ng mga bisita ang laman nito. Panatilihin ang pagkakapareho ng pananalita at pagkakasunod.
Pinapayuhan ng Google ang maikli at may-kaugnayang link text na naiintindihan kahit out of context. Ang generic na “click here” at mga keyword-stuffed na link ay hindi nakakatulong. Bigyan ng accessible name ang icon-only control na naglalarawan ng aksyon nito.
Gamitin ang “View plans” sa halip na “Learn more” kapag ang destinasyon ay mga plano.
I-markahan ang aktibong destinasyon visual at programmatically; inilalarawan ng W3C ang aria-current=page para sa ipinapakitang pahina.
Gawing crawlable at structurally clear ang mga destinasyon
Ang isang destinasyon sa nabigasyon ay karaniwang dapat isang HTML anchor na may href na nagre-resolve sa isang totoong web address. Sinasabi ng Google na kadalasan ay makakacrawl ito sa ganitong anyo, kasama ang dinamically inserted anchors kapag pinananatili ng rendered markup ang istrukturang iyon. Ang isang click handler o custom attribute lamang ay hindi maaasahang pamalit. Inspeksyunin ang rendered output, hindi lamang ang framework source.
Gumamit ng semantikong istruktura sa paligid ng pangunahing nabigasyon. Inirerekomenda ng W3C ang isang nav element at, para sa ordinaryong site navigation, isang list. Kung ang isang pahina ay may ilang rehiyon ng nabigasyon, lagyan ng label bawat isa upang ang screen-reader user ay makapaghihiwalay ng primary navigation mula sa footer o lokal na nabigasyon.
Kumpirmahin na ang mahalagang desktop at mobile destinasyon ay may anchors at href values pagkatapos ng client-side rendering.
Nagbibigay ang URL Inspection ng impormasyon sa crawl, index, at serving ng Google; hindi nito pinapatunayan na ang mga bisita ay makakahanap ng isang pahina.
Disenyuhin ang mobile menu bilang isang kumpletong interaction
Maaaring mag-collapse ang responsive navigation, ngunit ang mga destinasyong nananatili ay dapat panatilihin ang parehong wording, pagkakasunod, at target sa lahat ng laki ng screen. Pinapayagan ng W3C ang pag-collapse o pagtatago ng mga item sa subnavigation habang hinihingi ang consistency. Huwag gawing desktop-only ang isang kritikal na ruta dahil lang siksik ang header; ilipat ang mga mababang-priority na materyal o muling isaalang-alang ang hierarchy.
Para sa isang show-and-hide menu, gumamit ng button upang kontrolin ang grupo ng link at ipahatid kung bukas ito o hindi. Ginagamit ng disclosure-navigation example ng W3C ang aria-expanded at aria-controls at dinidokumento ang Tab, Shift+Tab, at Escape. Panuto lamang iyon, kaya subukan ang iyong component sa kombinasyong ginagamit ng iyong audience.
Kapag kailangan ang parehong parent page at ang mga child link nito, gawing magkakaiba ang page link at ang control na nagpapalawak nito.
Ang anumang bagay na ipinapakita dahil lang sa pointer hover ay dapat ma-discover din gamit ang keyboard focus at touch.
Suportahan ang orientation at keyboard travel
Ang keyboard access ay hindi isang pangwakas na dagdag. Ang WCAG 2.1 Success Criterion 2.1.1 ay nangangailangan na ang functionality ay ma-o-operate sa pamamagitan ng keyboard interface maliban sa path-dependent input. Sa header, dapat makapag-Tab ang mga bisita sa mga control, makita ang focus, i-activate ang mga link at button, at makalabas nang walang trap.
Ang paulit-ulit na mga link sa header ay maaaring magpabagal sa paglalakbay sa mga pahina. Ang isang skip link malapit sa simula ay nagbibigay sa mga keyboard user ng ruta papunta sa main content. Ipinaliwanag ng GOV.UK na ito ay visually hidden hanggang ma-activate ng paggamit ng keyboard. Subukan na tumama ito sa makabuluhang target.
Huwag alisin ang browser focus indicator nang walang malinaw na alternatibo na nananatiling visible kapag naka-zoom.
Gamitin ang Tab, Shift+Tab, Enter, Space, at Escape mula sa header papunta sa destination page.
Subukin ang findability bago at pagkatapos ilabas
Hilingin sa mga representatibong tao na kumpletuhin ang isang realistang gawain, tulad ng paghahanap ng gabay sa kanselasyon o paghahambing ng mga plano. Panoorin kung saan nila inaasahang pupunta, aling mga label ang kanilang maling binabasa, at kung babagsak sila sa paghahanap dahil nabigo ang nabigasyon sa kanila. Huwag pangunahan sila papunta sa inaasahang label. Itala ang bawat hadlang at ang pinakamaliit na pagbabago na malamang magtanggal nito.
Ipares ang task testing sa teknikal na tseke. Inirerekomenda ng W3C’s Easy Checks ang pagsubok nang walang mouse, kasama ang visibility ng focus, tab order, keyboard traps, at dropdowns. Ulitin ang pangunahing gawain sa makitid na lapad at mas malaking laki ng teksto. Maaaring mag-flag ang automated checks ng mga markup issue, ngunit hindi nila matitiyak na may sentido ang isang label.
Itala ang intensiyong endpoint at suportadong device o input method bago mag-test.
Subukan ang lumang at bagong ruta laban sa parehong gawain sa halip na umasa sa pabor ng stakeholder.
Tratuhin ang mga pagbabago sa nabigasyon bilang availability-sensitive na release
Maaaring mag-load ang isang header habang ang isang kritikal na path ay epektibong hindi magagamit: ang checkout, login, support route, o dokumentasyon ay maaaring nasa likod ng sirang state, stale link, o maling redirect. Bago ilabas, imbentaryuhin ang mga kritikal na destinasyon, subukan ang desktop at mobile routes, at kumpirmahing ang rendered links ay tumutungo sa inaasahang pahina. Gumamit ng authorized na environment para sa authenticated o regional na mga path.
Ang papel ng SIU ay proaktibong remediation: magpatakbo ng preflight, i-verify ang mahalagang landas pagkatapos ng deployment, at gawing reversible ang mga pagwawasto. Panatilihin ang versioned menu configuration, pangalanan ang taong may awtoridad na makakapag-restore nito, at i-validate ang na-restore na mga landas. Nililimitahan nito ang epekto ng release; hindi nito pinapalitan ang usability research o live-status monitoring.
Pigilan ang publikasyon kapag may nawawala, maling, o hindi maaabot na kritikal na destinasyon gamit ang keyboard at touch.
Idokumento ang naunang configuration, owner, trigger, at mga hakbang sa validation bago mag-restructure.