` ボタンのことのようです]。[`activeElement`](/ja/docs/Web/API/Document/activeElement) は、ページ上で現在フォーカスの当たっている要素を教えてくれます。
-> **Note:** 自分の独自のイベントハンドラーを、イベントハンドラー・プロパティ (たとえば `onclick`) を介して設定した場合にのみ、この技法がうまくいくだろうということに留意すべきです。`addEventListener` だと、うまくいきません。
+> **メモ:** 自分の独自のイベントハンドラーを、イベントハンドラー・プロパティ (たとえば `onclick`) を介して設定した場合にのみ、この技法がうまくいくだろうということに留意すべきです。`addEventListener` だと、うまくいきません。
これでは、機能を呼び戻すように盛り込むための、余計な厄介ごとの山ですね。それに、これにともなう他の問題もきっとあるはずです。**そもそも、単にふさわしい要素をふさわしい役割に使うべきなのです。**
@@ -352,7 +352,7 @@ UI コントロールのテキストラベルはあらゆるユーザーにと
クジラは本当にすごい生き物です。クジラについてもっと知るには、ここをクリックしてください。
```
-> **Note:** リンクの実装とベスト・プラクティスに関するさらなる情報を、[Creating hyperlinks](/ja/docs/Learn/HTML/Introduction_to_HTML/Creating_hyperlinks) という記事で知ることができます。また、いくつかの良い例と悪い例を、[good-links.html](http://mdn.github.io/learning-area/accessibility/html/good-links.html) と [bad-links.html](http://mdn.github.io/learning-area/accessibility/html/bad-links.html) で見ることもできます。
+> **メモ:** リンクの実装とベスト・プラクティスに関するさらなる情報を、[Creating hyperlinks](/ja/docs/Learn/HTML/Introduction_to_HTML/Creating_hyperlinks) という記事で知ることができます。また、いくつかの良い例と悪い例を、[good-links.html](http://mdn.github.io/learning-area/accessibility/html/good-links.html) と [bad-links.html](http://mdn.github.io/learning-area/accessibility/html/bad-links.html) で見ることもできます。
フォーム・ラベルも重要です。なぜなら、各フォーム入力欄に何を入力する必要があるのかについての手がかりを与えてくれるからです。以下のものは、十分に筋の通った例のように見えます。
@@ -377,7 +377,7 @@ UI コントロールのテキストラベルはあらゆるユーザーにと
追加のおまけとして、ほとんどのブラウザーにおいて、ラベルをフォーム入力欄に結びつけることは、ラベルをクリックして当該フォーム要素を選択 / アクティブ化することが可能なことを意味します。このことにより、入力欄に対して、より大きなヒット領域を与えることになり、したがって、入力欄が選択しやすくなります。
-> **Note:** [good-form.html](http://mdn.github.io/learning-area/accessibility/html/good-form.html) と [bad-form.html](http://mdn.github.io/learning-area/accessibility/html/bad-form.html) で、いくつかの良いフォーム例と悪いフォーム例を見られます。
+> **メモ:** [good-form.html](http://mdn.github.io/learning-area/accessibility/html/good-form.html) と [bad-form.html](http://mdn.github.io/learning-area/accessibility/html/bad-form.html) で、いくつかの良いフォーム例と悪いフォーム例を見られます。
## アクセシブルなデータテーブル
@@ -415,7 +415,7 @@ UI コントロールのテキストラベルはあらゆるユーザーにと
- テーブルの見出しは、 {{htmlelement("th")}} 要素を用いて定義されています。さらに、`scope` 属性を使って、その見出しが行に対する見出しなのか列に対する見出しなのかを指定することもできます。こうすると、スクリーンリーダーが一つの単位として処理できる、データの完全なグループが示されることになります。
- {{htmlelement("caption")}} 要素と、`
` の `summary` 属性は、どちらも似たような役割を果たします。テーブルに対する alt テキストとして機能し、スクリーンリーダーのユーザーに対して、テーブルの中身についての有用で手短な要約を示すのです。`` が一般に好ましいのですが、それは、晴眼者のユーザーに対しても `` の中身がアクセシブルだからであり、晴眼者のユーザーもその中身を有用だと思うでしょう。実際には、(必ずしも) 二つとも必要というわけではありません。
-> **Note:** アクセシブルなデータテーブルにまつわる更なる詳細は、[HTML テーブルの発展的な機能とアクセシビリティ](/ja/docs/Learn/HTML/Tables/Advanced) という記事を参照してください。
+> **メモ:** アクセシブルなデータテーブルにまつわる更なる詳細は、[HTML テーブルの発展的な機能とアクセシビリティ](/ja/docs/Learn/HTML/Tables/Advanced) という記事を参照してください。
## 代替テキスト
@@ -450,7 +450,7 @@ UI コントロールのテキストラベルはあらゆるユーザーにと
1 枚目の画像は、スクリーンリーダーで見たときに、実際のところ大した手助けをユーザーに与えてはくれません。たとえば VoiceOver は、「/dinosaur.png, image」と読み上げます。なんらかの手助けを提供しようとしてファイル名を読み上げるわけです。この例では、ユーザーは、少なくともこれがある種の恐竜なのだと知ることでしょうが、機械で生成されたファイル名とともにファイルが (たとえばディジタルカメラから) アップロードされる場合もよくありますし、そうしたファイル名は画像の中身に対する文脈を何も与えてはくれないでしょう。
-> **Note:** これこそが、画像の内部にテキストコンテンツを決して含めるべきではない理由です。スクリーンリーダーは、まったくそのテキストコンテンツにアクセスできません。それに、他の欠点もあります。すなわち、そのテキストコンテンツを選択することもコピー / ペーストすることもできません。画像の内部にテキストコンテンツを含めるなどということは、とにかくしないでください!
+> **メモ:** これこそが、画像の内部にテキストコンテンツを決して含めるべきではない理由です。スクリーンリーダーは、まったくそのテキストコンテンツにアクセスできません。それに、他の欠点もあります。すなわち、そのテキストコンテンツを選択することもコピー / ペーストすることもできません。画像の内部にテキストコンテンツを含めるなどということは、とにかくしないでください!
スクリーンリーダーは、2 枚目の画像に出くわすと、alt 属性を丸々読み上げます。つまり、「赤いティラノサウルス・レックス。人間のように直立する二足歩行の恐竜で、腕は小さく、頭部は大きくて多くの鋭い歯があります」と読み上げます。
@@ -458,7 +458,7 @@ UI コントロールのテキストラベルはあらゆるユーザーにと
考えるべきことの一つは、画像がコンテンツの内部で意味を持っているのか、あるいは、純粋に視覚的装飾のためのものであって意味は持たないのか、ということです。もし画像が装飾用であれば、その画像を CSS 背景画像としてページ内に含めるだけにする方が良いのです。
-> **Note:** 画像の実装とベスト・プラクティスについての更なる多くの情報については、[Images in HTML](/ja/docs/Learn/HTML/Multimedia_and_embedding/Images_in_HTML) と [Responsive images](/ja/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images) をお読みください。
+> **メモ:** 画像の実装とベスト・プラクティスについての更なる多くの情報については、[Images in HTML](/ja/docs/Learn/HTML/Multimedia_and_embedding/Images_in_HTML) と [Responsive images](/ja/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images) をお読みください。
文脈のある追加的な情報をどうしても提示したい場合、その情報は、画像の周囲のテキストの中か、あるいは、上記のように `title` 属性の内部に入れるべきです。この場合、ほとんどのスクリーンリーダーは、`alt` テキストと、`title` 属性と、ファイル名とを読み上げるでしょう。さらに、マウスオーバーしたときには、ブラウザーが `title` テキストをツールチップとして表示します。
@@ -474,7 +474,7 @@ UI コントロールのテキストラベルはあらゆるユーザーにと
この場合、`alt` 属性をまったく使っていません。その代わり、画像についての説明を通常のテキスト段落として提示し、その段落に `id` を与え、そして、その `id` を参照するための `aria-labelledby` 属性を用いました。こうすると、スクリーンリーダーに、その段落をその画像についての alt テキスト / ラベルとして使わせることになります。これは、複数の画像に対して同じテキストをラベルとして使いたい場合に、とりわけ有用です (こうしたことは、`alt` を使ってではできない事柄なのです)。
-> **Note:** `aria-labelledby` は [WAI-ARIA](https://www.w3.org/TR/wai-aria-1.1/) 仕様の一部です。これのおかげで開発者は、必要な箇所においてスクリーンリーダーのアクセシビリティを高めるために、自分のマークアップに追加的な意味 (セマンティクス) を足すことができます。これがどのように機能するのかについての更なる情報を知るには、[WAI-ARIA の基本](/ja/docs/Learn/Accessibility/WAI-ARIA_basics) の記事をお読みください。
+> **メモ:** `aria-labelledby` は [WAI-ARIA](https://www.w3.org/TR/wai-aria-1.1/) 仕様の一部です。これのおかげで開発者は、必要な箇所においてスクリーンリーダーのアクセシビリティを高めるために、自分のマークアップに追加的な意味 (セマンティクス) を足すことができます。これがどのように機能するのかについての更なる情報を知るには、[WAI-ARIA の基本](/ja/docs/Learn/Accessibility/WAI-ARIA_basics) の記事をお読みください。
### その他の代替テキストの仕組み
@@ -510,7 +510,7 @@ HTML5 は、{{htmlelement("figure")}} と {{htmlelement("figcaption")}} とい
`alt` を含めないようにする代わりに空の `alt` を用いる理由は、`alt` が与えられていない場合には多くのスクリーンリーダーが画像の URL を丸々全部発声するからです。上記の例において画像は、その画像が結びつけられている見出しに対する視覚的装飾として機能しています。このような場合、および、画像が単に装飾にすぎず中身の価値がない場合には、画像に空の `alt` を入れるべきです。別の選択肢は、`role="presentation"` という ARIA `role` 属性を使うことです。こうすることによっても、スクリーンリーダーに代替テキスト (`alt` テキスト) を読み上げるのをやめさせることができます。
-> **Note:** もし可能なら、単なる修飾であるような画像を表示するのには CSS を使うべきです。
+> **メモ:** もし可能なら、単なる修飾であるような画像を表示するのには CSS を使うべきです。
## 要約
diff --git a/files/ja/learn/accessibility/index.md b/files/ja/learn/accessibility/index.md
index 146bbca669c3cb..7b053ff45a1baa 100644
--- a/files/ja/learn/accessibility/index.md
+++ b/files/ja/learn/accessibility/index.md
@@ -11,7 +11,7 @@ slug: Learn/Accessibility
このモジュールの大半の理解には、少なくとも [HTML](/ja/docs/Learn/HTML), [CSS](/ja/docs/Learn/CSS), [JavaScript](/ja/docs/Learn/JavaScript) の最初の 2 モジュールを通して読むのが良いでしょうし、 たぶんもっと良いのは、関連するテクノロジートピックを進めるにつれて、関連するアクセシビリティの部分を進めるのが良いでしょう。
-> **Note:** 自分のファイルを作れない コンピューター/タブレット/その他の端末で作業する場合、コードの実例の大半を [JSBin](https://jsbin.com/) や [Glitch](https://glitch.com/) などのオンラインコーディングプログラム内で試すことができます。
+> **メモ:** 自分のファイルを作れない コンピューター/タブレット/その他の端末で作業する場合、コードの実例の大半を [JSBin](https://jsbin.com/) や [Glitch](https://glitch.com/) などのオンラインコーディングプログラム内で試すことができます。
## ガイド
diff --git a/files/ja/learn/accessibility/mobile/index.md b/files/ja/learn/accessibility/mobile/index.md
index 7e3cfcfa44204a..ddb7959a7ccdbd 100644
--- a/files/ja/learn/accessibility/mobile/index.md
+++ b/files/ja/learn/accessibility/mobile/index.md
@@ -52,7 +52,7 @@ TalkBack をオフにしたい場合は、
2. \[ユーザー補助] > \[TalkBack] に移動します。
3. スライダースイッチに移動してアクティブにすると、オフになります。
-> **Note:** 連続した動きで上にスワイプしてから左にスワイプすると、いつでもホーム画面にアクセスできます。複数のホーム画面がある場合は、左右に 2 本指でスワイプすることでそれらの間を移動できます。
+> **メモ:** 連続した動きで上にスワイプしてから左にスワイプすると、いつでもホーム画面にアクセスできます。複数のホーム画面がある場合は、左右に 2 本指でスワイプすることでそれらの間を移動できます。
TalkBack ジェスチャーのより完全なリストについては、[TalkBack ジェスチャーを利用する](https://support.google.com/accessibility/android/answer/6151827?hl=ja)を参照してください。
@@ -109,7 +109,7 @@ VoiceOver のモバイル版は iOS オペレーティングシステムに組
それをオンにするには、あなたの設定アプリに行き、\[一般] > \[アクセシビリティ] > \[VoiceOver] を選択してください。VoiceOver スライダを押して有効にします(このページには VoiceOver に関連する他の多数のオプションも表示されます)。
-> **Note:** 古い iOS 端末では VoiceOver メニューは _設定_ > _一般_ > _アクセシビリティ_ > *VoiceOver*にあります。
+> **メモ:** 古い iOS 端末では VoiceOver メニューは _設定_ > _一般_ > _アクセシビリティ_ > *VoiceOver*にあります。
VoiceOver が有効になると、iOS の基本的なコントロールジェスチャーは次のように少し違います。
diff --git a/files/ja/learn/accessibility/multimedia/index.md b/files/ja/learn/accessibility/multimedia/index.md
index 95c26f26e8bc84..e8fb2cd972aa39 100644
--- a/files/ja/learn/accessibility/multimedia/index.md
+++ b/files/ja/learn/accessibility/multimedia/index.md
@@ -244,13 +244,13 @@ player.ontimeupdate = function() {
しかし、いくつかのエッジケースもあります。例えば、スプレッドシートやグラフの資料を使用したミーティングの録音オーディオがあるかもしれません。その場合、それらの資料がオーディオとトランスクリプトとともに提供されていることを確認するべきであり、特にトランスクリプトの中でそれらの資料に言及されている箇所をリンクとすることが大事です。これは聴覚障害の方だけでなく、すべてのユーザーの助けになります。
-> **Note:** オーディオトランスクリプトは、一般的に様々なユーザーグループを助けます。聴覚障害の人へオーディオに含まれたコンテンツにアクセスを提供するように、オーディオをダウンロードすることが困難な狭い帯域のユーザーのことを考えて見ましょう。パブやバーのような騒音の多い環境で、雑音のためにオーディオを聞くことが難しいユーザーのことも考えて見ましょう。
+> **メモ:** オーディオトランスクリプトは、一般的に様々なユーザーグループを助けます。聴覚障害の人へオーディオに含まれたコンテンツにアクセスを提供するように、オーディオをダウンロードすることが困難な狭い帯域のユーザーのことを考えて見ましょう。パブやバーのような騒音の多い環境で、雑音のためにオーディオを聞くことが難しいユーザーのことも考えて見ましょう。
## ビデオテキストトラック
聴覚障害者、視覚障害者、そして他のユーザー (狭い帯域のユーザーや、ビデオで使用される言語を話さないユーザー) にとってビデオをアクセシブルにするために、ビデオコンテンツにテキストトラックを含める必要があります。
-> **Note:** テキストトラックは障害者だけでなく他のユーザーにとっても便利になる可能性があります。例えば、うるさい環境 (スポーツ中継を流している混雑したバーなど) にいるためにオーディオが聞こえないユーザーや、他の人を邪魔したくない静かな場所 (図書館など) にいるユーザーなどです。
+> **メモ:** テキストトラックは障害者だけでなく他のユーザーにとっても便利になる可能性があります。例えば、うるさい環境 (スポーツ中継を流している混雑したバーなど) にいるためにオーディオが聞こえないユーザーや、他の人を邪魔したくない静かな場所 (図書館など) にいるユーザーなどです。
これは新しいコンセプトではありません — テレビ放送では、かなり長い間クローズドキャプションを提供しています:
@@ -308,7 +308,7 @@ HTML のメディア再生と共に表示させるためには、次のことを
詳細は [Adding captions and subtitles to HTML5 video](/ja/docs/Web/Apps/Fundamentals/Audio_and_video_delivery/Adding_captions_and_subtitles_to_HTML5_video) を読んでください。あなたは、GitHub で GIan Devlin によって作られた[例](http://iandevlin.github.io/mdn/video-player-with-captions/)をこの記事と併せて見ることができます。([source ソースコード](https://github.com/iandevlin/iandevlin.github.io/tree/master/mdn/video-player-with-captions) も見てください) この例では JavaScript を使用して、ユーザーが異なる言語の字幕を選択できるようになっています。字幕を表示するためには、"CC" ボタンをクリックして英語、ドイツ語、スペイン後のオプションを選択する必要があります。
-> **Note:** テキストトラックは {{glossary("SEO")}} でも役に立ちます。検索エンジンはテキストによって更新されるためです。検索エンジンは、テキストトラックによってビデオの途中に直接リンクすることさえできます。
+> **メモ:** テキストトラックは {{glossary("SEO")}} でも役に立ちます。検索エンジンはテキストによって更新されるためです。検索エンジンは、テキストトラックによってビデオの途中に直接リンクすることさえできます。
## その他のマルチメディアコンテンツ
diff --git a/files/ja/learn/accessibility/wai-aria_basics/index.md b/files/ja/learn/accessibility/wai-aria_basics/index.md
index c356f52dd78ec1..8219c2fa8acdf5 100644
--- a/files/ja/learn/accessibility/wai-aria_basics/index.md
+++ b/files/ja/learn/accessibility/wai-aria_basics/index.md
@@ -50,7 +50,7 @@ slug: Learn/Accessibility/WAI-ARIA_basics
WAI-ARIA 属性の重要な点は、ブラウザーのアクセシビリティ API(スクリーンリーダーはここから情報を取得する)によって提供される情報を除いて、それらはウェブページに何の影響も与えないという点です。 WAI-ARIA はウェブページの構造や DOM に影響を与えませんが、 CSS の要素選択で利用することが可能です。
-> **Note:** WAI-ARIA の仕様で、ARIA ロールの使用方法と追加情報へのリンクを含む便利なリストを確認することができます。 [ロールの定義](https://www.w3.org/TR/wai-aria-1.1/#role_definitions)(英語)を見てください。
+> **メモ:** WAI-ARIA の仕様で、ARIA ロールの使用方法と追加情報へのリンクを含む便利なリストを確認することができます。 [ロールの定義](https://www.w3.org/TR/wai-aria-1.1/#role_definitions)(英語)を見てください。
>
> この仕様では、プロパティとステートの追加情報を含んだリストも確認することができます。 [ステートとプロパティの定義(すべての aria-\* 属性)](https://www.w3.org/TR/wai-aria-1.1/#state_prop_def)(英語)を見てください。
@@ -70,7 +70,7 @@ WAI-ARIA 属性の重要な点は、ブラウザーのアクセシビリティ A
この記事では、全ての WAI-ARIA の機能と詳細についてカバーするわけではありません。 代わりに、あなたが知るべき最も重要な WAI-ARIA の機能についてカバーします。 もしサポートの詳細について何も記述してしない場合は、その機能が十分にサポートされていると想定してください。 この例外がある場合は、明確に記述します。
-> **Note:** JavaScript ライブラリには WAI-ARIA をサポートしているものがありますが、それはライブラリが複雑なフォームコントロールのような UI を生成した場合に、アクセシビリティを向上させるための ARIA 属性を追加することを意味します。 迅速な UI 開発のためにサードパーティーの JavaScript ライブラリを探しているのであれば、その決断を下す際、UI のアクセシビリティのサポートを重要な要素として必ず考慮すべきです。 良い例としては、 jQuery UI([jQuery UI について: ディープアクセシビリティサポート](https://jqueryui.com/about/#deep-accessibility-support)(英語)を見てください)、 [ExtJS](https://www.sencha.com/products/extjs/) 、 [Dojo/Dijit](https://dojotoolkit.org/reference-guide/1.10/dijit/a11y/statement.html) があります。
+> **メモ:** JavaScript ライブラリには WAI-ARIA をサポートしているものがありますが、それはライブラリが複雑なフォームコントロールのような UI を生成した場合に、アクセシビリティを向上させるための ARIA 属性を追加することを意味します。 迅速な UI 開発のためにサードパーティーの JavaScript ライブラリを探しているのであれば、その決断を下す際、UI のアクセシビリティのサポートを重要な要素として必ず考慮すべきです。 良い例としては、 jQuery UI([jQuery UI について: ディープアクセシビリティサポート](https://jqueryui.com/about/#deep-accessibility-support)(英語)を見てください)、 [ExtJS](https://www.sencha.com/products/extjs/) 、 [Dojo/Dijit](https://dojotoolkit.org/reference-guide/1.10/dijit/a11y/statement.html) があります。
### いつ WAI-ARIA を使うべき?
@@ -85,7 +85,7 @@ WAI-ARIA 属性の重要な点は、ブラウザーのアクセシビリティ A
もう一度言いますが、必要な時だけ使ってください!
-> **Note:** 実際のさまざまなユーザーによってあなたのサイトをテストすることも忘れないでください — 障害のないユーザー、スクリーンリーダーを使用するユーザー、キーボードナビゲーションを使用するユーザーなどです。 どれだけうまく動作するかという点で、彼らはあなたよりもうまく観察してくれるでしょう。
+> **メモ:** 実際のさまざまなユーザーによってあなたのサイトをテストすることも忘れないでください — 障害のないユーザー、スクリーンリーダーを使用するユーザー、キーボードナビゲーションを使用するユーザーなどです。 どれだけうまく動作するかという点で、彼らはあなたよりもうまく観察してくれるでしょう。
## 実際的な WAI-ARIA の実装
@@ -206,7 +206,7 @@ var intervalID = window.setInterval(showQuote, 10000);
これにより、コンテンツの更新があった際にスクリーンリーダーがその内容を読み上げてくれるようになります。
-> **Note:** `file://` URL をもつページから `XMLHttpRequest` を呼び出そうとするとほとんどのブラウザーはセキュリティ例外を投げます。 例えば、(ダブルクリックなどにより)ファイルを直接ブラウザーで読み込んだ場合に `file://` URL で開かれます。 動作させるためには、 ウェブサーバー([GitHub を利用](/ja/docs/Learn/Common_questions/Using_Github_pages)するなど)やローカルウェブサーバー([Python の SimpleHTTPServer](http://www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/)(英語)など)にファイルをアップロードする必要があります。
+> **メモ:** `file://` URL をもつページから `XMLHttpRequest` を呼び出そうとするとほとんどのブラウザーはセキュリティ例外を投げます。 例えば、(ダブルクリックなどにより)ファイルを直接ブラウザーで読み込んだ場合に `file://` URL で開かれます。 動作させるためには、 ウェブサーバー([GitHub を利用](/ja/docs/Learn/Common_questions/Using_Github_pages)するなど)やローカルウェブサーバー([Python の SimpleHTTPServer](http://www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/)(英語)など)にファイルをアップロードする必要があります。
加えて、考慮すべきことがあります。 テキストの更新された部分だけを読み上げるべきかどうかです。 常に見出し全体を読み上げる方が、何を読み上げられているかをユーザーが認識できるという点で望ましいかもしれません。 その対象に [`aria-atomic`](https://www.w3.org/TR/wai-aria-1.1/#aria-atomic) プロパティを追加することで、このような動作を得ることができます。 手元の `` タグを再度更新して、次のようにしてください。
@@ -216,9 +216,9 @@ var intervalID = window.setInterval(showQuote, 10000);
この `aria-atomic="true"` 属性が、更新された一部分だけではなく、要素全体のコンテンツを 1 つのまとまりとして読み上げるようスクリーンリーダーに伝えます。
-> **Note:** 完成した例は [aria-live.html](https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-live.html) をご覧ください(もしくは[動作版をご覧ください](http://mdn.github.io/learning-area/accessibility/aria/aria-live.html))。
+> **メモ:** 完成した例は [aria-live.html](https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-live.html) をご覧ください(もしくは[動作版をご覧ください](http://mdn.github.io/learning-area/accessibility/aria/aria-live.html))。
-> **Note:** [`aria-relevant`](https://www.w3.org/TR/wai-aria-1.1/#aria-relevant) プロパティはライブリージョンが更新された際に何が読み上げられるかを制御するのに非常に役に立ちます。 例えば、追加や削除をされた内容だけを読み上げさせることもできます。
+> **メモ:** [`aria-relevant`](https://www.w3.org/TR/wai-aria-1.1/#aria-relevant) プロパティはライブリージョンが更新された際に何が読み上げられるかを制御するのに非常に役に立ちます。 例えば、追加や削除をされた内容だけを読み上げさせることもできます。
### キーボードでのアクセシビリティの拡張
@@ -277,7 +277,7 @@ ARIA を使用して、更に先へ踏み込むこともできるでしょうし
```
-> **Note:** この完成した例を、[form-validation-updated.html](http://mdn.github.io/learning-area/accessibility/aria/form-validation-updated.html) においてライブ版で見られます。
+> **メモ:** この完成した例を、[form-validation-updated.html](http://mdn.github.io/learning-area/accessibility/aria/form-validation-updated.html) においてライブ版で見られます。
また、古典的な {{htmlelement("label")}} 要素以上の、ある種の先進的なフォームのラベルづけ技法も、WAI-ARIA によって可能になります。 晴眼者のユーザーに対してラベルを可視にしたくない箇所にラベルを設けるために [`aria-label`](https://www.w3.org/TR/wai-aria-1.1/#aria-label) プロパティを使うことについては、すでに述べました(上記の [道しるべ/ランドマーク(Signpost/Landmark)](#signpostslandmarks) のセクションを参照)。 別のプロパティを使う別のラベルづけ技法も、いくつかあります。 例えば、非 `