diff --git a/content/docs/accessibility.md b/content/docs/accessibility.md
index 663251a03..dd101d81a 100644
--- a/content/docs/accessibility.md
+++ b/content/docs/accessibility.md
@@ -1,22 +1,22 @@
 ---
 id: accessibility
-title: Accessibility
+title: アクセシビリティ
 permalink: docs/accessibility.html
 ---
 
-## Why Accessibility? {#why-accessibility}
+## なぜアクセシビリティが必要なのか？ {#why-accessibility}
 
-Web accessibility (also referred to as [**a11y**](https://en.wiktionary.org/wiki/a11y)) is the design and creation of websites that can be used by everyone. Accessibility support is necessary to allow assistive technology to interpret web pages.
+Web アクセシビリティ（[**a11y**](https://en.wiktionary.org/wiki/a11y) とも呼ばれます）とは、誰にでも使えるようウェブサイトを設計・構築することです。ユーザ補助技術がウェブページを解釈できるようにするためには、サイトでアクセシビリティをサポートする必要があります。
 
-React fully supports building accessible websites, often by using standard HTML techniques.
+React はアクセシビリティを備えたウェブサイトの構築を全面的にサポートしており、大抵は標準の HTML の技術が用いられます。
 
-## Standards and Guidelines {#standards-and-guidelines}
+## 標準およびガイドライン {#standards-and-guidelines}
 
 ### WCAG {#wcag}
 
-The [Web Content Accessibility Guidelines](https://www.w3.org/WAI/intro/wcag) provides guidelines for creating accessible web sites.
+[Web Content Accessibility Guidelines](https://www.w3.org/WAI/intro/wcag) はアクセシビリティを備えたウェブサイトを構築するためのガイドラインを提供しています。
 
-The following WCAG checklists provide an overview:
+以下の WCAG のチェックリストはその概要を示します。
 
 - [WCAG checklist from Wuhcag](https://www.wuhcag.com/wcag-checklist/)
 - [WCAG checklist from WebAIM](http://webaim.org/standards/wcag/checklist)
@@ -24,9 +24,9 @@ The following WCAG checklists provide an overview:
 
 ### WAI-ARIA {#wai-aria}
 
-The [Web Accessibility Initiative - Accessible Rich Internet Applications](https://www.w3.org/WAI/intro/aria) document contains techniques for building fully accessible JavaScript widgets.
+[Web Accessibility Initiative - Accessible Rich Internet Applications](https://www.w3.org/WAI/intro/aria) には十分なアクセシビリティを持つ JavaScript ウィジェットの構築テクニックが含まれています。
 
-Note that all `aria-*` HTML attributes are fully supported in JSX. Whereas most DOM properties and attributes in React are camelCased, these attributes should be hyphen-cased (also known as kebab-case, lisp-case, etc) as they are in plain HTML:
+補足として、JSX ではすべての `aria-*` で始まる HTML 属性がサポートされています。React においてほとんどの DOM プロパティと属性がキャメルケースである一方で、これらの属性は純粋な HTML と同じようにハイフンケース（ケバブケースやリスプケースなどとも言われる）である必要があります。
 
 ```javascript{3,4}
 <input
@@ -39,16 +39,15 @@ Note that all `aria-*` HTML attributes are fully supported in JSX. Whereas most
 />
 ```
 
-## Semantic HTML {#semantic-html}
-Semantic HTML is the foundation of accessibility in a web application. Using the various HTML elements to reinforce the meaning of information
-in our websites will often give us accessibility for free.
+## セマンティックな HTML {#semantic-html}
 
-- [MDN HTML elements reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Element)
+セマンティック（意味論的）な HTML はウェブアプリケーションにおけるアクセシビリティの基礎となります。ウェブサイト内の情報の意味を明確にするための多様な HTML 要素を使うことにより、大抵の場合は少ない手間でアクセシビリティを手に入れられます。
 
-Sometimes we break HTML semantics when we add `<div>` elements to our JSX to make our React code work, especially when working with lists (`<ol>`, `<ul>` and `<dl>`) and the HTML `<table>`.
-In these cases we should rather use [React Fragments](/docs/fragments.html) to group together multiple elements.
+- [MDN HTML 要素リファレンス](https://developer.mozilla.org/en-US/docs/Web/HTML/Element)
 
-For example,
+ときおり、React コードを動くようにするために JSX に `<div>` を追加すると、HTML のセマンティックが崩れることがあります。とりわけ、リスト (`<ol>`, `<ul>`, `<dl>`) や `<table>` タグと組み合わせるときに問題になります。そんなときは複数の要素をグループ化するために [React フラグメント](/docs/fragments.html)を使う方がよいでしょう。
+
+具体例です。
 
 ```javascript{1,5,8}
 import React, { Fragment } from 'react';
@@ -73,7 +72,7 @@ function Glossary(props) {
 }
 ```
 
-You can map a collection of items to an array of fragments as you would any other type of element as well:
+項目の集合をフラグメントの配列に変換することができますし、他の任意の要素でも同様です。
 
 ```javascript{6,9}
 function Glossary(props) {
@@ -91,7 +90,7 @@ function Glossary(props) {
 }
 ```
 
-When you don't need any props on the Fragment tag you can use the [short syntax](/docs/fragments.html#short-syntax), if your tooling supports it:
+もし、フラグメントタグに props を渡す必要がなく、かつ使用しているツールがサポートしているのであれば、[省略記法](/docs/fragments.html#short-syntax)が使えます。
 
 ```javascript{3,6}
 function ListItem({ item }) {
@@ -104,72 +103,71 @@ function ListItem({ item }) {
 }
 ```
 
-For more info, see [the Fragments documentation](/docs/fragments.html).
+より詳細な情報は[フラグメントドキュメント](/docs/fragments.html)にあります。
+
+## アクセシブルなフォーム {#accessible-forms}
 
-## Accessible Forms {#accessible-forms}
+### ラベル付け {#labeling}
 
-### Labeling {#labeling}
-Every HTML form control, such as `<input>` and `<textarea>`, needs to be labeled accessibly. We need to provide descriptive labels that are also exposed to screen readers.
+`<input>` や `<textarea>` のような各 HTML フォームコントロールには、アクセシブルな形でのラベル付けが必要です。スクリーンリーダに公開される、説明的なラベルを提供する必要があります。
 
-The following resources show us how to do this:
+以下の資料にはその方法が示されています：
 
-- [The W3C shows us how to label elements](https://www.w3.org/WAI/tutorials/forms/labels/)
-- [WebAIM shows us how to label elements](http://webaim.org/techniques/forms/controls)
-- [The Paciello Group explains accessible names](https://www.paciellogroup.com/blog/2017/04/what-is-an-accessible-name/)
+- [W3C による要素にラベルを付ける方法の解説](https://www.w3.org/WAI/tutorials/forms/labels/)
+- [WebAIM による要素にラベルを付ける方法の解説](http://webaim.org/techniques/forms/controls)
+- [The Paciello Group によるアクセシブルな名前についての解説](https://www.paciellogroup.com/blog/2017/04/what-is-an-accessible-name/)
 
-Although these standard HTML practices can be directly used in React, note that the `for` attribute is written as `htmlFor` in JSX:
+React でこれらの標準的な HTML の実践知識を直接使用できますが、JSX では `for` 属性は `htmlFor` として記述されることに注意してください。
 
 ```javascript{1}
 <label htmlFor="namedInput">Name:</label>
 <input id="namedInput" type="text" name="name"/>
 ```
 
-### Notifying the user of errors {#notifying-the-user-of-errors}
+### ユーザーへのエラー通知 {#notifying-the-user-of-errors}
 
-Error situations need to be understood by all users. The following link shows us how to expose error texts to screen readers as well:
+すべてのユーザがエラーの起きた状況を理解できる必要があります。以下のリンクはどのようにエラーテキストをユーザーと同じくスクリーンリーダにも公開するかを解説しています。
 
-- [The W3C demonstrates user notifications](https://www.w3.org/WAI/tutorials/forms/notifications/)
-- [WebAIM looks at form validation](http://webaim.org/techniques/formvalidation/)
+- [W3C によるユーザーへの通知方法の例示](https://www.w3.org/WAI/tutorials/forms/notifications/)
+- [WebAIM によるフォームバリデーションの解説](http://webaim.org/techniques/formvalidation/)
 
-## Focus Control {#focus-control}
+## フォーカス制御 {#focus-control}
 
-Ensure that your web application can be fully operated with the keyboard only:
+あなたのウェブアプリケーションが完全にキーボードだけで操作できることを確かめてください：
 
-- [WebAIM talks about keyboard accessibility](http://webaim.org/techniques/keyboard/)
+- [WebAIM によるキーボードアクセシビリティの解説](http://webaim.org/techniques/keyboard/)
 
-### Keyboard focus and focus outline {#keyboard-focus-and-focus-outline}
+### キーボードフォーカスとフォーカス時のアウトライン（輪郭線）{#keyboard-focus-and-focus-outline}
 
-Keyboard focus refers to the current element in the DOM that is selected to accept input from the keyboard. We see it everywhere as a focus outline similar to that shown in the following image:
+キーボードフォーカスは DOM の中でキーボードからの入力を受け付けるために選択されている要素を示します。フォーカスを輪郭線で示した以下の画像のような例を、様々な場所で見かけることができます：
 
-<img src="../images/docs/keyboard-focus.png" alt="Blue keyboard focus outline around a selected link." />
+<img src="../images/docs/keyboard-focus.png" alt="選択中のリンクの周囲に表示されている青色のフォーカス線" />
 
-Only ever use CSS that removes this outline, for example by setting `outline: 0`, if you are replacing it with another focus outline implementation.
+例えば `outline: 0` のようにしてこのアウトラインを CSS で削除できますが、これは他の実装でフォーカス線を置き換える場合にのみ行うようにしてください。
 
-### Mechanisms to skip to desired content {#mechanisms-to-skip-to-desired-content}
+### 目的のコンテンツまで飛べる仕組み {#mechanisms-to-skip-to-desired-content}
 
-Provide a mechanism to allow users to skip past navigation sections in your application as this assists and speeds up keyboard navigation.
+キーボードによる操作を補助して高速化するために、あなたのアプリケーションのナビゲーション（メニューや目次）部分をユーザが読み飛ばせるような仕組みを提供しましょう。
 
-Skiplinks or Skip Navigation Links are hidden navigation links that only become visible when keyboard users interact with the page. They are very easy to implement with
-internal page anchors and some styling:
+スキップリンクやスキップナビゲーションリンクとは、ユーザがキーボードでページを操作する場合にのみ出現する、隠れたナビゲーションリンクです。これらのリンクはページ内アンカーといくらかのスタイルを用いて、とても簡単に実装できます：
 
 - [WebAIM - Skip Navigation Links](http://webaim.org/techniques/skipnav/)
 
-Also use landmark elements and roles, such as `<main>` and `<aside>`, to demarcate page regions as assistive technology allow the user to quickly navigate to these sections.
+`<main>` や `<aside>` のようなランドマーク要素とロール属性も活用してページの領域を区切り、補助技術を使うユーザが素早くこれらのセクションに移動できるようにしてください。
 
-Read more about the use of these elements to enhance accessibility here:
+アクセシビリティを強化する、これらの要素の使い方についての詳細は以下を読んでください：
 
 - [Accessible Landmarks](http://www.scottohara.me/blog/2018/03/03/landmarks.html)
 
-### Programmatically managing focus {#programmatically-managing-focus}
+### プログラムによりフォーカスを管理する {#programmatically-managing-focus}
 
-Our React applications continuously modify the HTML DOM during runtime, sometimes leading to keyboard focus being lost or set to an unexpected element. In order to repair this,
-we need to programmatically nudge the keyboard focus in the right direction. For example, by resetting keyboard focus to a button that opened a modal window after that modal window is closed.
+React アプリケーションは実行されている間、継続的に HTML の DOM を変更するため、時にキーボードフォーカスが失われたり、予期しない要素にセットされたりすることがあります。これを修正するためには、プログラムによってキーボードフォーカスを正しい位置に移動させる必要があります。例えばモーダルウィンドウを閉じた後には、モーダルを開いたボタンにキーボードフォーカスを戻すことなどです。
 
-MDN Web Docs takes a look at this and describes how we can build [keyboard-navigable JavaScript widgets](https://developer.mozilla.org/en-US/docs/Web/Accessibility/Keyboard-navigable_JavaScript_widgets).
+MDN のウェブドキュメントには、[キーボードで移動可能な JavaScript ウィジェット](https://developer.mozilla.org/en-US/docs/Web/Accessibility/Keyboard-navigable_JavaScript_widgets) の作り方が解説されています。
 
-To set focus in React, we can use [Refs to DOM elements](/docs/refs-and-the-dom.html).
+React でフォーカスをセットするには、[DOM 要素への Ref](/docs/refs-and-the-dom.html) が使えます。
 
-Using this, we first create a ref to an element in the JSX of a component class:
+これを使って、まずコンポーネントクラスの JSX 要素に ref を作成します：
 
 ```javascript{4-5,8-9,13}
 class CustomTextInput extends React.Component {
@@ -191,7 +189,7 @@ class CustomTextInput extends React.Component {
 }
 ```
 
-Then we can focus it elsewhere in our component when needed:
+これで必要な場合にはコンポーネントのほかの場所からその要素にフォーカスすることができます。
 
  ```javascript
  focus() {
@@ -201,8 +199,7 @@ Then we can focus it elsewhere in our component when needed:
  }
  ```
 
-Sometimes a parent component needs to set focus to an element in a child component. We can do this by [exposing DOM refs to parent components](/docs/refs-and-the-dom.html#exposing-dom-refs-to-parent-components)
-through a special prop on the child component that forwards the parent's ref to the child's DOM node.
+ときおり、親コンポーネントは子コンポーネント内にフォーカスをセットする必要があります。これは、子コンポーネントの特定のプロパティを通して[親コンポーネントに DOM の ref をさらし](/docs/refs-and-the-dom.html#exposing-dom-refs-to-parent-components) 、親の ref を子の DOM ノードに伝播させることで可能になります。
 
 ```javascript{4,12,16}
 function CustomTextInput(props) {
@@ -229,28 +226,24 @@ class Parent extends React.Component {
 this.inputElement.current.focus();
 ```
 
-When using a HOC to extend components, it is recommended to [forward the ref](/docs/forwarding-refs.html) to the wrapped component using the `forwardRef` function of React. If a third party HOC
-does not implement ref forwarding, the above pattern can still be used as a fallback.
+コンポーネントを拡張するのに高階コンポーネント (HOC) を使う場合は、React の `forwardRef` 関数を用いて、関数に囲われたコンポーネントに [ref を差し出す](/docs/forwarding-refs.html) ことをおすすめします。もし、サードパーティの高階コンポーネントが ref フォワーディングを実装していないときでも、上記のパターンはフォールバックとして使えます。
 
-A great focus management example is the [react-aria-modal](https://github.com/davidtheclark/react-aria-modal). This is a relatively rare example of a fully accessible modal window. Not only does it set initial focus on
-the cancel button (preventing the keyboard user from accidentally activating the success action) and trap keyboard focus inside the modal, it also resets focus back to the element that
-initially triggered the modal.
+良いフォーカス管理の例は [react-aria-modal](https://github.com/davidtheclark/react-aria-modal) です。これは完全にアクセシブルなモーダルウィンドウの比較的珍しい例です。このライブラリは、最初のフォーカスをキャンセルボタンに設定し（これは、キーボードを使っているユーザがうっかり次のアクションに移ってしまうのを防ぎます）、モーダルの中でキーボードフォーカスが閉じているだけでなく、最初にモーダルを開いた要素にフォーカスを戻してもくれます。
 
->Note:
+> 補足：
 >
->While this is a very important accessibility feature, it is also a technique that should be used judiciously. Use it to repair the keyboard focus flow when it is disturbed, not to try and anticipate how
->users want to use applications.
+> これはとても重要なアクセシビリティ機能ですが、慎重に使用されるべきテクニックでもあります。このテクニックはキーボードフォーカスの流れが妨げられた場合の修正に使用し、ユーザがアプリケーションをどのように使いたいかを試したり予測するのに使わないでください。
+
+## マウスとポインタのイベント {#mouse-and-pointer-events}
 
-## Mouse and pointer events {#mouse-and-pointer-events}
+マウスまたは、ポインタのイベントを通じて使われる機能がキーボード単体でも同じように使用できるようにしてください。ポインタデバイスだけに依存した実装は、多くの場合にキーボードユーザがアプリケーションを使えない原因になります。
 
-Ensure that all functionality exposed through a mouse or pointer event can also be accessed using the keyboard alone. Depending only on the pointer device will lead to many cases where
-keyboard users cannot use your application.
+これを説明するために、クリックイベントによってアクセシビリティが損なわれるよくある例を見てみましょう。以下の画像はアウトサイドクリックパターンというユーザが要素の外側をクリックして開いている要素を閉じられるパターンです。
 
-To illustrate this, let's look at a prolific example of broken accessibility caused by click events. This is the outside click pattern, where a user can disable an opened popover by clicking outside the element.
+<img src="../images/docs/outerclick-with-mouse.gif" alt="クリックアウトサイドパターンで実装されたトグルボタンがポップアップリストを開き、閉じる動作が機能することを示すマウスで操作される様子" />
 
-<img src="../images/docs/outerclick-with-mouse.gif" alt="A toggle button opening a popover list implemented with the click outside pattern and operated with a mouse showing that the close action works." />
 
-This is typically implemented by attaching a `click` event to the `window` object that closes the popover:
+これは通常、ポップアップを閉じる役割をもつ `click` イベントを `window` オブジェクトに付与して実装します。
 
 ```javascript{12-14,26-30}
 class OuterClickExample extends React.Component {
@@ -301,12 +294,11 @@ constructor(props) {
 }
 ```
 
-This may work fine for users with pointer devices, such as a mouse, but operating this with the keyboard alone leads to broken functionality when tabbing to the next element
-as the `window` object never receives a `click` event. This can lead to obscured functionality which blocks users from using your application.
+これはマウスのようなポインタデバイスでは問題なく機能しますが、キーボード単体で操作しようとした場合、タブキーによって次の要素に移動しても `window` オブジェクトは `click` イベントを受け取らないため、うまく機能しません。
 
-<img src="../images/docs/outerclick-with-keyboard.gif" alt="A toggle button opening a popover list implemented with the click outside pattern and operated with the keyboard showing the popover not being closed on blur and it obscuring other screen elements." />
+<img src="../images/docs/outerclick-with-keyboard.gif" alt="クリックアウトサイドパターンで実装されたトグルボタンがポップアップを開き、キーボードによってフォーカスが外れてもポップアップが閉じず、他の画面上の要素を隠してしまう様子" />
 
-The same functionality can be achieved by using an appropriate event handlers instead, such as `onBlur` and `onFocus`:
+これと同じ機能は `onBlur` と `onFocus` のような適切なイベントハンドラを代わりに用いることで実現できます。
 
 ```javascript{19-29,31-34,37-38,40-41}
 class BlurExample extends React.Component {
@@ -368,86 +360,79 @@ class BlurExample extends React.Component {
 }
 ```
 
-This code exposes the functionality to both pointer device and keyboard users. Also note the added `aria-*` props to support screen-reader users. For simplicity's sake
-the keyboard events to enable `arrow key` interaction of the popover options have not been implemented.
+上記のコードは、ポインタデバイス使うユーザとキーボードを使うユーザの双方にこの機能を公開します。さらに、`aria-*` props を加えるとスクリーンリーダを使うユーザーもサポートできます。話を簡単にするため、ポップアップの選択肢を `矢印キー` で操作できるようにするキーボードイベントは実装していません。
 
-<img src="../images/docs/blur-popover-close.gif" alt="A popover list correctly closing for both mouse and keyboard users." />
+<img src="../images/docs/blur-popover-close.gif" alt="ポップアップリストがマウスとキーボードのどちらを使うユーザーにも使いやすくなった様子" />
 
-This is one example of many cases where depending on only pointer and mouse events will break functionality for keyboard users. Always testing with the keyboard will immediately
-highlight the problem areas which can then be fixed by using keyboard aware event handlers.
+これはポインタデバイスとマウスイベントだけに依存するとキーボードを使うユーザにとって機能が損なわれてしまう数多くの具体例のうちのひとつです。つねにキーボードによるテストをすれば、キーボードに対応するイベントを使うことで解決できる問題をすばやく発見できるでしょう。
 
-## More Complex Widgets {#more-complex-widgets}
+## より複雑なウィジェット {#more-complex-widgets}
 
-A more complex user experience should not mean a less accessible one. Whereas accessibility is most easily achieved by coding as close to HTML as possible,
-even the most complex widget can be coded accessibly.
+ユーザ体験がより複雑であるほど、よりアクセシビリティが損なわれるということがあってはいけません。できるだけ HTML に近くなるようコーディングすればアクセシビリティを最も簡単に達成できますが、一方でかなり複雑なウィジェットでもアクセシビリティを保ってコーディングすることができます。
 
-Here we require knowledge of [ARIA Roles](https://www.w3.org/TR/wai-aria/#roles) as well as [ARIA States and Properties](https://www.w3.org/TR/wai-aria/#states_and_properties).
-These are toolboxes filled with HTML attributes that are fully supported in JSX and enable us to construct fully accessible, highly functional React components.
+ここでは [ARIA のロール](https://www.w3.org/TR/wai-aria/#roles) や [ARIA のステートとプロパティ](https://www.w3.org/TR/wai-aria/#states_and_properties)についての知識も必要となります。これらは JSX で完全にサポートされている HTML 属性が詰まったツールボックスであり、十分にアクセシブルで高機能な React コンポーネントの構築を可能にしてくれます。
 
-Each type of widget has a specific design pattern and is expected to function in a certain way by users and user agents alike:
+それぞれの種類のウィジェットはそれぞれ特定のデザインパターンを持っており、ユーザやユーザーエージェントはそれらが特定の方法で機能することを期待します：
 
 - [WAI-ARIA Authoring Practices - Design Patterns and Widgets](https://www.w3.org/TR/wai-aria-practices/#aria_ex)
 - [Heydon Pickering - ARIA Examples](http://heydonworks.com/practical_aria_examples/)
 - [Inclusive Components](https://inclusive-components.design/)
 
-## Other Points for Consideration {#other-points-for-consideration}
+## その他に考慮すべきポイント {#other-points-for-consideration}
 
-### Setting the language {#setting-the-language}
+### 言語設定 {#setting-the-language}
 
-Indicate the human language of page texts as screen reader software uses this to select the correct voice settings:
+ページテキストで使用する自然言語を明示して、読み上げソフトが適切な音声設定を選ぶために利用できるようにしてください：
 
 - [WebAIM - Document Language](http://webaim.org/techniques/screenreader/#language)
 
-### Setting the document title {#setting-the-document-title}
+### ドキュメントの title の設定 {#setting-the-document-title}
 
-Set the document `<title>` to correctly describe the current page content as this ensures that the user remains aware of the current page context:
+ドキュメントの `<title>` は、ユーザが現在いるページのコンテキストを認識していられるように、そのページのコンテンツを正しく説明するものにしてください：
 
 - [WCAG - Understanding the Document Title Requirement](https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html)
 
-We can set this in React using the [React Document Title Component](https://github.com/gaearon/react-document-title).
+React では [React Document Title Component](https://github.com/gaearon/react-document-title) を使用することで title を設定できます。
 
-### Color contrast {#color-contrast}
+### 色のコントラスト {#color-contrast}
 
-Ensure that all readable text on your website has sufficient color contrast to remain maximally readable by users with low vision:
+あなたのウェブサイトにある全ての読めるテキストが、色弱のユーザにも最大限読めるように配慮した色のコントラストがあることを確認してください：
 
 - [WCAG - Understanding the Color Contrast Requirement](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html)
 - [Everything About Color Contrast And Why You Should Rethink It](https://www.smashingmagazine.com/2014/10/color-contrast-tips-and-tools-for-accessibility/)
 - [A11yProject - What is Color Contrast](http://a11yproject.com/posts/what-is-color-contrast/)
 
-It can be tedious to manually calculate the proper color combinations for all cases in your website so instead, you can [calculate an entire accessible color palette with Colorable](http://jxnblk.com/colorable/).
+適切な色の組み合わせをウェブサイト内の全てのケースについて手作業で行うのは面倒になりがちなので、代わりに[アクセシブルなカラーパレット全体を Colorable で計算する](http://jxnblk.com/colorable/)ことができます。
 
-Both the aXe and WAVE tools mentioned below also include color contrast tests and will report on contrast errors.
+以下に述べる aXe および WAVE ツールのどちらも同じように色のコントラストのテストを備えておりコントラストの違反を報告してくれます。
 
-If you want to extend your contrast testing abilities you can use these tools:
+コントラストをチェックする能力を拡張したい場合は、以下のツールが利用できます：
 
 - [WebAIM - Color Contrast Checker](http://webaim.org/resources/contrastchecker/)
 - [The Paciello Group - Color Contrast Analyzer](https://www.paciellogroup.com/resources/contrastanalyser/)
 
-## Development and Testing Tools {#development-and-testing-tools}
+## 開発とテストのツール {#development-and-testing-tools}
 
-There are a number of tools we can use to assist in the creation of accessible web applications.
+アクセシブルなウェブアプリケーションの作成を支援するために利用できる様々なツールがあります。
 
-### The keyboard {#the-keyboard}
+### キーボード {#the-keyboard}
 
-By far the easiest and also one of the most important checks is to test if your entire website can be reached and used with the keyboard alone. Do this by:
+最も簡単で最も重要なチェックのうちのひとつは、ウェブサイト全体がキーボード単体であまねく探索でき、使えるかどうかのテストです。これは以下の手順でチェックできます。
 
-1. Plugging out your mouse.
-1. Using `Tab` and `Shift+Tab` to browse.
-1. Using `Enter` to activate elements.
-1. Where required, using your keyboard arrow keys to interact with some elements, such as menus and dropdowns.
+1. マウスを外します。
+2. `Tab` と `Shift+Tab` を使ってブラウズします。
+3. 要素を起動するのに `Enter` を使用します。
+4. 必要に応じて、キーボードの矢印キーを使ってメニューやドロップダウンリストなどの要素を操作します。
 
-### Development assistance {#development-assistance}
+### 開発支援 {#development-assistance}
 
-We can check some accessibility features directly in our JSX code. Often intellisense checks are already provided in JSX aware IDE's for the ARIA roles, states and properties. We also
-have access to the following tool:
+アクセシビリティ機能には JSX のコード内で直接チェックできるものもあります。JSX に対応した IDE では、ARIA ロールやステートやプロパティに対する intellisense によるチェックが既に提供されていることが多いでしょう。他にも以下のツールを使うこともできます：
 
 #### eslint-plugin-jsx-a11y {#eslint-plugin-jsx-a11y}
 
-The [eslint-plugin-jsx-a11y](https://github.com/evcohen/eslint-plugin-jsx-a11y) plugin for ESLint provides AST linting feedback regarding accessibility issues in your JSX. Many
-IDE's allow you to integrate these findings directly into code analysis and source code windows.
+ESLint の [eslint-plugin-jsx-a11y](https://github.com/evcohen/eslint-plugin-jsx-a11y) プラグインはあなたの JSX コードのアクセシビリティに対して、AST による lint のフィードバックを提供します。多くの IDE はコード解析とソースコードのウィンドウに直接そのフィードバックを統合できるようになっています。
 
-[Create React App](https://github.com/facebookincubator/create-react-app) has this plugin with a subset of rules activated. If you want to enable even more accessibility rules,
-you can create an `.eslintrc` file in the root of your project with this content:
+[Create React App](https://github.com/facebookincubator/create-react-app) はこのプラグインを備えており、一部のルールを有効化しています。もし、より多くのアクセシビリティルールを有効化したいときは、プロジェクトルートに `.eslintrc` ファイルを作成し、以下の内容を書き込んでください：
 
   ```json
   {
@@ -456,77 +441,75 @@ you can create an `.eslintrc` file in the root of your project with this content
   }
   ```
 
-### Testing accessibility in the browser {#testing-accessibility-in-the-browser}
+### ブラウザでアクセシビリティをテストする {#testing-accessibility-in-the-browser}
 
-A number of tools exist that can run accessibility audits on web pages in your browser. Please use them in combination with other accessibility checks mentioned here as they can only
-test the technical accessibility of your HTML.
+ブラウザからウェブページのアクセシビリティを検査できるツールは沢山あります。それらのツールはあなたが作成した HTML の技術的なアクセシビリティしかチェックできないため、ここで言及した他のアクセシビリティ確認法と組み合わせて使用してください。
 
 #### aXe, aXe-core and react-axe {#axe-axe-core-and-react-axe}
 
-Deque Systems offers [aXe-core](https://github.com/dequelabs/axe-core) for automated and end-to-end accessibility tests of your applications. This module includes integrations for Selenium.
+Deque System はアプリケーションの自動化された E2E アクセシビリティテストを行う [aXe-core](https://github.com/dequelabs/axe-core) を提供しています。このモジュールは Selenium に統合できます。
 
-[The Accessibility Engine](https://www.deque.com/products/axe/) or aXe, is an accessibility inspector browser extension built on `aXe-core`.
+[The Accessibility Engine](https://www.deque.com/products/axe/) もしくは aXe は、`aXe-core` により構築されたアクセシビリティを検査するブラウザ拡張機能です。
 
-You can also use the [react-axe](https://github.com/dylanb/react-axe) module to report these accessibility findings directly to the console while developing and debugging.
+[react-axe](https://github.com/dylanb/react-axe) モジュールを使用して、開発時やデバッグ時にこれらによるアクセシビリティの検査結果を直接コンソールへ出力させることもできます。
 
 #### WebAIM WAVE {#webaim-wave}
 
-The [Web Accessibility Evaluation Tool](http://wave.webaim.org/extension/) is another accessibility browser extension.
+[Web Accessibility Evaluation Tool](http://wave.webaim.org/extension/) はアクセシビリティに関する別のブラウザ拡張機能です。
 
-#### Accessibility inspectors and the Accessibility Tree {#accessibility-inspectors-and-the-accessibility-tree}
+#### アクセシビリティ検査ツールとアクセシビリティツリー {#accessibility-inspectors-and-the-accessibility-tree}
 
-[The Accessibility Tree](https://www.paciellogroup.com/blog/2015/01/the-browser-accessibility-tree/) is a subset of the DOM tree that contains accessible objects for every DOM element that should be exposed
-to assistive technology, such as screen readers.
+[アクセシビリティツリー (The Accessibility Tree)](https://www.paciellogroup.com/blog/2015/01/the-browser-accessibility-tree/) は、スクリーンリーダのような補助技術に公開されるべきすべての要素についてアクセス可能なオブジェクトを含んだ DOM ツリーのサブセットです。
 
-In some browsers we can easily view the accessibility information for each element in the accessibility tree:
+一部のブラウザではアクセシビリティツリー内の各要素のアクセシビリティに関する情報を簡単に見ることができます：
 
 - [Using the Accessibility Inspector in Firefox](https://developer.mozilla.org/en-US/docs/Tools/Accessibility_inspector)
 - [Activate the Accessibility Inspector in Chrome](https://gist.github.com/marcysutton/0a42f815878c159517a55e6652e3b23a)
 - [Using the Accessibility Inspector in OS X Safari](https://developer.apple.com/library/content/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTestingApps.html)
 
-### Screen readers {#screen-readers}
+### スクリーンリーダ {#screen-readers}
 
-Testing with a screen reader should form part of your accessibility tests.
+アクセシビリティのテストの一環として、スクリーンリーダによるテストを行うべきです。
 
-Please note that browser / screen reader combinations matter. It is recommended that you test your application in the browser best suited to your screen reader of choice.
+ブラウザとスクリーンリーダの相性に注意してください。選択したスクリーンリーダに最適なブラウザでアプリケーションのテストをすることをおすすめします。
 
-### Commonly Used Screen Readers {#commonly-used-screen-readers}
+### よく使われるスクリーンリーダ {#commonly-used-screen-readers}
 
-#### NVDA in Firefox {#nvda-in-firefox}
+#### NVDA と FireFox {#nvda-in-firefox}
 
-[NonVisual Desktop Access](https://www.nvaccess.org/) or NVDA is an open source Windows screen reader that is widely used.
+[NonVisual Desktop Access](https://www.nvaccess.org/) または NVDA は広く利用されているオープンソースの Windows 向けスクリーンリーダーです。
 
-Refer to the following guides on how to best use NVDA:
+NVDA を最大限に活用する方法は以下のガイドを参照してください：
 
 - [WebAIM - Using NVDA to Evaluate Web Accessibility](http://webaim.org/articles/nvda/)
 - [Deque - NVDA Keyboard Shortcuts](https://dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts)
 
-#### VoiceOver in Safari {#voiceover-in-safari}
+#### VoiceOver と Safari {#voiceover-in-safari}
 
-VoiceOver is an integrated screen reader on Apple devices.
+VoiceOver は Apple 社製品に統合されたスクリーンリーダです。
 
-Refer to the following guides on how activate and use VoiceOver:
+VoiceOver を有効化して使用する方法は以下のガイドを参照してください：
 
 - [WebAIM - Using VoiceOver to Evaluate Web Accessibility](http://webaim.org/articles/voiceover/)
 - [Deque - VoiceOver for OS X Keyboard Shortcuts](https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts)
 - [Deque - VoiceOver for iOS Shortcuts](https://dequeuniversity.com/screenreaders/voiceover-ios-shortcuts)
 
-#### JAWS in Internet Explorer {#jaws-in-internet-explorer}
+#### JAWS と Internet Explorer {#jaws-in-internet-explorer}
 
-[Job Access With Speech](http://www.freedomscientific.com/Products/Blindness/JAWS) or JAWS, is a prolifically used screen reader on Windows.
+[Job Access With Speech](http://www.freedomscientific.com/Products/Blindness/JAWS) もしくは JAWS は、Windows 上での使用例が豊富なスクリーンリーダです。
 
-Refer to the following guides on how to best use JAWS:
+JAWS を最大限に活用する方法は以下のガイドを参照してください：
 
 - [WebAIM - Using JAWS to Evaluate Web Accessibility](http://webaim.org/articles/jaws/)
 - [Deque - JAWS Keyboard Shortcuts](https://dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts)
 
-### Other Screen Readers {#other-screen-readers}
+### 他のスクリーンリーダ {#other-screen-readers}
 
-#### ChromeVox in Google Chrome {#chromevox-in-google-chrome}
+#### ChromeVox と Google Chrome {#chromevox-in-google-chrome}
 
-[ChromeVox](http://www.chromevox.com/) is an integrated screen reader on Chromebooks and is available [as an extension](https://chrome.google.com/webstore/detail/chromevox/kgejglhpjiefppelpmljglcjbhoiplfn?hl=en) for Google Chrome.
+[ChromeVox](http://www.chromevox.com/) は Chromebook に統合されたスクリーンリーダで、Google Chrome では[拡張機能](https://chrome.google.com/webstore/detail/chromevox/kgejglhpjiefppelpmljglcjbhoiplfn?hl=en)として利用可能です。
 
-Refer to the following guides on how best to use ChromeVox:
+ChromeVox を最大限に活用する方法は以下のガイドを参照してください：
 
 - [Google Chromebook Help - Use the Built-in Screen Reader](https://support.google.com/chromebook/answer/7031755?hl=en)
 - [ChromeVox Classic Keyboard Shortcuts Reference](http://www.chromevox.com/keyboard_shortcuts.html)