Berita

Proyek Aktif

Terakhir diperbarui 31 Oktober 2026

Sedang Berjalan

v3: Suite QA lengkap

27 September 2026

Diperkenalkan di DrupalCon Europe 2026

Fitur baru utama

• Inti pengujian digabungkan dengan Sa11y. Set aturan baru yang dikembangkan bersama ini menambahkan pengujian untuk pengembang, pemeriksaan kontras, dan skor keterbacaan ke set aturan inti pengujian konten.
• Dukungan multibahasa
• Pembangun pemeriksaan kustom
• Alat pemeliharaan dasbor
• Alat perayapan situs untuk menambahkan hasil baru.
• Memungkinkan pengujian tertentu (apakah PDF ini dapat diakses?) untuk mengabaikan peringatan di seluruh situs bagi peran tertentu.
• Konfigurasi terpisah: pengujian dan tampilan laporan berbasis peran, masing-masing untuk pengembang dan untuk editor konten.

Dan yang mungkin paling penting bagi masa depan proyek ini:

• Memperoleh hibah untuk mendirikan organisasi sponsor ini guna mendukung pengguna yang ada dan mendanai pengerjaan ide-ide proyek di masa depan.

v2: Pengabaian & laporan

2 Maret 2023

Dua tahun lalu kami memperkenalkan pemeriksa aksesibilitas Editoria11y sebagai plugin situs siap pakai untuk Drupal, yang memberi penulis umpan balik otomatis dan instan, disertai tips bermanfaat untuk memperbaiki konten mereka.

Kami menduga alat ini akan mengisi kebutuhan yang belum terpenuhi. Semua pilihan yang ada menuntut pelatihan dan pemakaian yang tekun agar benar-benar berguna, dan pengalaman menunjukkan bahwa melatih dan memantau ribuan penulis konten di organisasi besar bukanlah cara yang efisien untuk mengatasi masalah ini. Agar program semacam ini berhasil, kami yakin tingkat otomatisasinya harus tinggi: alat harus memberikan “pelatihan tepat pada saat dibutuhkan” dengan sopan kepada penulis konten ketika mendeteksi kesalahan umum.

Dan ternyata berhasil.

Di Princeton, hal ini nyaris membalikkan arah komunikasi saya. Di platform yang memasangnya, kami beralih dari mengirim email berulang kepada penulis konten untuk meminta teks alt, perbaikan tautan, atau perbaikan heading, menjadi menerima pertanyaan dari penulis konten tentang cara memperbaiki tulisan mereka agar tidak terlalu sering ditandai.

Di luar Princeton, reaksinya adalah kegembiraan luar biasa:

Menulis tips yang mandiri

Untuk tips v1, kami memakai pendekatan “ringkasan dan detail”: penjelasan singkat tentang isu, ditambah tautan untuk detail selengkapnya.

Ini lebih baik daripada alat yang ditulis untuk pengembang: tipsnya pendek dan jelas. Namun, keputusan tentang ke mana harus menautkan selalu menjadi masalah. Beberapa pengguna dari pemerintahan dan pendidikan tinggi merasa perlu mengubah tips tersebut untuk menghapus tautan ke dokumentasi Princeton, sehingga pekerjaan mereka bertambah. Jadi, kami menulis ulang tips bawaan agar mandiri, lengkap dengan contoh langsung di dalamnya.

Perbedaan antara peringatan merah (isu yang pasti) dan peringatan kuning (kemungkinan isu) ternyata membingungkan, dan terkadang menjengkelkan.

Jadi, kami mengubah peringatan kuning menjadi “pemeriksaan manual” untuk memperjelas maknanya, dan menambahkan tombol agar penulis dapat mengabaikan peringatan. Peringatan yang “diabaikan” hanya disembunyikan bagi orang yang mengekliknya; peringatan yang “ditandai OK” disembunyikan bagi semua editor situs. Administrator situs dapat menentukan siapa yang berhak melakukan masing-masing tindakan.

Membuat dasbor

Keluhan umum para pemilik situs: alat ini sangat piawai menemukan isu di seluruh situs, tetapi tidak ada cara untuk melihat laporan seluruh situs.

Penulisan ulang ini menambahkan opsi untuk menyinkronkan temuan kembali ke basis data situs. Pemilik situs kini dapat menelusuri temuan per halaman atau per isu, meninjau isu mana yang telah diabaikan atau ditandai OK – dan memulihkannya jika mereka tidak setuju!

Tur kode V2 untuk pengembang

V2 nyaris merupakan penulisan ulang total. Beberapa fitur barunya antara lain:

• Menghapus ketergantungan pada jQuery membuatnya dapat dipasang di lebih banyak platform dan meningkatkan performa hingga 2x lipat.
• Pemeriksa kini dapat dikonfigurasi untuk memeriksa beberapa bagian halaman yang terpisah (misalnya isi artikel dan footer halaman).
• Pemeriksa kini dapat menguji elemen di dalam shadow DOM, yang digunakan oleh berbagai Web Components dan perpustakaan JavaScript.
• Banyak parameter baru mempermudah integrasi platform, misalnya mengabaikan secara otomatis semua isu pada halaman tertentu bagi pengguna tertentu, jika mereka tidak bertanggung jawab atas konten halaman itu tetapi mungkin tetap ingin melihat hasilnya sewaktu-waktu.
• Pemeriksa kini dilengkapi beberapa tema dasar dan parameter untuk menyesuaikan warna.
• Pengujian otomatis membantu mencegah regresi kode.

A11yTalks 2024

11 Juni 2024

Drupal GovCon 2023

27 Oktober 2023

DrupalCamp NJ 2023

28 Maret 2023

v1: Bantuan inline

11 Maret 2021

Membuat konten Web yang benar-benar mudah diakses itu rumit, dan biasanya dimulai dengan banyak pelatihan.

Kebiasaan yang sudah akrab harus dicegah:

• Tabel tidak boleh digunakan untuk membuat kolom palsu
• Teks paragraf tidak boleh dibuat rata tengah atau rata kanan-kiri
• Pemformatan yang hanya bersifat visual (ketebalan dan ukuran font) tidak boleh menjadi satu-satunya cara menyampaikan makna kepada pengguna, yang mungkin mendengarkan konten atau melihatnya dalam “mode baca”

Kebiasaan baru harus didorong:

• Gambar memerlukan teks alternatif yang bermakna sesuai konteks
• Halaman memerlukan struktur yang sesungguhnya
• Tautan harus memiliki judul yang bermakna

Tentu sebagian pelatihan kami diadakan karena kami memang mengajarkan konsep baru, tetapi pada titik tertentu kita perlu bertanya: seberapa besar kebutuhan akan keterampilan baru itu muncul karena konsepnya baru, dan seberapa besar karena kita menerapkan tuntutan baru tanpa memperbarui alat kita? Sesuatu yang baru bukan berarti tidak bisa intuitif.

Pelajaran dari sejarah ejaan

Fase 1: Salahkan penulisnya

Sejak awal sejarah tertulis hingga awal 1980-an, kita menyalahkan penulisnya jika ada kata yang salah eja. Tanggung jawab belajar mengeja dengan baik ada di pundak penulis.

Bagaimana seseorang memperbaiki ejaannya? Ini akan terdengar akrab:

1. Mereka mengikuti pelatihan, bersama tutor atau di ruang kelas
2. Mereka diberi daftar, pedoman, dan kamus untuk dipelajari, sebuah tradisi yang bermula dari leksikon paku kuno yang diguratkan pada tanah liat.

Fase 2: Salahkan kamusnya

Namun, ada yang berubah pada 1980-an: sebut saja “fase ejaan 2.” Program pengolah kata terpopuler mulai menyertakan pemeriksa ejaan.

Lalu, bagaimana nasib permainan saling menyalahkan? Nyaris dalam semalam, kesalahan beralih ke alatnya:

• Tidak tahu cara mengeja suatu kata? Tebak saja dan berharap ada yang cocok. Kalau tidak ada, salahkan kamusnya.
• Memakai kata yang benar-benar ada, tetapi ditandai kamus karena tidak mengenalnya? Menggerutulah, lalu putuskan apakah akan mengabaikan garis bawahnya atau mengeklik kanan dan menambahkan kata itu ke kamus.

Apakah pemeriksa ejaan membereskan semua masalah ejaan kita? Tentu tidak. Namun, alat ini membantu. Dan sebagian besar beban serta tanggung jawab pun berpindah dari penulis ke mesin.

Namun, ceritanya belum berakhir…

Fase 3: Salahkan alat penulisannya

Beberapa tahun terakhir membawa satu langkah maju lagi: komputer mulai mengeja untuk kita:

• Algoritma prediktif berusaha menebak kata berikutnya, frasa berikutnya, bahkan mungkin seluruh balasan pesan teks.
• Alat pemformatan otomatis berusaha mengubah tanda bintang, angka, dan huruf menjadi daftar, mengubah kode pendek menjadi karakter khusus dan emoji, dan sebagainya.
• Alat dikte berusaha mengenali konsep untuk memilih di antara homonim.

Dan siapa yang disalahkan ketika semua ini berantakan? Alatnya!

Agregator media sosial sangat menyukai tangkapan layar memalukan bertema “Bukan itu maksud saya!”.

Editoria11y adalah langkah menuju fase 2

Dalam pelatihan kami, kami banyak membahas pengujian dan memperkenalkan beberapa alat pengujian yang cukup bagus. Tidak satu pun dapat menangkap segalanya: konsep seperti “menghindari penjelasan konsep melalui rujukan warna atau ruang” perlu diperiksa oleh manusia; alat biasanya hanya menangkap kurang dari separuh isu sebenarnya yang mungkin ada di sebuah situs. Namun, alat-alat ini sangat baik dalam menangkap banyak kesalahan umum pada konten editorial.

Namun, ada tiga masalah:

1. Sebagian besar adalah alat manual. Pembuat konten harus sudah diajari cara memakainya, harus ingat bahwa alat itu ada saat menulis konten, dan harus ingat menjalankannya setelah selesai. Ketiga titik kegagalan itu bersekongkol membuat banyak (sebagian besar?) konten tidak pernah diperiksa.
2. Alat-alat ini menandai terlalu banyak. Yang ditandai bukan hanya kesalahan yang baru saja dibuat penulis, tetapi juga masalah warna dari desainer, masalah teknis dari pengembang, elemen struktural untuk keperluan informasi, dan sebagainya. Ini menaikkan standar pelatihan: penulis tidak hanya perlu memahami alatnya, tetapi juga harus diajari untuk mengabaikan sederet positif palsu atau hal-hal yang memang nyata, tetapi bukan tanggung jawab mereka untuk diperbaiki hari ini, saat sedang menulis artikel yang satu ini.
3. Alat otomatis cenderung memakai paradigma “rayapi situs, kunjungi dasbor”. Sekali lagi: ini mengandaikan penulis sudah dilatih untuk mengunjungi dasbor, dan akan ingat melakukannya.

Maka Princeton mulai membuat sesuatu yang baru: pemeriksa otomatis yang terintegrasi dengan situs web dan hanya memeriksa kesalahan editorial yang umum.

Otomatis itu… sulit.

1. Pemeriksa otomatis harus halus: jika terlalu tegas, ia menyela dan membuat penulis frustrasi. Jika terlalu sopan, ia mudah menjadi kebisingan latar yang diabaikan.
2. Pemeriksa otomatis harus berperforma sangat tinggi: jika halaman tersendat atau ragu-ragu saat pemeriksa berjalan, penulis akan membenci kehadirannya dan menonaktifkannya.
3. Pemeriksa otomatis memerlukan tips yang ramah bagi pemula. Bagi banyak penulis, inilah pertama kalinya mereka mendengar tentang penandaan, struktur, dan bahasa yang akan membuat konten mereka lebih mudah diakses. Peringatan harus memakai bahasa yang sederhana dan tidak teknis, disertai saran praktis untuk memperbaiki konten.

Jadi, kami memulai dari alat yang paling mendekati tujuan tersebut: Sa11y, dari Toronto Metropolitan University. Kami mengambil arsitektur pengujiannya serta pendekatan panel informasi dengan tooltip yang ramah pengguna, lalu menghabiskan setengah tahun mengadaptasi alat tersebut agar pengujian selalu berjalan otomatis, mengoptimalkan performanya, menyempurnakan tooltip, dan membuat daftar panjang opsi konfigurasi yang dapat dipakai pengembang untuk menyesuaikannya dengan cepat ke platform apa pun.

Beginilah tampilannya saat ini:

Saat penulis masuk ke situsnya, tombol alih Editoria11y menunjukkan jumlah dan jenis isu (lolos, perlu pemeriksaan manual, kemungkinan ada isu) di setiap halaman. Mereka dapat mengekliknya untuk memunculkan sorotan dan tips langsung di dalam konten. Jika kesalahan itu baru, karena mereka sedang melihat halaman yang baru saja diedit, panel akan terbuka secara otomatis.

Per Maret 2021, ini berarti lebih dari 400 situs web Princeton secara otomatis memeriksa:

• Kerangka dokumen yang baik
  • Level heading yang terlewati
  • Heading kosong
  • Heading sangat panjang
  • Blockquote yang mencurigakan pendeknya dan mungkin sebenarnya adalah heading.
• Alternatif teks
  • Gambar tanpa teks alt
  • Gambar dengan nama file sebagai teks alt
  • Gambar dengan teks alt yang sangat panjang
  • Teks alt yang mengandung kata redundan seperti “gambar dari” atau “foto dari”
  • Gambar di dalam tautan dengan teks alt yang tampaknya menjelaskan gambar, bukan tujuan tautan
  • Visualisasi tersemat yang biasanya memerlukan alternatif teks
• Tautan yang bermakna
  • Tautan tanpa teks
  • Tautan yang berjudul nama file
  • Tautan yang hanya berjudul teks umum: “klik di sini”, “pelajari lebih lanjut”, “unduh”, dan sebagainya
  • Tautan yang terbuka di jendela baru tanpa ikon tautan eksternal
• Jaminan kualitas umum
  • Memastikan pemformatan daftar digunakan, bukan tanda bintang, angka, dan huruf
  • TEKS CAPS LOCK DALAM JUMLAH BESAR
  • Tabel tanpa header dan tabel dengan heading dokumen (“Heading 3”), bukan header tabel (<th>)
  • Tautan ke PDF dan dokumen lain, yang mengingatkan pengguna untuk menguji aksesibilitas unduhan atau menyediakan format alternatif yang dapat diakses
  • Video tersemat, yang mengingatkan pengguna untuk menambahkan teks tertutup
  • Audio tersemat, yang mengingatkan pengguna untuk menyediakan transkrip
  • Media sosial tersemat, yang mengingatkan pengguna untuk menyediakan elemen alt

Kami telah merilis perpustakaan JavaScript kepada komunitas, membuat integrasi Drupal siap pakai, dan mulai mengerjakan integrasi WordPress siap pakai.

Menuju Fase 3: Dapat Diakses secara Bawaan

Dalam banyak hal, Editoria11y adalah solusi sementara. Sebagian besar kesalahan yang ditangkapnya terjadi karena kita menaruh tuntutan baru pada penulis konten (“tandai konten Anda dengan struktur yang baik”), tetapi memberi mereka alat yang justru mendorong sebaliknya.

Jalan ke depan adalah membuat pembuatan konten yang dapat diakses menjadi lebih mudah, dan seotomatis mungkin. Seperti apa wujudnya belum jelas, tetapi mungkin mencakup hal-hal seperti:

• Memikirkan ulang opsi apa saja yang tersedia. Misalnya: jika kita terus meminta pengguna agar tidak membuat teks rata kanan-kiri di Web, bukankah sudah saatnya memensiunkan tombol “rata kanan-kiri” itu?
• Memikirkan ulang opsi bawaan. Misalnya: tabel bawaan di sebagian besar sistem manajemen konten tidak memiliki header. Pengguna dituntut untuk tahu bahwa mereka harus mengeklik “properti” dan menambahkan fitur aksesibilitas; mungkin sudah saatnya hal itu dibalik?
• Menimbang pemformatan prediktif dan “petunjuk saat bekerja.” Jika pengguna menebalkan seluruh baris, bisakah kita menyarankan agar baris itu dijadikan heading? Jika pengguna hendak memilih heading, bisakah kita menebak level heading yang mungkin diinginkannya, alih-alih memberikan enam pilihan? Bisakah kita memberikan pelatihan tepat pada saat dibutuhkan untuk konsep yang sulit?