• 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。(詳細

このWikiはいつでも誰でも編集できます

「アクセシビリティコーディング規約」の版間の差分

提供: WordPress Codex 日本語版
移動先: 案内検索
(最新英語版 「Accessibility Coding Standards」(2016/8/25時点) を反映)
 
(和訳完了 「Accessibility Coding Standards」(2016/8/25時点))
1行目: 1行目:
These are standards that WordPress features should meet for accessibility in order to be merged into core. All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA. These basic guidelines are intended for easy reference during development, but do not cover all possible accessibility issues.
+
<p class="important">注意: この記事は「[https://make.wordpress.org/core/handbook/ Core Contributor Handbook]」の「[https://make.wordpress.org/core/handbook/best-practices/coding-standards/accessibility-coding-standards/ Accessibility Coding Standards]」(2016年8月25日時点)の訳です。<br />最新版については[https://make.wordpress.org/core/handbook/best-practices/coding-standards/accessibility-coding-standards/ 英語版]を参照してください。</p>
  
== HTML Semantics ==
+
この「アクセシビリティコーディング規約」は WordPress コアにマージを予定するコードが満たすべきアクセシビリティについて規定します。
 +
WordPress のすべての新規コード、および更新コードは WCAG 2.0 Guideline の Level AA に準拠する必要があります。
 +
この文書は開発中に簡単なリファレンスとして利用可能な基本のガイドラインですが、考えられるすべてのアクセシビリティ問題をカバーする意図はありませんので注意してください。
  
Take a pragmatic approach to HTML semantics. Don't add semantics purely for the sake of semantics; but if there is an HTML structure that clearly matches the content, use that element. For example, if you have a group of links, it should most likely use a list element.
+
参照: [[WordPress コーディング規約]]、[[WordPress インラインドキュメント規約]]
  
=== Heading structure ===
+
== HTML のセマンティクス<span id="HTML_Semantics"></span> ==
  
The H1 is the main heading representing the page title on every core page. For subsections, use a reasonable HTML heading structure — including the use of heading elements for page subsections. Heading markup should not be used for presentational purposes.
+
HTML のセマンティクス、あるいは意味付け、タグ付けでは、意味のある実用的なアプローチを取ってください。セマンティクスのためのセマンティクスは行わないでください。ただしコンテンツと明確に一致する HTML 構造があれば、そのタグを使用しても構いません。たとえば複数の関連するリンクがある場合、「<tt>list</tt>」要素の使用がもっとも自然です。
  
* Use H2 through H6 to give internal structure to the page.
+
=== 見出しの構造<span id="Heading_structure"></span> ===
* Don't skip heading levels.
+
* Don't add extra functionality inside a heading, like links or buttons.
+
  
=== Semantics for Controls ===
+
「<tt>H1</tt>」はすべてのページにおいてページのタイトルを表す、メインの見出しです。その下で各章や節に対応する見出し要素を含め、正しい HTML の見出し構造を使用してください。見出しのマークアップをデザイン目的で使用しないでください。
  
Controls with a native keyboard interaction (buttons or links) are always preferred. If there is a valid target link for the control, either an in-page reference or a link, then the control should use an <tt><a href=""></tt>. If there isn't, it should use a <tt><button></tt>.
+
* <tt>H2</tt> から <tt>H6</tt> を使用してページの内部構造を表してください。
 +
* 見出しのレベルをスキップしないでください。
 +
* 見出しの中に見出し以外の機能、たとえばリンクやボタンを追加しないでください。
  
If you're updating an existing control:
+
=== コントロールのセマンティクス<span id="Semantics_for_Controls"></span> ===
Button or link decision logic
+
 
 +
ボタンやリンクなど、ネイティブのキーボード操作を伴うコントロールは常に推奨されます。ページ内部での参照やリンクのように明確なリンク先が存在する場合、コントロールは「<tt><a href=""></tt>」を使用してください。そうでなければ「<tt><button></tt>」を使用してください。
 +
 
 +
既存のコントールをアップデートする場合は以下の表に従ってください。
 +
 
 +
ボタン、あるいはリンクの決定ロジック
 
<table style="border-width: thin; border-style: solid; border-collapse: collapse;">
 
<table style="border-width: thin; border-style: solid; border-collapse: collapse;">
 
<tr style="border-bottom: thin solid black;">
 
<tr style="border-bottom: thin solid black;">
<th>Scenario</th>
+
<th>シナリオ</th>
<th>Choice</th>
+
<th>選択肢</th>
 
</tr>
 
</tr>
 
<tr style="border-bottom: thin solid black;">
 
<tr style="border-bottom: thin solid black;">
<td>Anchors with null or meaningless HREF values: href='#', no href, href='#something' where #something does not exist</td>
+
<td>リンク先が null または 意味のない HREF 値、たとえば href='#'、href がない、href='#something' だが #something が存在しない</td>
 
<td><tt>button</tt></td>
 
<td><tt>button</tt></td>
 
</tr>
 
</tr>
 
<tr style="border-bottom: thin solid black;">
 
<tr style="border-bottom: thin solid black;">
<td>Anchors with meaningful on-page HREF values href='#something' where #something does exist</td>
+
<td>リンク先がページ内の意味のある HREF 値、例えば href='#something' #something は存在する</td>
<td><tt>button</tt> or <tt>a href='#target'</tt></td>
+
<td><tt>button</tt> または <tt>a href='#target'</tt></td>
 
</tr>
 
</tr>
 
<tr style="border-bottom: thin solid black;">
 
<tr style="border-bottom: thin solid black;">
<td>Anchors with meaningful off-page HREF values that are renderable (but actual behavior is AJAX)</td>
+
<td>リンク先が外部ページの意味のある HREF 値で、レンダリング可能 (ただし実際の動作は AJAX)</td>
<td>Link when JS not available, button the rest of the time.</td>
+
<td>JavaScript が利用可能であればリンク、それ以外ではボタン</td>
 
</tr>
 
</tr>
 
<tr style="border-bottom: thin solid black;">
 
<tr style="border-bottom: thin solid black;">
<td>Anchors with meaningful off-page HREF values that are *not* renderable</td>
+
<td>リンク先が外部ページの意味のある HREF 値で、レンダリングできない</td>
<td>Should be a button, but perhaps the target should be made renderable</td>
+
<td>ボタン。ただし理想的にはリンク先がレンダリング可能であるべき</td>
 
</tr>
 
</tr>
 
<tr style="border-bottom: thin solid black;">
 
<tr style="border-bottom: thin solid black;">
<td>Buttons that direct to new locations on the same page</td>
+
<td>同じページの新しい場所にジャンプするボタン</td>
<td>Could be either a button or a link.</td>
+
<td>ボタン、またはリンクの両方可</td>
 
</tr>
 
</tr>
 
<tr style="border-bottom: thin solid black;">
 
<tr style="border-bottom: thin solid black;">
<td>Buttons that direct to new locations on different pages.</td>
+
<td>外部ページの新しい場所にジャンプするボタン</td>
<td>Should be a link.</td>
+
<td>リンク</td>
 
</tr>
 
</tr>
 
</table>
 
</table>
  
=== Dynamic Content ===
+
=== 動的コンテンツ<span id="Dynamic_Content"></span> ===
  
When there are dynamic changes within a page without a page reload you must provide audible feedback with ARIA for important changes, like a successful save event, for example.
+
ページ内でリロードせずに動的な変化が起きる場合、その変化が、イベントの保存の正常終了等の重要な変化の場合には ARIA を使用し、音を使ってユーザーにフィードバックしてください。
  
Use <tt>wp.a11y.speak()</tt> for all simple AJAX responses. If you are doing a complex interaction, <tt>wp.a11y.speak()</tt> may not be the best choice. In that case, discuss your usage with the Accessibility team to determine whether extending <tt>wp.a11y.speak()</tt> or coding your own ARIA live regions is the best choice.
+
すべてのシンプルな AJAX 応答に対しては <tt>wp.a11y.speak()</tt> を使用してください。逆に複雑な応答の場合には <tt>wp.a11y.speak()</tt> は最適な選択でないかもしれません。アクセシビリティチームと使い方を相談し、<tt>wp.a11y.speak()</tt> を拡張するか、専用の ARIA ライブリージョンをコーディングするかを決定してください。
  
* [https://make.wordpress.org/accessibility/2015/04/15/let-wordpress-speak-new-in-wordpress-4-2/ Let WordPress Speak: introduction to <tt>wp.a11y.speak()</tt>].
+
* [https://make.wordpress.org/accessibility/2015/04/15/let-wordpress-speak-new-in-wordpress-4-2/ Let WordPress Speak: <tt>wp.a11y.speak()</tt> 入門].
* [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions Mozilla developer documentation on ARIA Live Regions]
+
* [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions ARIA ライブリージョンMozilla 開発者ドキュメント]
  
 +
== 色のコントラスト<span id="Color_Contrast"></span> ==
  
== Color Contrast ==
+
ほとんどの場合、プラグインがコアに色の追加や変更を行うことはないでしょう。もしもプラグインで新しい色の組み合わせを追加する必要があれば、最低限、色のコントラストの要求レベルは満たしてください。最小レベルの色のコントラスト要求は、フォントサイズが24ピクセル以下のレンダリングの場合は4.5:1、24ピクセル以上、あるいは19ピクセルで太字のレンダリングの場合は3.0:1です。
  
In most cases, feature plug-ins are not expected to add or modify colors in core. However, if a feature plug-in needs to add new color combinations, those combinations must meet minimum contrast requirements. Minimum contrast requirements are 4.5:1 for font sizes rendering smaller than 24px or smaller and 3.0:1 for font sizes larger than 24px or 19px and bold.
+
* [https://make.wordpress.org/accessibility/handbook/quick-start-guide/#color-contrast WordPress アクセシビリティクイックスタート: 色のコントラスト]
  
* [https://make.wordpress.org/accessibility/handbook/quick-start-guide/#color-contrast WordPress Accessibility Quick Start: Color Contrast]
+
== キーボードのアクセシビリティ<span id="Keyboard_Accessibility"></span> ==
  
== Keyboard Accessibility ==
+
ユーザーはページ上の操作可能なすべての要素、フォーム上のすべてのインプット、ボタン、リンクにキーボードを使用してアクセスし、操作できなければなりません。キーボードのフォーカスも視覚的に表現される必要があります。スクリーンリーダーが動作している場合、キーボードのイベントが異なる動きをする場合がありますので注意してください。
  
Users must be able to reach and successfully interact with all elements on the page that are actionable, including all form inputs, buttons and links by using the keyboard. They must be able to see a visual indicator of keyboard focus. You should be aware that keyboard events may operate differently when a screen reader is running.
+
マウスで完了できる操作はすべてキーボードを使用しても操作できなければなりません。
  
If you can complete an action with a mouse, you must also be able to complete that action using the keyboard.
+
== 画像とアイコン<span id="Images_and_Icons"></span> ==
  
== Images and Icons ==
+
すべての画像リソースはアクセス可能な名前を含む必要があります。画像は実際の <tt>&lt;img></tt> 要素、アイコンフォント、svg 要素だけでなく、グラフィカルな表現を含むすべてが対象です。要素の種類により、異なる種類のアクセス名があります。
  
Any image resource must include an accessible name. An image can be represented by an actual <tt>&lt;img></tt> element, an icon font, or an svg element; but any graphical representation is considered an image for these purposes. Different types of elements use different types of accessible names.
+
<tt>&lt;img></tt> 要素のアクセス可能な名前は alt 属性です。img が飾りの場合、その場合も alt 属性は必須ですが、値は空白で構いません。
 
+
For <tt>&lt;img></tt> elements, the accessible name should be in the alt attribute. If the img is ornamental, the alt attribute should still be included, but left empty.
+
 
+
For icon fonts, the font icon itself should be aria-hidden, with screen-reader-text in a neighbor element.
+
  
 
<pre>
 
<pre>
87行目: 91行目:
 
</pre>
 
</pre>
  
For SVG, the SVG should be inline, so that accessible information isn't hidden from assistive technology. SVG elements should contain a <tt>&lt;title></tt> element with the accessible name of the image. For cross-technology support, the title element should be associated with the svg element via aria-labelledby.
+
SVG に関しては、アクセス情報がアシスト技術で認識できるよう SVG をインラインにしてください。SVG 要素には画像のアクセス名を指定した <tt>&lt;title></tt> 要素を含めてください。クロス技術サポートのため、title 要素は aria-labelledby 属性を使用して svg 要素と関連付けてください。
 +
 
 +
* [http://www.sitepoint.com/tips-accessible-svg/ SVG アクセシビリティの詳細情報]
 +
 
 +
== ラベル<span id="Labeling"></span> ==
  
* [http://www.sitepoint.com/tips-accessible-svg/ More information on SVG Accessibility]
+
すべてのフォーム上のインプットには明示的に関連付けた <tt>&lt;label></tt> 要素が必要です。ラベルは非表示でも構いませんが、その場合は「.screen-reader-text」を使用する必要があります。プレースホルダーは使用できますが、ラベルの代用にはなりません。ラベルがフィールドのラベルの場合、クリックすると対応するフィールドに項目が移動し、チェックボックスやラジオボタンのラベル場合、クリックすると該当する項目が選択される必要があります。
  
== Labeling ==
+
情報の伝達を目的として新しい title 属性を導入しないでください。代替のラベルが必要であれば aria-label を使用し、追加のデータを付加するには <tt>.screen-reader-text</tt> を使用してください。
  
All form inputs must include an explicitly associated <tt>&lt;label></tt> element. Labels are not required to be visible, but must use the .screen-reader-text class when hidden. Placeholders are fine, but are not a substitute for labels. For all labels, clicking on the field label should cause the associated field to receive focus or, for checkboxes and radio selectors, select that choice.
+
フォームの作成では、複雑なフォームの場合、<tt>&lt;fieldset></tt> と <tt>&lt;legend></tt> を使用して関するフォームの要素を論理的にグループ化するか、見出しの下にラジオボタン、またはチェックボックスをグループ化してください。
  
Don't introduce new title attributes to convey information. Use aria-label when you need to provide an alternate label and <tt>.screen-reader-text</tt> if you're appending additional data.
+
最新英語版: [https://make.wordpress.org/core/handbook/ Core Contributor Handbook]  > [https://make.wordpress.org/core/handbook/best-practices/coding-standards/accessibility-coding-standards/ Accessibility Coding Standards]
  
When creating forms, use <tt>&lt;fieldset></tt> and <tt>&lt;legend></tt> to group logically related form elements inside complex forms or to group radio buttons and checkboxes under a heading.
+
[[Category:WordPress の開発]]

2016年8月29日 (月) 22:13時点における版

注意: この記事は「Core Contributor Handbook」の「Accessibility Coding Standards」(2016年8月25日時点)の訳です。
最新版については英語版を参照してください。

この「アクセシビリティコーディング規約」は WordPress コアにマージを予定するコードが満たすべきアクセシビリティについて規定します。 WordPress のすべての新規コード、および更新コードは WCAG 2.0 Guideline の Level AA に準拠する必要があります。 この文書は開発中に簡単なリファレンスとして利用可能な基本のガイドラインですが、考えられるすべてのアクセシビリティ問題をカバーする意図はありませんので注意してください。

参照: WordPress コーディング規約WordPress インラインドキュメント規約

HTML のセマンティクス

HTML のセマンティクス、あるいは意味付け、タグ付けでは、意味のある実用的なアプローチを取ってください。セマンティクスのためのセマンティクスは行わないでください。ただしコンテンツと明確に一致する HTML 構造があれば、そのタグを使用しても構いません。たとえば複数の関連するリンクがある場合、「list」要素の使用がもっとも自然です。

見出しの構造

H1」はすべてのページにおいてページのタイトルを表す、メインの見出しです。その下で各章や節に対応する見出し要素を含め、正しい HTML の見出し構造を使用してください。見出しのマークアップをデザイン目的で使用しないでください。

  • H2 から H6 を使用してページの内部構造を表してください。
  • 見出しのレベルをスキップしないでください。
  • 見出しの中に見出し以外の機能、たとえばリンクやボタンを追加しないでください。

コントロールのセマンティクス

ボタンやリンクなど、ネイティブのキーボード操作を伴うコントロールは常に推奨されます。ページ内部での参照やリンクのように明確なリンク先が存在する場合、コントロールは「<a href="">」を使用してください。そうでなければ「<button>」を使用してください。

既存のコントールをアップデートする場合は以下の表に従ってください。

ボタン、あるいはリンクの決定ロジック

シナリオ 選択肢
リンク先が null または 意味のない HREF 値、たとえば href='#'、href がない、href='#something' だが #something が存在しない button
リンク先がページ内の意味のある HREF 値、例えば href='#something' で #something は存在する button または a href='#target'
リンク先が外部ページの意味のある HREF 値で、レンダリング可能 (ただし実際の動作は AJAX) JavaScript が利用可能であればリンク、それ以外ではボタン
リンク先が外部ページの意味のある HREF 値で、レンダリングできない ボタン。ただし理想的にはリンク先がレンダリング可能であるべき
同じページの新しい場所にジャンプするボタン ボタン、またはリンクの両方可
外部ページの新しい場所にジャンプするボタン リンク

動的コンテンツ

ページ内でリロードせずに動的な変化が起きる場合、その変化が、イベントの保存の正常終了等の重要な変化の場合には ARIA を使用し、音を使ってユーザーにフィードバックしてください。

すべてのシンプルな AJAX 応答に対しては wp.a11y.speak() を使用してください。逆に複雑な応答の場合には wp.a11y.speak() は最適な選択でないかもしれません。アクセシビリティチームと使い方を相談し、wp.a11y.speak() を拡張するか、専用の ARIA ライブリージョンをコーディングするかを決定してください。

色のコントラスト

ほとんどの場合、プラグインがコアに色の追加や変更を行うことはないでしょう。もしもプラグインで新しい色の組み合わせを追加する必要があれば、最低限、色のコントラストの要求レベルは満たしてください。最小レベルの色のコントラスト要求は、フォントサイズが24ピクセル以下のレンダリングの場合は4.5:1、24ピクセル以上、あるいは19ピクセルで太字のレンダリングの場合は3.0:1です。

キーボードのアクセシビリティ

ユーザーはページ上の操作可能なすべての要素、フォーム上のすべてのインプット、ボタン、リンクにキーボードを使用してアクセスし、操作できなければなりません。キーボードのフォーカスも視覚的に表現される必要があります。スクリーンリーダーが動作している場合、キーボードのイベントが異なる動きをする場合がありますので注意してください。

マウスで完了できる操作はすべてキーボードを使用しても操作できなければなりません。

画像とアイコン

すべての画像リソースはアクセス可能な名前を含む必要があります。画像は実際の <img> 要素、アイコンフォント、svg 要素だけでなく、グラフィカルな表現を含むすべてが対象です。要素の種類により、異なる種類のアクセス名があります。

<img> 要素のアクセス可能な名前は alt 属性です。img が飾りの場合、その場合も alt 属性は必須ですが、値は空白で構いません。

<a href="this.html">
<span class="dashicons dashicon-thumbs-up" aria-hidden="true"></span>
<span class="screen-reader-text">Something</span>
</a>

SVG に関しては、アクセス情報がアシスト技術で認識できるよう SVG をインラインにしてください。SVG 要素には画像のアクセス名を指定した <title> 要素を含めてください。クロス技術サポートのため、title 要素は aria-labelledby 属性を使用して svg 要素と関連付けてください。

ラベル

すべてのフォーム上のインプットには明示的に関連付けた <label> 要素が必要です。ラベルは非表示でも構いませんが、その場合は「.screen-reader-text」を使用する必要があります。プレースホルダーは使用できますが、ラベルの代用にはなりません。ラベルがフィールドのラベルの場合、クリックすると対応するフィールドに項目が移動し、チェックボックスやラジオボタンのラベル場合、クリックすると該当する項目が選択される必要があります。

情報の伝達を目的として新しい title 属性を導入しないでください。代替のラベルが必要であれば aria-label を使用し、追加のデータを付加するには .screen-reader-text を使用してください。

フォームの作成では、複雑なフォームの場合、<fieldset><legend> を使用して関するフォームの要素を論理的にグループ化するか、見出しの下にラジオボタン、またはチェックボックスをグループ化してください。

最新英語版: Core Contributor Handbook > Accessibility Coding Standards