「カスタムUI部品」がA11y崩壊しやすい：実務で避ける設計
2026年 3月13日
近年のインタラクティブなWebアプリでは、独自にデザインされたカスタムUI部品（疑似ボタンやコンボボックス、スライダーなど）が増えています。しかしこれらはアクセシビリティの落とし穴になりやすく、スクリーンリーダーやキーボード操作などの支援技術で“詰む”UIを生みます。問題の本質は、見た目や操作のカスタマイズだけに走り、本来必要なアクセシビリティ要件（名前・役割・値）が担保されない点にあります。本稿では、この事故パターンを実務視点で整理し、避けるべき設計とその対策を解説します。
カスタムUIが崩壊する典型的な原因
カスタム部品で起こりがちなアクセシビリティ違反の原因は次の通りです。
- 標準コンポーネントではなく要素を偽装する
<div>や<span>でボタンやリンクを見た目だけ作り、ARIAや役割を付与しないために支援技術に意味が伝わらない。これはWCAGでも“役割（role）や名前が不適切な実装”として失敗例に挙げられています。 - キーボード操作が未設計
マウス中心でしか操作できず、Tabキー・Enterキーが機能しない部品は多くのユーザーにとって使えません。カスタムUI部品はこうした“キーボード操作非対応”の問題でアクセシビリティ事故になることがあります。 - 適切な名前や状態が提供されない
スクリーンリーダーが何であるか／どう動くかを理解できないため、ユーザーは誤解しやすくなります。WCAGではアクセシビリティAPIに名前・役割・値を提供することが求められます。
なぜ既存のHTML要素を使うべきか
WCAGや現場の実務知見でも、アクセシビリティは“最初からあるものを使う”という原則が推奨されています。
- 標準要素はアクセシビリティAPIを備えている
Button・input・selectなどのHTML要素は名前・役割・状態が支援技術に自動的に伝わるため、カスタム要素を最初から避けられます。 - 適切な操作モデルが保証される
キーボードフォーカスやEnter/Spaceによる操作など、既存UI要素は一般的なUXパターンとして認識されます。 - 設計と開発コストの削減
カスタム実装ではARIA等で補完せざるを得ず、テストや修正工数が増える恐れがあります。
カスタムUIで特に危険な部品パターン
以下のようなカスタムUIはアクセシビリティ事故を生みやすいです。
- 疑似ボタン
本来<button>であるべき要素を<div>等で作り、キーボード制御やARIA属性が欠ける例。 - カスタムセレクト/ドロップダウン
標準<select>を再実装し、フォーカス制御や選択状態の名前がスクリーンリーダーに伝わらない例。 - スライダー/タブUI
ARIA rolesを適切に付与せず、状態変更が支援技術に伝わらない場合。
実務で発生するアクセシビリティ事故例
現場でよくある事故として、次の問題が指摘されています。
- 部品に役割がプログラム的に決定できない
スクリーンリーダーがそのUIが何であるか判断できないため、操作方法を読み上げられません。 - フォーカス状態が把握できない
見た目上はフォーカスがあるようでも、支援技術に通知されないパターン。 - バリデーションや状態変化が伝わらない
変更される値や状態がARIA等で伝えられないため、障害ユーザーが直前の状態を把握できません。
避けるべき設計と代替アプローチ
カスタムUIを使わざるを得ない場合でも、次の実務的な設計ルールを守るべきです。
- まずは標準HTML要素を優先する
可能であれば<button>や<input>などを使い、アクセシビリティAPIの恩恵を受けます。 - 必要なWCAG要件を設計時に定義する
名前・役割・状態などを実装前に明示し、ARIA属性で補完します。 - キーボードナビゲーションを保証する
Tab順序やEnter/Spaceの挙動を定義し、フォーカス可視化を設計に含めます。 - スクリーンリーダーテストを行う
実装後に支援技術で操作可能か確認します。
BtoBプロダクトで特に重要な理由
BtoB製品は複雑なUIを持つため、カスタム部品のアクセシビリティ設計ミスが重大な障壁になります。
- 高度な操作を求められる場面が多い
カスタム部品で操作が詰むと業務全体が停止します。 - 多様なユーザー背景
障害の有無を問わず、キーボード中心・支援技術利用者が存在します。 - 修正コストが大きい
既存UIを後付けで修正するのは工数・品質リスクになります。
まとめ（実務アクション）
カスタムUI部品によるアクセシビリティ事故を防ぐため、次を実践してください。
- 可能な限り標準HTML要素を優先する
- 役割・名前・状態が支援技術に伝わることを設計時に定義する
- キーボード操作が自然に成立するよう設計する
- ARIAは補完として正しく使う
- スクリーンリーダーや支援技術で検証する