Aksesibilitas untuk developer web

Meningkatkan aksesibilitas akan membuat situs Anda lebih mudah digunakan oleh semua orang.

Addy Osmani

Tips: Ikuti Pelajari Aksesibilitas, kursus aksesibilitas yang selalu aktual dan referensi untuk meningkatkan pengembangan web Anda.

Penting untuk membuat situs yang inklusif dan dapat diakses oleh semua orang. Setidaknya ada enam area utama disabilitas yang dapat Anda optimalkan: visual, pendengaran, mobilitas, kognisi, bicara, dan neural. Banyak alat dan sumber daya yang dapat membantu di sini, bahkan jika Anda baru mengenal aksesibilitas web.

Lebih dari satu miliar orang hidup dengan beberapa bentuk disabilitas.

Agar dapat diakses, situs harus dapat berfungsi di beberapa perangkat dengan berbagai ukuran layar dan jenis input, seperti pembaca layar. Selain itu, situs harus dapat digunakan oleh sebanyak mungkin pengguna, termasuk pengguna yang menyandang disabilitas.

Berikut adalah beberapa disabilitas yang mungkin dimiliki pengguna Anda:

Visi	Pendengaran	Mobilitas
Gangguan penglihatan Tunanetra Buta warna Katarak Pantulan matahari	Gangguan pendengaran Tuna Rungu Kebisingan Infeksi telinga	Cedera sumsum tulang belakang Ketangkasan terbatas Tangan penuh
Kognitif	Ucapan	Neural
Kesulitan belajar Mengantuk atau gangguan Migrain Autisme Kejang	Derau sekitar Sakit tenggorokan Hambatan berbicara Tidak dapat berbicara	Depresi PTSD Gangguan bipolar Kecemasan

Masalah visual berkisar dari ketidakmampuan membedakan warna hingga tidak memiliki penglihatan sama sekali.

• Pastikan konten teks memenuhi batas rasio kontras minimum.
• Hindari menyampaikan informasi hanya menggunakan warna dan pastikan semua teks resizable.
• Pastikan semua komponen antarmuka pengguna dapat digunakan dengan teknologi pendukung seperti pembaca layar, kaca pembesar, dan penampil braille. Hal ini memerlukan memastikan bahwa komponen UI diberi markup sehingga API aksesibilitas dapat secara terprogram menentukan role, state, value, dan title elemen apa pun.

Tips: Fitur pemeriksaan elemen di browser menampilkan tooltip properti CSS yang menyertakan pemeriksaan cepat untuk rasio kontras warna.

Saya pribadi hidup dengan gangguan penglihatan, dan saya sering memperbesar situs, DevTools, dan terminal. Meskipun mendukung zoom hampir tidak pernah berada di bagian atas daftar tugas developer, ini dapat membuat banyak perbedaan bagi pengguna seperti saya.

Masalah pendengaran berarti pengguna mungkin mengalami masalah saat mendengarkan suara yang dikeluarkan dari halaman.

• Berikan alternatif teks untuk semua konten yang tidak hanya berisi teks.
• Uji apakah komponen UI Anda masih berfungsi tanpa suara.

Masalah mobilitas dapat mencakup ketidakmampuan untuk mengoperasikan mouse, keyboard, atau layar sentuh.

• Buat konten komponen UI Anda dapat diakses secara fungsional dari keyboard untuk tindakan apa pun yang tidak menggunakan mouse.
• Pastikan halaman di-markup dengan benar untuk teknologi pendukung—termasuk pembaca layar, software kontrol suara, dan kontrol tombol fisik—yang cenderung menggunakan API yang sama.

Masalah kognitif berarti pengguna mungkin memerlukan teknologi pendukung untuk membantu mereka membaca teks, jadi penting untuk memastikan adanya alternatif teks.

• Berhati-hatilah saat menggunakan animasi. Hindari video dan animasi yang berulang atau berkedip, yang dapat menyebabkan masalah bagi sebagian pengguna.

  Kueri media CSS prefers-reduced-motion memungkinkan Anda membatasi animasi dan video yang diputar otomatis untuk pengguna yang lebih memilih gerakan yang dikurangi:

  /*
  If the user expresses a preference for reduced motion, don't use animations on buttons.
  */
  @media (prefers-reduced-motion: reduce) {
    button {
      animation: none;
    }
  }
  

• Hindari interaksi yang berbasis waktu.

Ini mungkin tampak seperti banyak dasar yang harus dibahas, tetapi kita akan membahas proses untuk menilai dan kemudian meningkatkan aksesibilitas komponen UI Anda.

Untuk dukungan visual tambahan, tim aksesibilitas GOV.UK telah membuat serangkaian poster digital anjuran dan larangan aksesibilitas, yang dapat Anda gunakan untuk membagikan praktik terbaik kepada tim.

Enam poster yang mencantumkan praktik terbaik aksesibilitas. Baca teks lengkapnya.

Mengukur aksesibilitas komponen UI

Saat mengaudit komponen UI halaman untuk aksesibilitas, tanyakan pada diri Anda sendiri:

• Dapatkah Anda menggunakan komponen UI dengan keyboard saja?

  Apakah komponen tersebut mengelola fokus dan menghindari perangkap fokus? Dapatkah itu merespons peristiwa keyboard yang sesuai?

• Dapatkah Anda menggunakan komponen UI dengan pembaca layar?

  Sudahkah Anda memberikan alternatif teks untuk informasi apa pun yang ditampilkan secara visual? Sudahkah Anda menambahkan informasi semantik menggunakan ARIA?

• Apakah komponen UI Anda dapat berfungsi tanpa suara?

  Matikan speaker dan periksa kasus penggunaan Anda.

• Apakah komponen UI Anda dapat berfungsi tanpa warna?

  Pastikan komponen UI Anda dapat digunakan oleh seseorang yang tidak dapat melihat warna. Alat yang berguna untuk menyimulasikan buta warna adalah ekstensi Chrome yang disebut Colorblindly. (Coba keempat bentuk simulasi buta warna yang tersedia.) Anda mungkin juga tertarik dengan ekstensi Daltonize, yang juga bermanfaat.

• Apakah komponen UI Anda dapat berfungsi saat mode kontras tinggi diaktifkan?

  Semua sistem operasi modern mendukung mode kontras tinggi. Kontras Tinggi adalah ekstensi Chrome yang dapat membantu di sini.

Kontrol yang distandardisasi (seperti <button> dan <select>) memiliki aksesibilitas yang terintegrasi ke dalam browser. Fungsi ini dapat difokuskan menggunakan tombol Tab; mereka merespons peristiwa keyboard (seperti Enter, Space, dan tombol panah); dan memiliki peran, status, dan properti semantik yang digunakan oleh alat aksesibilitas. Gaya visual default-nya juga harus memenuhi persyaratan aksesibilitas yang tercantum.

Komponen UI kustom (dengan pengecualian komponen yang memperluas elemen standar seperti <button>) tidak memiliki kemampuan bawaan, termasuk aksesibilitas, sehingga Anda perlu menyediakannya. Sebaiknya mulai saat menerapkan aksesibilitas adalah membandingkan komponen Anda dengan elemen standar yang setara (atau kombinasi beberapa elemen standar, bergantung pada seberapa kompleks komponen Anda).

Kebanyakan alat developer browser mendukung pemeriksaan hierarki aksesibilitas halaman. Di Chrome DevTools, fitur ini tersedia di tab Aksesibilitas di panel Elemen.

Firefox juga memiliki panel Aksesibilitas.

Safari mengekspos informasi aksesibilitas di tab Node pada panel Elemen.

Berikut adalah daftar pertanyaan yang dapat Anda tanyakan pada diri sendiri saat mencoba membuat komponen UI lebih mudah diakses.

Tingkatkan fokus keyboard

Idealnya, pastikan semua fungsi di komponen UI Anda dapat diakses dengan keyboard. Saat mendesain pengalaman pengguna, pikirkan bagaimana Anda akan menggunakan elemen hanya dengan keyboard dan cari tahu serangkaian interaksi keyboard yang konsisten.

Pertama, pastikan Anda memiliki target fokus yang masuk akal untuk setiap komponen. Misalnya, komponen kompleks, seperti menu, dapat menjadi salah satu target fokus dalam halaman, tetapi harus mengelola fokus dalam halaman itu sendiri agar item menu aktif selalu menjadi fokus.

Mengelola fokus dalam elemen yang kompleks.

Gunakan tabindex

Anda dapat menambahkan fokus keyboard untuk elemen dan komponen UI dengan atribut tabindex. Pengguna teknologi pendukung dan khusus keyboard harus dapat menempatkan fokus keyboard pada elemen untuk berinteraksi dengannya.

Elemen interaktif bawaan (seperti <button>) secara implisit dapat difokuskan, sehingga tidak memerlukan atribut tabindex, kecuali jika Anda perlu mengubah posisinya dalam urutan tab.

Ada tiga jenis nilai tabindex:

• tabindex="0" adalah yang paling umum dan menempatkan elemen dalam urutan tab alami (ditentukan oleh urutan DOM).
• Nilai tabindex yang lebih besar dari 0 menempatkan elemen dalam urutan tab manual. Semua elemen di halaman dengan nilai tabindex positif dikunjungi dalam urutan numerik, sebelum elemen dalam urutan tab alami.
• Nilai tabindex yang sama dengan -1 menyebabkan elemen dapat difokuskan secara terprogram, tetapi tidak dalam urutan tab.

Untuk komponen UI kustom, selalu gunakan nilai tabindex 0 atau -1, karena Anda tidak akan dapat menentukan urutan elemen pada halaman tertentu sebelumnya. Nilai tabindex -1 sangat berguna untuk mengelola fokus dalam komponen yang kompleks.

Pastikan fokus selalu terlihat, baik dengan menggunakan gaya cincin fokus default maupun dengan menerapkan gaya fokus kustom yang jelas. Ingatlah untuk tidak menjebak pengguna keyboard—mereka harus dapat memindahkan fokus dari elemen hanya dengan menggunakan keyboard.

Catatan: Anda mungkin juga tertarik dengan pendekatan tabindex atau aria-activedescendant roving, seperti yang dibahas di MDN.

Menggunakan fokus otomatis

Atribut fokus otomatis HTML memungkinkan penulis menentukan bahwa elemen tertentu harus otomatis mengambil fokus saat halaman dimuat. autofocus sudah didukung di semua kontrol formulir web, termasuk tombol. Untuk memfokuskan elemen secara otomatis dalam komponen UI kustom Anda, panggil metode focus(), yang didukung pada semua elemen HTML yang dapat difokuskan (misalnya, document.querySelector('myButton').focus()).

Menambahkan interaksi keyboard

Setelah komponen UI dapat difokuskan, berikan cerita interaksi keyboard yang baik saat komponen difokuskan dengan menangani peristiwa keyboard yang sesuai. Misalnya, izinkan pengguna menggunakan tombol panah untuk memilih opsi menu dan Space atau Enter untuk mengaktifkan tombol. Panduan pola desain ARIA memberikan beberapa panduan di sini.

Terakhir, pastikan pintasan keyboard Anda dapat ditemukan. Praktik umumnya adalah memiliki legenda pintasan keyboard (teks di layar) untuk memberi tahu pengguna bahwa ada pintasan. Misalnya, "Tekan ? untuk pintasan {i>keyboard <i}“. Atau, petunjuk seperti tooltip dapat digunakan untuk memberi tahu pengguna tentang pintasan.

Pentingnya mengelola fokus tidak boleh dilebih-lebihkan. Contoh penting adalah panel navigasi. Jika komponen UI ditambahkan ke halaman, Anda harus mengarahkan fokus ke elemen di dalamnya; jika tidak, pengguna mungkin harus menekan tombol tab di seluruh halaman untuk membukanya. Ini bisa menjadi pengalaman yang menjengkelkan, jadi pastikan untuk menguji fokus untuk semua komponen yang dapat dinavigasi keyboard di halaman Anda.

Tips: Anda dapat menggunakan Puppeteer untuk mengotomatiskan pengoperasian pengujian aksesibilitas keyboard guna mengganti status UI. WalkMe Engineering memiliki panduan bagus tentang hal ini yang direkomendasikan untuk saya baca.

// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

Memastikan keberhasilan penggunaan pembaca layar

Sekitar 1% hingga 2% orang menggunakan {i>screen reader<i}. Dapatkah Anda memahami semua informasi penting dan berinteraksi dengan komponen menggunakan pembaca layar dan keyboard saja?

Pertanyaan berikut akan membantu Anda menangani aksesibilitas pembaca layar.

Apakah semua komponen dan gambar memiliki alternatif teks yang bermakna?

Di mana pun informasi tentang nama atau tujuan komponen interaktif disampaikan secara visual, berikan alternatif teks yang dapat diakses.

Misalnya, jika komponen UI <fancy-menu> Anda hanya menampilkan ikon roda gigi untuk menunjukkan bahwa itu adalah menu setelan, komponen UI tersebut memerlukan alternatif teks yang dapat diakses, seperti "setelan", yang menyampaikan informasi yang sama. Bergantung pada konteksnya, Anda dapat menyediakan alternatif teks menggunakan atribut alt, atribut aria-label, atribut aria-labelledby, atau teks biasa di Shadow DOM. Anda dapat menemukan tips teknis umum di Referensi Cepat WebAIM.

Komponen UI apa pun yang menampilkan gambar harus menyediakan mekanisme untuk menyediakan teks alternatif untuk gambar tersebut, yang serupa dengan atribut alt.

Apakah komponen Anda memberikan informasi semantik?

Teknologi pendukung menyampaikan informasi semantik yang dinyatakan kepada pengguna yang normal dengan isyarat visual, seperti pemformatan, gaya kursor, atau posisi. Elemen standar memiliki informasi semantik ini bawaan oleh browser, tetapi untuk komponen kustom, Anda harus menggunakan ARIA untuk menambahkan informasi.

Secara umum, komponen apa pun yang memproses peristiwa klik mouse atau pengarahan kursor harus memiliki sejenis pemroses peristiwa keyboard dan peran ARIA, mungkin juga status dan atribut ARIA.

Misalnya, komponen UI <fancy-slider> kustom mungkin menggunakan peran penggeser ARIA, yang memiliki beberapa atribut ARIA terkait: aria-valuenow, aria-valuemin, dan aria-valuemax. Dengan mengikat atribut ini ke properti yang relevan pada komponen kustom, Anda dapat mengizinkan pengguna teknologi pendukung untuk berinteraksi dengan elemen, mengubah nilainya, dan bahkan menyebabkan presentasi visual elemen berubah sesuai dengan itu.

Komponen penggeser rentang.

<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

Dapatkah pengguna memahami semuanya tanpa mengandalkan warna?

Warna tidak boleh digunakan sebagai satu-satunya cara untuk menyampaikan informasi, seperti menunjukkan status, meminta respons pengguna, atau memvisualisasikan data. Misalnya, jika Anda memiliki diagram lingkaran, berikan label dan nilai untuk setiap irisan agar pengguna yang memiliki gangguan penglihatan dapat memahami informasi tersebut, meskipun mereka tidak dapat melihat titik awal dan akhir potongan:

Diagram lingkaran yang dapat diakses. (Dari W3C Web Accessibility Initiative.)

Apakah ada kontras yang cukup?

Konten teks yang ditampilkan di komponen Anda harus memenuhi batas kontras tingkat AA minimum WCAG. Pertimbangkan untuk menyediakan tema kontras tinggi yang memenuhi batas AAA yang lebih tinggi, dan pastikan bahwa lembar gaya agen pengguna dapat diterapkan jika pengguna memerlukan kontras kustom atau warna yang berbeda. Anda dapat menggunakan Pemeriksa Kontras Warna ini sebagai bantuan saat mendesain komponen Anda.

Apakah konten yang bergerak atau berkedip dapat dihentikan dan aman?

Pengguna harus dapat menjeda, menghentikan, atau menyembunyikan konten yang bergerak, men-scroll, atau kedip selama lebih dari lima detik. Secara umum, hindari mem-flash konten.

Jika ada yang harus berkedip, pastikan perangkat berkedip tidak lebih dari tiga kali per detik.

Pengujian dan alat aksesibilitas

Ada lebih dari 100 alat yang tersedia untuk mengevaluasi aksesibilitas situs dan komponennya. Beberapa alat bersifat otomatis, sementara alat lainnya memerlukan pengujian manual.

Berikut ini beberapa yang dapat Anda pertimbangkan:

• Axe menyediakan pengujian aksesibilitas otomatis untuk framework atau browser pilihan Anda. Axe Puppeteer dapat digunakan untuk menulis pengujian aksesibilitas otomatis.

• Audit Aksesibilitas Lighthouse memberikan insight yang bermanfaat untuk menemukan masalah aksesibilitas umum. Skor aksesibilitas adalah rata-rata tertimbang dari semua audit aksesibilitas berdasarkan penilaian dampak pengguna Axe. Untuk memantau aksesibilitas dengan continuous integration, lihat Lighthouse CI.

  

• Tenon.io berguna untuk menguji masalah aksesibilitas umum. Tenon memiliki dukungan integrasi yang kuat di seluruh alat build, browser (melalui ekstensi), dan bahkan editor teks.

• Ada banyak alat khusus library dan framework untuk menyoroti masalah aksesibilitas dengan komponen. Misalnya, gunakan eslint-plugin-jsx-a11y untuk menandai masalah aksesibilitas untuk komponen React di editor Anda.

  

  Jika Anda menggunakan Angular, codelyzer juga menyediakan audit aksesibilitas dalam editor:

  

Bekerja dengan teknologi pendukung

Tips: Pelajari cara melakukan pengujian Teknologi Pendukung.

• Anda dapat memeriksa cara teknologi pendukung melihat konten web menggunakan Accessibility Inspector (Mac) atau Windows Automation API Testing Tools dan AccProbe (Windows). Anda juga dapat melihat hierarki aksesibilitas lengkap yang dibuat Chrome dengan membuka about://accessibility.
• Cara terbaik untuk menguji dukungan pembaca layar di Mac adalah menggunakan utilitas VoiceOver. Gunakan ⌘F5 untuk mengaktifkan atau menonaktifkannya, Ctrl+Option ←→ untuk berpindah-pindah halaman, dan Ctrl+Shift+Option + ↑↓ untuk naik dan turun pada hierarki aksesibilitas. Untuk petunjuk yang lebih mendetail, lihat daftar lengkap perintah VoiceOver dan daftar perintah Web VoiceOver.

• Di Windows, NVDA adalah pembaca layar open source dan gratis. Namun, jalur ini memiliki kurva belajar yang curam bagi pengguna dengan kemampuan penglihatan normal.

  

• ChromeOS memiliki pembaca layar bawaan.

Masih banyak langkah yang harus kami lakukan untuk meningkatkan aksesibilitas di web. Sesuai dengan Web Almanac:

• 4 dari setiap 5 situs memiliki teks yang menyatu dengan latar belakang, sehingga tidak dapat dibaca.
• 49,91% halaman masih gagal memberikan atribut alt untuk beberapa gambar mereka.
• Hanya 24% halaman yang menggunakan tombol atau link menyertakan label.
• Hanya 22,33% halaman yang memberikan label untuk semua input formulirnya.

Ada banyak hal yang dapat kita lakukan untuk membangun pengalaman yang lebih mudah diakses oleh semua orang.

Tips: Untuk mempelajari lebih lanjut dasar-dasar aksesibilitas dan membantu meningkatkan statistik tersebut, lihat Dapat diakses oleh semua dan Mempelajari Aksesibilitas.