Figmaからアクセシブルなhtmlへ:実践ガイド

簡単な答え： Figma→HTMLのワークフローにおけるアクセシビリティは、ひとつの設定をオンにすれば済むものではありません——具体的な一連の判断の積み重ねです。スタイルを当てただけの<div>ではなく本物のセマンティック要素を使うこと、コンテンツの構造に沿った見出しの順序にすること(Figmaには見出しレベルというネイティブな概念がありません)、フォームフィールドやアイコンのみのボタンにラベルを付けること、目に見えるフォーカス状態を用意すること、十分な色のコントラストを確保すること、そしてARIAは控えめに——セマンティックHTMLだけではその操作を表現できない場合にのみ使うこと。自動生成された出力はその大部分をカバーしてくれますが、デザインファイルには持たせられない部分を拾うために、短い手動チェックがそれでも必要です。

なぜFigma→HTML変換でアクセシビリティが失われるのか

Figmaファイルが説明しているのは、デザインの見た目です。スクリーンリーダーが何を読み上げるべきか、次にどの要素にフォーカスが移るべきか、ある色の組み合わせが弱視のユーザーにとって読みやすいかどうかは、Figmaファイルには記述されていません。このギャップこそが、変換時にアクセシビリティが崩れる本当の理由です——不注意のせいではなく、アクセシビリティが必要とする情報の一部が、そもそもデザインファイルに含まれていないという事実によるものです。見た目がピクセル単位で完全に一致していても、その下にあるマークアップが構造もラベルもキーボード対応もない汎用的な<div>であれば、アクセシビリティとしては失敗のままです。

解決策は、たった一度の自動処理では済みません。優れたコンバーターが、視覚のみのマークアップではなく実際の構造を生成することで、アクセシビリティのどの部分をすでに正しく処理できているのかを理解し、そして——デザイナーか開発者か、あるいはその両方が——意図的な判断を常に必要とする部分がどこなのかを理解することです。後者が必要になるのは、デザインファイルが本当にその情報を持っていないからです。

アクセシビリティに影響するFigmaのデザイン上の判断

変換ツールが関わるよりも前の段階で、いくつかのよくあるFigmaの使い方の癖が、後工程でアクセシビリティの問題を生み出します。

• 色だけを頼りにした信号。 赤色で示された必須フォームフィールドや、同じ色を少し薄くしただけの無効化ボタンは、どちらもその色相を区別できない人には見えません。この違いを伝えるには、色の変化だけでなく、二つ目の信号(アイコン、ラベル、パターンなど)が必要です。
• テキストを画像に焼き込む。 フラット化したPNGとしてエクスポートされた見出しは、本物のテキストレイヤーと見た目は同じに見えるかもしれませんが、スクリーンリーダーで読み上げることも、ブラウザでリサイズすることも、クローラーにインデックスさせることもできません。
• 視覚的なフォーカス状態が設計されていない。 多くのFigmaのコンポーネントセットには、デフォルト、hover、時にはdisabledの状態がありますが、フォーカス状態(ページをTabキーで移動するキーボードユーザー向け)はそもそも設計されていないことが多く、変換時に引き継ぐものが何もありません。
• アイコンのみのボタンに、ファイル内のどこにもアクセシブルな名前がない。 「削除」を意味するゴミ箱アイコンは、見た目には明らかです。しかしレイヤー自体に意味のある名前が付けられていない限り、Figmaのレイヤーにはそのアイコンが何を意味するのかをコンバーターにも、スクリーンリーダーにも伝える情報がありません。
• 見出しのサイズが一貫していない。 FigmaにはCMSやワープロソフトのような「見出し2」という要素は存在せず、テキストレイヤーはただのテキストに、特定のサイズに見えるスタイルが当てられているだけです。異なるフレームにまたがる、見た目が似た二つの見出しが、実際のコンテンツ階層ではまったく異なるレベルを表していることがあります。

これらはどれも変換ツールの不具合ではありません。パイプラインのどこかで必ず判断しなければならない事柄であり、ツールが自動的に推測してくれるはずだと思い込む前に、この点を理解しておく価値があります。

セマンティックHTMLとランドマーク

これは、優れたFigma→コードコンバーターであればデフォルトで正しく処理できているはずのアクセシビリティの部分です。ラベルのない<div>だけでページ全体を組み立てるのではなく、本物の<header>、<nav>、<main>、<article>、<section>、<aside>、<footer>要素を使うことです。ランドマークが重要なのは、スクリーンリーダーのユーザーがページ全体を線形にTabキーでたどるのではなく、「メインコンテンツ」や「ナビゲーション」に直接ジャンプできるようにする手段だからです。MarkupGenの出力が構造的にどのようなものかについてはFigma to Semantic HTMLを、セマンティックマークアップとクロール可能性の重なりについてはIs Figma-to-HTML Output SEO-Ready?を参照してください——この二つの問題は根本原因を共有しており、解決策の大部分も共通しています。

見出しの階層構造

1ページにつき<h1>はひとつ、そして見出しは順番に段階を下げていくべきです——<h3>はすでに<h2>が存在するセクションの中に置かれるべきであり、デザイン上たまたまそのサイズに見えたテキストレイヤーだからといって、いきなりそこに飛ぶべきではありません。前述の通り、Figmaには見出しレベルというネイティブな概念がないため、大きくスタイリングされたテキストレイヤーが自動的に<h1>になるわけではありません——これはどのツールがマークアップを生成したかにかかわらず、手動で確認する価値があります。見た目のサイズだけでなく、コンテンツの実際の構造を理解する必要があるからです。

ボタンとリンク

これは変換後のマークアップで最もよくあるアクセシビリティの誤りのひとつであり、Figmaのコンポーネント構造がこれを自動的に解決してくれるわけではありません。<button>は現在のページ上でのアクション(送信する、モーダルを開く、項目を削除する)のためのものであり、<a href>は別のページやビューへのナビゲーションのためのものです。同じような見た目のピル形状で埋め尽くされたデザインファイルからは、どちらがどちらなのか判断できません——これは視覚的な判断ではなくセマンティックな判断であり、キーボードの挙動(ボタンとリンクはデフォルトで異なるキーに反応します)とスクリーンリーダーが読み上げる内容の両方に直接影響します。

フォームとラベル

すべての入力欄には、プレースホルダーで代用するのではなく、プログラム的に関連付けられた本物の<label>が必要です。プレースホルダーのテキストは、ユーザーが入力を始めた瞬間に消えてしまい、デフォルトでコントラストが低いことで悪名高く、すべてのスクリーンリーダーがラベルの代わりとして確実に読み上げてくれるわけでもありません。デザイン上の理由でフォームがラベルなしに見える必要がある場合は、マークアップからラベルを完全に取り除くのではなく、視覚的に隠したラベルを使いましょう。エラーメッセージは、色だけで問題を示しながら近くに配置するのではなく、(一般的にはaria-describedbyを使って)対象のフィールドと関連付ける必要があります。

画像とalt テキスト

エクスポートされた画像には、空の文字列やファイル名ではなく、意味のあるalt属性が必要です。これは、手動でのチェックが本当に避けられない領域のひとつです。装飾的な背景画像が何のためにあるのかと、商品写真に何を説明する必要があるのかは、Figmaのフレームだけからは必ずしも明らかではありません——デザインファイルが持っているのはピクセルだけで、意図までは持っていないからです。純粋に装飾的な画像には空のalt=""を設定し(スクリーンリーダーがスキップできるように)、意味のある画像には、見た目そのものではなく、それが伝えている内容についての本物の説明が必要です。

キーボード操作

リンク、ボタン、フォームフィールドといったすべてのインタラクティブな要素は、キーボードだけで到達・操作でき、その順序は視覚的な読み順と一致している必要があります。ここでAuto Layoutが本当に役立ちます。Auto Layoutの構造は、絶対配置された断片ではなく、論理的なDOMの順序として引き継がれるため、Tabキーの移動順序は、自由配置・絶対配置のレイアウトにありがちな予測不能な飛び方をするのではなく、自然と読み順に沿ったものになりやすいのです。

フォーカス状態

Figmaのコンポーネントセットにはフォーカス状態が設計されていることがほとんどないため、これは変換後のページで単一の項目として最もよく見られるアクセシビリティのギャップです。キーボードユーザーがインターフェースをTabキーでたどっても、自分が今どこにいるのか視覚的にわかりません。最低限、ブラウザのデフォルトのフォーカスアウトライン(outline: none)を、同じくらい目立つ何かに置き換えずに削除することは避けてください——これは、そもそもフォーカス状態を考慮していなかったデザインに合わせるという名目で、よくやってしまいがちな、しかし簡単に上線できてしまうミスです。

色のコントラスト

Figmaでは、読みやすさに関係なくどんな2色でも選べてしまうため、これは思い込みではなく明示的なチェックが必要です。WCAG AAでは、通常の本文テキストで少なくとも4.5:1、大きなテキスト(18px以上の太字、または24px以上の標準ウェイト)やアイコン、入力欄の枠線といった意味のあるUIコンポーネントについては3:1のコントラストが求められます。変換の前に、デザインで実際に使われている色の組み合わせをコントラストチェッカーにかけましょう——Figma内でトークンを直しておく方が、後から生成済みのマークアップ全体を追いかけて直すよりもはるかに安上がりです。

ARIA——役に立つとき、逆に害になるとき

ARIAの第一原則は今も変わらず正しいものです。悪いARIAを使うくらいなら、ARIAを使わない方がましです。ネイティブの<button>は、すでに正しいroleを持ち、フォーカス可能で、デフォルトでEnterキーとスペースキーに反応します——これにrole="button"を追加しても何の役にも立たず、その要素本来のセマンティクスと衝突するリスクがあるだけです。ARIAが本当に必要になるのは、セマンティックHTMLだけではその操作を表現できない場面に限られます。

• 使うべき場面： 目に見えるテキストのないアイコンのみのボタンにaria-labelを付ける(「削除」を意味するゴミ箱アイコンなど)、折りたたみ可能なセクションを制御するトグルにaria-expandedを付ける、ページの再読み込みなしに更新される領域(フォームのバリデーションメッセージ、カートの件数など)にaria-live="polite"を付ける。
• 使うべきでない場面： すでに正しいネイティブのセマンティクスを持つ要素にARIAロールを追加すること、すでに見えていて読み上げられている内容と重複する装飾的なARIA、そして本当に緊急でないものにaria-live="assertive"を使うこと——スクリーンリーダーの読み上げを中断してしまい、乱用しやすい設定です。

レスポンシブ環境でのアクセシビリティ

アクセシビリティの問題は、ひとつのサイズで対処したからといって、すべてのブレイクポイントで解決されたままにはなりません。レイアウトが圧縮されても、モバイルではタッチターゲットを少なくともおおよそ44×44px確保する必要があります——デスクトップでは快適にクリックできるボタンでも、Auto Layoutのリサイズ制約で縮小されると、確実にタップするには小さすぎるものになりかねません。テキストは、幅の狭い画面で切り取られたり重なったりするのではなく、リフローする必要があり、コンテンツの順序も、スクリーンリーダーが依存する論理的な読み順を崩すような形で、ブレイクポイント間で混乱を招く変わり方をすべきではありません。

よくあるFigma→HTMLのアクセシビリティの誤り

• クリック可能な要素がすべて、本物の<button>や<a>ではなく<div onclick>に変換されている。
• アイコンのみのボタンにaria-labelがない。Figmaのレイヤーが単に「Icon 4」と名付けられていたため。
• 状態(エラー、無効化、選択済み)が色だけで伝えられている。
• フォーカス状態にoutline: noneが設定され、代わりとなる可視の表示が何も用意されていない。
• フォームフィールドの唯一のラベルとしてプレースホルダーのテキストが使われている。
• 装飾的な画像のaltテキストが、空のalt=""ではなくファイル名になっている。
• 見出しレベルが、実際のコンテンツ構造ではなくデザイン上のフォントサイズによって選ばれている。

ビフォー/アフター:アイコンのみのボタン

ビフォー——見た目は正しいが、アクセシブルではない：

<div class="icon-btn" onclick="deleteItem()">
  <svg><!-- trash icon --></svg>
</div>

アフター——見た目の結果は同じだが、実際に使える：

<button type="button" class="icon-btn" aria-label="Delete item" onclick="deleteItem()">
  <svg aria-hidden="true"><!-- trash icon --></svg>
</button>

この違いは見た目にはまったく現れません——フォーカス可能でキーボード操作でき、スクリーンリーダーに正しく読み上げられる本物の<button>要素であること、アイコンにアクセシブルな名前を与えるaria-label、そして装飾的なSVGに付けられたaria-hidden="true"によって二重に読み上げられないようにしていること、この違いです。

実践的なアクセシビリティチェックリスト

• 1ページにつき<h1>はひとつ。見出しはフォントサイズではなく順番に段階を下げる
• 本物のランドマーク要素(header、nav、main、footer)が存在する
• クリック可能なアクションはすべて<button>。ナビゲーションリンクはすべて<a href>
• すべてのフォーム入力に、プレースホルダーだけでなく本物の関連付けられた<label>がある
• 意味のある画像には説明的なaltテキストがあり、装飾的な画像にはalt=""がある
• すべてのインタラクティブ要素でフォーカス状態が可視である
• Tabキーの順序が視覚的な読み順と一致している
• テキストとUIコンポーネントのコントラストがWCAG AA(4.5:1 / 3:1)を満たしている
• 色が状態や意味を伝える唯一の信号になっていない
• ARIAはセマンティックHTMLでは操作を表現できない場所でのみ使われている
• タッチターゲットがモバイルのブレイクポイントでも使いやすいサイズを保っている
• 幅の狭い画面でテキストが切り取られたり重なったりせずにリフローする

本番投入前に生成コードをどうレビューすべきか

MarkupGenの出力は、オプトインの設定としてではなくデフォルトでセマンティック要素と本物の見出し構造を優先しており、Auto Layoutの構造が論理的なDOM順序として引き継がれることが、そもそも正しいTabキー順序を可能にしている最大の要因です。各エクスポートで得られる自動のAI品質スコアは、確かに有用な最初の手がかりですが、これは明示的に視覚的な一致度を測るスコアであり、レンダリングされたプレビューを元のデザインと比較しているだけです。ARIAの正しさやコントラスト比、キーボードの挙動を監査しているわけではありません。それらはスクリーンショットの比較には映らないからです。上記のチェックリストは、視覚スコアが高いことの代わりではなく、その後に行う手動チェックとして扱ってください——同じ原則をコードレビュー全般に当てはめた内容についてはHow to Evaluate AI-Generated HTML Before You Ship Itを参照してください。

自分のデザインで試してみる

デザインのどこにアクセシビリティ対応が必要かを知る一番早い方法は、実際に変換してみて、生成されたマークアップを開いてみることです。MarkupGenを無料で試すか、このガイドが土台としているエンドツーエンドのワークフローについては、まずFigma→HTML変換ガイド全体をご覧ください。