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, kemungkinan Anda menggunakan proses yang sama untuk memecah desain besar untuk situs, aplikasi, atau produk digital lainnya menjadi bagian-bagian yang mudah dikelola.

Seperti membangun struktur fisik, penting untuk membangun satu bagian dalam satu waktu. Pertama, fondasi, struktur, dinding, jendela, atap, dan segala sesuatu di antaranya. Alat pengembangan berbasis komponen memungkinkan kami melakukannya untuk situs, aplikasi, dan produk digital lainnya.

Beberapa keuntungan pada pengembangan berbasis komponen mencakup membagi hal-hal menjadi bagian-bagian yang dapat dikelola, sehingga waktu pengembangan komponen yang dapat digunakan kembali menjadi lebih singkat. Hal ini memungkinkan desainer, developer frontend dan backend, serta UM (Uji Mutu) untuk bekerja secara bersamaan. Dan klien, desainer, PM, dan banyak lagi, menyukainya karena mereka dapat melihat pratinjau proses build dan menggunakan panduan gaya hidup sebagai referensi setelah situs diluncurkan.

Namun, ketika kita melihat pola, komponen, dan sistem desain dengan mempertimbangkan aksesibilitas, beberapa pertanyaan muncul. Bagaimana Anda mengetahui pola mana yang terbaik dalam hal aksesibilitas? Apakah Anda harus menggunakan pola/library yang telah ditetapkan atau membuat yang baru? Bagaimana cara mengetahui apakah pola ini benar-benar akan membantu pengguna?

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

Berpikirlah secara kritis

Memilih pola, komponen, atau sistem desain yang mudah diakses bukanlah ilmu roket, tetapi membutuhkan waktu dan pemikiran kritis. Faktanya, tidak ada yang namanya "satu pola yang sempurna", tetapi mungkin ada banyak opsi yang bisa dilakukan. Ini tentang mempelajari cara memilih opsi terbaik untuk situasi unik Anda.

Dalam modul pengujian berikutnya, Anda akan mempelajari lebih lanjut teknik dan metode terkait cara mengevaluasi pola, komponen, dan sistem desain untuk aksesibilitas. Tetapi sebelum tahap itu, Anda perlu mundur dan bertanya pada diri sendiri beberapa pertanyaan mendasar, seperti:

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

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

Resource yang ditetapkan

Sebelum membangun sesuatu yang baru, lakukan uji tuntas dan tinjau apa yang sudah ada dalam hal pola, komponen, dan sistem desain yang mudah diakses. Dengan melakukan sedikit penelitian, Anda mungkin akan terkejut menemukan solusi—atau beberapa—yang sesuai dengan kebutuhan Anda.

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

Untuk framework JavaScript, resource berikut cukup dapat diakses langsung atau mudah disesuaikan untuk aksesibilitas:

Namun—dan hal ini tidak cukup membuat stres—Anda tidak boleh sekadar menyalin/menempel kode dan berasumsi bahwa kode tersebut akan cocok dengan lingkungan Anda dan secara otomatis memenuhi kebutuhan pengguna. Hal ini berlaku untuk semua pola, komponen, dan sistem desain, bahkan jika diberi label sebagai dapat diakses sepenuhnya.

Semua resource 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 cocok untuk lingkungan pengembangan Anda, Anda dapat melanjutkan 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 akan berfungsi paling baik jika disambungkan dengan browser ini. Kita akan membahas topik ini secara lebih mendetail dalam modul pengujian AT, tetapi untuk tujuan evaluasi pola, sebaiknya memahami kombinasi ini, sehingga Anda tahu apa yang Anda butuhkan dalam hal dukungan.

Pembaca layar OS Kompatibilitas browser Biaya
Akses Pekerjaan dengan Ucapan (JAWS) Windows Chrome, Firefox, Edge Lisensi diperlukan (ada versi gratis 40 menit)
Akses Desktop Non-Visual (NVDA) Windows Chrome dan Firefox Gratis (perlu didownload)
Narator Windows Edge Gratis (terintegrasi ke dalam komputer Windows)
VoiceOver macOS Safari Gratis (tertanam di dalam mesin macOS)
{i>Orca<i} Linux Firefox Gratis (terintegrasi ke dalam distribusi berbasis Gnome)
TalkBack Android Chrome dan Firefox Gratis (disertakan dalam versi Android OS tertentu)
VoiceOver iOS Safari Gratis (terpasang di perangkat iOS)

Dukungan browser umumnya rumit, dan keadaan akan semakin rumit saat Anda menambahkan perangkat AT dan spesifikasi ARIA ke kombinasi tersebut.

Tapi ini bukan semua hal buruk. Untungnya, referensi bagus seperti Aksesibilitas HTML5, Dukungan Aksesibilitas, dan Checklist Pengembangan Kontrol yang Dapat Diakses Kustom dari WCAG membantu kami lebih memahami dukungan browser dan perangkat AT saat ini, dan bahkan kapan harus menggunakan ARIA sejak awal.

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 browser desktop dan seluler/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 memperhitungkan dukungan perangkat browser dan AT, 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 terkait pola yang dapat Anda gunakan. Setelah ditinjau, beberapa pilihan pola dapat dengan cepat dipotong menjadi satu atau dua opsi.

Banyak framework JavaScript 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 pasti akan berperan dalam pilihan pola Anda, tetapi Anda juga harus mempertimbangkan orang yang membuat konten dan kode itu sendiri. Pola yang Anda pilih harus cukup kuat untuk menangani potensi batasan terkait konten buatan editor atau buatan pengguna, serta dibuat dengan cara yang dapat digunakan oleh developer dengan semua pengetahuan aksesibilitas.

Menguji 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 perlu upaya tambahan.
Meskipun resource yang dibuat untuk aksesibilitas lebih cenderung berfungsi secara otomatis dibandingkan resource lainnya, Anda harus tetap melakukan pengujian aksesibilitas untuk memastikan komponen tersebut berfungsi bagi pengguna Anda.
Tidak, Anda harus menguji komponen terlebih dahulu.
Bahkan komponen dan pola yang dirancang untuk aksesibilitas harus diuji. Mungkin file tidak dapat diakses saat digabungkan dengan komponen lain yang sudah ada.