Pengantar aksesibilitas aplikasi Windows — bersiap untuk UI Automation dan persyaratan akomodasi wajar

“Rekrutmen mid-career yang tunanetra tidak dapat memakai aplikasi entri pesanan inti dengan pembaca layar. Mereka memakai peramban web dan surat tanpa kesulitan, tetapi hanya pembacaan aplikasi bisnis kita yang tidak bekerja dengan benar. Bisakah sesuatu dilakukan?” — Konsultasi semacam ini dari departemen IT pelanggan semakin meningkat.

Satu latar belakang 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 yang di pembuka (bidang ketenagakerjaan) adalah ranah Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas, yang telah mewajibkan pemberi kerja menyediakan akomodasi wajar sejak April 2016.² Gagasan bahwa “aksesibilitas adalah topik situs web dan tidak ada hubungannya dengan aplikasi Windows internal” tidak lagi bertahan, baik secara hukum maupun dalam praktik.

Di sisi lain, dari lantai pengembangan, “kita tidak tahu harus berbuat apa” adalah tempat yang jujur. Aksesibilitas untuk aplikasi desktop Windows punya lebih sedikit informasi daripada Web, dan tidak ada solusi ajaib setelah-fakta. Tidak perlu pesimis juga. Jika Anda memahami mekanisme yang dipakai pembaca layar untuk membaca aplikasi (UI Automation) dan menyerap dasar nama, keyboard, dan warna, kegunaan aplikasi bisnis meningkat secara substansial. Dan banyak dari itu adalah perbaikan yang menaikkan produktivitas setiap pengguna, dengan atau tanpa disabilitas.

Ditujukan kepada pengembang aplikasi bisnis Jepang dan staf IT, artikel ini menghubungkan dalam satu lintasan 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 lewat mekanisme, implementasi, verifikasi, dan prioritas dalam satu alur.

1. Kesimpulan lebih dulu

• Penyediaan akomodasi wajar telah menjadi kewajiban bagi pelaku usaha juga sejak 1 April 2024. Ketika penyandang disabilitas menyatakan niat agar hambatan dihapus, respons dalam rentang yang bukan beban berlebihan diperlukan. Bidang ketenagakerjaan di bawah Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas, dan itu telah menjadi kewajiban pemberi kerja sejak April 2016.¹²
• Akomodasi wajar adalah proses “merespons permintaan individual lewat dialog konstruktif”; membuat aplikasi lebih mudah dipakai di muka adalah “perbaikan lingkungan” (kewajiban upaya). Dukungan sempurna di muka bukan kewajibannya; yang penting adalah tidak menolak dialog secara sepihak.¹
• Kriteria teknis aksesibilitas terkonsentrasi di WCAG (JIS X 8341-3:2016). JIS X 8341-3:2016 adalah standar koresponden dengan isi yang sama seperti WCAG 2.0, dan WCAG2ICT milik W3C memberi panduan menerapkannya pada perangkat lunak non-Web. Aplikasi desktop dapat diperiksa dengan pemikiran 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 diumumkan hanya sebagai “tombol”. Perbaikan prioritas tertinggi adalah penamaan. WinForms memakai AccessibleName dan mengaitkan Label dengan 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. Memasang urutan tab, access key, dan indikasi fokus terhubung langsung ke efisiensi setiap pengguna.⁸
• Ambil rasio kontras teks 4,5:1 atau lebih sebagai panduan, dan jangan sampaikan informasi hanya lewat warna. Dalam tema kontras (kontras tinggi), hormati warna sistem daripada warna yang di-hard-code.⁸⁹
• Gabungkan verifikasi dengan FastPass di Accessibility Insights for Windows dan pemeriksaan langsung dengan pembaca layar. Karena mereka duduk pada fondasi UIA yang sama, pekerjaan ini juga saling menguntungkan dengan aset pengujian otomatis UI seperti FlaUI.¹⁰
• Anda tidak perlu memperbaiki setiap layar sekaligus. Urutan realistis adalah (1) dari layar yang dipakai pengguna itu, (2) pengembangan baru patuh standar, (3) gulirkan ke samping dengan memperbaiki kontrol bersama.

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

2. Memilah kerangka hukum dan standar — apa yang “menjadi kewajiban” berubah

2.1. Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas — dari April 2024, pelaku usaha juga diwajibkan menyediakan akomodasi wajar

Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas adalah undang-undang yang melarang “perlakuan diskriminatif yang tidak adil” terhadap penyandang disabilitas oleh organ administratif dan pelaku usaha, serta mensyaratkan “penyediaan akomodasi wajar”. Dalam amandemen 2021 (Reiwa 3), penyediaan akomodasi wajar oleh pelaku usaha, yang tadinya kewajiban upaya, menjadi kewajiban, dan undang-undang yang diamandemen berlaku pada 1 April 2024 (Reiwa 6).¹

Menurut leaflet Cabinet Office, penyediaan akomodasi wajar adalah merespons, dalam rentang yang bukan beban berlebihan, ketika penyandang disabilitas menyatakan niat bahwa suatu respons dibutuhkan untuk menghapus hambatan di masyarakat. Dan karena isinya berbeda menurut karakteristik disabilitas, adegan, dan situasi, sebuah “dialog konstruktif” di mana penyandang disabilitas dan pelaku usaha menumpuk dialog dan mempertimbangkan respons bersama ditekankan. Menolak dialog konstruktif secara sepihak dinyatakan berpotensi merupakan pelanggaran kewajiban menyediakan akomodasi wajar.¹

Dua pembedaan praktis penting di sini.

1. “Memiliki semuanya di tempat di muka” bukan yang menjadi kewajiban. Langkah perbaikan di muka yang ditujukan kepada jumlah tak tertentu penyandang disabilitas — sisi lunak seperti meninjau ulang manual dan pelatihan, sisi keras seperti membuat fasilitas bebas hambatan — disebut “perbaikan lingkungan”, dan ini adalah kewajiban upaya.¹ Menaruh aplikasi bisnis dalam keadaan dapat dipakai dengan pembaca layar di muka dapat dipikirkan sebagai upaya perbaikan lingkungan. Semakin jauh perbaikan lingkungan telah pergi, semakin ringan beban menyediakan akomodasi wajar individual.
2. Bidang ketenagakerjaan tidak di bawah Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas melainkan di bawah Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas. Leaflet yang sama juga menyatakan bahwa ketenagakerjaan dan kerja mengikuti ketentuan Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas.¹ Dan di bawah undang-undang itu, lewat amandemen yang berlaku April 2016 (Heisei 28), larangan diskriminasi disabilitas dalam ketenagakerjaan dan penyediaan akomodasi wajar dalam rentang yang bukan beban berlebihan telah diwajibkan bagi pemberi kerja.² Konsultasi pembuka “seorang karyawan tidak dapat memakai aplikasi bisnis” pada kenyataannya sudah lama berada di ranah kewajiban jauh sebelum 2024.

flowchart TB
    accTitle: Posisi akomodasi wajar dan perbaikan lingkungan
    accDescr: Hubungan antara pelaku usaha umum dan penyandang disabilitas di bawah Undang-Undang Penghapusan Diskriminasi terhadap Penyandang Disabilitas, dan menyediakan akomodasi wajar dengan merespons permintaan individual lewat dialog konstruktif telah menjadi kewajiban sejak April 2024; bidang ketenagakerjaan telah menjadi kewajiban pemberi kerja sejak April 2016 di bawah Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas; membuat aplikasi lebih mudah dipakai di muka adalah perbaikan lingkungan, kewajiban upaya
    scene{"Adegan mana?"}
    scene -->|Usaha + disabilitas| kaisho["Undang-undang diskriminasi"]
    scene -->|Ketenagakerjaan / kerja| koyou["Undang-undang ketenagakerjaan"]
    kaisho --> moushide["Permintaan lewat dialog"]
    moushide --> hairyo["Sediakan akomodasi"]
    hairyo -.-> hairyoN["Kewajiban sejak 2024"]
    koyou --> koyougimu["Sediakan akomodasi"]
    koyougimu -.-> koyouN["Kewajiban sejak 2016"]
    kaisho -.-> kankyo["Aplikasi lebih mudah di muka"]
    kankyo -.-> kankyoN["Perbaikan lingkungan"]
    kankyoN -.-> kankyoN2["kewajiban upaya"]
    kankyo -.-> moushide

Gambar 2: Undang-undang yang mengatur belah menurut adegan; akomodasi wajar adalah kewajiban, dan perbaikan di muka adalah perbaikan lingkungan, kewajiban upaya.

Bagaimana kasus individual diperlakukan dalam hukum bergantung pada situasinya. Artikel ini tidak masuk ke interpretasi hukum; ia berlanjut dari sudut pandang apa yang dapat dilakukan seorang insinyur ketika respons diminta. Untuk sumber primer, rujuk materi Cabinet Office dan Kementerian Kesehatan, Tenaga Kerja, dan Kesejahteraan.¹²

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

Di sisi kriteria teknis, mereka terkonsentrasi di JIS X 8341-3:2016. Standar ini adalah standar koresponden ISO/IEC 40500:2012, dan tubuh standarnya adalah isi yang sama seperti WCAG 2.0 milik W3C.³ Jika Anda ingin tahu secara konkret dari apa “dukungan aksesibilitas” terdiri, membaca kriteria keberhasilan WCAG (kini diperluas di WCAG 2.1/2.2) adalah jalur terpendek, dan terjemahan Jepang oleh WAIC juga diterbitkan.⁸

Pertanyaan “apakah WCAG adalah kriteria untuk konten Web?” adil, tetapi W3C telah menata, dalam Group Note yang disebut WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies), cara menerapkan kriteria keberhasilan WCAG 2.0/2.1/2.2 pada dokumen dan perangkat lunak non-Web.⁴ Dengan kata lain, pemikiran seperti “alternatif teks”, “kontras”, “operasi keyboard”, dan “warna bukan satu-satunya sarana” dapat diterapkan pada aplikasi desktop Windows dalam kerangka yang sama seperti Web. Bab 3 dan seterusnya artikel ini menjatuhkan pemikiran itu ke implementasi WinForms/WPF konkret.

flowchart TB
    accTitle: Hubungan antara JIS X 8341-3 dan WCAG
    accDescr: JIS X 8341-3:2016 adalah standar koresponden dengan isi yang sama seperti WCAG 2.0, dan WCAG2ICT menunjukkan cara menerapkan kriteria keberhasilan WCAG pada perangkat lunak non-Web, jadi aplikasi desktop Windows dapat diperiksa dalam kerangka yang sama
    wcag["WCAG 2.0（W3C）"] ---|Standar koresponden dengan isi yang sama| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["Terapkan pada perangkat lunak non-Web"]
    soft --> app["Aplikasi desktop Windows"]

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

3. Bagaimana teknologi bantu membaca aplikasi — trio UI Automation

3.1. Pohon UIA, properti, dan pola kontrol

Windows punya fondasi aksesibilitas yang disebut UI Automation (UIA) built-in. UIA adalah mekanisme yang membiarkan teknologi bantu seperti pembaca layar memperoleh informasi UI dan mengoperasikan UI dengan sarana selain input standar, dan ia menengahi antara sisi aplikasi (penyedia) dan sisi teknologi bantu (klien).⁵

Dunia UIA dapat dipahami sebagai trio berikut.⁵

Ketika pembaca layar memfokuskan tombol, pengumuman “tombol Konfirmasi pesanan” secara kasar adalah kombinasi Name + jenis kontrol. Ketika pengguna melakukan operasi “jalankan”, teknologi bantu menekan tombol itu lewat pola Invoke. Dengan kata lain, jika Name dan pola diekspos dengan benar ia dapat dibaca dan dioperasikan; jika tidak diekspos, sama seperti tidak ada bahkan jika terlihat di layar.

flowchart TB
    accTitle: Trio UI Automation
    accDescr: Aplikasi, sebagai penyedia, mengekspos properti dan pola kontrol setiap elemen pada pohon UIA; pembaca layar, sebagai klien, mengumumkan Name dan ControlType serta beroperasi lewat pola seperti Invoke
    app["Aplikasi（penyedia）"] --> tree["Pohon UIA"]
    tree --> prop["Properti（Name, ControlType, dan semacamnya）"]
    tree --> pat["Pola（Invoke, Value, dan semacamnya）"]
    sr["Pembaca layar（klien）"] -->|Mengumumkan| prop
    sr -->|Mengoperasikan| pat

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

3.2. Pembaca layar adalah klien UIA

Pembaca layar utama yang dipakai di Windows mencakup Narrator, built-in di Windows; NVDA,¹¹ yang gratis dan sumber terbuka; dan PC-Talker, produk komersial yang banyak dipakai di Jepang. Gaya pengumuman berbeda di antara mereka, tetapi jalur primer untuk membaca UI aplikasi desktop adalah UIA dalam setiap kasus. Itulah mengapa respons sisi aplikasi bukan “dukungan untuk pembaca layar tertentu” melainkan berkonsentrasi pada mengekspos informasi yang benar ke UIA.

flowchart TB
    accTitle: Jalur bersama pembaca layar utama
    accDescr: Jika aplikasi mengekspos informasi yang benar ke UIA, Narrator, NVDA, dan PC-Talker semuanya dapat membaca UI lewat jalur yang sama, jadi respons sisi aplikasi tidak ditujukan pada pembaca layar tertentu melainkan berkonsentrasi pada mengekspos ke UIA
    app["Aplikasi"] -->|Mengekspos informasi| uia["UI Automation（UIA）"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["Respons berkonsentrasi pada mengekspos ke UIA"]

Gambar 5: Pembaca layar utama semuanya mengambil UIA sebagai jalur, jadi respons aplikasi berkonsentrasi pada mengekspos ke UIA.

3.3. “Tombol yang Name-nya kosong” diumumkan sebagai apa?

Satu contoh konkret. Misalkan toolbar punya tombol Simpan yang hanya menampilkan ikon floppy-disk. Bagi pengguna yang melihat, ikon menyampaikan makna, tetapi jika Name dibiarkan kosong, pembaca layar mengumumkan tombol ini hanya sebagai “tombol”. Jika “Buka” dan “Cetak” di sebelahnya sama, pengguna hanya mendengar “tombol, tombol, tombol” dan tidak punya sarana untuk mengetahui mana yang mana. Panduan perbaikan aksesibilitas Microsoft juga mencantumkan tombol tanpa Name, dan gambar yang diumumkan hanya sebagai “Image”, sebagai masalah representatif yang menghentikan pekerjaan pengguna.⁷

Untungnya, baik kontrol standar WinForms maupun WPF punya dukungan UIA sejak awal, dan dalam banyak kasus Name diputuskan secara otomatis dari teks atau label. Yang rusak biasanya salah satu dari (1) hanya-ikon, tanpa bahan untuk nama, (2) tidak ada kaitan dengan label, atau (3) gambar kustom yang tidak menaruh informasi pada pohon UIA. Dua bab berikutnya melihat cara memperbaikinya per kerangka.

flowchart TB
    accTitle: Tiga cara khas pengumuman rusak
    accDescr: Pengumuman rusak ketika tidak ada bahan untuk nama karena hanya-ikon, ketika tidak ada kaitan dengan label, atau ketika gambar kustom tidak menaruh informasi pada pohon UIA, dan akhirnya diumumkan hanya sebagai tombol
    c1["Hanya-ikon, tanpa bahan"] --> broken["Name menjadi kosong"]
    c2["Tidak ada kaitan dengan label"] --> broken
    c3["Gambar kustom tidak mengeluarkan informasi"] --> broken
    broken --> result["Diumumkan hanya sebagai tombol"]

Gambar 6: Pengumuman yang rusak biasanya turun ke salah satu dari tiga pola: bahan nama tidak cukup, kaitan tidak cukup, atau gambar kustom.

4. Implementasi di WinForms — AccessibleName dan urutan tab

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

Di WinForms, kontrol yang menampilkan teks, seperti Button atau CheckBox, memakai nilai properti Text sebagai Name UIA. Di sisi lain, ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView dan semacamnya tidak menjadikan Text sebagai Name. Ini membutuhkan nama dengan sarana lain.⁶

Cara yang paling mudah dipelihara adalah menempatkan Label deskriptif di urutan tab langsung sebelumnya dari kontrol sasaran. Jika Anda menyetel TabIndex kontrol sasaran agar datang langsung setelah TabIndex Label, teks Label itu dipakai secara otomatis sebagai Name UIA. Label yang terlihat di layar dan pengumuman cocok, dan Anda tidak harus mengelola kata dua kali.⁶¹²

Jika Anda tidak dapat menempatkan Label, setel AccessibleName secara eksplisit. Anda juga dapat menyetel AccessibleDescription jika penjelasan tambahan dibutuhkan, dan AccessibleRole jika peran berbeda dari tampilan.¹³

flowchart TB
    accTitle: Bagaimana nama kontrol WinForms diputuskan
    accDescr: Untuk Button dan semacamnya, Text menjadi Name UIA apa adanya; untuk kontrol seperti TextBox yang Text-nya tidak dipakai ulang, teks Label yang ditempatkan di urutan tab langsung sebelumnya dipakai; jika Anda tidak dapat menempatkan Label, setel AccessibleName secara eksplisit
    ctrl["Kontrol"] --> qtext{"Jenis yang Text-nya menjadi Name?"}
    qtext -->|Ya| usetext["Text menjadi Name apa adanya"]
    qtext -->|Tidak| qlabel{"Label di urutan tab langsung sebelumnya?"}
    qlabel -->|Ya| uselabel["Teks Label dipakai sebagai Name"]
    qlabel -->|Tidak| explicit["Setel AccessibleName secara eksplisit"]

Gambar 7: Untuk Name WinForms, pilih cara memutuskannya dalam urutan Text, Label di urutan tab langsung sebelumnya, AccessibleName.

// An icon-only toolbar button: state the name for announcement explicitly
saveToolStripButton.AccessibleName = "Save";

// An image-only button: name + a supplementary explanation
btnSearchCustomer.AccessibleName = "Search customer";
btnSearchCustomer.AccessibleDescription = "Search the customer master by customer code or name";

// Set it directly on an input field where you cannot place a Label in the immediately preceding tab order
txtOrderNo.AccessibleName = "Order number";

// A PictureBox reused as a chart display: match the role to the reality as well
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Monthly order-count chart";

Sebagai peringatan, jika Anda menyetel AccessibleName sekali di panel Properties Visual Studio lalu mengosongkannya, pengaturan string-kosong dapat tetap di berkas desainer dan mengganggu resolusi nama bawaan. Hapus baris yang bersesuaian dari berkas desainer.⁶

flowchart TB
    accTitle: Masalah AccessibleName string-kosong yang tertinggal
    accDescr: Jika Anda menyetel AccessibleName sekali di panel Properties lalu mengosongkannya, pengaturan string-kosong tetap di berkas desainer dan mengganggu resolusi nama bawaan, jadi Anda memperbaikinya dengan menghapus baris yang bersesuaian dari berkas desainer
    set["Setel AccessibleName"] --> erase["Kosongkan di panel Properties"]
    erase --> remain["Pengaturan string-kosong tertinggal"]
    remain --> block["Mengganggu resolusi nama bawaan"]
    block -.-> fix["Hapus baris yang bersesuaian dari berkas desainer"]

Gambar 8: Mengosongkannya di panel Properties tetap meninggalkan string kosong, jadi Anda memperbaikinya dengan menghapus baris yang bersesuaian dari berkas desainer.

4.2. Perbaikan umum pada layar entri pesanan

Tempat yang sebenarnya sering kami perbaiki di aplikasi bisnis dirangkum sebagai daftar periksa.

Masing-masing adalah perbaikan beberapa baris, tetapi bagi pengguna pembaca layar itu cabang antara “layar yang tidak dapat dipakai” dan “layar yang dapat dipakai”.

5. Implementasi di WPF — AutomationProperties dan AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

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

TextBox punya peringatan penting. Text milik TextBlock dipakai ulang sebagai Name, tetapi Text milik TextBox diekspos di sisi properti Value UIA dan tidak menjadi Name. Untuk field input, mengaitkan TextBlock label-tampilan dengan LabeledBy adalah kandidat pertama. Pengumuman dan tampilan di layar cocok, dan Anda juga menghindari mengelola kata dua kali.¹⁴

<!-- An input field: associate the display label with LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="Order number" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- An icon-only button: state the name, and a supplement if needed -->
<Button
    AutomationProperties.Name="Confirm order"
    AutomationProperties.HelpText="Confirm the order being entered and allocate inventory">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: Bagaimana nama kontrol WPF diputuskan
    accDescr: Kontrol yang Content-nya adalah string memakai konten itu sebagai Name; jika tidak, mengaitkan label tampilan di dekatnya dengan LabeledBy adalah kandidat pertama; jika itu juga absen, nyatakan AutomationProperties.Name; Text milik TextBox diekspos di sisi Value, bukan sebagai Name
    ctrl["Kontrol"] --> qc{"Apakah Content sebuah string?"}
    qc -->|Ya| auto["Konten menjadi Name"]
    qc -->|Tidak| ql{"Label tampilan di dekatnya?"}
    ql -->|Ya| lb["Kaitkan dengan LabeledBy"]
    ql -->|Tidak| nm["Setel Name secara eksplisit"]
    tbx["Text milik TextBox"] -.-> val["Diekspos sebagai Value, bukan Name"]

Gambar 9: Untuk Name WPF, putuskan dalam urutan string Content, LabeledBy, pengaturan eksplisit; Text milik TextBox tidak menjadi Name.

Informasi tambahan yang tidak muat di Name dapat diekspos dengan AutomationProperties.HelpText.⁷ Juga, AutomationId adalah pengenal yang dipakai untuk identifikasi elemen dalam pengujian otomatis UI, jadi memutuskan konvensi penamaan pada waktu desain layar terbayar nanti (dibahas secara mendalam di “Pengujian otomatis UI untuk aplikasi desktop Windows”).

5.2. Kontrol kustom membutuhkan AutomationPeer

Kontrol kustom yang Anda gambar sendiri tidak dapat, apa adanya, mengekspos informasi yang bermakna pada pohon UIA. Di WPF Anda menimpa OnCreateAutomationPeer pada kelas turunan UIElement dan mengembalikan kelas turunan AutomationPeer untuk mengekspos nama, jenis, dan pola. Jika Anda mewarisi kontrol yang sudah ada, mewarisi Peer yang bersesuaian (ButtonBaseAutomationPeer untuk ButtonBase) membiarkan Anda mengambil alih perilaku yang sudah diimplementasikan.¹⁵

flowchart TB
    accTitle: Bagaimana informasi diekspos lewat AutomationPeer
    accDescr: Kontrol kustom mengekspos nama, jenis, dan pola dengan menimpa OnCreateAutomationPeer dan mengembalikan kelas turunan AutomationPeer; jika Anda mewarisi kontrol yang sudah ada, warisi Peer yang bersesuaian dan ambil alih perilaku yang sudah diimplementasikan
    custom["Kontrol kustom"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Kembalikan kelas turunan Peer"]
    peer --> pub["Ekspos nama, jenis, dan pola"]
    inherit["Warisi kontrol yang sudah ada"] -.-> basepeer["Warisi Peer yang bersesuaian"]
    basepeer -.-> reuse["Ambil alih perilaku yang sudah diimplementasikan"]

Gambar 10: Kontrol kustom mengembalikan Peer dari OnCreateAutomationPeer dan mengekspos informasi ke UIA.

// An example of a control that custom-draws line status as a coloured lamp
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 ? "Line status: online" : "Line status: offline";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Raise a UIA property-changed event the moment the value changes. Without this,
        // a screen reader keeps the old name and cannot notice the change of state
        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; // Text-equivalent if it is a status display with no operation

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

Mengembalikan nama tidak cukup; memberitahunya dengan event saat ia berubah juga adalah pekerjaan Peer. Teknologi bantu tidak punya waktu sendiri untuk mengambil ulang nilai, jadi implementasi yang tidak menaikkan event perubahan berada dalam keadaan “benar hanya ketika ditanya lagi”, dan pengguna pembaca layar tidak diberitahu tentang perubahan state.

sequenceDiagram
    accTitle: Alur memberitahu pembaca layar tentang perubahan state
    accDescr: Saat nilai kontrol berubah, AutomationPeer menaikkan event perubahan properti Name; teknologi bantu tidak mengambil ulang sendiri, jadi tanpa event ia tetap pada nama lama dan tidak dapat menyadari perubahan
    participant c as Kontrol
    participant p as AutomationPeer
    participant s as Pembaca layar
    c->>p: Nilai IsOnline berubah
    p->>s: Naikkan event perubahan properti Name
    s->>s: Umumkan state baru
    Note over s: Tanpa event ia tetap pada nama lama

Gambar 11: Perubahan nilai mencapai pembaca layar hanya ketika AutomationPeer memberitahunya dengan event perubahan.

Jika kontrol kustom punya operasi (dapat ditekan, nilainya dapat diubah, dapat dipilih), Anda menimpa GetPattern dan menyediakan antarmuka pola seperti IInvokeProvider atau IRangeValueProvider.¹⁵ Poinnya adalah bahwa jika Anda membangun Peer juga di sisi pustaka-kontrol-bersama, setiap layar yang memakainya menjadi didukung secara otomatis. Itu fondasi “gulirkan ke samping” Bab 9.

6. Bisakah Anda mencapai setiap fungsi dari keyboard saja?

Kriteria keberhasilan WCAG 2.1.1 (Keyboard) mensyaratkan bahwa semua fungsionalitas konten dapat dioperasikan lewat antarmuka keyboard.⁸ Pengguna pembaca layar pada prinsipnya tidak memakai mouse, jadi fungsi yang tidak dapat Anda capai dari keyboard sama seperti fungsi yang tidak ada. Sudut pandang pemeriksaan adalah sebagai berikut.

Walkthrough aksesibilitas WinForms juga mencantumkan, sebagai dasar, menempatkan label di urutan tab langsung sebelumnya dari field input, dan menaruh access key pada kontrol dan menu yang ingin dipindah pengguna.¹²

Yang ingin kami tekankan adalah bahwa ini bukan “biaya ekstra untuk dukungan disabilitas”. Dalam pekerjaan rutin seperti entri pesanan, apakah Anda dapat menyelesaikan input tanpa melepaskan tangan dari posisi home adalah yang memutuskan throughput operator apa adanya. Urutan tab yang kacau atau operasi yang mensyaratkan mouse adalah cacat yang mencukur sedikit produktivitas setiap pengguna setiap hari. Dukungan aksesibilitas dan efisiensi keyboard hanyalah dua nama untuk pekerjaan yang sama (untuk prioritas menurut lingkungan pemakaian, lihat juga “Desain UX aplikasi Windows”).

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

Gambar 12: Merapikan operasi keyboard mewujudkan dukungan teknologi bantu dan efisiensi setiap pengguna pada saat yang sama; fungsi hanya-mouse sama seperti tidak ada.

7. Warna dan kontras — 4,5:1 dan “warna bukan satu-satunya sarana”

7.1. Panduan rasio kontras adalah 4,5:1

Kriteria keberhasilan WCAG 1.4.3 (Contrast (Minimum)) mensyaratkan rasio kontras setidaknya 4,5:1 untuk teks dan gambar teks, dan setidaknya 3:1 untuk teks besar.⁸ Desain modern yang menempatkan teks abu-abu muda pada latar putih tidak jarang gagal memenuhi kriteria ini. Pengguna aplikasi bisnis mencakup orang yang penglihatan dan penglihatan warnanya telah berubah dengan usia, dan orang yang memakainya di lingkungan redup seperti pabrik. Biasakan mengukur dengan pemeriksa kontras pada tinjauan desain.

7.2. Jangan sampaikan informasi hanya lewat warna

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

• Menampilkan baris kesalahan hanya dengan teks merah → juga sediakan ikon kesalahan dan kolom pesan
• Menampilkan field wajib hanya dengan warna label → tambahkan “*” atau kata “Wajib”
• Menampilkan status hanya dengan warna lampu → jadikan warna + bentuk, atau kata (“Berjalan”, “Berhenti”)

Mengingat keragaman penglihatan warna, ini juga bukan “respons khusus” melainkan dasar desain tampilan.

flowchart TB
    accTitle: Mengganti informasi yang disampaikan hanya lewat warna
    accDescr: Tampilan yang menunjukkan kesalahan hanya dengan teks merah diganti dengan ikon kesalahan plus kolom pesan; tampilan yang menunjukkan field wajib hanya dengan warna label diganti dengan menambah kata Wajib; tampilan yang menunjukkan status hanya dengan warna lampu diganti dengan menggabungkan bentuk atau kata
    err["Kesalahan hanya teks merah"] --> erra["Juga sediakan ikon dan kata"]
    req["Wajib hanya dari warna label"] --> reqa["Tambahkan kata Wajib"]
    lamp["Status hanya dari warna lampu"] --> lampa["Gabungkan warna dengan bentuk atau kata"]

Gambar 13: Contoh khas menyampaikan hanya lewat warna diganti dengan menggabungkan ikon, kata, serta bentuk atau teks.

7.3. Mengikuti tema kontras (kontras tinggi)

Windows punya tema kontras (dulu kontras tinggi) yang beralih ke skema warna dengan pemisahan kuat latar depan dan latar belakang; pengguna dapat memilih dan menyunting tema built-in yang dirancang agar rasio kontras umumnya 7:1 atau lebih.⁹ Prinsip di sisi aplikasi sederhana: jangan hard-code warna; hormati warna sistem.

• WinForms: jika Anda membiarkan ForeColor/BackColor pada bawaan, pengaturan warna pengguna dipakai. Di tempat Anda telah menerapkan warna sendiri, nilai dengan SystemInformation.HighContrast, beralih ke skema berbasis SystemColors, dan ikuti perubahan pengaturan dengan event UserPreferenceChanged.¹²
• WPF/WinUI: jika Anda merujuk sumber daya kelas SystemColors, Anda mengikuti peralihan tema. Tempat yang Anda isi dengan kuas sendiri menjadi penyebab kerusakan.⁹

flowchart TB
    accTitle: Mengikuti tema kontras
    accDescr: Tempat di mana warna di-hard-code rusak pada peralihan ke tema kontras, jadi beralih ke skema berbasis SystemColors dan ikuti dengan event perubahan pengaturan; jika Anda merujuk warna sistem Anda dapat mengikuti warna pengguna secara otomatis
    theme["Beralih ke tema kontras"] --> qh{"Bagaimana warna ditentukan?"}
    qh -->|Di-hard-code| broken["Skema warna rusak"]
    qh -->|Rujukan warna sistem| ok["Secara otomatis mengikuti warna pengguna"]
    broken -.-> fix["Beralih ke SystemColors"]
    fix -.-> ev["Ikuti dengan event perubahan pengaturan"]

Gambar 14: Hanya tempat di mana warna di-hard-code yang rusak di bawah tema kontras; rujukan warna sistem mengikuti secara otomatis.

Juga, pengguna dengan penglihatan rendah sering memakai pembesaran OS tinggi (penskalaan DPI), jadi dukungan DPI tinggi juga bagian dari dukungan aksesibilitas. Aplikasi yang tata letaknya rusak pada 125%–200% tidak dapat dipakai pada titik itu. Lihat “Dukungan DPI tinggi di WinForms” dan “Dukungan DPI tinggi WPF” untuk rinciannya.

8. Verifikasi dalam praktik — Accessibility Insights dan pemeriksaan langsung pembaca layar

8.1. Accessibility Insights for Windows

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

• Live Inspect: cukup arahkan mouse ke elemen atau fokuskan dengan keyboard, dan Anda dapat mengonfirmasi properti UIA-nya (Name, ControlType, pola, dan semacamnya). Sarana terpendek untuk melihat “apa Name tombol ini”.
• FastPass: pemeriksaan ringan yang mendeteksi masalah aksesibilitas berdampak tinggi dalam kurang dari lima 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 Anda dapat berjalan langsung ke panduan perbaikan per kerangka yang juga dikutip artikel ini.

Inspect.exe dan AccEvent, termasuk dalam Windows SDK, juga dapat mengonfirmasi pohon UIA dan properti, tetapi mereka diposisikan sebagai alat warisan, dan pindah ke Accessibility Insights kini direkomendasikan.¹⁰

flowchart TB
    accTitle: Tiga pemakaian Accessibility Insights
    accDescr: Accessibility Insights for Windows menyediakan mengonfirmasi properti UIA dengan Live Inspect, pemeriksaan ringan masalah berdampak tinggi dengan FastPass, dan bantuan mendiagnosis serta memperbaiki masalah dengan Troubleshooting; pindah dari alat warisan seperti Inspect.exe direkomendasikan
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["Konfirmasi properti UIA"]
    fast --> fastf["Deteksi masalah berdampak tinggi"]
    ts --> tsf["Bantu diagnosis dan perbaikan"]
    legacy["Inspect.exe dan semacamnya"] -.->|Pindah direkomendasikan| ai

Gambar 15: Accessibility Insights punya tiga pemakaian konfirmasi, deteksi, dan diagnosis, dan adalah tujuan pindah dari alat warisan.

8.2. Pemeriksaan langsung dengan pembaca layar

Yang dapat dideteksi pemeriksaan otomatis alat hanyalah masalah yang dapat dinilai secara mekanis. Pada akhirnya, selalu telusuri operasi bisnis sungguhan dengan pembaca layar. Narrator built-in Windows dapat dimulai segera dengan Ctrl+tombol Windows+Enter, dan NVDA dapat diperkenalkan secara gratis.¹¹ Trik pemeriksaannya adalah mencoba, tanpa melihat layar (atau dengan tampilan mati), hanya mengandalkan pengumuman, apakah Anda dapat menyelesaikan tugas sungguhan seperti “masukkan satu pesanan dan konfirmasikan”. Masalah seperti nama ada tetapi urutan pengumuman tidak koheren, atau fokus lolos ke luar modal, hanya ditemukan secara langsung.

flowchart TB
    accTitle: Menggabungkan verifikasi alat dan pemeriksaan langsung
    accDescr: Yang dapat dideteksi pemeriksaan otomatis seperti FastPass hanyalah masalah yang dapat dinilai secara mekanis; sisanya ditemukan secara langsung dengan menelusuri operasi bisnis sungguhan dengan pembaca layar dan menemukan masalah urutan-pengumuman serta fokus
    tool["Pemeriksaan otomatis alat"] --> kikai["Masalah yang dapat dinilai secara mekanis"]
    tool -.-> nokori["Masalah yang tidak dapat dideteksinya tetap"]
    nokori --> sr["Pemeriksaan langsung dengan pembaca layar"]
    sr --> task["Telusuri operasi bisnis"]
    task --> mieru["Masalah urutan-pengumuman dan fokus"]

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

8.3. Membangunnya ke dalam alur pengembangan, dan manfaat bersama dengan pengujian otomatis UI

Agar verifikasi tidak menjadi bergantung-orang, kami merekomendasikan membangun daftar periksa berikut ke dalam item tinjauan untuk layar baru.

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

flowchart TB
    accTitle: Manfaat bersama aksesibilitas dan pengujian otomatis UI
    accDescr: Pembaca layar dan pengujian otomatis UI seperti FlaUI dibangun di atas UIA yang sama, jadi Name dan pola yang Anda pasang dapat dipakai dari keduanya, dan UI yang tidak muncul di pohon UIA tidak terlihat dari mana pun
    uia["Merapikan pohon UIA"] --> sr["Pembaca layar dapat membacanya"]
    uia --> test["Dapat dipakai dalam pengujian otomatis UI"]
    sr -.-> both["Dua sisi investasi yang sama"]
    test -.-> both
    hidden["UI yang tidak muncul di UIA"] -.-> invisible["Tidak terlihat dari mana pun"]

Gambar 17: Karena mereka duduk pada fondasi UIA yang sama, merapikan pohon UIA terbayar baik untuk teknologi bantu maupun pengujian otomatis UI.

9. Cara menetapkan prioritas — jangan perbaiki setiap layar sekaligus

Memperbaiki sistem inti ratusan layar sekaligus tidak realistis baik dalam biaya maupun mutu. Pendekatan yang kami rekomendasikan adalah tiga tingkat berikut.

1. Perbaiki dari layar yang dipakai pengguna itu dalam pekerjaan. Akomodasi wajar adalah proses merespons secara individual permintaan dari orang yang bersangkutan.¹ Pertama minta orang itu mengoperasikan pekerjaan aktual dengan pembaca layar, dan identifikasi bersama di mana mereka macet. Dalam banyak kasus layar yang dipakai dalam kerja sehari-hari menyempit ke beberapa hingga belasan, dan masalah fatal di antaranya (tombol tanpa nama, tombol konfirmasi yang tidak dapat ditekan dari keyboard) dapat diselesaikan dalam perbaikan berhari-hari.
2. Buat pengembangan baru patuh standar. Tambahkan daftar periksa Bab 8 ke Definition of Done, dan bangun layar baru yang didukung sejak awal. Tidak seperti perbaikan setelah-fakta, kenaikan biaya membangunnya pada waktu desain sedikit.
3. Gulirkan ke samping dengan memperbaiki kontrol bersama. Jika Anda mengimplementasikan AccessibleName bawaan atau AutomationPeer pada bagian internal bersama seperti dialog pencarian, kisi, atau input tanggal, ia berlaku secara batch pada setiap layar yang memakainya. Itu langkah yang jauh lebih hemat biaya daripada menyentuh layar individual satu per satu.

flowchart TB
    accTitle: Tiga tingkat prioritas perbaikan
    accDescr: Perbaiki dari layar yang dipakai pengguna dalam pekerjaan, buat pengembangan baru patuh standar dengan daftar periksa, dan gulirkan ke setiap layar dengan memperbaiki kontrol bersama
    s1["1. Perbaiki dari layar yang dipakai pengguna"] --> s2["2. Pekerjaan baru patuh standar"] --> s3["3. Gulirkan ke samping dengan kontrol bersama"]
    s3 -.-> all["Berlaku secara batch pada setiap layar yang memakainya"]

Gambar 18: Maju bukan dengan memperbaiki setiap layar sekaligus melainkan dalam tiga tingkat layar yang dipakai, pekerjaan baru, dan bagian bersama.

Dan catatan dialog sama pentingnya dengan respons teknis. Akomodasi wajar adalah proses “berdialog dan menyesuaikan secara individual”, bukan memenuhi penuh setiap permintaan. Mempertimbangkan sarana alternatif dengan orang itu (melakukan pekerjaan itu di layar lain, menyiapkan ekspor CSV, menutupinya dalam operasi) dan menyepakati, untuk perbaikan yang bebannya terlalu berat, juga adalah hasil sah dialog konstruktif.¹ Mencatat apa yang diminta, apa yang direspons, dan apa yang dijadikan sarana alternatif menjadi bukti itikad baik organisasi.

flowchart TB
    accTitle: Alur dialog konstruktif dan catatan
    accDescr: Respons permintaan dari penyandang disabilitas lewat dialog konstruktif; laksanakan perbaikan yang dapat direspons; untuk perbaikan yang bebannya terlalu berat, pertimbangkan sarana alternatif dengan orang itu dan sepakati; catat apa yang diminta, apa yang direspons, dan apa yang dijadikan sarana alternatif
    req["Permintaan"] --> talk["Dialog konstruktif"]
    talk --> q{"Apakah bebannya terlalu berat?"}
    q -->|Tidak| kaishu["Respons dengan perbaikan"]
    q -->|Ya| alt["Pertimbangkan sarana alternatif dan sepakati"]
    kaishu --> rec["Catat riwayat"]
    alt --> rec

Gambar 19: Dalam dialog konstruktif Anda bersepakat dengan orang itu tentang perbaikan atau sarana alternatif, dan meninggalkan riwayat itu dalam catatan.

10. Ringkasan

• Dengan undang-undang yang diamandemen tentang Penghapusan Diskriminasi terhadap Penyandang Disabilitas yang berlaku April 2024, penyediaan akomodasi wajar menjadi kewajiban bagi pelaku usaha juga. Bidang ketenagakerjaan telah menjadi kewajiban pemberi kerja sejak 2016 di bawah Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas. Membuat aplikasi lebih mudah dipakai di muka adalah “perbaikan lingkungan” (kewajiban upaya), dan semakin jauh ia telah pergi, semakin ringan respons individual.
• Kriteria teknis terkonsentrasi di WCAG (JIS X 8341-3:2016), dan pemikiran yang sama dapat diterapkan pada aplikasi desktop lewat WCAG2ICT.
• Pembaca layar membaca aplikasi lewat UI Automation. Trio pohon UIA, properti (Name/ControlType/AutomationId), dan pola kontrol adalah fondasinya.
• Prioritas tertinggi adalah Name. WinForms memakai AccessibleName dan mengaitkan Label dengan urutan tab; WPF memakai AutomationProperties.Name/LabeledBy; kontrol kustom memakai AutomationPeer.
• Dapat mencapai setiap fungsi dari keyboard saja adalah kriteria keberhasilan WCAG dan, pada saat yang sama, produktivitas setiap operator. Rapikan urutan tab, access key, dan indikasi fokus.
• Tiga dasar warna adalah rasio kontras 4,5:1, warna bukan satu-satunya sarana, dan menghormati warna sistem dalam tema kontras.
• Gabungkan verifikasi dengan FastPass+Live Inspect di Accessibility Insights dan pemeriksaan langsung dengan Narrator/NVDA, dan bangun ke dalam alur pengembangan sebagai daftar periksa untuk layar baru.
• Jangan perbaiki setiap layar sekaligus; maju dalam urutan layar yang dipakai pengguna → dukungan standar untuk pekerjaan baru → guliran ke samping kontrol bersama. Akomodasi wajar adalah proses dialog, dan catatan riwayat melindungi organisasi.

Sebagai langkah pertama kami merekomendasikan memilih salah satu layar utama Anda, menjalankan FastPass di Accessibility Insights for Windows, lalu menelusuri pekerjaan dengan tombol Tab saja. Dalam tiga puluh menit, posisi saat ini aplikasi Anda sendiri menjadi sangat konkret.

Artikel terkait

• Pengujian otomatis UI untuk aplikasi desktop Windows — cara kerja UI Automation dan membangun uji yang kokoh dengan FlaUI
• Desain UX aplikasi Windows - prioritas menurut lingkungan pemakaian
• Dukungan DPI tinggi di WinForms — mengapa UI kabur atau rusak pada monitor 4K, dan perbaikan praktis
• Dukungan DPI tinggi WPF — mengapa masih kabur dan merembes meski ‘seharusnya sadar-DPI’, dan cara memperbaikinya
• Mengapa KomuraSoft membangun situs web pada Design System Digital Agency — biaya rendah dan mutu tinggi dapat berdampingan
• Jebakan font dan karakter Jepang — menangani JIS2004, IVS, dan gaiji di aplikasi bisnis

Area konsultasi terkait

KomuraSoft LLC menangani perbaikan aksesibilitas aplikasi bisnis WinForms/WPF (dukungan pembaca layar, merapikan operasi keyboard, dukungan tema kontras), mengimplementasikan AutomationPeer pada kontrol bersama, serta konsultasi diagnosis keadaan saat ini dan penetapan prioritas dengan Accessibility Insights. Memulai dari tahap “kami ingin mengonfirmasi apakah seorang karyawan dapat memakai aplikasi kami dengan pembaca layar” tidak apa-apa.

• Pengembangan aplikasi Windows
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

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 respons yang, ketika penyandang disabilitas membuat permintaan, menghapus hambatan individual dalam rentang yang bukan beban berlebihan; membuat aplikasi lebih mudah dipakai di muka diposisikan sebagai kewajiban upaya yang disebut "perbaikan lingkungan". Ketenagakerjaan, seperti hubungan antara karyawan dan perusahaan, tidak di bawah undang-undang itu melainkan di bawah Undang-Undang Promosi Ketenagakerjaan Penyandang Disabilitas, yang telah mewajibkan pemberi kerja menyediakan akomodasi wajar sejak amandemen yang berlaku April 2016. Dengan kata lain, situasi "seorang karyawan tidak dapat memakai aplikasi bisnis" sudah lama berada di ranah kewajiban. Seberapa jauh pergi dalam kasus tertentu bergantung pada situasi individual, jadi Anda mengonfirmasi sumber primer dari Cabinet Office dan Kementerian Kesehatan, Tenaga Kerja, dan Kesejahteraan serta memutuskan lewat dialog dengan orang yang bersangkutan.

Bagaimana pembaca layar membaca aplikasi desktop Windows?

Pembaca layar seperti Narrator dan NVDA membaca UI aplikasi lewat fondasi aksesibilitas yang disebut UI Automation (UIA). Sisi aplikasi mengekspos elemen di layar dalam struktur yang disebut pohon UIA; setiap elemen punya 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 beroperasi lewat pola. Kontrol standar WinForms dan WPF punya mekanisme ini sejak awal, jadi pekerjaan utama pengembang adalah tidak meninggalkan Name kosong, membuat UI dapat dioperasikan dari keyboard, dan mengimplementasikan informasi pada kontrol kustom.

Pada aplikasi WinForms yang sudah ada, apa yang harus kita mulai?

Jalur terpendek adalah menjalankan FastPass di Accessibility Insights for Windows terhadap layar sasaran dan menginventarisasi kontrol yang Name-nya kosong serta masalah urutan tab. Perbaikan dimulai dengan menyetel AccessibleName pada tombol hanya-ikon, mengaitkan Label di urutan tab langsung sebelumnya dari field input, dan merapikan TabIndex agar cocok dengan urutan visual. Lalu mulai Narrator atau NVDA dan telusuri operasi bisnis sungguhan tanpa melihat layar, serta konfirmasi di mana Anda macet. Anda tidak perlu memperbaiki setiap layar sekaligus; memulai dari layar yang benar-benar dipakai seseorang, dan membuat layar baru patuh standar dengan daftar periksa, adalah realistis.

Apa yang harus kita lakukan untuk dukungan kontras tinggi (tema kontras)?

Dasarnya adalah tidak meng-hard-code warna dan menghormati warna sistem. Di WinForms, biarkan ForeColor/BackColor pada bawaan atau pakai SystemColors, nilai state dengan SystemInformation.HighContrast, dan ikuti peralihan dengan event UserPreferenceChanged. Di WPF dan WinUI, juga, jika Anda merujuk sumber daya kelas SystemColors, Anda mengikuti peralihan tema secara otomatis. Pada saat yang sama, berhenti menyampaikan informasi "hanya lewat warna" — menampilkan kesalahan hanya dengan merah — dan gabungkan dengan ikon atau kata. Bahkan di tema biasa, mengambil kriteria WCAG rasio kontras teks 4,5:1 atau lebih sebagai panduan juga membuat UI lebih mudah dibaca untuk lantai toko yang redup dan untuk pengguna yang lebih tua.

Apakah dukungan aksesibilitas juga membantu pengujian otomatis UI?

Ya. Alat pengujian otomatis UI seperti FlaUI dibangun di atas UI Automation yang sama yang dipakai pembaca layar. Name, ControlType, dan pola kontrol yang Anda pasang untuk aksesibilitas dapat dipakai apa adanya dari kode uji, dan AutomationId yang dirancang untuk uji menstabilkan identifikasi elemen. Sebaliknya, UI yang digambar kustom yang tidak muncul di pohon UIA tidak terlihat baik bagi pembaca layar maupun uji. Aksesibilitas dan pengujian otomatis adalah investasi pada fondasi yang sama, jadi memasang 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.