Aksesibilitas untuk developer web

Meningkatkan aksesibilitas akan membuat situs Anda lebih bermanfaat bagi semua orang.

Addy Osmani

Penting untuk membangun situs yang inklusif dan dapat diakses oleh semua orang. Setidaknya ada enam area disabilitas utama yang dapat Anda optimalkan: visual, pendengaran, mobilitas, kognisi, ucapan, dan neural. Ada banyak alat dan referensi yang dapat membantu Anda, bahkan jika Anda benar-benar baru mengenal aksesibilitas web.

Lebih dari satu miliar orang hidup dengan beberapa bentuk disabilitas.

Agar dapat diakses, situs harus berfungsi di beberapa perangkat dengan berbagai ukuran layar dan berbagai jenis {i>input<i}, seperti pembaca layar. Selain itu, situs harus dapat digunakan oleh kelompok pengguna yang paling luas, termasuk mereka yang difabel.

Berikut adalah beberapa disabilitas yang mungkin dimiliki pengguna Anda:

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

• Pastikan konten teks memenuhi persyaratan minimum batas rasio kontras.
• Hindari menyampaikan informasi hanya menggunakan warna dan memastikan bahwa semua teks dapat diubah ukurannya.
• Memastikan semua komponen antarmuka pengguna dapat digunakan dengan teknologi pendukung seperti pembaca layar, kaca pembesar, dan penampil braille. Ini berarti memastikan bahwa komponen UI di-markup sehingga API aksesibilitas dapat menentukan role, state, value, dan title elemen apa pun.

Saya pribadi hidup dengan keterbatasan penglihatan, dan saya sering mendapati diri saya memperbesar tampilan situs, DevTools, dan terminal. Meskipun mendukung zoom hampir tidak pernah menjadi prioritas developer daftar tugas, hal itu dapat menciptakan perbedaan bagi pengguna seperti saya.

Masalah pendengaran berarti pengguna mungkin mengalami masalah saat mendengar suara yang keluar dari halaman.

• Sediakan alternatif teks untuk semua konten yang bukan teks sepenuhnya.
• Menguji apakah komponen UI Anda masih berfungsi tanpa suara.

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

• Membuat konten komponen UI dapat diakses secara fungsional dari keyboard untuk tindakan apa pun yang seharusnya menggunakan {i>mouse<i}.
• 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 dalam membaca teks, jadi penting untuk memastikan alternatif teks tersedia.

• Berhati-hatilah saat menggunakan animasi. Hindari video dan animasi yang ulangi atau flash, yang dapat menyebabkan masalah untuk beberapa pengguna.

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

  /*
  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.

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

Untuk dukungan visual tambahan, tim aksesibilitas GOV.UK telah membuat serangkaian yang perlu dilakukan dan tidak dilakukan terkait aksesibilitas pada poster digital, yang dapat Anda gunakan untuk membagikan praktik terbaik dengan tim Anda.

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 mengelola fokus dan menghindari jebakan fokus? Dapatkah itu merespons peristiwa keyboard yang sesuai?

• Dapatkah Anda menggunakan komponen UI dengan pembaca layar?

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

• Apakah komponen UI Anda dapat berfungsi tanpa suara?

  Matikan speaker dan pelajari kasus penggunaan Anda.

• Dapatkah komponen UI 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 Buta warna. (Cobalah keempat bentuk simulasi buta warna yang tersedia.) Anda mungkin juga tertarik dengan Daltonisasi , yang sama bermanfaatnya.

• Dapatkah komponen UI Anda berfungsi jika mode kontras tinggi diaktifkan?

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

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

Komponen UI kustom (kecuali komponen yang memperluas elemen seperti <button>) tidak memiliki kemampuan bawaan, termasuk aksesibilitas, jadi Anda perlu menyediakannya. Tempat yang baik untuk memulai menerapkan aksesibilitas adalah membandingkan komponen Anda dengan standar analog (atau kombinasi beberapa elemen standar, tergantung pada seberapa rumit komponen Anda).

Sebagian besar 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 Elements.

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

Tingkatkan fokus keyboard

Idealnya, pastikan semua fungsionalitas di komponen UI Anda dapat diakses dengan {i>keyboard<i}. Saat mendesain pengalaman pengguna, pikirkan bagaimana Anda akan menggunakan elemen Anda dengan {i>keyboard<i} saja dan mencari tahu serangkaian interaksi {i>keyboard<i} yang konsisten.

Pertama, pastikan Anda memiliki target fokus yang logis untuk setiap komponen. Misalnya, komponen yang kompleks seperti menu dapat menjadi salah satu target fokus dalam tetapi selanjutnya mengelola fokus di dalamnya sendiri sehingga item menu aktif selalu membutuhkan fokus.

Menggunakan tabindex

Anda dapat menambahkan fokus keyboard untuk elemen dan komponen UI dengan tabindex . Pengguna {i>keyboard<i} dan teknologi pendukung harus dapat menempatkan {i>keyboard<i} berfokus pada elemen untuk berinteraksi dengan mereka.

Elemen interaktif bawaan (seperti <button>) secara implisit dapat difokuskan, jadi fungsi ini 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 di tab alami (ditentukan oleh urutan DOM).
• Nilai tabindex yang sama dengan -1 menyebabkan elemen ditampilkan secara terprogram dapat difokuskan, tetapi tidak dalam urutan tab.
• Nilai tabindex yang lebih besar dari 0 menempatkan elemen dalam urutan tab manual. Semua elemen di halaman dengan nilai tabindex positif dikunjungi di urutan numerik, sebelum elemen dalam urutan tab alami.

Temukan beberapa kasus penggunaan untuk tabindex di artikel Menggunakan tabindex.

Pastikan fokus selalu terlihat, baik dengan menggunakan cincin fokus default atau dengan menerapkan gaya fokus kustom yang jelas. Ingatlah untuk tidak menjebak pengguna {i>keyboard<i}—mereka harus dapat mengalihkan fokus dari elemen hanya dengan menggunakan {i>keyboard<i}.

Menggunakan fokus otomatis

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

Menambahkan interaksi keyboard

Setelah komponen UI Anda dapat difokuskan, berikan cerita interaksi keyboard yang bagus ketika komponen difokuskan dengan menangani peristiwa {i>keyboard<i} 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 yang umum adalah memiliki legenda pintasan keyboard (teks di layar) untuk memberi tahu pengguna bahwa ada pintasan. Misalnya, "Tekan ? untuk keyboard pintasan." Atau, petunjuk seperti tooltip seperti itu dapat digunakan untuk memberi tahu pengguna tentang {i>shortcut<i}.

Pentingnya mengelola fokus tidak boleh dilebih-lebihkan. Sebuah contoh penting adalah panel navigasi. Jika Anda menambahkan komponen UI ke laman, Anda perlu mengarahkan fokus ke elemen di dalamnya; jika tidak, pengguna mungkin harus menelusuri seluruh halaman untuk sampai ke sana. Hal ini bisa menjadi pengalaman yang membuat frustrasi, jadi pastikan untuk menguji fokus pada semua komponen yang dapat dinavigasi menggunakan keyboard di halaman.

// 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 pembaca layar. Bisakah Anda memahami semua hal penting informasi dan berinteraksi dengan komponen menggunakan pembaca layar dan {i>keyboard<i} sendirian?

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 dari sebuah komponen interaktif disampaikan secara visual, menyediakan alternatif teks yang dapat diakses.

Misalnya, jika komponen UI <fancy-menu> Anda hanya menampilkan ikon roda gigi untuk menunjukkan bahwa ini adalah menu pengaturan, aplikasi memerlukan alternatif teks yang dapat diakses, seperti "setelan", yang menyampaikan informasi yang sama. Tergantung pada konteksnya, Anda dapat memberikan 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.

Setiap komponen UI yang menampilkan gambar harus menyediakan mekanisme untuk memberikan teks alternatif bagi gambar tersebut, setara dengan atribut alt.

Apakah komponen Anda menyediakan informasi semantik?

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

Secara umum, komponen apa pun yang mendengarkan klik mouse atau peristiwa pengarahan kursor harus memiliki semacam pemroses peristiwa keyboard dan peran ARIA, mungkin Status dan atribut ARIA.

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

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

Bisakah pengguna memahami semuanya tanpa bergantung pada warna?

Warna tidak boleh digunakan sebagai satu-satunya cara menyampaikan informasi, seperti menunjukkan status, meminta respons pengguna, atau memvisualisasikan data. Misalnya, jika Anda memiliki bagan pai, berikan label dan nilai untuk setiap irisan sehingga pengguna yang memiliki gangguan penglihatan dapat memahami informasi, bahkan jika mereka tidak dapat melihat di mana irisan dimulai dan berakhir:

Apakah ada kontras yang memadai?

Setiap konten teks yang ditampilkan di komponen Anda harus memenuhi batas kontras tingkat AA minimum WCAG. Pertimbangkan untuk menyediakan tema kontras tinggi yang memenuhi nilai minimum AAA lebih tinggi, dan memastikan bahwa lembar gaya agen pengguna dapat diterapkan jika pengguna membutuhkan kontras khusus atau warna yang berbeda. Anda dapat menggunakan Pemeriksa Kontras Warna ini sebagai bantuan ketika mendesain komponen Anda.

Apakah konten yang berpindah atau berkedip dapat dihentikan dan aman?

Pengguna harus dapat menjeda, menghentikan, atau menyembunyikan konten yang berpindah, men-scroll, atau berkedip selama lebih dari lima detik. Secara umum, hindari melakukan flash konten.

Jika sesuatu harus berkedip, pastikan itu berkedip tidak lebih dari tiga kali per detik.

Alat dan pengujian aksesibilitas

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

Berikut beberapa hal untuk Anda pertimbangkan:

• Axe menyediakan aksesibilitas otomatis untuk kerangka kerja atau browser pilihan Anda. Puppet Kapak dapat digunakan untuk menulis pengujian aksesibilitas otomatis.

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

  

• 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 kerangka kerja untuk menyoroti masalah aksesibilitas dengan komponen. Misalnya, gunakan eslint-plugin-jsx-a11y untuk menandai masalah aksesibilitas komponen React di editor Anda.

  

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

  

Bekerja dengan teknologi pendukung

• Anda dapat memeriksa cara teknologi pendukung melihat konten web dengan 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 dengan menggunakan VoiceOver utilitas. Gunakan ⌘F5 untuk mengaktifkan atau menonaktifkannya, Ctrl+Option ←→ untuk melanjutkan halaman, dan Ctrl+Shift+Option + ↑↓ untuk memindahkan aksesibilitas ke atas dan bawah hierarki. Untuk petunjuk yang lebih rinci, lihat daftar lengkap perintah VoiceOver dan daftar perintah VoiceOver Web.

• Di Windows, NVDA adalah layar open source gratis pembaca. Namun, cara ini memiliki kurva belajar yang curam bagi pengguna yang mampu melihat.

  

• ChromeOS memiliki pembaca layar bawaan.

Masih banyak yang harus kita lakukan untuk meningkatkan aksesibilitas di web. Sesuai dengan Web Almanak:

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

Masih banyak yang bisa kita lakukan untuk membangun pengalaman yang lebih mudah diakses semua orang.