Windowsアプリのアクセシビリティ入門 ── UI Automationと合理的配慮の義務化に備える

「視覚障害のある社員が、基幹の受注入力アプリをスクリーンリーダーで使えない。Webブラウザーやメールは使いこなしているのに、うちの業務アプリだけ読み上げが動かない」── お客様の情シス部門から、こうした相談を受けることが増えてきました。

この問題を解く出発点は、画面の見た目ではなく、支援技術に何を伝えているかを見ることです。Windowsには、スクリーンリーダーがアプリの情報を読むためのUI Automation(UIA)があります。仕組みを理解し、名前・キーボード・色の基本を押さえれば、業務アプリの使い勝手は大きく改善します。¹

法制度の面でも、社内のWindowsアプリは無関係ではありません。2021年改正の障害者差別解消法は2024年4月1日に施行され、事業者にも合理的配慮の提供が義務化されました。一方、冒頭のような雇用分野は障害者雇用促進法の対象で、2016年4月から事業主の義務です。この違いは2章で整理します。²³

WindowsデスクトップアプリのアクセシビリティはWebほど情報が多くなく、後付けで一度に解決する方法もありません。ただし、必要な改善の多くは、障害の有無にかかわらず全ユーザーの生産性も高めます。

この記事は、日本の業務アプリ開発者と情シス担当者に向けた解説です。法制度と規格、UIAの仕組みを押さえてから、WinForms/WPFの実装、キーボード、色とコントラスト、検証、改修の優先順位へ進みます。

flowchart TB
    accTitle: 本記事の流れ
    accDescr: 法制度と規格の整理からUI Automationの仕組み、WinFormsとWPFでの実装、キーボード操作、色とコントラスト、検証ツール、優先順位の付け方までを順につなぐ本記事の構成
    law["法制度と規格の整理"] --> uia["UI Automationの仕組み"]
    uia --> impl["WinForms/WPFでの実装"]
    impl --> kb["キーボード操作"]
    kb --> color["色とコントラスト"]
    color --> verify["検証ツール"]
    verify --> prio["優先順位の付け方"]

図1: 本記事は法制度から仕組み・実装・検証・優先順位までを一本の流れでつなぐ。

1. まず結論

最初に押さえたいのは、次の3点です。

1. 個別の合理的配慮と、事前の環境整備を分けて考えます。 合理的配慮は、申出に対して建設的対話を重ね、負担が重すぎない範囲で対応するプロセスです。事業者は2024年4月から、雇用分野の事業主は2016年4月から義務を負います。事前のアプリ改修は「環境の整備」(努力義務)に当たり、最初から全画面を完璧に直すこととは別です。²³
2. 技術対応の土台は、UIAへの情報公開と、名前・キーボード・色の基本です。 UIAツリーのName・ControlTypeと、Invoke・Value・SelectionItemなどのパターンが読み上げと操作の材料になります。最優先は名前付けです。WinFormsはAccessibleNameとLabel・タブオーダーの関連付け、WPFはAutomationProperties.Name/LabeledByで対応し、キーボード操作、コントラスト比4.5:1を目安とする配色、色だけに頼らない表示も整えます。¹⁴⁵⁶
3. 検証と改修は、実際の業務から進めます。 Accessibility InsightsのFastPassとスクリーンリーダーでの実地確認を組み合わせ、利用者が使う画面、新規画面、共通コントロールの順に整備します。同じUIA基盤を使うFlaUI等のUI自動テストにも、この改善が役立ちます。⁷

技術基準はWCAGを軸に整理できます。JIS X 8341-3:2016はWCAG 2.0と同じ内容の一致規格で、WCAG2ICTが非Webのソフトウェアへの適用ガイダンスを示しています。詳しくは2.2節で確認します。⁸⁹

目的に合わせて読む場合は、次の章から進めてください。

一文でまとめるなら、アクセシビリティ対応とは「UIAツリーに正しい名前と操作を公開し、キーボードと色の基本を守ること」です。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全16件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 法制度と規格の整理 ── 「義務化」で何が変わったか

2.1. 障害者差別解消法 ── 2024年4月から事業者も「合理的配慮の提供」が義務

この節では、何が義務になったのか、事前の改修はどう位置づくのか、雇用分野では何の法律を見るのかを分けて確認します。

事業者の合理的配慮は、努力義務から義務に変わった

障害者差別解消法は、行政機関等と事業者に対して、障害のある人への「不当な差別的取扱い」を禁止し、「合理的配慮の提供」を求める法律です。2021年(令和3年)の改正で、それまで努力義務だった事業者による合理的配慮の提供が義務に変わり、2024年(令和6年)4月1日に施行されました。²

内閣府のリーフレットでは、障害のある人からバリアを取り除く対応が必要だという意思が示されたときに、負担が重すぎない範囲で対応することと説明されています。内容は障害特性や場面・状況によって異なるため、本人と事業者が対話を重ね、共に対応案を検討する「建設的対話」が重要です。一方的に対話を拒むことは、提供義務違反となる可能性があると明記されています。²

事前のアプリ改修は「環境の整備」として考える

事前にすべて対応しておくことが義務化されたわけではありません。 不特定多数の障害者を対象に、マニュアルの見直しや研修、施設のバリアフリー化などを事前に進める措置は「環境の整備」と呼ばれ、努力義務に位置づけられます。²

業務アプリをあらかじめスクリーンリーダーで使える状態にすることは、この環境の整備側の取り組みと考えられます。整備が進んでいるほど、個別の合理的配慮を軽い負担で提供できます。

社員が使う場面は、障害者雇用促進法を見る

雇用・就業の場面は、障害者差別解消法ではなく障害者雇用促進法の対象です。 この区別は内閣府のリーフレットにも記載されています。²

障害者雇用促進法では、2016年(平成28年)4月施行の改正により、雇用分野での障害者差別の禁止と、過重な負担にならない範囲での合理的配慮の提供が事業主に義務付けられています。冒頭の「社員が業務アプリを使えない」という相談は、2024年より前から義務の領域だったわけです。³

flowchart TB
    accTitle: 合理的配慮と環境の整備の位置づけ
    accDescr: 一般の事業者と障害のある人の関係は障害者差別解消法の対象で個別の申出に建設的対話で応じる合理的配慮の提供が2024年4月から義務、雇用分野は障害者雇用促進法により2016年4月から事業主の義務、アプリの事前改修は努力義務の環境の整備に当たる
    scene{"どの場面?"} -->|事業者と障害のある人| kaisho["障害者差別解消法"]
    scene -->|雇用・就業の場面| koyou["障害者雇用促進法"]
    kaisho --> moushide["個別の申出に建設的対話で対応"]
    moushide --> hairyo["合理的配慮の提供（2024年4月から義務）"]
    koyou --> koyougimu["合理的配慮の提供（2016年4月から義務）"]
    kaisho -.-> kankyo["事前のアプリ改修=環境の整備（努力義務）"]
    kankyo -.-> moushide

図2: 場面により根拠法が分かれ、合理的配慮は義務、事前改修は環境の整備として努力義務に当たる。

なお、個別のケースが法律上どう扱われるかは状況により異なります。本記事は法解釈には踏み込まず、対応を求められたときに技術者として何ができるか、という観点で進めます。一次情報としては内閣府・厚生労働省の資料を参照してください。²³

2.2. JIS X 8341-3とWCAG ── 「Webの基準」はソフトウェアにも延びている

技術基準を具体的に読むときは、WCAGを軸に整理すると見通しがよくなります。JIS X 8341-3:2016、WCAG、WCAG2ICTは、次の関係です。⁸⁶⁹

「WCAGはWebコンテンツの基準では？」という疑問には、WCAG2ICTが橋渡しになります。正式名はGuidance on Applying WCAG 2 to Non-Web Information and Communications Technologiesです。⁹

テキストの代替、コントラスト、キーボード操作、色だけに頼らない情報伝達といった考え方は、Windowsデスクトップアプリにも同じ枠組みで適用できます。3章以降では、それをWinForms/WPFの実装に落とし込みます。

flowchart TB
    accTitle: JIS X 8341-3とWCAGの関係
    accDescr: JIS X 8341-3:2016はWCAG 2.0と同じ内容の一致規格であり、WCAG2ICTがWCAGの達成基準を非Webのソフトウェアへ適用する方法を示すため、Windowsデスクトップアプリも同じ枠組みで点検できる
    wcag["WCAG 2.0（W3C）"] ---|同じ内容の一致規格| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["非Webのソフトウェアへ適用"]
    soft --> app["Windowsデスクトップアプリ"]

図3: JIS X 8341-3:2016はWCAG 2.0の一致規格で、WCAG2ICTが同じ基準をデスクトップアプリへ延ばしている。

3. 支援技術がアプリを読む仕組み ── UI Automationの3点セット

3.1. UIAツリー・プロパティ・コントロールパターン

Windowsに組み込まれているUI Automation(UIA)は、アプリ側と支援技術側の間を取り持つアクセシビリティ基盤です。アプリ側は「プロバイダー」としてUIの情報を公開し、スクリーンリーダーなどの支援技術側は「クライアント」として情報を取得します。標準の入力以外の手段によるUI操作も、この仕組みで可能になります。¹

まずは、画面の構造・要素の性質・できる操作という3点セットで理解してください。¹

たとえば、ボタンにフォーカスしたときの「受注を確定 ボタン」という読み上げは、おおむねNameとコントロール種別の組み合わせです。ユーザーが実行を指示すると、支援技術はInvokeパターンを通じてボタンを押します。

つまり、画面にボタンが描かれていることと、支援技術から読めて操作できることは別です。Nameとパターンが正しく公開されていなければ、画面に見えていても存在しないのと同じになります。

flowchart TB
    accTitle: UI Automationの3点セット
    accDescr: アプリはプロバイダーとしてUIAツリーに各要素のプロパティとコントロールパターンを公開し、スクリーンリーダーはクライアントとしてNameとControlTypeを読み上げInvokeなどのパターンで操作する
    app["アプリ（プロバイダー）"] --> tree["UIAツリー"]
    tree --> prop["プロパティ（Name・ControlTypeなど）"]
    tree --> pat["パターン（Invoke・Valueなど）"]
    sr["スクリーンリーダー（クライアント）"] -->|読み上げ| prop
    sr -->|操作| pat

図4: アプリがUIAツリーに公開したプロパティとパターンを、スクリーンリーダーが読み上げと操作に使う。

3.2. スクリーンリーダーはUIAのクライアント

Windowsの主なスクリーンリーダーには、組み込みのナレーター、無料・オープンソースのNVDA¹⁰、国内で広く使われる商用のPC-Talkerがあります。

読み上げの流儀はそれぞれ異なりますが、デスクトップアプリのUIを読む主要な経路はいずれもUIAです。アプリ側の対応は、特定のスクリーンリーダーだけを意識するのではなく、UIAに正しい情報を公開することに集約されます。

flowchart TB
    accTitle: 主要スクリーンリーダーの共通経路
    accDescr: アプリがUIAへ正しい情報を公開すればナレーターとNVDAとPC-Talkerのいずれも同じ経路でUIを読めるため、アプリ側の対応は特定のスクリーンリーダー向けではなくUIAへの公開に集約される
    app["アプリ"] -->|情報を公開| uia["UI Automation（UIA）"]
    uia --> nar["ナレーター"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["対応はUIAへの公開に集約"]

図5: 主要なスクリーンリーダーはいずれもUIAを経路とするため、アプリの対応はUIAへの公開に集約される。

3.3. 「Nameが空のボタン」は何と読まれるか

ツールバーに、フロッピーディスクのアイコンだけを表示した保存ボタンがあるとします。見た目で目的が伝わっても、Nameが空のままでは、スクリーンリーダーは「ボタン」としか読み上げません。隣の「開く」「印刷」も同じ状態なら、「ボタン、ボタン、ボタン」と聞こえるだけで区別できません。

Nameのないボタンや「Image」としか読まれない画像は、Microsoftの修正ガイドでも、ユーザーの作業を止める代表的な問題として挙げられています。⁵

WinForms/WPFの標準コントロールは最初からUIAに対応し、多くはテキストやラベルから自動的にNameが決まります。壊れる典型は次の3つです。

次の2章では、この切り分けをWinFormsとWPFそれぞれの直し方につなげます。

flowchart TB
    accTitle: 読み上げが壊れる3つの典型
    accDescr: アイコンのみで名前の材料がない場合とラベルとの関連付けがない場合と独自描画でUIAツリーに情報が出ていない場合に読み上げが壊れ、ボタンとしか読まれない状態になる
    c1["アイコンのみで材料なし"] --> broken["Nameが空になる"]
    c2["ラベルの関連付けなし"] --> broken
    c3["独自描画で情報が出ない"] --> broken
    broken --> result["ボタンとしか読まれない"]

図6: 読み上げが壊れるのは大抵、名前の材料不足・関連付け不足・独自描画の3パターンに帰着する。

4. WinFormsでの実装 ── AccessibleNameとタブオーダー

4.1. Textが自動でNameになるコントロールと、ならないコントロール

まず、Textが名前に使われる種類かを確認する

WinFormsでは、文字を表示するコントロールでも、TextがUIAのNameに使われるものと、使われないものがあります。⁴

表示ラベルを使い、置けない場合はAccessibleNameを設定する

最も保守しやすいのは、説明用のLabelを対象コントロールの直前のタブオーダーに置く方法です。LabelのTabIndexの直後に対象コントロールのTabIndexが来るようにすると、LabelのテキストがUIAのNameとして使われます。表示と読み上げを一致させられ、文言の二重管理も不要になります。⁴¹¹

Labelを置けない場合は、AccessibleNameを明示します。補足説明にはAccessibleDescription、役割を実態に合わせる必要がある場合にはAccessibleRoleも設定できます。¹²

flowchart TB
    accTitle: WinFormsコントロールの名前の決まり方
    accDescr: ButtonなどはTextがそのままUIAのNameになり、TextBoxなどTextが転用されないコントロールは直前のタブオーダーに置いたLabelのテキストが使われ、Labelを置けない場合はAccessibleNameを明示的に設定する
    ctrl["コントロール"] --> qtext{"TextがNameになる種類?"}
    qtext -->|はい| usetext["TextがそのままNameになる"]
    qtext -->|いいえ| qlabel{"直前のタブオーダーにLabel?"}
    qlabel -->|はい| uselabel["LabelのテキストがNameに使われる"]
    qlabel -->|いいえ| explicit["AccessibleNameを明示的に設定"]

図7: WinFormsのNameはText、直前タブオーダーのLabel、AccessibleNameの順で決め方を選ぶ。

// アイコンのみのツールバーボタン: 読み上げ用の名前を明示する
saveToolStripButton.AccessibleName = "上書き保存";

// 画像だけのボタン: 名前+補足説明
btnSearchCustomer.AccessibleName = "顧客を検索";
btnSearchCustomer.AccessibleDescription = "顧客コードまたは氏名で顧客マスタを検索します";

// Labelを直前のタブオーダーに置けない入力欄には直接設定する
txtOrderNo.AccessibleName = "受注番号";

// グラフ表示に転用したPictureBox: 役割も実態に合わせる
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "月別受注件数グラフ";

名前を消したはずなのに、既定の読み上げに戻らないとき

Visual StudioのプロパティペインでAccessibleNameを一度設定してから消すと、デザイナーファイルに空文字列の設定だけが残ることがあります。その設定が既定の名前解決を妨げる場合は、デザイナーファイルから該当行を削除してください。⁴

flowchart TB
    accTitle: AccessibleNameの空文字列が残る問題
    accDescr: プロパティペインでAccessibleNameを一度設定してから消すとデザイナーファイルに空文字列の設定が残って既定の名前解決を妨げるため、デザイナーファイルから該当行を削除して直す
    set["AccessibleNameを設定"] --> erase["プロパティペインで消す"]
    erase --> remain["空文字列の設定が残る"]
    remain --> block["既定の名前解決を妨げる"]
    block -.-> fix["デザイナーファイルの該当行を削除"]

図8: プロパティペインで消しても空文字列が残るため、デザイナーファイルの該当行を削除して直す。

4.2. 受注入力画面でよくある改善点

当社が業務アプリで実際によく直す箇所を、チェックリストにまとめます。

いずれも数行の修正ですが、スクリーンリーダーの利用者にとっては「使えない画面」と「使える画面」の分かれ目になります。

5. WPFでの実装 ── AutomationPropertiesとAutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

ボタンの名前は、文字列のContentか明示設定で与える

WPFのButtonのようにContentが文字列のコントロールでは、その内容がUIAのNameに使われます。一方、ImageやPathだけのボタンには名前の材料がありません。AutomationProperties.Nameで明示するか、近くに表示テキストがあればAutomationProperties.LabeledByで関連付けます。⁵

TextBoxでは「名前」と「入力値」を分ける

TextBlockのTextはNameに転用されますが、TextBoxのTextはUIAのValueプロパティ側に公開され、Nameにはなりません。入力値が入っていても、それだけでは「何を入力する欄か」は伝わらないのです。¹³

入力欄では、表示ラベルのTextBlockをLabeledByで関連付けるのが第一候補です。表示と読み上げが一致し、文言の二重管理も避けられます。¹³

<!-- 入力欄: 表示ラベルをLabeledByで関連付ける -->
<TextBlock x:Name="OrderNoLabel" Text="受注番号" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- アイコンのみのボタン: 名前を明示し、必要なら補足も付ける -->
<Button
    AutomationProperties.Name="受注を確定"
    AutomationProperties.HelpText="入力中の受注を確定し、在庫を引き当てます">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: WPFコントロールの名前の決まり方
    accDescr: Contentが文字列のコントロールはその内容がNameに使われ、そうでない場合は近くの表示ラベルをLabeledByで関連付けるのが第一候補で、それも無ければAutomationProperties.Nameを明示し、TextBoxのTextはNameではなくValue側に公開される
    ctrl["コントロール"] --> qc{"Contentが文字列?"}
    qc -->|はい| auto["内容がNameになる"]
    qc -->|いいえ| ql{"近くに表示ラベル?"}
    ql -->|はい| lb["LabeledByで関連付け"]
    ql -->|いいえ| nm["Nameを明示設定"]
    tbx["TextBoxのText"] -.-> val["NameでなくValueに公開"]

図9: WPFのNameはContentの文字列、LabeledBy、明示設定の順で決め、TextBoxのTextはNameにならない。

HelpTextとAutomationIdは、名前とは役割が違う

Nameに収まらない補足情報はAutomationProperties.HelpTextで公開します。⁵ AutomationIdは、UI自動テストで要素を特定するためにも使う識別子です。画面設計の段階で命名規則を決めておくと、後のテストで役立ちます。

まとめると、Nameは目的、HelpTextは補足、AutomationIdは識別子です。自動テストでの使い方は「WindowsデスクトップアプリのUI自動テスト」で詳述しています。

5.2. カスタムコントロールにはAutomationPeer

独自描画のカスタムコントロールは、そのままではUIAツリーに意味のある情報を公開できません。WPFでは、UIElement派生クラスのOnCreateAutomationPeerをオーバーライドし、AutomationPeer派生クラスを返すことで、名前・種類・パターンを公開します。¹⁴

既存のコントロールを継承している場合は、対応するPeerも継承します。たとえばButtonBaseならButtonBaseAutomationPeerを使うと、実装済みの挙動を引き継げます。¹⁴

flowchart TB
    accTitle: AutomationPeerによる情報公開の仕組み
    accDescr: カスタムコントロールはOnCreateAutomationPeerをオーバーライドしてAutomationPeer派生クラスを返すことで名前と種類とパターンを公開し、既存コントロールを継承している場合は対応するPeerを継承して実装済みの挙動を引き継ぐ
    custom["カスタムコントロール"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Peer派生クラスを返す"]
    peer --> pub["名前・種類・パターンを公開"]
    inherit["既存コントロールを継承"] -.-> basepeer["対応するPeerを継承"]
    basepeer -.-> reuse["実装済みの挙動を引き継ぐ"]

図10: カスタムコントロールはOnCreateAutomationPeerでPeerを返してUIAへ情報を公開する。

// 回線状態を色付きランプで独自描画するコントロールの例
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 ? "回線状態: オンライン" : "回線状態: オフライン";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // 値が変わった瞬間にUIAのプロパティ変更イベントを発行する。これが無いと、
        // スクリーンリーダーは古い名前を保持したまま、状態の変化に気づけない
        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相当

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

現在の名前だけでなく、状態の変化も通知する

上の例では、現在の状態に応じた名前を返す処理と、IsOnlineが変わったときにNameのプロパティ変更イベントを発行する処理を組み合わせています。

名前を返すだけでなく、変化した瞬間にイベントで知らせるところまでがPeerの仕事です。 支援技術は値を再取得するタイミングを自分では持たないため、イベントがなければ「問い直されたときだけ正しい」実装になり、スクリーンリーダーの利用者に状態の変化が伝わりません。

sequenceDiagram
    accTitle: 状態変化をスクリーンリーダーへ伝える流れ
    accDescr: コントロールの値が変わった瞬間にAutomationPeerがNameのプロパティ変更イベントを発行し、支援技術は自分では再取得しないためイベントがなければ古い名前のまま変化に気づけない
    participant c as コントロール
    participant p as AutomationPeer
    participant s as スクリーンリーダー
    c->>p: IsOnlineの値が変化
    p->>s: Nameのプロパティ変更イベントを発行
    s->>s: 新しい状態を読み上げ
    Note over s: イベントが無いと古い名前のまま

図11: 値の変化はAutomationPeerが変更イベントで知らせて初めてスクリーンリーダーに届く。

操作を持つならパターンを実装し、共通部品へまとめる

押せる、値を変えられる、選択できるカスタムコントロールでは、GetPatternをオーバーライドし、IInvokeProviderやIRangeValueProviderなどのパターンインターフェイスを提供します。¹⁴

共通コントロールライブラリ側でPeerまで作り込めば、それを使う全画面が自動的に対応済みになります。 これが9章で説明する横展開の土台です。

6. キーボードだけで全機能に到達できるか

WCAGの達成基準2.1.1(キーボード)は、すべての機能をキーボードインターフェイスから操作可能にすることを求めています。⁶ スクリーンリーダーの利用者は原則マウスを使わないため、キーボードで到達できない機能は、存在しない機能と同じです。

6.1. 移動・実行・現在位置を点検する

タブオーダーだけでなく、主要操作を実行できることや、現在のフォーカスが分かることまで確認します。

WinFormsのアクセシビリティ手引きでも、入力欄の直前のタブオーダーにラベルを置くこと、ユーザーが移動したいコントロールとメニューにアクセスキーを付けることが基本として挙げられています。¹¹

6.2. キーボード整備は、全ユーザーの入力効率にもつながる

これは「障害者対応のための追加コスト」だけではありません。受注入力のような定型業務では、ホームポジションから手を離さずに入力を完結できるかが、オペレーターの処理件数を決めます。

タブオーダーの乱れやマウス必須の操作は、全ユーザーの生産性を毎日少しずつ削る欠陥です。アクセシビリティ対応とキーボード効率化は、同じ作業の2つの呼び名にすぎません。利用環境別の優先順位は「WindowsアプリUX設計」も参照してください。

flowchart TB
    accTitle: キーボード整備の二重の効果
    accDescr: タブオーダーやアクセスキーやフォーカス表示の整備は、支援技術の利用者が機能に到達できることと全オペレーターの入力速度という2つの効果を同時に生み、マウスでしか使えない機能は存在しない機能と同じになる
    seibi["キーボード操作の整備"] --> a11y["支援技術の利用者が使える"]
    seibi --> speed["全オペレーターの入力速度"]
    mouse["マウス専用の機能"] -.-> none["存在しない機能と同じ"]

図12: キーボード操作の整備は支援技術対応と全ユーザーの効率化を同時に実現し、マウス専用機能は存在しないのと同じになる。

7. 色とコントラスト ── 4.5:1と「色だけに頼らない」

7.1. コントラスト比の目安は4.5:1

WCAGの達成基準1.4.3(コントラスト(最低限))では、テキストと文字画像に少なくとも4.5:1、大きな文字には少なくとも3:1のコントラスト比を求めています。⁶

薄いグレーの文字を白背景に置くデザインは、この基準を割ることが珍しくありません。加齢で視力・色覚が変化した人や、工場のように照明条件の悪い場所で使う人も想定し、デザイン確認ではコントラストチェッカーで実測する習慣を付けてください。

7.2. 色だけで情報を伝えない

達成基準1.4.1(色の使用)は、色が情報を伝える唯一の視覚的手段になってはならない、というものです。⁶ 業務アプリの典型例は次のとおりです。

色覚の多様性を考えると、これも「特別な対応」ではなく表示設計の基本です。

flowchart TB
    accTitle: 色だけに頼らない情報伝達への置き換え
    accDescr: エラーを赤い文字だけで示す表示はエラーアイコンとメッセージ列の併設に、必須項目をラベルの色だけで示す表示は必須の表記の追加に、ステータスをランプの色だけで示す表示は形や文字の併用に置き換える
    err["エラーを赤い文字だけ"] --> erra["アイコンと文言を併設"]
    req["必須をラベルの色だけ"] --> reqa["必須の表記を添える"]
    lamp["状態をランプの色だけ"] --> lampa["色に形や文字を併用"]

図13: 色だけで伝えている典型例は、アイコン・表記・形や文字の併用に置き換える。

7.3. コントラストテーマ(ハイコントラスト)への追従

Windowsのコントラストテーマ(従来のハイコントラスト)は、前景と背景を強く分離した配色です。組み込みテーマは概ね7:1以上のコントラスト比になるよう設計され、ユーザーが選択・編集できます。¹⁵

アプリ側は、色をハードコードせず、システムカラーを尊重します。フレームワークごとの対応は次のとおりです。

WinFormsの具体的な設定はMicrosoftの手引き、テーマの配色についてはコントラストテーマの資料を参照してください。¹¹¹⁵

flowchart TB
    accTitle: コントラストテーマへの追従
    accDescr: 色をハードコードした箇所はコントラストテーマへの切り替えで崩れるため、SystemColorsベースの配色へ切り替え設定変更イベントで追従し、システムカラーを参照していればユーザーの配色に自動で追従できる
    theme["コントラストテーマへ切り替え"] --> qh{"色の指定方法は?"}
    qh -->|ハードコード| broken["配色が崩れる"]
    qh -->|システムカラー参照| ok["ユーザーの配色に自動追従"]
    broken -.-> fix["SystemColorsへ切り替え"]
    fix -.-> ev["設定変更イベントで追従"]

図14: 色をハードコードした箇所だけがコントラストテーマで崩れ、システムカラー参照なら自動で追従する。

高DPIで崩れないことも、同じ点検に含める

弱視のユーザーはOSの拡大率(DPIスケーリング)を高くして使うことが多く、高DPI対応もアクセシビリティ対応の一部です。125%〜200%でレイアウトが崩れるアプリは、その利用環境では使えません。

具体的な対処は「WinFormsの高DPI対応」「WPFの高DPI対応」を参照してください。

8. 検証の実務 ── Accessibility Insightsとスクリーンリーダー実地確認

8.1. Accessibility Insights for Windows

Microsoftが提供するAccessibility Insights for Windowsは、目的に応じて3つの使い方を選べます。⁷

Windows SDKに含まれるInspect.exeやAccEventでもUIAツリーとプロパティを確認できますが、これらはレガシーツールという位置づけで、現在はAccessibility Insightsへの移行が推奨されています。⁷

flowchart TB
    accTitle: Accessibility Insightsの3つの使い方
    accDescr: Accessibility Insights for WindowsはLive InspectでUIAプロパティの確認、FastPassで高影響の問題の軽量チェック、Troubleshootingで問題の診断と修正支援を提供し、Inspect.exeなどのレガシーツールからは移行が推奨されている
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["UIAプロパティを確認"]
    fast --> fastf["高影響の問題を検出"]
    ts --> tsf["診断と修正を支援"]
    legacy["Inspect.exeなど"] -.->|移行推奨| ai

図15: Accessibility Insightsは確認・検出・診断の3つの使い方を持ち、レガシーツールからの移行先になる。

8.2. スクリーンリーダーでの実地確認

自動チェックに通ったことと、実際の業務を完了できることは別です。 ツールが検出できるのは機械的に判定できる問題だけなので、最後は必ずスクリーンリーダーで業務操作を一巡してください。

まず、ナレーターをCtrl+Windowsキー+Enterで起動するか、無料のNVDAを導入します。¹⁰ 次に「受注を1件入力して確定する」のような代表タスクを決め、画面を見ずに、またはディスプレイを消して、読み上げだけで完了できるか試します。

名前が付いていても読み上げ順が支離滅裂だったり、フォーカスがモーダルの外へ抜けたりする問題は、こうした実地確認でなければ見つかりません。

flowchart TB
    accTitle: ツール検証と実地確認の組み合わせ
    accDescr: FastPassなどの自動チェックが検出できるのは機械的に判定できる問題だけであり、残りはスクリーンリーダーで実際の業務操作を一巡し読み上げ順やフォーカスの問題を実地で見つける
    tool["ツールの自動チェック"] --> kikai["機械的に判定できる問題"]
    tool -.-> nokori["検出できない問題が残る"]
    nokori --> sr["スクリーンリーダーで実地確認"]
    sr --> task["業務操作を一巡する"]
    task --> mieru["読み上げ順やフォーカスの問題"]

図16: 自動チェックで機械的な問題を洗い出し、残りはスクリーンリーダーでの実地確認で見つける。

8.3. 開発フローへの組み込みとUI自動テストとの相乗効果

検証を属人化させないために、新画面のレビュー項目に次のチェックリストを組み込むことをおすすめします。

UIAの整備を、自動テストにも生かす

FlaUIなどのUI自動テストは、スクリーンリーダーと同じUIAを基盤にしています。アクセシビリティのために整備したNameとパターンはテストコードの部品になり、テストのために設計したAutomationIdはLive Inspectでのデバッグも楽にします。

逆に、UIAツリーに現れないUIは、テストからも支援技術からも見えません。アクセシビリティとテスト容易性は、同じ投資の両面です。 詳しくは「WindowsデスクトップアプリのUI自動テスト」を参照してください。

flowchart TB
    accTitle: アクセシビリティとUI自動テストの相乗効果
    accDescr: スクリーンリーダーとFlaUIなどのUI自動テストは同じUIAを基盤とするため、整備したNameやパターンは両方から利用でき、UIAツリーに現れないUIはどちらからも見えない
    uia["UIAツリーの整備"] --> sr["スクリーンリーダーが読める"]
    uia --> test["UI自動テストで使える"]
    sr -.-> both["同じ投資の両面"]
    test -.-> both
    hidden["UIAに現れないUI"] -.-> invisible["どちらからも見えない"]

図17: 同じUIA基盤の上にあるため、UIAツリーの整備は支援技術とUI自動テストの両方に効く。

9. 優先順位の付け方 ── 全画面を一度に直さない

数百画面ある基幹システムを一斉に改修するのは、コスト面でも品質面でも現実的ではありません。当社では、次の3段階で進めることを推奨しています。

9.1. その利用者が業務で使う画面から直す

合理的配慮は、当事者の申出に個別に応じるプロセスです。² まず本人に実際の業務をスクリーンリーダーで操作してもらい、詰まる箇所を一緒に特定します。

多くの場合、日常業務で使う画面は数個〜十数個に絞られます。その中の致命的な問題、たとえば名前のないボタンやキーボードで押せない確定ボタンは、数日単位の修正で解消できます。

9.2. 新規開発分は標準で対応する

8章のチェックリストを、完成の定義(Definition of Done)に加えます。新しい画面は、最初から対応済みで作る方針です。後付けの改修と違い、設計時に組み込む分にはコスト増はわずかです。

9.3. 共通コントロールの改修で横展開する

社内共通の検索ダイアログ、グリッド、日付入力などに、AccessibleNameの既定値やAutomationPeerを実装します。共通部品を直せば、それを使う全画面へ一括で効きます。個別画面を1つずつ直すより、費用対効果の高い打ち手です。

flowchart TB
    accTitle: 改修の優先順位の3段構え
    accDescr: 利用者が業務で使う画面から直し、新規開発分はチェックリストで標準対応し、共通コントロールの改修で全画面へ横展開する
    s1["1. 利用者が使う画面から直す"] --> s2["2. 新規分は標準で対応"] --> s3["3. 共通コントロールで横展開"]
    s3 -.-> all["それを使う全画面に一括で効く"]

図18: 全画面の一斉改修ではなく、使う画面・新規分・共通部品の3段構えで進める。

9.4. 改修内容だけでなく、対話の経緯を記録する

技術対応と同じくらい重要なのが、対話の記録です。合理的配慮は対話して個別に調整するプロセスであり、すべての要望に完全対応することではありません。

負担が重すぎる改修では、別画面で該当業務を行う、CSV出力を用意する、運用でカバーするといった代替手段を、本人と検討して合意することも建設的対話の正当な帰結です。²

何を求められ、何を対応し、何を代替手段としたかを記録しておくことが、組織としての誠実さの証明になります。

flowchart TB
    accTitle: 建設的対話と記録の流れ
    accDescr: 障害のある人からの要望に建設的対話で応じ、対応できる改修は実施し、負担が重すぎる改修は代替手段を本人と検討して合意し、何を求められ何を対応し何を代替手段としたかを記録する
    req["要望"] --> talk["建設的対話"]
    talk --> q{"負担が重すぎる?"}
    q -->|いいえ| kaishu["改修で対応"]
    q -->|はい| alt["代替手段を検討し合意"]
    kaishu --> rec["経緯を記録する"]
    alt --> rec

図19: 建設的対話では改修か代替手段かを本人と合意し、その経緯を記録に残す。

10. まとめ

法制度・技術・進め方を分けると、着手点が見えてきます。

法制度では、事業者の合理的配慮は2024年4月から、雇用分野の事業主の合理的配慮は2016年から義務です。事前のアプリ改修は「環境の整備」(努力義務)に当たり、進めておくほど個別対応が軽くなります。対話の経緯も記録してください。

技術では、WCAG(JIS X 8341-3:2016)を軸に、WCAG2ICTを通じてデスクトップアプリを点検します。土台は、UIAツリー・プロパティ(Name/ControlType/AutomationId)・コントロールパターンです。最優先の名前付けは、WinFormsならAccessibleNameとLabel・タブオーダー、WPFならAutomationProperties.Name/LabeledBy、カスタムコントロールならAutomationPeerで対応します。

そのうえで、キーボードだけで全機能に到達できるよう、タブオーダー・アクセスキー・フォーカス表示を整えます。色はコントラスト比4.5:1を目安にし、色だけに頼らず、コントラストテーマではシステムカラーを尊重します。これらは、全オペレーターの生産性にもつながる改善です。

進め方は、利用者が使う画面、新規分の標準対応、共通コントロールの横展開の順です。Accessibility InsightsのFastPass・Live Inspectと、ナレーター/NVDAによる実地確認を組み合わせ、新画面のチェックリストとして開発フローに組み込んでください。

最初の一歩としておすすめなのは、自社の主力画面を1つ選び、Accessibility Insights for WindowsのFastPassを実行してから、Tabキーだけで業務を一巡してみることです。30分で、自分たちのアプリの現在地が驚くほど具体的に見えてきます。

関連記事

• WindowsデスクトップアプリのUI自動テスト ── UI Automationの仕組みとFlaUIで作る壊れにくいテスト
• WindowsアプリUX設計 - 利用環境別の優先順位
• WinFormsの高DPI対応 ── 4Kモニターでぼやける・崩れる原因と現実的な対処
• WPFの高DPI対応 ── 「DPIに強いはず」なのにぼやける・にじむ原因と対処
• なぜ小村ソフトはデジタル庁デザインシステムでHPを作るのか ── 安さと品質は両立できる
• 日本語フォントと文字の落とし穴 ── JIS2004・異体字セレクタ・外字を業務アプリでどう扱うか

関連する相談領域

合同会社小村ソフトでは、WinForms/WPF業務アプリのアクセシビリティ改修(スクリーンリーダー対応、キーボード操作の整備、コントラストテーマ対応)、共通コントロールへのAutomationPeer実装、Accessibility Insightsを使った現状診断と優先順位付けの相談を扱っています。「社員がスクリーンリーダーでうちのアプリを使えるか確かめたい」という段階からで構いません。

• Windowsアプリ開発
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

業務アプリのアクセシビリティ対応は、法律で義務付けられたのですか？

2021年改正の障害者差別解消法が2024年4月1日に施行され、事業者にも障害のある人への合理的配慮の提供が義務化されました。合理的配慮は、障害のある人から申出があったときに、負担が重すぎない範囲で個別のバリアを取り除く対応で、アプリをあらかじめ使いやすく改修しておくことは「環境の整備」という努力義務に位置づけられています。なお、社員と会社の関係のような雇用分野は障害者差別解消法ではなく障害者雇用促進法の対象で、こちらは2016年4月施行の改正で事業主に合理的配慮の提供が義務付けられています。つまり「社員が業務アプリを使えない」という場面は、以前から義務の領域です。何をどこまで対応するかは個別の状況によるため、内閣府や厚生労働省の一次情報を確認したうえで、当事者との対話を通じて決めていくことになります。

スクリーンリーダーはWindowsのデスクトップアプリをどうやって読み上げているのですか？

ナレーターやNVDAなどのスクリーンリーダーは、UI Automation(UIA)というアクセシビリティ基盤を通じてアプリのUIを読み取っています。アプリ側はUIAツリーという構造で画面上の要素を公開し、各要素はName(目的)、ControlType(種類)などのプロパティと、Invoke(押す)、Value(値)などのコントロールパターンを持ちます。スクリーンリーダーはこの情報を「受注を確定 ボタン」のように読み上げ、パターンを通じて操作します。WinFormsやWPFの標準コントロールはこの仕組みを最初から備えているため、開発者の主な仕事は、Nameを空にしないこと、キーボードで操作できること、独自コントロールに情報を実装することです。

既存のWinFormsアプリでは、最初に何から手を付ければよいですか？

最初にAccessibility Insights for WindowsのFastPassを対象画面に実行し、Nameが空のコントロールとタブオーダーの問題を洗い出すのが近道です。修正は、アイコンのみのボタンへのAccessibleName設定、入力欄の直前のタブオーダーにLabelを置く関連付け、見た目の並びと一致したTabIndexの整理から始めます。そのうえでナレーターかNVDAを起動し、画面を見ずに実際の業務操作を一巡して、詰まる箇所を確認してください。全画面を一度に直す必要はなく、実際に使う人がいる画面から着手し、新規画面はチェックリストで標準対応にするのが現実的です。

ハイコントラスト(コントラストテーマ)対応では何をすればよいですか？

基本は、色をハードコードせずシステムカラーを尊重することです。WinFormsならForeColor/BackColorを既定のままにするかSystemColorsを使い、SystemInformation.HighContrastで状態を判定して、UserPreferenceChangedイベントで切り替えに追従します。WPFやWinUIでもSystemColors系のリソースを参照していれば、テーマ切り替えに自動で追従します。あわせて、エラーを赤色だけで示すような「色だけに頼った」情報伝達をやめ、アイコンや文言を併用してください。通常テーマでも、テキストのコントラスト比4.5:1以上というWCAGの基準を目安にすると、照明条件の悪い現場や高齢のユーザーにも読みやすくなります。

アクセシビリティ対応はUI自動テストにも役立ちますか？

役立ちます。FlaUIなどのUI自動テストツールは、スクリーンリーダーと同じUI Automationを基盤にしているからです。アクセシビリティ対応で整備したName、ControlType、コントロールパターンはそのままテストコードから利用でき、テストのために設計したAutomationIdは要素特定を安定させます。逆に、UIAツリーに現れない独自描画のUIは、スクリーンリーダーからもテストからも見えません。アクセシビリティと自動テストは同じ土台への投資なので、どちらかを整備すればもう一方のコストも下がります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。