Ngobrolin Accessibility
Ringkasan Episode
Bantu KoreksiAksesibilitas dibahas berangkat dari satu kekeliruan yang sering kita lakukan: menganggap pengguna kita sama seperti kita sendiri. Sama seperti soal performa, di mana kita mengasumsikan semua orang punya koneksi lancar, di sini kita mengasumsikan semua orang melihat, mendengar, dan bergerak seperti kita. Padahal cakupannya luas — dari buta warna sebagian, penglihatan yang menurun karena usia, gangguan motorik, sampai kemampuan memahami. Ivan bercerita jujur bahwa ia mulai mempelajarinya karena tuntutan hukum: sebuah bank internasional mensyaratkan situsnya lolos WCAG level AAA, sejajar dengan GDPR dan urusan keamanan lain. Di banyak negara aturan itu memang kelanjutan dari aturan fisik yang sudah lama ada — bangunan publik wajib menyediakan akses kursi roda, trotoar wajib punya jalur khusus Tuna Netra. Karena infrastruktur pindah ke digital, kewajibannya ikut pindah. Yang menarik adalah efek yang meluas. Landaian di ujung trotoar mula-mula dibuat untuk pengguna kursi roda, tapi ternyata membantu jauh lebih banyak orang, termasuk yang mendorong stroller. Begitu pula di web: pengaturan ukuran teks dan kontras yang baik menolong bukan hanya mereka yang penglihatannya terbatas. Navigasi lewat tombol tab pun sama — dipakai mereka yang tak bisa memakai tetikus sekaligus pengguna mahir yang enggan memindahkan tangan. WCAG dari W3C menyediakan patokan teknis berjenjang dari A sampai AAA, dan Lighthouse menangkap yang paling dasar seperti kontras warna — tapi lolos pemeriksaan bukan jaminan: alt text yang asal tulis tetap lolos padahal tidak menolong pengguna screen reader.
Poin-poin Utama
- •Kekeliruan paling dasar adalah menganggap semua pengguna seperti kita sendiri — sama seperti mengasumsikan semua orang punya koneksi internet lancar
- •Tuntutan hukum bisa jadi pemicunya: sebuah bank internasional mensyaratkan situsnya lolos WCAG level AAA, sejajar dengan GDPR dan urusan keamanan lain
- •Aturan aksesibilitas digital adalah kelanjutan aturan fisik yang lebih dulu ada, seperti akses kursi roda dan jalur khusus Tuna Netra di trotoar
- •Landaian trotoar dibuat untuk pengguna kursi roda tapi menolong jauh lebih banyak orang — prinsip yang sama berlaku di web
- •Navigasi lewat tombol tab dipakai mereka yang tidak bisa memakai tetikus sekaligus pengguna mahir yang enggan memindahkan tangan
- •WCAG dari W3C memberi patokan teknis berjenjang dari A sampai AAA, dan Lighthouse menangkap yang paling dasar seperti kontras warna
- •Lolos pemeriksaan bukan jaminan: alt text yang asal tulis tetap lolos padahal tidak menolong pengguna screen reader
Hai, hai, hai selamat malam semuanya.
Halo.
Jumpa kembali kita di Selasa Malam.
Selasa Malam waktunya ngobrolin.
Ngobrolin, ngobrolin.
Udah lama libur kan, jadi lupa kan.
Jadi harus ratian lagi.
Terus ada sesi yel-yel sendiri.
Iya, gimana liburannya teman-teman semua.
Sekarang kita sudah kembali ke dunia nyata.
Macet, macet, macet.
Macet lagi.
Kedengerannya macet ya, harus balik ya.
Kerja ribet, can't relate.
Ini teman-teman penonton, ada yang mudik gak?
Atau masih di kampung halaman?
Udah balik lagi?
Atau lagi di jalan?
Atau lagi di jalan.
Wah bahaya, jangan nyetir ya.
Kalau lagi nyetir jangan ya.
Jangan nonton, dengerin audionya aja.
Halo ada Audi nih.
Halo.
Oke, malam hari ini kita topiknya akan membahas tentang aksesibility atau a11y.
Ali, Eli.
Ali, Eli.
Eli, Eli.
Alay, alay.
Trivia, trivia.
Lihat transkrip lengkap (1082 segmen lagi)
Tau gak kenapa mungkin teman-teman yang dikomen tau gak kenapa ditulisnya kayak gitu.
A11y ya.
Kalau bahasa Indonesia, baca apa ya?
Aksesibilitas.
Aksesibilitas kelihatannya ya.
Jadi itu tuh nama, ada istilahnya ternyata.
Itu namanya numeronik.
Aneh ya.
Jadi sama kan kayak internationalization juga gitu kan ya.
I, 18, N.
I, 18, N.
Aksesibility a11y.
Jadi 11 itu jumlah huruf yang di antara, yang di tengah antara a sama y,
antara huruf pertama sama terakhir, itu ada 11 huruf.
Makanya a11y.
Ada namanya numeronim.
Gak tau kenapa orang bisa aja ya mikir, bikin konsep kayak gitu.
Kenapa itu dipakai dengan a11? Susah ya.
Lebih gampang nulisnya.
Gnya 2, Snya 2, atau 1, gitu kan.
Cuma di dunia webdive atau tech pada umumnya,
sebenarnya yang dibuat numeronimnya itu apa aja sih ya,
selain aksesibility dan internationalization.
Pada temen-temen, pada pernah denger istilah lain gak yang pakai?
Ada sering.
Kalau kayak nama company misalnya kayak automatic terus suka nulisnya a28c.
Oh iya automatic.
Ada lagi kalau apa ya?
Ada terkait internationalization, localization, L10n.
Pertama kali liat istilah itu tuh di WordPress dulu banget, dulu bingung banget.
Kirain itu huruf i kan, kenapa ada leon, apa lion, apa apa.
L10n, itu localization.
Banyak juga ya ternyata ya.
Gak banyak sih baru lima.
Kalau Riza, R2a, R2a, R2a gitu aja.
Kayak kapa pendek gak perlu numeron, apalagi namanya tiga hurufnya yang kayak S1a.
Sama aja tuh tiga huruf.
Buat apa?
Oke, sebelum kita ngelantar kemana-mana, kita mungkin mulai dari apa sih itu,
apa aksesibility di ranah web, di lengkupnya web gitu.
Dan kenapa kita penting memperhatikan hal ini.
Ini kita siasin.
Nah, ini dia.
Aksesibilitas.
Nah, baca sendiri.
Terus kita ngapain?
Intinya adalah kita membuat aplikasi web ataupun website itu
harus mementingkan user experience atau pengalaman pengguna.
Dan pengguna itu juga kita gak bisa ekspektasi semua orang itu sama.
Kalau kita ngomongin performa, kita menganggap semua koneksi internet itu bagus, lancar.
Kita gak ngetes mungkin di kondisi yang agak sulit atau kadang nyala mati-nyala mati.
Begitu juga di aksesibilitas.
Kita tidak bisa menyamaratakan user, apakah user kita, asumsinya kita adalah user.
Jadi kita mendesain web kita itu hanya untuk kita.
Padahal sebenarnya banyak orang di luar sana yang mungkin dengan keterbatasan-keterbatasan,
salah satunya disabilitas.
Kesulitan membaca, misalkan dia rabun jauh atau rabun dekat.
- Jadi kita harus pastikan. - Buta warna.
Buta warna seluruhnya, buta warna sebagian juga ada.
Misalnya ada beberapa orang gak bisa melihat biru, gak bisa melihat merah juga.
Itu kategorinya banyak banget ya dari penglihatan, dari pendengaran,
bahkan dari anggota tubuh atau gerak.
Terus dari apa sih, kayak gangguan syaraf itu neurological kayak apa, epilepsi gitu.
Terus apa, gangguan namanya kognitif ya, kemampuan memahami, ya banyak lah.
Jadi itu sebisa mungkin kita bikin website ya, ya mungkin gak bisa 100% ideal,
tapi apa, semaksimal mungkin mengakumodasi user seluas-luasnya lah.
Sebentar, interupsi sedikit. Ini dari Rafki ada input bahwa audionya kecil.
Audio siapa yang kecil? Apa kita tiga-tiganya?
- Kita bertiga. - Salah satu.
Kalau tiga-tiganya berarti dari mana ya, dari YouTube seperti?
- Speaker. - Master, master.
- Speaker. - Volume speaker mungkin.
Kalau kita bertiga ya.
Salah satu mungkin boleh disebutkan siapa, jadi kita bisa gedein.
Oke, lanjut.
Tapi jujur aja, jujur aja saya belajar accessibility.
Kenapa saya harus belajar accessibility? Itu karena forced by law.
- Bisa dituntut ya. - Buat website-nya.
Terus kemudian company-nya itu punya salah satu requirement.
Webnya harus low-loss accessibility standard.
- AAA. - WCAG AAA.
WCAG AAA.
Jadi sudah, jadi project-nya requirement-nya itu.
Karena dia situs bank dan kalau...
- Bukan Indonesia. - International, jadi international bank.
Jadi cabangnya di mana-mana seluruh dunia.
Jadi accessibility itu penting.
Jadi salah satu, nggak cuma security, nggak cuma privacy.
Nggak cuma GDPR yang dipikirkan.
Tetapi accessibility juga salah satu poin penting.
Jadi ada performance, security, privacy, GDPR, dan accessibility.
Jadi itu mungkin kayak, itu ya kan di negara-negara, di banyak negara lain kan.
Apa sih, infrastruktur secara umum nih. Bukan digital doang.
Infrastruktur kan ada aturannya. Kayak misalnya di banyak negara.
Kalau kita bikin, apalah bank misalnya tadi contohnya Yvan.
Atau bahkan bikin toko, atau bikin apapun yang diakses banyak orang.
Kita itu harus menyediakan akses untuk defable.
Misalnya kalau contoh fisiknya kan wheelchair ramp ya.
Harus bisa diakses oleh customer atau user yang menggunakan kursi roda dan lain-lain.
Terus itu apa, itu mungkin bisa bisnis.
Kalau untuk layanan publik dari pemerintah jelas.
Banyak negara yang misalnya apalah trotoar.
Kayak harus ada jalur yang aman dilalui kursi roda lah, suna netra lah.
Jalur kuningnya itu ya. Jalur kuning itu khusus suna netra.
Bahkan pernah lihat sih kayak di beberapa negara Eropa.
Itu kalau misalnya ke stasiun kereta, itu di handle-nya.
Kayak di pinggirnya itu ada railing yang ada bril-nya.
Jadi itu penggantinya, itu semacam alternatif signage system yang kita lihat secara visual.
Nah, orang masyarakat yang punya gangguan penglihatan, suna netra.
Bisa mengakses informasi yang sama.
Jadi sekarang balik ke web kan banyak infrastruktur yang udah pindah ke digital.
Termasuk ke web ya.
Jadi itu hukum-hukum yang ada di luar sebetulnya kayak meneruskan aturan yang udah ada.
Cuma kalau di Indonesia tuh penasaran sih.
Ada hukumnya atau enggak sih selama ini di kita?
Kayaknya belum ada.
Kayaknya belum ada.
Tahu soal hukum, ada nggak hukum untuk aksesibilitas di Indonesia?
Bahkan yang fisik aja kalau di kita kadang ada trotor yang tiba-tiba bolong itu ada gallian.
Kayaknya nggak apa-apa deh, nggak ada yang dituntut, nggak ada yang kenapa.
Nggak juga sih, ada sih sebenarnya cuma nggak diterapkan.
Cuma lebih menarik untuk menanyakannya, pertanyaannya adalah apakah ada di Indonesia hukum untuk aksesibilitas untuk web?
Jadi web dan kontennya.
Kayaknya ini juga belum ada.
Ya kalau fisik aja belum kayaknya web lebih sulit.
Karena di luar pun digital itu kan sebenarnya sebagai kelanjutan dari fisik.
Jadi restoran atau bank atau toko harus menyediakan layanan tanpa mendiskriminasi customer yang punya kekurangan fisik.
Nah di web juga gitu kan.
Lebih tepatnya untuk tujuannya untuk equality ya.
Jadi semua pengguna harus mendapatkan informasi yang sama.
- Menyediakan akses ke semua orang. - Iya.
Nah ini kalau kita ngomongin tadi, kita udah sempet sebutkan kan.
Ada yang buta warna parsial, ada yang buta warna full, ada yang rabun jauh, rabun dekat gitu kan.
Itu masih, mungkin masih bisa lah ya.
Maksudnya teks kan kita bisa zoom in, bisa zoom out.
Warna pun kalau hitam putih pun sebenarnya masih bisa dibaca gitu kan.
Tapi coba bayangkan ada teman-teman kita yang tidak beruntung di luar sana,
yang bahkan tidak bisa melihat.
Nah aksesibility akan lebih berasa di sana gitu.
Dengan sebuah aplikasi atau web yang kita bangun dengan aksesibilitas yang bagus,
teman-teman yang bahkan tidak bisa melihat masih bisa menikmati aplikasi web kita gitu.
Ya apakah dengan menggunakan, kalau misalkan form gitu kan,
kalau kita tap biasanya apa yang terjadi ya.
Ada property, tap index ya.
Jadi kita harus menyusun bahwa, oh yang pertama...
- Nggak semua orang bisa menggunakan mouse, contohnya. - Betul.
Nggak semua orang bisa menggunakan mouse.
Jadi mungkin dia pakai tab, abis itu misalkan masukkan nama atau username,
abis itu dia tab password, abis itu dia enter.
Kalau kita tidak dengan hati-hati mendesain sebuah form aja,
yang kayak form login, ya kita bisa kehilangan satu user gitu.
Dan ini luas banget sebenarnya apa, scope-nya ya.
Bukan cuma yang Tuna Netra, biasa juga defabilitas bentuk lain.
Misalnya orang yang apa, gerakan, nggak bisa bergerak atau apalah ada gangguan motorik,
biasanya mereka pakai alat khusus entah yang pakai apa sih, mulut gitu.
- Greenreader bukan? - Bukan.
Ada namanya zip and puff device, itu dia pakai sedotan.
Jadi di tube sama di sedot atau bahkan pakai gerakan mata,
ada yang pakai gerakan kepala, ya macem-macem lah.
Intinya navigasinya pakai tab, udah gitu aja sih.
Jadi bahkan orang yang nggak defable sekalipun, misalnya kita pakai itu loh,
mechanical keyboard atau apalah keyboard yang enak gitu, yang ergonomis,
males kan udah keyboard-nya enak, kita harus gerak-gerak,
mindahin tangan ke mouse lagi, power user.
Jadi power user pun bisa sering navigasi pakai tab, nggak tahu gue doang.
Atau power user lain, kayak males lah mindahin tangan udah tab-tab aja.
Jadi itu macem-macem sih dari yang defable beneran,
ya pasti itu kan lebih utama fokusnya karena mereka nggak punya pilihan
sampai ke power user.
Kalau misalnya fokusnya ngaco, kita bikin elemen yang nggak bisa difokusin
atau urutan fokusnya ngaco, itu bakal nggak cuma ngurangin satu atau dua konsumen ya,
calon konsumen yang mungkin, mungkin kan temen-temen mikir
berapa banyak sih orang tunanetra atau apalah defabilitas yang pakai situs kita.
Tapi kalau dijumlahin di total, ya itu bisa mempengaruhi banyak orang sih.
Jadi bisa kehilangan banyak calon konsumen.
Balik lagi ke ekualitas tadi ya, kesetaraan.
- Sama ada tuh, ada link gue sambil dibuka, krep-krep effect, ya gimana event, sorry.
- Ada hal yang simpel aja ibu saya, matanya sehat dan mata tua ya,
jadi ibu saya sudah umur 70-an, dan mata tua,
jadi kalau misalnya mau baca web aja, kadang dia harus begini loh,
harus matanya micing-micing, itu berarti, dan saya lihat webnya ngapain sih,
mama baca web yang background-nya susah, sapi masih aja mau dibaca gitu.
- Ya pengennya, pengen baca itu gimana?
- Nah, berarti itu kan kita harus bisa di zoom in, atau harus bisa dipinch?
- Ya intinya, mobilnya, misalnya kalau dipinch, atau untuk di mobil,
bisa font-nya lebih kontras, warnanya dengan background, dan font-nya lebih besar,
bisa ada setting font, maybe, I don't know, ya.
Makanya kalau kayak, kalau nggak salah mobil, atau yang saya tahu Safari ya,
jadi nggak tahu, saya belum pernah coba di Chrome, dia ada mode reader mode kan,
semua background-nya bisa hilang, terus langsung cuma kontennya aja yang dibaca.
- Jadi kalau kontrasnya bagus, kekurangannya bagus?
- Itu untuk asesibilitas mata tua.
Dan itu sering lihat sih, ada beberapa UI artikel, misalnya biasanya artikel berita,
tolong read, kita bisa ngatur size font-nya, jadi bisa plus-plus, bisa kita plus,
bisa kita minus, nah lagi-lagi, kalau kita udah mikir aksesibilitas,
ini mempengaruhi banyak orang, bukan cuma orang yang misalnya tadi kasus mata tua,
atau matanya udah minus, tapi kan monitor orang size-nya lain-lain ya,
kalau misalnya kita lihat, kita bacanya di, apalah, iMac yang gede banget itu,
mungkin kita pengen ngecilin, karena terlalu besar juga sulit dibaca.
Kalau kita baca di HP, terus misalnya ada mata tua atau minus,
pasti kita pengen memperbesar, jadi di mana kita mempertimbangkan aksesibilitas,
itu bisa bikin experience-nya lebih bagus buat banyak orang.
Nah, itu kalau contoh fisiknya itu tuh yang di layar namanya cut effect.
Jadi jaman dulu, konon ada beneran kasusnya, di mana gitu tahun 70-an,
dulu trotoar kan semua nggak ada yang bagian landa gitu,
terus dibikin, jadi ada bagian yang melanda yang di tengah itu, yang ditandain merah itu,
biar orang yang pakai kursi roda bisa mengakses.
Nah, itu tujuan utamanya, karena kalau orang pakai kursi roda kan nggak bisa dipaksa
berdiri dulu, jalan dulu, kursinya diangkat turun.
Tapi selain target utama itu, ternyata banyak orang lainnya yang terbantu juga dengan fitur itu.
Jadi ya sebenarnya web sama aja prinsipnya kayak gitu juga.
- Oke. Tapi di Indonesia, di Indonesia yang saya perhatikan ya, terutama di Jakarta,
yang cut effect ini malah banyak-banyak, malah menjadi apa ya,
ada beberapa trotoar yang sengaja ditaro pancang gitu.
Iya, satu itu motor. - Biar motor nggak naik.
- Biar motor nggak naik. Kedua, pendagang kaki lima, dia bawa barangnya lewat situ.
Jadi, akhirnya pancang juga, akhirnya jadi nggak aksesibilitas.
- Nggak bisa. - Masih itu trik, sih.
Ngimbangin antara kebutuhan orang yang defable, misalnya kebutuhan yang kayak gitu tuh,
kursi roda sama menertipkan ya itu biar apalah motor atau apa nggak naik.
- Betul. Iya, kita kasih aksesibilitas yang bagus untuk jembatan penyeberangan,
malah motor yang naik kan. - Iya, itu juga salah gunakan.
- Nah, ini sulit di handle dari teknologi, karena ini human factor.
- Namun ada juga selain ini loh, mungkin supaya untuk melebarkan wawasan teman-teman juga ya,
nggak mesti juga harus kursi roda. Masih ada orang yang pakai tongkat, contohnya.
Atau yang sehat sekalipun, kayak saya seorang yang punya anak, itu bawanya, apa itu namanya?
Kereta dorong. - Stroller.
- Stroller. Itu kalau misalnya... - Iya, kan ada contohnya stroller di...
- Iya, kalau kita tinggalnya di hotel atau di... - Di mall, enak ya?
- Mall yang nggak ada aksesibilitasnya, susah loh.
- Ribet ya? - Ribet.
Tapi ujung-ujungnya yang apa namanya? Tapi stroller nggak boleh naik eskalator ya?
Harus naiknya elevator. - Oh, bahaya ya?
- Bahaya. - Bahaya mental.
- Makanya ada eskalator kan jadinya kan? - Itu buat bawa keranjang belanja biasanya kan.
- Oh iya. Tapi boleh kan kalau itu? - Boleh lah.
- Boleh ya. Oke. Nih, Audi ada, dia pakai ini, pakai salah satu fiturnya Android ya,
kalau nggak salah ya, digital world viewing ya. - Iya, digital world viewing. Iya, betul.
- Ini untuk mengurangi screen time ya? - Screen time.
- Kalau udah batu banget mah nggak mumpan. - Nggak mumpan.
- Kayak tuh nge-set apa, layar jadi greyscale, jadi hitam jati.
Maksudnya ya kan, biar visual kan nonton video atau apa. - Biar males.
- Jadi nggak menarik. Tapi, ada tapi ya kalau emang orangnya bandel.
Jadi ngebaca, ngebaca artikel yang di safe di pocket atau apalah kan nggak ngaruh kan.
Masa yang baca tetap oke-oke aja. - Boleh lagi, teknologi hanya bisa membatasi
sampai tahap tertentu. - Kalau udah human factor, nggak bisa.
- Saya juga biasanya handphone itu diset ke greyscale.
Tapi akhirnya macamnya di laptop sama aja. Screen timenya pindah ke layarnya yang lebih besar.
Dan di laptop kan biasanya ada tuh yang pakai apa namanya, istilahnya yang mengurangi blue light ya.
Flux ya. Lama-lama udah nggak dipakai. - Human factor.
- Nggak ngaruh. Nah, ini ada pertanyaan nih dari Muhammad Amrikom Tidar.
Gimana cara kita measure good accessibility web sejauh ini baru kelihatan dari Chrome DevTool masih terbatas?
Nah, kita ngomongin terus. - Nah, ini bagus nih bridging ke.
- Bridgingnya pas ya. Kita ngomongin terus yang mana dulunya.
- Mungkin WCAG kali ya. - WCAG dulu, ya. Jadi ada standarnya dari web accessibility
- Jadi ini bagian. - Accessibility guideline. Web content accessibility guideline.
- Ini yang bikin adalah WAI. WAI itu panjangan apa, lupa web accessibility, blablabla.
- Inisiatif. - Inisiatif. Nah, ini kelompok kerja yang merupakan bagian dari si W3C itu.
Kayaknya kita dulu pernah bahas ya soal standar. Jadi apapun yang di web, semua feature web itu, web API, blablabla,
itu kan bukan milik satu perusahaan tertentu, tapi kayak standar POD lah yang mendiskusikan dan merumuskan spesifikasi.
Yaudah, jadi sebenarnya ini soal accessibility, ini juga bagian dari si W3C itu. Jadi WCAG itu merupakan technical standards.
Jadi kalau accessibility sendiri, itu ternyata web accessibility itu nggak bisa di, ya itu kan kita dituluh human factor,
tergantung user kita siapa, tergantung feature-nya gimana. Jadi accessibility itu ya nggak bisa dimesure secara,
itu cenderung subjektif dan nggak bisa dimesure secara seragam. Itu harus user testing, blablabla.
Tapi ini bisa dibuat technical standard untuk minimal mengcover hal-hal yang bisa dimesure atau dikontrol secara teknis.
Nah, makanya lahir si WCAG itu. Makanya tulisannya kan bukan web content accessibility, apalah misalnya,
accessibility acceptance atau apa, tapi sekedar guideline, kayak panduan aja.
Kalau misalnya kita ngikutin item-item di guideline itu, maka ya lebih besar kemungkinan situs kita accessible.
Jadi kalau misalnya WCAG aja nggak bisa fail, itu ya hampir pasti nggak accessible.
Walaupun udah ngikutin WCAG sepenuhnya, ya tetap ada faktor-faktor yang,
faktor subjektif yang bisa bikin mungkin nggak accessible, misalnya contoh yang paling gampangnya,
ada alt text, tapi alt text-nya ngaco. Ya pasti kan? Apa?
Itu nggak accessible ya namanya, karena user yang livable nggak bisa mengakses seperti orang lain yang...
Tetapi pas.
Tapi kalau fail semua, itu kan bisa pas, tapi belum tentu accessible.
Tapi kalau fail semua, ya udah jelas nggak accessible.
Image, SRC, blablabla, ALT, gambar. Orang udah tahu itu gambar.
Oke, ini guideline-nya ya, ada audio, ada caption, ada macem-macem ya.
Ini technical standard. Jadi kalau misalnya hukum yang tadi Ivan bilang bisa dituntut, itu patokannya standard ini.
Kan nggak mungkin ya kalau hukum mau oncarin si customer-nya satu per satu, ya hukum nggak bisa gitu.
Harus pakai patokan yang objektif dan tertulis. Nah, ini fungsinya standard.
Makanya waktu requirement adalah pass accessibility level AAA.
Jadi itu kan ada level A itu. Level A, kamu scroll ke bawah dikit.
Ya, untuk yang masih tentang captions.
Kayak baterai nih, ada A, ada AAA, ada AAA.
Jadi A itu yang paling dasar banget, AAA itu yang menengah, yang sedeng lah.
AAA itu yang paling strict. Jadi dari paling linian, paling santai sampai paling strict.
Nah, kalau bagi teman-teman yang umum, yang biasanya ini bisa pakai lighthouse juga, ada accessibility ya.
Itu yang common, dia akan ngetes hal-hal yang common.
Yang paling low hanging root lah, itu kayaknya agak keterlaluan kalau nggak ikutin.
Tapi itu simple, kayak contrast warna, itu kan masuk lighthouse.
Ya, text, terus image dan iframe juga harus ada title.
Sekarang udah cukup banyak ya, tools-tools atau plugin yang bisa membantu.
Misalkan kita bisa install eslin ya, kalau nggak salah ya, untuk memastikan bahwa misalkan image itu
harus ada alternate text-nya, terus ada misalkan apa lagi ya?
Banyak. Jadi kalau buat development process nih, pas lagi kita bikin nulis kodenya,
itu rata-rata berdasarkan XAXA, itu ada library-nya sendiri buat deteksi common mistakes.
Nah, ini kan Chrome extension buat ngecek website pas udah jadi, pas develop,
ada eslin plugin accessibility, ada.
Terus?
Oh, jsaccess ini.
Eslin plugin, lupa namanya apa ya?
Eslin plugin accessibility. Nah, ini dia.
Eslin plugin jsxaccessibility.
Ini?
Iya.
Terus biasanya sih, kalau udah punya testing workflow, ya dimasukin ke testing workflow aja sebaiknya.
Kalau belum punya testing workflow, sebaiknya punya.
Jadi kayaknya apapun yang major nih, misalkan kita pake Jest atau Vitex,
atau kalau misalnya itu nnya C-Press, ada semua sih.
Nah, kalau misalkan kayak ini nih, ARIA roles ini, ini sebenarnya fungsinya buat apa?
Nah, macam-macam sih itu. Itu kalau kita menggunakan elemen yang bukan seharusnya.
Jadi, kan, sebaiknya kita utamakan elemen natif, maksudnya natif, itu built-in dari sono-nya.
Semantik.
Misalnya button, ya udah kita pake button aja.
Jangan pake link.
Jangan pake link, dikasih on-click, dikasih prevent default, jangan pake div.
Jadi, sebisa mungkin pake button.
Udah kita gak perlu ARIA role, se-simple itu.
Tapi kalau misalnya, entah karena alesan apa, kita pake elemen lain,
kita harus kasih ARIA role sama dengan button, biar assistive technology paham itu button.
Contohnya untuk yang pake ARIA role itu yang kayak tab content atau accordion.
Jadi kalau ARIA role itu tab content, role-nya yang parent-nya itu tab content,
dan yang child-nya itu jadi tab item.
Jadi, kita memberitahu alat assistive technology, oke, ini adalah sebuah komponen yang ada tab-nya.
Bisa dipindah tab-nya.
Di pencet-pencet, exact.
Di nothing gate, bahasa di nothing gate.
Itu keren sih, itu menarik konsepnya, karena biasanya kalau kita gak pake ARIA,
kan kita mengkomunikasikan itu secara visual ya.
Kalau misalnya kayak accordion, pasti atasnya tab-nya itu ada border-nya,
ada kayak shading background warnanya secara visual.
User rata-rata tahu bahwa kalau misalnya kita klik tab itu, kotak bawahnya, content-nya bakal berubah.
Itu kan konseptual yang dikomunikasiin secara visual.
Nah, itu cuma kalau screen reader kan gak bisa tuh, gak ngerti itu.
Jadi, kita harus kasih tahu pakai ARIA role.
Oh, oke.
Itu ada contohnya ARIA role saya kasih di chat.
Tab role, nah, jadi pakenya, karena tab-nya itu bisa jadi,
yang bisa diklik itu mungkin div-nya atau heading-nya atau button-nya,
kan kita gak bisa pastiin, tergantung desain, ya kan?
Tapi kita bisa, jadi ada tabs dan tab list contohnya, ada tab.
Jadi, bisa ngasih tahu bagian mana yang...
- Clickable? - Iya, bagian dari kayak susunannya.
- Fungsinya buat apa gitu, div itu kan kosongan kan, bisa dijadikan apa saja gitu kan.
Kita mau jadikan button bisa, kita mau jadikan invisible, apa?
Sesuatu yang tidak terlihat juga bisa gitu kan.
- Cuma kayak apa ya? - Dan ARIA role ini,
bisa didetek juga dideteksi sama si Lighthouse.
Jadi, kalau salah satu bagian yang komon juga,
yang teman-teman harus bisa pas dari Google Lighthouse test.
- Menarik ya, jadi ARIA role ini bisa mengkomunikasikan perannya entah basic elements,
kayak tadi itu button yang paling simpel,
bahwa kalau div ini perannya seperti button,
tapi bisa juga hal-hal yang konseptual kan kayak tabs kan,
sebenarnya kita di HTML juga gak ada elemen khusus buat tabs,
tapi biasanya itu dikomunikasiin secara visual bentuk tampilan akordeon,
apalah tab interface, tab list ini bisa dikomunikasikan juga pakai ARIA,
biar user yang gak mengakses secara visual tetap bisa paham.
- Nggak banyak lagi sih, role-role, table contohnya, timer, toolbar, tooltip, terlalu banyak.
- Nah, mungkin teman-teman yang belum tahu kenapa banyak ARIA-ARIA ini bukan ARIA rajasa atau ARIA-ARIA lain,
bukan juga, ARIA ini kepanjangannya apa ya, lupa, coba ntar cari.
Jadi intinya, ini adalah atribut khusus untuk aplikasi yang cenderung interaktif,
sering kita bahaskan web dulu, dokumen doang nih, cuman artikel, text artikel, image, link, ya udah.
Makin lama, makin banyak client-side interactivity, interaksi yang pakai JavaScript,
kayak tadi akordeon di-clicktap, kita nge-clicktap, kontennya berubah.
Nah, ini kan terlalu rumit untuk di-cover oleh elemen semantik begitu aja kosongan,
jadi dibuatlah segala ARIA-ARIA-an ini untuk equivalentnya untuk screen reader atau assistive technology lainnya.
Jadi kayak misalnya ada, tadi kan ARIA-Role, ada juga ARIA-Live, ARIA-Live itu untuk kayak misalnya ada pop-up,
jadi pas awal di DOM gak muncul nih, tiba-tiba ada yang muncul, tiba-tiba ada elemen baru muncul.
Kalau user yang pakai screen reader kan, kalau misalnya tabbing fokusnya udah lewat bagian itu,
kan gak tau, tiba-tiba ada misalnya notifikasi, apalah, Anda akan otomatis terlockout setelah karena tidak active selama sekian menit misalnya,
atau apa, tiba-tiba ada promo, potongan harga pas segi belanja atau lainnya.
Nah, biar user yang pakai screen reader bisa tau, ada elemen baru muncul, itu pakenya ARIA-Live contohnya.
ARIA itu panjangannya Accessible Rich Internet Application.
Oh iya, mantap.
Ini ada salah satu contoh web yang cukup, accessibility-nya cukup bagus, yang sering kali tidak sengaja saya ke pencet gitu ya,
kalau misalkan teman-teman buka GitHub gitu kan, kalau pencet tab, itu dia ada, kita bisa navigasi tanpa harus menggunakan mouse.
Nah, ini langsung ada skip to content, jadi misalkan kita lagi berada dimana, terus tiba-tiba saya mau lihat kontennya dimana gitu kan,
itu juga hal yang sebenarnya penting, walaupun jarang kelihatan gitu kan.
Dan lebih penting lagi, kalau pakai screen reader kan, soalnya itu kalau kita visual kan tinggal scrolling,
walaupun pakai keyboard ya tinggal pencet panah ke bawah aja ya, kalau screen reader kan kuda baca satu-satu tuh,
setiap ganti halaman, by default setiap pencet tab ini navigasinya dibaca satu-satu, product, solutions, blablabla.
Nah, bosan kan kalau emang cuma pengen baca, user sudah masuk ke halaman sekian,
cuma langsung pengen baca isi utama halamannya, ya dia bisa pakai skip to content itu.
Ya, betul. Nah ini menjawab pertanyaannya dari Mohamad Ambrikom lagi yang barusan.
Ya, salah satunya GitHub itu aksesibilitasnya bagus.
Oke, kita lanjut lagi tadi bahas tentang tools, tadi kita udah bahas...
Eh, di Indonesia tadi pertanyaannya, ada yang tau nggak?
Di Indonesia ya, oh di Indonesia, ya mungkin ada yang tau aksesibilitas yang bagus.
Aku tau, coba chat tolong jawab ya kalau ada yang tau.
Klik BCA bagus nggak, klik BCA?
Mau komen nih.
Tapi kalau pengen lihat di luar Indonesia sih,
kalau Indonesia kan kita nggak ada yang tau nih ya,
cuma kalau yang di luar, pengen lihat contoh yang bagus itu website pemerintah,
pemerintah beberapa negara yang emang punya divisi, kayak semacam divisi aksesibilitas digital.
Kalau yang aku tau, UK sama Netherlands.
Negara lain mungkin ada sih, cuma nggak terlalu meretin.
Yang paling nyenangin dilihat tuh UK sama NL.
Sambil cari ya.
Oke, tadi kita udah bahas tentang tools ya.
Kita balik lagi sebelum melihat contoh-contoh.
Tadi kita bahas switch AIG, terus kita juga tadi bahas tentang Lighthouse.
Ada beberapa aksesibilitas yang bisa kita improve di sana, yang long-hanging fruit, yang gampang gitu ya.
Ada beberapa Chrome extension.
Seperti X ini.
Kan tadi ada yang tanya tuh gimana cara measure-nya.
Kalau dalam proses development masih lagi ngoding, itu tadi udah ada di S-Link.
S-Link.
S-Link ada, terus digabungin, dijadikan satu sama test suite.
Entah kita pake JS atau C-Press atau V-Test dan lainnya.
Kalau pake storybook juga ada.
Kalau pake storybook enak tuh.
Ada panelnya sendiri yang menunjukin aksesibility issues.
Menarik.
Gimana-gimana, Yufan?
Dari itu ada yang gue bisa tunjukin yang ada aksesibility-nya.
Ada add-on-nya ya, berarti? Ini nggak otomatis di-install ya?
Jadi harus cari add-on-nya dulu ya?
Sebenarnya versi yang baru udah otomatis deh.
Ada panelnya di bawah.
Jadi by default, storybook tuh come with beberapa add-on gitu.
Sekarang, kalau dari starter storybook yang offisial, itu udah ada sih langsung.
Ya walaupun itu berupa add-on.
Ini yang dari Project WordPress untuk storybook-nya si Gutenberg.
Jadi ada komponen-komponennya, sudah ada storybook.
Nah, bagi temen-temen yang belum tahu, WordPress punya block editor namanya Gutenberg.
Jadi semua komponen yang ada di block editor itu ada di storybook ini.
Itu ada tab aksesibility-nya, sudah ada plug-in-nya.
Oh, sudah ada yang berhasil tes ya, testing-nya ya.
Nah, kalau kita bikin yang nggak lolos itu, nggak lolos, cek kan ada di violations-nya.
Memang ini pasti violations-nya lolos mula ya.
Kalau nggak lolos, nggak bisa di-merge PR ya.
Oh, iya.
Oke, ini ada card, ada 15 tuh.
Yang di-check adalah area role, area hidden element, area attribute, macem-macem ya.
Banyak sekali.
Nah, kalau website-nya udah jadi dipublish, kita nge-check conference-nya mah gampang.
Itu tadi pake Chrome extension.
Ada banyak ya, ini salah satunya aja ya.
Ada X, ada Wave, terus Microsoft begin juga.
Gue paling suka pakai yang Microsoft ya.
Microsoft itu kelebihan-nya ya Chrome extension buat web ya.
Cuma mereka punya toolkit juga buat native OS app.
Nah, cuma belum pernah pakai sih, cuma lihat, cuma tahu aja.
Jadi apa?
Iya, install aja. Install aja masih bisa.
Add to Chrome.
Nah, ini kan untuk web. Nah, mereka juga punya buat kalau kita develop Android atau apa? Windows app.
Jelas nggak ada buat iOS app.
Oke.
Coba aja tes salah satu.
Tes salah satu.
Iya, apa, situs apa gitu.
Oke, ini ya.
Ini ya, ini.
Itu dia, iya. Karena nanti bisa fast-pass dia.
Liatan nggak?
Wah, nggak kelihatan ya.
Bisa install Chrome extension ya?
Bisa dong.
Oh, karena Chromium.
Chromium Base.
Ini dia, ada error tuh.
Ini dia error-nya.
Nah, enaknya Mas Lisa bisa, kalau tadi dia bisa layering sama hasil webnya, jadi bisa lihat yang mana.
Di highlight-nya biasanya.
Di elemen yang bermasalah.
Oke, oh, jadi spesifik di komponen atau di elemennya itu ya.
Terus ada, yang nomor 2 kan ada tab stop tuh, di sebelah kiri.
Bisa lihat, cek tab stopnya, sudah.
Oke, tadi yang di tes website apa ya?
Ini, web.dev ya.
Web.dev tentang accessibility punya ada sedikit isu dengan accessibility.
Tapi itu kelihatannya minor isu.
Minor-minor ya, nggak ada yang merah-merah kan.
Yang merah cuma 2.
Need review.
Color contrast.
Oh, hitam ya.
Kita lihat lagi ya.
Share screen, window, ini dia.
Warnanya agak gelap kali ya.
Sama link-nya biru umu.
Kurang terang.
Nah, yang buat teman-teman mau belajar accessibility bisa ke sini ya, web.dev/learn/accessibility.
Mengkap gratis.
Mengkap gratis.
Bisa diikutin aja, tahapan-tahapannya semua ada mulai dari HTML.
Content, dokumen, keyboard focus, javascript, image, animation, typography, video, audio, form.
Sampai assistive technology.
Minimal konsep-konsepnya, paham dululah.
Walaupun mungkin kalau ya prakteknya in reality nggak semua perusahaan atau tempat.
Atau kalau kita freelance ya, kita nggak mungkin, mungkin kita nggak punya resource buat apa itu kayak manual accessibility testing ya.
Oke lah, kalau nggak bisa nggak apa-apa, tapi minimal kita paham. Jadi kita paham semua konsepnya.
Ini berguna juga sih kalau pengalaman pribadi aku adalah selain kayaknya dari pengalaman pribadi ya,
kalau di Indonesia terutama, selain web.dev terutama yang ke front-end, front-end-an,
itu kelihatannya orang lain nggak ada yang tahu sama sekali konsep ini.
Jadi akibatnya apa kalau yang konkritnya, kita dapat dari designer itu kayak ukuran atau warnanya itu nggak lolos WCAG semua.
Tapi kita bisa mengedukasi kenapa perlu gini, terus dampaknya misalnya kalau Lighthouse. Sekarang enak nakut-nakutin kolega atau teammate kita.
Lighthouse kan emang punya kriteria aksesibilitas konon, suatu saat ke depannya itu bakal bisa jadi pertimbangan SEO juga, walaupun belum sih.
Tapi itu apa, kita bisa bilang bahwa ini hal yang memang sudah dianggap penting oleh Lighthouse.
Termasuk misalnya kenapa kita harus bikin elemen model atau pop-up dialog, itu kita harus ada fokusnya.
Kadang kan designer atau mungkin anggota tim lain nggak suka tuh kenapa pinggirnya, kenapa luarnya ada bordernya.
Kita jelasin bahwa ini emang penting. Terus misalnya kita mungkin teammate kita atau teman kita atau kita mungkin dapat kode yang bukan ditulis kita,
legacy codebase yang pakai library yang nggak aksesibel misalnya, nggak bisa tab atau fokusnya ngacau semua, kita perlu nge-fix itu, kenapa kita bisa ngejelasin itu sih.
Kepatnya minimal kalau kita udah paham dasarnya, kita bisa mengkomunikasikan itu dengan baik.
- Oke, mantap. Oh iya, akhirnya saya menemukan salah satu contoh web yang di Indonesia yang aksesibilitinya bagus.
- Hore, apa itu? Web nya saya sendiri? - Bukan, ini ada komunitas ternyata, komunitas aksesibilitas.
- Bagus nih, kayaknya mereka tuh punya weekly atau nggak tau mingguan atau bulanan.
- Ada meet up ya, mereka ada meet up ya. - Pernah jadi itunya soalnya, pernah ngomong di meet upnya.
- Siapa yang sering ngomongin aksesibilitas di Indonesia ya? - Dan ini kayaknya apa?
CEO atau apa atau leadernya, namanya Suarez ini namanya Mbak Rahma kalau nggak salah. Pernah jadi speaker di acara apa ya itu dulu.
- Pernah, saya pernah satu panggung juga. - Yang jamannya Mas Johan, pas lagi online semua itu.
- Ya itulah punya ada... - Uncon. Jadi kalau teman-teman mau tau lebih lanjut bisa gabung di komunitasnya alai.
- Alai ID. - Alai ID susah ya.
- Alai ID. - Ini ada diskusi sharing bulanan.
- Nah ini ada YouTube-nya ya, karena online kali ya. - Dan kerennya mereka sih, maksudnya yang bagus.
Hal yang bagus mereka itu beneran berurusan punya networking-nya sama user dan developer yang memang defabilitas.
Jadi kalau kayak kita ini di sini kan kita ngeliat ini dari perspektif web dev in general ya sebagai seorang developer web
yang paham tentang WCAG yang mana itu standard teknis, tapi kan ya bisa tau caranya pakai screen reader defaultnya Mac.
Oke lah tau cara pakai voice over, cuma tetap perspektifnya beda sama yang di lapangan, dari perspektif user yang defabel beneran.
Dan Suarice ini kerennya mereka emang punya jaring dengan user yang emang beneran defabel.
Oke. Nah ini ada pertanyaan bagus lagi nih, gimana cara menyeimbangkan antara keinginan bisnis, kebutuhan bisnis dengan accessibility?
- Ada yang punya pengalaman mungkin? - Punya, jadi begini, dari, kan accessibility itu luas ya, intinya dari sisi yang common mistake
atau common pitfall mengenai implementasi accessibility kita sudah cover dulu deh, yang misalnya kayak area label, area text, area role,
terus kemudian color contrast, nah yang paling sering mengenai design ya, mengenai design itu paling banyak slacknya itu dalam mengenai color contrast.
Jadi pengennya warnanya begini, textnya begini, sebenarnya kalau mata sehat baca itu fine gitu, biasa aja bisa gitu, apalagi kalau misalnya phone-nya besar.
Ya, misalnya bagian yang masalah itu heading, tetapi kalau phone-nya yang kecil mungkin jadi masalah dan ditangkap oleh sama WCAG checker,
accessibility checker oleh tools-tools mana gitu ya.
Kalau bagi saya, waktu kasus saya, saya langsung ini, apa namanya, langsung bilang terus terang, ini desainnya color contrast-nya nggak pas dengan accessibility test-nya gitu, apalagi khusus untuk...
Saya bilang ini saya udah contohin pakai Lighthouse ini kena nih sama Lighthouse, jadi kalau kena di Lighthouse nanti kena juga di search console,
bakal muncul tuh nanti warning-nya di search console, dan kebetulannya dia situs berita ya, jadi situs berita dan CEO merupakan...
KPI.
KPI penting gitu ya, jadi hal yang penting secara bisnis, jadi saya bilang accessibility itu mungkin sekarang belum masuk dari sisi CEO,
tapi kapan masuk saya nggak tahu, namun kalau sudah bisa dideteksi oleh Lighthouse dan sudah masuk ke search console, itu sudah bisa menjadi dalam waktu dekat,
soalnya bisa jadi. - Suatu hari saja jadi pertimbangan. - Kenapa? Kita cuma selisihnya sedikit gitu, maksudnya antara orange color dan putihnya dia itu kurang matching gitu,
tinggal dikit aja di adjust, mau nggak pakai color orange yang slightly different atau pakaiin, mungkin dia di, apa namanya, di...
kan ada, kemarin kita bahas color ya soal lightness dan saturation, lightness-nya diturunin sedikit, misalnya supaya text-nya lebih kontras,
jadi karena secara score dari sisi color contrast dia cuma diambang batas gagal, ya dinaikin dikit aja gitu, tapi dari sisi designer,
wah ini sudah approve design, terus kemudian kalau misalnya diroba harus approve lagi, ya udah, do your job, do your job.
Jadi saya kasihnya begitu, jadi dan akhirnya mereka ngasih tau reasoning-nya saya itu dan dibawa dan akhirnya di approve, ya udah.
Itu secara kasus yang kita menang secara developer, mau ngasih tau, namun kalau awnan-nya keke, ya sudah lah.
Yang penting untuk hal yang lainnya pas, kan ada banyak ya, untuk hal yang lainnya pas, jadi bayangkan sebuah link aja itu ada state-nya loh,
hover state, visited state, kemudian default state, active state, itu ada banyak.
Jadi jangan sampai hal-hal yang hover state, active state, visited state-nya itu nggak accessible juga, hal-hal yang seperti.
Jadi masih ada bahasa Eka-nya, low-hanging fruit yang lain, yang bisa kita penuhi, jangan terpaku sama satu hal yang gagal.
Kalau misalnya ada satu atau dua point, ya oke lah, maksudnya jangan sampai hal itu yang menyebabkan kita berantem dan akhirnya web-nya nggak maju-maju.
Jadi bisa, banyak-banyak hal yang bisa kita perhatikan yang lain.
Dan sebetulnya kita sebaiknya bisa mengedukasi kolega atau tim kita bahwa ini nggak bersebrangan juga sih antara kebutuhan bisnis sama aksesibilitas.
Karena gampangnya kan kalau yang kasus ekstrim, Ivan tadi kalau nggak aksesibel malah dituntut, itu kan jelas, itu ada kepentingan.
Itu jelas, itu dari sisi desain sudah confirm, memang dia sudah tes, jadi udah nggak ada masalah di sana.
Itu ma, justru dari atasannya yang mengharuskan kan, itu udah nggak ada masalah sebenarnya.
Ya maksudnya itu kan kasus ekstrim semua faktornya ya, maksudnya semua elemen aksesibilitas.
Nah terus yang kedua, nilaiar kedua masih ekstrim juga, ya makin banyak yang bisa menggunakan situs kita dengan enak, dengan nyaman,
kan makin banyak, apalah makin banyak yang beli atau makin banyak yang baca, apalnya itu akan membantu makin banyak kita juga.
Nah itu bisa. Terus yang ketiga, apa, makin confirm ke WCAG minimal, makin bagus Lighthouse Core kita.
Ya itu layer-layernya. Nah terus keempat ya pasti kalau yang udah, kalau apa sih, syarat aksesibilitas yang lebih rumit,
ya butuh waktu misalnya. Nah tapi kan kadang waktunya ya sebenarnya waktu developmentnya tetap nggak butuh apa ya, nggak butuh perubahan yang ekstrim.
Kayak dari hal simple, misalnya kita sebagai developer, kita pakai aria rolling tepat, kita pakai elemen yang semangatik.
Itu kan ya sebetulnya nggak nambah waktu development yang terlalu banyak.
Nah tapi mungkin ada, bakal ada masalah kalau itu tadi kode yang nggak kita kontrol atau legacy code.
Ya kalau itu sih subjektif ya, tergantung misalnya kita bisa negol bahwa kalau lagi ada,
kalau lagi nggak banyak kerjaan, kita bisa minta waktu sedikit untuk memperbaiki lah refactor itu sedikit.
Itu kan nggak bertentangan yang sampai nggak ekstrim yang kayak ngorbanin misalnya kita jadi nggak bisa release ini sama sekali karena belum sepenuhnya aksesibel.
Mungkin ya jangan se-ekstrim itu tapi sebisa mungkin kita integrasiin kebutuhan aksesibilitas sedikit-sedikit dan tetap dengan mendukung kebutuhan bisnis.
Ya tergantung ini juga kali ya, kalau saya sih pernah mengalami tapi bukan dari ranah web juga,
cuman lebih ke konten. Saya punya beberapa online course video kan, terus tiba-tiba ada yang beli dan dia japri katanya dia itu tidak bisa mendengar.
Jadi butuh caption bahasa Indonesia. Dan sekarang sih terakhir saya lihat di YouTube itu atau generated caption yang berbahasa Indonesia itu udah cukup bagus.
Terutama yang teknis ya, kita ngomongnya nyampur-nyampur kayak misalkan note, itu kan bahasa Inggris. Itu dia bisa nangkap itu.
Tapi dia bisa paham, oh nice.
Bagus, udah bagus sekarang. Tapi beberapa tahun yang lalu masih ngaco, akhirnya karena permintaan satu orang ini dan dia bilang temen-temen saya yang disabilitas juga banyak.
Banyak yang bakal beli katanya gitu kan. Akhirnya ya udah, mau tidak mau saya harus mengeluarkan uang lebih untuk hire orang untuk bikinin subtitle.
Mulia sekali.
Tapi kan itu pertimbangan bisnis juga, ada unsur pertimbangan bisnis.
- Salah satunya itu namun bagi saya itu adalah hal yang benar untuk dilakukan.
- Iya maksudnya karena kita tidak berada di posisinya dia, kita nggak kepikiran itu gitu.
Ngapain sih pakai subtitle segala gitu kan. Kita asumsinya orang itu ya udah belajar-belajar aja gitu.
Kita nggak memikirkan bahwa oh dia ada kekurangan ini, ada kekurangan itu.
Jangan-jangan nanti videonya, ilustrasinya mungkin kurang besar atau gimana. Kita nggak mikirin kalau tidak kejadian seperti tadi gitu.
Akhirnya itu yang membuka mata, oh ternyata ini butuh gitu.
- Nah terus gitu ada efek. - Nah kalau ada design slide, presentasi aja harus mikirin yang paling belakang.
- Yang nonton dari HP.
- Yes, yang nonton dari HP. - Terus slide-nya kan bisa, misalnya slide-nya di posting nih di Youtube atau platform lain.
Kadang atau apalah di platform slide apapun, kadang kan ada orang baca dari HP, berarti harus kelihatan.
Dan itu card cut effect itu berlaku lagi tadi, misalnya videonya di caption nih, video kursusnya di caption.
Terus kadang orang lagi di tempat umum, di luar, males ngeluarin earbud atau earbudnya atau baterai habis atau apalah.
Kan sekarang udah ada captionnya, orang bisa ngeluarin HP, bisa ngereview, bisa lihat kursusnya.
Jadi itu kan pertimbangan bisnis yang positif juga ya, itu jadi feature product.
Nah tapi itu tadi kisah sukses kan, kalau aku ada kisah gagal, gagal tanda kutip.
Jadi ngerjain website yang, platform yang banyak content user generated, termasuk image, user bisa nge-upload image.
Nah ini kan agak tricky ya, sekarang kalau kayak Twitter atau mungkin Facebook ya, pokoknya kalau website besar,
itu kan bisa nambah feature menyuruh user mendeskripsikan image-nya, biar ada alt text yang akurat.
Cuma kan itu feature terpisah sendiri, gak dapet buy-off untuk nambahin feature itu.
Yaudah akhirnya mau gak mau, kurang accessible di bidang itu.
Jadi yang image yang pertimbangan lainnya sempet sih kepikiran apa misalnya auto, pakai machine learning gitu, nge-parsing.
Sekarang bisa AI generated, bisa langsung.
Nah cuma kalau yang free, nyari yang free, kayaknya gak ada yang akurat, sulit.
Nanti malah kalau misalnya isinya ngaco, kayak banyak text-nya kan, itu screen reader-nya bakal ngebaca semua dan gak bermakna.
Dan itu malah tambah gak accessible ya, merusak UX. Akhirnya disepakatin semua pake alt text-nya empty string aja biar di-skip oleh screen reader.
Jadi kurang accessible, tapi minimal gak memperburuk experience buat screen reader user.
Kalau gak salah yang pernah denger, Chrome bisa ada auto, misalnya untuk screen reader dia bisa bacain kalau misalnya kita gak ada alt text-nya, dia bisa ngasih tau itu image apa, by core.
Saya lupa, malah pernah denger, tapi Chrome-nya mana ya.
Sanggih juga ya, dia bisa menebak, ini kira-kira gambar apa gitu ya? Gambar menyerupai kotak gitu misalkan.
Iya betul nih Damar, sayangnya YouTube live belum ada, belum bisa, belum mampu ya.
Kalau live belum, yang rekaman, ini misalkan kita kan lagi live, mungkin 2-3 hari berselang itu udah ada versi rekamannya, itu bisa dinyalain.
Bisa, oh.
Dan hasilnya lumayan.
Google Meet aja, udah ada caption-nya kan.
Oh iya, tapi bisa bahasa Indonesia?
Tapi gak co. Ada linknya tuh.
Oh coba share.
Mari kita share.
Jadi ada image description on auto off dari Google, Chrome.
Cuma belum pernah nyoba saya ya, cuma pernah denger.
Image description are available in Indonesia.
Wow.
Wow, nice.
Gimana caranya? Windows, shift F10.
Oh gak bisa?
Ini untuk yang image yang gak ada description-nya, dia bisa bacain.
Jadi kalau kita tap ke image itu, voice over, dia bisa bacain itu apa.
Jadi harusnya yang ada gambarnya gitu ya?
Khusus image description kan?
Oh iya iya iya.
Belum pernah nyoba saya, belum pernah nyoba nanti.
Ini gambar bukan?
Bukan ya? Oh iya ini gambarnya.
Shift F10.
Bukan harus diaktifkan dulu.
Oh diaktifkan dulu. Cara aktifinnya gimana?
Itu?
Turn on image description for all pages for just one specific page.
Open context menu.
Open context menu-nya.
Terus kemudian.
Terus?
Gak ada kan, langsung kan?
Ini langsung, search image, gak ada.
Oh berarti, mungkin harus diaktifkan dulu.
Click kanan ya?
Ini klik kanan ya? Coba klik kanan.
Udah tadi, ini klik kanan.
Gak kelihatan kita kalau masukin.
Oh gak kelihatan ya?
Ya gak muncul sih.
Ya udah, coba aja teman-teman kalau ada yang bisa.
Siapa tahu ada yang bisa?
Share entire screen.
Nah kalau share entire screen baru bisa.
Screen section dulu.
Nah ini klik kanan.
Saya ke ini dulu.
Setting accessibility-nya masuk ke setting dulu.
Chrome setting, accessibility.
Setting, accessibility.
Terus ada image description.
Ada gak tulisannya?
Accessibility, live caption, caption preferences, show quick highlight.
Mana? Gak ada.
Gak ada image description?
Gak ada, belum ada. Di tempat baru live caption.
Mungkin beda kali ya?
Gak, ini chrome juga belum ada.
Live caption, caption preferences, show quick highlight, navigate page width, text cursor.
Ada opsi ini, add accessibility features from chrome web store.
Apa harus install extension?
Ya sudah, teman-teman coba sendiri aja.
Kapan-kapan lagi?
Mungkin gak ya, mungkin aja.
Perusahaan sosmed yang push user untuk menambahin alt text sekalian buat train.
Kayaknya di Facebook mereka mencoba untuk otomatis ya.
Mungkin blog image.
Justru kalau Facebook kebalikannya kayaknya, user gak disuruh nambahin alt text.
Facebook-nya punya AI sendiri kayak indies photo, titik 2, one human, one house.
Jadi dia memudahkan kita untuk masuk dengan cepat gitu kan.
Upload image dengan cepat biar banyak kontennya gitu kan.
Dan dia coba mengantisipasi dengan cara bikin AI-nya, termasuk juga translate kan.
Otomatis ditranslasikan.
Nah, terus kalau balik ke pertanyaannya, gak tahu.
Twitter sih yang selama ini kayaknya ada feature alt text.
Twitter punya bikin AI internal atau enggak ya, gak tahu.
Ya mungkin aja.
Atau jangan-jangan dijual.
Teori konspirasi di encourage world ke third party yang bikin AI.
Gak tahu sih dulu itu.
Betul.
Intinya perbincangan malam ini adalah untuk teman-teman aware aja gitu.
Bahwa ini penting dan sebenarnya banyak hal-hal yang kita belum lakukan,
bisa kita lakukan dengan apa ya, gak perlu nambah tool semacam-macam gitu ya.
Tinggal tambahin misalkan.
Mungkin butuh ada semacam checklist-nya kali ya.
Oh kalau image itu harus ada alt text, pengingat gitu.
Checklist-nya ya WCAG tadi.
Itu literally checklist kan dengan dibantu semua extension tadi.
Jadi kita tinggal ngikutin aja.
Mulai dari Lighthouse lah yang udah pasti kita jalanin kan.
Lighthouse untuk ngecek performance.
Nah disana ada accessibility ya udah diikutin aja gitu ya.
Tapi Lighthouse sendiri ada penilaian accessibility-nya gak?
Ada kan?
Ada.
Ada kan ya?
Ada dong.
Ah 90, 100 gitu kan.
Ada, ada score-nya dan ada penjelasannya juga nih.
Coba buka link-nya.
Nah ini dia.
Perhitungan scoring-nya juga ada, bisa kita baca.
Terus key tips-tips-nya juga ada.
Jadi bisa mulai dari sana?
Kalau misalkan.
Yang atas tuh audit scoring, coba klik.
Oh ada nilainya ya.
Nah terus udah ada penjelasannya juga.
Udah kita tinggal ngikutin aja sih ini.
Enak.
Yang tidak kalah penting adalah mulai dari semantik HTML dulu.
Itu yang paling fundamental lah.
Jangan sampai button kita pakai kalau tidak terpaksa banget.
Kalau kecil tapi impact-nya besar.
Sebenarnya ini bukan cuma accessibility tapi kayak SEO dan lain-lain.
Termasuk kayak struktur heading.
Itu kan itu ngaruh buat accessibility juga.
Karena screen reader kan ngebaca itunya heading-nya.
User navigasi berdasarkan H1, H2 itu ngaruh ke accessibility, ngaruh ke SEO juga.
Jadi mulai dari situ.
Ini sekedar 3 key questions, 3 via questions buat teman-teman.
Bisa jawab nanti di kolom komentar.
Jadi diskusi biar buat teman-teman mikir.
Untuk actionable element apakah lebih bagus pakai link atau button?
Misalnya kita mau next atau previous.
Kalau element itu diklik ada action yang terjadi.
Itu pakai link atau button.
Dan apakah link yang di-style sebagai button atau button yang di-style sebagai link?
Coba nanti teman-teman bisa dilihat dari sudut pandang accessibility.
Button yang dibungkus ke dalam element marquee.
Element wing.
Ini bukan kita kan yang jawab.
Harus ketik jawab.
Makanya marquee hilang itu salah satunya adalah kurang accessible ya.
Karena jalan.
Cuma ini jadi inget sih soal bahasa, soal kata-kata.
Kita webdev kan punya definisi sendiri link itu apa, link element itu apa, button element itu apa.
Itu kan hal teknis di webdev.
Link itu maksudnya angkor link ya?
Angkor.
Angkor element, button itu apa.
Tapi kan dari segi designer, dari segi developer lain.
Mungkin developer back-end, dari segi tech lead gitu.
Itu kan mereka punya definisi sendiri button itu apapun yang bentuknya.
Misalnya kotak gitu ada backgroundnya.
Nah, jadi itu kalau kita punya pemahaman kuat tentang itu kita juga,
kalau misalnya tiket nih, add a button.
Nah, kita harus tahu kapan itu maksudnya button beneran,
kapan maksudnya link.
Jadi soal bahasa, kata-kata yang digunakan.
Belum kalau kita bikin design system nih.
Kita bikin UI component library entah untuk internal atau buat dikomsum publik.
Kita juga harus bikin kata-kata yang tepat kan.
Kadang kita butuh link yang di-style seperti button.
Jangan di-wrap juga, nggak lucu.
Kita cuma butuh visualnya button tapi sebetulnya itu link adakalanya.
Atau mungkin kadang ada sebaliknya sebetulnya button tapi secara visual ditampilin sebagai link.
Nah, kita harus mikirin itu pas bikin nama UI component.
Tapi harus ada penjelasannya dan coba nanti teman-teman yang nonton video ini jelasin
dan apa hubungannya sama accessibility.
Kenapa?
Udah kayak dulu sen aja nih, ada 13 nya.
Ini ada, udah ada yang jawab tapi belum ada penjelasannya.
Link di-style sebagai button.
Link di-style sebagai button.
Ada shorthandnya, poinnya dipikir aja elemen apa yang cocok buat do something,
melakukan sesuatu, elemen apa yang cocok buat go somewhere, pergi ke suatu tempat.
Shorthandnya itu sih.
Betul.
Kisih-kisihnya dari bu dosen Eka.
Kita udah jadi dosen semua.
Gua biasa bolos terus, sekarang jadi dosen ala-ala.
Oh iya, bener-bener.
Wah itu sudah menjawab sekali itu.
Oke, oke, oke.
Ada lagi yang mau kita bahas?
Itu terakhir yang testing library.
Testing library.
Ini adalah library untuk alat bantu testing.
Mas Kenzie Dots.
Kenzie Dots yang bikin.
Itu yang serba bisa ya, apa aja dia bikin.
Jadi, sedikit aja ya.
Khusus misalnya kita lihat contohnya yang React testing library-nya yang React.
Tapi bukan hanya untuk React ya.
Saya hanya pakai contoh untuk React aja, simple.
Untuk di penjelasan ini.
Accessibility juga bisa dijadikan bagian dalam unit testing.
Tadi kan kita sudah punya eslin untuk ngecek kodenya kita.
Terus kita juga bisa pakai browser testing dengan extension untuk ngecek accessibility.
Dan juga bisa pakai accessibility testing dengan menggunakan apa tadi?
Yang handbook tadi ya?
Storybook.
Storybook, bisa juga pakai test.
Kita juga bisa menambahkan unit test dengan mengecek elemen-elemen accessibility.
Contohnya kita mau, misalnya kita mau ngetes sebuah button.
Dan daripada kita mengambil ID dari button itu, atau mengambil class name dari button itu,
kenapa nggak kita ambil area label dari button itu?
Jadi sekaligus mendeteksi apakah kita punya button sudah pas accessibility,
dan juga bisa ngetes unit testing kita untuk user behavior-nya.
Contohnya itu.
A white screen find by role.
Jadi daripada kita find by class name, atau find by class name heading,
header title, contohnya, mending kita find by role heading.
Jadi kita sudah accessibility by standard.
Itu kayak encourage, secara nggak langsung kayak mendorong kita ya.
Selalu pakai entah elemen yang semantik dari sono-nya,
atau kalau nggak semantik ya gimana caranya kita ngakalin pakai area role,
atau apalah, biar yang penting bisa ditemukan heading yang tulisannya itu.
Hello there.
Betul. Jadi by base, by standard, kita sudah pakai accessibility, bahkan untuk unit testing-nya.
Jadi lebih ini lagi, lebih advanced lagi kita ngetes-nya, jadi lebih baik.
Testing library ini salah satu tools yang mengencourage kita untuk menggunakan area label,
or find by role, model-model gitu ya, sekaligus berarti ya.
Daripada hanya ngetes untuk tampilan saja, ini juga dites untuk apakah di halaman tersebut,
atau di komponen tersebut sudah ada heading-nya belum.
Sudah ada role sebagai button-nya, kalau kita bikin form, ada button-nya atau nggak.
Bisa sekalian dicek juga kan, nggak hanya ngecek kayak by class name atau by ID,
ternyata dia nge-link.
Karena class name mungkin bisa berubah.
Kalau class name-nya itu generative CSS, NGS, boosing, boosing, nggak tuh.
Terus kalau ID bisa berubah, tetapi role...
Funksional.
Funksionalnya di dalam elemen itu tidak berubah kan fungsinya gitu.
Karena kita ngetes user behavior dan fungsi dari elemen yang kita buat.
Jadi lebih tepat menggunakan accessibility.
Justru lebih memudahkan kita juga ya.
Daripada kita pakai data test ID, data test ID, pusing kita harus mikir nama nih.
Kan sekarang kita udah nggak usah mikir nama, tapi lebih dari fungsinya.
User cari button untuk di-click.
Nah itu kan sesimple itu.
Kan banyak orang yang mengeluhkan kalau testing itu berarti kita harus maintain dua code kan.
Code testingnya dan code implementasinya kan.
Kalau misalkan gimana caranya supaya code testing kita nggak banyak berubah.
Ya salah satunya dengan menggunakan role dan lain-lain yang juga diterapkan di testing library ini ya.
Jadi nggak perlu terlalu banyak perubahan.
Kalau misalkan class name-nya berubah atau bertambah atau ID-nya berubah.
Yang penting, tapi behavior-nya kan tetap...
Tetap sama.
Kalau elemen itu kan button atau heading, nggak berubah.
Jadi lebih spesifik, eh lebih general, bukan lebih spesifik.
Kalau ID lebih spesifik.
Data test ID lebih spesifik.
Makanya kalau shape dari elemen berubah, text-nya berubah.
Jadi kayak itu ya, jadi kayak snapshot testing ya.
Ya itu gue paling nggak suka.
Stream manual.
Itu buat kemalas aja.
Buat kemalas.
Ini ada tambahan juga dari Mas Denny.
Button juga harus ada label-nya.
Supaya apa nih, JAWS.
Itu screen reader.
Jadi kalau voice-over itu kan screen reader yang bawaan di Mac.
Kalau kita punya Macbook, otomatis ada voice-over.
Nah kalau di Windows, kalau nggak salah NVDA itu yang open source.
Windows nggak...
Keliatannya sampai nggak tahu sekarang yang baru udah ada atau belum.
Tapi by default Windows itu nggak ada screen reader-nya.
Jadi biasanya orang download NVDA yang free, open source.
Atau pakai JAWS itu, JAWS itu yang berbayar.
Yang berbayar.
Terus kalau Android namanya apa ya? Talkback, kalau nggak salah.
Kalau yang iPhone, sama voice-over juga.
Nah ini juga apa?
Kita biasanya nge-develop tuh ada pusing-pusing antar browser.
Suka lain-lain behavior-nya, atau suka ada browser quark.
Nah ini kalau yang udah tingkat advanced nih, tingkat kompleks.
Antar screen reader bisa, ya walaupun sudah ada standarnya.
Ya browser juga gitu kan, web API udah ada standarnya.
Tapi mungkin ada behavior quark.
Nah screen reader itu juga kalau yang profesional banget.
Khusus accessibility expert nih, kudu nge-check di semua screen reader itu.
Kayak misalnya itu button, button harus ada label-nya.
Nah sekarang sih kelihatannya asal button itu ada child element yang ada text-nya sih.
Setahu aku sih bisa dibaca sih.
Nah cuma apakah sudah konsisten di semua screen reader.
Ya itu harus testing.
Tadi kan ada assistive technology check.
Betul, betul, betul.
Jadi entah itu berupa label di button, atau child element.
Jadi button, terus child-nya, children-nya ada isi text-nya, itu bisa dibaca harusnya.
Hmm, iya, iya, iya.
Oh cuma itu kasus yang sering keskip orang, button-nya itu icon.
Misalnya shopping card atau apa, misalnya apa, open shopping card.
Muncul dialog atau pop-up yang isinya isi shopping card.
Itu kan sering tuh cuma gambar kereta doang.
Nah itu kan nggak ada label-nya, itu harus dikasih label.
Harus dikasih text label, harus kita tambahin sendiri.
Tapi kalau button-nya, misalnya isinya udah text, shopping card gitu beneran text.
Itu sih harusnya aman, bisa dibaca juga.
Oh yang lumayan sering akhir-akhirnya kan trend-nya itu kalau bikin web itu ada emoji.
Emoji juga harus direp ke dalam span dengan role image, kan.
Nah ini juga menarik.
Dulu kayak gitu, karena dulu emoji nggak dibaca.
Konon katanya sekarang emoji udah dibaca.
Ngetes sendiri sih pakai voice-over udah dibaca.
Nah itu kelihatannya cuma rule-nya masih masuk di Aslin deh sampai sekarang.
Bentar-bentar, beneran pernah baca artikel tentang itu sih.
Cuma intinya ya gitu, behavior-nya bisa berubah juga.
Kan mungkin screen reader ngikutin perkembangan jaman juga ya.
Ada yang pernah nyoba assistive teknologi yang pakai handphone nggak sih?
Coba gimana gitu?
Belum pernah.
Belum pernah, cuma di laptop lang, di Macbook.
Ya, ada voice-over-nya ya.
Sering itu nggak sengaja kepencet, tiba-tiba aktif.
Seperti gue bunyi, kaget.
Loh, kok ada yang bersuara?
Oh ini lagi nyari ya?
Iya, eh cuma nggak nemu sih kelihatannya.
Oh nggak nemu, ya sudah.
Sebetulnya ini kan kayak kita nge-handle browser behavior aja ya.
Kalau misalnya masih banyak yang belum support, ya jangan dipakai dulu.
Nah ini juga, maksudnya walaupun misalnya voice-over udah bisa baca emoji,
kan kita belum tahu nih screen reader lain gimana.
Ya udah tetap pakai roll image.
Jadi di rep pake span, dikasih roll image untuk memberi tahu bahwa ini maksudnya image lho.
Terus area label-nya, ya text isi emoji itu.
Oke, jadi text yang mendeskripsikan isi emoji itu ya?
Oke, ini lumayan sering juga kena soalnya sering suka males pake icon kan.
Yaudahlah emoji aja lah, gampang.
Dan bahkan kadang kan kita pakai, itu ya ASCII art itu suka pakai ada generator-nya.
Misalnya untuk judul ya, judul diritmi gitu, judul nama library kita.
Itu kan nggak kebaca kalau di screen reader pusing nggak sih?
Iya, iya, iya.
Itu kayak random karakter doang ya.
Ada contohnya nggak?
Ada dong, scroll aja di bawah.
Oh, ini jamannya MRC nih, Smiley MRC.
Belum ada image ya, nggak ada visualnya.
Jadi pakai titik 2, senyum, terus wink, gitu ya.
Atau ini ya?
Oke, ini dipakaiin role-nya image ya.
Karena kita memberitahu ini maksudnya semacam image lah ya.
Bacanya adalah WCAG.
Kalau sama assistir teknologi, bacanya ini image WCAG gitu.
Oh, oh, oh, oh.
Kalo nggak dikasih real label, oh, oh, oh, oh.
Dinyun nggak sih?
Dinyun ya.
Jadi nyanyi dia.
Oh, ya bukankah.
Itu kan nyanyi.
Aduh, wah seru ya.
Oke, oh, komen lagi nih.
Mulai sering pakai screen reader, browser edge, banyak pilihan asennya, dan lumayan udah bagus.
Oh, edge udah ada ya.
Itu belum ada ya?
Dia, edge itu justru.
Menurut saya ya, edge itu lahir untuk unik selling pointnya itu accessibility.
Oh, baru tau.
Bisa pilih asen.
Baca konten bahasa Inggris, asen Jawa Timur.
Wih.
Hebat itu kalo ada.
Kalo misalkan, kita ngomongin semantik HTML deh.
Misalkan kita desainnya nggak sal nih, ya nggak sal dan takut gitu.
Div di dalam, div di dalam, div di dalam, baru di dalamnya ada button gitu.
Itu mempengaruhi nggak sih?
Walaupun divnya ya invisible, kosong nggak ada.
Mungkin hanya ada class name, ada style sedikit gitu.
Divnya kan nggak fokusable kan, misalnya kalo behavior tab ya langsung ke button, atau kalo pake screen reader ya dia tetep ngebaca buttonnya.
Jadi screen reader itu biasanya bunyinya gini, button, click me.
Dia nyebut button, habis itu nyebut isinya, label-nya.
Atau kebalik?
Nggak, yang disebut elemennya dulu.
Elemennya dulu ya?
Kayaknya iya sih, terakhir nyoba voice over, kayaknya iya.
Misalnya link, kayak yang di layar ini, link, tadi ya recommendation.
Tapi ngomongnya cepet-cepet gitu, screen reader.
Ya karena kontennya kan banyak link.
Sebelum masuk link, jadi dia nyebut list, 2 items, atau semacamnya gitu lah.
Jadi dia introduce dulu, dari dom element kan dia ketemunya list dulu kan, unordered list dulu, yaudah dia ngebaca list yang berisi 2 item.
Nah terus itemnya kan berupa link.
Dia baca, link, area recommendation.
Link, accessible name, and blablabla.
Oke, ini ada pengalaman juga dari Ray.
Untuk case button yang calanya hanya icon, bisa ditambahkan area label, supaya bisa terbaca ya.
Kalau hanya icon doang ya. Betul-betul.
Karena kalau nggak, ya buttonnya jadi nggak bisa dibaca sama si screen reader-nya.
Jadi nggak tahu itu fungsi buttonnya buat apa.
Oke, oke, oke.
Oh paling sering search button isinya cuma kacang besar kan.
Kacang besar.
Kacang besarnya SCG lagi, nggak ketahuan sama sekali itu apa.
Oke, oke.
Bagi Ida Business, ya bikin ini course untuk accessibility.
Ayo Tomas Rizal lah bikin kursusnya.
Udah masuk kurikulung nggak, Tomas?
Kita bertanya bagaimana caranya supaya accessibility masuk ke hukum di Indonesia, tapi kurikulungnya kita belum ada.
Ayo, pasti mulai dari grassroot dulu nih.
Masuk kurikulung, accessibility.
Minimal ada satu topik.
Itu chicken or egg sih. Itu ayam dulu, apa telur dulu.
Misalnya nih, tiba-tiba di Indonesia ada hukum, kalau nggak accessible bisa dituntut.
Pasti langsung masuk kurikulung, semua kurikulung.
Karena itu jadi syarat kerja kan.
Jadi harus dia.
Tapi ya bisa juga dibalik.
Tetapi kan lulusannya dari institusi manapun kan nggak harus bekerja atau punya menggara project yang ada di Indonesia.
Betul, betul.
Jadi harus punya ilmu accessibility juga.
Ini makanya kita ngobrolin accessibility, asik kan diputerin lagi.
Ini topik-topik seperti accessibility, web security, itu hal-hal yang penting nggak penting.
Penting, tapi kadang-kadang ya kalau misalkan udah buru-buru, ya udahlah, nggak apa-apalah, nanti bisa nanti, gitu kan.
Karena nggak langsung fisik, nggak langsung kelihatan oleh orang awam ya, atau dari perspektif apa, organisasi atau perusahaan kan.
Mereka kan nggak tahu nih, orang lain selain kita kan rata-rata nggak tahu dan nggak langsung kelihatan.
Cuma nanti paling tiba-tiba dituntut.
Kalau kejadian, kalau ada kejadian baru.
Intinya kan kayak kalau kita berkompet sama security apple-to-apple ya, security itu bukan sesuatu yang kita perbaiki setelah live tetapi menjadi sebuah habit.
Lebih mudah kalau dibikin dari awal.
Habit dari awal, habit untuk nge-developnya itu sudah security-minded.
Punya common-common security mistake itu sudah nggak ada, gitu. Karena sudah dicek sama linter, sudah dicek sama sniffer, segala macem.
Kan sudah jadi apa namanya, sudah ada yang ngasih tahu dari awal code-nya kerjakan.
Accessibility juga bisa juga dilakukan hal yang lebih kaya.
Bisa dilakukan hal yang sama ya.
Berarti harus dimasukkan ke prosedur untuk continuous integration dan lain-lain ya.
Jadi kalau misalkan accessibility-nya nggak lulus, nggak boleh pull request.
Gak bisa di-merge, pull request boleh.
Oh, nggak bisa di-merge.
Gak di-merge.
Ada lagi? Terakhir? Penutup?
Lagi ya? Udah accessibility nggak ada. Cuma seperti biasa, saran request topik bit.ly/NgeobrolinWeb.
Saya ada satu topik, tapi nanti kita bicara akan di belakang layar.
Boleh, siap.
Meskipun kita ada topik sendiri, kita juga butuh saran topik dari teman-teman.
Yang pengen teman-teman dengar apa?
Yang pengen dengar apa? Karena kita bisa ngobrol bareng-bareng kayak sekarang kan.
Ada yang punya pengalaman, ada yang nanya, gitu.
Nah kita lebih sukanya tuh yang interaktif.
Jadi kalau topik yang teman-teman tertarik tuh dimana, kita bisa bahas di sana.
Kayak kemarin itu salah satunya itu ya web jadul.
Itu kita belum kebayang sebelumnya ada topik itu dan ternyata disarankan dan itu menarik sekali.
Itu seru.
Itu seru sekali.
Dan mungkin kita bisa bahas itu lagi kayak mungkin ada beberapa teknologi yang jadul,
yang dulu mungkin keren banget, terus sekarang udah almarhum gitu.
Bisa kita jadikan satu topik sendiri.
Jadi kita tetap nunggu saran dari teman-teman terkait topik ataupun perbaikan dari acara kita ini.
Atau saran bintang tamu juga boleh ya kalau ada yang ingin...
Sekalian kontaknya lah kalau gitu. Iya, mengundang siapa, mengundang siapa, boleh.
Kalau siapa tahu ada yang mau mengajukan diri, bikin project web yang apa, yang keren banget.
Terus bisa dibahas, bisa diobrolin secara live.
Oh iya ya, kayak showcase gitu ya.
Terus saya bikin website nih, terus minta sarannya gitu ya.
Yang nggak harus bikin website sih, bikin komunitas gitu, punya komunitas.
Iya, apa tadi misalnya, komunitas accessibility atau apalah.
Oh iya, kita bisa mengundang tim dari Alay ID ini ya.
Alay ID. - Alia.
Alay ID itu salah semua kita bertiga.
Oh Alay ID. - Dari Suarez lah ya.
Jadi bisa bikin acara bareng juga.
Terus kemarin itu sempat kita ngobrol beberapa teman-teman kita juga melakukan acara seperti ini.
Contohnya React Indonesia, ada ngobrolin club juga.
Ada beberapa lah, dari GDG juga ada ya, tiap hari Rabu.
Di Discord. - Jadi Discord ya?
Discordnya apa tuh? Coba.
Discord itu ada shortlink-nya nggak sih? - Google Dev.
Google Dev.
Iya, maksudnya ada shortlink-nya kayaknya ya.
Nah, nggak tahu sih, cari sendiri deh.
Ya, follow aja Instagramnya GDG Bogor. Salah satu lead-nya GDG Bogor yang bikin acara ini, sudah menjadi GDE sekarang.
Jadi GDE itu jadi mubah dari GDG nggak sih?
Nggak ya? - Nggak, nggak kayaknya.
Nggak kayaknya.
Oke, kalau gitu terima kasih banyak buat semuanya yang sudah menemani dan sudah diskusi dari awal sampai...
Sampai berakhirnya acara, kita udahan dulu untuk minggu ini.
Tunggu acara kita berikutnya di hari Selasa depan, kembali ke jam 8 lagi.
Terima kasih dan selamat malam, selamat istirahat. Bye bye.
Bye bye.
Ntar, closing dulu closing.
Salah.
Salah pencet.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://bit.ly/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
12 Mar 2025
Ngobrolin Keamanan bareng @mazipan
Episode ini membahas tentang keamanan web (web security) bersama Mas Irfan, narasumber untuk ketiga kalinya. Diskusi dim...
17 Jan 2024
Ngobrolin Form
Episode ini membahas secara mendalam tentang formulir (forms) dalam pengembangan web, yang ternyata jauh lebih kompleks ...
11 Jun 2025
Bedah Situs
Episode ini merupakan sesi bedah situs yang pertama kali mendapatkan partisipasi dari penonton. Website yang dibedah ada...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .