learn 以下の Note: Warning: Callout: を日本語に変換

files/ja/learn/accessibility/accessibility_troubleshooting/index.md

@@ -23,7 +23,7 @@ slug: Learn/Accessibility/Accessibility_troubleshooting
 
 この評価の開始時点であなたがサイトを表示したとき、いくつかの違いや問題を見つけることでしょう。これは主にマークアップ中の違いが原因であり、CSS が正しく適用されずにスタイリングの問題を引き起こしています。心配しないでください。以降の節でそれらの問題を修正します！
 
-> **Note:** もし行き詰まって助けを求める場合 — ページ最下部の [Assessment or further help](#assessment_or_further_help) セクションを見てください。
+> **メモ:** もし行き詰まって助けを求める場合 — ページ最下部の [Assessment or further help](#assessment_or_further_help) セクションを見てください。
 
 ## プロジェクトの概要
 
@@ -39,7 +39,7 @@ slug: Learn/Accessibility/Accessibility_troubleshooting
 2. スクリーンリーダーのユーザーがナビゲートしやすいように、記事のテキストを変更できますか？
 3. サイトのナビゲーションメニュー ( `<div class="nav"></div>` で囲まれた部分) は正しい HTML5 セマンティック要素の中に入れることでよりアクセシブルになったかもしれません。どれを変更する必要がありますか？変更してください。
 
-> **Note:** タグをスタイル付けする CSS ルールセレクターは、セマンティック見出しのために適切に変更する必要があります。パラグラフ要素を加えると、スタイルもより良く見えることに気がつくでしょう。
+> **メモ:** タグをスタイル付けする CSS ルールセレクターは、セマンティック見出しのために適切に変更する必要があります。パラグラフ要素を加えると、スタイルもより良く見えることに気がつくでしょう。
 
 ### 画像
 

files/ja/learn/accessibility/css_and_javascript/index.md

@@ -166,7 +166,7 @@ a:active {
 
 問題を起こさない程度に十分にコントラストが大きいかどうかを調べる簡単な方法があります。前景色と背景色を入力して調べることができる、コントラストのチェック用ツールが、オンライン上にいくつもあります。たとえば、WebAIM の [Color Contrast Checker](http://webaim.org/resources/contrastchecker/) は、簡単に使えますし、色のコントラストに関して WCAG の基準に適合するためには何を行えば良いのかについて、説明もしてくれます。
 
-> **Note:** コントラスト比を高くすることによって、光沢のある画面のスマートフォンまたはタブレットを使う人が陽光のような明るい環境でページを読みやすくもなるでしょう。
+> **メモ:** コントラスト比を高くすることによって、光沢のある画面のスマートフォンまたはタブレットを使う人が陽光のような明るい環境でページを読みやすくもなるでしょう。
 
 もう一つ別のコツは、標識や案内について色だけに頼らないことです。というのも、色だけに頼るのは、色が見えない人々にとってまったく良くないからです。必須のフォーム・フィールドを赤でマークする代わりに、たとえば、アスタリスクと赤でマークしましょう。
 
@@ -180,7 +180,7 @@ a:active {
 
 一方で、 {{cssxref("visibility")}}`:hidden` も {{cssxref("display")}}`:none` も、スクリーン・リーダーからコンテンツを隠してしまうので、使うべきではありません。もちろん、スクリーン・リーダーからこのコンテンツを隠したいと思う然るべき理由がない限りは、ということですが。
 
-> **Note:** [Invisible Content Just for Screen Reader Users](http://webaim.org/techniques/css/invisiblecontent/) には、この話題をめぐる多くのさらに有用な詳細があります。
+> **メモ:** [Invisible Content Just for Screen Reader Users](http://webaim.org/techniques/css/invisiblecontent/) には、この話題をめぐる多くのさらに有用な詳細があります。
 
 ### ユーザーがスタイルを上書きできることを受け入れる
 
@@ -227,7 +227,7 @@ JavaScript に頼りすぎると、しばしば問題が起きます。ときど
 
 この種のフォーム検査はひかえめです。JavaScript が利用できなくても、依然としてまったく申し分なくフォームを使えます。それに、分別のあるフォームの実装なら何であれ、サーバーサイドの検査も作動させておくことでしょう。なぜなら、悪意のあるユーザーがクライアントサイドの検査を (たとえば、ブラウザーで JavaScript をオフにしておくことによって) 迂回することは、あまりに容易だからです。クライアントサイドの検査は、それでも実際に、エラーを報告するためには有用なのです。ユーザーは、自分のおかした間違いについて、サーバーまでのラウンドトリップおよびページリロードを待つ必要なしに、すぐに知ることができます。これは使い勝手の上での明らかな利点です。
 
-> **Note:** この単純なデモではサーバーサイドの検査を実装しませんでした。
+> **メモ:** この単純なデモではサーバーサイドの検査を実装しませんでした。
 
 このフォーム検査も、とてもアクセシブルにしておきました。{{htmlelement("label")}} 要素を用いて、フォーム・ラベルがそのラベルの入力欄に曖昧な点なしに紐付けられるようにして、それによってスクリーン・リーダーがラベルを一緒に読み上げられるようにしました。
 
@@ -257,7 +257,7 @@ function validate(e) {
 }
 ```
 
-> **Note:** この例では、絶対的な位置指定を用いてエラーメッセージ・ボックスを隠したり見せたりしています。visibility や display などの他の方法を使っているわけではありません。なぜなら、絶対的な位置指定は、スクリーン・リーダーがコンテンツを読めるようにしておくことを妨げないからです。
+> **メモ:** この例では、絶対的な位置指定を用いてエラーメッセージ・ボックスを隠したり見せたりしています。visibility や display などの他の方法を使っているわけではありません。なぜなら、絶対的な位置指定は、スクリーン・リーダーがコンテンツを読めるようにしておくことを妨げないからです。
 
 現実のフォーム検査は、これよりもっと複雑でしょう。入力された名前が実際に名前のようであることを確認したいかもしれませんし、入力された年齢が実際に数であり、かつ現実的である (たとえば、負数ではなく、4 桁でもない、など) ということを確認したいかもしれません。ここでは、各入力フィールドに値が入れられたことを確認する (`if(testItem.input.value === '')` という) 簡単な検査を実装しただけです。
 
@@ -281,7 +281,7 @@ function createLink(testItem) {
 
 各リンクは二つの役割を果たします。つまり、何のエラーなのかを教えてくれますし、さらに、そのリンクをクリックする / アクティブにすると問題の入力要素へ直接ジャンプして入力を訂正できるようになっています。
 
-> **Note:** この例の `focus()` の部分は少し手が込んでいます。Chrome と Edge (と、IE の新しいバージョン) は、リンクがクリックされたときに要素にフォーカスを当てるので、`onclick`/`focus()` ブロックを必要としません。Safari はリンク自体とともにフォーム要素をハイライトするだけであり、そのため、実際にフォーム要素にフォーカスを当てるには `onclick`/`focus()` ブロックが必要です。Firefox は、こうした状況において入力要素に適切にフォーカスを当てることはまったくありません。よって、Firefox のユーザーは、現時点ではこの `onclick`/`focus()` ブロックの利益を享受できません (それ以外のすべてはうまく機能するのですが)。Firefox の問題はすぐに修正されるはずです。というのも、他のブラウザーと同等のふるまいを Firefox にさせるための作業が、今なされている最中ですから ({{bug(277178)}} を参照).
+> **メモ:** この例の `focus()` の部分は少し手が込んでいます。Chrome と Edge (と、IE の新しいバージョン) は、リンクがクリックされたときに要素にフォーカスを当てるので、`onclick`/`focus()` ブロックを必要としません。Safari はリンク自体とともにフォーム要素をハイライトするだけであり、そのため、実際にフォーム要素にフォーカスを当てるには `onclick`/`focus()` ブロックが必要です。Firefox は、こうした状況において入力要素に適切にフォーカスを当てることはまったくありません。よって、Firefox のユーザーは、現時点ではこの `onclick`/`focus()` ブロックの利益を享受できません (それ以外のすべてはうまく機能するのですが)。Firefox の問題はすぐに修正されるはずです。というのも、他のブラウザーと同等のふるまいを Firefox にさせるための作業が、今なされている最中ですから ({{bug(277178)}} を参照).
 
 さらに、ソース順における先頭に `errorField` を置いてあります (CSS を使って、UI 上では別のところに配置してありますが)。これが意味することは、ユーザーが、ページの最初に戻ることで、自分のフォーム送信でまさに何が間違っているのかも分かるし、問題の入力要素にも行ける、ということです。
 
@@ -296,9 +296,9 @@ function createLink(testItem) {
 
 もっと詳細に [WAI-ARIA](/ja/docs/Learn/Accessibility/WAI-ARIA_basics) を扱う次の記事で、これらの属性について説明します。
 
-> **Note:** HTML5 フォームには `required` 属性や `min`/`minlength` 属性や `max`/`maxlength` 属性のような組み込みの検査の仕組みがあること (より詳しくは、{{htmlelement("input")}} 要素のリファレンスを参照) について考える読者もおそらくいることでしょう。このデモでは、結局これらの属性は使いませんでした。なぜなら、これらの属性についてのクロスブラウザー・サポートが当てにならないからです (たとえば IE10 以上のみでのサポートだったり、Safari ではサポートされていなかったりします)。
+> **メモ:** HTML5 フォームには `required` 属性や `min`/`minlength` 属性や `max`/`maxlength` 属性のような組み込みの検査の仕組みがあること (より詳しくは、{{htmlelement("input")}} 要素のリファレンスを参照) について考える読者もおそらくいることでしょう。このデモでは、結局これらの属性は使いませんでした。なぜなら、これらの属性についてのクロスブラウザー・サポートが当てにならないからです (たとえば IE10 以上のみでのサポートだったり、Safari ではサポートされていなかったりします)。
 
-> **Note:** WebAIM の [Usable and Accessible Form Validation and Error Recovery](http://webaim.org/techniques/formvalidation/) は、アクセシブルなフォーム検査についてのさらに有用な情報をいくつか教えてくれます。
+> **メモ:** WebAIM の [Usable and Accessible Form Validation and Error Recovery](http://webaim.org/techniques/formvalidation/) は、アクセシブルなフォーム検査についてのさらに有用な情報をいくつか教えてくれます。
 
 ### JavaScript のアクセシビリティのその他の問題