Website yang Aksesibel adalah Keputusan Layanan, Bukan Sekadar Kotak Kepatuhan

Website yang aksesibel adalah keputusan layanan, bukan sekadar kotak kepatuhan

Seseorang dapat menemukan produk Anda lewat pencarian, iklan, tautan pesan, atau rekomendasi teman, lalu gagal sebelum sempat memahami penawarannya. Tombol tidak bisa dipilih dengan keyboard. Formulir tidak memberi tahu kesalahan. Teks hilang ketika ukuran huruf dibesarkan. Video menyampaikan informasi penting tanpa teks. Dalam semua kasus itu, masalahnya bukan hiasan antarmuka. Layanan berhenti bekerja bagi sebagian orang.

Aksesibilitas web adalah cara memastikan informasi, tindakan, dan bantuan di situs dapat dipakai oleh orang dengan kemampuan, perangkat, pengaturan, serta situasi yang berbeda. Ia menyangkut pengguna tunanetra yang memakai pembaca layar, pengguna dengan keterbatasan motorik yang mengandalkan keyboard atau sakelar, orang dengan gangguan pendengaran, pengguna dengan gangguan kognitif, dan orang yang sedang berada dalam kondisi sementara seperti cedera tangan, layar retak, cahaya menyilaukan, atau koneksi yang tidak stabil. Banyak perbaikan yang baik untuk kelompok-kelompok itu sekaligus membuat pengalaman lebih jelas untuk semua orang.

Perjalanan pelanggan tidak dimulai ketika halaman produk terbuka. Ia dimulai pada saat seseorang memutuskan apakah tautan itu dapat dipercaya, dapat dibuka, dan bisa dipahami. Judul hasil pencarian, nama tautan, kejelasan tujuan, kecepatan halaman, hingga cara situs mempertahankan konteks ketika berpindah halaman ikut menentukan apakah orang dapat melanjutkan. Jika halaman pertama membuat pengguna bingung atau terhalang, keunggulan produk di halaman berikutnya tidak banyak berarti.

Bayangkan calon pelanggan yang membuka laman pendaftaran dari telepon. Ia memperbesar teks karena membaca di luar ruangan. Menu menutupi tombol utama. Setelah memilih paket, dialog pembayaran muncul tanpa judul yang dibacakan pembaca layar dan fokusnya tetap berada di belakang dialog. Pengguna tidak yakin tindakan apa yang sedang diminta, lalu menutup halaman. Sistem analitik mungkin hanya mencatat kunjungan singkat. Bagi orang itu, layanan tidak pernah benar-benar tersedia.

Nilai rangkaian tugas, bukan halaman yang tampak rapi saat dipresentasikan. Untuk toko, uji pencarian produk sampai pembayaran. Untuk layanan publik atau pendidikan, uji pencarian persyaratan sampai pelacakan permohonan. Jangan menilai jalur ideal saja. Cari titik ketika alamat salah, kata sandi lupa, stok habis, atau pengguna perlu mengubah pilihan.

Pertanyaan operasional yang berguna antara lain:

• Apakah tujuan setiap tautan dan tombol dapat dipahami dari namanya, termasuk ketika dibaca di luar konteks visualnya?
• Apakah pengguna mendapat pemberitahuan yang jelas setelah data dikirim, pembayaran diproses, atau terjadi kesalahan?
• Apakah informasi penting hanya dibedakan dengan warna, posisi, bentuk yang samar, atau gerakan?
• Apakah halaman tetap dapat digunakan saat teks diperbesar, orientasi layar berubah, atau pengguna memakai perangkat masukan lain?
• Apakah kanal bantuan dapat ditemukan dan digunakan tanpa harus melewati hambatan yang sama?

Pertanyaan tersebut menggeser pembicaraan dari “apakah situs kita sudah cantik” menjadi “apakah orang dapat menyelesaikan urusannya”. Itu adalah ukuran layanan yang lebih jujur.

WCAG, singkatan dari Web Content Accessibility Guidelines, adalah pedoman W3C yang mengelompokkan kebutuhan aksesibilitas ke dalam empat prinsip: dapat dipersepsi, dapat dioperasikan, dapat dipahami, dan tangguh. Keempatnya sering diringkas sebagai POUR. Ringkasan ini membantu, tetapi jangan menganggapnya sebagai daftar cek singkat yang menggantikan pengujian manusia.

Dapat dipersepsi berarti informasi tidak boleh tersedia hanya melalui satu indera atau satu bentuk penyajian. Gambar informatif memerlukan alternatif teks yang sesuai. Rekaman suara memerlukan transkrip atau bentuk setara sesuai konteks. Video yang memuat dialog perlu teks. Kontras warna harus memadai agar teks dan elemen penting tetap terbaca. Struktur judul, daftar, tabel, dan label perlu disampaikan secara terprogram sehingga pembaca layar dapat mengenalinya.

Dapat dioperasikan berarti orang dapat mencapai dan menggunakan kontrol. Keyboard tidak boleh terjebak di bagian halaman tertentu. Fokus harus tampak dan bergerak dengan urutan yang masuk akal. Waktu yang dibatasi perlu dapat diperpanjang atau dikendalikan bila konteksnya memungkinkan. Interaksi yang mengandalkan gerakan rumit, seret-lepas, atau gestur harus memiliki cara lain yang setara.

Dapat dipahami berkaitan dengan bahasa, perilaku, dan pemulihan dari kesalahan. Tombol seharusnya menyatakan akibat tindakannya. Formulir perlu memberi label dan petunjuk yang cukup. Pesan kesalahan perlu menunjukkan masalahnya dan, bila mungkin, cara memperbaikinya. Navigasi yang berubah-ubah tanpa alasan dan istilah yang kabur membuat biaya mental bertambah, bahkan pada orang yang tidak memakai teknologi bantu.

Tangguh berarti konten tetap dapat ditafsirkan oleh beragam peramban dan teknologi bantu, sekarang maupun ketika sistem berkembang. Kode semantik yang benar, nama kontrol yang tersedia bagi teknologi bantu, serta pola komponen yang konsisten memberi fondasi yang lebih tahan lama dibanding perbaikan visual sesaat.

“Kekuatan Web terletak pada sifatnya yang universal. Akses oleh semua orang tanpa memandang disabilitas adalah aspek yang sangat penting.”

Tim Berners-Lee, sumber W3C

Pernyataan itu tidak meminta tim menebak semua kebutuhan secara pribadi. Ia meminta Web tidak mengunci akses pada satu cara melihat, mendengar, bergerak, atau memahami. Pedoman memberi bahasa bersama untuk membicarakan mutu. Pengalaman pengguna menunjukkan apakah bahasa itu benar-benar diwujudkan.

Keyboard adalah pemeriksaan sederhana yang mengungkap banyak hal. Tekan tombol Tab dari awal halaman, lalu ikuti fokus sampai ke menu, pencarian, konten, formulir, dialog, dan kaki halaman. Jika Anda tidak dapat melihat posisi fokus, tidak tahu kontrol mana yang aktif, tidak dapat membuka atau menutup menu, atau terjebak dalam suatu bagian, pengguna keyboard menghadapi hambatan yang sama atau lebih berat.

Pengguna keyboard bukan kelompok kecil yang seragam. Ada orang yang tidak dapat memakai tetikus, memakai teknologi bantu yang menerjemahkan perintah ke keyboard, atau memilih keyboard karena lebih cepat. Pembaca layar juga bergantung pada struktur dan fokus untuk menavigasi. Karena itu, dukungan keyboard bukan tambahan khusus. Ia adalah bukti bahwa komponen dasar memiliki perilaku yang dapat diprediksi.

Fokus perlu diperlakukan sebagai posisi kerja pengguna, bukan garis dekoratif yang boleh disembunyikan. Ketika pengguna membuka dialog, fokus harus masuk ke dialog agar konteksnya jelas. Ketika dialog ditutup, fokus idealnya kembali ke kontrol yang membukanya, kecuali tindakan pengguna telah membawa mereka ke konteks baru. Pada komponen seperti menu, tab, pilihan otomatis, dan daftar saran, urutan tombol serta perilaku tombol panah perlu mengikuti pola yang dikenal pengguna.

Kesalahan umum adalah memakai elemen noninteraktif sebagai tombol lalu menambahkan respons klik. Elemen itu mungkin tampak berfungsi bagi pengguna tetikus, tetapi tidak memiliki perilaku keyboard, nama, peran, atau status yang diharapkan. Pilihan yang lebih aman biasanya adalah memakai elemen HTML asli untuk tujuan aslinya. Tombol untuk tindakan. Tautan untuk berpindah tujuan. Label untuk menghubungkan keterangan dengan bidang isian. Semantik bawaan mengurangi pekerjaan tambahan dan memperkecil risiko perilaku yang berbeda-beda.

Uji cepat yang dapat dilakukan pada setiap rilis:

• Lepaskan tetikus dan selesaikan satu tugas inti hanya dengan Tab, Shift+Tab, Enter, Spasi, serta tombol panah bila relevan.
• Pastikan indikator fokus memiliki kontras dan tidak tertutup bilah lengket, dialog, atau animasi.
• Buka setiap dialog, panel samping, menu, dan pemberitahuan. Periksa apakah fokus berpindah dengan masuk akal.
• Pastikan tidak ada perangkap keyboard dan tersedia cara yang jelas untuk menutup komponen.
• Coba pintasan yang mungkin bertabrakan dengan fungsi peramban atau teknologi bantu.

Temuan dari uji ini perlu masuk ke daftar pekerjaan produk, bukan dicatat sebagai cacat kosmetik. Jika pintu depan digital hanya terbuka untuk pengguna tetikus, layanan belum memiliki pintu depan yang nyata.

Orang tidak membaca halaman sebagaimana desain melihatnya. Pembaca layar dapat melompat antartajuk, daftar tautan, wilayah halaman, dan kontrol formulir. Pengguna yang memperbesar halaman melihat sebagian kecil layar. Orang dengan konsentrasi terbatas mungkin memindai judul dan kalimat pertama setiap bagian. Struktur yang baik memberi mereka pegangan. Polesan visual tanpa struktur sering tampak meyakinkan dalam tangkapan layar, lalu runtuh ketika cara berinteraksi berubah.

Gunakan satu judul utama yang menjelaskan topik halaman, kemudian susun judul tingkat berikutnya sesuai hierarki isi. Jangan memilih tingkat judul hanya karena ukuran hurufnya cocok. Gaya visual dapat diatur dengan CSS, sedangkan tingkat judul menyampaikan hubungan antarbagian. Daftar yang benar membantu pembaca memahami bahwa sejumlah item memiliki hubungan. Tabel sebaiknya dipakai untuk data yang memang berbentuk matriks, lengkap dengan tajuk yang sesuai, bukan untuk mengatur tata letak.

Teks tautan perlu memberi tujuan. “Baca selengkapnya” yang berulang pada satu halaman membuat daftar tautan menjadi kabur. Lebih jelas menulis “Baca panduan pengembalian barang” atau “Unduh syarat layanan PDF”. Demikian juga tombol “Kirim” dapat memadai di formulir pendek dengan konteks sangat jelas, tetapi “Kirim permohonan” sering lebih membantu ketika halaman memuat beberapa tindakan.

Ketika struktur dan nama kontrol jelas, pengguna tidak perlu mengingat susunan layar untuk memahami apa yang dapat dilakukan. Mereka dapat menggunakan cara navigasi yang sesuai dengan kebutuhannya, termasuk pembaca layar, pembesaran, keyboard, atau layar kecil.

Alternatif teks bukan tugas mengisi atribut. Tujuannya adalah menyampaikan fungsi atau informasi yang hilang bila gambar tidak dapat dilihat. Gambar produk mungkin perlu menyebut produk dan ciri yang relevan untuk memilihnya. Ikon tombol perlu memiliki nama tindakan. Gambar hias yang tidak menambah informasi dapat dibiarkan diabaikan teknologi bantu. Grafik kompleks mungkin membutuhkan ringkasan dan penjelasan data yang lebih panjang di dekatnya. Hindari menulis “gambar dari” karena teknologi bantu sudah menyampaikan bahwa elemen tersebut gambar.

Bahasa juga bagian dari struktur. Pecah instruksi panjang menjadi langkah yang dapat ditindaklanjuti. Letakkan syarat penting sebelum pengguna berkomitmen, bukan di catatan yang tersembunyi. Hindari kode internal, singkatan, dan istilah hukum tanpa penjelasan bila pembaca umum harus mengambil keputusan. Keterbacaan tidak berarti menyederhanakan semua hal secara berlebihan. Artinya memberi informasi pada urutan dan bentuk yang membantu orang memakainya.

Layar kecil mengubah cara orang menavigasi, membaca, dan memperbaiki kesalahan. Jempol menutup sebagian layar. Papan ketik virtual mengurangi ruang yang tersisa. Koneksi bisa putus di tengah formulir. Pengguna dapat membuka halaman sambil membawa barang, menunggu kendaraan, atau berada di tempat bising. Menganggap seluler sebagai desktop yang dipersempit menghasilkan kontrol terlalu rapat, informasi penting yang terpotong, dan alur yang sulit dipulihkan.

Desain responsif yang aksesibel mempertahankan makna dan fungsi pada berbagai lebar layar. Urutan konten secara visual sebaiknya sejalan dengan urutan yang masuk akal bagi keyboard dan pembaca layar. Jangan menyembunyikan tindakan penting hanya karena ruang terbatas tanpa menyediakan jalan yang setara. Pastikan pengguna dapat memperbesar tanpa harus menggulir mendatar untuk membaca satu baris teks, kecuali pada konten yang memang membutuhkan dua dimensi seperti peta atau tabel data besar.

Target sentuh perlu cukup besar dan cukup berjarak untuk mengurangi salah tekan. Ini tidak hanya menguntungkan pengguna dengan tremor atau keterbatasan motorik; siapa pun pernah salah menyentuh ikon kecil dalam kendaraan yang bergerak. Kontrol yang hanya tampak saat kursor diarahkan juga tidak cocok untuk layar sentuh. Status seperti item terpilih, kesalahan, atau proses memuat harus disampaikan lebih dari perubahan warna tipis atau animasi singkat.

Formulir seluler memerlukan perhatian khusus. Gunakan jenis masukan yang membantu papan ketik virtual bila sesuai, tetapi jangan mengandalkan format otomatis yang membingungkan. Pertahankan data yang sudah diisi ketika validasi gagal. Letakkan pesan kesalahan dekat bidang terkait dan buat ringkasannya mudah ditemukan. Jangan memaksa pengguna mengingat data dari halaman sebelumnya ketika mereka kembali untuk memperbaiki satu kesalahan. Untuk proses panjang, jelaskan tahap yang sedang berlangsung dan cara menyimpan atau melanjutkan bila tersedia.

Periksa pengalaman di perangkat nyata, bukan hanya mode responsif di komputer. Mode itu bermanfaat, tetapi tidak sepenuhnya meniru pembesaran sistem, pembaca layar seluler, sentuhan, papan ketik virtual, rotasi, atau keterbatasan jaringan. Uji pula saat ukuran teks perangkat dinaikkan. Jika navigasi, kartu, atau tombol utama tiba-tiba saling menindih, itu adalah masalah layanan di perangkat yang banyak dipakai pelanggan.

Pemindai otomatis berguna untuk menemukan pola masalah yang dapat dikenali mesin, seperti atribut yang hilang, kontras tertentu, atau struktur dokumen yang tidak lazim. Namun pemindai tidak memahami apakah alternatif teks menggambarkan gambar secara tepat, apakah urutan fokus masuk akal, apakah instruksi membingungkan, atau apakah proses pembayaran dapat diselesaikan dengan percaya diri. Skor yang tinggi dapat berdampingan dengan pengalaman yang buruk.

Chrome Lighthouse menyajikan skor aksesibilitas dari audit berbobot. Skor itu dapat membantu memprioritaskan perbaikan teknis dan melihat regresi, tetapi Chrome menjelaskan bahwa audit otomatis tidak menangkap seluruh kebutuhan aksesibilitas. Perlakukan skor sebagai sinyal pemeriksaan, bukan sertifikat bahwa situs sudah aksesibel. Mengubah satu nilai demi angka tanpa memeriksa penggunaannya sering menghasilkan rasa aman palsu.

W3C juga membedakan evaluasi awal dengan evaluasi menyeluruh. Pengenalan masalah dapat dimulai dengan pemeriksaan sederhana, tetapi evaluasi yang andal membutuhkan beberapa halaman, komponen, alur, kombinasi peramban dan teknologi bantu, serta orang yang memahami metode evaluasi. Lingkup harus dicatat. Tanpa lingkup, pernyataan “situs telah diuji” tidak memberi tahu halaman mana, tugas apa, atau batasan apa yang sebenarnya diperiksa.

Buat rutinitas berlapis yang sesuai dengan perubahan produk:

• Jalankan pemeriksaan otomatis pada perubahan kode dan tetapkan tindak lanjut untuk temuan yang bermakna.
• Lakukan uji keyboard manual pada komponen baru dan alur bernilai tinggi sebelum rilis.
• Tinjau judul, tautan, alternatif teks, formulir, pesan kesalahan, serta perubahan dinamis dengan pembaca layar pada kombinasi yang dipilih tim.
• Uji alur nyata bersama pengguna penyandang disabilitas dan libatkan mereka sebagai ahli atas cara mereka memakai produk, bukan sekadar sebagai pemeriksa akhir.
• Catat temuan, dampaknya terhadap tugas, lingkungan pengujian, keputusan perbaikan, dan hasil verifikasi setelah perbaikan.

Keterlibatan pengguna tidak perlu menunggu proyek besar. Satu sesi yang dirancang baik dapat memperlihatkan hambatan yang tidak muncul di laporan teknis. Tim perlu membayar partisipan secara layak, meminta persetujuan yang jelas, dan tidak memaksa seseorang mewakili semua pengalaman disabilitas. Temuan pengguna melengkapi standar dan pengujian ahli, bukan menggantikannya.

Ada keterbatasan yang harus diakui. Tidak semua kombinasi perangkat dan teknologi bantu dapat diuji dalam satu siklus. Tidak semua kebutuhan pengguna sama. Produk lama mungkin memerlukan perbaikan bertahap. Pengakuan ini bukan alasan untuk diam. Ia alasan untuk menentukan risiko terbesar, memperbaiki jalur inti terlebih dahulu, dan mengomunikasikan batasan secara jujur.

Aksesibilitas gagal ketika hanya dimiliki oleh satu spesialis yang dipanggil menjelang peluncuran. Keputusan yang menciptakan hambatan muncul jauh lebih awal: saat riset menentukan persona, saat pengadaan memilih platform, saat desain menetapkan sistem komponen, saat penulis menyiapkan instruksi, saat pengembang memilih pola interaksi, dan saat layanan pelanggan membuat prosedur bantuan. Karena itu, tanggung jawab perlu dibagi, dengan pemilik yang jelas untuk setiap keputusan.

Tim produk dapat memasukkan kriteria aksesibilitas ke definisi selesai untuk cerita pengguna dan komponen. Desainer dapat mendokumentasikan status fokus, kontras, ukuran target, keadaan kesalahan, serta perilaku responsif, bukan hanya keadaan normal yang statis. Penulis dapat meninjau kejelasan label, judul, tautan, dan instruksi. Pengembang dapat mengutamakan HTML semantik, menguji interaksi keyboard, dan menjaga nama kontrol bagi teknologi bantu. Penjamin mutu dapat menjalankan skenario tugas dengan perangkat masukan yang berbeda.

Sistem desain adalah titik ungkit penting. Komponen tombol, dialog, menu, peringatan, isian, dan tab yang telah diuji dengan baik mengurangi kebutuhan setiap tim untuk menciptakan ulang perilaku dasar. Namun komponen yang diberi label “aksesibel” tetap dapat dipakai dengan cara yang salah. Dialog yang benar dapat berisi judul kabur. Bidang isian yang baik dapat dipasangkan dengan instruksi yang tidak cukup. Pemeriksaan perlu mencakup komponen dan konteks pemakaiannya.

Buat catatan keputusan yang praktis. Untuk setiap isu besar, simpan uraian masalah, pengguna atau tugas yang terdampak, tingkat prioritas, pemilik, rencana perbaikan, dan cara memverifikasinya. Bahasa seperti “aksesibilitas perlu ditingkatkan” terlalu umum untuk dikerjakan. Bahasa seperti “pesan kesalahan alamat tidak dibacakan setelah validasi, sehingga pengguna pembaca layar tidak mengetahui bidang yang perlu diperbaiki” memberi tim arah yang jelas.

Dukungan setelah rilis juga penting. Sediakan cara bagi pelanggan untuk melaporkan hambatan, dan pastikan laporan itu tidak berakhir sebagai tiket umum tanpa konteks. Tanggapi dengan informasi yang dapat digunakan: apa yang dipahami tim, alternatif sementara bila ada, serta kapan pengguna dapat memeriksa kembali. Jangan menjanjikan tanggal yang belum pasti. Hubungkan pola laporan ke perencanaan produk agar masalah berulang tidak hanya ditangani satu per satu.

WCAG menyediakan rujukan teknis yang luas dan digunakan secara internasional. Kriteria keberhasilannya memiliki tingkat A, AA, dan AAA. Tingkat tersebut membantu organisasi menetapkan target dan mengevaluasi ruang lingkup, tetapi tidak otomatis menjawab setiap pertanyaan desain atau setiap kewajiban hukum. Kesesuaian perlu ditentukan terhadap versi pedoman, tingkat, halaman atau proses yang dinilai, serta kondisi evaluasi yang jelas.

Aturan hukum berbeda menurut yurisdiksi, jenis organisasi, layanan, kontrak, dan sektor. Regulasi aksesibilitas layanan publik di Inggris, misalnya, memiliki konteks serta kewajiban tersendiri yang dijelaskan GOV.UK. Regulasi itu bukan hukum yang otomatis berlaku di Indonesia. Mengutipnya sebagai aturan lokal akan menyesatkan pengambil keputusan. Organisasi yang beroperasi di Indonesia perlu menilai kewajibannya berdasarkan hukum, regulasi sektoral, kontrak, dan nasihat profesional yang relevan di Indonesia.

Meski begitu, rujukan internasional tetap berguna. WCAG dapat menjadi dasar teknis yang konsisten untuk produk lintas negara, kebijakan pengadaan, dan pengujian vendor. Yang perlu dihindari adalah lompatan dari “kami mengikuti beberapa praktik WCAG” menjadi “kami pasti patuh terhadap semua kewajiban”. Pernyataan kedua membutuhkan bukti, lingkup, dan penilaian yang jauh lebih spesifik.

Bahaya kepastian palsu muncul dalam beberapa bentuk. Ada lencana yang menyiratkan situs sudah dapat dipakai semua orang tanpa penjelasan metode. Ada overlay yang menjanjikan perbaikan instan tanpa membenahi sumber masalah. Ada laporan audit satu halaman yang menutup diskusi tentang alur kritis. Ada skor otomatis yang diperlakukan sebagai pengganti evaluasi manusia. Semua itu dapat mengalihkan anggaran dari perbaikan yang nyata.

Komunikasi publik yang lebih bertanggung jawab menyebut apa yang telah dilakukan, bagian yang sedang diperbaiki, serta kanal untuk melaporkan hambatan. Di dalam organisasi, bedakan target teknis, kesiapan pengalaman pengguna, dan kesimpulan legal. Ketiganya berkaitan, tetapi bukan hal yang sama. Ketelitian ini melindungi pengguna dari klaim berlebihan dan membantu pimpinan melihat pekerjaan yang masih diperlukan.

Jangan mulai dengan mencari kalimat kebijakan yang paling mengesankan. Mulailah dengan satu alur yang menentukan apakah pelanggan dapat menerima layanan. Pilih perjalanan dengan dampak tinggi, lakukan pengujian keyboard dan teknologi bantu, temukan hambatan yang menghalangi penyelesaian tugas, lalu tetapkan pemilik serta tenggat yang realistis untuk memperbaikinya. Ulangi pada alur berikutnya sambil membangun kebiasaan dan komponen yang mencegah masalah kembali.

Keputusan yang perlu dibuat minggu ini cukup konkret:

• Tetapkan alur pelanggan prioritas dan definisikan apa arti “berhasil” bagi pengguna.
• Pilih lingkungan pengujian awal, termasuk peramban, perangkat, serta teknologi bantu yang relevan dengan audiens.
• Masukkan pemeriksaan aksesibilitas ke perubahan desain, konten, kode, dan jaminan mutu.
• Sisihkan waktu serta anggaran untuk pengujian bersama pengguna penyandang disabilitas.
• Buat jalur eskalasi untuk laporan hambatan dan ukur penyelesaiannya.
• Dokumentasikan batasan yang diketahui tanpa menyamarkannya sebagai kepatuhan penuh.

Aksesibilitas bukan proyek sekali selesai karena konten, perangkat, dan produk terus berubah. Namun itu bukan alasan untuk menunda keputusan. Saat tim memperlakukan akses sebagai syarat layanan, mereka berhenti bertanya apakah kepatuhan dapat ditempelkan di akhir. Mereka mulai memastikan bahwa orang benar-benar dapat menemukan, memahami, dan menggunakan apa yang telah dijanjikan situs.

Sumber:

• https://www.w3.org/WAI/standards-guidelines/wcag/
• https://www.w3.org/WAI/fundamentals/accessibility-intro/
• https://www.w3.org/WAI/test-evaluate/
• https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/
• https://developer.chrome.com/docs/lighthouse/accessibility/scoring
• https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps