Enam Kriteria WCAG 2.2 yang Merusak Proses Pembayaran, dan Urutan Perbaikannya

Enam Kriteria WCAG 2.2 yang Merusak Proses Pembayaran, dan Urutan Perbaikannya

Pada tanggal 2 September 2026, ETSI menerbitkan EN 301 549 V4.1.1WCAG 2.2 adalah versi standar aksesibilitas TIK Eropa yang menggeser acuan dasar dari WCAG 2.1 ke WCAG 2.2. WCAG 2.2 menambahkan sembilan kriteria keberhasilan, enam di antaranya pada Level A atau AA, dan keenamnya berada di dalam alur pembayaran atau pemesanan, bukan di halaman pemasaran. Turki lebih dulu menerapkan standar ini dalam satu hal: Surat Edaran Presiden 2025/10, yang diterbitkan pada 21 Juni 2025, telah menyebutkan WCAG 2.2 dan memberi penyedia e-commerce berdasarkan Undang-Undang No. 6563 waktu dua tahun untuk mematuhinya.

Panduan ini ditujukan bagi siapa pun yang memiliki alur pembayaran atau pemesanan untuk konsumen di Uni Eropa, Turki, atau keduanya. Pada akhirnya, Anda akan dapat menjalankan enam tahap pengecekan pada alur Anda sendiri dalam waktu sekitar satu jam, menilai apa yang Anda temukan, dan memperbaikinya dengan urutan yang mengutamakan perlindungan pendapatan.

Apa yang berubah pada tanggal 2 September 2026?

V4.1.1 diadopsi pada 24 Agustus 2026 dan diterbitkan pada 2 September. Versi ini disiapkan berdasarkan Keputusan Pelaksanaan Komisi C(2022) 6456 final, permintaan standardisasi M/587, untuk mendukung Direktif (EU) 2019/882 (Undang-Undang Aksesibilitas Eropa) dan Direktif (EU) 2016/2102. Klausul 9, 10, dan 11 diselaraskan kembali dengan WCAG 2.2. Pengumuman dijadwalkan pada 30 November 2026, pengesahan pada 31 Mei 2027, dan penarikan standar nasional yang bertentangan pada 31 Mei 2028.

Koreksinya: Anda tidak memiliki anggapan kesesuaian.

Situs vendor berulang kali menyatakan bahwa memenuhi EN 301 549 membuat Anda dianggap patuh terhadap Undang-Undang Aksesibilitas. Pasal 15(1) hanya memberikan anggapan tersebut kepada standar "yang referensinya telah dipublikasikan dalam Jurnal Resmi Uni Eropa" sebagai pendukung arahan tersebut. EN 301 549 dikutip dalam Jurnal Resmi di bawah Arahan Aksesibilitas Web, melalui Keputusan Pelaksanaan Komisi (EU) 2018/2048. Kami tidak menemukan kutipan yang mendukung Arahan (EU) 2019/882, dan Lampiran ZB V4.1.1 sendiri ditulis dalam bentuk bersyarat: anggapan berlaku "setelah dokumen ini dikutip dalam Jurnal Resmi."

Jadi standar tersebut adalah bukti Anda, bukan tameng Anda. Anda mematuhi persyaratan fungsional dalam Lampiran I, menggunakan EN 301 549 sebagai sarana teknis, dan mendokumentasikan alasan tersebut sendiri berdasarkan Pasal 13(2).

Apakah ini berlaku untuk Anda?

  1. Apakah layanan Anda termasuk dalam Pasal 2(2)? Daftar tersebut mencakup layanan e-commerce, elemen-elemen transportasi penumpang udara, bus, kereta api, dan perairan seperti situs web, aplikasi, tiket elektronik dan informasi perjalanan, perbankan konsumen, dan buku elektronik. Pasal 3 mendefinisikan layanan e-commerce sebagai layanan yang diberikan dari jarak jauh, melalui sarana elektronik, atas permintaan individu konsumen, dengan tujuan untuk menyimpulkan kontrak konsumen.
  2. Apakah Anda berjualan kepada konsumen di Uni Eropa? Pendirian usaha di luar Uni Eropa tidak lantas membuat Anda keluar dari Uni Eropa. Pasal 3 mendefinisikan penyedia jasa sebagai orang "yang menyediakan jasa di pasar Uni Eropa atau menawarkan jasa tersebut kepada konsumen di Uni Eropa." Peritel Turki yang mengirimkan barang ke Jerman dan maskapai penerbangan Turki yang menjual tiket kepada konsumen Uni Eropa sama-sama termasuk di dalam Uni Eropa.
  3. Apakah Anda sebuah usaha mikro? Pasal 4(5) mengecualikan penyedia jasa usaha mikro: kurang dari 10 karyawan dan omset atau total neraca tidak lebih dari EUR 2 juta.

Kewajiban berlaku untuk layanan yang diberikan kepada konsumen setelah 28 Juni 2025. Pasal 32 memberikan masa transisi hanya untuk kontrak yang disepakati sebelum tanggal tersebut dan produk yang sudah digunakan secara sah, hingga 28 Juni 2030, dan hingga 20 tahun masa manfaat ekonomi untuk terminal swalayan. Di Turki, Surat Edaran 2025/10 menetapkan satu tahun untuk bank, rumah sakit swasta, operator telekomunikasi besar, yang kini telah disahkan, dan dua tahun untuk e-commerce berdasarkan Undang-Undang No. 6563. Kedua rezim tersebut mengacu pada pedoman yang sama pada tingkat yang berbeda, sehingga jika dibangun berdasarkan WCAG 2.2 AA, kewajiban Level A Turki akan hilang. Sebaliknya, hal itu tidak berlaku.

Enam kriteria yang menggagalkan proses pembayaran

Ini adalah tambahan WCAG 2.2 pada Level A dan AA. Tiga tambahan AAA, 2.4.12, 2.4.13, dan 3.3.9, berada di luar program AA. Satu penghapusan juga penting: 4.1.1 Parsing sudah usang dan dihapus, sehingga temuan lama terhadapnya dapat ditutup daripada diperbaiki.

KriteriumTingkatApa yang rusak saat pembayaranTes dalam 60 detik
3.3.8 Otentikasi yang Dapat Diakses (Minimum)AALangkah-langkah login yang memblokir fungsi salin-tempel dari clipboard, atau mengharuskan pengguna untuk menyalin OTP atau memecahkan teka-teki tanpa alternatif lain.Salin kata sandi dan OTP dari clipboard. Penyalinan yang diblokir dianggap gagal.
2.5.8 Ukuran Target (Minimum)AAPengukur kuantitas, ikon hapus item, tombol tutup kupon, kartu radio slot pengiriman kecil.Pada ukuran 375px, ukur target terkecil. Ukuran di bawah 24 x 24 piksel CSS tanpa jarak yang cukup akan gagal.
2.4.11 Fokus Tidak Terhalang (Minimum)AABar ringkasan pesanan yang tetap terlihat, banner persetujuan, dan peluncur obrolan yang mencakup bidang yang difokuskan.Telusuri formulir menggunakan tombol Tab. Kontrol yang terfokus dan sepenuhnya tersembunyi adalah sebuah kegagalan.
2.5.7 Gerakan MenyeretAAPenanda lokasi di peta, carousel geser, pemilih tanggal geser, tombol geser untuk konfirmasiSelesaikan setiap seret hanya dengan satu ketukan. Tidak adanya jalur yang tersedia berarti gagal.
3.3.7 Entri BerlebihanAMengetik ulang alamat penagihan setelah pengiriman, atau alamat email saat pembayaran.Isi alur sekali dan hitung nilai yang Anda ketik dua kali yang sudah dimiliki sistem.
3.2.6 Bantuan yang KonsistenATautan bantuan, obrolan, atau kontak ditempatkan secara berbeda pada keranjang belanja, pengiriman, dan pembayaran.Ambil tangkapan layar setiap langkah. Bantuan harus berada dalam urutan relatif yang sama di mana pun ia muncul.

Buku pedoman

Inilah jalur yang kami lalui. Jalur ini manual, karena lima dari enam titik tidak terdeteksi secara andal oleh pemindai otomatis.

1. Bekukan satu rute. Pembayaran sebagai tamu, satu barang, pengiriman standar, pembayaran kartu, lintas keranjang belanja, alamat pengiriman, metode pengiriman, pembayaran, dan konfirmasi. Jalankan dua kali: tampilan seluler 375px dengan sentuhan, lalu desktop dengan mouse dilepas.

2. Lulus ujian keyboard. Tekan tombol Tab dari bagian atas setiap langkah hingga ke tombol kirim. Perhatikan kegagalan 2.4.11 pada saat elemen lengket muncul, biasanya ketika bilah ringkasan menempel. Perhatikan letak bantuan pada setiap langkah untuk 3.2.6.

3. Umpan penunjuk. Di perangkat seluler, ukur target untuk versi 2.5.8 dan coba setiap seret tanpa menyeret untuk versi 2.5.7. Peta alamat dan carousel adalah penyebab kegagalan yang umum.

4. Kartu akses entri data. Selesaikan alur sebagai pelanggan pertama kali. Setiap kolom yang Anda isi dengan nilai yang sudah dimiliki sistem merupakan temuan 3.3.7. Kemudian coba otentikasi dengan pengelola kata sandi dan tempel dari clipboard untuk temuan 3.3.8.

5. Beri nilai sebelum Anda memperbaiki. Urutkan setiap temuan berdasarkan tingkat keparahan yang dikalikan dengan persentase keluaran alur kerja pada langkah tersebut dalam analitik Anda sendiri.

KerasnyaDefinisiSkor
PemblokiranPengguna sama sekali tidak dapat menyelesaikan pembelian.3
MerendahkanPenyelesaiannya memerlukan cara alternatif atau percobaan berulang.2
GesekanUpaya ekstra, risiko pengabaian kecil.1

6. Perbaiki dengan urutan ini. Otentikasi terlebih dahulu, karena pasal 3.3.8 dapat menghentikan pembelian secara langsung. Kemudian ukuran target, pengaburan fokus, menyeret alternatif, entri yang berlebihan, bantuan yang konsisten. Itulah urutan paparan pendapatan, bukan tingkat keparahan hukum, dan yang akan didanai sponsor tanpa perdebatan.

7. Tuliskan pernyataan tersebut. Pasal 13 ayat (2) mensyaratkan informasi berdasarkan Lampiran V yang menjelaskan bagaimana layanan tersebut memenuhi persyaratan, yang dipublikasikan dalam format tertulis dan lisan serta dengan cara yang mudah diakses. Jika Anda mengajukan beban yang tidak proporsional berdasarkan Pasal 14, dokumentasikan hal tersebut sesuai dengan kriteria Lampiran VI dan perbarui setidaknya setiap lima tahun. Keputusan yang tidak didokumentasikan untuk tidak memperbaiki sesuatu bukanlah klaim beban, melainkan cacat yang tidak diperbaiki.

8. Masukkan keenam pemeriksaan tersebut ke dalam QA rilis. Proses checkout mengalami kemunduran pada versi 2.4.11 saat pertama kali seseorang mengirimkan banner promosi.

Di sinilah letak kesalahannya

  • Enam kali pengecekan bukanlah suatu kesesuaian. Ini adalah peningkatan tambahan di atas WCAG 2.1 AA, dan jika Anda belum pernah mencapai 2.1 AA, peningkatan ini akan menyembunyikan masalah sebenarnya.
  • Ini bukan audit pembaca layar. Pemeriksaan keyboard menemukan masalah fokus dan urutan, bukan masalah pada kolom pembayaran yang salah label.
  • Iframe pembayaran Anda mungkin bukan milik Anda. Jika formulir kartu tersebut milik PSP Anda, mintalah pernyataan tertulis mereka mengenai klausul 9 EN 301 549.
  • Aplikasi native dipetakan secara berbeda. Klausul 11 ​​mencakup perangkat lunak, di mana ukuran target dan perilaku menyeret berbeda di bawah API aksesibilitas platform.
  • Overlay tidak memperbaiki masalah-masalah ini. Masing-masing dari keenamnya merupakan properti dari struktur alur atau desain otentikasi Anda, yang tidak dapat diubah oleh skrip yang disuntikkan.
  • Penegakan hukumnya bersifat nasional. Pasal 30 mensyaratkan agar sanksi bersifat efektif, proporsional, dan mencegah, tetapi tingkat dan praktik pengawasan ditetapkan per Negara Anggota.

FAQ (Pertanyaan Umum)

Apakah EN 301 549 V4.1.1 mengikat saya hari ini?

Tidak dengan sendirinya. Undang-undang tersebut mengikat Anda; standar tersebut menjelaskan jalur teknis menuju undang-undang tersebut. Adopsi nasional berlaku hingga 31 Mei 2027 dan penarikan standar yang bertentangan hingga 31 Mei 2028. Isinya merupakan interpretasi terbaik yang tersedia dari persyaratan Lampiran I, jadi bangunlah berdasarkan standar ini sekarang.

Jika kita memenuhi standar EN 301 549, apakah kita sudah memenuhi standar EAA?

Anda memiliki posisi pembuktian yang kuat tetapi Anda tidak memiliki asumsi hukum tentang kesesuaian. Pasal 15(1) mensyaratkan referensi tersebut dipublikasikan dalam Jurnal Resmi sebagai pendukung Arahan (EU) 2019/882, dan kami tidak menemukan kutipan tersebut. Dokumentasikan alasan Anda sendiri berdasarkan Pasal 13(2).

Kami adalah perusahaan Turki tanpa kantor cabang di Uni Eropa. Apakah kami termasuk dalam cakupan peraturan ini?

Jika Anda menawarkan layanan Anda kepada konsumen di Uni Eropa, ya. Pasal 3 mengaitkan kewajiban untuk menawarkan layanan kepada konsumen di Uni Eropa, bukan di tempat Anda terdaftar. Surat Edaran 2025/10 mungkin berlaku secara terpisah untuk pasar Turki.

Apakah tanggal 2030 berarti kita punya waktu hingga tahun 2030?

Tidak. Transisi Pasal 32 mencakup kontrak yang disepakati sebelum 28 Juni 2025 dan produk yang sudah digunakan secara sah. Layanan baru yang diberikan kepada konsumen setelah tanggal tersebut termasuk dalam cakupan sejak tanggal tersebut.

Apakah kita masih perlu memperbaiki temuan parsing versi 4.1.1 yang lama?

Nomor 4.1.1 sudah usang dan dihapus dalam WCAG 2.2. Tutup temuan tersebut, tetapi periksa apakah markup yang mendasarinya juga menyebabkan kegagalan nama, peran, atau nilai di bawah 4.1.2, yang masih berlaku.

Bagaimana jika perbaikannya ternyata terlalu mahal?

Pasal 14 memperbolehkan argumen beban yang tidak proporsional, tetapi hanya sebagai penilaian terdokumentasi berdasarkan kriteria Lampiran VI, yang diperbarui setidaknya setiap lima tahun. Otoritas pengawasan pasar akan meminta untuk melihatnya.

Lakukan operan

Lakukan enam pengecekan ini pada kasir Anda minggu ini, atau kirimkan URL-nya kepada kami dan kami akan menjalankan audit serta memberikan kembali hasil temuannya. Pemindai kami di wcag.switas.com mencakup bagian otomatis terhadap WCAG 2.0, 2.1 dan 2.2, dan memberi Anda dasar yang menjadi acuan proses manual.

sumber


Artikel terkait

Switas Seperti yang Terlihat di

Magnify: Meningkatkan Pemasaran Influencer dengan Engin Yurtdakul

Simak Studi Kasus Microsoft Clarity Kami

Kami menyoroti Microsoft Clarity sebagai produk yang dibangun dengan mempertimbangkan kasus penggunaan praktis di dunia nyata oleh orang-orang yang benar-benar ahli di bidang produk dan memahami tantangan yang dihadapi perusahaan seperti Switas. Fitur-fitur seperti klik yang menimbulkan kekecewaan dan pelacakan kesalahan JavaScript terbukti sangat berharga dalam mengidentifikasi frustrasi pengguna dan masalah teknis, memungkinkan peningkatan yang tepat sasaran yang secara langsung berdampak pada pengalaman pengguna dan tingkat konversi.