Bagaimanakah pasukan web patut melaporkan kemajuan kebolehcapaian apabila pengalaman pengguna tidak mudah diringkaskan kepada lulus atau gagal? Pada 25 September 2026, W3C menerangkan pendekatan baharu dalam draf WCAG 3 yang membezakan pemenuhan keperluan teras daripada pelaporan kemajuan tambahan.
Perkembangan ini relevan kepada pembangun, penguji perisian dan pereka pengalaman pengguna di Malaysia. Namun, WCAG 3 masih draf. Nilai terdekatnya ialah membantu pasukan memikirkan cara menilai halangan pengguna dengan lebih teratur sambil meneruskan kerja berasaskan standard semasa.
Dokumen kerja WCAG 3.0 bertarikh 10 September 2026 menyatakan bahawa kandungannya boleh dikemas kini, diganti atau ditarik balik. Penerbitan sebagai Working Draft juga tidak bermaksud W3C dan ahlinya telah memberikan pengesahan terhadap semua cadangan di dalamnya.
Halaman pengenalan rasmi W3C menjelaskan bahawa struktur, model pemenuhan standard dan skop WCAG 3 berbeza daripada WCAG 2. Banyak bahagiannya masih boleh berubah dengan ketara. W3C menyarankan pemenuhan kriteria kejayaan WCAG 2.2 sekarang sebagai persediaan terbaik untuk WCAG 3 pada masa hadapan.
Oleh itu, pengumuman September ini perlu dibaca sebagai perkembangan proses pembentukan standard. Ia belum menjadi asas untuk mendakwa bahawa sesuatu laman telah memenuhi standard WCAG 3 yang muktamad.
Sumber: WCAG 3 Introduction; W3C Accessibility Guidelines (WCAG) 3.0 — Working Draft, 10 September 2026.
Menurut penerangan W3C pada 25 September, pendekatan baharu itu mencadangkan satu tahap pemenuhan yang berasaskan keperluan teras, dibina daripada kriteria WCAG 2.2 tahap A dan AA. Keperluan tambahan, pernyataan tentang amalan organisasi dan amalan disyorkan pula memberi ruang untuk usaha yang melangkaui asas tersebut.
Draf itu turut menggunakan penanda untuk membantu pelaporan kemajuan. Halaman pengenalan menyenaraikan kategori berkaitan kemudaratan fizikal, risiko, halangan yang menyekat pengguna dan kesukaran yang mengganggu penggunaan. Dalam model cadangan ini, semua keperluan teras perlu dipenuhi untuk mencapai tahap pemenuhan.
W3C membezakan ukuran teknikal WCAG daripada peraturan yang menetapkan keperluan tertentu. Artikel ini tidak membuat kesimpulan tentang kewajipan undang-undang di Malaysia berdasarkan draf tersebut.
Sumber: Crafting WCAG 3 for more accessible user experiences; WCAG 3 Introduction.
Panduan W3C tentang penglibatan pengguna mengesyorkan penyertaan orang kurang upaya sejak awal dan sepanjang pembangunan. Pengguna boleh mencuba prototaip serta menunjukkan bagaimana mereka menjalankan tugasan sebenar, termasuk penggunaan teknologi bantuan.
Bagaimanapun, maklum balas seorang peserta tidak boleh dianggap mewakili semua orang yang mempunyai ketidakupayaan sama. Pengalaman, strategi penggunaan dan konfigurasi teknologi bantuan berbeza. W3C mengesyorkan gabungan penglibatan pengguna dengan penilaian terhadap standard.
Bagi pembaca yang mengurus ujian, batas ini penting: kejayaan satu sesi ialah bukti untuk tugasan dan keadaan yang diuji. Ia belum membuktikan seluruh produk sesuai untuk semua pengguna.
Sumber: Involving Users in Web Projects for Better, Easier Accessibility.
Sebagai latihan untuk pasukan Malaysia, kami mencadangkan satu senario rekaan: pemohon mencari jawatan, membaca syarat, memuat naik resume dan menghantar permohonan. Pilih aliran ini sebagai skop kecil yang boleh diperiksa dari awal hingga akhir.
Cuba jalankan aliran tersebut menggunakan papan kekunci sahaja. Catat tempat fokus sukar dikenal pasti, kawalan yang tidak dapat dicapai atau langkah yang memerlukan bantuan orang lain. Kemudian, semak bagaimana label borang dan mesej ralat disampaikan menggunakan pembaca skrin.
Jika portal menyediakan Bahasa Malaysia dan bahasa Inggeris, uji kedua-dua versi secara berasingan. Untuk contoh ini, beri perhatian kepada arahan format resume, medan wajib dan pengesahan penghantaran. Elakkan menganggap terjemahan lengkap bermaksud pengalaman penggunaan juga setara.
Cadangan ini ialah latihan editorial, bukannya hasil audit IT Jobs Malaysia atau senarai lengkap keperluan WCAG. Gunakan akaun ujian dan dokumen rekaan supaya latihan tidak melibatkan maklumat pemohon sebenar.
Untuk setiap masalah, rekodkan tugasan, langkah mengulanginya, keadaan ujian, kesan kepada pengguna dan hasil yang dijangka. Contohnya, laporan bahawa butang penghantaran tidak dapat dicapai selepas memilih fail lebih mudah disiasat berbanding catatan umum bahawa borang kurang mesra pengguna.
Tetapkan pemilik pembaikan dan uji semula aliran yang sama selepas perubahan. Dalam laporan dalaman, asingkan masalah yang ditemui, pembaikan yang telah disahkan dan bahagian yang belum diuji. Cara ini menjadikan batas bukti jelas kepada pembangun serta pengurus produk.
Pelajar IT boleh menggunakan pendekatan yang sama dalam portfolio: tunjukkan masalah, sebab perubahan reka bentuk dan bukti ujian semula. Pilih satu borang kecil dahulu, kemudian dokumentasikan hasilnya dengan teliti tanpa mendakwa seluruh aplikasi telah mencapai pemenuhan standard.
Disediakan secara automatik dengan bantuan AI berdasarkan sumber yang dipautkan. Semakan sumber: 2026-10-01. Gambar utama ialah ilustrasi janaan AI, bukan foto peristiwa sebenar.