Pengantar aksesibilitas aplikasi Windows — bersiap menghadapi UI Automation dan kewajiban akomodasi wajar

“Karyawan yang baru direkrut di tengah karier dan memiliki disabilitas penglihatan tidak bisa memakai aplikasi entri pesanan inti dengan pembaca layar. Peramban web dan email sudah dikuasai tanpa masalah, tetapi hanya aplikasi bisnis kami yang bacaannya tidak berjalan dengan benar. Bisakah dibantu?” — konsultasi semacam ini dari departemen TI pelanggan semakin sering datang.

Salah satu latar belakangnya adalah kerangka hukum. Amandemen 2021 terhadap Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas berlaku pada 1 April 2024, dan “penyediaan akomodasi wajar” kepada penyandang disabilitas menjadi kewajiban bagi pelaku usaha juga.¹ Lebih jauh, hubungan karyawan–perusahaan seperti di pembuka (bidang ketenagakerjaan) adalah ranah Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas, yang telah mewajibkan pemberi kerja menyediakan akomodasi wajar sejak April 2016.² Anggapan bahwa “aksesibilitas adalah urusan situs web, tidak relevan bagi aplikasi Windows internal” tidak lagi bertahan, baik secara hukum maupun di lapangan.

Sementara itu, dari sisi pengembangan, “tidak tahu harus berbuat apa” adalah kondisi yang jujur. Aksesibilitas aplikasi desktop Windows lebih miskin informasinya dibanding Web, dan tidak ada solusi ajaib yang bisa dipasang belakangan. Tidak perlu pesimis juga. Jika mekanisme pembaca layar membaca aplikasi (UI Automation) dipahami, lalu dasar nama, keyboard, dan warna dikuasai, kegunaan aplikasi bisnis meningkat secara substansial. Sebagian besar perbaikan itu, dengan atau tanpa disabilitas, juga menaikkan produktivitas semua pengguna.

Artikel ini ditujukan kepada pengembang aplikasi bisnis di Jepang dan staf TI, dan menghubungkan dalam satu alur mulai dari pemilahan minimum kerangka hukum dan standar, lewat mekanisme UI Automation, implementasi di WinForms/WPF, operasi keyboard, warna dan kontras, serta alat verifikasi, sampai cara realistis menetapkan prioritas.

flowchart TB
    accTitle: Alur artikel ini
    accDescr: Struktur artikel ini, menghubungkan secara berurutan dari pemilahan kerangka hukum dan standar lewat mekanisme UI Automation, implementasi di WinForms dan WPF, operasi keyboard, warna dan kontras, alat verifikasi, dan cara menetapkan prioritas
    law["Pemilahan kerangka hukum dan standar"] --> uia["Mekanisme UI Automation"]
    uia --> impl["Implementasi di WinForms/WPF"]
    impl --> kb["Operasi keyboard"]
    kb --> color["Warna dan kontras"]
    color --> verify["Alat verifikasi"]
    verify --> prio["Cara menetapkan prioritas"]

Gambar 1: Artikel ini menghubungkan kerangka hukum, mekanisme, implementasi, verifikasi, dan prioritas dalam satu alur.

1. Intinya dulu

• Penyediaan akomodasi wajar menjadi kewajiban bagi pelaku usaha juga sejak 1 April 2024. Ketika penyandang disabilitas menyatakan keinginan agar hambatan dihapus, respons dalam batas yang tidak menjadi beban berlebihan dituntut. Bidang ketenagakerjaan diatur Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas, dan itu sudah menjadi kewajiban pemberi kerja sejak April 2016.¹²
• Akomodasi wajar adalah proses “menanggapi permintaan individual lewat dialog konstruktif”; merapikan aplikasi di muka termasuk “penataan lingkungan” (kewajiban upaya). Dukungan sempurna di muka bukan kewajibannya; yang penting adalah tidak menolak dialog secara sepihak.¹
• Kriteria teknis aksesibilitas terkumpul di WCAG (JIS X 8341-3:2016). JIS X 8341-3:2016 adalah standar padanan dengan isi yang sama seperti WCAG 2.0, dan WCAG2ICT milik W3C memberi panduan penerapan pada perangkat lunak non-Web. Aplikasi desktop dapat diperiksa dengan kerangka pikir yang sama.³⁴
• Pembaca layar membaca aplikasi lewat UI Automation (UIA). Properti yang dipegang setiap elemen pada pohon UIA — Name, ControlType, dan semacamnya — serta pola kontrol seperti Invoke, Value, dan SelectionItem adalah bahan pengumuman dan operasi.⁵
• Tombol yang Name-nya kosong hanya diumumkan sebagai “tombol”. Perbaikan prioritas tertinggi adalah penamaan. WinForms memakai AccessibleName serta kaitan Label dan urutan tab; WPF memakai AutomationProperties.Name/LabeledBy.⁶⁷
• Dapat mencapai setiap fungsi dari keyboard saja adalah kriteria keberhasilan WCAG (2.1.1) dan, pada saat yang sama, kecepatan input operator terampil itu sendiri. Merapikan urutan tab, access key, dan indikasi fokus terhubung langsung ke efisiensi semua pengguna.⁸
• Pakai rasio kontras teks 4,5:1 atau lebih sebagai acuan, dan jangan sampaikan informasi hanya lewat warna. Pada tema kontras (kontras tinggi), hormati warna sistem, bukan warna yang di-hard-code.⁸⁹
• Gabungkan verifikasi dengan FastPass di Accessibility Insights for Windows dan pemeriksaan langsung dengan pembaca layar. Karena keduanya duduk di fondasi UIA yang sama, pekerjaan ini juga saling menguntungkan dengan aset pengujian otomatis UI seperti FlaUI.¹⁰
• Tidak perlu memperbaiki semua layar sekaligus. Urutan realistis adalah (1) mulai dari layar yang dipakai pengguna itu, (2) pengembangan baru memenuhi standar, (3) perluas ke samping dengan merapikan kontrol bersama.

Dalam satu kalimat: dukungan aksesibilitas adalah “memublikasikan nama dan operasi yang benar pada pohon UIA, serta menjaga dasar keyboard dan warna”.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 16, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Pemilahan kerangka hukum dan standar — apa yang berubah dengan “kewajiban”

2.1. Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas — sejak April 2024 pelaku usaha juga wajib “menyediakan akomodasi wajar”

Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas melarang “perlakuan diskriminatif yang tidak adil” terhadap penyandang disabilitas bagi lembaga administrasi dan pelaku usaha, serta menuntut “penyediaan akomodasi wajar”. Melalui amandemen 2021 (tahun Reiwa 3), penyediaan akomodasi wajar oleh pelaku usaha yang sebelumnya merupakan kewajiban upaya menjadi kewajiban, dan undang-undang amandemen itu berlaku pada 1 April 2024 (tahun Reiwa 6).¹

Menurut leaflet Cabinet Office, penyediaan akomodasi wajar berarti menanggapi, dalam batas yang tidak menjadi beban berlebihan, ketika penyandang disabilitas menyatakan bahwa diperlukan tindakan untuk menghapus hambatan di masyarakat. Isinya berbeda menurut karakteristik disabilitas serta situasi dan kondisi, sehingga dialog konstruktif — pelaku usaha dan penyandang disabilitas berulang kali berdialog dan bersama-sama menelaah opsi tanggapan — dipentingkan. Dinyatakan secara tegas bahwa menolak dialog konstruktif secara sepihak dapat menjadi pelanggaran kewajiban menyediakan akomodasi wajar.¹

Ada dua pemilahan yang penting di lapangan.

1. Bukan berarti “harus menangani semuanya di muka” menjadi kewajiban. Tindakan perbaikan di muka yang menyasar penyandang disabilitas secara tidak spesifik — sisi lunak seperti peninjauan manual dan pelatihan, sisi keras seperti aksesibilitas fasilitas — disebut “penataan lingkungan”, dan ini kewajiban upaya.¹ Menata aplikasi bisnis agar dapat dipakai dengan pembaca layar dari awal termasuk upaya di sisi penataan lingkungan. Semakin maju penataan lingkungan, akomodasi wajar individual dapat disediakan dengan beban yang lebih ringan.
2. Bidang ketenagakerjaan bukan ranah Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas, melainkan Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas. Leaflet yang sama juga mencatat bahwa ketenagakerjaan dan pekerjaan mengikuti ketentuan Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas.¹ Di undang-undang itu, melalui amandemen yang berlaku April 2016 (tahun Heisei 28), larangan diskriminasi disabilitas di bidang ketenagakerjaan dan penyediaan akomodasi wajar dalam batas yang tidak menjadi beban berlebihan diwajibkan bagi pemberi kerja.² Konsultasi pembuka “karyawan tidak bisa memakai aplikasi bisnis” sebenarnya sudah lama berada di ranah kewajiban, jauh sebelum 2024.

flowchart TB
    accTitle: Posisi akomodasi wajar dan penataan lingkungan
    accDescr: Hubungan pelaku usaha umum dan penyandang disabilitas diatur Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas, dan penyediaan akomodasi wajar yang menanggapi permintaan individual lewat dialog konstruktif menjadi kewajiban sejak April 2024; bidang ketenagakerjaan menjadi kewajiban pemberi kerja sejak April 2016 berdasarkan Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas; merapikan aplikasi di muka termasuk penataan lingkungan sebagai kewajiban upaya
    scene{"Situasi yang mana?"} -->|Pelaku usaha dan penyandang disabilitas| kaisho["Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas"]
    scene -->|Ketenagakerjaan dan pekerjaan| koyou["Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas"]
    kaisho --> moushide["Menanggapi permintaan individual lewat dialog konstruktif"]
    moushide --> hairyo["Penyediaan akomodasi wajar (kewajiban sejak April 2024)"]
    koyou --> koyougimu["Penyediaan akomodasi wajar (kewajiban sejak April 2016)"]
    kaisho -.-> kankyo["Merapikan aplikasi di muka = penataan lingkungan (kewajiban upaya)"]
    kankyo -.-> moushide

Gambar 2: Dasar hukum terbagi menurut situasi; akomodasi wajar adalah kewajiban, merapikan di muka termasuk penataan lingkungan sebagai kewajiban upaya.

Catatan: bagaimana kasus individual diperlakukan secara hukum bergantung pada situasinya. Artikel ini tidak masuk ke tafsir hukum, dan maju dari sudut “apa yang bisa dikerjakan sebagai teknisi ketika dukungan diminta”. Sebagai sumber primer, rujuk materi Cabinet Office dan Kementerian Kesehatan, Tenaga Kerja, dan Kesejahteraan.¹²

2.2. JIS X 8341-3 dan WCAG — “kriteria Web” juga menjangkau perangkat lunak

Di sisi kriteria teknis, semuanya terkumpul di JIS X 8341-3:2016. Standar ini adalah standar padanan ISO/IEC 40500:2012, dan teks standarnya sama isinya dengan WCAG 2.0 milik W3C.³ Jika ingin tahu secara konkret isi “dukungan aksesibilitas”, cara cepatnya adalah membaca kriteria keberhasilan WCAG (kini diperluas ke WCAG 2.1/2.2); terjemahan bahasa Jepang oleh WAIC juga dipublikasikan.⁸

Keraguan “bukankah WCAG adalah kriteria konten Web?” masuk akal, tetapi W3C menata cara menerapkan kriteria keberhasilan WCAG 2.0/2.1/2.2 pada dokumen dan perangkat lunak non-Web dalam Group Note bernama WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies).⁴ Artinya, kerangka pikir seperti “alternatif teks”, “kontras”, “operasi keyboard”, dan “jangan hanya mengandalkan warna” dapat diterapkan pada aplikasi desktop Windows dengan kerangka yang sama seperti Web. Bab 3 dan seterusnya dalam artikel ini menurunkan kerangka pikir itu ke implementasi konkret WinForms/WPF.

flowchart TB
    accTitle: Hubungan JIS X 8341-3 dan WCAG
    accDescr: JIS X 8341-3:2016 adalah standar padanan dengan isi yang sama seperti WCAG 2.0, dan WCAG2ICT menunjukkan cara menerapkan kriteria keberhasilan WCAG pada perangkat lunak non-Web, sehingga aplikasi desktop Windows juga dapat diperiksa dengan kerangka yang sama
    wcag["WCAG 2.0 (W3C)"] ---|standar padanan dengan isi yang sama| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["Diterapkan pada perangkat lunak non-Web"]
    soft --> app["Aplikasi desktop Windows"]

Gambar 3: JIS X 8341-3:2016 adalah standar padanan WCAG 2.0, dan WCAG2ICT memperluas kriteria yang sama ke aplikasi desktop.

3. Mekanisme teknologi bantu membaca aplikasi — tiga komponen UI Automation

3.1. Pohon UIA, properti, dan pola kontrol

Windows menyertakan fondasi aksesibilitas bernama UI Automation (UIA). UIA adalah mekanisme yang memungkinkan teknologi bantu seperti pembaca layar mengambil informasi UI dan mengoperasikan UI dengan cara selain input standar, serta menjadi perantara antara sisi aplikasi (penyedia) dan sisi teknologi bantu (klien).⁵

Dunia UIA dapat dipahami lewat tiga komponen berikut.⁵

Saat pembaca layar memfokuskan tombol dan mengumumkan “tombol Konfirmasi pesanan”, itu pada dasarnya kombinasi Name + jenis kontrol. Ketika pengguna melakukan operasi “jalankan”, teknologi bantu menekan tombol itu lewat pola Invoke. Dengan kata lain, jika Name dan pola dipublikasikan dengan benar, elemen dapat dibaca dan dioperasikan; jika tidak dipublikasikan, meski terlihat di layar, praktis sama dengan tidak ada.

flowchart TB
    accTitle: Tiga komponen UI Automation
    accDescr: Aplikasi sebagai penyedia memublikasikan properti dan pola kontrol setiap elemen pada pohon UIA, dan pembaca layar sebagai klien mengumumkan Name dan ControlType serta mengoperasikan lewat pola seperti Invoke
    app["Aplikasi (penyedia)"] --> tree["Pohon UIA"]
    tree --> prop["Properti (Name, ControlType, dll.)"]
    tree --> pat["Pola (Invoke, Value, dll.)"]
    sr["Pembaca layar (klien)"] -->|pengumuman| prop
    sr -->|operasi| pat

Gambar 4: Pembaca layar memakai properti dan pola yang dipublikasikan aplikasi pada pohon UIA untuk pengumuman dan operasi.

3.2. Pembaca layar adalah klien UIA

Pembaca layar utama di Windows mencakup Narrator yang terpasang di Windows, NVDA yang gratis dan sumber terbuka,¹¹ serta PC-Talker komersial yang banyak dipakai di Jepang. Gaya pengumuman berbeda-beda, tetapi jalur utama untuk membaca UI aplikasi desktop semuanya UIA. Karena itu, dukungan di sisi aplikasi bukan “dukungan pembaca layar tertentu”, melainkan terkumpul pada memublikasikan informasi yang benar ke UIA.

flowchart TB
    accTitle: Jalur bersama pembaca layar utama
    accDescr: Jika aplikasi memublikasikan informasi yang benar ke UIA, Narrator, NVDA, dan PC-Talker semuanya dapat membaca UI lewat jalur yang sama, sehingga dukungan sisi aplikasi bukan untuk pembaca layar tertentu melainkan terkumpul pada publikasi ke UIA
    app["Aplikasi"] -->|memublikasikan informasi| uia["UI Automation (UIA)"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["Dukungan terkumpul pada publikasi ke UIA"]

Gambar 5: Pembaca layar utama semuanya memakai UIA sebagai jalur, sehingga dukungan aplikasi terkumpul pada publikasi ke UIA.

3.3. Apa yang diumumkan jika “tombol yang Name-nya kosong”

Satu contoh konkret. Misalkan di bilah alat ada tombol simpan yang hanya menampilkan ikon disket. Bagi pengguna yang dapat melihat, makna tersampaikan lewat ikon, tetapi jika Name dibiarkan kosong, pembaca layar hanya mengumumkan “tombol”. Jika “Buka” dan “Cetak” di sebelahnya sama, pengguna hanya mendengar “tombol, tombol, tombol” dan tidak punya cara mengetahui mana yang apa. Panduan perbaikan aksesibilitas Microsoft juga menempatkan tombol tanpa Name dan gambar yang hanya diumumkan sebagai “Image” sebagai masalah khas yang menghentikan pekerjaan pengguna.⁷

Untungnya, baik WinForms maupun WPF, kontrol standar sudah mendukung UIA dari awal, dan dalam banyak kasus Name ditentukan otomatis dari teks atau label. Yang rusak biasanya salah satu dari: (1) hanya ikon sehingga tidak ada bahan nama, (2) tidak ada kaitan dengan label, (3) gambar kustom sehingga informasi tidak muncul di pohon UIA. Dua bab berikutnya meninjau cara memperbaikinya per kerangka.

flowchart TB
    accTitle: Tiga pola khas pengumuman yang rusak
    accDescr: Pengumuman rusak jika hanya ikon tanpa bahan nama, jika tidak ada kaitan dengan label, atau jika gambar kustom tidak mengeluarkan informasi ke pohon UIA, sehingga hanya diumumkan sebagai tombol
    c1["Hanya ikon, tanpa bahan"] --> broken["Name menjadi kosong"]
    c2["Tidak ada kaitan label"] --> broken
    c3["Gambar kustom, informasi tidak keluar"] --> broken
    broken --> result["Hanya diumumkan sebagai tombol"]

Gambar 6: Pengumuman yang rusak biasanya bermuara pada tiga pola: kekurangan bahan nama, kekurangan kaitan, atau gambar kustom.

4. Implementasi di WinForms — AccessibleName dan urutan tab

4.1. Kontrol yang Text-nya otomatis menjadi Name, dan yang tidak

Di WinForms, kontrol yang menampilkan teks seperti Button dan CheckBox memakai nilai properti Text sebagai Name UIA. Sebaliknya, ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView, dan sejenisnya tidak menjadikan Text sebagai Name. Untuk itu, nama harus diberikan dengan cara lain.⁶

Cara yang paling mudah dirawat adalah menempatkan Label penjelas pada urutan tab tepat sebelum kontrol sasaran. Jika TabIndex kontrol sasaran diatur langsung setelah TabIndex Label, teks Label itu dipakai otomatis sebagai Name UIA. Label yang terlihat di layar dan pengumuman menjadi selaras, dan tidak perlu mengelola dua kali salinan teks.⁶¹²

Jika Label tidak bisa ditempatkan, setel AccessibleName secara eksplisit. Selain itu, AccessibleDescription dapat disetel jika perlu penjelasan tambahan, dan AccessibleRole jika perannya berbeda dari tampilan.¹³

flowchart TB
    accTitle: Cara Name ditentukan pada kontrol WinForms
    accDescr: Pada Button dan sejenisnya Text langsung menjadi Name UIA; pada kontrol yang Text-nya tidak dipakai ulang seperti TextBox, teks Label yang diletakkan pada urutan tab tepat sebelumnya dipakai; jika Label tidak bisa diletakkan, AccessibleName disetel secara eksplisit
    ctrl["Kontrol"] --> qtext{"Jenis yang Text-nya menjadi Name?"}
    qtext -->|Ya| usetext["Text langsung menjadi Name"]
    qtext -->|Tidak| qlabel{"Ada Label pada urutan tab tepat sebelumnya?"}
    qlabel -->|Ya| uselabel["Teks Label dipakai sebagai Name"]
    qlabel -->|Tidak| explicit["Setel AccessibleName secara eksplisit"]

Gambar 7: Name di WinForms dipilih berurutan dari Text, Label pada urutan tab sebelumnya, lalu AccessibleName.

// Tombol bilah alat hanya ikon: nyatakan nama untuk pengumuman
saveToolStripButton.AccessibleName = "Simpan";

// Tombol hanya gambar: nama + penjelasan tambahan
btnSearchCustomer.AccessibleName = "Cari pelanggan";
btnSearchCustomer.AccessibleDescription = "Mencari master pelanggan berdasarkan kode atau nama";

// Field input yang tidak bisa menempatkan Label pada urutan tab sebelumnya: setel langsung
txtOrderNo.AccessibleName = "Nomor pesanan";

// PictureBox yang dipakai ulang sebagai tampilan grafik: sesuaikan juga perannya dengan kenyataan
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Grafik jumlah pesanan per bulan";

Catatan: jika AccessibleName sekali disetel di panel properti Visual Studio lalu dihapus, pengaturan string kosong dapat tertinggal di berkas desainer dan menghalangi resolusi nama bawaan. Hapus baris terkait dari berkas desainer.⁶

flowchart TB
    accTitle: Masalah string kosong AccessibleName yang tertinggal
    accDescr: Jika AccessibleName sekali disetel di panel properti lalu dihapus, pengaturan string kosong tertinggal di berkas desainer dan menghalangi resolusi nama bawaan, sehingga diperbaiki dengan menghapus baris terkait dari berkas desainer
    set["Setel AccessibleName"] --> erase["Hapus di panel properti"]
    erase --> remain["Pengaturan string kosong tertinggal"]
    remain --> block["Menghalangi resolusi nama bawaan"]
    block -.-> fix["Hapus baris terkait di berkas desainer"]

Gambar 8: Menghapus di panel properti tetap meninggalkan string kosong, jadi hapus baris terkait di berkas desainer.

4.2. Titik perbaikan yang sering muncul di layar entri pesanan

Berikut daftar periksa dari titik yang sering kami perbaiki di aplikasi bisnis.

Semuanya hanya beberapa baris perbaikan, tetapi bagi pengguna pembaca layar itu menjadi batas antara “layar yang tidak bisa dipakai” dan “layar yang bisa dipakai”.

5. Implementasi di WPF — AutomationProperties dan AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

Di WPF, kontrol seperti Button yang Content-nya berupa string memakai isi itu sebagai Name UIA. Tombol yang hanya ikon (Image atau Path) tidak punya bahan Name, jadi nyatakan secara eksplisit dengan AutomationProperties.Name, atau jika ada teks tampilan di dekatnya, kaitkan dengan AutomationProperties.LabeledBy.⁷

Ada catatan penting untuk TextBox. Text pada TextBlock dipakai ulang sebagai Name, tetapi Text pada TextBox dipublikasikan di sisi properti Value UIA, dan tidak menjadi Name. Untuk field input, kandidat pertama adalah mengaitkan TextBlock label tampilan lewat LabeledBy. Pengumuman dan tampilan layar menjadi selaras, dan pengelolaan ganda teks juga terhindar.¹⁴

<!-- Field input: kaitkan label tampilan lewat LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="Nomor pesanan" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- Tombol hanya ikon: nyatakan nama, dan tambahkan penjelasan jika perlu -->
<Button
    AutomationProperties.Name="Konfirmasi pesanan"
    AutomationProperties.HelpText="Mengonfirmasi pesanan yang sedang diinput dan mengalokasikan stok">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: Cara Name ditentukan pada kontrol WPF
    accDescr: Kontrol yang Content-nya string memakai isi itu sebagai Name; jika tidak, kandidat pertama adalah mengaitkan label tampilan di dekatnya lewat LabeledBy; jika itu pun tidak ada, setel AutomationProperties.Name secara eksplisit; Text pada TextBox dipublikasikan di sisi Value, bukan Name
    ctrl["Kontrol"] --> qc{"Content berupa string?"}
    qc -->|Ya| auto["Isi menjadi Name"]
    qc -->|Tidak| ql{"Ada label tampilan di dekatnya?"}
    ql -->|Ya| lb["Kaitkan lewat LabeledBy"]
    ql -->|Tidak| nm["Setel Name secara eksplisit"]
    tbx["Text pada TextBox"] -.-> val["Dipublikasikan ke Value, bukan Name"]

Gambar 9: Name di WPF ditentukan berurutan dari string Content, LabeledBy, lalu setelan eksplisit; Text pada TextBox tidak menjadi Name.

Informasi tambahan yang tidak muat di Name dapat dipublikasikan dengan AutomationProperties.HelpText.⁷ AutomationId juga pengidentifikasi yang dipakai untuk mengidentifikasi elemen dalam pengujian otomatis UI, jadi menetapkan aturan penamaan di tahap desain layar akan berguna belakangan (dibahas lebih rinci di “Pengujian otomatis UI aplikasi desktop Windows”).

5.2. Kontrol kustom memerlukan AutomationPeer

Kontrol kustom yang digambar sendiri tidak dapat memublikasikan informasi bermakna ke pohon UIA apa adanya. Di WPF, OnCreateAutomationPeer pada kelas turunan UIElement di-override, lalu kelas turunan AutomationPeer dikembalikan untuk memublikasikan nama, jenis, dan pola. Jika mewarisi kontrol yang sudah ada, mewarisi Peer yang sesuai (ButtonBaseAutomationPeer untuk ButtonBase) memungkinkan perilaku yang sudah diimplementasikan diwariskan.¹⁵

flowchart TB
    accTitle: Mekanisme publikasi informasi lewat AutomationPeer
    accDescr: Kontrol kustom meng-override OnCreateAutomationPeer dan mengembalikan kelas turunan AutomationPeer untuk memublikasikan nama, jenis, dan pola; jika mewarisi kontrol yang sudah ada, mewarisi Peer yang sesuai untuk mewariskan perilaku yang sudah diimplementasikan
    custom["Kontrol kustom"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Mengembalikan kelas turunan Peer"]
    peer --> pub["Memublikasikan nama, jenis, dan pola"]
    inherit["Mewarisi kontrol yang sudah ada"] -.-> basepeer["Mewarisi Peer yang sesuai"]
    basepeer -.-> reuse["Mewariskan perilaku yang sudah diimplementasikan"]

Gambar 10: Kontrol kustom mengembalikan Peer dari OnCreateAutomationPeer untuk memublikasikan informasi ke UIA.

// Contoh kontrol yang menggambar sendiri lampu berwarna untuk status saluran
public class StatusLamp : Control
{
    public static readonly DependencyProperty IsOnlineProperty =
        DependencyProperty.Register(nameof(IsOnline), typeof(bool), typeof(StatusLamp),
            new FrameworkPropertyMetadata(false,
                FrameworkPropertyMetadataOptions.AffectsRender, OnIsOnlineChanged));

    public bool IsOnline
    {
        get => (bool)GetValue(IsOnlineProperty);
        set => SetValue(IsOnlineProperty, value);
    }

    internal static string NameFor(bool isOnline)
        => isOnline ? "Status saluran: online" : "Status saluran: offline";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Terbitkan event perubahan properti UIA pada saat nilai berubah. Tanpa ini,
        // pembaca layar tetap memegang nama lama dan tidak menyadari perubahan status
        if (UIElementAutomationPeer.FromElement((UIElement)d) is AutomationPeer peer)
        {
            peer.RaisePropertyChangedEvent(
                AutomationElementIdentifiers.NameProperty,
                NameFor((bool)e.OldValue), NameFor((bool)e.NewValue));
        }
    }

    protected override AutomationPeer OnCreateAutomationPeer()
        => new StatusLampAutomationPeer(this);
}

public class StatusLampAutomationPeer : FrameworkElementAutomationPeer
{
    public StatusLampAutomationPeer(StatusLamp owner) : base(owner) { }

    protected override AutomationControlType GetAutomationControlTypeCore()
        => AutomationControlType.Text; // Tampilan status tanpa operasi setara Text

    protected override string GetNameCore()
        => StatusLamp.NameFor(((StatusLamp)Owner).IsOnline);
}

Pekerjaan Peer bukan hanya mengembalikan nama, melainkan memberitahu lewat event pada saat berubah. Teknologi bantu tidak punya jadwal sendiri untuk mengambil ulang nilai, jadi implementasi yang tidak menerbitkan event perubahan menjadi “benar hanya ketika ditanya ulang”, dan pengguna pembaca layar tidak menerima perubahan status.

sequenceDiagram
    accTitle: Alur menyampaikan perubahan status ke pembaca layar
    accDescr: Pada saat nilai kontrol berubah, AutomationPeer menerbitkan event perubahan properti Name; teknologi bantu tidak mengambil ulang sendiri, jadi tanpa event nama lama tetap dan perubahan tidak disadari
    participant c as Kontrol
    participant p as AutomationPeer
    participant s as Pembaca layar
    c->>p: Nilai IsOnline berubah
    p->>s: Menerbitkan event perubahan properti Name
    s->>s: Mengumumkan status baru
    Note over s: Tanpa event, nama lama tetap

Gambar 11: Perubahan nilai baru sampai ke pembaca layar setelah AutomationPeer memberitahu lewat event perubahan.

Untuk kontrol kustom yang punya operasi (dapat ditekan, dapat diubah nilainya, dapat dipilih), override GetPattern dan sediakan antarmuka pola seperti IInvokeProvider atau IRangeValueProvider.¹⁵ Poin pentingnya: jika Peer dikerjakan sampai tuntas di sisi pustaka kontrol bersama, semua layar yang memakainya otomatis sudah didukung. Itu menjadi fondasi “perluasan ke samping” di bab 9.

6. Apakah semua fungsi dapat dicapai hanya dengan keyboard

Kriteria keberhasilan WCAG 2.1.1 (keyboard) menuntut agar semua fungsi konten dapat dioperasikan dari antarmuka keyboard.⁸ Pengguna pembaca layar pada prinsipnya tidak memakai mouse, jadi fungsi yang tidak dapat dicapai dari keyboard sama dengan fungsi yang tidak ada. Sudut pemeriksaan adalah sebagai berikut.

Panduan aksesibilitas WinForms juga menempatkan sebagai dasar: meletakkan label pada urutan tab tepat sebelum field input, dan memberi access key pada kontrol serta menu yang ingin dituju pengguna.¹²

Yang ingin ditegaskan: ini bukan “biaya tambahan untuk dukungan disabilitas”. Pada pekerjaan rutin seperti entri pesanan, apakah input dapat diselesaikan tanpa mengangkat tangan dari home position langsung menentukan jumlah pemrosesan operator. Urutan tab yang kacau dan operasi yang wajib mouse adalah cacat yang setiap hari menggerus produktivitas semua pengguna. Dukungan aksesibilitas dan efisiensi keyboard hanyalah dua nama untuk pekerjaan yang sama (prioritas menurut lingkungan pemakaian, lihat juga “Perancangan UX aplikasi Windows”).

flowchart TB
    accTitle: Efek ganda merapikan keyboard
    accDescr: Merapikan urutan tab, access key, dan indikasi fokus sekaligus menghasilkan dua efek — pengguna teknologi bantu dapat mencapai fungsi, dan kecepatan input semua operator — sementara fungsi yang hanya bisa dipakai mouse sama dengan fungsi yang tidak ada
    seibi["Merapikan operasi keyboard"] --> a11y["Dapat dipakai pengguna teknologi bantu"]
    seibi --> speed["Kecepatan input semua operator"]
    mouse["Fungsi khusus mouse"] -.-> none["Sama dengan fungsi yang tidak ada"]

Gambar 12: Merapikan operasi keyboard sekaligus mewujudkan dukungan teknologi bantu dan efisiensi semua pengguna; fungsi khusus mouse sama dengan tidak ada.

7. Warna dan kontras — 4,5:1 dan “jangan hanya mengandalkan warna”

7.1. Acuan rasio kontras adalah 4,5:1

Kriteria keberhasilan WCAG 1.4.3 (kontras (minimum)) menuntut rasio kontras setidaknya 4,5:1 untuk teks dan gambar teks, serta setidaknya 3:1 untuk teks besar.⁸ Desain modern yang meletakkan teks abu-abu muda di latar putih tidak jarang memotong kriteria ini. Pengguna aplikasi bisnis mencakup orang yang ketajaman dan persepsi warnanya berubah karena usia, serta orang yang memakai aplikasi di lingkungan pencahayaan buruk seperti pabrik. Biasakan mengukur dengan pemeriksa kontras saat meninjau desain.

7.2. Jangan sampaikan informasi hanya lewat warna

Kriteria keberhasilan 1.4.1 (penggunaan warna) menyatakan bahwa warna tidak boleh menjadi satu-satunya sarana visual untuk menyampaikan informasi.⁸ Contoh khas di aplikasi bisnis adalah sebagai berikut.

• Menandai baris kesalahan hanya dengan teks merah → sertakan ikon kesalahan dan kolom pesan
• Menandai item wajib hanya dengan warna label → tambahkan notasi “*” atau “wajib”
• Menandai status hanya dengan warna lampu → gabungkan warna dengan bentuk atau teks (“berjalan”, “berhenti”)

Jika keragaman persepsi warna dipertimbangkan, ini pun bukan “dukungan khusus” melainkan dasar perancangan tampilan.

flowchart TB
    accTitle: Mengganti penyampaian informasi yang hanya mengandalkan warna
    accDescr: Tampilan yang menandai kesalahan hanya dengan teks merah diganti dengan ikon kesalahan plus kolom pesan; item wajib yang hanya ditandai warna label ditambah notasi wajib; status yang hanya ditandai warna lampu digabung dengan bentuk atau teks
    err["Kesalahan hanya teks merah"] --> erra["Sertakan ikon dan teks"]
    req["Wajib hanya warna label"] --> reqa["Tambahkan notasi wajib"]
    lamp["Status hanya warna lampu"] --> lampa["Gabungkan warna dengan bentuk atau teks"]

Gambar 13: Contoh khas yang menyampaikan hanya lewat warna diganti dengan kombinasi ikon, notasi, bentuk, atau teks.

7.3. Mengikuti tema kontras (kontras tinggi)

Windows memiliki tema kontras (dulu kontras tinggi) yang beralih ke palet yang memisahkan kuat latar depan dan latar belakang; pengguna dapat memilih dan menyunting tema bawaan yang dirancang agar rasio kontras kira-kira 7:1 atau lebih.⁹ Prinsip di sisi aplikasi sederhana: jangan hard-code warna, hormati warna sistem.

• WinForms: jika ForeColor/BackColor dibiarkan bawaan, pengaturan palet pengguna dipakai. Untuk bagian yang diwarnai sendiri, tentukan dengan SystemInformation.HighContrast, beralih ke palet berbasis SystemColors, dan ikuti perubahan pengaturan lewat event UserPreferenceChanged.¹²
• WPF/WinUI: jika merujuk sumber daya kelas SystemColors, peralihan tema diikuti. Bagian yang diisi kuas kustom menjadi penyebab rusak.⁹

flowchart TB
    accTitle: Mengikuti tema kontras
    accDescr: Bagian yang di-hard-code warnanya rusak saat beralih ke tema kontras, jadi beralih ke palet berbasis SystemColors dan ikuti event perubahan pengaturan; jika merujuk warna sistem, palet pengguna diikuti otomatis
    theme["Beralih ke tema kontras"] --> qh{"Cara menentukan warna?"}
    qh -->|Hard-code| broken["Palet rusak"]
    qh -->|Merujuk warna sistem| ok["Mengikuti palet pengguna secara otomatis"]
    broken -.-> fix["Beralih ke SystemColors"]
    fix -.-> ev["Mengikuti event perubahan pengaturan"]

Gambar 14: Hanya bagian yang di-hard-code warnanya yang rusak pada tema kontras; merujuk warna sistem mengikuti secara otomatis.

Selain itu, pengguna low vision sering memakai faktor pembesaran OS (penskalaan DPI) yang tinggi, sehingga dukungan DPI tinggi juga bagian dari dukungan aksesibilitas. Aplikasi yang tata letaknya rusak pada 125%–200% sudah tidak dapat dipakai pada titik itu. Rinciannya, lihat “Dukungan DPI tinggi WinForms” dan “Dukungan DPI tinggi WPF”.

8. Praktik verifikasi — Accessibility Insights dan pemeriksaan langsung dengan pembaca layar

8.1. Accessibility Insights for Windows

Microsoft menyediakan Accessibility Insights for Windows sebagai alat verifikasi aksesibilitas aplikasi Windows, dengan tiga cara pakai utama.¹⁰

• Live Inspect: cukup mengarahkan mouse ke elemen atau memfokuskan keyboard untuk melihat properti UIA-nya (Name, ControlType, pola, dll.). Cara tercepat melihat “apa Name tombol ini”.
• FastPass: pemeriksaan ringan yang mendeteksi masalah aksesibilitas berdampak tinggi dalam waktu kurang dari 5 menit. Masalah yang dapat dinilai secara mekanis, seperti Name yang hilang, dapat diinventarisasi per layar baru.
• Troubleshooting: membantu diagnosis dan perbaikan masalah tertentu. Dari masalah yang terdeteksi, panduan perbaikan per kerangka yang juga dikutip artikel ini dapat ditelusuri langsung.

Inspect.exe dan AccEvent yang disertakan Windows SDK juga dapat memeriksa pohon UIA dan properti, tetapi keduanya diposisikan sebagai alat warisan, dan saat ini migrasi ke Accessibility Insights direkomendasikan.¹⁰

flowchart TB
    accTitle: Tiga cara pakai Accessibility Insights
    accDescr: Accessibility Insights for Windows menyediakan Live Inspect untuk memeriksa properti UIA, FastPass untuk pemeriksaan ringan masalah berdampak tinggi, dan Troubleshooting untuk diagnosis serta dukungan perbaikan; migrasi dari alat warisan seperti Inspect.exe direkomendasikan
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["Memeriksa properti UIA"]
    fast --> fastf["Mendeteksi masalah berdampak tinggi"]
    ts --> tsf["Membantu diagnosis dan perbaikan"]
    legacy["Inspect.exe dll."] -.->|migrasi direkomendasikan| ai

Gambar 15: Accessibility Insights punya tiga cara pakai — memeriksa, mendeteksi, mendiagnosis — dan menjadi tujuan migrasi dari alat warisan.

8.2. Pemeriksaan langsung dengan pembaca layar

Pemeriksaan otomatis alat hanya dapat mendeteksi masalah yang dinilai secara mekanis. Pada akhirnya, selalu telusuri operasi bisnis sungguhan satu putaran penuh dengan pembaca layar. Narrator bawaan Windows dapat langsung dijalankan dengan Ctrl+Windows+Enter, dan NVDA dapat dipasang secara gratis.¹¹ Kiat pemeriksaannya: tanpa melihat layar (atau dengan menonaktifkan tampilan), andalkan hanya pengumuman dan coba selesaikan tugas nyata seperti “menginput satu pesanan lalu mengonfirmasinya”. Masalah seperti urutan pengumuman kacau meski nama sudah ada, atau fokus yang keluar dari modal, hanya ditemukan di lapangan.

flowchart TB
    accTitle: Menggabungkan verifikasi alat dan pemeriksaan langsung
    accDescr: Pemeriksaan otomatis seperti FastPass hanya dapat mendeteksi masalah yang dinilai secara mekanis; sisanya ditelusuri dengan pembaca layar melalui operasi bisnis satu putaran untuk menemukan masalah urutan pengumuman dan fokus di lapangan
    tool["Pemeriksaan otomatis alat"] --> kikai["Masalah yang dapat dinilai secara mekanis"]
    tool -.-> nokori["Masalah yang tidak terdeteksi tetap ada"]
    nokori --> sr["Pemeriksaan langsung dengan pembaca layar"]
    sr --> task["Menelusuri operasi bisnis satu putaran"]
    task --> mieru["Masalah urutan pengumuman dan fokus"]

Gambar 16: Inventarisasi masalah mekanis dengan pemeriksaan otomatis, lalu temukan sisanya lewat pemeriksaan langsung dengan pembaca layar.

8.3. Memasukkan ke alur pengembangan dan efek sinergi dengan pengujian otomatis UI

Agar verifikasi tidak bergantung pada individu, disarankan memasukkan daftar periksa berikut ke item tinjauan layar baru.

Dan satu lagi. Pengujian otomatis UI dengan FlaUI dan sejenisnya dibangun di atas UIA yang sama dengan pembaca layar. Name dan pola yang ditata untuk aksesibilitas menjadi bagian kode uji, dan AutomationId yang dirancang untuk pengujian memudahkan debug di Live Inspect. Sebaliknya, UI yang tidak muncul di pohon UIA tidak terlihat baik dari uji maupun dari teknologi bantu. Aksesibilitas dan kemudahan pengujian adalah dua sisi investasi yang sama (“Pengujian otomatis UI aplikasi desktop Windows”).

flowchart TB
    accTitle: Efek sinergi aksesibilitas dan pengujian otomatis UI
    accDescr: Pembaca layar dan pengujian otomatis UI seperti FlaUI berfondasi pada UIA yang sama, sehingga Name dan pola yang ditata dapat dipakai dari keduanya, dan UI yang tidak muncul di pohon UIA tidak terlihat dari mana pun
    uia["Merapikan pohon UIA"] --> sr["Dapat dibaca pembaca layar"]
    uia --> test["Dapat dipakai pengujian otomatis UI"]
    sr -.-> both["Dua sisi investasi yang sama"]
    test -.-> both
    hidden["UI yang tidak muncul di UIA"] -.-> invisible["Tidak terlihat dari keduanya"]

Gambar 17: Karena duduk di fondasi UIA yang sama, merapikan pohon UIA berdampak pada teknologi bantu dan pengujian otomatis UI.

9. Cara menetapkan prioritas — jangan perbaiki semua layar sekaligus

Merapikan sekaligus sistem inti yang punya ratusan layar tidak realistis, baik dari sisi biaya maupun mutu. Cara yang kami rekomendasikan adalah tiga tahap berikut.

1. Perbaiki mulai dari layar yang dipakai pengguna itu dalam pekerjaan. Akomodasi wajar adalah proses menanggapi permintaan orang yang bersangkutan secara individual.¹ Minta orang itu sendiri mengoperasikan pekerjaan nyata dengan pembaca layar, lalu identifikasi bersama di mana alur macet. Dalam banyak kasus, layar yang dipakai sehari-hari menyempit ke beberapa hingga belasan, dan masalah fatal di dalamnya (tombol tanpa nama, tombol konfirmasi yang tidak bisa ditekan dari keyboard) dapat diselesaikan dalam satuan beberapa hari.
2. Pengembangan baru memenuhi standar dari awal. Tambahkan daftar periksa bab 8 ke definisi selesai (Definition of Done), dan buat layar baru sudah didukung dari awal. Berbeda dengan perbaikan belakangan, kenaikan biaya kecil jika dimasukkan saat perancangan.
3. Perluas ke samping lewat perbaikan kontrol bersama. Jika nilai bawaan AccessibleName atau AutomationPeer diimplementasikan pada komponen bersama seperti dialog pencarian, kisi, dan input tanggal internal, dampaknya berlaku sekaligus ke semua layar yang memakainya. Itu langkah dengan rasio biaya–manfaat jauh lebih tinggi daripada menyentuh layar satu per satu.

flowchart TB
    accTitle: Tiga tahap prioritas perbaikan
    accDescr: Perbaiki mulai dari layar yang dipakai pengguna dalam pekerjaan, pengembangan baru memenuhi standar lewat daftar periksa, dan perluas ke semua layar lewat perbaikan kontrol bersama
    s1["1. Perbaiki mulai dari layar yang dipakai pengguna"] --> s2["2. Bagian baru memenuhi standar"] --> s3["3. Perluas ke samping lewat kontrol bersama"]
    s3 -.-> all["Berlaku sekaligus ke semua layar yang memakainya"]

Gambar 18: Bukan perbaikan massal semua layar, melainkan maju dengan tiga tahap: layar yang dipakai, bagian baru, dan komponen bersama.

Dan yang sama pentingnya dengan dukungan teknis adalah catatan dialog. Akomodasi wajar adalah proses “berdialog dan menyesuaikan secara individual”, bukan menangani semua permintaan secara sempurna. Untuk perbaikan yang bebannya terlalu berat, menelaah bersama orang yang bersangkutan dan menyepakati alternatif (menjalankan pekerjaan terkait di layar lain, menyediakan ekspor CSV, menutupinya dengan operasional) juga konsekuensi sah dari dialog konstruktif.¹ Mencatat apa yang diminta, apa yang ditangani, dan apa yang dijadikan alternatif menjadi bukti kejujuran organisasi.

flowchart TB
    accTitle: Alur dialog konstruktif dan pencatatan
    accDescr: Tanggapi permintaan dari penyandang disabilitas lewat dialog konstruktif, laksanakan perbaikan yang dapat ditangani, dan untuk perbaikan yang bebannya terlalu berat telaah serta sepakati alternatif bersama orang yang bersangkutan, lalu catat apa yang diminta, apa yang ditangani, dan apa yang dijadikan alternatif
    req["Permintaan"] --> talk["Dialog konstruktif"]
    talk --> q{"Beban terlalu berat?"}
    q -->|Tidak| kaishu["Tangani dengan perbaikan"]
    q -->|Ya| alt["Telaah dan sepakati alternatif"]
    kaishu --> rec["Catat prosesnya"]
    alt --> rec

Gambar 19: Dalam dialog konstruktif, sepakati perbaikan atau alternatif bersama orang yang bersangkutan, dan sisakan prosesnya dalam catatan.

10. Ringkasan

• Amandemen Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas yang berlaku April 2024 mewajibkan pelaku usaha juga menyediakan akomodasi wajar. Bidang ketenagakerjaan sudah menjadi kewajiban pemberi kerja sejak 2016 berdasarkan Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas. Merapikan aplikasi di muka termasuk “penataan lingkungan” (kewajiban upaya), dan semakin maju semakin ringan tanggapan individual.
• Kriteria teknis terkumpul di WCAG (JIS X 8341-3:2016), dan kerangka pikir yang sama dapat diterapkan pada aplikasi desktop lewat WCAG2ICT.
• Pembaca layar membaca aplikasi lewat UI Automation. Tiga komponen — pohon UIA, properti (Name/ControlType/AutomationId), dan pola kontrol — adalah fondasinya.
• Prioritas tertinggi adalah Name. WinForms memakai AccessibleName serta kaitan Label dan urutan tab; WPF memakai AutomationProperties.Name/LabeledBy; kontrol kustom memakai AutomationPeer.
• Dapat mencapai semua fungsi hanya dengan keyboard adalah kriteria keberhasilan WCAG dan sekaligus produktivitas semua operator. Rapikan urutan tab, access key, dan indikasi fokus.
• Dasar warna adalah tiga poin: rasio kontras 4,5:1, jangan hanya mengandalkan warna, dan hormati warna sistem pada tema kontras.
• Verifikasi menggabungkan FastPass+Live Inspect di Accessibility Insights dengan pemeriksaan langsung Narrator/NVDA, lalu dimasukkan ke alur pengembangan sebagai daftar periksa layar baru.
• Jangan perbaiki semua layar sekaligus; maju dengan urutan layar yang dipakai pengguna → standar untuk bagian baru → perluasan kontrol bersama. Akomodasi wajar adalah proses dialog, dan catatan prosesnya melindungi organisasi.

Langkah pertama yang disarankan: pilih satu layar andalan internal, jalankan FastPass di Accessibility Insights for Windows, lalu telusuri pekerjaan hanya dengan tombol Tab. Dalam 30 menit, posisi aplikasi sendiri terlihat jauh lebih konkret.

Artikel terkait

• Pengujian otomatis UI aplikasi desktop Windows — mekanisme UI Automation dan uji yang tidak rapuh dengan FlaUI
• Perancangan UX aplikasi Windows - prioritas menurut lingkungan pemakaian
• Dukungan DPI tinggi WinForms — penyebab buram dan rusak di monitor 4K, serta penanganan realistis
• Dukungan DPI tinggi WPF — penyebab buram dan berbayang meski “seharusnya kuat terhadap DPI”, serta penanganannya
• Mengapa Komura Soft membuat situs dengan sistem desain Digital Agency — murah dan bermutu dapat berjalan bersama
• Jebakan font dan aksara Jepang — cara menangani JIS2004, pemilih varian, dan gaiji di aplikasi bisnis

Area konsultasi terkait

Di 合同会社 Komura Soft, kami menangani konsultasi perbaikan aksesibilitas aplikasi bisnis WinForms/WPF (dukungan pembaca layar, merapikan operasi keyboard, dukungan tema kontras), implementasi AutomationPeer pada kontrol bersama, serta diagnosis kondisi saat ini dan penetapan prioritas dengan Accessibility Insights. Boleh mulai dari tahap “ingin memastikan apakah karyawan dapat memakai aplikasi kami dengan pembaca layar”.

• Pengembangan aplikasi Windows
• Konsultasi teknis dan tinjauan perancangan
• Kontak

Tautan rujukan

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apakah dukungan aksesibilitas untuk aplikasi bisnis diwajibkan oleh hukum?

Amandemen 2021 terhadap Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas berlaku pada 1 April 2024, dan penyediaan akomodasi wajar kepada penyandang disabilitas menjadi kewajiban bagi pelaku usaha juga. Akomodasi wajar adalah tindakan yang, ketika penyandang disabilitas mengajukan permintaan, menghapus hambatan individual dalam batas yang tidak menjadi beban berlebihan; merapikan aplikasi agar lebih mudah dipakai dari awal diposisikan sebagai kewajiban upaya yang disebut "penataan lingkungan". Bidang ketenagakerjaan, seperti hubungan karyawan dan perusahaan, tidak diatur undang-undang itu melainkan Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas, yang telah mewajibkan pemberi kerja menyediakan akomodasi wajar sejak amandemen yang berlaku April 2016. Dengan kata lain, situasi "karyawan tidak bisa memakai aplikasi bisnis" sudah lama berada di ranah kewajiban. Sejauh mana harus ditangani bergantung pada situasi masing-masing, jadi konfirmasikan sumber primer dari Cabinet Office dan Kementerian Kesehatan, Tenaga Kerja, dan Kesejahteraan, lalu putuskan melalui dialog dengan orang yang bersangkutan.

Bagaimana pembaca layar membaca aplikasi desktop Windows?

Pembaca layar seperti Narrator dan NVDA membaca UI aplikasi melalui fondasi aksesibilitas yang disebut UI Automation (UIA). Sisi aplikasi memublikasikan elemen di layar dalam struktur bernama pohon UIA; setiap elemen memiliki properti seperti Name (tujuan) dan ControlType (jenis), serta pola kontrol seperti Invoke (tekan) dan Value (nilai). Pembaca layar mengumumkan informasi ini sebagai "tombol Konfirmasi pesanan" dan mengoperasikan elemen lewat pola. Kontrol standar WinForms dan WPF sudah memiliki mekanisme ini dari awal, jadi pekerjaan utama pengembang adalah tidak membiarkan Name kosong, memastikan UI dapat dioperasikan dari keyboard, dan mengimplementasikan informasi pada kontrol kustom.

Pada aplikasi WinForms yang sudah ada, apa yang harus dikerjakan lebih dulu?

Jalur terpendek adalah menjalankan FastPass di Accessibility Insights for Windows pada layar sasaran, lalu menginventarisasi kontrol yang Name-nya kosong serta masalah urutan tab. Perbaikan dimulai dengan menyetel AccessibleName pada tombol yang hanya berupa ikon, mengaitkan Label pada urutan tab tepat sebelum field input, dan merapikan TabIndex agar selaras dengan urutan visual. Setelah itu jalankan Narrator atau NVDA dan telusuri operasi bisnis sungguhan tanpa melihat layar, lalu konfirmasikan di mana alur macet. Tidak perlu memperbaiki semua layar sekaligus; memulai dari layar yang benar-benar dipakai seseorang, dan membuat layar baru memenuhi standar lewat daftar periksa, adalah pendekatan yang realistis.

Apa yang harus dilakukan untuk dukungan kontras tinggi (tema kontras)?

Dasarnya adalah tidak meng-hard-code warna dan menghormati warna sistem. Di WinForms, biarkan ForeColor/BackColor pada nilai bawaan atau pakai SystemColors, tentukan status dengan SystemInformation.HighContrast, dan ikuti peralihan lewat event UserPreferenceChanged. Di WPF dan WinUI, jika merujuk sumber daya kelas SystemColors, peralihan tema diikuti secara otomatis. Pada saat yang sama, hentikan penyampaian informasi yang "hanya mengandalkan warna" — misalnya menandai kesalahan hanya dengan merah — dan gabungkan dengan ikon atau teks. Bahkan pada tema biasa, memakai kriteria WCAG rasio kontras teks 4,5:1 atau lebih sebagai acuan juga membuat UI lebih mudah dibaca di lantai kerja yang redup dan bagi pengguna yang lebih tua.

Apakah dukungan aksesibilitas juga membantu pengujian otomatis UI?

Membantu. Alat pengujian otomatis UI seperti FlaUI dibangun di atas UI Automation yang sama yang dipakai pembaca layar. Name, ControlType, dan pola kontrol yang ditata untuk aksesibilitas dapat dipakai apa adanya dari kode uji, dan AutomationId yang dirancang untuk pengujian menstabilkan identifikasi elemen. Sebaliknya, UI gambar kustom yang tidak muncul di pohon UIA tidak terlihat baik oleh pembaca layar maupun oleh uji. Aksesibilitas dan pengujian otomatis adalah investasi pada fondasi yang sama, jadi menata salah satunya juga menurunkan biaya yang lain.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.