Aksesibilitas untuk tim

Cara menyertakan aksesibilitas ke dalam proses tim Anda.

Rob Dodson

Membuat situs Anda lebih mudah diakses bisa menjadi tugas yang sulit. Jika Anda baru pertama kali mendekati aksesibilitas, topiknya yang luas dapat membuat Anda bertanya-tanya harus mulai dari mana. Lagi pula, berupaya untuk mengakomodasi berbagai kemampuan berarti ada beragam rentang masalah yang sesuai untuk dipertimbangkan.

Ingat, aksesibilitas adalah upaya tim. Setiap orang memiliki perannya masing-masing. Artikel ini menguraikan kriteria untuk setiap disiplin ilmu utama (project manager, desainer UX, dan developer) agar mereka dapat berupaya menerapkan praktik terbaik aksesibilitas ke dalam proses.

Manajer proyek

Tujuan utama setiap project manager adalah mencoba menyertakan pekerjaan aksesibilitas di setiap tonggak pencapaian; memastikan hal tersebut sama prioritasnya dengan topik lainnya seperti performa dan pengalaman pengguna. Berikut adalah beberapa item {i>checklist<i} yang perlu diingat saat mengerjakan proses Anda.

  • Menyediakan pelatihan aksesibilitas untuk tim.
  • Identifikasi perjalanan penting pengguna di situs atau aplikasi.
  • Cobalah untuk memasukkan {i>checklist<i} aksesibilitas ke dalam proses tim.
  • Jika memungkinkan, evaluasi situs atau aplikasi dengan studi pengguna.

Pelatihan aksesibilitas

Ada banyak referensi gratis yang bagus untuk belajar tentang aksesibilitas web. Meluangkan waktu bagi tim Anda untuk mempelajari topik dapat memudahkan untuk menyertakan aksesibilitas di awal proses.

Beberapa referensi yang disediakan oleh Google mencakup:

Web Accessibility by Google — kursus pelatihan interaktif selama beberapa minggu.

Dasar-Dasar Aksesibilitas — panduan aksesibilitas tertulis dan praktik terbaik.

Pedoman Material: Aksesibilitas — sekumpulan praktik terbaik UX untuk desain inklusif.

Mengidentifikasi {i>user journey<i} yang penting

Setiap aplikasi memiliki beberapa tindakan utama yang perlu diambil pengguna. Misalnya, jika Anda mem-build aplikasi e-commerce, setiap pengguna harus dapat menambahkan item ke keranjang belanjanya.

Perjalanan pengguna utama: Pengguna dapat menambahkan item ke keranjang belanja mereka.

Beberapa tindakan mungkin memiliki kepentingan sekunder dan mungkin hanya dilakukan terkadang. Misalnya, mengubah foto avatar adalah fitur yang bagus, tetapi mungkin tidak penting untuk setiap pengalaman.

Mengidentifikasi tindakan utama dan sekunder dalam aplikasi akan membantu Anda memprioritaskan pekerjaan aksesibilitas terlebih dahulu. Nantinya, Anda dapat menggabungkan tindakan ini dengan checklist aksesibilitas untuk melacak progres dan menghindari regresi.

Menggabungkan checklist aksesibilitas

Topik aksesibilitas cukup luas, sehingga memiliki checklist area penting yang perlu dipertimbangkan dapat membantu memastikan Anda mencakup semua dasar.

Ada sejumlah checklist aksesibilitas di luar sana, beberapa contoh industrinya meliputi:

Checklist WebAIM WCAG Panduan Aksesibilitas Vox

Dengan checklist, Anda dapat memeriksa tindakan utama dan sekunder untuk mulai menentukan prioritas pekerjaan yang masih perlu dilakukan. Anda bisa menjadi sangat taktis mengenai proses ini dan bahkan membuat matriks tindakan primer dan sekunder serta menentukan untuk setiap langkah dalam proses tersebut, apakah ada bit aksesibilitas yang hilang.

Tabel dengan kasus penggunaan utama sebagai baris dan checklist item sebagai kolom.

Mengevaluasi dengan studi pengguna

Tidak ada yang lebih baik bila Anda berinteraksi dengan pengguna sebenarnya dan mengamati mereka saat mencoba menggunakan aplikasi Anda. Jika Anda menerapkan aksesibilitas ke dalam pengalaman yang sudah ada, proses ini dapat membantu Anda mengidentifikasi dengan cepat area yang perlu ditingkatkan. Dan jika Anda memulai project baru, studi pengguna awal dapat membantu Anda menghindari menghabiskan terlalu banyak waktu untuk mengembangkan fitur yang sulit digunakan.

Upayakan untuk menggabungkan {i>feedback<i} dari berbagai populasi pengguna. Pertimbangkan pengguna yang umumnya melakukan navigasi dengan keyboard, atau mengandalkan teknologi asistif seperti pembaca layar atau pembesar layar.

Desainer UX

Karena orang cenderung mendesain menggunakan biasnya sendiri, jika Anda tidak memiliki disabilitas dan tidak memiliki rekan kerja yang menyandang disabilitas, Anda mungkin tidak sengaja mendesain hanya untuk sebagian pengguna. Saat Anda bekerja, tanyakan pada diri Anda sendiri "apa saja tipe pengguna yang mungkin mengandalkan desain ini?" Berikut adalah beberapa teknik yang dapat Anda coba untuk membuat proses Anda lebih inklusif.

  • Konten memiliki kontras warna yang memadai.
  • Urutan tab ditentukan.
  • Kontrol memiliki label yang dapat diakses.
  • Ada beberapa cara untuk berinteraksi dengan UI.

Konten memiliki kontras warna yang baik

Tujuan utama sebagian besar situs adalah menyampaikan beberapa informasi kepada pengguna, baik melalui teks tertulis atau gambar. Namun, jika konten ini memiliki kontras rendah, mungkin sulit bagi beberapa pengguna (terutama mereka yang memiliki gangguan penglihatan) untuk membaca. Hal ini dapat berdampak negatif terhadap pengalaman pengguna mereka. Untuk mengatasi masalah ini, upayakan agar semua teks dan gambar memiliki kontras warna yang memadai.

Kontras diukur dengan membandingkan luminans warna latar depan dan latar belakang. Untuk teks yang lebih kecil (di bawah 18 pt atau tebal 14 pt), sebaiknya gunakan rasio minimum 4,5:1. Untuk teks yang lebih besar, rasio ini dapat disesuaikan menjadi 3:1.

Pada gambar di bawah, teks di sisi kiri memenuhi kontras minimum ini, sedangkan teks di sisi kanan memiliki kontras rendah.

Contoh teks berdampingan. Satu kontrasnya cukup, satu lagi kontras rendah.

Ada sejumlah alat untuk mengukur kontras warna, seperti Alat Warna Material Google, aplikasi Rasio Kontras Lea Verou, dan aXe Deque.

Urutan tab ditentukan

Urutan tab adalah urutan elemen menerima fokus saat pengguna menekan tombol tab. Bagi pengguna yang terutama melakukan navigasi dengan keyboard, tombol tab adalah sarana utama mereka untuk menjangkau semua yang ada di layar. Anggap saja seperti kursor {i>mouse<i} mereka.

Idealnya, urutan tab harus mengikuti urutan pembacaan dan mengalir dari bagian atas halaman ke bawah, dengan item yang lebih penting muncul lebih tinggi sesuai urutan. Hal ini menjadikan lebih efisien bagi siapa saja yang menggunakan keyboard untuk menjangkau item ini dengan cepat.

Perbandingan desain dengan kontrol interaktif bernomor.

Antarmuka tiruan di atas diberi nomor untuk menunjukkan urutan tab. Membuat {i>mockup<i} seperti ini dapat membantu dengan mengidentifikasi urutan tab yang diinginkan. Kemudian, hasil ini dapat dibagikan kepada developer dan penguji QA untuk memastikannya diimplementasikan dan diuji dengan benar.

Kontrol memiliki label yang dapat diakses

Untuk pengguna teknologi pendukung seperti pembaca layar, label memberikan informasi yang biasanya hanya bersifat visual. Misalnya, tombol penelusuran yang berupa ikon kaca pembesar dapat memiliki label "Penelusuran" yang dapat diakses untuk membantu mengisi kemampuan visual yang hilang.

Berikut adalah beberapa saran sederhana untuk diikuti saat mendesain label yang mudah diakses:

  • Singkat - Mendengarkan deskripsi yang panjang mungkin membosankan.
  • Coba untuk tidak menyertakan jenis atau status kontrol - Jika kontrol dikodekan dengan benar, pembaca layar akan mengumumkannya secara otomatis.
  • Fokus pada kata kerja tindakan - Gunakan "telusuri" bukan "kaca pembesar".
Kompor desain dengan kontrol yang ditandai dengan label yang dapat diakses.

Anda dapat mempertimbangkan untuk membuat {i>mockup<i} dengan semua kontrol diberi label. Ini dapat dibagikan kepada tim pengembangan dan tim UM (Uji Mutu) untuk implementasi dan pengujian.

Banyak cara untuk berinteraksi dengan dan memahami UI

Sangat mudah untuk mengasumsikan bahwa semua pengguna berinteraksi dengan halaman, terutama menggunakan mouse. Saat mendesain, pertimbangkan bagaimana seseorang akan berinteraksi dengan kontrol menggunakan keyboard.

Rencanakan status fokus Anda! Hal ini berarti menentukan tampilan kontrol saat pengguna memfokuskannya dengan tab atau menekan tombol panah. Keadaan ini akan lebih baik jika direncanakan lebih awal, daripada mencoba menyertakan semuanya ke dalam desain nanti.

Terakhir, untuk setiap titik interaksi, pastikan bahwa pengguna memiliki beberapa cara untuk memahami kontennya. Cobalah untuk tidak menggunakan warna saja untuk menyampaikan informasi, karena petunjuk halus ini mungkin terlewatkan oleh pengguna yang memiliki kekurangan penglihatan warna. Contoh yang paling klasik adalah kolom teks yang tidak valid. Selain garis bawah berwarna merah untuk menandakan masalah, pertimbangkan juga untuk menambahkan beberapa teks bantuan. Dengan demikian, Anda mencakup lebih banyak basis dan meningkatkan kemungkinan pengguna akan memperhatikan masalah tersebut.

Developer

Peran developer adalah menggabungkan pengelolaan fokus dan semantik untuk membentuk pengalaman pengguna yang tangguh. Berikut beberapa item yang dapat diingat developer saat sedang mengerjakan situs atau aplikasi:

  • Urutan tab bersifat logis.
  • Fokus dikelola dan terlihat dengan benar.
  • Elemen interaktif memiliki dukungan keyboard.
  • Peran dan atribut ARIA diterapkan sesuai kebutuhan.
  • Elemen diberi label dengan benar.
  • Pengujian dilakukan secara otomatis.

Urutan tab logis

Elemen native seperti input, button, dan select diikutsertakan ke dalam urutan tab secara gratis dan dapat difokuskan secara otomatis dengan keyboard. Namun, tidak semua elemen menerima perilaku yang sama ini. Secara khusus, elemen umum seperti div, dan span, tidak diikutsertakan dalam urutan tab. Ini berarti jika Anda menggunakan div untuk membuat kontrol interaktif, Anda harus melakukan pekerjaan tambahan agar membuatnya dapat diakses dari keyboard.

Dua opsinya adalah:

  • Berikan tabindex="0" pada kontrol. Setidaknya hal ini akan membuatnya dapat difokuskan, meskipun Anda mungkin perlu melakukan pekerjaan tambahan guna menambahkan dukungan untuk penekanan tombol.
  • Jika memungkinkan, sebaiknya gunakan button, bukan div atau span, untuk kontrol seperti tombol. Elemen button native sangat mudah ditata gayanya dan mendapatkan dukungan keyboard secara gratis.

Mengelola fokus

Saat Anda mengubah konten halaman, penting untuk mengarahkan perhatian pengguna dengan memindahkan fokus. Contoh klasik terkait kegunaan teknik ini adalah saat membuka dialog modal. Jika pengguna yang mengandalkan keyboard menekan tombol untuk membuka dialog dan fokusnya tidak dipindahkan ke elemen dialog, satu-satunya tindakan mereka adalah melakukan tab di seluruh situs hingga menemukan kontrol baru. Dengan memindahkan fokus ke konten baru segera setelah konten tersebut ditampilkan, Anda dapat meningkatkan efisiensi pengalaman pengguna tersebut.

Dukungan {i>keyboard<i} untuk elemen interaktif

Jika membangun kontrol kustom seperti carousel atau dropdown, Anda harus melakukan beberapa tugas tambahan untuk menambahkan dukungan keyboard. Panduan Praktik Penulisan ARIA adalah referensi berguna yang mengidentifikasi berbagai pola UI dan jenis tindakan keyboard yang diharapkan dapat didukung.

Kutipan dari panduan ARIA Authoring Practices yang menjelaskan cara membuat grup radio.

Untuk mempelajari lebih lanjut cara menambahkan dukungan keyboard ke elemen, lihat bagian roving tabindex dalam dokumen Dasar-Dasar Aksesibilitas Google.

Peran dan atribut ARIA diterapkan sesuai kebutuhan

Kontrol kustom tidak hanya memerlukan dukungan keyboard yang tepat, tetapi juga memerlukan semantik yang tepat. Lagi pula, div, secara semantik, hanyalah penampung pengelompokan generik. Jika menggunakan div sebagai dasar untuk menu dropdown, Anda harus mengandalkan ARIA untuk menambahkan lapisan dalam semantik tambahan sehingga jenis kontrol dapat disampaikan ke teknologi pendukung. Sekali lagi, Panduan Praktik Penulisan ARIA dapat membantu dengan mengidentifikasi peran, status, dan properti mana yang harus Anda gunakan. Sebagai bonus tambahan, banyak penjelasan dalam panduan ARIA juga dilengkapi dengan kode contoh.

Elemen pelabelan

Untuk melabeli input native, Anda dapat menggunakan elemen <label> bawaan seperti yang dijelaskan di MDN. Hal ini tidak hanya membantu Anda membuat kemampuan visual di layar, tetapi juga memberi input nama yang dapat diakses di pohon aksesibilitas. Nama ini kemudian diambil oleh teknologi pendukung (seperti pembaca layar) dan diumumkan kepada pengguna.

Sayangnya, <label> tidak mendukung pemberian nama yang dapat diakses ke kontrol kustom (seperti yang dibuat menggunakan Elemen Kustom atau di luar div dan span sederhana). Untuk jenis kontrol ini, Anda harus menggunakan atribut aria-label dan aria-labelledby.

Pengujian otomatis

Bermalas-malasan itu bagus, terutama saat melakukan pengujian. Jika memungkinkan, berusahalah untuk mengotomatiskan pengujian aksesibilitas agar Anda tidak perlu melakukan semuanya secara manual. Ada sejumlah alat pengujian industri hebat yang ada saat ini untuk memudahkan dan cepat memeriksa masalah aksesibilitas umum:

aXe, yang dibuat oleh sistem Deque, tersedia sebagai ekstensi Chrome dan modul Node (cocok untuk lingkungan continuous integration). A11ycast singkat ini menjelaskan beberapa cara untuk menggabungkan aXe ke dalam proses pengembangan Anda.

Lighthouse adalah project open source Google untuk mengaudit performa Progressive Web App Anda. Selain memeriksa apakah PWA Anda memiliki dukungan untuk hal-hal seperti Pekerja Layanan dan Manifes Aplikasi Web, Lighthouse juga akan menjalankan serangkaian uji praktik terbaik, termasuk pengujian untuk masalah aksesibilitas.

Kesimpulan

Aksesibilitas adalah upaya tim. Setiap orang memiliki perannya masing-masing. Panduan ini telah menjabarkan beberapa item penting yang dapat digunakan setiap anggota tim untuk meningkatkan subjek tersebut dengan cepat, dan semoga dapat meningkatkan pengalaman aplikasi secara keseluruhan.

Untuk mempelajari aksesibilitas lebih lanjut, pastikan untuk melihat kursus mdpi gratis kami dan jelajahi dokumen aksesibilitas yang tersedia di sini di web.dev.