1. Pilih pekerjaan halaman sebelum memilih tata letak
Mulailah dengan halaman yang membawa tugas pelanggan atau bisnis: halaman layanan, halaman produk, formulir lead, pemesanan, masuk akun, keranjang, dan bantuan. Tulis satu pernyataan penyelesaian untuk masing‑masing, misalnya: “Seorang pengunjung baru dapat memahami layanan ini, melihat bukti relevan, dan meminta panggilan.” Jika halaman memiliki lebih dari satu pekerjaan, putuskan mana yang muncul lebih dulu.
Daftar isinya sebagai esensial, pendukung, atau opsional. Esensial tidak berarti singkat; pengunjung mungkin membutuhkan konteks harga, kelayakan, detail pengiriman, atau informasi perbandingan. Beri materi itu jalur yang jelas pada tata letak sempit. Google menyarankan kesetaraan konten primer pada mobile dan desktop, sambil memperbolehkan penyajian berbeda seperti tab atau akordeon.
Pada lebar sempit, seorang rekan harus dapat mengatakan apa yang ditawarkan halaman, siapa yang diuntungkan, dan tindakan bermakna berikutnya.
2. Buat baseline sempit yang lengkap
Mulailah dengan jalur kolom tunggal yang bekerja daripada mengecilkan tata letak desktop. Gunakan kontainer fleksibel, biarkan teks membungkus, dan sertakan pengaturan viewport yang membiarkan browser menyesuaikan tata letak ke lebar perangkat. Jangan mencegah zoom. Periksa bahwa menu, pemberitahuan, gambar, embed, dan kesalahan formulir tetap di dalam viewport; scrolling horizontal pada tingkat halaman yang tidak disengaja biasanya adalah cacat.
Gunakan 320 CSS pixels sebagai pemeriksaan reflow yang menantang untuk bacaan dan konten tugas biasa. WCAG 2.2 menggambarkan penyajian konten vertikal pada lebar itu tanpa kehilangan informasi atau fungsionalitas atau kebutuhan scrolling dua dimensi. Peta, grafik, atau tabel data dapat memerlukan area scroll sendiri, tetapi itu tidak membenarkan membuat halaman sekitarnya bergulir ke samping.
Sesuaikan gambar dengan kontainernya dan sediakan dimensi sehingga browser dapat menyediakan ruang sebelum gambar dimuat.
3. Tambahkan peningkatan tanpa membuat jalur dasar rapuh
Progressive enhancement berarti konten dan fungsionalitas esensial bekerja sebagai baseline, sementara browser yang mampu dan layar lebih besar menerima tambahan. Alamat, detail produk, label formulir, penjelasan harga, dan jalur pengiriman tidak boleh bergantung pada animasi, hover, atau skrip yang dimuat terakhir. Tata letak yang lebih lebar dapat menambahkan panel perbandingan, navigasi persisten, atau penyaringan yang lebih kaya tanpa membuat baseline menjadi tidak lengkap.
Minta pelaksana menambahkan breakpoint ketika konten menjadi sempit atau tidak efisien, bukan karena muncul nama perangkat tertentu. Breakpoint hanyalah tempat aturan tata letak berubah. Jangan gunakan tata letak sempit untuk diam‑diam menghapus teks bantuan, syarat kebijakan, ulasan, metadata, atau detail terstruktur penting.
Tampilkan gambar galeri dasar dan deskripsi terlebih dahulu, lalu tambahkan kontrol zoom atau swipe ketika skripnya tersedia.
4. Rancang kontrol untuk sentuhan, kejelasan, dan pemulihan
Ergonomi sentuh berarti merancang untuk tangan, bukan penunjuk mouse yang presisi. Beri tombol, kotak centang, ikon tutup, pengatur kuantitas, dan pilihan formulir ukuran dan pemisahan yang cukup untuk mengurangi kesalahan ketuk. Beri label ikon ketika maknanya tidak jelas. Jangan jadikan hover sebagai satu‑satunya cara untuk menampilkan harga, submenu, penjelasan, atau aksi.
WCAG 2.2 mencakup kriteria ukuran target Level AA sekurang‑kurangnya 24 by 24 CSS pixels untuk target penunjuk, dengan pengecualian yang dinyatakan termasuk jarak dan tautan inline. Perlakukan itu sebagai acuan minimum, bukan jaminan kenyamanan. Aksi kritis layak mendapat label jelas, jarak luas, dan langkah konfirmasi yang dapat dibalik. Mintalah tinjauan aksesibilitas yang memenuhi syarat untuk jalur berisiko tinggi atau klaim konformansi formal.
Pertahankan label tetap terlihat, tampilkan umpan balik validasi yang dapat digunakan, dan simpan nilai yang dimasukkan setelah terjadi kesalahan.
5. Perlakukan media dan embed sebagai bagian dari perjalanan pengunjung
Tentukan apakah setiap gambar bersifat informatif, persuasif, atau dekoratif. Gambar informatif memerlukan alternatif teks yang sesuai dan crop untuk tata letak sempit yang mempertahankan detail yang diperlukan. Opsi gambar responsif membiarkan browser memilih sumber yang sesuai alih‑alih membuat setiap pengunjung mengunduh aset desktop terbesar. Jangan biarkan gambar hero atau video menutupi tujuan halaman dan aksi utama.
Inventarisasikan peta, chat, video, pembayaran, penjadwalan, persetujuan, dan widget ulasan. Pada layar sempit, periksa status pemuatan, ukuran kontrol, tata letak terbatas, dan rute fallback yang praktis. Untuk pembayaran, identitas, atau aliran data yang diatur, libatkan peninjau keamanan, privasi, dan kepatuhan yang berkualifikasi; pengujian visual bukanlah penilaian keamanan.
Catat setiap komponen eksternal, pemiliknya, fungsi bisnisnya, dan fallback yang disetujui jika lambat atau rusak.
6. Uji jalur tugas sebelum rilis dan rencanakan remediasi
Gunakan mode responsif browser sejak awal untuk memeriksa lebar sempit, sedang, dan lebar. Chrome Device Mode dapat memperkirakan viewport, sentuhan, orientasi, jaringan, dan kondisi CPU, tetapi Chrome mendokumentasikan ini sebagai perkiraan, bukan eksekusi perangkat nyata. Selesaikan jalur kritis di ponsel nyata dan browser yang relevan bila memungkinkan.
Uji sebuah tugas, bukan hanya screenshot: cold load, navigasi, pengiriman formulir tidak valid dan valid, perubahan orientasi, zoom, dan kembali dari layar pihak ketiga. Catat URL, browser atau perangkat, tugas, hasil yang diharapkan, pemilik, dan keputusan rollback. Untuk perubahan besar pada template, checkout, CMS, atau dependensi, tahapkan rilis dan siapkan untuk mengembalikan jalur sebelumnya alih‑alih mengimprovisasi di bawah tekanan.
Setujui hanya setelah tugas kritis bekerja, kontrol dapat digunakan, tidak ada scroll horizontal tingkat halaman, dan dependensi utama memiliki fallback.