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

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

背景のひとつは法制度です。2021年に改正された障害者差別解消法が2024年4月1日に施行され、事業者にも障害のある人への「合理的配慮の提供」が義務化されました。¹ さらに言えば、冒頭のような社員と会社の関係(雇用分野)は障害者雇用促進法の領域で、こちらは2016年4月から事業主に合理的配慮の提供が義務付けられています。² 「アクセシビリティはWebサイトの話で、社内のWindowsアプリには関係ない」という認識は、法制度の面でも実務の面でも、もう成り立ちません。

一方で、開発の現場から見ると「何をすればいいのか分からない」が正直なところだと思います。WindowsデスクトップアプリのアクセシビリティはWebほど情報がなく、後付けの魔法のような解決策もありません。しかし、悲観する必要もありません。スクリーンリーダーがアプリを読む仕組み(UI Automation)を理解し、名前・キーボード・色という基本を押さえれば、業務アプリの使い勝手は大きく改善します。しかもその多くは、障害の有無にかかわらず全ユーザーの生産性を上げる改善です。

この記事では、日本の業務アプリ開発者と情シス担当者を対象に、法制度と規格の最低限の整理から、UI Automationの仕組み、WinForms/WPFでの実装、キーボード操作、色とコントラスト、検証ツール、そして現実的な優先順位の付け方までを一気につなぎます。

1. まず結論

• 合理的配慮の提供は、2024年4月1日から事業者にも義務です。障害のある人からバリアを取り除きたいという意思が示されたとき、負担が重すぎない範囲で対応することが求められます。雇用分野は障害者雇用促進法の対象で、こちらは2016年4月から事業主の義務です。¹²
• 合理的配慮は「個別の申出に建設的対話で応じる」プロセスであり、アプリの事前改修は「環境の整備」(努力義務)に当たります。完璧な事前対応が義務なのではなく、対話を一方的に拒まないことが重要です。¹
• アクセシビリティの技術基準はWCAG(JIS X 8341-3:2016)に集約されています。JIS X 8341-3:2016はWCAG 2.0と同じ内容の一致規格で、W3CのWCAG2ICTが非Webのソフトウェアへの適用ガイダンスを示しています。デスクトップアプリも同じ考え方で点検できます。³⁴
• スクリーンリーダーはUI Automation(UIA)を通じてアプリを読みます。UIAツリー上の各要素が持つName・ControlTypeなどのプロパティと、Invoke・Value・SelectionItemなどのコントロールパターンが読み上げと操作の材料です。⁵
• Nameが空のボタンは「ボタン」としか読まれません。最優先の改修は名前付けです。WinFormsはAccessibleNameとLabel・タブオーダーの関連付け、WPFはAutomationProperties.Name/LabeledByで対応します。⁶⁷
• すべての機能にキーボードだけで到達できることは、WCAGの達成基準(2.1.1)であると同時に、熟練オペレーターの入力速度そのものです。タブオーダー・アクセスキー・フォーカス表示の整備は全ユーザーの効率化に直結します。⁸
• テキストのコントラスト比は4.5:1以上を目安にし、色だけで情報を伝えないでください。コントラストテーマ(ハイコントラスト)では、ハードコードした色ではなくシステムカラーを尊重します。⁸⁹
• 検証はAccessibility Insights for WindowsのFastPassとスクリーンリーダーでの実地確認を組み合わせます。UIAという同じ基盤の上にあるため、この整備はFlaUI等のUI自動テスト資産とも相互に効きます。¹⁰
• 全画面を一度に直す必要はありません。①その利用者が使う画面から、②新規開発分は標準で対応、③共通コントロールの改修で横展開、という順序が現実解です。

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

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

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

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

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

ここで実務上重要な整理が2つあります。

1. 「事前にすべて対応しておくこと」が義務化されたわけではありません。マニュアル見直しや研修などのソフト面、施設のバリアフリー化などのハード面といった、不特定多数の障害者を対象とする事前の改善措置は「環境の整備」と呼ばれ、こちらは努力義務です。¹ 業務アプリをあらかじめスクリーンリーダーで使える状態に整えておくことは、この環境の整備側の取り組みと考えられます。環境の整備が進んでいるほど、個別の合理的配慮は軽い負担で提供できます。
2. 雇用分野は障害者差別解消法ではなく、障害者雇用促進法の対象です。同リーフレットにも、雇用・就業については障害者雇用促進法の定めによると記載されています。¹ そして障害者雇用促進法では、2016年(平成28年)4月施行の改正により、雇用分野での障害者差別の禁止と、過重な負担にならない範囲での合理的配慮の提供が事業主に義務付けられています。² 冒頭の「社員が業務アプリを使えない」という相談は、実は2024年よりずっと前から義務の領域だったわけです。

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

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

技術基準の側は、JIS X 8341-3:2016に集約されています。この規格はISO/IEC 40500:2012の一致規格で、規格本文はW3CのWCAG 2.0と同じ内容です。³ 「アクセシビリティ対応」の中身を具体的に知りたければ、WCAGの達成基準(現在はWCAG 2.1/2.2に拡張)を読むのが早道で、WAICによる日本語訳も公開されています。⁸

「WCAGはWebコンテンツの基準では？」という疑問はもっともですが、W3CはWCAG2ICT(Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies)というGroup Noteで、WCAG 2.0/2.1/2.2の達成基準を非Webの文書とソフトウェアに適用する方法を整理しています。⁴ つまり「テキストの代替」「コントラスト」「キーボード操作」「色だけに頼らない」といった考え方は、WindowsデスクトップアプリにもWebと同じ枠組みで適用できます。本記事の3章以降は、この考え方をWinForms/WPFの具体的な実装に落とすものです。

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

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

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

UIAの世界は、次の3点セットで理解できます。⁵

スクリーンリーダーがボタンにフォーカスしたとき読み上げる「受注を確定 ボタン」は、おおむねName+コントロール種別の組み合わせです。ユーザーが「実行」の操作をすると、支援技術はInvokeパターンを通じてそのボタンを押します。つまり、Nameとパターンが正しく公開されていれば読めて操作でき、公開されていなければ画面に見えていても存在しないのと同じです。

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

Windowsで使われる主なスクリーンリーダーには、Windowsに組み込まれているナレーター、無料・オープンソースのNVDA¹¹、国内で広く使われている商用のPC-Talkerなどがあります。読み上げの流儀はそれぞれ異なりますが、デスクトップアプリのUIを読むための主要な経路はいずれもUIAです。だからこそ、アプリ側の対応は「特定のスクリーンリーダー対応」ではなく、UIAに正しい情報を公開することに集約されます。

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

具体例を1つ。ツールバーに、フロッピーディスクのアイコンだけを表示した保存ボタンがあるとします。目の見えるユーザーにはアイコンで意味が伝わりますが、Nameが空のままだと、スクリーンリーダーはこのボタンを「ボタン」としか読み上げません。隣に並ぶ「開く」「印刷」も同様なら、ユーザーには「ボタン、ボタン、ボタン」としか聞こえず、どれが何かを知る手段がありません。Microsoftのアクセシビリティ修正ガイドでも、Nameのないボタンや「Image」としか読まれない画像は、ユーザーの作業を止める代表的な問題として挙げられています。⁷

幸い、WinFormsもWPFも標準コントロールはUIA対応を最初から備えており、多くの場合はテキストやラベルから自動的にNameが決まります。壊れるのは大抵、①アイコンのみで名前の材料がない、②ラベルとの関連付けがない、③独自描画でUIAツリーに情報が出ていない、のいずれかです。次の2つの章で、フレームワーク別の直し方を見ていきます。

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

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

WinFormsでは、ButtonやCheckBoxのように文字を表示するコントロールは、Textプロパティの値がUIAのNameとして使われます。一方、ComboBox、ListBox、ListView、PictureBox、ProgressBar、TabControl、TextBox、TreeViewなどはTextがNameになりません。これらには別の手段で名前を与える必要があります。⁶

最も保守しやすいのは、説明用のLabelを、対象コントロールの直前のタブオーダーに置く方法です。LabelのTabIndexの直後に対象コントロールのTabIndexが来るように設定すると、そのLabelのテキストがUIAのNameとして自動的に使われます。画面に見えているラベルと読み上げが一致し、文言を二重管理せずに済みます。⁶¹²

Labelを置けない場合は、AccessibleNameを明示的に設定します。あわせて、補足説明が必要ならAccessibleDescription、役割が見た目と異なる場合はAccessibleRoleも設定できます。¹³

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

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

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

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

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

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

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

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

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

5.1. AutomationProperties.Name / LabeledBy / HelpText

WPFでは、ButtonのようにContentが文字列のコントロールは、その内容がUIAのNameに使われます。アイコン(ImageやPath)だけのボタンはNameの材料がないため、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>

Nameに収まらない補足情報はAutomationProperties.HelpTextで公開できます。⁷ また、AutomationIdはUI自動テストでの要素特定にも使う識別子なので、画面設計の段階で命名規則を決めておくと後で効いてきます(「WindowsデスクトップアプリのUI自動テスト」で詳述しています)。

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

自前で描画するカスタムコントロールは、そのままではUIAツリーに意味のある情報を公開できません。WPFでは、UIElement派生クラスのOnCreateAutomationPeerをオーバーライドし、AutomationPeer派生クラスを返すことで、名前・種類・パターンを公開します。既存のコントロールを継承している場合は、対応するPeer(ButtonBaseならButtonBaseAutomationPeer)を継承すると、実装済みの挙動を引き継げます。¹⁵

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

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

操作を持つカスタムコントロール(押せる、値を変えられる、選択できる)なら、GetPatternをオーバーライドしてIInvokeProviderやIRangeValueProviderなどのパターンインターフェイスを提供します。¹⁵ ポイントは、共通コントロールライブラリ側でPeerまで作り込んでおけば、それを使う全画面が自動的に対応済みになることです。これは9章の「横展開」の土台になります。

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

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

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

強調したいのは、これが「障害者対応のための追加コスト」ではないことです。受注入力のような定型業務では、ホームポジションから手を離さず入力を完結できるかどうかが、そのままオペレーターの処理件数を決めます。タブオーダーの乱れやマウス必須の操作は、全ユーザーの生産性を毎日少しずつ削っている欠陥です。アクセシビリティ対応とキーボード効率化は、同じ作業の2つの呼び名にすぎません(利用環境別の優先順位は「WindowsアプリUX設計」も参照してください)。

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

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

WCAGの達成基準1.4.3(コントラスト(最低限))は、テキストと文字画像に少なくとも4.5:1、大きな文字には少なくとも3:1のコントラスト比を求めています。⁸ 薄いグレーの文字を白背景に置いたモダンなデザインは、この基準を割っていることが珍しくありません。業務アプリの利用者には、加齢で視力・色覚が変化した人や、工場のように照明条件の悪い環境で使う人も含まれます。デザイン確認の際にコントラストチェッカーで実測する習慣を付けてください。

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

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

• エラー行を赤い文字だけで示す → エラーアイコンとメッセージ列を併設する
• 必須項目をラベルの色だけで示す → 「*」や「必須」の表記を添える
• ステータスをランプの色だけで示す → 色+形または文字(「稼働中」「停止」)にする

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

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

Windowsには、前景と背景を強く分離した配色に切り替えるコントラストテーマ(従来のハイコントラスト)があり、コントラスト比が概ね7:1以上になるよう設計された組み込みテーマをユーザーが選択・編集できます。⁹ アプリ側の原則はシンプルで、色をハードコードせず、システムカラーを尊重することです。

• WinForms: ForeColor/BackColorを既定のままにすればユーザーの配色設定が使われます。独自に色を付けている箇所は、SystemInformation.HighContrastを判定してSystemColorsベースの配色に切り替え、UserPreferenceChangedイベントで設定変更へ追従します。¹²
• WPF/WinUI: SystemColors系のリソースを参照していればテーマ切り替えに追従します。独自ブラシで塗り潰している箇所が崩れの原因になります。⁹

また、弱視のユーザーはOSの拡大率(DPIスケーリング)を高くして使うことが多いため、高DPI対応はアクセシビリティ対応の一部でもあります。125%〜200%でレイアウトが崩れるアプリは、この時点で使えません。詳細は「WinFormsの高DPI対応」「WPFの高DPI対応」を参照してください。

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

8.1. Accessibility Insights for Windows

MicrosoftはWindowsアプリのアクセシビリティ検証ツールとしてAccessibility Insights for Windowsを提供しており、主に3つの使い方があります。¹⁰

• Live Inspect: 要素にマウスホバーまたはキーボードフォーカスするだけで、そのUIAプロパティ(Name、ControlType、パターン等)を確認できます。「このボタンのNameは何か」を最短で見る手段です。
• FastPass: 高影響のアクセシビリティ問題を5分以内で検出する軽量チェックです。Nameの欠落など、機械的に判定できる問題を新画面ごとに洗い出せます。
• Troubleshooting: 特定の問題の診断と修正を支援します。検出された問題からは、本記事でも引用しているフレームワーク別の修正ガイドへ直接たどれます。

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

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

ツールの自動チェックが検出できるのは機械的に判定できる問題だけです。最後は必ずスクリーンリーダーで実際の業務操作を一巡してください。Windows組み込みのナレーターはCtrl+Windowsキー+Enterですぐ起動でき、NVDAは無料で導入できます。¹¹ 確認のコツは、画面を見ずに(またはディスプレイを消して)、読み上げだけを頼りに「受注を1件入力して確定する」のような実タスクを完了できるか試すことです。名前が付いていても読み上げ順が支離滅裂、フォーカスがモーダルの外へ抜ける、といった問題は実地でしか見つかりません。

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

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

そしてもう1つ。FlaUIなどによるUI自動テストは、スクリーンリーダーと同じUIAを基盤にしています。アクセシビリティのために整備したNameとパターンはテストコードの部品になり、テストのために設計したAutomationIdはLive Inspectでのデバッグを楽にします。逆に、UIAツリーに現れないUIはテストからも支援技術からも見えません。アクセシビリティとテスト容易性は同じ投資の両面です(「WindowsデスクトップアプリのUI自動テスト」)。

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

数百画面ある基幹システムを一斉に改修するのは、コスト的にも品質的にも非現実的です。当社が推奨する進め方は次の3段構えです。

1. その利用者が業務で使う画面から直す。合理的配慮は、当事者の申出に個別に応じるプロセスです。¹ まず本人に実際の業務をスクリーンリーダーで操作してもらい、詰まる箇所を一緒に特定してください。多くの場合、日常業務で使う画面は数個〜十数個に絞られ、その中の致命的な問題(名前のないボタン、キーボードで押せない確定ボタン)は数日単位の修正で解消できます。
2. 新規開発分は標準で対応する。8章のチェックリストを完成の定義(Definition of Done)に加え、新しい画面は最初から対応済みで作ります。後付けの改修と違い、設計時に組み込む分にはコスト増はわずかです。
3. 共通コントロールの改修で横展開する。社内共通の検索ダイアログ、グリッド、日付入力などの共通部品にAccessibleName既定値やAutomationPeerを実装すれば、それを使う全画面へ一括で効きます。個別画面を1つずつ触るより、はるかに費用対効果が高い打ち手です。

そして、技術対応と同じくらい重要なのが対話の記録です。合理的配慮は「対話して個別に調整する」プロセスであり、すべての要望に完全対応することではありません。負担が重すぎる改修について、代替手段(該当業務を別画面で行う、CSV出力を用意する、運用でカバーする)を本人と検討して合意するのも、建設的対話の正当な帰結です。¹ 何を求められ、何を対応し、何を代替手段としたかを記録しておくことが、組織としての誠実さの証明になります。

10. まとめ

• 2024年4月施行の改正障害者差別解消法で、事業者にも合理的配慮の提供が義務化されました。雇用分野は障害者雇用促進法により2016年から事業主の義務です。アプリの事前改修は「環境の整備」(努力義務)に当たり、進めておくほど個別対応が軽くなります。
• 技術基準はWCAG(JIS X 8341-3:2016)に集約され、WCAG2ICTによりデスクトップアプリにも同じ考え方を適用できます。
• スクリーンリーダーはUI Automationを通じてアプリを読みます。UIAツリー・プロパティ(Name/ControlType/AutomationId)・コントロールパターンの3点セットが土台です。
• 最優先はNameです。WinFormsはAccessibleNameとLabel・タブオーダーの関連付け、WPFはAutomationProperties.Name/LabeledBy、カスタムコントロールはAutomationPeerで対応します。
• キーボードだけで全機能に到達できることは、WCAGの達成基準であると同時に全オペレーターの生産性です。タブオーダー・アクセスキー・フォーカス表示を整えてください。
• コントラスト比4.5:1、色だけに頼らない、コントラストテーマではシステムカラーを尊重、の3点が色の基本です。
• 検証は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 ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。