Ibuo ang coverage batay sa mga customer task
Ilahad ang mga ruta at kinalabasan na nagdudulot ng halaga: paghahanap ng serbisyo, paghahanap (search), pagdagdag ng item, pag-book, pag-sign in, paghahanap ng tulong, o pagbabayad. Para sa bawat isa, pangalanan ang mga component na maaaring magbago ang hugis o mabigo: navigasyon, filter, card, table, larawan, banner, form, drawer, at embedded widget. Subukan ang mga lapad kung saan nagiging constrained ang iyong nilalaman, hindi lamang isang katalogo ng kasalukuyang modelo ng telepono. Subukan ng kaunti sa ibaba, sa, at kaunti sa ibabaw ng bawat breakpoint.
Isama ang makitid at mid-width na phone, isang tablet-like na lapad, laptop, malawak na desktop, at landscape kapag binabago nito ang gawain.
Gamitin ang mahahabang pamagat, empty results, validation errors, price badges, buong address, at mahahabang label kapag umiiral ang mga estadong iyon.
Patunayan ang reflow, pagbabasa, at zoom
Kumpirmahin na may angkop na viewport setting ang pahina, pagkatapos hanapin ang page-level horizontal scrolling. Karaniwang sanhi ang fixed images, malalapad na field, negative margins, off-canvas panels, at banner. Inilalarawan ng WCAG 2.1 Reflow criterion ang vertical-scrolling content sa lapad na katumbas ng 320 CSS pixels, kabilang ang 1280-pixel viewport sa 400% zoom. Kung saklaw ng iyong target ang kriteriyong iyon, subukan ang aktwal na zoom scenario. Maaaring mangailangan ng two-dimensional layout ang mapa, video, o data table, pero panatilihin ang pag-scroll na iyon sa loob ng component at hayaan ang nakapaligid na pahina na mag-reflow.
Suriin ang headers, main content, footers, sticky bars, dialogs, at error summaries sa bawat sinubukang boundary.
I-reorganisa ang impormasyon para sa makitid na screen; huwag tahimik na alisin ang isang kinakailangan, detalye ng presyo, o help path.
I-stress ang nilalaman at mga form
Maaaring magdulot ang content operations ng mga responsive failure nang walang CSS release. Subukan ang pinakamahabang aprubadong heading, maraming badge, nawawalang imahe, napiling filter, malaking legal notice, at browser-filled field. Kapag nag-stack ang mga kolum, i-verify na may katuturan pa rin ang reading at keyboard order. Kumpletuhin ang totoong form sa maliit na device: buksan ang mga control, itama ang error, at isumite. Subukan ang third-party widgets sa production-like na pahina dahil ang kanilang container, consent state, fonts, at styles ay maaaring magbago ng resulta.
Ipadama ang malamang na maximum lengths at kombinasyon, ngunit huwag isama ang customer o payment data sa QA evidence.
Buksan ang notices, chat, promotions, at validation messages nang sabay; wala sa mga ito ang dapat takpan ang pangunahing aksyon o ang focused field.
Isanay ang bawat input path
Ang malaking screen ay hindi nangangahulugang may mouse, at ang maliit na screen ay hindi nangangahulugang touch lamang. Sinusuri ng hover media feature kung maaaring mag-hover nang maginhawa ang pangunahing input, kaya ang hover ay dapat magdagdag ng karagdagan kaysa maging nag-iisang daan papunta sa isang aksyon o paliwanag. Subukan ang keyboard at pointer use sa desktop, taps at scrolling sa touch device, at mixed-input devices kung may kaugnayan. Suriin ang compact close buttons, steppers, chips, calendars, at icon actions. Tinukoy ng WCAG 2.2 Target Size (Minimum) ang 24 by 24 CSS-pixel target size na may mga pinaglinyang eksepsyon, kabilang ang spacing at inline links. Ito ay isang kriteriyon na may saklaw at eksepsyon, hindi isang pangakong pantay na madali ang bawat 24-pixel control para sa lahat.
Tab sa kabuuan ng pahina. Dapat manatiling nakikita ang focus, sumunod sa makatuwirang pagkakasunod-sunod, at pumasok at lumabas sa mga menu at dialog nang predictable.
Gawing available ang isang mahalagang hover reveal sa pamamagitan ng focus, tap, o isang nakikitang kontrol, at pigilan ang nakalilitong unang-tap na pag-uugali.
Beripikahin ang mga asset at performance sa ilalim ng mga limitasyon
Maaaring magkasya ang isang imahe sa kanyang container at maging maling file pa rin para sa device. Suriin na nananatiling contained ang media, nagre-reserve ng layout space kapag naaangkop, pinapanatili ang kapaki-pakinabang na crop, at humihiling ng angkop na candidates. Nagbibigay ang srcset at sizes ng impormasyon sa browser para pumili mula sa mga sinuplying image source; hindi nito ginagarantiya ang isang tiyak na request. Gamitin ang DevTools throttling para matuklasan ang mga problema nang maaga, pero ang kanyang CPU at network controls ay nag-simulate ng mga kondisyon na relative sa development computer. Muling i-check ang mga key journey sa totoong device at koneksyon. Suriin ang fonts, hero media, carousels, client-side work, at third-party scripts para sa delay, shift, o blocked taps.
I-capture ang ruta, viewport, totoong o simulated na koneksyon, at kung ano ang bumagal o naging unstable; ihambing ang magkatulad na kondisyon.
Kung ligtas, i-delay ang mga nonessential embed sa test build upang malaman kung nananatiling magagamit ang core task.
Ayusin bilang proactive uptime work
Para sa Status Is UP, ang responsive readiness ay proactive uptime optimization: tukuyin ang user-blocking device path, itama ang sanhi nito, patunayan ang pag-aayos, at pigilan ang pag-uulit. Hindi ito pahayag na kayang husgahan ng monitoring alert ang bawat layout o interaction defect. I-prioritize ayon sa impact ng task at saklaw. Bago i-deploy, subukan ang kalapit na mga lapad at ang binagong journey sa totoong hardware. Magplano ng rollback para sa pagbabago sa shared navigation, styles, scripts, payments, o integrations. Pagkatapos ng release, ulitin ang mga hakbang ng patunay at i-attach ang ebidensya sa change record.
I-state ang ruta, device o viewport, orientation, input, state, inaasahang resulta, aktwal na resulta, at isang redacted capture.
Mas piliin ang pag-aayos sa component, layout rule, token, o image-delivery kaysa isang route-only override; bigyan ang mga eksepsiyon ng may-ari at plano para alisin ang mga ito.