[ru] replace old noteblock syntax with GFM syntax in `learn/accessibi…

…lity` folder (#22663)

[ru] replace old noteblock syntax with GFM syntax in 'learn/accessibility' folder

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

@@ -35,7 +35,8 @@ The text is difficult to read because of the current color scheme. Can you do a
 2. Can you update the article text to make it easier for screenreader users to navigate?
 3. The navigation menu part of the site (wrapped in `<div class="nav"></div>`) could be made more accessible by putting it in a proper HTML5 semantic element. Which one should it be updated to? Make the update.
 
-> **Примечание:** You'll need to update the CSS rule selectors that style the tags to their proper equivalents for the semantic headings. Once you add paragraph elements, you'll notice the styling looking better.
+> [!NOTE]
+> You'll need to update the CSS rule selectors that style the tags to their proper equivalents for the semantic headings. Once you add paragraph elements, you'll notice the styling looking better.
 
 ### The images
 

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

@@ -176,7 +176,8 @@ a:active {
 
 К счастью, проверить, всё ли в порядке с уровнем контрастности, весьма просто. Существует множество онлайн-инструментов, которые помогут сравнить пару цветов и вычислить значение контрастности. Например, [Color Contrast Checker](http://webaim.org/resources/contrastchecker/) от WebAIM. Это довольно простой в использовании инструмент, который также предоставляет инструкции, как можно добиться соответствия критериям WCAG по контрастности цветов.
 
-> **Примечание:** Высокий уровень контрастности также позволяет пользователям мобильных устройств с глянцевыми экранами комфортнее читать текст при ярком освещении.
+> [!NOTE]
+> Высокий уровень контрастности также позволяет пользователям мобильных устройств с глянцевыми экранами комфортнее читать текст при ярком освещении.
 
 Кроме того, не следует полагаться только на цвет при выделении важной информации, потому что некоторые пользователи не распознают цвета. Например, стоит не просто пометить обязательные поля формы красным, но также добавить рядом звёздочку.
 
@@ -190,7 +191,8 @@ a:active {
 
 А вот {{cssxref("visibility")}}`:hidden` и {{cssxref("display")}}`:none`, напротив, использовать для скрытия контента не следует, потому что они скрывают его не только визуально, но и от скринридеров. Поэтому применять эти свойства стоит, только если совсем скрыть контент и является вашей задачей.
 
-> **Примечание:** В статье [Невидимый контент только для пользователей скринридеров (EN)](http://webaim.org/techniques/css/invisiblecontent/) содержится множество полезной информации по этой теме.
+> [!NOTE]
+> В статье [Невидимый контент только для пользователей скринридеров (EN)](http://webaim.org/techniques/css/invisiblecontent/) содержится множество полезной информации по этой теме.
 
 ### Помните, что пользователи могут переопределять стили
 
@@ -237,7 +239,8 @@ a:active {
 
 Такая валидации формы соответствует принципам ненавязчивости — форму можно будет абсолютно полноценно использовать вообще без JavaScript. Форма всё равно будет провалидирована. Так как злонамеренные пользователи могут очень просто обойти клиентскую валидацию (например, отключив JavaScript в браузере), для важных форм её всегда дублируют на сервере. При этом валидация на стороне клиента всё ещё остаётся очень полезной для показа ошибок — пользователи узнают о проблемах с заполнением формы мгновенно, вместо того, чтобы ждать цикла: отправка на сервер - валидация - перезагрузка страницы. Это очень хорошее улучшение пользовательского опыта.
 
-> **Примечание:** В этом простом примере серверная валидация не реализована.
+> [!NOTE]
+> В этом простом примере серверная валидация не реализована.
 
 Также мы постарались сделать эту форму довольно доступной. Мы использовали элементы {{htmlelement("label")}} и связали их со своими полями ввода, таким образом скринридеры смогут корректно их озвучить:
 
@@ -267,7 +270,8 @@ function validate(e) {
 }
 ```
 
-> **Примечание:** В данном примере мы скрываем и показываем сообщение об ошибке с помощью абсолютного позиционирования, а не каким-то иным методом, потому что такой способ не мешает скринридерам озвучивать контент.
+> [!NOTE]
+> В данном примере мы скрываем и показываем сообщение об ошибке с помощью абсолютного позиционирования, а не каким-то иным методом, потому что такой способ не мешает скринридерам озвучивать контент.
 
 В реальности валидация формы будет в разы сложнее. Возможно, вы захотите проверить, что введённое имя действительно выглядит как имя, а возраст — как число, да ещё и реалистичное (например, не отрицательное и состоящее не более чем из 3 цифр). Здесь мы реализовали лишь примитивную проверку на наличие хоть какого-то текста в полях ввода (`if (testItem.input.value === '')`).
 
@@ -297,7 +301,8 @@ function createLink(testItem) {
 
 Каждая ссылка выполняет две задачи — она рассказыает, какая ошибка случилась, а также при клике на неё можно перейти прямо в связанное поле ввода и скорректировать введённое значение.
 
-> **Примечание:** Часть этого примера, связанная с `focus()`, довольно хитрая. Браузеры Chrome и Edge (а также новые версии IE) не нуждаются в коде `onclick`/`focus()` — они сами переведут фокус на элемент после клика по ссылке. Safari лишь выделит нужный элемент, так что этот блок кода нужен для корректной установки фокуса. В Firefox же трюк с выделением элемента при клике по ссылке не работает вообще. Данная ошибка должна быть вскоре исправлена — тогда Firefox придет к паритету с прочими браузерами (смотрите [Firefox bug 277178](https://bugzil.la/277178)).
+> [!NOTE]
+> Часть этого примера, связанная с `focus()`, довольно хитрая. Браузеры Chrome и Edge (а также новые версии IE) не нуждаются в коде `onclick`/`focus()` — они сами переведут фокус на элемент после клика по ссылке. Safari лишь выделит нужный элемент, так что этот блок кода нужен для корректной установки фокуса. В Firefox же трюк с выделением элемента при клике по ссылке не работает вообще. Данная ошибка должна быть вскоре исправлена — тогда Firefox придет к паритету с прочими браузерами (смотрите [Firefox bug 277178](https://bugzil.la/277178)).
 
 Дополнительно, то что `errorField` расположено в вёрстке в самом начале (тогда как визуально в интерфейсе расположено иначе при помощи CSS), позволяет пользователям увидеть, что именно не так с заполнением формы, и легко вернуться обратно к нужным полям ввода в начале страницы.
 
@@ -312,9 +317,11 @@ function createLink(testItem) {
 
 Мы разберем данные атрибуты в следующей статье, которая подробно описывает [WAI-ARIA](/ru/docs/Learn/Accessibility/WAI-ARIA_basics).
 
-> **Примечание:** Кто-то из читателей мог задуматься о том факте, что в HTML5 формах есть встроенные механизмы валидации, такие как атрибуты `required`, `min`/`minlength` и `max`/`maxlength` (смотрите подробнее на странице элемента {{htmlelement("input")}}). Мы не использовали их в примере, потому что поддержка браузерами у HTML5 валидации весьма варьируется (например, только IE10 и новее).
+> [!NOTE]
+> Кто-то из читателей мог задуматься о том факте, что в HTML5 формах есть встроенные механизмы валидации, такие как атрибуты `required`, `min`/`minlength` и `max`/`maxlength` (смотрите подробнее на странице элемента {{htmlelement("input")}}). Мы не использовали их в примере, потому что поддержка браузерами у HTML5 валидации весьма варьируется (например, только IE10 и новее).
 
-> **Примечание:** Статья [Удобная и доступная валидация форм (EN)](http://webaim.org/techniques/formvalidation/) от WebAIM содержит дополнительную полезную информацию по этой теме.
+> [!NOTE]
+> Статья [Удобная и доступная валидация форм (EN)](http://webaim.org/techniques/formvalidation/) от WebAIM содержит дополнительную полезную информацию по этой теме.
 
 ### Прочие проблемы доступности, связанные с JavaScript