Bangun cakupan di sekitar tugas pelanggan
Daftar rute dan hasil yang menciptakan nilai: menemukan layanan, pencarian, menambahkan item, pemesanan, masuk, meminta bantuan, atau membayar. Untuk masing-masing, sebutkan komponen yang dapat berubah bentuk atau gagal: navigasi, filter, kartu, tabel, gambar, banner, formulir, drawer, dan widget tersemat. Uji lebar di mana konten Anda menjadi terbatas, bukan sekadar katalog model ponsel saat ini. Uji sedikit di bawah, pada, dan sedikit di atas setiap breakpoint.
Sertakan ponsel berlebar sempit dan sedang, lebar mirip tablet, laptop, desktop lebar, dan lanskap bila itu mengubah tugas.
Gunakan judul panjang, hasil kosong, kesalahan validasi, badge harga, alamat lengkap, dan label lebih panjang bila keadaan itu ada.
Buktikan reflow, keterbacaan, dan zoom
Konfirmasi halaman memiliki pengaturan viewport yang tepat, lalu periksa pengguliran horizontal di tingkat halaman. Gambar tetap, field lebar, margin negatif, panel off-canvas, dan banner adalah penyebab umum. Kriteria Reflow WCAG 2.1 menggambarkan konten yang dapat digulir secara vertikal pada lebar ekuivalen 320 CSS pixels, termasuk viewport 1280-pixel pada zoom 400%. Jika kriteria itu masuk ruang lingkup, uji skenario zoom sebenarnya. Peta, video, atau tabel data mungkin memerlukan tata letak dua dimensi, tapi jaga agar pengguliran tetap berada dalam komponen dan biarkan halaman di sekitarnya melakukan reflow.
Periksa header, konten utama, footer, sticky bar, dialog, dan ringkasan kesalahan pada setiap batas yang diuji.
Atur ulang informasi untuk layar sempit; jangan diam-diam menghapus persyaratan, detail harga, atau jalur bantuan.
Tekan konten dan formulir
Operasi konten dapat menyebabkan kegagalan responsif tanpa rilis CSS. Uji judul terpanjang yang disetujui, beberapa badge, gambar yang hilang, filter terpilih, catatan hukum panjang, dan field yang diisi browser. Saat kolom menumpuk, konfirmasi bahwa urutan bacaan dan keyboard masih masuk akal. Lengkapi formulir nyata pada perangkat kecil: buka kontrol, koreksi kesalahan, dan kirim. Uji widget pihak ketiga pada halaman yang mirip produksi karena container, status persetujuan, font, dan gaya mereka dapat mengubah hasil.
Cerminkan panjang dan kombinasi maksimum yang mungkin, tetapi jangan sertakan data pelanggan atau pembayaran dalam bukti QA.
Buka notifikasi, chat, promosi, dan pesan validasi bersama; tidak satu pun boleh menutupi aksi utama atau field yang sedang fokus.
Jalankan setiap jalur input
Layar besar tidak menjamin mouse, dan layar kecil tidak menjamin hanya sentuhan. Media feature hover menguji apakah input utama dapat meng-hover dengan mudah, jadi hover harus meningkatkan pengalaman dan bukan menjadi satu-satunya jalan menuju aksi atau penjelasan. Uji penggunaan keyboard dan pointer di desktop, ketukan dan pengguliran pada perangkat sentuh, dan perangkat input campuran bila relevan. Tinjau tombol tutup kompak, steppers, chip, kalender, dan aksi ikon. WCAG 2.2 Target Size (Minimum) menentukan ukuran target 24 by 24 CSS-pixel dengan pengecualian yang didefinisikan, termasuk spasi dan tautan inline. Itu adalah kriteria dengan ruang lingkup dan pengecualian, bukan janji bahwa setiap kontrol 24-piksel sama mudahnya untuk semua orang.
Tab melalui halaman. Fokus harus tetap terlihat, mengikuti urutan yang masuk akal, dan masuk serta keluar menu dan dialog secara dapat diprediksi.
Buat pengungkapan hover penting tersedia melalui fokus, ketukan, atau kontrol yang terlihat, dan cegah perilaku ketukan-pertama yang membingungkan.
Verifikasi aset dan kinerja di bawah keterbatasan
Sebuah gambar bisa pas di kontainernya namun tetap file yang salah untuk perangkat. Periksa bahwa media tetap tertata dalam kontainer, menyisakan ruang tata letak bila perlu, mempertahankan crop yang berguna, dan meminta kandidat yang sesuai. srcset dan sizes memberi browser informasi untuk memilih antara sumber gambar yang disediakan; itu tidak menjamin permintaan tertentu. Gunakan throttling DevTools untuk menemukan masalah lebih awal, tetapi kontrol CPU dan jaringan-nya mensimulasikan kondisi relatif terhadap komputer pengembangan. Periksa ulang jalur kunci pada perangkat nyata dan koneksi nyata. Inspeksi font, hero media, carousel, pekerjaan sisi-klien, dan skrip pihak ketiga untuk keterlambatan, pergeseran, atau ketukan yang tertutup.
Tangkap rute, viewport, koneksi nyata atau disimulasikan, dan apa yang menjadi lambat atau tidak stabil; bandingkan kondisi yang sepadan.
Jika aman, tunda embed yang tidak penting di build uji untuk mengetahui apakah tugas inti tetap dapat digunakan.
Tindaklanjuti sebagai pekerjaan kesiapan uptime proaktif
Untuk Status Is UP, kesiapan responsif adalah optimasi uptime proaktif: identifikasi jalur perangkat yang memblokir pengguna, koreksi penyebabnya, buktikan perbaikan, dan cegah berulang. Ini bukan klaim bahwa alert pemantauan dapat menilai setiap cacat tata letak atau interaksi. Prioritaskan menurut dampak tugas dan jangkauan. Sebelum penyebaran, uji lebar yang berdekatan dan perjalanan yang diubah pada perangkat nyata. Rencanakan rollback untuk perubahan pada navigasi bersama, gaya, skrip, pembayaran, atau integrasi. Setelah rilis, ulangi langkah pembuktian dan lampirkan bukti pada catatan perubahan.
Nyatakan rute, perangkat atau viewport, orientasi, input, status, hasil yang diharapkan, hasil aktual, dan tangkapan layar yang disunting (redacted).
Utamakan perbaikan komponen, aturan tata letak, token, atau pengiriman gambar daripada override hanya pada rute; berikan pengecualian pemilik dan rencana penghapusannya.
