Основные ошибки accessibility при разработке сайта

Приветствую! В данной статье речь пойдет о самых распространенных ошибках web мастеров с точки зрения доступности для пользователей программ экранного доступа. Я, будучи и сам таким пользователем, постараюсь описать основные проблемы недоступности сайтов и способы их решения.

Хотелось бы сразу подчеркнуть, что данная статья не претендует на какой-либо стандарт, не является прямым руководством к действию, а также содержит в себе только самые распространенные, но от того не менее критичные ошибки accessability при создании сайта.

Картинки и атрибут ALT


Самой распространенной ошибкой многих web мастеров является неиспользование атрибута alt="" в теге <img/> или неправильное его использование.

Если хотя бы указывать атрибут кое-как приучили требования поисковиков, то верно указывать мало кто умеет. Ниже приведу примеры неграмотного содержимого атрибута:

  • Использование одного и того же слова для разных картинок (alt=«image»);
  • Использование не несущего смысла набора символов (alt=«dsf86sdfgbvc94nf56»);
  • Дублирование заголовка страницы;
  • Размещение в атрибуте целого предложения, словосочетания;
  • Указание в атрибуте одной буквы, зачастую не являющуюся даже первой буквой названия предмета на изображении.

Как наиболее логично использовать данный атрибут, разберем на примере.

Предположим, что у вас на сайте есть список пользователей, напротив аватарки каждого отображается его имя. Также предположим, что в списке пользователей попалось три пользователя с именем «Игорь». Если обычный пользователь среди Игорей найдет нужного по аватарке, то пользователь программы экранного доступа по одному имени нужного определить не сможет.

В этом случае самым верным решением будет у каждой аватарки в атрибуте alt="" вывести имя с фамилией пользователя. Таким образом, с точки зрения графического отображения, ничего не изменится, а незрячий посетитель сможет найти нужного человека.

Заголовки


Всем отлично известны теги заголовков с <h1> по <h6>. Думаю логично, что они должны использоваться именно для заголовков, а не для изменения размера шрифта, но находятся и такие умные люди.

В программе экранного доступа можно задать длину строки, обычно по умолчанию это 100 символов.

Когда символов в заголовке оказывается больше, чем одна сотня, скринридер перебрасывает остаток на новую строку.

Таким образом, при нажатии стрелки вниз на слишком длинном заголовке, программа озвучивает на двух строках «Заголовок уровня 1-6».

Всплывающий подсказки


На многих сайтах, в том числе некоторых регистраторов доменных имен, любят указывать цены за продление услуги во всплывающей подсказке при наведении мыши. Я не говорю, что это плохая тактика, но стоит задуматься о доступности этих подсказок для всех клиентов.

Решение очень простое, достаточно использовать у ссылок атрибут title="", но никак не использовать скрипты.

Примечание: есть непроверенная информация, что на планшетах атрибут title не озвучивается, но в статье речь идет в первую очередь о программах экранного доступа для Windows: Jaws и NVDA.

Таблицы и табличная верстка


Я не знаю, кто сейчас еще использует табличную верстку, но все же стоит от нее отказаться, если вы хотите сделать свой ресурс удобным для незрячих и слабовидящих.

Основные ошибки при использовании таблиц:

  • Вложенность одной или нескольких таблиц в другую очень затрудняет навигацию, так как скринридер читает координаты каждой ячейки;
  • Использование тега <th> там, где он не требуется. Примером может выступить скрипт игр «Ogame», «2moons», «Supernova» и подобных;

От вложенности таблиц лучше отказаться совсем, а атрибут <th> использовать в таблицах с расценками, со списком терминов, а не просто для красоты.

Роли и метки


Наверное самое известное из accessability — это роли и метки.

Атрибут role="" обычно прописывают в блоках <div>, но с приходом HTML5 надобность прописывания ролей в блоках исчезла.

В таблице представлен список ролей и заменяющих тегов из HTML5.

Роль Заменяющий тег Представление скринридером
banner <header> Банер ориентир
navigation <nav> Навигация ориентир
main <main> Основной ориентир
complementary <aside> Добавочный ориентир
contentinfo <footer> Информация о содержимом ориентир
search - Поиск ориентир

Как видно из таблицы, в HTML5 нет альтернативного тега для роли «search», ну или я ее не знаю.

Если на сайте встречается несколько разных меню, полей поиска, все ведь с одинаковой ролью, а если каждый подписывать обычным текстом, может получиться визуально слишком много информации.

В этом случае выручает атрибут area-label="".

В данном атрибуте вы можете указать любую информацию для пользователя программы экранного доступа, которая поможет ему сориентироваться среди однородных областей.

Важное дополнение: не стоит сразу же прописывать роли и метки ко всем областям сайта, это ужасно затрудняет навигацию.

Как по мне, например, роль «banner» вообще только мешается, так как всем понятно, что сверху шапка, а не подвал.

Капча


Напоследок хотелось бы затронуть тему капчей.

Благодаря специальным плагинам и аддонам, у современного пользователя скринридера не должно возникать проблем с прохождением защиты от роботов в следующих случаях:

  • капча представлена текстовым арифметическим примером с просьбой ввести ответ;
  • В форме используется виджет Recaptcha от Google, в котором необходимо просто отметить флажок;
  • если используется графическая картинка, то у нее должен быть атрибут alt, желательно alt=«captcha» или alt=«картинка с кодом».

Если же картинка с кодом без атрибута alt, либо защита представляет собой паззл, либо вообще картинка вшита в дизайн сайта и символы генерируются прямо на фоне, то форму самостоятельно отправить незрячий посетитель уже не сможет.

На этом все


Я постарался описать основные ошибки, из-за которых сайты могут быть мало доступны для пользователей программ экранного доступа. Надеюсь, что кому-нибудь данная статья поможет в создании доступного сайта.

Если у кого-то остались еще какие-либо вопросы, охотно постараюсь ответить на них в комментариях.
Метки:
Поделиться публикацией
Комментарии 43
  • 0

    Самое главное — попробуйте сами свой сайт через IE и NVDA (щас расскажу почему), узнаете много интересного о себе и о своем коде.


    Jaws является самой популярной программой среди слепых пользователей, но на самом деле она ужасна:


    • ломает рендеринг шрифтов
    • иногда без спросу добавляет раскладки
    • курсор в полях ввода начинает мигать с адской частотой

    При всем при этом стоит 900 баксов для некорпоративного пользователя. В бесплатной версии работает по 40 минут после каждого ребута. В таких условиях я бы лично отдал эти лишние 900 баксов за макбук.


    В NVDA таких проблем нет, плюс бесплатно. Синтез речи там немного похуже, но в любом случае надо в настройках включать Microsoft TTS, остальные все кромешный мрак.


    Ни тот, ни другой софт не позволяют поставить себя на паузу. Поскольку кодить под аккомпанемент роботического голоса, произносящего каждую нажатую клавишу нереально, проще всего отрубить софтине звук через микшер.

    • 0
      Здравствуйте!
      Я не знаю, где вы взяли такой бред. Видимо, вы не являетесь незрячим человеком и программами экранного доступа не пользуетесь.

      1. Оптимизировать что-то под IE — это себя не уважать. Да и IE сам по себе не самый доступный из браузеров для программ экранного доступа.
      Большинство незрячих людей пользуются спокойно Mozilla Firefox и не знают горя.

      2. Jaws является известной, но не самой часто используемой программой. У 85% всех незрячих и слабовидящих установлена NVDA, причем Jaws из них дополнительно использует всего не более 40%.

      3. Нажатием на клавишу CTRL любой синтезатор можно остановить, нажатием на SHIFT — поставить на паузу.

      4. Самыми распространенными синтезаторами для NVDA являются Ispeak, Newfon, RHVoice и голоса для SAPE5, например Милена.

      P.S.
      При всем уважении, в чем смысл вашего комментария? Как он относится к теме данной публикации?
      • 0
        Я не знаю, где вы взяли такой бред.

        А я не знаю, где вы взяли свои манеры, но крайне рекомендую обратиться туда с рекламацией и потребовать деньги назад.


        Видимо, вы не являетесь незрячим человеком

        Интересно, что вас навело на эту мысль? Уж не то ли, что я заметил испорченные шрифты и мигающий курсор?


        Большинство незрячих людей пользуются спокойно Mozilla Firefox и не знают горя.
        Jaws является известной, но не самой часто используемой программой.

        У вас свои источники, у меня свои.


        Нажатием на клавишу CTRL любой синтезатор можно остановить, нажатием на SHIFT — поставить на паузу.

        А вы сами пробовали это?


        Самыми распространенными синтезаторами для NVDA являются Ispeak, Newfon, RHVoice и голоса для SAPE5, например Милена.

        Аналогично, вы сами их пробовали?

        • –3
          Интересно, что вас навело на эту мысль? Уж не то ли, что я заметил испорченные шрифты и мигающий курсор?

          Ничуть, только ваше полное невежество и предложение во время кодинга отключать программу экранного доступа.

          А вы сами пробовали это?

          Если я тотально слепой человек и пользуюсь программой экранного доступа семь лет, может я понимаю, о чем говорю?

          Аналогично, вы сами их пробовали?

          Успешно сейчас работаю с RHVoice на максимальной скорости.

          И я повторяю вопрос: как данная тема относится к текущей публикации?
          • 0
            Если я тотально слепой человек и пользуюсь программой экранного доступа семь лет, может я понимаю, о чем говорю?

            Ваш тон и ваш подбор слов это не извиняет, даже если это и правда.


            И я повторяю вопрос: как данная тема относится к текущей публикации?

            Я буду приспосабливать сайты для пользователей с ограниченными возможностями, но в число таковых люди с функциональной неграмотностью не относятся.

      • +1
        При всем при этом стоит 900 баксов для некорпоративного пользователя. В бесплатной версии работает по 40 минут после каждого ребута. В таких условиях я бы лично отдал эти лишние 900 баксов за макбук.

        Используйте виртуальные машины, я так и делаю несмотря на наличие коробочной версии JAWS на полке. :) Перезагрузить VM раз в 40 минут не проблема, и звук заглушить тоже можно отдельно от системного.


        Только учтите, что использование демо-версии JAWS для любых целей, кроме ознакомительных, будет нарушать лицензию. Да, даже тестирование своих сайтов на совместимость. Freedom Scientific известные м%@#ки. :(


        Тестировать в IE имеет смысл, только если есть отдельный заказ именно на это. Поддержка WAI-ARIA сломана во всех версиях IE вплоть до 11, плюс навзничь кривая прокладка между браузером (MSAA) и Windows 7+ (UIA) = адская боль и безнадёга.


        Firefox + NVDA это основная связка для тестирования в 2017. В Firefox лучшая среди браузеров поддержка WAI-ARIA.


        Источник: 4 года запиливания accessibility support в одном большом и развесистом JavaScript фреймворке. :)

        • –1
          Святой вы человек! Может хоть не пользователя программ экранного доступа, но профессионального верстальщика послушает эта странная персона)
          • 0

            Спасибо, но я даже близко не святой. Мне за эту работу хорошо платят. :)


            Вёрстку знаю больше по касательной, моя задача это widgets. Делать в HTML + JavaScript годные компоненты UI как на десктопе это больно, а сделать, чтобы эти компоненты работали с экранными читалками это испытание характера и полный хардкор. Уже неплохо получается (после 4-х лет!), но до полной победы ещё ой как далеко...

            • 0
              Та я про другое))

              Если потребуется сайт какой проверить на доступность, подсказать с точки зрения не просто доступности для галочки, а конкретно доступности для длительного использования, привычности, то стучитесь на admin@maniyax.ru.

              Ну, разумеется, если вам не лень и за это платят)
              • 0

                Спасибо, непременно обращусь в будущем. Мне как зрячему человеку очень трудно оценивать доступность сайтов и веб-приложений, т.к. я не пользуюсь экранными читалками постоянно и у меня нет набора привычек и ожиданий. Грубо говоря, я не знаю, как оно должно себя вести. :)


                В прошлом году была возможность консультироваться с ребятами из University of Washington, там есть большой специалист по accessibility, при этом сам незрячий. Очень помогло сдвинуть тему из категории "ну вроде работает, фиг знает" в сторону "да вроде можно использовать". :) Помощь реальных пользователей очень ценна в таких вопросах.

                • 0
                  Сам занимаюсь разработкой сайтов (правда в последнее время переползаю в область хостинга, администрирования linux серверов), так что всегда буду рад помочь.
          • 0

            Ну винда в виртуалке тоже лицензию требует, разве нет?) Плюс пожирание ресурсов хоста и тормоза внутри, в общем, не идеальный выход.


            Поддержка WAI-ARIA сломана во всех версиях IE вплоть до 11

            Ну не знаю — то, что мы хотели, у нас в IE11 работало на таком же уровне, как в FF и Chrome.

            • +1

              Windows в виртуалке можно использовать с бесплатной лицензией: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/. Microsoft предоставляет эти образы для веб-разработки, ну так мы же о ней как раз и говорим. В эти же виртуалки можно установить JAWS и NVDA, насколько я понимаю, лицензии Microsoft это не противоречит.


              К тому же, если вы серьёзно относитесь к поддержке IE, то вам всё равно придётся держать под рукой зоопарк разных версий Windows + IE. Проще всего делать это в виртуальных машинах.


              Ну не знаю — то, что мы хотели, у нас в IE11 работало на таком же уровне, как в FF и Chrome.

              Очень хорошо если так, рад за вас. У меня ситуация другая: есть набор очень сложных и навороченных виджетов, которые надо "сделать доступными". Нативные HTML элементы весьма, гхм, ограничены, поэтому приходится использовать разные ухищрения + толстый слой WAI-ARIA соуса поверх. Вот тут IE и ломается с громким треском. :(


              Самое смешное, что во многих случаях IE8 в Windows XP работает с экранными читалками намного прямее, чем IE11 в Windows 10. Это потому, что IE использует старое MS Accessibility API, а в Windows Vista и последующих его заменило более новое UI Automation API. Между старым и новым API сделали прокладку, кривую и безумно глюкавую. Чинить её не будут, потому как IE уже всё, а Edge использует новое API напрямую. А вот насколько хорошо Edge поддерживает WAI-ARIA это тоже открытый вопрос. :(

              • 0
                Мы с одним незрячим знакомым планируем перевод WAI-ARIA сделать с разбором каждой роли, с тестированием NVDA/Jaws/Orca в FF и возможно Chrome.
                Потихоньку может так весь стандарт и протестируем, может сюда будем публиковать, если оно конечно для кого-то надо.

                Просто не нашел русского перевода стандарта, тем более с тестами.
                • 0

                  Мне кажется, более полезным был бы перевод критериев WCAG с рекомендациями по их выполнению. WAI-ARIA это набор инструментов для постройки сложных компонентов UI, использовать их нужно аккуратно и без фанатизма.


                  Есть мнение, что использование нативных элементов HTML может давать неплохие результаты, к этому надо стремиться. А если сходу кидаться использовать роли и атрибуты ARIA направо и налево, то результат будет менее, чем оптимальный. Плавали, знаем. :(

                  • 0
                    Имеете ввиду просто перевод Wcag или еще с проверкой на актуальность?

                    Есть мнение, что использование в нативных элементов HTML может давать неплохие результаты, к этому надо стремиться. А если сходу кидаться использовать роли и атрибуты ARIA направо и налево, то результат будет менее, чем оптимальный. Плавали, знаем. :(

                    Это да, но не все ведь об этом знают?)

                    И вы, как профессионал в этом деле, можете объяснить мне смысл замены всех дефолтных тегов ролями? Взять для примера замену на role=«button».
                    С Orca, например, вариант из WAI-ARIA активировать нельзя, то есть это бессмысленно как минимум для одной части программ экранного доступа.
                    • 0
                      Имеете ввиду просто перевод Wcag или еще с проверкой на актуальность?

                      Не совсем понял вопрос. Насколько я знаю, все критерии, перечисленные в WCAG 2.0 вполне актуальны в принципе, но не все могут относиться к незрячим людям.


                      Это да, но не все ведь об этом знают?)

                      Знают наверное только те, кто уже разбил на этом лоб. :)


                      И вы, как профессионал в этом деле, можете объяснить мне смысл замены всех дефолтных тегов ролями?

                      Роли не заменяют нативные элементы. Роли и прочие WAI-ARIA атрибуты нужно использовать в тех случаях, когда нативный элемент по каким-то причинам использовать нельзя, или элемент используется не по своей основной роли.


                      Если вы в разметке используете <button>foo</button>, то никаких дополнительных атрибутов использовать не нужно. Если у вас кнопки сделаны через <div>foo</div>, то нужно использовать role="button" и пр., чтобы "переубедить" браузер и дать ему понять, что это кнопка, а не просто кусок разметки с текстом.


                      Казалось бы, почему просто не использовать элемент <button>? Тому есть разные веские причины, в т.ч. трудности со стилизацией, разница в поведении вне/внутри форм, разница в поведении на десктопе и планшетах/телефонах, различные глюки браузеров и т.д. и т.п. до тошноты. А если использовать не <button>, то лезут проблемы с доступностью.


                      Текущий вариант решения примерно таков:


                      <style type="text/css">
                          .outer {
                              position: relative;
                          }
                          .inner {
                              position: absolute;
                              width: 100%;
                              height: 100%;
                          }
                          .inner-button {
                              opacity: 0;
                          }
                      </style>
                      <div id="button-1" class="outer">
                          <div id="button-1-inner" class="inner">button text here</div>
                          <button class="inner inner-button" aria-labelledby="button-1-inner"></button>
                      </div>

                      Тут недостатки тоже есть, но меньшие, чем в случае использования <div role="button">. По крайней мере можно назначить обработчик на событие click и не заморачиваться отдельно на pointer*, touch*, key*; ну и отработка фокусирования тоже идёт нативная, без страшных извращений.


                      И это просто кнопка, да. Мы с вами ещё не добрались даже до кнопок с меню, split buttons, cycle buttons, segmented buttons… А теперь масштабируйте всё это до более сложных компонентов, типа Combobox или, боже упаси, Grid. :)


                      С Orca, например, вариант из WAI-ARIA активировать нельзя, то есть это бессмысленно как минимум для одной части программ экранного доступа.

                      Orca никогда не тестировал, мы поддерживаем только NVDA и JAWS. Но охотно верю, т.к. поддержка Accessibility API хромает во всех читалках, так же как и поддержка WAI-ARIA в браузерах. Хорошо хоть ребята из Mozilla слушают (иногда) и фиксят проблемы.

                      • 0
                        Благодарю за объяснение.

                        Пока не сталкивался с невозможностью использования нотивных тегов и пр., что радует безмерно))

                        Orca, в чем ее безмерный плюс, предоставляет как можно больше информации о позиции элемента, то есть если меню горизонтальное, то и читаться оно будет как горизонтальное.
                        Причем это справедливо всегда, для любых методов реализации того же горизонтального меню, когда как NVDA и Jaws, даже в специальном режиме чтения того, что на экране, зачастую расставляют элементы в вертикальной плоскости.

                        Сейчас я наконец дорвался до чата с разработчиками ВКонтакте, будем наводить порядок в доступности, ибо ранее там не было среди тестеров ни одного человека, который смыслил бы в просто верстке, не говорю уж о адаптивной.
                        • 0
                          Пока не сталкивался с невозможностью использования нотивных тегов и пр., что радует безмерно))

                          Это просто у вас пока не было таких задач. Я бы с удовольствием использовал только нативные теги везде, но даже с банальными кнопками это не прокатывает. А такие штуки, как поля тегов или таблицы с отдельными регионами прокрутки в HTML вообще не вписываются никак, поэтому только WAI-ARIA, только хардкор.


                          Orca, в чем ее безмерный плюс, предоставляет как можно больше информации о позиции элемента, то есть если меню горизонтальное, то и читаться оно будет как горизонтальное.

                          Вот это интересно. Я всегда предполагал, что экранные читалки не озвучивают ориентацию меню просто потому, что она семантически неважна. Что в горизонтальном, что в вертикальном меню можно использовать одни и те же клавиши для навигации. Если вам важно знать ориентацию меню, то может быть имеет смысл открыть тикет в NVDA?

                          • 0
                            При личном использовании какого-либо ресурса это не очень важно, но если приходится общаться с каким-нибудь зрячим человеком, очень удобно сообщить ему что-то вроде:
                            «Пункт в горизонтальном меню справа», нежели:
                            «Пункт в меню где-то сверху экрана».
                            • 0

                              Спасибо, никогда не думал о таких вариантах использования. Наверное всё же стоит попинать разработчиков NVDA, может хотя бы как опцию добавят.

                              • 0
                                Всегда пожалуйста)

                                Если что, стучитесь по контактам: coress.ru/ct
                • 0

                  О, эта программа у них еще жива! отлично.


                  Нет, у нас только IE11.

          • 0
            Если серьезно, о чем пост?)
            Все правила, перечисленные в нем, учатся на фундаментальном уровне современной верстки. И даже более того…
            • +1
              Серьезно?
              Вот давайте для развенчания этого мифа разберем какой-нибудь сайт.
              Предлагаю вам выбрать для примера, чтобы ваши слова были чем-то подтверждены.
              • +1

                Пост о том, что 2 из 10 верстальщиков знают об этом, а применяют — 0,5 из 10.

                • 0
                  Угу.
                  Статья ведь не зря называется «Ошибки». Мало знать, изучив курсы, надо применять уметь.
                  • 0
                    Дело не в ошибках, а в деньгах. Нет смысла тратить время для 1% аудитории, если можно потратить то же время для 10% аудитории. Такие вещи должны регулироваться государством на уровне дотаций. Бизнес на это реагировать будет ровно так же как и сейчас — нет смысла тратить на это деньги.
                    • 0

                      В США суды уже штрафуют сайты за плохую доступность. Во многих странах есть нормы регулятора по доступности сайтов, как минимум государственных. Так что шанс отхватить за дискриминацию клиентов заметно отличен от нуля.

                      • 0
                        Та вон, дело в финансировании только. Все все знают, хотя на деле знают только в теории и очень отдаленно.
              • 0
                Здравствуйте. Уважаю людей с ограниченными возможностям. разрабатываю сайты (и дорабатываю ). в том году надо было для сайта детского садика поставить плагин оптимизирующий сайт для людей с ОВ по нажатии кнопки. бюджет 500рублей. ну естественно, что я не стал убирать верстку табличную или alt к картинкам дописывать. просто возможность увеличить шрифт, убрать картинки и сменить контраст. это все ))) вред ли это поможет, но сайт в соответствии ). грустно все это.
                • 0
                  Это да, грустно.
                • 0
                  Спасибо за статью, а особенно за живые примеры.
                  Вы практически не упомянули формы. Значит ли это, что вцелом с ними все ок в плане доступности?
                  Еще интересны рекомендации по использованию JS на страницах. Есть ли какие-то популярные JS плагины или техники, которых лучше избегать?
                  Есть ли смысл в хардкорной оптимизации сайта по wcag ААА, или часть требований оттуда не имеют смысла?
                  Есть ли рейтинг фреймворков/cms, у которых все хорошо/плохо с доступностью из коробки?
                  • +1
                    Здравствуйте!
                    Удивлен после всех комментариев и минусов, что статья для кого-то оказалась полезной. Радость.

                    Пойдем по порядку:
                    1. В целом с формами все нормально, кроме некоторых комбинированных списков, как в Qiwi, Yandex, например. Но я не разбирал код тех элементов, поэтому прописывать их в статье не стал. Да и не так часто они встречаются.
                    2. По JS ничего особого сказать не могу, ибо JS JS-у рознь. Если бы для примера что-то взять, а так не смогу ответить.
                    3. Читал я когда-то тот гост, вообще не понимаю, кто его писал и для кого. Для слабовидящих, не пользующихся скринридерами, там может что-то и есть полезное, но для программ экранного доступа ничего нужного.
                    4. Рейтингов нет, ибо зависит все в первую очередь от шаблона, а не CMS.
                    По личному опыту могу самым идеальным вариантом из коробки назвать тему Twenty Sixteen для Wordpress.
                    UPD: Drupal 8 вообще не доступен.
                    • 0
                      Спасибо за ответы!
                      А на минусы не обращайте внимания, здесь своя специфика. Главное, что есть полезная информация и те, кому она будет полезна, смогут ее найти.
                      • 0
                        И то хлеб, если таким людям помочь смогу. Заодно может их плюсы закроют минусы :-D
                    • 0
                      Есть ли смысл в хардкорной оптимизации сайта по wcag ААА, или часть требований оттуда не имеют смысла?

                      WCAG 2.0 наполнен смыслом до краёв, это крайне серьёзный документ. Кроме слабо- и полностью незрячих людей, есть ещё очень много видов ограниченных возможностей, WCAG пытается охватить всё, что можно.


                      Прочите документ, большая часть рекомендаций не выходит за рамки здравого смысла. Level AAA это жёсткий хардкор, на практике можно начать с первого уровня и дальше улучшать по мере необходимости.

                    • +1

                      Вот только что вспомнил важную штуку про тег alt, которую имеет смысл добавить в статью и выделить жирным шрифтом:


                      Если на сайте используются изображения, заданные через data URL, то надо обязательно присваивать таким элементам либо описание через alt="текст", если изображение несёт какой-то семантический смысл, либо role="presentation", если это просто фоновая картинка или спрайт.


                      Почему? А потому, что некоторые версии некоторых экранных читалок (JAWS! ненависть!) будут читать содержимое data-url, если нет alt. Т.е. например:


                      <img src="data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jvb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7" width="16" height="14">

                      … будет анонсировано в виде длинной строки букв, цифр и символов, что звучит ужасно конфузно. :(


                      Справедливости ради надо отметить что, сайт, с которого я взял этот пример, использует тег alt. В данном случае это неправильное решение, незрячим пользователям совершенно всё равно, есть эта картинка или её нет. Это элемент визуального оформления, который нужно "спрятать" от экранных читалок через role="presentation".

                      • 0
                        Если бы я еще знал, как тут редактировать публикации...)))

                        То наверное удалил бы ее в первый же день :-)
                      • 0
                        В заголовке: accessibility, а не accessability
                        • 0
                          Наоборот, в заголовке Accessability.
                          • 0
                            Я имел в виду, что правильно должно быть accessibility
                            https://en.wikipedia.org/wiki/Accessibility
                            • 0
                              Дык я бы изменил, но не могу найти, где статью редактировать.

                              А изначально написал accessAbility, потому что я безграмотный :-)

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.