1. Piliin muna ang tungkulin ng pahina bago ang layout
Magsimula sa mga pahinang may dalang gawain ng customer o negosyo: service pages, product pages, lead forms, booking, pag-login ng account, cart, at help. Isulat ang isang completion statement para sa bawat isa, halimbawa: "Ang isang first-time visitor ay maaari nang maunawaan ang serbisyong ito, makita ang kaukulang patunay, at humiling ng tawag." Kung higit sa isang tungkulin ang pahina, magpasya kung alin ang mauuna.
Ilista ang nilalaman bilang essential, supporting, o optional. Hindi nangangahulugang maigsi ang essential; maaaring kailanganin ng bisita ang konteksto ng presyo, eligibility, detalye ng paghahatid, o impormasyon ng paghahambing. Bigyan ng malinaw na ruta ang materyal na iyon sa makitid na layout. Pinapayuhan ng Google na magkasingkahulugan ang pangunahing nilalaman sa mobile at desktop, habang pinapayagan ang ibang presentasyon tulad ng tabs o accordions.
Sa makitid na lapad, dapat masabi ng isang kasamahan kung ano ang inaalok ng pahina, sino ang pinakikinabangan nito, at ang susunod na makabuluhang aksyon.
2. Gawing kumpleto ang makitid na baseline
Magsimula sa gumaganang single-column path sa halip na paliitin ang desktop layout. Gumamit ng flexible containers, hayaang mag-wrap ang teksto, at isama ang viewport setting na nagpapahintulot sa browser na i-size ang layout ayon sa lapad ng device. Huwag pigilan ang zoom. Siguraduhing ang mga menu, paalala, imahe, embed, at error sa form ay manatili sa loob ng viewport; ang hindi inaasahang page-level horizontal scrolling ay karaniwang depekto.
Gumamit ng 320 CSS pixels bilang isang mahigpit na reflow check para sa ordinaryong pagbabasa at task content. Inilarawan ng WCAG 2.2 ang pagpapakita ng patayong nilalaman sa lapad na iyon nang walang pagkawala ng impormasyon o pag-andar o dalawang-dimensiyong pag-scroll. Maaaring mangailangan ang mapa, chart, o data table ng sarili nitong scroll region, ngunit hindi nito pinapalaganap ang paggawa ng paligid na pahina na mag-scroll nang pahalang.
I-fit ang mga imahe sa kanilang container at magbigay ng sukat upang makareserba ng espasyo ang browser bago pa man mag-load ang mga ito.
3. Magdagdag ng enhancements nang hindi pinapahina ang base path
Ang progressive enhancement ay nangangahulugang gumagana ang mahalagang nilalaman at functionality bilang baseline, habang ang mga browser na may kakayahan at ang mas malalaking screen ay tumatanggap ng dagdag. Ang address, detalye ng produkto, label ng form, paliwanag sa presyo, at submit path ay hindi dapat umasa sa animation, hover, o sa huling script. Maaaring magdagdag ang mas malapad na layout ng comparison panel, persistent navigation, o mas mayamang filtering nang hindi ginagawa ang baseline na hindi kumpleto.
Hilingin sa implementer na magdagdag ng breakpoint kapag siksikan o nasasayang ang nilalaman, hindi dahil may nakalistang pangalan ng device. Ang breakpoint ay simpleng punto kung saan nagbabago ang rule ng layout. Huwag gamitin ang makitid na layout para tahimik na alisin ang help text, policy terms, reviews, metadata, o mahahalagang structured na detalye.
Ipakita muna ang basic gallery image at deskripsyon, pagkatapos idagdag ang zoom o swipe controls kapag available na ang mga script nila.
4. Idisenyo ang mga kontrol para sa touch, kalinawan, at recovery
Ang touch ergonomics ay nangangahulugang pagdidisenyo para sa mga kamay sa halip na eksaktong mouse pointer. Bigyan ng sapat na laki at agwat ang mga button, checkbox, close icon, quantity selector, at pagpipilian sa form para mabawasan ang maling tap. Lagyan ng label ang mga icon kapag hindi halata ang ibig sabihin. Huwag gawing tanging paraan ang hover para ipakita ang presyo, submenu, paliwanag, o aksyon.
Kasama sa WCAG 2.2 ang Level AA target-size criterion na hindi bababa sa 24 by 24 CSS pixels para sa pointer targets, na may nakasaad na mga eksepsyon kabilang ang spacing at inline links. Tratuhin ito bilang minimum reference, hindi garantiya ng kaginhawaan. Karapat-dapat sa malinaw na label, maluwag na spacing, at reversible confirmation step ang kritikal na mga aksyon. Humanap ng kwalipikadong accessibility review para sa high-risk na mga paglalakbay o pormal na claim ng conformance.
Panatilihin ang mga label na nakikita, magpakita ng usable validation feedback, at panatilihin ang na-enter na mga halaga pagkatapos ng isang error.
5. Tratuhin ang media at embeds bilang bahagi ng paglalakbay ng bisita
Magpasya kung ang bawat imahe ay nagbibigay-kaalaman, nakapanghikayat, o dekoratibo. Ang isang informative na imahe ay nangangailangan ng angkop na text alternative at crop para sa makitid na layout na nagpapanatili ng kinakailangang detalye. Pinapayagan ng responsive image options ang browser na pumili ng angkop na resource sa halip na pilitin ang bawat bisita na i-download ang pinakamalaking desktop asset. Huwag hayaang ang hero image o video ay magtakas sa layunin ng pahina at pangunahing aksyon.
I-inventory ang mga mapa, chat, video, payment, scheduling, consent, at review widgets. Sa makitid na screen, suriin ang kanilang loading state, laki ng kontrol, bounded layout, at praktikal na fallback route. Para sa payment, identity, o regulated data flows, isangkot ang mga kwalipikadong reviewer sa security, privacy, at compliance; ang visual testing ay hindi assessment ng seguridad.
Itala ang bawat external component, ang may-ari nito, ang business function nito, at ang inaprubahang fallback kung ito ay mabagal o sira.
6. Subukan ang mga task path bago mag-release at magplano ng remediation
Gamitin ang browser responsive mode nang maaga para inspeksyunin ang makitid, medium, at malapad na lapad. Maaaring i-approximate ng Chrome Device Mode ang viewport, touch, orientation, network, at CPU conditions, ngunit binabanggit ng Chrome na approximation lamang ito at hindi totoong real-device execution. Kumpletuhin ang kritikal na mga path sa aktwal na mga telepono at kaugnay na browser kung maaari.
Subukan ang isang task, hindi lamang isang screenshot: cold load, navigation, invalid at valid na pagsusumite ng form, pagbabago ng orientation, zoom, at pagbalik mula sa third-party screen. Itala ang URL, browser o device, task, inaasahang resulta, may-ari, at rollback decision. Para sa malalaking pagbabago sa template, checkout, CMS, o dependencies, i-stage ang release at ihanda ang pagpapanumbalik ng naunang path sa halip na improvisasyon habang nasa ilalim ng pressure.
Mag-apruba lamang pagkatapos gumana ang critical task, magamit ang mga kontrol, mawala ang page-level horizontal scroll, at may fallback ang mga pangunahing dependency.