Pola, komponen, dan sistem desain

Banyak orang menggunakan pengembangan berbasis komponen menggunakan panduan gaya pola, library komponen, atau sistem desain lengkap dalam proses alur kerja pengembangan mereka. Meskipun belum menggunakan alat ini secara formal, Anda mungkin menggunakan proses serupa untuk memecah desain besar untuk situs, aplikasi, atau produk digital lainnya menjadi bagian yang mudah dikelola.

Seperti membangun struktur fisik, Anda harus membangun satu bagian satu per satu. Pertama, fondasi, struktur, dinding, jendela, atap, dan semua yang ada di antaranya. Alat pengembangan berbasis komponen memungkinkan kita melakukannya untuk situs, aplikasi, dan produk digital lainnya.

Beberapa manfaat pengembangan berbasis komponen mencakup pemecahan berbagai hal menjadi bagian yang dapat dikelola, sehingga waktu pengembangan dengan komponen yang dapat digunakan kembali ini lebih singkat. Hal ini memungkinkan desainer, developer frontend dan backend, serta QA bekerja secara bersamaan. Klien, desainer, PM, dan lainnya menyukainya karena mereka dapat melihat pratinjau proses build dan menggunakan panduan gaya hidup sebagai referensi setelah situs diluncurkan.

Namun, saat kita melihat pola, komponen, dan sistem desain dengan mempertimbangkan aksesibilitas, beberapa pertanyaan akan muncul. Bagaimana cara mengetahui pola mana yang terbaik dalam hal aksesibilitas? Haruskah Anda menggunakan pola atau library yang sudah ada, atau membuat yang baru? Bagaimana Anda tahu apakah pola ini benar-benar akan membantu pengguna?

Dengan banyaknya pilihan yang tersedia, Anda akan mudah bingung dengan pola, komponen, dan sistem desain. Modul ini bertujuan untuk memberi Anda informasi umum tentang cara mengevaluasi pola, komponen, dan sistem desain untuk aksesibilitas serta memberi Anda titik awal untuk membantu Anda membuat pilihan yang lebih mudah diakses.

Berpikir secara kritis

Memilih pola, komponen, atau sistem desain yang mudah diakses bukanlah hal yang sulit, tetapi memerlukan waktu dan pemikiran kritis. Sebenarnya, tidak ada "satu pola yang sempurna", tetapi mungkin ada banyak opsi yang dapat berfungsi. Ini adalah tentang belajar memilih opsi terbaik untuk situasi unik Anda.

Di modul pengujian berikutnya, Anda akan membaca lebih lanjut teknik dan metode tentang cara mengevaluasi pola, komponen, dan sistem desain untuk aksesibilitas. Sebelum sampai ke sana, Anda perlu mengajukan beberapa pertanyaan dasar, seperti:

  • Apakah sudah ada pola, komponen, atau sistem desain yang mapan dan dapat diakses?
  • Browser dan teknologi pendukung (AT) apa yang saya dukung?
  • Apakah ada batasan kode atau framework? Apakah ada integrasi, faktor, atau kebutuhan pengguna lain yang harus saya pertimbangkan?

Bergantung pada lingkungan pengembangan dan kebutuhan pengguna, Anda mungkin memiliki pertanyaan tambahan atau berbeda dari pertanyaan ini. Pertimbangkan pertanyaan ini sebagai titik awal dalam evaluasi aksesibilitas Anda.

Resource yang sudah ada

Sebelum membuat sesuatu yang baru, lakukan uji kelayakan dan tinjau apa saja yang sudah ada dalam hal pola, komponen, dan sistem desain yang dapat diakses. Dengan sedikit riset, Anda mungkin akan terkejut menemukan solusi (atau beberapa) yang sesuai dengan kebutuhan Anda.

Beberapa referensi bagus untuk pola, komponen, dan sistem desain yang mudah diakses meliputi:

Untuk framework JavaScript, resource berikut cukup dapat diakses secara default atau dapat disesuaikan untuk aksesibilitas:

Namun—dan hal ini tidak dapat ditekankan—Anda tidak boleh hanya menyalin/menempelkan kode dan menganggapnya akan sesuai dengan lingkungan Anda dan secara otomatis memenuhi kebutuhan pengguna. Hal ini berlaku untuk semua pola, komponen, dan sistem desain, meskipun diberi label sebagai sepenuhnya dapat diakses.

Semua referensi harus dilihat sebagai titik awal. Pastikan untuk menguji semuanya.

Dukungan browser dan teknologi pendukung (AT)

Setelah meneliti beberapa pola dasar, komponen, atau sistem desain lengkap yang mungkin berfungsi untuk lingkungan pengembangan Anda, Anda dapat beralih ke dukungan teknologi pendukung. Salah satu jenis AT utama yang perlu Anda fokuskan saat mengevaluasi pola, komponen, dan sistem desain adalah pembaca layar.

Pembaca layar dibuat dengan mempertimbangkan browser tertentu dan berfungsi optimal saat disambungkan dengan browser ini. Kita akan membahas topik ini secara lebih mendetail dalam modul tentang pengujian AT, tetapi untuk tujuan evaluasi pola, sebaiknya pahami bahwa kombinasi ini ada, sehingga Anda tahu apa yang Anda butuhkan dalam hal dukungan.

Pembaca layar OS Kompatibilitas browser Biaya
Job Access with Speech (JAWS) Windows Chrome, Firefox, Edge Lisensi diperlukan (ada versi gratis berdurasi 40 menit)
Non-Visual Desktop Access (NVDA) Windows Chrome dan Firefox Gratis (memerlukan download)
Narator Windows Edge Gratis (terintegrasi dengan komputer Windows)
VoiceOver macOS Safari Gratis (terintegrasi di komputer macOS)
Orca Linux Firefox Gratis (terintegrasi dalam distribusi berbasis Gnome)
TalkBack Android Chrome dan Firefox Gratis (terintegrasi dalam versi Android OS tertentu)
VoiceOver iOS Safari Gratis (terintegrasi di perangkat iOS)

Dukungan browser umumnya rumit, dan semuanya menjadi lebih rumit saat Anda menambahkan perangkat AT dan spesifikasi ARIA ke dalam campuran.

Namun, tidak semuanya buruk. Untungnya, referensi yang bagus seperti Aksesibilitas HTML5, Dukungan Aksesibilitas, dan Checklist Pengembangan yang Dapat Diakses Kontrol Kustom WCAG membantu kita lebih memahami dukungan browser dan perangkat AT saat ini, dan bahkan kapan harus menggunakan ARIA.

Referensi ini menguraikan berbagai sub-elemen pola HTML dan ARIA yang tersedia, termasuk pengujian komunitas open source. Anda juga dapat meninjau beberapa contoh pola untuk desktop, browser seluler, dan perangkat AT. Dengan demikian, referensi ini dapat membantu Anda membuat keputusan yang lebih mudah diakses terkait pola, komponen, dan sistem desain yang mungkin ingin Anda gunakan.

Pertimbangan lainnya

Setelah memilih beberapa pola atau komponen dasar yang dapat diakses, dan mempertimbangkan dukungan perangkat AT dan browser, Anda dapat melanjutkan ke pertanyaan kontekstual yang lebih spesifik tentang pola, komponen, sistem desain, dan lingkungan pengembangan.

Misalnya, jika Anda bekerja di sistem pengelolaan (CMS) atau memiliki kode lama, mungkin ada beberapa batasan pola yang dapat Anda gunakan. Setelah ditinjau, beberapa pilihan pola dapat dengan cepat dipangkas menjadi satu atau dua opsi.

Banyak framework JavaScript yang memungkinkan developer menggunakan hampir semua pola yang mereka pilih. Dalam kasus seperti ini, Anda mungkin memiliki lebih sedikit batasan dan dapat memilih opsi pola yang paling mudah diakses.

Ada pertimbangan tambahan yang perlu dipertimbangkan saat memilih pola, komponen, atau sistem desain, seperti:

  • Performa
  • Keamanan
  • Pengoptimalan mesin telusur
  • Dukungan terjemahan bahasa
  • Integrasi pihak ketiga

Faktor-faktor ini tentunya akan memengaruhi pilihan pola Anda, tetapi Anda juga harus mempertimbangkan orang yang membuat konten dan kode itu sendiri. Pola yang Anda pilih harus cukup andal untuk menangani potensi batasan apa pun terkait konten buatan editor atau konten buatan pengguna, serta dibuat dengan cara yang dapat digunakan oleh developer dari semua pengetahuan aksesibilitas.

Memeriksa pemahaman Anda

Uji pengetahuan Anda tentang pola

Apakah komponen yang dapat diakses selalu tetap dapat diakses oleh pengguna?

Ya, Anda dapat menggunakan komponen ini tanpa pekerjaan tambahan.
Meskipun resource yang dibuat untuk aksesibilitas lebih cenderung berfungsi secara otomatis daripada resource lainnya, Anda tetap harus melakukan pengujian aksesibilitas untuk memastikan komponen ini berfungsi bagi pengguna.
Tidak, Anda harus menguji komponen terlebih dahulu.
Bahkan komponen dan pola yang dirancang untuk aksesibilitas harus diuji. Mungkin komponen tersebut tidak dapat diakses jika digabungkan dengan komponen lain yang sudah ada.